What’s wrong with me? Why do I have to uncover another weirdness every single time I run netlab integration tests on a new platform? Today, it’s Cisco IOS/XR (release 25.2.1) and its understanding of what “passive” means. According to the corresponding documentation, the passive interface configuration command is exactly what I understood it to be:

Use the passive command in appropriate mode to suppress the sending of OSPF protocol operation on an interface.

However, when I ran the OSPFv2 passive interface integration test with an IOS/XR container, it kept failing with neighbor is in Init state (the first and only time I ever encountered such an error after testing over two dozen platforms).

Last week, I described some of the gotchas I encountered while trying to make EVPN MAC-VRFs work on Cisco IOS/XE. In the meantime, I got IP-VRFs with transit VXLAN segments working. Here are the CliffsNotes:

Starting with the disgusting configuration mechanism:

Ignoring the obligatory misguided mention of OpenFlow and a few other unicorns, I found this article to be a nice introduction to modern forwarding architectures, including networking infrastructure for AI clusters and distributed cell-based fabrics.

Apart from IP multicast and QoS, netlab can configure commonly used networking technologies across dozens of devices from most networking vendors. Why don’t you use all that embedded knowledge (supported by hundreds of integration tests) to help you configure unfamiliar devices?

You don’t have to install VM or container managers (Vagrant/containerlab), or beg vendors to give you access to device VMs/containers, to get working device configurations. All you need is a Python package that works on Windows¹, macOS, or Linux.

It’s as simple as this:

Want to spend an hour or two configuring some cool stuff this weekend? How about getting SR-MPLS to work with IS-IS and building a BGP-free core with it?

If you already set up your own netlab environment, you probably know what to do (or you can get the details here). Alternatively, you can click here to start the lab in your browser using GitHub Codespaces. After starting the lab environment, change the directory to advanced/10-sr and execute netlab up.

After reading the L2 Vxlan On Catalyst blog post, I decided to add EVPN configuration templates to netlab-supported Cisco IOS/XE devices. It wasn’t the easiest EVPN implementation I encountered; here’s what I learned (hoping you’ll find it helpful).

Starting with the trivial hiccups:

netlab release 26.02 is out, including the usual potpourri of goodies:

• Support for Kubernetes (KinD) clusters based on work by @wnagele
• Layer-2 EVPN/VXLAN support on Cat8000v, IOL, and IOLL2
• netlab graph command can create graphs from a subset of nodes or links
• You can specify the parameters of core links in the fabric plugin
• OSPFv3 reports

The fun part, however, are the new container configuration methods:

Brian Linkletter published an updated overview of open-source network simulators and emulators.

containerlab and GNS3 are clear leaders (no surprise there) with the original vrnetlab becoming abandonware (fortunately, we have Roman Dodin’s fork), which makes me think we should focus on using netlab primarily with containerlab and slowly sunset the Vagrant support, particularly considering some people actively hate the license change.

After the enormous speedup I achieved with the FRR containers, I tried to do something similar with the Arista cEOS ones. After all, Arista’s pretty open about running its software on standard Linux, so it should be possible to map host-side configuration files into container-side scripts and execute them, right?

There was just one tiny gotcha: all netlab-generated EOS configuration files are device configuration snippets that are intended to be submitted via EOS CLI, and I didn’t feel like cracking open the netmiko documentation (that’s another backburner project).

However, Arista cEOS includes this magic command called FastCli ;)

In the previous EVPN/VXLAN lab exercises, we covered the basics of Ethernet bridging over VXLAN and the use of the EVPN control plane to build layer-2 segments.

It’s time to move up the protocol stack. Let’s see how you can route between VXLAN segments, this time using unique unicast IP addresses on the layer-3 switches.