Archive

Category Archives for "ipSpace.net"

FRRouting Claims IBGP Loopbacks Are Inaccessible

Last week, I explained the differences between FRRouting and more traditional networking operating systems in scenarios where OSPF and IBGP advertise the same prefix:

  • Traditional networking operating systems enter only the OSPF route into the IP routing table.
  • FRRouting enters OSPF and IBGP routes into the IP routing table.
  • On all platforms I’ve tested, only the OSPF route gets into the forwarding table1.

One could conclude that it’s perfectly safe to advertise the same prefixes in OSPF and IBGP. The OSPF routes will be used within the autonomous system, and the IBGP routes will be propagated over EBGP to adjacent networks. Well, one would be surprised 🤦‍♂️

FRRouting Claims IBGP Loopbacks Are Inaccessible

Last week, I explained the differences between FRRouting and more traditional networking operating systems in scenarios where OSPF and IBGP advertise the same prefix:

  • Traditional networking operating systems enter only the OSPF route into the IP routing table.
  • FRRouting enters OSPF and IBGP routes into the IP routing table.
  • On all platforms I’ve tested, only the OSPF route gets into the forwarding table1.

One could conclude that it’s perfectly safe to advertise the same prefixes in OSPF and IBGP. The OSPF routes will be used within the autonomous system, and the IBGP routes will be propagated over EBGP to adjacent networks. Well, one would be surprised 🤦‍♂️

netlab: Building Leaf-and-Spine Fabrics with the Fabric Plugin

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:

netlab: Building Leaf-and-Spine Fabrics with the Fabric Plugin

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:

BGP Labs: Stop the Fat-Finger Incidents

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.

BGP Labs: Stop the Fat-Finger Incidents

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.

FRRouting RIB and FIB

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:

FRRouting RIB and FIB

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:

Interface EBGP Sessions on Arista EOS

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.

Interface EBGP Sessions on Arista EOS

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.

Running netlab and BGP Labs on Apple Silicon

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 started wondering 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:

1 10 11 12 13 14 177