At Apstra we focus on understanding and solving network engineering problems. We developed our intent-based networking system with input from real engineers. Now we’re adding three new sets of features in our Apstra Operating System (AOS) 1.2 release.
One set of features gives network engineers the ability to ask just about any question they can think of about their network. The second lets engineers reap all the benefits of AOS for any network design, and support additional devices more easily. The third helps engineers make changes to an existing network safely and efficiently. Let’s get started!
Network troubleshooting can be a painstaking “yak-shaving” experience. We frequently use the term “Mean-Time-To-Resolution” (MTTR) when we talk about going from problem to solution, but really there are three different stages (at least) in this process: Mean-Time-To-Insight (MTTI), Mean-Time-To-Solution (MTTS), and finally MTTR.
MTTI, in which we gain meaningful insight into what’s happening with the network, frequently takes up most of an engineer’s time, especially when they go down the wrong path when troubleshooting.
We have all these bits of information inside the network, and they are all related. For instance, there is a MAC address in an ARP entry, and in the course of troubleshooting you might find that MAC address using a “show” command, and then look for it in another show command like “show mac-table.”
When troubleshooting, we effectively follow a chain of information from one link to the next. Knowing what to look for and what direction to go takes some amount of sorcery and experience, but even seasoned engineers can waste time following the wrong links.
In AOS 1.2, our engineers have performed major surgery into how state is represented to create a graph-based model of all the interrelated information that can be harvested from the network. With this industry-first model, you can query this graph for any information about how the network was designed and deployed, and examine the current state of the network.
This helps close the gap between what the network engineers intended when they designed the network, and the actual environment the operations team has to work with as they troubleshoot and remediate the inevitable issues that arise.
There is quite a lot of information hidden away in the network, too. Apstra has taken to heart that no network tool can perfectly capture all the information an engineer might need, so we’ve introduced the ability to extend this graph model using the AOS API.
In this release, Apstra introduces python libraries that make it easy to collect, format, and stream any telemetry you might require. Where can you stream it to? AOS is now integrated with Telegraf, a popular open-source project that can route your data to a wide variety of collection tools.
Taken together, this means we, as network engineers, can reach the MTTI milestone sooner and with greater accuracy. You can construct intelligent questions for the graph query API and get quick, accurate answers!
Extend All The Things
Telemetry isn’t the only new extensible thing in AOS! Apstra has opened the hood in our 1.2 release. Network engineers using AOS can now specify their own reference network designs through our API. If our (very flexible) turnkey L3 CLOS solution doesn’t match your environment, then no problem: you can describe any network design using our API. Once the pattern is fully described to AOS, networks of any scale can be implemented from it, and with any device model from a multitude of device vendors.
We know that vendor-agnostic support has largely been an unfulfilled promise. Not any more! In version 1.2 we’ve made it much easier to support new network devices. We’re not just talking about switches either. We mean routers, firewalls, and other nodes along the network path.
And to help you integrate more devices into AOS, we’ve decoupled device support from our main release cycle—something that’s never been done in a network automation platform. This means new devices can be supported without requiring the installation of agents on the devices themselves. We even support devices without programmatic APIs!
What happens on Day 2 when your requirements have, of course, changed and you need to modify your network? We all know (whether we want to admit it or not) that networks evolve organically to encompass exceptions, design constraints, and choices that occur over time. AOS now lets engineers change their intent after a network is deployed, and stage all related changes so that the network transitions in a safe and orderly manner. Exceptions can now be accommodated in a sane, stress-free way!
Taken together, what does this mean? AOS v1.2 allows an engineer to design any network, using whatever vendors and models they want, and then specify any arbitrary telemetry relevant to that design. Most importantly, because it’s done with AOS, whatever networks you deploy from these designs will be automatically, well… automated!
In this release Apstra introduces Enhanced Day-2 Operations. Changes in the network can be staged, pre-validated, deployed, and post-validated. If something goes wrong, changes can be rolled back.
This capability extends our existing layered approach to changes: before routing configurations are applied, we ensure the right OS is on each network device, and that cabling is as expected.
Now, after the network is rolled out, the same care can be taken for ongoing operations. All this happens at the network level in a vendor-agnostic way, using AOS’s closed-loop telemetry feedback system. This new capability streamlines change operations while minimizing the risk of making errors—something network engineers have told us was really important to them. I will be writing more on this topic in the future.
What You Should Do Next
I’ve been a network engineer for 17 years, so I know that meaningful network automation has been elusive, with tools usually tightly coupled to specific network designs, device models, and features. Also, the information that these tools gathered and presented to the user have always been limited.
AOS is the first intent-based, vendor-agnostic, closed-loop software to address all of these problems. Check out what our CTO, Sasha Ratkovic, has to say about this new release!
And AOS is only going to get better. This is true because we listen to network engineers.
For instance, based on feedback from engineers we’ve made significant improvements in AOS v1.2 to the user interface for those wishing to use our out-of-the-box L3 CLOS solution. In fact, all of the features discussed in this article were the result of Apstra working with and talking to actual network engineers. AOS wouldn’t be what it is today without their feedback.
We want to hear from you, so find out today how you can leverage AOS to better operate your networks and help us make a true Self-Operating Network ™ a reality!
Oh and come see me, @cloudtoad, at Cisco Live in booth 2925 to talk tech and learn how you can change your own quality of life for the better using intelligent network automation software. AOS was built by network engineers to help solve network engineer problems!