The early October 2021 Facebook outage generated a predictable phenomenon – couch epidemiologists became experts in little-known Bridging the Gap Protocol (BGP), including its Introvert and Extrovert variants. Unfortunately, I also witnessed several unexpected trips to Mount Stupid by people who should have known better.

To set the record straight: everyone’s been there, and the more vocal you tend to be on social media (including mailing lists), the more probable it is that you’ll take a wrong turn and end there. What matters is how gracefully you descend and what you’ve learned on the way back.

When I started creating the How Networks Really Work series, I wondered whether our subscribers (mostly seasoned networking engineers) would find it useful. Turns out at least some of them do; this is what a long-time subscriber sent me:

How Networks Really Work is great, it’s like looking from a plane and seeing how all the roads are connected to each other. I know networking just enough to design and manage a corporate network, but there are many things I have learned, used and forgotten along the way.

So, getting a broad vision helps me remember why I chose something and maybe solve my bad choices. There are many things that I may never use, but with the movement of all things in the cloud it’s great to know, or at least understand, how things really work.

Two weeks ago I replied to a battle-scar reaction to 7-layer OSI model, this time I’ll address a much more nuanced view from Russ White. Please read his article first (as always, it’s well worth reading) and when you come back we’ll focus on this claim:

The OSI Model does not accurately describe networks.

Like with any tool in your toolbox, you can view the 7-layer OSI model in a number of ways. In the case of OSI model, it can be used:

I should have known better, but I got pulled into another stretched VLANs for disaster recovery tweetfest. Surprisingly, most of the tweets were along the lines of you really shouldn’t be doing that and that would never work well, but then I guess I was only exposed to a small curated bubble of common sense… until this gem appeared in my timeline:

Interestingly, that’s exactly how IP works:

One of my readers sent me this interesting question:

It begs the question in how far graduated students with a degree in computer science or applied IT infrastructure courses (on university or college level or equivalent) are actually aware of networking fundamentals. I work for a vendor independent networking firm and a lot of my new colleagues are college graduates. Positively, they are very well versed in automation, scripting and other programming skills, but I never asked them what actually happens when a packet traverses a network. I wonder what the result would be…

I can tell you what the result would be in my days: blank stares and confusion. I “enjoyed” a half-year course in computer networking that focused exclusively on history of networking and academic view of layering, and whatever I know about networking I learned after finishing my studies.

I was speaking with a participant of an SDN event in Zurich after the presentations, and he made an interesting comment: whenever he experienced serious troubleshooting problems in his career, it was due to lack of understanding of networking fundamentals.

Let me give you a few examples: Do you know how ARP works? What is proxy ARP? How does TCP offload work and why is it useful? What is an Ethernet collision and when would you see one? Why do we need MLD in IPv6 neighbor discovery?

While we’re mostly discussing EVPN in conjunction with VXLAN encapsulation, its initial use case was as an alternate control plane for MPLS networks.

Krzysztof Szarkowicz had a great presentation describing the specifics of EVPN in MPLS-Based Environments a few years ago. Those videos (part of the EVPN Technical Deep Dive webinar) are now public; you can watch them without an ipSpace.net account.

Looking for more binge-watching materials? You’ll find them here.

What’s wrong with me? Why do I have to uncover another weirdness every single time I run netlab integration tests on a new platform? Today, it’s Cisco IOS/XR (release 25.2.1) and its understanding of what “passive” means. According to the corresponding documentation, the passive interface configuration command is exactly what I understood it to be:

Use the passive command in appropriate mode to suppress the sending of OSPF protocol operation on an interface.

However, when I ran the OSPFv2 passive interface integration test with an IOS/XR container, it kept failing with neighbor is in Init state (the first and only time I ever encountered such an error after testing over two dozen platforms).

Last week, I described some of the gotchas I encountered while trying to make EVPN MAC-VRFs work on Cisco IOS/XE. In the meantime, I got IP-VRFs with transit VXLAN segments working. Here are the CliffsNotes:

Starting with the disgusting configuration mechanism:

Ignoring the obligatory misguided mention of OpenFlow and a few other unicorns, I found this article to be a nice introduction to modern forwarding architectures, including networking infrastructure for AI clusters and distributed cell-based fabrics.

Apart from IP multicast and QoS, netlab can configure commonly used networking technologies across dozens of devices from most networking vendors. Why don’t you use all that embedded knowledge (supported by hundreds of integration tests) to help you configure unfamiliar devices?

You don’t have to install VM or container managers (Vagrant/containerlab), or beg vendors to give you access to device VMs/containers, to get working device configurations. All you need is a Python package that works on Windows¹, macOS, or Linux.

It’s as simple as this:

Want to spend an hour or two configuring some cool stuff this weekend? How about getting SR-MPLS to work with IS-IS and building a BGP-free core with it?

If you already set up your own netlab environment, you probably know what to do (or you can get the details here). Alternatively, you can click here to start the lab in your browser using GitHub Codespaces. After starting the lab environment, change the directory to advanced/10-sr and execute netlab up.

After reading the L2 Vxlan On Catalyst blog post, I decided to add EVPN configuration templates to netlab-supported Cisco IOS/XE devices. It wasn’t the easiest EVPN implementation I encountered; here’s what I learned (hoping you’ll find it helpful).

Starting with the trivial hiccups:

netlab release 26.02 is out, including the usual potpourri of goodies:

• Support for Kubernetes (KinD) clusters based on work by @wnagele
• Layer-2 EVPN/VXLAN support on Cat8000v, IOL, and IOLL2
• netlab graph command can create graphs from a subset of nodes or links
• You can specify the parameters of core links in the fabric plugin
• OSPFv3 reports

The fun part, however, are the new container configuration methods:

Brian Linkletter published an updated overview of open-source network simulators and emulators.

containerlab and GNS3 are clear leaders (no surprise there) with the original vrnetlab becoming abandonware (fortunately, we have Roman Dodin’s fork), which makes me think we should focus on using netlab primarily with containerlab and slowly sunset the Vagrant support, particularly considering some people actively hate the license change.

Also, if anyone feels like writing an interface (provider module) between netlab and GNS3, the pull request would be most welcome 😎

Any thoughts? Please leave a comment!