I know a few software development companies use netlab to test their network management software (and contribute back to netlab – thanks a million!), and I always wanted to chat about that. As I have known Dinesh Dutt for ages, it wasn’t hard to decide who to invite to have that chat with ;)

As it turns out, it’s dangerous to put Dinesh¹ and me in the same (virtual) room – we were all over the place, from the ancient history of Vagrant in networking labs to the recent Ansible woes, but we did manage to cover how netlab helps Stardust Systems test new SuzieQ features.

Long, long time ago, in a long-forgotten PR adding support for Cumulus VX Ignite runtime, an off-the-cuff remark was made saying, “and this is how you use netlab with Podman”. That remark was quietly sitting in the documentation for years until someone (A) tried to use Podman and (B) found enough time to report that it doesn’t work with netlab.

I don’t know what that tells us: either very few people use Podman, or nobody (apart from a notable exception) cares enough to spend a few minutes telling us stuff doesn’t work¹.

Anyway, based on Joey Buiteweg’s wonderful research, I was able to put together a working solution pretty quickly, but it did involve a lot of yak shaving (more bovine details).

In late June, we added GRE tunnels to netlab, including a Junos implementation. It looked great (as in “everything worked”) until I changed the integration tests to have GRE tunnels between a tested device and a pair of FRR containers. All other implementations worked as before, but Junos failed to establish an OSPFv3 adjacency over the GRE tunnel with FRR.

Stefano Sasso quickly identified the culprit: Junos OSPFv3 process thinks it should send the DBD packets over GRE tunnels with MTU set to zero (the behavior reserved for virtual links)¹.

Summer is almost over, and it’s time to resume regular programming with the next example from the Segment Routing workshop I had at ITNOG10: multi-vendor SR-MPLS. I used the same lab topology as in the previous examples but deployed Arista EOS on PE1, FRRouting on P, and SR Linux on PE2¹

When someone starts singing the Use Digital Twins to Test Your Network hymn (or, more recently, tells you how AI agents can do that to validate their ideas), ask them about these minor details. If they persist, point them (not that it would help) to this long list of gotchas.

That list just got longer: Arista cEOS container does not apply inbound ACLs to control-plane traffic (Arista vEOS VM does).

Tony Mattke continues publishing excellent “Git for Networking Engineers” content. In his latest article, he described how to find who made what changes (and why) in a Git repository.

Absolutely worth reading if you’re new to Git, but even oldtimers might find a few useful tidbits (Git is one of those things one never truly masters).

A lot of AI-coding enthusiasts are making claims along the lines of “AI coding tools are like compilers; you supply intent, they translate it into code, and who ever looked at the machine-code output?” Unfortunately, there is a bit of a gap between hope and reality; traditional compilers were always deterministic, and are (after decades of development and bug-fixing) pretty much bug-free. AI coding tools are neither, and no amount of “agentic loops” will solve that.

Sakar left an interesting comment on my The Curious Case of the BGP Connect State blog post, claiming that Cisco IOS/XE goes through a CONNECT state when opening an incoming BGP session.

I wanted to double-check this behavior, so I needed a scenario where one router would keep sending TCP SYN requests, the other would not (or we wouldn’t learn anything), and the two routers could not communicate (or they’d quickly go into the OPEN state).

Here’s my first attempt at meeting those requirements:

Remember the sage advice to simplify your life and use the IPv6 /64 prefixes everywhere? Not only does it make your life simpler (and wastes immesuarably less address space than the crazy “let’s assign /64 to every device” stupidity), it also reduces the hardware requirements in your high-speed routers layer-3 switches. You see, doing lookups on 64 bits uses half the silicon it takes to do lookups on 128 bits.

Alas, some people never got the memo. OSPFv3 standard clearly states in one of the bullets in section 4.4.3.9 that the loopback prefixes should always be advertised as /128s regardless of what’s configured on the interface.

Tony Mattke put together a long list of recommendations that might help you get more out of your LLM tokens.

Definitely worth reading instead of yelling at the stupid AI.