My father is a real craftsman. He always used to tell me whilst I was growing up (and still does to this day :-), “you cannot do all the jobs with the same tool. You would not use a hammer to cut wood, right?” He’s right of course, and the same folk wisdom is true for network automation. As of yet there is nothing out of the box that will meet all your needs from day one – that magic button is not quite there yet, we are getting close though! (Take a look at SD-WAN on DevNet.)
I have spent time evaluating and testing which network automation tools do the best jobs for our network, our needs, and our business requirements. This does not mean that down the line we shall not change our minds. Like anything, things evolve. What suited us a few years back might not suit us today, so change is required. But let’s take a look at some of the network automation tools being used today to configure our networks, and keep them safe.
Example One
Python has always been my main language, I like using Golang too, but Python is my first choice. I used Python for all types of network automation, with different transports. For example open source Python libraries such as Napalm or Nornir for network configuration and validation purposes which run over ssh (in most cases) are great tools when you are in a multi vendor environment and/or your devices have an API (you know those dusty old switches in the no man lands part of the network!). I tend here to lean more to RESTCONF.
The RESTCONF protocol stack is simpler in many ways. Here are a few:
- Content – Unlike NETCONF where we must use XML (eXtensible Markup Language). RESTCONF allows for either JSON (JavaScript Object Notation) or XML to be used (if you are new to JSON/XML see the note below).
- Operations – Each of the operations are aligned to the various HTTP methods, providing the required suite of CRUD based operations (Create, Replace, Update and Delete).
- Transport – The transport protocol is HTTP, allowing us to use HTTPS. Providing the security benefits that TLS (Transport Layer Security) has to offer.
JSON versus XML
The more lightweight JSON has become a popular alternative to XML for various reasons. A couple obvious ones are:
- Less verbose – XML uses more words than necessary.
- JSON is faster – Parsing XML software is slow and cumbersome. Many of these DOM manipulation libraries can lead to your applications using large amounts of memory due to the verbosity and cost of parsing large XML files.
So even here, I am using different transports/python libraries and the reason for picking one over the other depends on the project and the devices I am working on.
Example Two
Using Python for network automation is great. It gives you many options. However, a task that came up recently for me was to audit and rebuild a lot of ACLs (access lists) on the Cisco ASA platform. This was a global task with many Cisco ASAs and these were all multi-context. Writing this in Python was possible, but I found it easier and quicker to use Ansible. The challenge here was many devices, many ACLs, and wishing to ensure all Cisco ASAs had the correct ACLs for the site/location, and that these were standard over all sites/locations. It is easy to slip in an ACL for a break/fix solution and soon this ‘snowflake’ is forgotten and this can then grow out of control and the standard configuration/templates are lost. After this project Ansible was my main tool for managing our global Cisco ASA estate.
Besides the Cisco ASA, we then used Ansible to manage our local data center devboxes. These Linux based virtual machines, managed local configurations, monitoring, telemetry, and local device logging. As it turned out, we were able to leverage what we had learnt with the ASA project to then manage our devboxes … yet another problem is solved!
Conclusion
In conclusion, when someone asks me “which network automation tool should I use? Or, “what should I learn – Python or Ansible?” I say you should learn as much as you can. Learning is fun and in doing so you can make your tasks and workflows quicker, more reliable, and help break down the silos we have in our organization today. You might need to use and run Python scripts and Ansible playbooks for your network automation such as I did, and this is fine. Lots of companies do this. Leverage the tools, the python libraries, the transports as much as you can. All of this will help streamline your work.
Here I have just mentioned a few of the tools and methods I use in my day-to-day. Can you think of more? Drop me a comment on this blog, or join my upcoming Webinar April 16; I’d love to hear from you.
Free Webinar
“Solving Operational Challenges with Network Automation”
There is more to network automation than pushing out configuration snippets. Network automation skills can help solve day to day operational challenges too.
Join DevNet Today!
Get your free DevNet account for free access to resources, learning labs, and sandboxes for network automation and application development.
Stuart Clark on Twitter Follow @bigevilbeard
We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!
Twitter @CiscoDevNet | Facebook | LinkedIn
Visit the new Developer Video Channel
Can you please help me understand SDNs and how AI/ML has helped the growth of such techniques. Also, the core backbone modules helping achieve that.
Hey Romit, AI/ML iI see today being used for RCA (Root Cause Analysis) and relationship/connection between different network alarms. Working with large amounts of both structured and unstructured data to find patterns and predict future failures/outages, identify problems and trends. As i read this week one of the challenge with machine learning in networks is most of the network challenges we face today are network outages from human error, this can't be learned by the machine.