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.