In this series of posts I will cover how you can create your own API-like functionality for devices which do not have APIs built into them. Before I get started though, for those of you who don’t know what an API is, here’s Wikipedia’s description:
“Just as a graphical user interface makes it easier for people to use programs, application programming interfaces make it easier for developers to use certain technologies in building applications. By abstracting the underlying implementation and only exposing objects or actions the developer needs, an API reduces the cognitive load on a programmer.”
For example, if you wanted a list of IP addresses on a large number of Cisco switches, you could issue the show ip int brief command on each of them and then manually extract their IPs addresses. On the other hand, if the switches had an API you could use it to extract the IPs for you. This technique not only saves you time, but it also lends itself to automation and orchestration tasks perfectly.
The good news is that APIs are becoming increasingly popular in the networking space and you’ll find a large number of vendors are releasing them for their product lines. The bad news is that (understandably) they’re not releasing APIs for their older products. However, as with just about everything else in IT, there’s always a solution to the problem.
The solutions I have come up with are listed below. They might look familiar as I mentioned them in my Getting started with Ansible post too:
While the first two are valid options, my preference is NTC-Ansible. The reason being that, as its name suggests, it plugs into Ansible and therefore you’ve got your automation and orchestration piece already sorted. On the other hand, if you were to write scripts utilising the Paramiko and/or Netmiko libraries, you would then need to integrating them into Ansible.
(Note: NTC-Ansible actually uses Netmiko for its SSH connectivity.)
To provide API-like functionality, NTC-Ansible uses Google’s TextFSM. As per the github page:
It is a “Python module for parsing semi-structured text into python tables.”
“… implements a template based state machine for parsing semi-formatted text. Originally developed to allow programmatic access to information returned from the command line interface (CLI) of networking devices.”
“A template file is needed for each uniquely structured text input.”
“By developing a pool of template files, scripts can call TextFSM to parse useful information from a variety of sources.”
In a nutshell, you create template files which analyse your CLI output and return the information you specified, formatted in JSON - the same way that APIs do.
For a great example, check out Jason Edelman’s Getting Structured Data from Cisco IOS Devices using Ansible post. (Jason is the author of NTC-Ansible so it’s no surprise he delivered a great demo of it. I have also provided a demonstration in Part 4 of this blog series.)
The last line of Jason’s post really sums everything up nicely:
Since the return data from the network devices is now structured, we can use this data as inputs to other tasks in Ansible or in templates to create dynamic and real-time reports.
In my next post I cover TextFSM in further detail as well as run through one of the built in examples.
As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at will@oznetnerd.com, or drop me a message on Reddit (OzNetNerd).
Note: The opinions expressed in this blog are my own and not those of my employer.
Leave a comment