Network Automation – The journey is a destination
Network Automation – The journey is a destination
Don’t believe the hype around network automation, this isn’t about grandiose ten-year plans to build sentient, self-managing networks. It’s about solving those small, repetitive everyday tasks, and that makes it so much more important.
I’ve noticed a bit of a trend in meetings I’ve attended recently, the topic of conversation is the hottest thing in networking at the moment, namely automation. Often I’ve noticed that the conversation veers towards the notion that this means creating a fantastical, self-aware network that can operate and heal itself. Concerns about physical media and layer 2 encapsulation types and routing protocols are a thing of the past as sites are effortlessly provisioned and interconnected in a fully optimized manner.
Now all this does sound wonderful, but the reality is that while this is very appealing as a concept, this vision is somewhat off in the future, the networking version of a Tomorrow’s World.
In fact, this ‘whole network’ concept is more in tune with the idea of network orchestration, where elements of the network act in tandem, you know, like an orchestra. Whereas network automation focuses on the individual elements of a network, routers and switches. Allowing them to operate more efficiently, like a playing a single instrument more proficiently, maybe even akin to a 15 minutes drum solo from that guy in Rush.
Enough about Rush
These grand orchestration ideals also have the negative effect of raising the question of how? We’re still relying on 30-year-old routing protocol, IPv4 is still a thing. If you can’t see a possible route from the current state to a grand vision with today’s technology, it begs the question of how do we start to realise these aims? We can’t just jump on a 787 and fly to this magical destination, we need to travel towards it, but how?
That’s where network automation comes in. The one piece of advice I hear most often from those that have already started on their automation journey is ‘start small’. While other areas of IT are well on their way to automating end to end processes, networking lags behind with a large number of moves, adds & changes, being performed manually. All those simple small operations that are easy, yet time-consuming. Those are prime for automating.
Take, for example, configuring BGP. That is incredibly repetitive, building the peer statements, adding them to the correct address-families, adding the route-map policies. Or what about OSPF? I tend to always build OSPF links as point-to-point rather than broadcast. Under each L3 interface, I have to remember to add that point-to-point command.
Forget dreaming of building Skynet, there’s no shame in taking initial small steps with automation and stopping all this repetitive command input. At its most basic level, if I have to enter two CLI commands to perform one logical task, like my OSPF point-to-point example, but I invest the time to write a python script that I can call in one line, that’s progress, I’m automating. Now throw in some erroring checking, pause the script for 10 secs and check the links come up and the neighbour state. Now, from a very simple start, and some basic python, we are getting all programmatic and off on our journey.
‘Next Big Thing’ Fatigue?
Small, tangible advances like the above example also help to gain the interest of those out there sceptical of all the hype around automation. Those with ‘next big thing’ fatigue that have seen trends come and go, all the while spanning-tree is still live and clinging on.
For those, I offer for their consideration Zero Touch Provisioning. A pretty uncontroversial approach in networking nowadays. Adoption of such techniques varies amongst customers but I’ve worked on some networks with thousands of remote branches and ZTP is vital. If we can automate workflows on first boot we can build workflows for changes on the network, for decommissioning sites, even for our day-to-day operations of checking VLANs on uplinks and code revision levels across our estates. With this kind of approach, we can merrily set off on our network automation journey.
When the going gets tough…Aruba 8400!
But hang on, what if the going is tough? Progress arduous? What if the time required to write the automation scripts is too great? Engineers simple revert to type and bash out CLI commands from their keyboards. In the past PERL scripting and SNMP were not exactly a walk in the park, many preferred to stick to CLI.
However, with the rollout of APIs across ArubaOS-Switch range and the awesome Aruba 8400 with fully-exposed REST API, things got that much easier. With some basic understanding of python data types and how to process JSON, interacting with the network programmatically and unlocking the power of automation is a reality today.
Think Big but Start Small
Don’t be over-awed with tackling too great a task. Dive into those python tutorials, get familiar with REST APIs. That which was once strictly for software developers is now becoming common parlance amongst a small, but growing, group of network engineers. Focus on those little time-consuming tasks, write functions, share and build. Each process automated is a win.
With the outlook of a traditional network engineer, it is hard to grasp the possibilities that will unfold once you start on this journey. Adopting an ‘I could write a script for that’ approach, learning to interact with the network beyond the confines of the CLI opens up new challenges, for certain, but also new, unrealised opportunities.
First, you need to make a start on this journey, don’t just keep copy-and-pasting those CLI commands into the console. Take a different approach. The network automation trend is just beginning and there’s a long way to go until we’re playing the network like an orchestra. Making a commitment to the journey is the first destination.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.