Blog Posts in February 2026
Lab: Build an SR-MPLS Network with IS-IS
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.
EVPN on Cisco IOS/XE: Configuration Notes
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 26.02: KinD support, more EVPN/VXLAN
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:
Open-Source Network Simulators (2026 Edition)
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.
Also, if anyone feels like writing an interface (provider module) between netlab and GNS3, the pull request would be most welcome 😎
Any thoughts? Please leave a comment!
Fast Arista cEOS Container Configuration
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 ;)
Lab: Routing Between VXLAN Segments
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.
You can run the lab on your own netlab-enabled infrastructure (more details), but also within a free GitHub Codespace or even on your Apple-silicon Mac (installation, using Arista cEOS container, using VXLAN/EVPN labs).
On MPLS Forwarding Performance Myths
Whenever I claim that the initial use case for MPLS was improved forwarding performance (using the RFC that matches the IETF MPLS BoF slides as supporting evidence), someone inevitably comes up with a source claiming something along these lines:
The idea of speeding up the lookup operation on an IP datagram turned out to have little practical impact.
That might be true1, although I do remember how hard it was for Cisco to build the first IP forwarding hardware in the AGS+ CBUS controller. Switching labels would be much faster (or at least cheaper), but the time it takes to do a forwarding table lookup was never the main consideration. It was all about the aggregate forwarding performance of core devices.
Anyhow, Duty Calls. It’s time for another archeology dig. Unfortunately, most of the primary sources irrecoverably went to /dev/null, and personal memories are never reliable; comments are most welcome.
OMG, After a Decade, VXLAN Is Still Insecure
In 2017 (over eight years ago), I was making fun of the fact that “VXLAN is insecure” was news to some people. Obviously, the message needed to be repeated, as the same author gave a very similar presentation two years later at a security conference.
Unfortunately, it seems that everything old is new again (see also RFC 1925 rules 4 and 11), as proved by a “Using GRE and VXLAN for Fun and Profit” (my summary) presentation at DEFCON 33. Even if you knew that unencrypted tunnels are insecure (duh!) for decades, you might still want to read the summary of the talk (published on APNIC blog) and view the slides.
Interface MAC Address in IOS Layer-2 Images
Here’s another “You can’t make this up, but it sounds too crazy to be true” story: Cisco IOS layer-2 images change the interface MAC address when you change the interface switchport status.
Let me start with a bit of background:
- IOL Layer 2 image starts with interfaces enabled and in bridged (switchport) mode (details)
- netlab has to run a normalize script (applicable to IOLL2, IOSv L2, and Arista EOS) before configuring anything else to ensure all interfaces are shut down.
- The IOLL2
normalizeJinja template had a bug – when setting the interface MAC address, it checkedl.mac_addressinstead ofintf.mac_address. Nevertheless, everything worked because the MAC addresses were also set during the initial device configuration.
Fast FRR Container Configuration
After creating the infrastructure that generates the device configuration files within netlab (not in an Ansible playbook), it was time to try to apply it to something else, not just Linux containers. FRR containers were the obvious next target.
netlab uses two different mechanisms to configure FRR containers:
- Data-plane features are configured with bash scripts using ip commands and friends.
- Control-plane features are configured with FRR’s vtysh
I wanted to replace both with Linux scripts that could be started with the docker exec command.