
Author Archives: Ivan Pepelnjak
Author Archives: Ivan Pepelnjak
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:
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:
These blog posts will not make you an expert but will give you an excellent overview of the telemetry landscape1.
Hint: more than enough to turn you into an instant AI-assisted LinkedIn garbage generator Thought Leader™ 😜 ↩︎
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:
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 good1 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:
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.
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.
It all started with a netlab issue describing different interpretations of VLAN 1 in a trunk. While Cumulus NVUE (the way the netlab configuration template configures it) assumes that the VLAN 1 in a trunk is tagged, Arista EOS assumes it’s the native VLAN.
At that point, I should have said, “that’s crazy, we shouldn’t allow that” and enforce the “VLAN 1 has to be used as a native VLAN” rule. Alas, 20/20 hindsight never helped anyone.
TL&DR: Do not use VLAN 1 in VLAN trunks; if you have to, use it as a native VLAN.
The initial IS-IS labs covered the IS-IS basics. It’s time to move on to interesting IS-IS features (and why you might want to use them), starting with passive IS-IS interfaces.
In the Concise Link Descriptions blog post, I described various data formats that you could use to concisely list nodes attached to a link. Today, we’ll focus on a mechanism that helps you spot errors in your topology: a dictionary of links.
Imagine you have a large topology with dozens of links, and you get an error saying, “there is this problem with links[17]
”. It must be great fun counting the links to find which one triggered the error, right?
Once a virtual machine running a network operating system boots, you’d expect its data-plane interfaces to be operational, right? Some vendors disagree. It takes over a minute for some network operating systems to figure out they have this thing called interfaces.1
I would love to figure out what takes them so long (a minute is an eternity on modern CPUs), but I guess we’ll never know.
netlab uses two device provisioning mechanisms: it can start virtual machines with Vagrant or containers with containerlab. Some of those containers might use KVM/QEMU to run a hidden virtual machine (see also: RFC 1925 rule 6a).
A few days ago, someone mentioned Arista released a cEOS EFT image running on Arm. Of course, I had to test whether it would run on Apple Silicon.
TL&DR: YES 🎉 🎉
Here’s what you have to do to make the Arista cEOS container work with netlab running on an Ubuntu VM on Apple silicon:
There are three major ways to connect network devices in the physical world:
Implementing these connections in virtual labs is a bit harder than one might think, as all virtualization solutions assume you plan to run virtual servers connected to Ethernet segments.
During the last three weeks, we were busy squashing bugs (device configuration fixes, other bug fixes). Some were recent; others were ancient pests uncovered by better integration tests. The end result: netlab release 1.9.4.
netlab release 1.9.4 passed hundreds of integration tests and should be a better choice than the previous 1.9 releases. To upgrade, execute pip3 install --upgrade networklab
.
We still missed a few quirks :( Release 1.9.4-post1 addresses those (and, unfortunately, I’m pretty sure there will be more).
I got this question from Paul:
Have you ever seen a BGP peer in the “Connect” state? In 20 years, I have never been able to see or reproduce this state, nor any mention in a debug/log. I am starting to believe that all the documentation is BS, and this does not exist.
The BGP Finite State Machine (FSM) (at least the one defined in RFC 4271 and amended in RFC 9687) is “a bit” hard to grasp but the basics haven’t changed from the ancient days of RFC 1771:
Dalton Ortega, Cisco Modeling Labs Product Manager, sent me the following email as a response to my Configuring IP Addresses Won't Make You an Expert blog post:
First, your statement on Autonetkit is indeed correct. We had removed that from the product due to lack of popularity. That being said, in our roadmap we are looking at methods to reintroduce on-the-fly configuration as well as enhancing our sample labs library to make getting started with CML easier.
Secondly, CML can be run in full IaC mode because of the API-first build. In fact, many of our customers are using CML as an automated test/validation bed for their CI/CD pipelines. Tools like Ansible and Terraform are available to facilitate this inside CML too. For more details, read: