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.

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:

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

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.

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.

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:

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?

We’re starting the SR-MPLS workshop @ ITNOG 10 in Bologna in a few hours. Hope you’ll make it, but if you happen to be too far away, here’s the slide deck, the lab topologies, and the usage guidelines.

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.

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

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