Apstra at NFD16

Terry Slattery
Principal Architect

A platform for intent-based networking development has some hidden gems.

Who Is Apstra?

Apstra is one of the companies I was looking forward to seeing at NFD16 (#NFD16). It has been mentioned by Gartner as a company to watch in 2017 because of its approach to multivendor, intent-based networking. I wasn’t disappointed. When you look at what it is currently doing, it appears the product only functions on a leaf-spine network — typically used in very modern data centers. However, the functionality it has built is extensible to other network architectures, such as those normally used in enterprise networks. A recent announcement extends support to VXLAN overlays. But that’s not where its capabilities end.

The Apstra Operating System

The Apstra Operating System (AOS) is actually a platform upon which intent-based network modules can be built and deployed. The VXLAN module is one example, as is the Layer 3 CLOS fabric (i.e., leaf-spine) support. This means it is possible to develop a module for other network topologies, such as the core, distribution, and access model that is used in traditional enterprise network designs. Apstra is wisely concentrating on the more advanced leaf-spine network market. My take on its choice is simple: Customers who are willing to use leaf-spine designs are more likely to experiment with something new that gives them a competitive edge over their peers.

Apstra told the delegates at NFD16 that it envisions the teamwork between a networking person and a software developer to create intent-based applications on top of its API. The networking person knows about network protocols and common network failures. The software developer brings software development knowledge to the team. A module development team consists of both types of professionals, working together to create an intent-based network application. This team is described in the demonstration recording, starting at 8:32. (Apstra’s NFD13 sessions talk about AOS for network operators.)

Internally, AOS uses a graph database to represent the network design. The graph is then queried to determine intent. Once intent is known, data collected from the network can be used to determine whether the network meets the expectation for its functionality (NFD16 Sasha Ratkovic defines intent, starting at 13:00). As Ivan Pepenljak observed in that segment, checking to ensure the network meets expectations is essentially unit testing. If the intent is to provide router redundancy, the check might be to verify HSRP/VRRP/GLBP functionality. This is the same testing methodology that software development teams use to help identify and correct software bugs.

Continuing the thought about validation, Damien Garros of Apstra provided a demonstration in which the schema was extended to verify the network connectivity of application servers. An interesting approach to multivendor support is that they model device roles in their reference design — not devices. For example, the model for a leaf switch would include only the functions that would be used in that role (see Jeff Tantsura’s question in the demo recording at 3:53).

The demo video includes another gem that easily could be missed. AOS is essentially a platform, much like SAP or Salesforce are platforms. Apstra has helped by building the basic leaf-spine intent-based logic. The demo showed how that basic logic can be extended to add server connectivity verification. This is why Sasha referred to the company’s demonstration as an example of AOS for the “Developer Persona” and that the NFD13 presentation was AOS for the “Operator Persona.” It is important to watch both sessions.

Slack as a CLI!

Damien surprised us during the demonstration by using Slack as the CLI to AOS (demo at 29:47). Think about the implication. Instead of using something like Postman to craft the API calls, Damien used a chatbot-style API between Slack and the AOS API. He didn’t have to write any code to handle the text input and command-line editing part of the CLI. Very cool. The mental twist here is to realize that tools with a REST API-calling mechanism can interface with the REST API of other systems.

Hidden in the discussion was another gem: A description of using Slack for network changes and verification. I highly recommend watching this demo and spending time thinking about how this part of the demo worked and how to apply this to your network operation.


A lot of capabilities within AOS may not be obviously apparent upon first exposure. It seems that every time I watch Apstra’s videos, I pick up something that I had previously overlooked. There is a great deal of capability in AOS. It is more than a network automation system that can automatically validate intent. I’m just beginning to appreciate its capabilities and look forward to the day when I can use it in a real network.


The vendors at NFD16 indirectly paid for my expenses to attend. There was no direct compensation or gifts outside of some inexpensive marketing tchotchkes, which don’t affect my opinions and blog posts.

Leave a Reply


Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.


Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.


John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.