BGP Challenge: Build BGP-Free MPLS Core Network

Here’s another challenge for BGP aficionados: build an MPLS-based transit network without BGP running on core routers.

That should be an easy task if you configured MPLS in the past, so try to spice it up a bit:

• Use SR/MPLS instead of LDP
• Do it on a platform you’re not familiar with (hint: Arista vEOS is a bit different from Cisco IOS)
• Try to get it running on FRR containers.

BGP Challenge: Build BGP-Free MPLS Core Network

Here’s another challenge for BGP aficionados: build an MPLS-based transit network without BGP running on core routers.

That should be an easy task if you configured MPLS in the past, so try to spice it up a bit:

• Use SR/MPLS instead of LDP
• Do it on a platform you’re not familiar with (hint: Arista vEOS is a bit different from Cisco IOS)
• Try to get it running on FRR containers.

EVPN Designs: VXLAN Leaf-and-Spine Fabric

In this series of blog posts, we’ll explore numerous routing protocol designs that can be used to implement EVPN-with-VXLAN L2VPNs in a leaf-and-spine data center fabric. Every design will come with a companion netlab topology you can use to create a lab and explore the behavior of leaf- and spine switches.

Our leaf-and-spine fabric will have four leaves and two spines (but feel free to adjust the lab topology fabric parameters to build larger fabrics). The fabric will provide layer-2 connectivity to orange and blue VLANs. Two hosts will be connected to each VLAN to check end-to-end connectivity.

EVPN Designs: VXLAN Leaf-and-Spine Fabric

In this series of blog posts, we’ll explore numerous routing protocol designs that can be used to implement EVPN-with-VXLAN L2VPNs in a leaf-and-spine data center fabric. Every design will come with a companion netlab topology you can use to create a lab and explore the behavior of leaf- and spine switches.

Our leaf-and-spine fabric will have four leaves and two spines (but feel free to adjust the lab topology fabric parameters to build larger fabrics). The fabric will provide layer-2 connectivity to orange and blue VLANs. Two hosts will be connected to each VLAN to check end-to-end connectivity.

Using wemulate with netlab

An RSS hiccup brought an old blog post from Urs Baumann into my RSS reader. I’m always telling networking engineers that it’s essential to set up realistic WAN environments when testing distributed software, and wemulate (a nice tc front-end) seemed like a perfect match. Even better, it runs in a container – an ideal component for a netlab-generated virtual WAN network.

wemulate acts as a bump in the wire; it uses Linux bridges to connect two container interfaces. We’ll use it to introduce jitter into an IP subnet:

┌──┐   ┌────────┐   ┌──┐
│h1├───┤wemulate├───┤h2│
└──┘   └────────┘   └──┘                       
◄──────────────────────►
     192.168.33.0/24    

Using wemulate with netlab

An RSS hiccup brought an old blog post from Urs Baumann into my RSS reader. I’m always telling networking engineers that it’s essential to set up realistic WAN environments when testing distributed software, and wemulate (a nice tc front-end) seemed like a perfect match. Even better, it runs in a container – an ideal component for a netlab-generated virtual WAN network.

wemulate acts as a bump in the wire; it uses Linux bridges to connect two container interfaces. We’ll use it to introduce jitter into an IP subnet:

┌──┐   ┌────────┐   ┌──┐
│h1├───┤wemulate├───┤h2│
└──┘   └────────┘   └──┘                       
◄──────────────────────►
     192.168.33.0/24    

Repost: EBGP-Mostly Service Provider Network

Daryll Swer left a long comment describing how he designed a Service Provider network running in numerous private autonomous systems. While I might not agree with everything he wrote, it’s an interesting idea and conceptually pretty similar to what we did 25 years ago (IBGP without IGP, running across physical interfaces, with every router being a route-reflector client of every other router), or how some very large networks were using BGP confederations.

Just remember (as someone from Cisco TAC told me in those days) that “you might be the only one in the world doing it and might hit bugs no one has seen before.”

Repost: EBGP-Mostly Service Provider Network

Daryll Swer left a long comment describing how he designed a Service Provider network running in numerous private autonomous systems. While I might not agree with everything he wrote, it’s an interesting idea and conceptually pretty similar to what we did 25 years ago (IBGP without IGP, running across physical interfaces, with every router being a route-reflector client of every other router), or how some very large networks were using BGP confederations.

Just remember (as someone from Cisco TAC told me in those days) that “you might be the only one in the world doing it and might hit bugs no one has seen before.”

Public Videos: Service Insertion in EVPN Fabrics

In 2020, Lukas Krattiger ran a short webinar describing how to insert L4-L7 services into EVPN fabrics. The videos are now public, and you can view them without an ipSpace.net account.

BGP Labs: Advertise the Default Route

If you’re an Internet Service Provider running BGP with your customers, you might not want to send them the whole Internet routing table. Sending the regional prefixes and the default route is usually good enough.

BGP Labs: Advertise the Default Route

If you’re an Internet Service Provider running BGP with your customers, you might not want to send them the whole Internet routing table. Sending the regional prefixes and the default route is usually good enough.

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 table¹.

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 table¹.

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 🤦‍♂️

OSI Layers in Routing Protocols

Now and then, someone rediscovers that IS-IS does not run on top of CLNP or IP and claims that, therefore, it must be a layer-2 protocol. Even vendors’ documentation is not immune.

Interestingly, most routing protocols span the whole seven layers of the OSI stack, with some layers implemented internally and others offloaded to other standardized protocols.

OSI Layers in Routing Protocols

Now and then, someone rediscovers that IS-IS does not run on top of CLNP or IP and claims that, therefore, it must be a layer-2 protocol. Even vendors’ documentation is not immune.

Interestingly, most routing protocols span the whole seven layers of the OSI stack, with some layers implemented internally and others offloaded to other standardized protocols.

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:

Worth Reading: Things We Know about Network Queues

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.

Worth Reading: Things We Know about Network Queues

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.

Public Videos: Routing Protocol Convergence

All Routing Protocol Convergence videos from the How Networks Really Work webinar are now public. Enjoy!