Apstra: Networking by Intent

I was excited going into the Networking Field Day (#NFD16) session with Apstra. Apstra did a great job presenting on Intent-Based Networking at #NFD13. (My prior blog about it: NFD13: Apstra’s Unique Approach to Networking.) And the NFD16 session matched expectations.

To quote my pre-NFD16 blog (not quite eating my own words): “Apstra is generating a lot of market attention. Plus, I’m convinced that most organizations looking to do SDN need to buy a ‘canned’ user-friendly supported solution or at least framework, not put together rough snippets of unmaintainable code. We don’t all have the time to be coders!”

I see the future as consisting of solutions such as Apstra, supporting the deployment and management of a component: a datacenter or campus fabric. We no longer configure devices; we configure and manage the entire datacenter fabric as one entity. And do operational management at the same time. (Early days: That’s one aspect I haven’t seen too much of, other than basic device/link up/down tracking.)

After listening to Apstra, I remain convinced: It’s helpful to be a scripter, coder, and know how to work with coding tools, but most of us just want a supported way to get the job done.

Apstra’s Potential

Let’s start with some humor — networking (and I?) can always use a smattering of humor. Apparently Apstra is a little miffed that they started talking about “Intent-Based Networking” and then the big companies’ marketing jumped in on the newest cool thing. So Apstra found a way to push back with humor about “intent washing.” Recommended amusement value.

I suppose Cisco could push back. It seems like Cisco IOS led to everyone having a “network OS” — in Apstra’s case, AOS, which is viewed as an intent-based <appropriate sound effect here> distributed OS for a datacenter network.

More seriously, here is Apstra’s definition of intent:

Besides treating the fabric as a single managed entity, the other thing that impresses me with Apstra is the hardware neutrality (Cisco, Juniper, Arista, Cumulus, other), portability, and simple maintenance. Yes, APIs are cool, as are Yang models. But every vendor has lots of them! If you like the saying “the best thing about standards is there are so many of them,” then Yang and APIs are standards x 100. Another thing I’d rather not spend my time with — each vendor’s API variant of “how to create a VLAN.” Almost as bad as the CLI variations?

After watching Veriflow at NFD16 talk about auto-intent verification, and thinking about some of what I do in network assessments with Cisco configurations, it’s become clear that there’s a lot that a good network model buys you. Knowing interface state (up/down, L2 or L3, access or trunk, portfast/portfast trunk, speed, duplex, trunk allowed VLANs, BPDU Guard, subnet mask consistency, etc.) provides the basis for some good consistency and state checks. Knowing about neighbors lets you check both ends of a link. Whether the link is L2 or L3, that’s very helpful (e.g., HSRP consistency). What I see in the field is entropy (increased randomness): A lot of discrepancies creep into configurations.

The tie-in to Apstra? They know the relationship, the intended connectivity and state. They can ascertain or specify a lot of the other state, and check consistency, either by configuring and ongoing verification, or periodic spot-checking, or both. Human fingers cause entropy. Apstra keeps fingers off the CLI. Win!

Apstra at NFD16

The NFD16 talks and demonstrations were great. The focus was different: Instead of the operator perspective, they showed the developer POV. There is a lot of power under the Apstra hood!

From my notes: “Quick new features … feature velocity … sustainable code.” GraphQL in action! Device model, Jinja, device configuration. State tracking via Pub/Sub. Agents work in parallel for scalability. I thought for quite a while about how to go over the demo content for this blog — there’s just no way (writing time, blog page count).

So, I’m going to just point you to the streaming videos of the demos. A couple of streaming videos save a thousand words!

I should mention that the Apstra team has some fun with what they’re doing. During the demo, the group realized Damien had coded a Slack plug-in for some CLI interaction with the development tools. The whole demo sequence was conceptually neat: How do we extend the Apstra standard framework?

What really stood out here was the rapidity, power, and flexibility of the development environment and tools.

Fresh Apstra!

As of Tuesday, Oct. 3, Apstra announced AOS 2.0 with new features. Right now, the announcement literature is all over the Apstra main web page. I’ll attempt to summarize, and leave the reader to forage for details if they so desire.

Summary of the announcement:

AOS™ 2.0
Underlay/overlay: VXLAN within and across racks
Run L2 apps on scale-out L3 fabric
Network operator transition to leaf/spine architecture
Autonomous network operations
Tagged interfaces, workloads assigned to VXLAN segment
Constant state validation, route validation
“Intent-based analytics” (coming)
RBAC, HTTPS, headless operation
Still vendor-agnostic
Agility

All good!

Closing Thoughts

I’m much impressed with Apstra (if you can’t tell). They’ve come a long way in a short time.

When Apstra has time to widen their product focus (i.e., wish list item!), I think I’d like to see a L3-based fabric for campus LAN networks (one or several buildings). Adding VXLAN overlay support might be a way to grow that, for those interested in or requiring larger L2 domains with the added stability of routed underlay. Perhaps a simpler/multi-vendor version of what Cisco’s SD-Access will provide?

References

Comments

Comments are welcome, both in agreement or constructive disagreement about the above. I enjoy hearing from readers and carrying on deeper discussion via comments. Thanks in advance!

Disclosure Statement