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?

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!

After the enormous speedup I achieved with the FRR containers, I tried to do something similar with the Arista cEOS ones. After all, Arista’s pretty open about running its software on standard Linux, so it should be possible to map host-side configuration files into container-side scripts and execute them, right?

There was just one tiny gotcha: all netlab-generated EOS configuration files are device configuration snippets that are intended to be submitted via EOS CLI, and I didn’t feel like cracking open the netmiko documentation (that’s another backburner project).

However, Arista cEOS includes this magic command called FastCli ;)

In the previous EVPN/VXLAN lab exercises, we covered the basics of Ethernet bridging over VXLAN and the use of the EVPN control plane to build layer-2 segments.

It’s time to move up the protocol stack. Let’s see how you can route between VXLAN segments, this time using unique unicast IP addresses on the layer-3 switches.

You can run the lab on your own netlab-enabled infrastructure (more details), but also within a free GitHub Codespace or even on your Apple-silicon Mac (installation, using Arista cEOS container, using VXLAN/EVPN labs).

Whenever I claim that the initial use case for MPLS was improved forwarding performance (using the RFC that matches the IETF MPLS BoF slides as supporting evidence), someone inevitably comes up with a source claiming something along these lines:

The idea of speeding up the lookup operation on an IP datagram turned out to have little practical impact.

That might be true¹, although I do remember how hard it was for Cisco to build the first IP forwarding hardware in the AGS+ CBUS controller. Switching labels would be much faster (or at least cheaper), but the time it takes to do a forwarding table lookup was never the main consideration. It was all about the aggregate forwarding performance of core devices.

Anyhow, Duty Calls. It’s time for another archeology dig. Unfortunately, most of the primary sources irrecoverably went to /dev/null, and personal memories are never reliable; comments are most welcome.

In 2017 (over eight years ago), I was making fun of the fact that “VXLAN is insecure” was news to some people. Obviously, the message needed to be repeated, as the same author gave a very similar presentation two years later at a security conference.

Unfortunately, it seems that everything old is new again (see also RFC 1925 rules 4 and 11), as proved by a “Using GRE and VXLAN for Fun and Profit” (my summary) presentation at DEFCON 33. Even if you knew that unencrypted tunnels are insecure (duh!) for decades, you might still want to read the summary of the talk (published on APNIC blog) and view the slides.

Here’s another “You can’t make this up, but it sounds too crazy to be true” story: Cisco IOS layer-2 images change the interface MAC address when you change the interface switchport status.

Let me start with a bit of background:

• IOL Layer 2 image starts with interfaces enabled and in bridged (switchport) mode (details)
• netlab has to run a normalize script (applicable to IOLL2, IOSv L2, and Arista EOS) before configuring anything else to ensure all interfaces are shut down.
• The IOLL2 normalize Jinja template had a bug – when setting the interface MAC address, it checked l.mac_address instead of intf.mac_address. Nevertheless, everything worked because the MAC addresses were also set during the initial device configuration.