netlab release 1.9.1 brings packet capture capabilities and numerous routing features:

• IS-IS route redistribution and IS-IS VRF instances
• RIPv2/Ripng route redistribution and VRF instances
• Configurable RIPv2/RIPng protocol timers

We also added support for Cisco IOSv layer-2 image. You’ll find more details in the release notes.

I spent a few days in a beautiful place with suboptimal Internet connectivity. The only thing I could do whenever I got bored (without waiting for the Internet gnomes to hand-carry the packets across the mountain passes) was to fix the BGP labs on a Ubuntu VM running on my MacBook Air (hint: it all works).

Big things first. I added validation to these labs:

• MD5 Passwords and GTSM
• Use BGP Timers and BFD to Speed Up BGP Convergence
• BGP Route Aggregation
• EBGP Sessions over IPv6 LLA Interfaces
• Establish an IBGP Session
• Build a Transit Network with IBGP
• Use BGP Route Reflectors
• Using No-Export Community to Filter Transit Routes

After publishing the EVPN L3VPN lab-building instructions, I published a deep dive into EVPN and data-plane data structures. You might have missed it, as it was published in mid-August.

In the first exercise in the IS-IS labs series, you’ll configure IS-IS routing for IPv4. The basic configuration is trivial, but you’ll also have to tweak the defaults that most vendors got wrong (we’ll discuss why those defaults are wrong in the next lab exercises).

I also tried to make the IS-IS labs more than just lab exercises. Each exercise includes a bit of background information or IS-IS theory; this one describes generic OSI addresses (NSAPs) and router addresses (NETs).

When looking for the latest SR Linux container image, I noticed images with -arm-preview tags and wondered whether they would run on Apple Silicon.

TL&DR: YES, IT WORKS 🎉 🎉

Here’s what you have to do to make SR Linux work with netlab running on a Ubuntu VM on Apple silicon:

All our previous designs of the hub-and-spoke VPN (single PE, EVPN) used two VRFs for the hub device (ingress VRF and egress VRF). Is it possible to build a one-arm hub-and-spoke VPN where the hub device exchanges traffic with the PE router over a single link?

TL&DR: Yes, but only on some devices (for example, Cisco IOS or FRRouting) when using MPLS transport.

Here’s a high-level diagram of what we’d like to achieve:

In the previous BGP load balancing lab exercise, I described the BGP Link Bandwidth attribute and how you can use it on EBGP sessions. This lab moves the unequal-cost load balancing into your network; we’ll use the BGP Link Bandwidth attribute on IBGP sessions.

Retirement obviously does not sit well with my friend Tiziano Tofoni; the English version of his IPv6 book just came out.

It is a bit sad, though, that we still need “how to use IPv6” books when the protocol is old enough to enjoy a nice glass of whiskey (in the US) trying to drown its sorrow at its slow adoption.

A previous blog post described how you can use the netlab report functionality to generate addressing, wiring, BGP, and OSPF reports from a running lab. But what could you do if you need a report that doesn’t exist yet? It’s straightforward to define one (what else did you expect?).

Let’s create the report I used in the EVPN Hub-and-Spoke Layer-3 VPN blog post to create the VRF table.

Now that we figured out how to implement a hub-and-spoke VPN design on a single PE-router, let’s do the same thing with EVPN. It turns out to be trivial:

• We’ll split the single PE router into three PE devices (pe_a, pe_b, and pe_h)
• We’ll add a core router (p) and connect it with all three PE devices.

As we want to use EVPN and have a larger core network, we’ll also have to enable VLANs, VXLAN, BGP, and OSPF on the PE devices.

This is the topology of our expanded lab:

Yesterday’s blog post discussed the traffic flow and the routing information flow in a hub-and-spoke VPN design (a design in which all traffic between spokes flows through the hub site). It’s time to implement and test it, starting with the simplest possible scenario: a single PE router using inter-VRF route leaking to connect the VRFs.

Hub-and-spoke topology is by far the most complex topology I’ve ever encountered in the MPLS/VPN (and now EVPN) world. It’s used when you want to push all the traffic between sites attached to a VPN (spokes) through a central site (hub), for example, when using a central firewall.

You get the following diagram when you model the traffic flow requirements with VRFs. The forward traffic uses light yellow arrows, and the return traffic uses dark orange ones.

A year after I started the open-source BGP configuration labs project, I was persuaded to do something similar for IS-IS. The first labs are already online (with plenty of additional ideas already in the queue), and you can run them on any device for which we implemented IS-IS support in netlab.

Want an easy start? Use GitHub Codespaces. Have a laptop with Apple Silicon? We have you covered ;)

In May 2024, I made public the first half of the Network Connectivity and Graph Theory videos by Rachel Traylor.

Now, you can also enjoy the second part of the webinar without a valid ipSpace.net account; it describes trees, spanning trees, and the Spanning Tree Protocol. Enjoy!

In the previous blog posts, we explored the simplest possible IBGP-based EVPN design and tried to figure out whether BGP route reflectors do more harm than good. Ignoring that tiny detail for the moment, let’s see how we could add route reflectors to our leaf-and-spine fabric.

As before, this is the fabric we’re working with: