Network Automation     Archive

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.

Read more

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

Read more

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.

Read more



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.

Read more

OT - A quick post on using gpg to manage github in Linux

After being used to OSX Keychains in my old mac, I wanted a similar functionality on my Linux laptop. Being prompted each time to login, while interacting with github for instance was annoying. Searching the web, led me to git-credential-store. I was not too happy with the fact that credentials would be stored in clear text, locally, indefinitely. I came across this stackoverflow post that I adapted for Linux. The concept is as follows:

  1. Use a .netrc file to store your credentials. This follows the file format for netrc
  2. Encrypt this file, using GNU Privacy Guard
Read more