Author Archives: ipSpace.net blog
Author Archives: ipSpace.net blog
Following a link in Martin Fowler’s Fragments, I stumbled upon Genie Tarpit by Kent Beck – a perfect summary of my experiences with AI coding (code reviews are OK, new code less so). He also provided a good reason for that behavior:
The “plausible deniability” task orientation of the genie leaves it claiming success even though the code doesn’t work at all.
And the proposed solution?
You probably saw this one coming—nobody knows.
netlab release 26.06 adds OSPFv3 support on FortiOS (by @a-v-popov) and MPLS/VPN support on SR Linux. We also ensured the installation scripts work on Ubuntu 26.04 (everything else was OK) and updated the installed Vagrant version to 2.4.9 (we’re not using new Vagrant features; you don’t have to upgrade it in an existing installation).
Other than that, we added a few improvements and squashed a number of bugs.
pip3 install --upgrade networklab.Did you know that you can implement a VRF-Lite design with VXLAN? All you need are devices that can run VRF routing protocols over VXLAN-backed VLAN segments.
Compared to the “traditional” VRF-Lite design, in which you need a set of VLANs on every link and every device running the routing protocol for every VRF, the VXLAN-based design needs just IP routing on the core switches, resulting in a design that’s pretty close to what we were building with DMVPN (without IPsec and NHRP complications).
A happy netlab user sent me an unexpected use case: they successfully used its multi-vendor capabilities to argue with a vendor TAC. Here’s the gist of the story (edited/anonymized for obvious reasons):
A month ago, I described ARP issues in EVPN centralized routing design, and Naveen Kumar Devaraj was kind enough to add some Arista EOS implementation details. Today, let’s explore what EVPN routes Arista EOS generates in that scenario. We’ll use a very simple lab topology with a spine switch acting as a router. The leaf switches are layer-2 switches.

Packet forwarding in centralized routing design
Tony Mattke built several networking-focused CLI tools and released them on GitHub. You might find them useful.
After the simple SR-MPLS demo and the dual-stack SR-MPLS setup, it was time for the next obvious question: Does SR-MPLS work over unnumbered IPv4 interfaces1, assuming the implementation of the underlying routing protocol supports them? Of course it does; let’s go through the details, using the same topology I used throughout the Segment Routing workshop @ ITNOG10.
Here’s a short glimpse into the history of telecommunications: in a building at the top of this mountain (barely noticeable blip across the saddle from the radio tower; search for Capo Figari for more details), Guglielmo Marconi conducted experiments in the ~1930s (after inventing the wireless telegraph system in the late 1890s).
The original radio could “transmit” at most 40-60 words per minute (the limit of a skilled Morse Code operator). 130 years later, I’m writing this blog post using a 200 Mbps Internet connection via a low-earth-orbit satellite with response times low enough that I can run an interactive SSH session with no noticeable delay. It’s almost incomprehensible how far we’ve come in such a short time.
Doug Madory wrote an interesting article (published on APNIC blog) arguing that we shouldn’t worry about ephemeral BGP leaks that can be observed only during the BGP path hunting process that follows a route withdrawal.
I have to disagree with that. It’s never a good idea to ignore a dead canary in the coal mine.
While the ephemeral leaks do not impact the end result (after all, the route is gone), they are an important indicator of the lack of BGP route policy enforcement in the autonomous systems that propagate them. If an autonomous system is propagating a bogus route when no better routes are available, it’s equally likely to propagate a bogus route when an intruder manages to inject it.
After fixing the SR Linux LDP configuration template, I decided to add MPLS/VPN to the netlab SR Linux MPLS features. After all, the one-page recipe seemed simple enough, more so as we already have tested VRF and EVPN templates.
Alas, nothing is as simple as it looks. There were two details that tripped me pretty badly.
Did you manage not to stumble on a dramatic post explaining how someone generated 10,000 lines of code with AI while wasting time on your LinkedIn feed? Congratulations, you’re lucky.
However, as Nathaniel Fishel explained in his Your Code Is Worthless article, the “lines of code” is a useless vanity metric that sounds great in a LinkedIn self-promotion, but doesn’t matter when one has to maintain the product one has shipped to the customers. Add the natural laziness, and you have a perfect storm. As he wrote:
Remember OpenFlow, the One Protocol to Bind Them All1? I haven’t heard anyone even mention it in ages, and I never bothered to ask whether anyone is still using it after the dismal results of the 2022 poll.
Anyway, if you still have to deal with that ancient blunder, six hours of deep dive videos I recorded a decade ago might still be useful. You can watch them without an ipSpace.net account.
Looking for more binge-watching materials? You’ll find them here.
After the introduction to SR-MPLS demo I did during the Segment Routing workshop @ ITNOG10, we moved to dual-stack SR-MPLS – can we assign node segment identifiers (SIDs) to IPv4 and IPv6 prefixes? The demo used the same three-router network as the previous one, with IPv4 SIDs starting at one and IPv6 SIDs starting at 101:
Most of the hyperventilated AI “success stories” are as useful as the “ANSIBLE!!!” movement was a few years ago. It’s thus always a pleasure to find someone with well-established software development chops who took the time to describe what works for them.
One cannot argue with Mike McQuaid’s credentials (at least if you happen to be using homebrew on MacOS, which you REALLY SHOULD), and his Sandboxes and Worktrees: My secure Agentic AI Setup in 2026 article is full of relevant recommendations in case you’re brave enough to let AI agents loose on your GitHub repository.
netlab release 26.05 is out. Here are the highlights:
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:

Packet forwarding in an EVPN asymmetric IRB design
The second demo1 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.