If you’re at all interested in the history of networking, you simply MUST watch the BGP at 18: Lessons In Protocol Design lecture by Dr. Yakov Rekhter recorded in 2007 (as you can probably guess from the awful video quality) (HT: Berislav Todorovic via LinkedIn).
Petr Ankudinov made an interesting remark when I complained about how much time I wasted waiting for Cisco 8000v to boot when developing netlab device configuration templates:
For Arista part - just use AVD with all templates included and ANTA for testing. I was always wondering why netlab is not doing that.
Like any other decent network automation platform, netlab uses a high-level data model (lab topology) to describe the network. That data model is then transformed into a device-level data model, and the device-level data structures are used to generate device configurations.
One of the major differences between OSPF and IS-IS is their handling of inter-area routes. Non-backbone OSPF intra-area routes are copied into the backbone area and later (after the backbone SPF run) copied into other areas. IS-IS does not copy level-2 routes into level-1 areas; level-1 areas (by default) behave like totally stubby OSPF areas with the level-1 routers using the Attached (ATT) bit of level-1-2 routers in the same area to generate the default route.
One of my readers attempted to implement a multi-vendor multicast VPN over MPLS but failed. As a good network engineer, he tried various duct tapes but found that the only working one was a GRE tunnel within a VRF, resulting in considerable frustration. In his own words:
How is a GRE tunnel different compared to an MPLS LSP? I feel like conceptually, they kind of do the same thing. They just tunnel traffic by wrapping it with another header (one being IP/GRE, the other being MPLS).
Instead of going down the “how many angels are dancing on this pin” rabbit hole (also known as “Is MPLS tunneling?”), let’s focus on the fundamental differences between GRE/IPsec/VXLAN tunnels and MPLS paths.
TL&DR: Of course, the title is clickbait. While the differences are amazing, you won’t notice them in small topologies or when using bloatware that takes minutes to boot.
Let’s start with the background story: due to the (now fixed) suboptimal behavior of bleeding-edge Ansible releases, I decided to generate the device configuration files within netlab (previously, netlab prepared the device data, and the configuration files were rendered in an Ansible playbook).
As we use bash scripts to configure Linux containers, it makes little sense (once the bash scripts are created) to use an Ansible playbook to execute docker exec script or ip netns container exec script. netlab release 26.01 runs the bash scripts to configure Linux, Bird, and dnsmasq containers directly within the netlab initial process.
Now for the juicy part.
Why do we need Infrahub, another network automation tool? What does it bring to the table, who should be using it, and why is it using a graph database internally?
I discussed these questions with Damien Garros, the driving force behind Infrahub, the founder of OpsMill (the company developing it), and a speaker in the ipSpace.net Network Automation course.
David Gee was time-pressed to set up a demo network to showcase his network automation solution and found that a Ubuntu VM running netlab to orchestrate Arista cEOS containers on his Apple Silicon laptop was exactly what he needed.
I fixed a few blog posts based on his feedback (I can’t tell you how much I appreciate receiving a detailed “you should fix this stuff” message, and how rare it is, so thanks a million!), and David was kind enough to add a delightful cherry on top of that cake with this wonderful blurb:
Netlab has been a lifesaver. Ivan’s entire approach, from the software to collecting instructions and providing a meaningful information trail, enabled me to go from zero to having a functional lab in minutes. It has been an absolute lifesaver.
I can be lazy with the infrastructure side, because he’s done all of the hard work. Now I get to concentrate on the value-added functionality of my own systems and test with the full power of an automated and modern network lab. Game-changing.
TL&DR: Most probably not, but if you do, you’d better not rely on random blogs for professional advice #justSaying 😜
Here’s an interesting question I got from a reader in the midst of an OSPF-to-IS-IS migration:
Why should one bother with different [IS-IS] areas when the routing hierarchy is induced by the two levels and the appropriate IS-IS circuit types on the links between the routers?
Well, if you think you need a routing hierarchy, you’re bound to use IS-IS areas because that’s how the routing hierarchy is implemented in IS-IS. However…
I completely rewrote netlab’s device configuration file generation during the New Year break. netlab Release 26.01 no longer uses Ansible Jinja2 functionality and works with Ansible releases 12/13, which are used solely for configuration deployment. I had to break a few eggs to get there; if you encounter any problems, please open an issue.
Other new features include:
You’ll find more details (and goodies) in the release notes.
They say time goes faster as you get older, and it seems to be true. Another year has (almost) gone by.
Try to disconnect from the crazy pace of the networking world, forget the “vibe coding with AI will make engineers obsolete” stupidities (hint: Fifth Generation Languages and Natural Language Programming were all the rage in the 1980s and 1990s), and focus on your loved ones. I would also like to wish you all the best in 2026!
In the meantime, I’m working on weaning netlab off of a particular automation tool (you can always track the progress on GitHub). Expect the first results in the January netlab release.
Want to look up various HTTP status/error codes when troubleshooting a DNS BGP network server problem? Start at http.pizza for badly-needed stress relief (HT: Networking Notes), then start a chat session with your new AI friend exploring more focused resources like the Wikipedia list of HTTP status codes.
A month ago, I described how Ansible release 12 broke the network device configuration modules, the little engines (that could) that brought us from the dark days of copy-and-paste into the more-survivable land of configuration templates.
Three releases later (they just released 13.1), the same bug is still there (at least it was on a fresh Python virtual environment install I made on a Ubuntu 24.04 server on December 13th, 2025), making all device_config modules unusable (without changing your Ansible playbooks) for configuration templating. Even worse:
I don’t know why I decided to allow underscores in netlab node names. Maybe it’s a leftover from the ancient days when some network devices refused to accept hyphens in hostnames, or perhaps it’s a programmer’s subconscious hatred of hyphens in identifiers (no programming language I’m aware of allows them for a very good reason).
Regardless, you can use underscores in netlab node names (and plugins like multilab use them to create unique hostnames), and they work great on Linux distributions we recommend… until they don’t.
What follows is a story about the weird dependencies that might bite you if you ignore ancient RFCs.
Like OSPF, IS-IS was designed when router memory was measured in megabytes and clock speeds in megahertz. Not surprisingly, it includes a scalability mechanism similar to OSPF areas. An IS-IS router could be a level-1 router (having in-area prefixes and a default route), a level-2 router (knowing just inter-area prefixes), or a level-1-2 router (equivalent to OSPF ABR).
Even though multilevel IS-IS is rarely used today, it always makes sense to understand how things work, and the Multilevel IS-IS Deployments lab exercise created by Dan Partelly gives you a perfect starting point.
Click here to start the lab in your browser using GitHub Codespaces (or set up your own lab infrastructure). After starting the lab environment, change the directory to advanced/1-multilevel and execute netlab up.
The first IPv6 specs were published in 1995, and yet 30 years later, we still have a pretty active IETF working group focused on “developing guidelines for the deployment and operation of new and existing IPv6 networks.” (taken from the old charter; they updated it in late October 2025). Why is it taking so long, and what problems are they trying to solve?
Nick Buraglio, one of the working group chairs, provided some answers in Episode 203 of the Software Gone Wild podcast.
In 2007, Jeff Atwood published a legendary blog post summarizing a 1997 paper by Brian Foote and Joseph Yoder.
Reading that blog post (or the original paper), the inevitable conclusion is that we haven’t made much progress in the last 20 years. Even worse, almost every single pathological architecture described in that blog post applies quite well to real-life organically grown networks.
netlab release 25.12 (25.12.02 to be exact – I had a few PEBCAK moments) was published last Friday. Here are the highlights:
In the first VXLAN lab, we covered the very basics. Now it’s time for a few essential concepts (before introducing the EVPN control plane or integrated routing and bridging):
Sean Goedecke published an excellent set of recommendations for good technical writing, including:
Based on some emails I received in the past (and the lack of response to the lengthy emails I sent), we should apply the same rules to emails (and all other forms of technical communication).
What could be better than watching 0x02 Jeffs discuss networking? How about having Petr Lapukhov of the RFC 7938 fame as a guest discussing AI/ML Data Center Design?
Note: Petr disappeared into the information black hole called Facebook over a decade ago, so I wondered how they allowed him to chat on a podcast for hours. It turns out he moved to NVIDIA, which might influence the podcast content a bit, but I’m pretty sure Petr is still Petr ;)