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.
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.
This is how we described the interactions between routing protocol tables, RIB, and FIB in the ancient times:
Let’s use a simple BGP+OSPF network to illustrate what I’m talking about:
This is how we described the interactions between routing protocol tables, RIB, and FIB in the ancient times:
Let’s use a simple BGP+OSPF network to illustrate what I’m talking about:
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.
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.
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:
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 wondered 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:
The March 2024 Internet Protocol Journal has a lengthy article on the history and “future” of Ethernet that might be worth reading (although it’s short on details) if you weren’t around when it all started.
The March 2024 Internet Protocol Journal has a lengthy article on the history and “future” of Ethernet that might be worth reading (although it’s short on details) if you weren’t around when it all started.
Urs Baumann invited me to have a guest lecture in his network automation course, and so I had the privilege of being in lovely Rapperswil last week, talking about the basics of real-life network automation.
Urs published the video recording of the presentation on YouTube; hope you’ll like it, and if you don’t get too annoyed by the overly pushy ads, watch the other videos from his infrastructure-as-code course.
Urs Baumann invited me to have a guest lecture in his network automation course, and so I had the privilege of being in lovely Rapperswil last week, talking about the basics of real-life network automation.
Urs published the video recording of the presentation on YouTube; hope you’ll like it, and if you don’t get too annoyed by the overly pushy ads, watch the other videos from his infrastructure-as-code course.
The “should we use the same vendor for fabric spines and leaves?” discussion triggered the expected counterexamples. Here’s one:
I actually have worked with a few orgs that mix vendors at both spine and leaf layer. Can’t take names but they run fairly large streaming services. To me it seems like a play to avoid vendor lock-in, drive price points down and be in front of supply chain issues.
As always, one has to keep two things in mind:
The “should we use the same vendor for fabric spines and leaves?” discussion triggered the expected counterexamples. Here’s one:
I actually have worked with a few orgs that mix vendors at both spine and leaf layer. Can’t take names but they run fairly large streaming services. To me it seems like a play to avoid vendor lock-in, drive price points down and be in front of supply chain issues.
As always, one has to keep two things in mind:
One of my readers was building a private MPLS/VPN backbone and wondered whether they should use their public AS number or a private AS number for the backbone. Usually, it doesn’t matter; the deciding point was the way they want to connect to the public Internet:
We also plan to peer with multiple external ISPs to advertise our public IP space not directly from our PE routers but from dedicated Internet Routers, adding a firewall between our PEs and external Internet routers.
They could either run BGP between the PE routers, firewall, and WAN routers (see BGP as High-Availability Protocol for more details) or run BGP across a bump-in-the-wire firewall:
One of my readers was building a private MPLS/VPN backbone and wondered whether they should use their public AS number or a private AS number for the backbone. Usually, it doesn’t matter; the deciding point was the way they want to connect to the public Internet:
We also plan to peer with multiple external ISPs to advertise our public IP space not directly from our PE routers but from dedicated Internet Routers, adding a firewall between our PEs and external Internet routers.
They could either run BGP between the PE routers, firewall, and WAN routers (see BGP as High-Availability Protocol for more details) or run BGP across a bump-in-the-wire firewall:
In the Do We Still Need OSPF Areas and Summarization? I wrote this somewhat cryptic remark:
The routers advertising a summarized prefix should be connected by a path going exclusively through the part of the network with more specific prefixes. GRE tunnel also satisfies that criteria; the proof is left as an exercise for the reader.
One of my readers asked for a lengthier explanation, so here we go. Imagine a network with two areas doing inter-area summarization on /24 boundary:
In the Do We Still Need OSPF Areas and Summarization? I wrote this somewhat cryptic remark:
The routers advertising a summarized prefix should be connected by a path going exclusively through the part of the network with more specific prefixes. GRE tunnel also satisfies that criteria; the proof is left as an exercise for the reader.
One of my readers asked for a lengthier explanation, so here we go. Imagine a network with two areas doing inter-area summarization on /24 boundary:
Milan Zapletal submitted the source code for a huge lab topology they built with netlab. It has almost 50 routers and over 50 Linux nodes to emulate end-users and servers.
They used netlab to configure VLANs, VRFs, IS-IS, OSPF, EIGRP, BGP, MPLS, VXLAN, and EVPN. Imagine how long it would take to configure all that by hand using a more traditional labbing tool.
Milan Zapletal submitted the source code for a huge lab topology they built with netlab. It has almost 50 routers and over 50 Linux nodes to emulate end-users and servers.
They used netlab to configure VLANs, VRFs, IS-IS, OSPF, EIGRP, BGP, MPLS, VXLAN, and EVPN. Imagine how long it would take to configure all that by hand using a more traditional labbing tool.