netlab 1.9.6: Static Routes to Default Gateways

Last week, I had to push out netlab release 1.9.6 to address a particularly nasty Python dependency hell to make netlab work (again) on Ubuntu 24.04 (more details). The release also brought these goodies (and a bunch of bug fixes):

• Add default gateway (including anycast- and VRRP gateway )as a valid next-hop for static routes
• Rewrite the default gateway processing and add IPv6 default gateways on links without anycast or VRRP gateways
• Set libvirt MTU to 9500 on bridge-based networks to avoid the “transparent fragmentation” on Linux bridges.
• Use device- or node variables to specify the Juniper vMX license file.

IPv6 and the Revenge of the Stupid Bridges

This blog post describes another “OMG, this cannot possibly be true” scenario discovered during the netlab VRRP integration testing.

I wanted to test whether we got the nasty nuances of VRRPv3 IPv6 configuration right on all supported platforms and created a simple lab topology in which the device-under-test and an Arista cEOS container would be connected to two IPv6 networks (Arista EOS is a lovely device to use when testing a VRRP cluster because it produces JSON-formatted show vrrp printouts).

Most platforms worked as expected, but Aruba CX, Cumulus Linux with NVUE, and Dell OS10 consistently failed the tests. We were stumped until Jeroen van Bemmel discovered that the Arista container forwards IPv6 router advertisements between the two LAN segments.

Routed Interfaces on Layer-3 Switches and Internal VLANs

In the Router Interfaces and Switch Ports blog post, I described why we have switch ports and routed interfaces on layer-3 switches. Another blog post in the same series described the conceptual architecture of a layer-3 switch:

• All interfaces are connected to a VLAN-aware switch
• The switch interfaces could be access or trunk interfaces¹.
• Each VLAN in a VLAN-aware switch can be connected to an internal router through a VLAN interface.

However, that’s not how we configure layer-3 switches. There’s a significant gap between the conceptual configuration model and the internal architecture:

Comparing IP and CLNP: Network State Summarization

In the previous blog posts, we discussed how TCP/IP and CLNP reach adjacent nodes and build ARP/ND/ES caches and how they reach off-subnet nodes. Now, let’s move from the network edge into the network core and explore how the two protocol stacks reduce the amount of information they have to propagate in routing protocols.

While I’m not exactly an OSI fan, I must admit they got many things right (and IPv6 copied those ideas), but TCP/IP is a clear winner in this aspect.

Worth Reading: Standards for ANSI Escape Codes

I encountered the Escape sequences (named after the first character in the sequence) while programming stuff that would look nicely on the venerable VT100 terminals (not to mention writing one or two VT100 emulators myself).

In the meantime, those sequences got standardized and (par for the course) extended with “proprietary” stuff everyone uses now. Julia Evans did a great job documenting the state of the art. Thanks a million!

Arista EOS Spooky Action at a Distance

This blog post describes yet another bizarre behavior discovered during the netlab integration testing.

It started innocently enough: I was working on the VRRP integration test and wanted to use Arista EOS as the second (probe) device in the VRRP cluster because it produces nice JSON-formatted results that are easy to use in validation tests.

Everything looked great until I ran the test on all platforms on which netlab configures VRRP, and all of them passed apart from Arista EOS (that was before we figured out how Sturgeon’s Law applies to VRRPv3) – a “That’s funny” moment that was directly responsible for me wasting a few hours chasing white rabbits down this trail.

Public Videos: Queuing Theory

The Queuing Theory webinar by Rachel Traylor is now available without a valid ipSpace.net account. Enjoy!

Lab: IS-IS Designated Router Election

Like OSPF, IS-IS needs a router to originate the pseudo-node for a LAN segment. IS-IS standards call that router a Designated Intermediate System (DIS), and since it is not responsible for flooding, it does not need a backup.

Want to know more? The Influence the Designated IS Election lab exercise provides the details (and some hands-on work).

The Linux Bridge MTU Hell

It all started with an innocuous article describing the MTU basics. As the real purpose of the MTU is to prevent packet drops due to fixed-size receiver buffers, and I waste spend most of my time in virtual labs, I wanted to check how various virtual network devices react to incoming oversized packets.

As the first step, I created a simple netlab topology in which a single link had a slightly larger than usual MTU… and then all hell broke loose.

Worth Reading: Traffic Steering into LSPs

You can use SR-MPLS, MPLS-TE, or an SDN controller to build virtual circuits (label-switched paths) across the network core. The controller can push the LSPs into network devices with PCEP, BGP-LU, or some sort of NETCONF/RESTCONF trickery.

Unfortunately, you’re only half done once you have installed the LSPs. You still have to persuade the network devices to use them. Welcome to the confusing world of traffic steering explored in the Loopback as a Service blog post by Dmytro Shypovalov.

netlab 1.9.5: New Cumulus Linux(NVUE) and Junos Features

Jeroen van Bemmel and Stefano Sasso contributed tons of new device features for the netlab release 1.9.5:

Cumulus Linux (NVUE):

• VXLAN and EVPN
• VLAN-aware router (VLAN subinterfaces) functionality
• VRF route leaking
• VRF-aware BGP and full RFC 8950 support (IPv4 BGP AF over regular IPv6 BGP session)
• BGP allowas_in and EBGP multihop

New Networking Fundamentals Page

I wrote dozens of posts describing various fundamentals of networking technologies. They were a bit hard to find, so I organized them into subcategories and created a summary page to display them. I hope you like the new format.

Comparing IP and CLNP: Reaching Off-Subnet Nodes

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?

Capturing Traffic in Virtual Networking Labs

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.

Podcast: The Rise of NAT

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 ;)

Worth Reading: The Generative AI Con

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 ;)

Worth Reading: The IPv6 Agnostic Blog

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.

Stub Networks in Virtual Labs

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.

Worth Reading: Network Traffic Telemetry 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¹.

Run BGP Across a Firewall

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.