How Do You Get Information from Network Devices?

One of the biggest challenges of network automation is getting usable information from network devices… or as asked by a student in my Building Network Automation Solutions online course in the course Slack team:

How do I get specific information from a specific command from a device without an Ansible Network Module? Is Python the only suggested approach?

I described how hard it is to get structured information from network devices in great details in this section of the Ansible for Networking Engineers webinar and online course. Here are a few more thoughts on the topic:

In the ideal world, you could get information from any network device using NETCONF (or RESTCONF) and it would be structured according to OpenConfig or IETF YANG data models. We’re far far away from that nirvana.

The various Ansible network modules are just a thin layer of abstraction to hide the most horrendous device behavior like the need to enter terminal length 0 to disable paging. Unless the device itself returns structured data (check out which ones do), you still get the data in text format that needs to be parsed.

Some Ansible modules also deal with the sloppy SSH implementation – there are devices out there that don’t support SSH command mode at all.

If you want to get ready-to-use data structures back from network devices you could either parse the data yourself, or use NAPALM or ntc-ansible. I described various parsing tools you can use with Ansible in this video; David Barroso did a deep dive into using NAPALM with Ansible a while ago.

Finally, as I keep telling everyone who’s willing to listen, there’s no single ideal tool. There are many tools out there and each one is a better fit for some jobs and worse fit for others.

Some of the tools (any generic programing language) are really flexible but require a lot of undifferentiated heavy lifting. Other tools are great at doing simple things (Ansible comes to mind) but get annoyingly awkward pretty soon unless you extend them with your own Python module. We spent hours in the introductory part of the network automation course discussing these challenges, including “how do you select the best tool for a job” and “how do you master new tools”

As for programming languages, there’s no best one. Some are better suited to some problems (you get the idea). Most networking engineers believe Python is the way to go, an old-timer like myself would prefer Perl (aka Swiss Army Chainsaw of scripting languages) any time of the day.

This blog post was initially sent to the subscribers of my SDN and Network Automation mailing list. Subscribe here.

5 comments:

  1. If you don't want to use Ansible and / or Python expect might be a solution. Maybe expect wrapped into a tool like RANCID (which itself is written in a mixture of Shell, AWK, Perl and expect).

    Example: /usr/libexec/rancid/clogin -c "sh ver" router.example.com

    (clogin is part of rancid and takes care of logging into Cisco devices, there are several other variants like jlogin for Juniper, ...)

    The output can be parsed using the *NIX shell. Or Perl, Python, Ruby, ...

    My advice: If you don't have rancid running and you are not familiar with the *NIX shell learn Ansible and Python.

    https://www.nist.gov/services-resources/software/expect
    http://www.shrubbery.net/rancid/

    P.S. I know that people will be throwing stones at me for this comment
  2. "I know that people will be throwing stones at me for this comment" << FWIW, I totally agree with you... and if such stones would be real, I could build a nice palace out of everything I received in the past, mostly from anonymous donors.
  3. As far as I know Ansible doesn’t support logging in via telnet.
    So if I need some automation for a bunch of outdated cisco ISRs I still use Rancid without a hesitation
  4. There is always SNMP

    **Covers himselfs and waits for donations.
  5. If your vendor can't get their CLI to provide useful info then I wouldn't put much faith in their API for data. In that case consider wrapping some snmpwalks inside a .sh -- and then wrap that inside a .py for good measure -- the outer .py will be a shield to help you weather the #netdevops hype storm which will last a few more years.
    At least then your python box is checked :)
Add comment
Sidebar