Archive

Category Archives for "ipSpace.net"

Comparing IP and CLNP: Finding Adjacent Nodes

Now that we know a bit more about addresses in a networking stack (read the whole series) and why CLNP uses node addresses while TCP/IP uses interface addresses, let’s see how they solve common addressing problems like finding adjacent nodes.

Let’s start with the elephant in the room: how do you know whether you can reach a host you want to communicate with directly? In the following diagram, how does A know whether B is sitting next to it?

Using BGP NO_EXPORT Community to Filter Transit Routes

In previous BGP policy lab exercises, we covered several mechanisms you can use to ensure your autonomous system is not leaking transit routes (because bad things happen when you do, particularly when your upstream ISP is clueless).

As you probably know by now, there’s always more than one way to get something done with BGP. Today, we’ll explore how you can use the NO_EXPORT community to filter transit routes.

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/d-no-export and execute netlab up.

EVPN Designs: EBGP Everywhere

In the previous blog posts, we explored the simplest possible IBGP-based EVPN design and made it scalable with BGP route reflectors.

Now, imagine someone persuaded you that EBGP is better than any IGP (OSPF or IS-IS) when building a data center fabric. You’re running EBGP sessions between the leaf- and the spine switches and exchanging IPv4 and IPv6 prefixes over those EBGP sessions. Can you use the same EBGP sessions for EVPN?

TL&DR: It depends™.

BGP Labs: Improvements (September 2024)

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:

IS-IS Labs: Configure IS-IS Routing for IPv4

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

SR Linux Containers Run on Apple Silicon

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 🎉 🎉

Update 2024-12-11: Starting with 24.10.1 and 23.10.6 images, the SR Linux container manifest contains AMD and ARM images, making running SR Linux on ARM trivial. This blog post has been updated accordingly.

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

One-Arm Hub-and-Spoke VPN with MPLS/VPN

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:

IPv6: Instructions for Use

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.

EVPN Hub-and-Spoke Layer-3 VPN

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:

Hub-and-Spoke VPN Topology

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.