Here’s another BGP lab challenge to start your weekend: use RIB-to-FIB filters to reduce the forwarding table size on access routers in a large Service Provider network.
Here’s another BGP lab challenge to start your weekend: use RIB-to-FIB filters to reduce the forwarding table size on access routers in a large Service Provider network.
Craig Weinhold pointed me to a complex topic I managed to ignore in my MLAG Deep Dive series: how does an MLAG cluster reroute around a failure of a LAG member link?
In this blog post, we’ll focus on traditional MLAG cluster implementations using a peer link; another blog post will explore the implications of using VXLAN and EVPN to implement MLAG clusters.
We’ll also ignore the interesting question of “how is the LAG member link failure detected?”1 and focus on “what happens next?” using the sample MLAG topology:
Craig Weinhold pointed me to a complex topic I managed to ignore in my MLAG Deep Dive series: how does an MLAG cluster reroute around a failure of a LAG member link?
In this blog post, we’ll focus on traditional MLAG cluster implementations using a peer link; another blog post will explore the implications of using VXLAN and EVPN to implement MLAG clusters.
We’ll also ignore the interesting question of “how is the LAG member link failure detected?”1 and focus on “what happens next?” using the sample MLAG topology:
Erik Auerswald pointed me to an interesting open-source project. LibreQoS implements decent QoS using software switching on many-core x86 platforms. It’s implemented as a bump-in-the-wire software solution, so you should be able to plug it into your network just before a major congestion point and let it handle the packet dropping and prioritization.
Obviously, the concept is nothing new. I wrote about a similar problem in xDSL networks in 2009.
Erik Auerswald pointed me to an interesting open-source project. LibreQoS implements decent QoS using software switching on many-core x86 platforms. It’s implemented as a bump-in-the-wire software solution, so you should be able to plug it into your network just before a major congestion point and let it handle the packet dropping and prioritization.
Obviously, the concept is nothing new. I wrote about a similar problem in xDSL networks in 2009.
You might remember Béla Várkonyi’s use of LISP to build resilient ground-to-airplane networks from last week’s repost. It seems he’s not exactly happy with the current level of LISP support, at least based on what he wrote as a response to Jeff McLaughlin’s claim that “I can tell you that our support for EVPN does not, in any way, indicate the retirement of LISP for SD-Access.”:
Nice to hear the Cisco intends to support LISP. However, it is removed from IOS XR already. So it is not that clear…
If Cisco will stop supporting LISP, then we will be forced to create our own LISP routers, since we need it for extreme mobility environments.
You might remember Béla Várkonyi’s use of LISP to build resilient ground-to-airplane networks from last week’s repost. It seems he’s not exactly happy with the current level of LISP support, at least based on what he wrote as a response to Jeff McLaughlin’s claim that “I can tell you that our support for EVPN does not, in any way, indicate the retirement of LISP for SD-Access.”:
Nice to hear the Cisco intends to support LISP. However, it is removed from IOS XR already. So it is not that clear…
If Cisco will stop supporting LISP, then we will be forced to create our own LISP routers, since we need it for extreme mobility environments.
Some networking vendors realized that one way to gain mindshare is to make their network operating systems available as free-to-download containers or virtual machines. That’s the right way to go; I love their efforts and point out who went down that path whenever possible1 (as well as others like Cisco who try to make our lives miserable).
However, those virtual machines better work out of the box, or you’ll get frustrated engineers who will give up and never touch your warez again, or as someone said in a LinkedIn comment to my blog post describing how Junos vPTX consistently rejects its DHCP-assigned IP address: “If I had encountered an issue like this before seeing Ivan’s post, I would have definitely concluded that I am doing it wrong.”2
Some networking vendors realized that one way to gain mindshare is to make their network operating systems available as free-to-download containers or virtual machines. That’s the right way to go; I love their efforts and point out who went down that path whenever possible1 (as well as others like Cisco who try to make our lives miserable).
However, those virtual machines better work out of the box, or you’ll get frustrated engineers who will give up and never touch your warez again, or as someone said in a LinkedIn comment to my blog post describing how Junos vPTX consistently rejects its DHCP-assigned IP address: “If I had encountered an issue like this before seeing Ivan’s post, I would have definitely concluded that I am doing it wrong.”2
Daniel Dib started writing a series of blog posts describing Cisco vPC in VXLAN/EVPN Networks. The first one covers the anycast gateway, the second one the vPC configuration.
Let’s hope he will keep them coming and link them together so it will be easy to find the whole series after stumbling on one of the posts ;)
Daniel Dib started writing a series of blog posts describing Cisco vPC in VXLAN/EVPN Networks. The first one covers the anycast VTEP, the second one the vPC configuration.
Let’s hope he will keep them coming and link them together so it will be easy to find the whole series after stumbling on one of the posts ;)
When I decided to sunset the ipSpace.net subscription, I asked Rachel Traylor whether I could make the content of her webinars public. She graciously agreed, and the first results are already here: you can download approximately half of the videos from the Network Connectivity and Graph Theory without a valid ipSpace.net account. Enjoy!
If you insist on building your network with EBGP as a better IGP, make sure your implementation supports running IPv4 and IPv6 address families over EBGP sessions established between IPv6 link-local addresses (the functionality lovingly called unnumbered EBGP sessions).
Want to practice that neat trick? Check out the EBGP Sessions over IPv6 LLA Interfaces lab exercise.
If you insist on building your network with EBGP as a better IGP, make sure your implementation supports running IPv4 and IPv6 address families over EBGP sessions established between IPv6 link-local addresses (the functionality lovingly called unnumbered EBGP sessions).
Want to practice that neat trick? Check out the EBGP Sessions over IPv6 LLA Interfaces lab exercise.
Béla Várkonyi is working on an interesting challenge: building ground-to-airplane(s) networks providing multilink mobility. Due to its relative simplicity, he claims LISP works much better than BGP in that environment.
In some newer routers BGP would not be such a big bottleneck, but you need a lot of knob turning in BGP to get it right, while in LISP it is quite simple.
If you have many thousands concurrent airplanes with multi-link and max. 16 subnets with different routing policies on each, and the radio links are going up and down, then you have a large number of mobility events.
Béla Várkonyi is working on an interesting challenge: building ground-to-airplane(s) networks providing multilink mobility. Due to its relative simplicity, he claims LISP works much better than BGP in that environment.
In some newer routers BGP would not be such a big bottleneck, but you need a lot of knob turning in BGP to get it right, while in LISP it is quite simple.
If you have many thousands concurrent airplanes with multi-link and max. 16 subnets with different routing policies on each, and the radio links are going up and down, then you have a large number of mobility events.
When designing the netlab VRF configuration module, I tried to make it as flexible as possible while using the minimum number of awkward nerd knobs. As is often the case1, the results could be hard to grasp, so let’s walk through the various scenarios of using global and node VRFs.
netlab allows you to define a VRF in the lab topology vrfs dictionary (global VRF) or in a node vrfs dictionary (node VRF). In most cases, you’d define a few global VRFs and move on.
When designing the netlab VRF configuration module, I tried to make it as flexible as possible while using the minimum number of awkward nerd knobs. As is often the case1, the results could be hard to grasp, so let’s walk through the various scenarios of using global and node VRFs.
netlab allows you to define a VRF in the lab topology vrfs dictionary (global VRF) or in a node vrfs dictionary (node VRF). In most cases, you’d define a few global VRFs and move on.
You probably know I hate posting links to walled gardens or sites that try really hard to make you sign up. Sometimes, I have to make an exception: Roman Pomazanov wrote a great (and humorous) article comparing how easy it is to set up simple labs with GNS3, containerlab, and netlab.