Category: automation

I’m usually telling networking engineers seriously considering whether to automate their networks to cleanup their design and simplify the network services first.

The only reasonable way forward is to simplify your processes – get rid of all corner cases, all special deals that are probably costing you more than you earned on them, all one-off kludges to support badly-designed applications – and once you get that done, you might realize you don’t need a magic platform anymore, because you can run your simpler network using traditional tools.

While seasoned automation practitioners agree with me, a lot of enterprise engineers face a different reality. Straight from a source that wished to remain anonymous…

A friend of mine sent me the following question a few months ago:

I thought you might know the best way (currently) to create a digital clone of parts of a production network? The objective is to test changes against a test network as part of a CI/CD process. Ideally, there would be an automation that could replicate selected parts of a production network in a test network.

TL&DR: Sounds great, but you might be solving the wrong problem.

Lívio Zanol Puppim published a series of blog posts describing a full-stack network automation, including GitOps with GitLab, handling secrets with Hashicorp Vault, using Ansible and AWX to run automation scripts, continuous integration with Gitlab CI Runner, and topped it off with a REST API and React-based user interface.

You might not want to use the exact same components, but it’s probably worthwhile going through his solution and explore the source code. He’s also looking for any comments or feedback you might have on how to improve what he did.

Would you happen to have your network connectivity data in a tabular format (Excel or similar)? Would you like to make a graph out of that?

Look at the Excel-to-Graphviz solution created by and Salman Naqvi and Roman Urchin. It might not be exactly what you’re looking for, but you might get a few ideas and an inspiration to do something similar.

Nicholas Michel open-sourced an automation solution (video) that deploys the whole NSX-T infrastructure stack including:

• NSX-T manager virtual machines
• NSX-T uplink profiles and IP pools
• Transport zones and transport nodes (NSX-T modules on ESXi hypervisors)
• Edge clusters including BGP, EVPN and BFD

Once the infrastructure is set up, his solution uses a Terraform configuration file to deploy multiple tenants: external VLANs, tier-0 gateways, BGP neighbors, tier-1 gateways, and application segments.

While the infrastructure part of his solution might be fully reusable, the tenant deployments definitely aren’t, but they provide a great starting point if you decide to build a fully automated provisioning system.

One of ipSpace.net subscribers sent me the following feedback on Ansible for Networking Engineers webinar:

The “Ansible for Network Engineers” webinar is of the highest caliber. I’ve taken Ansible courses with your CCIE peers, and though they are good, I objectively feel, that I get more of a total comprehensive understanding with network automation here at ipSpace. Also, I enjoy your professional care-free tone, and how you pepper humor into the subject matter.

I’ve setup a virtual lab with Ubuntu 18.04 LTS server, and am using both Aruba and Cisco switches/routers. Ansible has lots of nuances that will take me time to fully get a grip-on– but, that’s why I subscribe with the network pros like ipSpace.

If you’re brand-new to Python and Ansible, you might be a bit reluctant to install a bunch of packages and Ansible collections on your production laptop to start building your automation skills. The usual recommendation I make to get past that hurdle is to create a Ubuntu virtual machine that can be destroyed every time to mess it up.

Creating a virtual machine is trivial on Linux and MacOS with Intel CPU (install VirtualBox and Vagrant). The same toolset no longer works on newer Macs with M1 CPU (VMware Fusion is in tech preview, so we’re getting there), but there’s an amazingly simple alternative: Multipass by Canonical.

Remington Loose sent me an interesting email describing his views on the right approach to network automation after reading my Network Reliability Engineering Should Be More than Software or Automation rant – he’s advocating standardizing network services and cleaning up your network before trying to deploy full-scale automation.

I think you are 100% right to start with a thorough cleanup before automation. Garbage in, garbage out. It is also the case that all that inconsistency and differentiation makes for complexity in automation (as well as general operations) that makes it harder to gain traction.

Here’s a fun fact network automation pundits don’t want to hear: if you’re working with replaceable device configurations (as we did for the past 20 years, at least those fortunate enough to buy Junos), you already meet the Infrastructure-as-Code requirements. Storing device configurations in a version control system and using reviews and merge requests to change them (aka GitOps) is just a cherry on the cake.

When I made a claim along these same lines a few weeks ago during the Network Automation Concepts webinar, Vladimir Troitskiy sent me an interesting question:

Setting up a network automation development environment is an interesting task:

• You have to install a half-dozen tools, each one with tons of dependencies;
• SSH libraries like paramiko have to installed manually;
• Ansible modules for individual network devices might need extra libraries;
• Parsing tools invoked with Ansible Jinja2 filters have to be installed separately;
• Add your pet peeve here ;)

Now imagine having to do that for a dozen networking engineers and software developers working on all sorts of semi-managed laptops. Containers seem to be one of the sane solutions¹.

Network automation CI/CD pipeline seems to be the next hot thing, with vendors and bloggers describing in detail how you could get it done. How realistic is that idea for an average environment that’s barely starting its automation journey?

TL&DR: it will take a long time to get there, and lack of tests is the first showstopper.

In Git as a source of truth for network automation, Vincent Bernat explained why they decided to use Git-managed YAML files as the source of truth in their network automation project instead of relying on a database-backed GUI/API product like NetBox.

Their decision process was pretty close to what I explained in Data Stores and Source of Truth parts of Network Automation Concepts webinar: you need change logging, auditing, reviews, and all-or-nothing transactions, and most IPAM/CMDB products have none of those.

On a more positive side, NetBox (and its fork, Nautobot) has change logging (HT: Leo Kirchner) and things are getting much better with Nautobot Version Control plugin. Stay tuned ;)

Vincent Bernat and his team open-sourced Jerikan, a production-grade network configuration management system.

It might not be immediately applicable to your network, but I’m positive you could find tons of good ideas in it.

Parsing and modifying IOS-like hierarchical device configurations is an interesting challenge, more so if you have no idea what the configuration commands mean or whether their order is relevant (I’m looking at you, Ansible ;).

Network to Code team decided to solve that problem for good, open-sourced Hierarchical Configuration Python library, and published a getting started article on their blog.

Dan Augustine sent me a wonderful example illustrating how even a very simple data model together with some automation templates can simplify a large-scale deployment.

We have a 100 router installation coming up for our schools and both of our installation vendors do not use open source templating tools and they are not willing to share.

Having taken the Data Models in Network Automation part of your Network Automation Concepts webinar, I decided to install GitLab, make an Ansible project and invite our installation partners to the project.