Updated: Getting Network Device Operational Data with Ansible

Recording the same content for the third time because software developers decided to write code before figuring out what needs to be done is disgusting… so it took me a long long while before I collected enough willpower to rewrite and retest all the examples and re-record the Getting Operational Data section of Ansible for Networking Engineers webinar.

The new videos explain how to consume data generated by show commands in JSON or XML format, and how to parse the traditional text-based show printouts. I dropped mentions of (semi)failed experiments like Ansible parse_cli and focused on things that work well: TextFSM, in particular with ntc-templates library, pyATS/Genie, and TTP. On the positive side, I liked the slick new cli_parse module… let’s hope it will stay that way for at least a few years.

On a totally unrelated topic, I realized (again) that fail fast, fail often sounds great in a VC pitch deck, and sucks when you have to deal with its results.


  1. Have you looked at Suzieq since you had us on your show? https://github.com/netenglabs/suzieq. I think it's a better platform for gathering that kind of data than Ansible. I looked quickly at your examples and I think Suzieq already collects that data. It then stores it in a vendor neutral format, and allows you to easily ask questions, rather than having to write your own code. I think it's great for integrating into automation as pre/post check, but we need to do a better job of documenting how that would work and the advantages.

    cheers, Justin

  2. Hi Justin! You know I love Suzieq, and if anyone ever asks me about a generic data gathering framework, Ansible would be pretty far down the list.

    However, sometimes you need information from the device to validate your data model, or you want to do post-deployment validation using the same tool, or you want to grab some data and create a report without investing into yet-another platform, or...

    In those cases, the hammer lying nearby is just what you need, even when you're dealing with squeaky disc brakes ;)

  3. It feels like you are trying to be practical : ) I appreciate your point of view and agree its good to let people know how to do these things. In general, I think this kind of data gathering is more general and people shouldn't think of it as one-off, they should figure out how to get this kind of data all the time.
  4. Hi there,
    This updated part is just another gem from Ivan. Thanks ever so much - much appreciated especially as pretty painful I guess.

    There is one thing I wanted to highlight from my part:
    Ivan showed that Nexus OS can render XML printouts into JSON but that, at least for some Nexus OS versions, single-row tables are rendered as JSON dictionaries while multi-row tables are rendered as JSON Lists.
    Well, I found the same issue (albeit not on the router but back on the Ansible host) on Junos (with the juniper_junos_command module and Ansible 2.5.0) on some 'deeper' junos commands such as 'show route forwarding-table destination DST table default extensive' or 'show route PFX table inet.0 active-path'. In that case in fact the "nh" info is either a JSON Dict or a List depending on whether the 'nh' is just one or more than one respectively. I guess the culprit must be the Ansible's juniper's module automatic translation of the returned XML printout into JSON performed with the help of the jmslease library ?


Add comment