Category: automation

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.

We have school holidays this week, so I’m reposting wonderful comments that would otherwise be lost somewhere in the page margins. Today: Minh Ha on recent Facebook failure and overly complex systems (slightly edited).

I incidentally commented on your NSF post some 3 weeks before […the Facebook outage…] happened, on the unpredictable nature of nonlinear effects resulting from optimization-induced complexity. Their outage just drives home the point that optimization is a dumb process and leads to combinations of circular dependency that no one can account for and test.

In case you’re ever asked to justify an investment in network automation, read How to Make the Case for Automation Architecture first. Not surprisingly, it includes the evergreen what problem are you trying to solve?

Network validation is becoming another overhyped buzzword with many opinionated pundits talking about it and few environments using it in practice (why am I not surprised?)

As always, there are exceptions. They don’t have to be members of the FAANG club, and some of them get the job done with open-source tools regardless of what vendor marketers would like you to believe. For example, Donatas Abraitis described how the Hostinger networking team gradually implemented network validation using Cumulus VX, Vagrant, SuzieQ, PyTest and Test Kitchen. Enjoy!