Using Ansible network-engine to simplify network automation tasks

Last week at Networking field day (NFD18), Peter Sprygada (@privateip) gave a fantastic presentation about the problems in network automation and new initiatives from Ansible to help network and automation engineers.

In short - network automation teams are recreating similar Ansible playbooks since most of us have similar problems to solve. For instance, adding an application to the datacenter will require creation of VLANS, extending them over port channels, creating STP priorities etc. The Ansible network-engine strives to provide pre-canned, opinionated (meaning best-practices) roles that will make automation easier to kick start and reuse across most teams.

Part2 of a 2 part blog on using the Ansible network-engine's command parser

In Part 1 of this 2 part series, I illustrated how to invoke the command_parser module using the network-engine role from Ansible. I then used it to illustrate how to build a simple parser, leveraging regex to convert unstructured device command output to structured data.

In this post, I’ll build on it, highlighting the command parser options that makes wrangling any complex device output into structured output. In particular this post will deep-dive into the following directives:

• pattern_group
• extend

The playbook and complete parser is available in this git repo.

Part1 of a 2 part blog on using the Ansible network-engine's command parser

A very brief introduction

The network-engine role was made available through Ansible galaxy recently. One of the modules this role makes available for network engineers, is the command parser. As the name implies, command parser enables the user to parse the output of show commands - commands that network engineers know and love, that are “pretty” formatted but not structured.

Until recently, I had only used TextFSM to do this. While TextFSM works, it has a significant learning curve, IMO. Last week I decided to give the command_parser module a spin and right off the bat my impressions were:

1. If you are already comfortable using Ansible, you will feel at home working with the command parser

2. The learning curve is much shorter without needing to worry about learning another domain specific language

Note: This is in no way pitting one against the other. network-engine provides a textfsm_parser as well as the command_parser

Please reverse mentor your managers

“Everybody automate everything, now!” - Enterprise CTO (who just got back from a industry networking event)

“I wish my management would help bring in some of this cool network automation stuff I am learning from my peers online” - Network engineer

I’ve heard these comments from numerous organizations; often from CTOs and engineers within the same organization. So if the topmost level of the management is laying down goals to automate “everything” and the engineers themselves are excited to make it happen, why is there a gap?

So are middle managers the problem? Across organizations, middle mangers could be senior network engineers who have advanced to a point where there is no technical growth path. They have become comfortable managing a team of network engineers and know how to hire network talent. The automation space is filled with technical jargon and buzzwords that are new (and therefore scary). Coming from a technical background fear of the unknown can be unnerving.

NETCONF Ain't YANG

Obvious!

Recently I was working on YANG device models, using NETCONF to interact with the actual device (NXOS 7.0.3.I6.1). I was using Cisco’s NX-OS Programmability Guide for the 7.x version. I have had previous experience working with YANG and Cisco’s NEDs through the tail-f/NSO product and was feeling quite confident in my understanding of how YANG is being used for modeling (Either a service or a device) and how NETCONF was one of the protocols used to interact with the model. However, I was getting lost trying to navigate the NXOS’s YANG model over the NETCONF client.