netlab release 1.7.0 added the fabric plugin that simplifies building lab topologies with leaf-and-spine fabrics. All you have to do to build a full-blown leaf-and-spine fabric is:

• Specify the default device type
• Enable the fabric plugin
• Specify the number of leaves and spines in the fabric.

For example, the following lab topology builds a fabric with Arista cEOS containers having two spines and four leaves:

Every time someone tries to persuade you to buy (expensive) big-buffer data center switches, take an antidote: the Things we (finally) know about network queues article by Avery Pennarun.

Last time, we discussed the first line of defense against fat finger incidents: limiting the number of BGP prefixes your router accepts from a BGP neighbor. However, you can do much more without deploying customer-specific filters (which might require a customer database) or ROV/RPKI.

You can practice the default filters you should always deploy on EBGP sessions with your customers in the Stop the Propagation of Configuration Errors lab exercise.

This is how we described the interactions between routing protocol tables, RIB, and FIB in the ancient times:

• Routing protocols compute the best paths to all known prefixes.
• These paths compete for entry in the routing table. The path(s) with the lowest administrative distance win.
• The entries from the routing table are fully evaluated (in particular, their next hops) and entered in the forwarding table.

Let’s use a simple BGP+OSPF network to illustrate what I’m talking about:

Arista EOS and Cisco Nexus OS got interface EBGP sessions years after Cumulus Linux. While they’re trivially easy to configure on FRRouting (the routing daemon used by Cumulus Linux), getting them to work on Arista EOS is a bit tricky.

To make matters worse, my Google-Fu failed me when I tried to find a decent step-by-step configuration guide; all I got was a 12-minute video full of YouTube ads. Let’s fix that.

I usually say that you cannot run netlab on Apple Silicon because the vendors don’t provide ARM images. However, when I saw an ARM version of the FRRouting container, I wondered whether I could run the BGP labs (admittedly only on FRR containers) on my M2 MacBook Pro.

TL&DR: Yes, you can do that.

Now for the recipe:

The March 2024 Internet Protocol Journal has a lengthy article on the history and “future” of Ethernet that might be worth reading (although it’s short on details) if you weren’t around when it all started.

Urs Baumann invited me to have a guest lecture in his network automation course, and so I had the privilege of being in lovely Rapperswil last week, talking about the basics of real-life network automation.

Urs published the video recording of the presentation on YouTube; hope you’ll like it, and if you don’t get too annoyed by the overly pushy ads, watch the other videos from his infrastructure-as-code course.

The “should we use the same vendor for fabric spines and leaves?” discussion triggered the expected counterexamples. Here’s one:

I actually have worked with a few orgs that mix vendors at both spine and leaf layer. Can’t take names but they run fairly large streaming services. To me it seems like a play to avoid vendor lock-in, drive price points down and be in front of supply chain issues.

As always, one has to keep two things in mind:

One of my readers was building a private MPLS/VPN backbone and wondered whether they should use their public AS number or a private AS number for the backbone. Usually, it doesn’t matter; the deciding point was the way they want to connect to the public Internet:

We also plan to peer with multiple external ISPs to advertise our public IP space not directly from our PE routers but from dedicated Internet Routers, adding a firewall between our PEs and external Internet routers.

They could either run BGP between the PE routers, firewall, and WAN routers (see BGP as High-Availability Protocol for more details) or run BGP across a bump-in-the-wire firewall: