I know many networking engineers who went into networking because they didn’t want to write code the rest of their lives. I also know a few awesome engineers who decided to keep coding while designing networks.

Andrea Dainese (author of UNetLab – the tool you might know as EVE-NG) is one of the latter and practiced network automation for years, dealing with all sorts of crappy device configuration and monitoring mechanisms, from screen- and web scraping to broken REST APIs.

He decided to write a series of articles describing individual mechanisms, starting with an overview and zero-touch provisioning.

One of my subscribers sent me a question along these lines (heavily abridged):

My customer runs a colocation business and has to provide L2 connectivity between racks, sometimes even across multiple data centers. They were using Q-in-Q to deliver that in a traditional fabric and would like to replace that with multi-site EVPN fabric with ~100 ToR switches in each data center. However, Cisco doesn’t support Q-in-Q with multi-site EVPN. Any ideas?

As Lukas Krattiger explained in his part of Multi-Site Leaf-and-Spine Fabrics section of Leaf-and-Spine Fabric Architectures webinar, multi-site EVPN (VXLAN-to-VXLAN bridging) is hard. Don’t expect miracles like Q-in-Q over VNI any time soon ;)

In summer 2018 Juniper started talking about another forward-looking concept: Network Reliability Engineering. We wanted to find out whether that’s another unicorn driving DeLorean with flux capacitors or something more tangible, so we invited Matt Oswalt, the author of Network Reliability Engineer’s Manifesto to talk about it in Episode 97 of Software Gone Wild.

In the first part of his interview with Christoph Jaggi Kristian Larsson talked about the basics of CI testing. Now let’s see how you can use these concepts in network automation.

How does CI testing fit into an overall testing environment?

Traditionally, in particular in the networking industry, it's been rather common to have proof of concepts (POC) delivered by vendors for various networking technologies and then people have sat down and manually tested that the POC meets some set of requirements.

As I’m doing occasional consulting for large enterprises redesigning their data centers, I encounter a wide range of network automation readiness, from “we don’t need that” to “how could we automate as much as possible”.

Based on the pervasiveness of “we don’t need that” responses it looks like many enterprise network engineers still have to go through the five stages of automation grief.

One of the attendees of the Building Next-Generation Data Center online course solved the build small data center fabric challenge with Virtual Chassis Fabric (VCF). I pointed out that I would prefer not to use VCF as it uses centralized control plane and is thus a single failure domain.

Here are his arguments for using VCF:

Every now and then someone tells me I should write more about the basic networking concepts like I did years ago when I started blogging. I’m probably too old (and too grumpy) for that, but fortunately I’m no longer on my own.

Over the years ipSpace.net slowly grew into a small community of networking experts, and we got to a point where you’ll see regular blog posts from other community members, starting with Using BGP as High-Availability protocol written by Nicola Modena, member of ExpertExpress team.

In spring 2019 Building Network Automation Solutions course we’ll have Kristian Larsson diving into continuous integration and his virtual networking lab product (you might want to listen to the Software Gone Wild episode we did with him to get a taste of what he’ll be talking about). Christoph Jaggi did a short interview with him starting with the obvious question:

What is CI testing and how does it differ from other testing methods?

CI is short for Continuous Integration and refers to a way of developing software where changes written by individual developers are frequently (or "continuously") integrated together into a master branch/trunk, thus continuous integration.

One of my readers sent me a description of their automation system that manages firewall rulesets on Fortigate firewalls using NAPALM to manage device configurations.

In his own words:

We are now managing thousands of address objects, services and firewall policies using David Barroso’s FortiOS Napalm module. This works very well and with a few caveats (such as finding a way to enforce the ordering of firewall policies) we are able to manage all the configuration of our firewalls from a single Ansible playbook.

The did the right thing and implemented an abstracted data model using GitOps to manage it:

You might have noticed that our Winter 2019 webinar schedule got crazily busy with seven live sessions in the first two months of the year (another first)… but that’s not all, there are two more live sessions that we haven’t announced yet as we always schedule a single live session of a particular webinar.

Wondering what’s coming during the rest of 2019? Starting with committed ideas: