The previous blog post in this series discussed how TCP/IP and CLNP reach adjacent nodes and build ARP/ND/ES caches. Now let’s move one step further: how do nodes running IPv4/IPv6 or CLNP discover the first-hop router that could forward their traffic to off-subnet nodes they want to communicate with?

When I announced the Stub Networks in Virtual Labs blog post on LinkedIn, I claimed it was the last chapter in the “links in virtual labs” saga. I was wrong; here comes the fourth part of the virtual links trilogy – capturing “on the wire” traffic in virtual networking labs.

While network devices provide traffic capture capabilities (usually tcpdump in disguise generating a .pcap file), it’s often better to capture the traffic outside of the device to see what the root cause of the problems you’re experiencing might be.

When Ned Bellavance asked me to be a guest on the Chaos Lever podcast talking about NAT, I replied, “and why do you hate me so much?”

However, it turned out one can have a fun conversation about a controversial topic. For more details, listen to The Rise of NAT on Chaos Lever. I hope you’ll enjoy it ;)

I love good steamy rants, and The Generative AI Con from Edward Zitron is as good as they come. Pour yourself a glass of wine (or a cup of tea or whatever else you prefer) and have some fun ;)

Ole Troan, an excellent networking engineer working on IPv6 for decades, has decided to comment on the color of the IPv6 kettle, starting with:

• Is the transition to IPv6 inevitable? (hint: Betteridge’s law of headlines)
• The mistakes and missed opportunities in the design of IPv6 - episode 1 (aka Second System Effect¹)

I’m pretty sure Ole won’t stop there, so stay tuned.

The previous blog posts described how virtualization products create LAN segments and point-to-point links.

However, sometimes we need stub segments – segments connected to a single router or switch – because we don’t want to waste resources creating hosts attached to a network device, but would still prefer a more realistic mechanism than static routes to inject IP subnets into routing protocols.

Pavel Odintsov published a series of introductory blog posts describing protocols we can use to collect network traffic telemetry:

• Part 1 covers the ancient Netflow v5, Netflow v9, and IPFIX. It also mentions sampling and flow aggregation.
• Part 2 describes sFlow, port mirroring and sampled mirroring, and the use of IPFIX/Netflow v9 to transport mirrored traffic.

These blog posts will not make you an expert but will give you an excellent overview of the telemetry landscape¹.

When I asked my readers what they would consider a good use case for EBGP multihop (thanks again to everyone who answered!), many suggested running BGP across a layer-3 firewall (Running BGP across a “transparent” (bump-in-the-wire) firewall is trivial). I turned that suggestion into a lab exercise in which you have to establish an EBGP multihop session across a “firewall” simulated by a Linux host.

If you haven’t set up your own lab infrastructure, click here to start the lab in your browser using GitHub Codespaces. After starting your codespace, change the directory to basic/e-ebgp-multihop and execute netlab up.

Dmytro Shypovalov published another article well worth reading: why should you use an SDN controller for RSVP-TE. It covers:

• The reasons people might still prefer RSVP-TE over SR-MPLS and the current state of RSVP-TE
• What an SDN controller might bring to the RSVP-TE world
• SR/RSVP coexistence and interworking

Have fun!

Last Monday, I decided to review and merge the “VXLAN on Cumulus Linux 5.x with NVUE” pull request. I usually run integration tests on the modified code to catch any remaining gremlins, but this time, all the integration tests started failing during the VM creation phase. I was completely weirded out, considering everything worked a week ago.

Fortunately, Vagrant debugging is pretty good¹ and I was quickly able to pinpoint the issue (full printout):

Donatas Abraitis asked me to spread the word about the first ever Baltic NOG meeting in the second half of September 2025 (more details)

If you were looking for a nice excuse to visit that part of Europe (it’s been on my wish list for a very long time), this might be a perfect opportunity to do it 😎.

On a tangential topic of fascinating destinations 😉, there’s also ITNOG in Bologna (May 19th-20th, 2025), Autocon in Prague (May 26th-30th, 2025), and SWINOG in Bern (late June 2025).

The results of netlab integration tests are stored in YAML files, making it easy to track changes improvements with Git. However, once I added the time of test and netlab version to the test results, I could no longer use git diff to figure out which test results changed after a test run – everything changed.

For example, these are partial test results from the OSPFv2 tests:

Whenever you’re faced with an “unexpected” network outage that doesn’t seem to be caused by a hardware failure, the root cause often tends to be a change in a device configuration, raising these questions:

• What changes were made to the device configuration?
• When were the changes made?
• Who made them?

Vini Motta decided to use AI on ipSpace.net content to find what it would recommend as the projects to work on in order to become employable in 2025. Here are the results he sent me; my comments are inline on a gray background.

Network Automation with Python

Project: Automate basic network tasks like device configuration, backup, or monitoring using Python scripts.

In the previous blog post, I described the usual mechanisms used to connect virtual machines or containers in a virtual lab, and the drawbacks of using Linux bridges to connect virtual network devices.

In this blog post, we’ll see how KVM/QEMU/libvirt/Vagrant use UDP tunnels to connect virtual machines, and how containerlab creates point-to-point vEth links between Linux containers.