If you take a look through my site you will quickly notice that most of my posts consist of how to articles for Python, Cisco networking devices, or Linux administration. It is no secret that I use those technologies every day in my job as a Network Administrator. With that said I am going to begin making several posts talking about automating Cisco infrastructure using Python, In these Posts I am going to cover my overall methodology, libraries I use, tips and tricks, and other things I have learned along the way.
Why Discuss Network Automation
One of the biggest drivers for me in discussing this is there is really no one that is having long form discussions on automation for the network and often times this leads to network engineers not having a clear direction on where to start and how to succeed. I believe my hands on experience doing network automation, describing infrastructure in code, and solving the problems posed with building automation scripts and programs from the ground up will help other network administrators reduce their workload and succeed in automating their network.
But I’m a Network Administrator not a Programmer
That is often what I hear when discussing automation with other network admins, they are not programmers, and they don’t want to be. The beauty of it is you don’t have to be any more than a Windows admin needs to be a ‘powershell programmer’, you will not be spending 100% of your day writing python code, but the better you get at it, the more problems you will look at and turn to automation to solve parts of them.
Why do I Need to Know This
With the release of IOS-XE and Cisco DNA, Cisco which is one of the leading networking vendors in the world, is pushing more and more toward opening their platforms to API’s (Application Programming Interfaces). This is a clear signal that the products they are building for the future will be built with the intention of an external script or program interfacing with them from the ground up. In addition to that much of Cisco’s online resources talk about the API being the new CLI which will not happen overnight, but as time progresses less emphasis will be placed on the CLI and more on the API. As a network administrator this is where the industry is going and to prepare yourself for the future understanding how to interface with an API will become more and more crucial.
Wouldn’t it be Easier to Buy a Product
Many times buying a product that already does it is the easier and smarter route to take, however with automation it is entirely different. With the hyper uniqueness that each network inherently has there are so many things that are next to impossible to automate with a turn key appliance that is dropped onto a customers network. That is not to mean that there are some things a purchased product can not solve, for instance Cisco DNA is a perfect example of that, it can handle config compliance, device on boarding, and other tasks that were previously only possible by logging into 3 or 4 plus routers and issuing commands on each.
Where turn key products like Cisco DNA fail is with business specific integration, lets say you want to check various devices on your network for events like incrementing errors on interfaces and based on the speed and frequency of these errors preform diagnostics such as a TDR test, power cycling the port, etc. Then after these tests have been performed if the issue has not resolved create a ticket within the ticketing system noting all of the tests that were done and finally emailing the network administrator on call. This scenario is extremely specific and would be very difficult to implement in any system that is purchased off the shelf and Cisco knows this which is why they have opened many of their new products with an API. Other companies know this to and have done the same, what this allows is for you as a network administrator to build a script to do all of this and integrate 3 or more systems to auto diagnose specific parts of your network with zero administrative Intervention. So instead of thinking of network automation with Python as building these large monolithic applications that reinvent the wheel from the ground up, while it can be if that makes sense for your business, think of it as building simple scripts, small applications, etc that tie in the various applications you have at your disposable for better business integration, workflow automation, and extend their functionality in ways that may only make sense for your specific business.
While I have only began to scratch the surface of the things to talk about in regards to network automation I believe this is a good spot to leave the introduction at.