Videos on TTP (Part1)

By Kirk Byers

This series of video discusses the Template Text Parser (TTP) library and how it can be used to parse the semi-structured data that we receive back from network devices.

In the videos, I explain the hidden regular expression patterns assumed in TTP and how you can modify them to work around some basic parsing problems.

Videos on TTP (Part2)

By Kirk Byers

This is Part2 in a series of videos that discusses the Template Text Parser (TTP) library.

In these videos, I parse network device configurations using TTP. This includes discussing named groups, the start of group processing, and how order affects group results.

Videos on TTP (Part3)

By Kirk Byers

This is Part3 in a series of videos covering the Template Text Parser (TTP) library.

These videos cover configuration parsing using TTP including using the "_start_" modifier, parsing a full configuration, and completing a full-cycle (i.e. using TTP for vars extraction and then Jinja2 for configuration regeneration).

Videos on Python Classes

By Kirk Byers

This series of video provides an introduction to Python classes and objects with a network engineering bent.

It discusses why you might want to use classes, basic class structure, the use of 'self', and creating class methods.

Videos on Class Inheritance

By Kirk Byers

This series of video discusses Python class inheritance including creating a class hierarchy, method resolution order, and using super() to invoke methods in a parent class.

It uses an example of a parent network SSH class and child classes for both Cisco IOS-XE and Juniper Junos.

StackStorm + Nagios event-driven Automation (Part1)

By Carl Montanari

In an earlier post, we created and executed our first action in Stackstorm. The action didn't do much, however. It was just a simple script that printed a message.

In this article, we'll ramp things up a bit and execute an action based upon on a "trigger". A "trigger" is a Stackstorm term that pretty much does what you expect! A trigger will get...triggered and then execute an action.

StackStorm + Nagios event-driven Automation (Part2)

By Carl Montanari

Previously, we configured Nagios to send a webhook to StackStorm. This will notify StackStorm of any downed hosts and will include the hostname in the Nagios message. In response to this event, StackStorm is currently setup to run our simple "hello world" action.

Our task now is to build not just a simple action—but a "workflow", that orchestrates the checking, remediation, and verification (to confirm that the device is now back online) of any failed hosts. Let's jump right into it...

StackStorm: Hello World

By Carl Montanari

Writing scripts or playbooks is only one piece of the greater puzzle that is automation. When do these scripts get executed, what arguments get passed, how can they be made consumable by non-developer team members, and best of all--how can they automatically be executed in response to some event?

Recently we have began to address some of these challenges internally--specifically, how can we abstract away, or simplify, some of our script argument passing, and how can we automate execution of scripts in response to events.

Nornir using an Ansible Inventory (Part1)

By Carl Montanari

Several months ago I presented at the Packet Pushers Virtual Design Clinic (VDC) 3, my session was titled, "CI/CD for Networking".

In this presentation, I demonstrated leveraging Jenkins and Ansible to provide a repeatable and automatable method for managing network device configurations.

I selected Ansible, more specifically NAPALM-Ansible, as the network automation tool of choice for a few reasons:

Nornir using an Ansible Inventory (Part2)

By Carl Montanari

In Part 1 of this series we covered: installing Nornir, using Ansible inventory in Nornir, Nornir tasks and results, and using Jinja2 for configuration rendering.

In this post, we'll start with our rendered Jinja2 configurations and write these configurations to disk. We'll also use Nornir plus NAPALM to retrieve and save the current device configurations. Finally, we will stage a set of configuration changes, obtain a live diff between the current and proposed configurations, and then commit these changes to the devices.