A Thought Leader¹ recently published a LinkedIn article comparing IGP and BGP convergence in data center fabrics². In it, they³ claimed that:

iBGP designs would require route reflectors and additional processing, which could result in slightly slower convergence.

Let’s see whether that claim makes any sense.

TL&DR: No. If you’re building a simple leaf-and-spine fabric, the choice of the routing protocol does not matter (but you already knew that if you read this blog).

As part of the netlab development process, I run almost 200 integration tests on more than 20 platforms (over a dozen operating systems), and the amount of weirdness I discover is unbelievable.

Today’s special: Junos is failing the IS-IS metrics test.

The test is trivial:

• The device under test is connected to two IS-IS routers (X1 and X2)
• It has a low metric configured on the link with X1 and a high metric configured on the link with X2

The validation process is equally trivial:

Imagine you want to create a simple multi-site network with netlab:

• The lab should have two sites (A and B).
• Each site has a layer-3 switch, a single VLAN (VLAN 100), and two hosts connected to that VLAN.
• As you don’t believe in the magic powers of stretched VLANs, you have a layer-3 (IPv4) link between sites.

After three and a half years of haggling (the IETF draft that became the RFC was written in May 2021; the original discussions go back to 2013), Nick Buraglio & co managed to persuade pontificators bikeshedding in the v6ops working group that we might need an IPv6 documentation prefix larger than the existing 2001:db8::/32.

With the new documentation prefix (3fff::/20) (defined in RFC 9637), there’s absolutely no excuse to use public IPv6 address space in examples anymore.

netlab release 1.9.3 brings these new features:

• Multi-chassis Link Aggregation (MLAG) on Arista EOS, Aruba CX, Cumulus NVUE, and Dell OS10
• VRF and VLAN groups
• Additional OSPF interface parameters (hello and dead timers, cleartext passwords, and DR priority) implemented on Arista EOS, Aruba CX, Cisco IOS/IOS-XE, Cisco Nexus OS, Cumulus Linux, Dell OS10, and FRRouting
• Static routes with direct or indirect next hops implemented on Arista EOS, Cisco IOS/IOS-XE, FRRouting, and Linux
• Node cloning plugin for users who want to build detailed digital twins of their networks.
• Consistent selection of default address pools based on the number of nodes attached to a link (this could change addressing in multi-provider topologies)
• Support for vjunos-router and Cisco NSO tool.

Other new features include:

A friend of mine recently wrote a nice post explaining how netlab helped him set up a large network topology in a reasonably short timeframe. As expected, his post attracted a wide variety of comments, from “netlab is a gamechanger” (thank you 😎) to “I prefer traditional labs.” Instead of writing a bunch of replies into a walled-garden ecosystem, I decided to address some of those concerns in a public place.

Let’s start with:

The introduction of real-time mission-critical applications into data networks has prompted many network designers to tune their routing protocols for faster convergence. While the resulting network can quickly detect failures and reroute around them, it usually becomes highly susceptible to repetitive failures (for example, a flapping interface), which can cause recurring instabilities in large parts of the network. A flapping interface can also cause significant data loss, as the data streams are constantly rerouted across the network following a routing protocol adjacency establishment and subsequent loss.

Wanted to share this “too weird to believe” SNAFU I found when running integration tests with the Bird routing daemon. It’s irrelevant unless you want Bird to advertise the IPv6 prefix configured on the main loopback interface (lo) with OSPFv3.

Late last year, I decided to run netlab integration tests with the Bird routing daemon. It passed most baseline netlab OSPFv3 integration tests but failed those that checked the loopback IPv6 prefix advertised by the tested device (test results).

Another year is almost gone, and it’s time for my traditional “I will disappear until mid-January” retreat (also, don’t expect me to read my email until I’m back).

I hope you’ll also be able to disconnect from the crazy pace of the networking world, forget the “AI will make networking engineers obsolete” shenanigans (hint: SDN did not), and focus on your loved ones. I would also like to wish you all the best in 2025!

I will probably get bored sometime in late December, so expect a few new netlab features in early January.

Addy Osmani published an excellent overview of the challenges of AI-assisted coding. They apply equally well to the “AI will generate device configurations for me” or “AI will troubleshoot my network” ideas (ignoring for the moment the impact of the orders-of-magnitude smaller training set), so it’s definitely worth reading.

I particularly liked the “‌AI is like having a very eager junior developer on your team” take, as well as the description of the “70% problem” (AI will get you 70% there, but the last 30% will be frustrating) – a phenomenon perfectly illustrated by the following diagram by Forrest Brazeal:

As much as I love explaining how to use BGP in an optimal way, sometimes we have to do what we know is bad to get the job done. For example, if you have to deal with clueless ISPs who cannot figure out how to use BGP communities, you might be forced to use the Big Hammer of disaggregated prefixes. You can practice how that works in the next BGP lab exercise.

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 policy/b-disaggregate and execute netlab up.

My Internet Routing Security talk from last year’s DEEP conference (a shorter version of the Internet Routing Security webinar) is now available on YouTube.

Hope you’ll find it useful ;)

We were always told that Open Shortest Path First (OSPF) is a fast converging link-state routing protocol that always results in a loop-free and blackhole-free network topology. In reality, it’s a link-state protocol within an area and almost a distance-vector protocol between areas.

In this article, I’ll illustrate how this unexpected behavior can affect the convergence of your network and how you can use proprietary extensions of Cisco IOS to alleviate the undesired side effects of OSPF.

A fellow networking engineer recently remarked, “FRRouting automatically selects the correct [IBGP] source interface even when not configured explicitly.”

TL&DR: No, it does not. You were just lucky.

Basics first¹. BGP runs over TCP sessions. One of the first things a router does when establishing a BGP session with a configured neighbor is to open a TCP session with the configured neighbor’s IP address.

On December 9th, 2020, I created a new GitHub repository and pushed the first commit of my “I hate creating Vagrantfiles by hand” tool. It could create Vagrantfile and Ansible inventory from a (very rudimentary) network topology and deploy handcrafted device configurations on Cisco IOS and Arista EOS.