Category: automation

I was discussing a totally unrelated topic with Terry Slattery when he mentioned a quote from the Mythical Man-Month. It got me curious, I started exploring and found out I can get the book as part of my Safari subscription.

Ansible is great at capturing and using JSON-formatted data returned by REST API (or any other script or method it can invoke), but unfortunately some of us still have to deal with network devices that cannot even spell structured data or REST.

One of my subscribers sent me this question after watching the second part of Network Automation Tools webinar (or maybe it was Elisa Jasinska's presentation in the Data Center course):

Elisa mentions that for a given piece of data, there should be “one source of truth”. It gets a bit muddled when you have an IPAM tool and Git source control simultaneously. It is not hard to imagine scenarios where these get out of sync especially if you consider multi-operator scenarios.

Confused? He provided a simple scenario:

As I was trying to automate configuration deployment in a multi-router Cisco IOS lab, I got to a point where the only way of figuring out what was going on was to log commands on Cisco IOS devices. Not a big deal, but I hate logging into a dozen boxes and configuring the same few lines on all of them (or removing them afterwards).

Time for another playbook: this one can push one of many (configurable) configuration snippets to a group of Cisco IOS devices defined in an Ansible inventory file.

Interesting? Want to do something more complex? Join the Network Automation online course.

Over a month ago I decided to create a lab network to figure out how to solve an interesting Inter-AS MPLS/VPN routing challenge. Instead of configuring half a dozen routers I decided to develop a fully-automated deployment because it will make my life easier.

I finally got to a point where OSPF, LDP, BGP (IPv4 and VPNv4) and MPLS/VPN configurations are created, deployed and verified automatically.

While it’s relatively easy to create an Ansible inventory file to support a Vagrant-created virtual networking lab, it’s also utterly boring – a perfect job for an automation script. I’m positive there are a zillion solutions out there, but I decided to reinvent the wheel and get a bit of Python hands-on practice.

One of my readers sent me a simple question: “Do you plan to have a Python for Networking Engineers webinar?”

Short answer: no immediate plans.

Here are just a few reasons:

Most network automation tutorials out there assume you’re running Ansible on your workstation and accessing virtual machines via SSH ports mapped by Vagrant. That’s great if you’re an experienced Ansible/Python user; for a clunky beginner like myself it’s safer to run Ansible within a VM that can be destroyed and recreated in seconds.

The featured webinar in December 2016 is the Network Automation Tools webinar, and in the featured videos you'll find in-depth description of automation frameworks (focusing on Ansible) and open-source IPAM tools (including NSoT recently released by Dropbox).

To view the videos, log into my.ipspace.net, select the webinar from the first page, and watch the videos marked with star.

I got several questions along the lines of “Do I need programming skills to attend the Building Network Automation Solutions course?”

Short answer: No.

A few days after I published the blog post describing why it might make sense to attend the Building Network Automation Solutions course even when you’re already using a $vendor network management system/platform, I got a surprising email from one of my friends working for a major networking vendor:

Every time I write about network automation in enterprise environments I get the usual set of excuses including:

Some of the environments I am looking at have around 2000-3000 devices and 6-7 vendors for various functions and 15-20 different device platform from those vendors. I am trying to understand what all environments can Ansible scale up to and what would be an ideal environment enterprises should be looking at more enterprise grade automation/orchestration platforms while keeping in mind that platform allows extensibility.

Luckily I didn’t have to write a response – one of the readers did an excellent job:

A few weeks ago Matt Oswalt wrote an interesting blog post on principles of automation, and we quickly agreed it’s a nice starting point for a podcast episode.

In the meantime Matt moved to StackStorm team so that became the second focus of our chat… and then we figured out it would be great to bring in Matt Stone (the hero of Episode 13).

Cisco VIRL is the ideal testing environment when you want to test your Ansible playbooks with various Cisco network operating systems (IOS, IOS XE, NX-OS or IOS XR). The “only” gotcha: how do you reach those devices from the outside world?

It was always possible to reach the management interface of devices running with VIRL, and it got even simpler with VIRL release 1.2.

Like with the Next-Generation Data Center course, the live sessions in the Building Network Automation Solutions course include guest speakers, Q&A discussions, and solutions to sample challenges that you’ll be able to use to complete your homework assignments.

The guest speakers for the January 2016 course include: