Category: BGP
BGP Labs: EBGP Sessions over IPv6 LLA Interfaces
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.
![](https://bgplabs.net/basic/topology-interface-ebgp.png)
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.
![](https://bgplabs.net/challenge/topology-mpls-core.png)
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.
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.”
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.
![](https://bgplabs.net/basic/topology-default-route.png)
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 🤦♂️
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:
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.
… updated on Friday, May 17, 2024 11:25 +0200
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 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:
BGP AS Numbers for a Private MPLS/VPN Backbone
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:
BGP Labs: Limit the Number of Accepted BGP Prefixes
Here’s an easy way to stop fat-finger incidents in which an end-user autonomous system redistributes IGP into BGP or advertises the whole DFZ routing table from affecting the entire Internet: limit the number of BGP prefixes your routers accept from your customers. You can practice this nifty feature in the next BGP lab exercise.
![](https://bgplabs.net/basic/topology-max-prefix.png)
BGP Labs: Policy Templates
One of the previous BGP labs explained how you can use session templates to configure common TCP or BGP session parameters. Some BGP implementations have another templating mechanism: policy templates that you can use to apply consistent routing policy parameters to an EBGP neighbor. You can practice them in the next BGP lab exercise.
![](https://bgplabs.net/session/topology-policy-template.png)
BGP Labs: Remove Private AS from AS-Path
In a previous BGP lab exercise, I described how an Internet Service Provider could run BGP with a customer without the customer having a public BGP AS number. The only drawback of that approach: the private BGP AS number gets into the AS path, and everyone else on the Internet starts giving you dirty looks (or drops your prefixes).
![](https://bgplabs.net/session/topology-removeprivate.png)
Let’s fix that. Most BGP implementations have some remove private AS functionality that scrubs AS paths during outgoing update processing. You can practice it in the Remove Private BGP AS Numbers from the AS Path lab exercise.
Applying BGP Policy Templates
I got this question after publishing the BGP Session Templates lab exercise:
Would you apply BGP route maps with a peer/policy template or directly to a BGP neighbor? Of course, it depends; however, I believe in using a template for neighbors with the same general parameters and being more specific per neighbor when it comes to route manipulation.
As my reader already pointed out, the correct answer is It Depends, now let’s dig into the details ;)
BGP Labs: Session Templates
Configuring an IBGP session on a route reflector takes a half-dozen parameters, starting with the remote BGP AS number (equal to the local one), remote IP address, and the source IP address or interface. You might have to specify the propagation of BGP communities and an MD5 password, and you will definitely have to specify that the BGP neighbor is a route reflector client.
Wouldn’t it be nice if you could group those parameters into a template and apply the template to a neighbor? Most BGP implementations have something along those lines. That feature could be called a session template or a peer group, and you can practice it in the next BGP lab exercise.
![](https://bgplabs.net/session/topology-session-templates.png)