Network Automation and Monitoring with Apstra AOS
Recently, I was lucky enough to attend Networking Field Day 19 where I saw many different presentations. One of the presentations I witnessed made me think about some of the operational aspects of managing a large-scale network, and I found the ideas presented by Apstra to be very interesting.
Apstra’s AOS is built around the concept of Intent-Based Networking (IBN). While this has become somewhat of a marketing term in the industry, the concept itself is founded in the idea that you express the desired networking outcome, and not how it shall be done. As a high-level example, you could express to the system that two different network segments should be allowed to communicate with each other, and AOS will work in the background to configure the relevant network equipment to make that happen.
As a computer networking professional, I can see this providing tremendous value, especially across multi-vendor networks. With the proliferation of whitebox networking and even more vendors coming to market with their own network OS, each with very similar syntax (but not exactly the same), having something like AOS to automatically configure the devices based on what you want done can be a major operational time-saver. You no longer have to maintain explicit knowledge of multiple vendor interfaces and their individual peculiarities. The tradeoff, of course, is that AOS must support your desired NOS.
Apstra defines four levels in their IBN model:
Level 0 is basic automation, which includes automation through libraries such as NAPALM to support heterogeneous infrastructures. This is the level most people think of when they hear the phrase “network automation”.
Level 1 is where the IBN model becomes the single source of truth, meaning the platform contains both the operational intent as well as the current operational state of the overall network. In my opinion, this is one step beyond general orchestration, where both configuration and monitoring meet.
Level 2 consists of real-time change validation. This is when the impact of business rules and policy changes can be assessed, along with real-time status changes and network failures. For example, if you express a particular intent, what will actually be affected by the result?
Level 3 is the full Intent-Based Networking level, where the path to a self- operating network is realized through validation and closing the loop between intent and the actual operational state of the network. In other words, is the actual outcome of the expressed intent actually realized in the network?
If a mismatch between intent and outcome is discovered through observability, the IBN platform should then be able to automatically take corrective actions to align the actual network operation with the desired intent. A use case for this could be designating that certain devices always maintain a specific configuration. If someone were to log into one of those devices and make an individual change, the IBN system could detect this and optionally remediate it automatically by ensuring the change falls in line with the defined configuration.
During the presentation, we were shown the automated datacenter use case. This is currently Apstra’s primary focus. Immediately I could see the benefits of using this platform in other kinds of networks, such as within a service provider. I asked about this during the presentation (click to view the video):
Carly’s response to me indicated their platform most certainly could be used for something like this. However, as with nearly all things in networking, a commercial product must necessarily follow customer demand. Service providers could use a platform like Apstra AOS as a commercial solution to automate various aspects of their services (I gave the use case of setting up customer L2VPNs, which typically require a fair amount of manual configuration). However, if service providers do not jump onboard with this idea, the platform will most likely never be developed to take advantage of this kind of use case.
Beyond specific use cases, the other thing that caught my attention about AOS is that when you reach the stage of the platform becoming the single source of truth in your network, it has the potential to replace other third-party network monitoring tools. Frequently, larger networks may even have multiple tools performing overlapping duties! AOS was demonstrated as having the capabilities to determine various trends in the network, including detecting “soft” failures that may lead to eventual hard failures. The example we were given was the detection of trending errors on an SFP module over time. With this type of detection, you have the chance to prevent a full outage by getting early warnings of the impending failure based on trending data.
I have described two aspects of the AOS product that I found particularly interesting. As AOS matures, the capabilities and use cases continue to grow. What I explained here is really only the tip of the iceberg. I highly recommend you view the other presentations from Apstra if you wish to go even deeper into the product. Depending on your use cases, it seems like it really could be an immense time-saver along with reducing the operational complexity of maintaining large-scale networks.