netlab release 26.05 is out. Here are the highlights:

• Support for global BGP routes with SRv6 next hops (inspired by proof-of-concept by @jvbemmel) on FRR and IOS XR
• Junos OSPF/IS-IS route redistribution, VRF IS-IS instances, and OSPF interface parameters
• Streamline and speed up the FortiOS initial device configuration by @a-v-popov
• Support for Juniper cSRX container by @leec-666

netlab release 26.05 is out. I’ll write about its highlights tomorrow; today, I want to focus on one of its breaking changes: netlab no longer works with Python 3.8 (which reached end-of-life in October 2024), so you can no longer install it on a vanilla Ubuntu 20.04 (which reached end of standard support a year ago).

We wanted to get rid of old Python versions for ages, but never did because Ubuntu 20.04 shipped with Python 3.8, and many netlab early adopters installed it on Ubuntu 20.04 (and the last thing a networking engineer wants is wasting time with upgrades, right?).

I postponed the discussion of ARP issues with EVPN anycast gateways to keep yesterday’s blog post reasonably short. If you’re impatient and want to try that out, I have just the right lab exercise for you; you’ll have to extend VLANs into end-to-end MAC-VRF instances and add IRB and anycast gateways:

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

In a previous blog post, I described the ARP issues you’ll encounter when using centralized routing (on a spine switch) between two EVPN MAC-VRF instances (a fancy name for a VLAN encapsulated in VXLAN or MPLS).

That blog post established a baseline that will help us unravel the ARP behavior in a more realistic scenario: asymmetric Integrated Routing and Bridging (IRB). That’s a mouthful, but it’s really quite a simple concept; the following diagram explains the asymmetric forwarding behavior:

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

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.

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.

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.

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?

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.