Hands-On Introduction to SR-MPLS

The second demo¹ I did during the Segment Routing workshop @ ITNOG10 illustrated how easy it is to set up and explore a small SR-MPLS network with netlab. The lab topology described a small three-router network (you need three routers to see “true” labels besides the penultimate-hop popping ones):

MUST READ: The Future of Everything is Lies, I Guess

Kyle Kingsbury published a long (10-part) article about his frustrations with AI, aptly named The Future of Everything is Lies, I Guess.

Regardless of where you are on the skeptic-to-fanboy spectrum, I would highly recommend you read it, even if you believe you’ll disagree with everything he wrote.

Reorganized ipSpace.net Segment Routing Resources

I created nine sample SR-MPLS topologies for the ITNOG 10 SR-MPLS workshop, and of course, we ran out of time. I plan to cover those topologies and resulting printouts in a series of blog posts; to prepare for those, I cleaned up and reorganized the Segment Routing blog category, which is now split into two:

• Segment Routing with MPLS Labels (SR-MPLS)
• Segment Routing over IPv6 (SRv6)

Hope you’ll find them useful! Also, if you know of other non-vendor Segment Routing resources, please leave a comment, email me, or submit a pull request.

Public Videos: Segment Routing 101

In the spring of 2017, Jeff Tantsura, the IETF Routing Area chair, delivered a short “Introduction to Segment Routing” webinar. In mid-April 2026, we had ~100 people at ITNOG 10 attending the excellent “Segment Routing: From Theory to Practice” workshop by the great Tiziano Tofoni. The future is obviously not evenly distributed.

If you’re in the early stages of your Segment Routing journey, you might appreciate the videos from Jeff’s webinar; you can now watch them without an ipSpace.net account.

On ARP and MAC Aging Timers

Naveen Kumar Devaraj mentioned an interesting fact in his EVPN-related comment:

The EOS default ARP timeout is 4 hours, and MAC aging is 5 minutes.

Arista is not the only platform using these default values; did you ever wonder where they came from?

Hmmm: Cloudflare’s Automatic Return Routing

A while ago, I found the How Automatic Return Routing solves IP overlap article on Cloudflare’s blog. They evidently have a technology that addresses a pain point well worth solving (access to shared resources from clients using overlapping address ranges). I just hate how they’re selling it. Go read the article first; I’ll wait.

OK, here’s what bothers me: the “VRFs and NAT are bad” claims, while they use the same technology in disguise.

ARP Issues in EVPN Centralized Routing Design

Adding IRB to a EVPN MAC-VRFs (the fancy way of saying stretched VLANs) seems like a no-brainer:

• Add IP addresses to VLAN interfaces
• Optionally add a shared anycast gateway
• Declare “Mission Accomplished” (and try to ignore the inevitable phone call at 2 AM on a Sunday night)

Making that work in a multi-vendor environment is even more fun¹, as I sadly discovered when creating the EVPN lab exercises or trying to figure out why some EVPN implementations were failing netlab EVPN integration tests.

SwiNOG 41: It Was Nice to Be Back

Last week’s SwiNOG was (as expected) great fun at a phenomenal location, starting with the first slide of the first presentation: “6 Stages of Network De-sh*tification”. I particularly loved the “talk less, chat more” schedule. The longer breaks gave us plenty of time to catch up with old friends and discuss interesting, sometimes completely unexpected, topics. For example, I learned that SIP MESSAGE is used to carry SMS messages these days.

As much as I loved chatting with fellow networking engineers, I also found these presentations highly interesting:

Generate Partial Device Configurations with netlab

At ITNOG 10, I’ve seen something that I haven’t seen in a very long time: a mini-Interop-style physical lab using a dozen devices from different vendors. The network core was a leaf-and-spine fabric with off-path BGP route reflectors and numerous other devices attached to it.

I’ve configured a few networks in the past, so I know it must have been a beast to configure all those devices by hand (and fix all the IP addressing errors), but then a thought struck me: unless one wants to practice configuring IP addresses, it might be a good idea to use netlab to generate the IP addressing plan and partial device configurations.

On Generating EVPN MAC/IP Routes

Naveen Kumar Devaraj was reading my Integrated Routing and Bridging (IRB) with EVPN MAC-VRF Instances lab exercise and spotted this detail:

Arista EOS originates MAC-IP routes with and without IP addresses, effectively doubling the size of the EVPN BGP table

He kindly wrote a LinkedIn comment explaining that behavior:

Worth Reading: Lab as Code (containerlab and netlab)

@sjhloco wrote an excellent in-depth description of how you can use containerlab and netlab to manage your labs as code.

He also documented a few netlab shortcomings (one of which caused a crash); fortunately, I found his blog post (admittedly over a year later) and fixed most of them in release 26.04:

State of Network Automation with Urs Baumann

I stopped tracking the (lack of) progress in network automation years ago, when I realized I had nothing new to say. As an eternal optimist, I hoped I was just missing something, but Urs Baumann (the guest of Software Gone Wild Episode 206) destroyed my hopes when he said, “I can still use the same slides I created 10 years ago”. On a more positive note, he recently completed his Master’s thesis on AI in network engineering, so we ended with a nice chat on its potential impact.

Worth Reading: AI and Knowledge Stagnation

Another week, another interesting AI article (is anyone writing about anything else these days?), this time from Noah Smith (another author worth following). I found this gem hidden in his weekly roundup:

Instead of trying to write a piece of code from scratch, or prove a math theorem from scratch, or figure out some piece of knowledge for yourself, you just ask AI to do it all for you. So everyone ends up getting the right answers to questions whose answers are already known, so they don’t end up adding anything new.

Read more …

Ten Years of ITNOG

I spent the last two days in Bologna at ITNOG 10 in the excellent company of Italian networking engineers (many of them personal friends) and a few guests from around the world. As always, the organizers and the program committee didn’t disappoint – it was a smoothly organized, lovely event full of interesting presentations. Thanks a million to everyone involved; I’ll definitely be back!

Now for the highlights, starting with the ultimate catnip for the differently attentive: running two presentations in parallel on the same screen with the soundtrack distributed via headphones. I’ve never seen anything like that, and while it looked weird (I have no idea how the presenters took it), it turned out to be very useful, as you could easily tune out AI-washing presentations and switch to something more interesting. On the other hand, you could be faced with a hard choice of having to select one of two excellent presentations:

Hmmm: Rail-Optimized Networking for AI Workloads

Phil Gervasi wrote an interesting article describing Rail-Optimized Networking for AI Training Workloads. Go read it first; I’ll wait.

Does it sound interesting? Were you able to see behind the curtain and figure out what it’s really about?

SR-MPLS Workshop Materials

We had a wonderful SR-MPLS workshop @ ITNOG 10 in Bologna on April 20th 2025. If you missed it, explore:

• The Segment Routing: from Theory to Practice presentation by Tiziano Tofoni
• The slide deck for the hands-on part of the workshop
• The lab topologies, and the usage guidelines.

Lab: Integrated Routing and Bridging (IRB) with EVPN MAC-VRF Instances

Most EVPN documentation rushes into the complexities of symmetric IRB, type-5 EVPN routes, and EVPN IP-VRFs, but if you want to master a technology, it’s better to take it slow and proceed with small steps. In today’s lab exercise, we’ll do just that: explore what happens when you add IP addresses (we’ll use anycast gateways) to VLAN interfaces tied to EVPN MAC-VRF instances.

Testing FRRouting Pull Requests with netlab

Every other blue moon, I discover a bug in FRRouting (example). Because the FRRouting developers care about their work, it usually gets fixed within a few days, often resulting in a “can you test this PR?” question.

It turns out that’s surprisingly easy to do with netlab – here’s the step-by-step procedure (assuming you already have the topology file that reproduced the bug):

BGP Labs: Graceful Degradation for Unsupported Devices

A few weeks ago, I described the changes in the online BGP labs that allow you to use most of the common network operating systems as “external” routers¹. However, while we keep improving it, netlab still can’t configure all BGP features on all supported devices (PRs from Nokia and Mikrotik fans would be highly appreciated 😎), which means that it’s possible to configure your environment in a way where some of the more complex labs would simply fail to start.

The limited choice of devices for external routers was always well-documented (example), but if you insisted on using unsupported devices, the lab would fail to start with an error message, and you’d have to tweak the lab topology (example). Wouldn’t it be better to start the lab with a warning?

What is Netlab and Why Network Engineers Should Care

Milan Zapletal, the author of the biggest netlab topology I’ve seen so far (full story), has published a nice introductory article explaining What is Netlab and Why Network Engineers Should Care.

Thank you, Milan! Much appreciated ;)