As a network operator, I want to describe in plain language what I need a network to do, and the network is configured accordingly. Then I want the network to monitor itself, and when things aren’t going well, the network will repair itself with no involvement from me. Hey, daydreaming is fun.
In the real world, plain language describing my network requirements isn’t going to conjure a relevant network. I must perform hard work to create a network design that’s useful for a business. I have to think through issues like capacity needs under peak load, redundancy to survive a network failure, and resiliency to support business operations in the face of a catastrophic outage. I need to understand individual application requirements, and be sure the network can support those requirements. I have to consider modularity, repeatability, and supportability. I must work within a budget.
My design will translate into an arcane collection of devices, interfaces, interconnections, protocols, and topologies. I’ll rely on education, experience, and experimentation to fine-tune the design, and then I’ll put it into production. Depending on your personality, this arduous task likely falls somewhere between “fun” and “frightening” for you. But no matter who you are, there is an element of tedium that goes into complex network design & engineering.
That’s right. Tedium. Much detail goes into configuring a network to do much of anything. For me, getting details wrong is easy. An incorrect subnet mask. Forgetting to adjust MTU on an interface. Referencing a prefix list I haven’t actually created. Applying a QoS policy in the wrong direction. Setting a router ID but neglecting to restart the routing process.
If I bang away at the configs long enough, everything falls into place. By the time the design goes into production, it’s more or less right. Sure, maybe I need to do some cleanup, but the system is working as designed.
If I may be so bold, the process of network design and implementation I’m describing is The Old Way™. As far as I’m concerned, the old way sucks. I want to automate as much of the old way as I can. While acknowledging that I will need to be in the loop to some degree (hey, a design has to happen, right?), I want to be out of the configuration loop as much as possible.
Configuration Is Just Details
A key idea I was taught many years ago was that configuration is just details. I didn’t grasp the importance of this at the time, because everything I’d been taught in a classroom was all about configuration. Configuration just details? All the vendor certification exams I’d passed suggested that configuration was the point. I chafed at the contradictory point the senior network designer was making.
What I was missing is that the strength of a network design is not in its configuration, but in its architecture. Put another way, the configuration that brings a design from the whiteboard and to a living, breathing architecture is merely a collection of details. Important details? Yes, but ask yourself this. Is the functioning of a network designed for a specific purpose any different because it came from Vendor C instead of Vendor A or Vendor J? Yes, the configuration will differ among the vendors, but the result will be the same.
I don’t want to have to care about configuration. I just want a network service to function as designed–and stay functioning.
Closed Loop Automation
In data networking, closed loop automation contains the following big ideas.
- A network service is deployed in an automated way.
- That network service is actively monitored.
- The monitoring ensures that the service is meeting a set of service level agreements (SLAs).
- Automation can update a network service if it is not meeting SLAs requirements, thus closing the loop.
In my view, closed loop automation moves me closer to my goal of not having to worry about configuration details.
Various vendors are offering closed loop automation tools today. Let’s take Anuta Networks’ Active Service Assurance (ASA). ASA is a relatively recent addition to Anuta’s ATOM platform. If you don’t know Anuta, they offer network automation aimed at service providers and large enterprises acting as service providers. Create a service, and ATOM will deploy it for you in a vendor agnostic way.
ASA adds network monitoring to know that a deployed service is or is not meeting the required service level agreement (SLA). If an SLA is not being met, ASA can modify the configuration to bring the service back into compliance.
Now, that all sounds lovely, if not downright magical. But the reality of what’s going on is more mundane and human-derived. For example, network services are defined by humans. The Anuta platform makes service definition a workflow-driven process and abstracts configuration details away, but a human is defining that workflow. The Anuta platform’s ASA will also monitor the service, but a human is describing the tests that need to be run. ASA will also attempt remediation, but the remediation actions that are possible are also defined by a human via an Anuta workflow.
This is not a criticism. This system is state of the art, and is among the best I’ve seen demonstrated in its flexibility and user interface. That flexibility also makes the platform non-trivial to make use of. I can’t just say, “Hey, Anuta. Make me an L3VPN,” and poof, magic happens. I have to define an L3VPN as a service. I have to establish the tests I care about that tell me an SLA is or is not being met. I must define what the options are such as rollback to restore a service to SLA compliance.
There is no network automation, closed loop or otherwise, I’ve seen that doesn’t require a significant upfront investment before that tool is useful. That’s certainly true for complex network configuration tasks with unique business requirements or specialized capabilities. I’m not suggesting there aren’t quick wins to be had with network automation tools. Many tools can help with things like NOS version management, config diffs, vulnerability assessments, and similar low hanging fruit shortly after network discovery is complete.
Closing The Loop Is What We’ve Been Missing All Along
Upfront investment notwithstanding, don’t think I’m dismissing closed loop automation as uninteresting. The idea is keenly interesting. Closed loop automation puts me, the network operator, one step further away from those pesky and easy to get wrong configuration details I don’t want to have to deal with. Importantly, closed loop automation also integrates monitoring into the network service.
Historically, networking has treated monitoring as a separate set of tools from configuration. In fact, I’ve always wanted a service to have self-monitoring as an integral part. I didn’t know that’s what I wanted. I’m used to building a service, then configuring a network management station, probably combined with application performance monitoring, to track service availability and performance. Combining the configuration & monitoring into one “closed loop automation” service means I’m going to be asking the right question.
The wrong question is, “Is the network service running?”
The right question is, “Is the network service running well?”
Frankly, having to design the tests that tell me with confidence that the service is running well is a big step in the right direction. Perhaps I can’t say, “Anuta, make me a network & make sure it’s running well.” But I can see the framework coming together where maybe, someday, I’ll be able to do just that.
For More Information
Anuta Networks presented at Networking Field Day 30, where I attended as a delegate. Find Anuta’s presentations in this YouTube playlist.