Lab: More Complex EVPN/VXLAN Bridging Scenario

In the first EVPN/VXLAN lab, we added the EVPN control plane to bridging over VXLAN. Now, let’s try out a more complex scenario: several EVPN MAC-VRFs mapped to different VLAN segments on individual PE-devices.

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).

Configuring 6PE Route Reflector on Cisco IOS

Imagine you want to deploy a BGP route reflector for MPLS 6PE or L3VPN service. Both services run over MPLS LSPs, use IPv4 BGP sessions, and use IPv4 next hops for BGP routes. There’s absolutely no reason to need IPv6 routing on a node that handles solely the control-plane activity (it never appears as a BGP next hop anywhere), right? Cisco IOS disagrees, as I discovered when running route reflector integration tests for netlab 6PE and (MPLS) L3VPN functionality.

Most platforms failed those tests because we forgot to configure route-reflector-clients in labeled IPv6 and VPNv4/VPNv6 address families¹. That was easy to fix, but the IOS-based devices were still failing the tests, with nothing in the toolchain ever complaining about configuration problems.

On AI Agents Speaking BGP

I guess your LinkedIn feed is as full of AI nonsense as mine is, so I usually just skip all that posturing. However, every now and then, I stumble upon an idea that makes sense… until you start to dig deeper into it.

There was this post about AI agents speaking BGP with an associated GitHub repo, so I could go take a look at what it’s all about.

The proof-of-concept (so the post author) has two components:

Interesting: Open Space Events

Following a link in another Martin Fowler’s blog post, I stumbled upon his thoughts on Open Space events – a way to set up self-organizing events.

I’m not sure I’m brave (or young) enough to try it out, but if you’re planning to organize a small gathering (like a local Network Operator Group), this might be an interesting, slightly more structured approach than a Net::Beer event. It would also be nice to know whether someone managed to pull it off in an online format.

netlab: The Caveats of Using Startup Configurations

Petr Ankudinov wrote an excellent comment about netlab Fast cEOS Configuration implementation. Paraphrasing the original comment:

If the use case is the initial lab deployment, why don’t you use containerlab startup-config option to change the device’s startup configuration?

I have to admit, I’m too old to boldly go with the just use the startup configuration approach. In ancient times, Cisco IOS did crazy stuff if you rearranged the commands in the startup configuration. But ignoring that historical trivia (Cisco IOS/XE seems to be doing just fine), there are several reasons why I decided to use the startup configurations (and you can use them with some containers) as the last resort:

Public Videos: EVPN in MPLS-Based Environments

While we’re mostly discussing EVPN in conjunction with VXLAN encapsulation, its initial use case was as an alternate control plane for MPLS networks.

Krzysztof Szarkowicz had a great presentation describing the specifics of EVPN in MPLS-Based Environments a few years ago. Those videos (part of the EVPN Technical Deep Dive webinar) are now public; you can watch them without an ipSpace.net account.

Looking for more binge-watching materials? You’ll find them here.

Cisco IOS/XR OSPFv2 Not-So-Passive Interfaces

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).

EVPN IP-VRFs on Cisco IOS/XE: Configuration Notes

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:

Worth Reading: Modern Forwarding Architectures

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.

Explore Configurations of Unfamiliar Devices with netlab

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:

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 true¹, 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 normalize Jinja template had a bug – when setting the interface MAC address, it checked l.mac_address instead of intf.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.