I always wanted to find someone who is more positive about AI than I am, while having solid “can deliver working stuff at scale” credentials. Andrew Yourtchenko definitely fits the bill. I first met him (online) when he was still an engineer in Cisco TAC, and when we finally met in person, he was busy automating the deployment of Cisco Live networking infrastructure. He was also instrumental in bringing us closer to ubiquitous IPv6 deployment with Happy Eyeballs.

Leo Fleskes sent me an interesting question after reading my Generate Partial Device Configurations with netlab blog post:

What is stopping us from eventually, given enough usage and coverage, using netlab to configure devices in the live network?

In theory, nothing. In practice, you might hit a few hurdles:

A friend of mine sent me links to a new paper published by AWS engineers, and an associated LinkedIn post which claims:

We got lean, resilient, massive aggregation fabrics that provide 33% better throughput with 69% fewer routers, savings 27% of costs, cutting power usage by 40%, and reducing CO2 emissions.

The obvious question one should ask after reading the hyperventilated Radical Network Redesign blog post is thus: is this the end of leaf-and-spine networks? Of course not. Let’s go into the details.

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.

Upgrading or Starting from Scratch?

• To upgrade your netlab installation, execute pip3 install --upgrade networklab.
• New to netlab? Start with the Getting Started document and the installation guide.
• Need help? Open a discussion or an issue in netlab GitHub repository.

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.

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 interfaces¹, 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.