Category: BGP

In the previous labs, we used BGP weights and Local Preference to select the best link out of an autonomous system and thus change the outgoing traffic flow.

Most edge (end-customer) networks face a different problem – they want to influence the incoming traffic flow, and one of the tools they can use is BGP Multi-Exit Discriminator (MED).

A while ago, we used BGP weights to select the best link out of an autonomous system. In this lab, we’ll use BGP local preference to implement a consistent network-wide routing policy:

A while ago, the Networking Notes blog published a link to my “Will Network Devices Reject BGP Sessions from Unknown Sources?” blog post with a hint: use Shodan to find how many BGP routers accept a TCP session from anyone on the Internet.

The results are appalling: you can open a TCP session on port 179 with over 3 million IP addresses.

In 2022, I was invited to speak about Internet routing security at the DEEP conference in Zadar, Croatia. One of the main messages of the presentation was how slow the progress had been even though we had had all the tools available for at least a decade (RFC 7454 was finally published in 2015, and we started writing it in early 2012).

At about that same time, a small group of network operators started cooperating on improving the security and resilience of global routing, eventually resulting in the MANRS initiative – a great place to get an overview of how many Internet Service Providers care about adopting Internet routing security mechanisms.

At least some people learn from others’ mistakes: using the concepts proven by some well-publicized BGP leaks, malicious actors quickly figured out how to hijack BGP prefixes for fun and profit.

Fortunately, those shenanigans wouldn’t spread as far today as they did in the past – according to RoVista, most of the largest networks block the prefixes Route Origin Validation (ROV) marks as invalid.

Notes:

• ROV cannot stop all the hijacks, but it can identify more-specific-prefixes hijacks (assuming the origin AS did their job right).
• You’ll find more Network Security Fallacies videos in the How Networks Really Work webinar.

Last time we built a network with two adjacent BGP routers. Now let’s see what happens when we add a core router between them:

Almost exactly a decade ago I wrote about a paper describing how IBGP migrations can cause forwarding loops and how one could reorder BGP reconfiguration steps to avoid them.

One of the paper’s authors was Laurent Vanbever who moved to ETH Zurich in the meantime where his group keeps producing great work, including the Chameleon tool (code on GitHub) that can tame transient loops while reconfiguring BGP. Definitely something worth looking at if you’re running a large BGP network.

My good friend Tiziano Tofoni finally created an English version of his evergreen classic BGP from theory to practice with co-authors Antonio Prado and Flavio Luciani.

I had the Italian version of the book since the days I was running SDN workshops with Tiziano in Rome, and it’s really nice to see they finally decided to address a wider market.

Also, you know what would go well with that book? Free open-source BGP configuration labs of course 😉

Here’s a quick update on the BGP Labs project status: now that netlab release 1.6.4 is out, I could remove the dependency on using Cumulus Linux as the external BGP router.

You can use any device that is supported by bgp.session and bgp.policy plugins as the external BGP router. You could use Arista EOS, Aruba AOS-CX, Cisco IOSv, Cisco IOS-XE, Cumulus Linux or FRR as external BGP routers with netlab release 1.6.4, and I’m positive Jeroen van Bemmel will add Nokia SR Linux to that list.

If you’re not ready for a netlab upgrade, you can keep using Cumulus Linux as external BGP routers (I’ll explain the behind-the-scenes magic in another blog post, I’m at the Deep Conference this week).

For more details, read the updated BGP Labs Software Installation and Lab Setup guide.

I’ll be talking about Internet routing security at the Deep conference in a few days, and just in case you won’t be able to make it¹ ;) here’s the first bit of my talk: a very brief history of BGP route leaks².

Note: you’ll find more Network Security Fallacies videos in the How Networks Really Work webinar.

After going through the BGP basics, it’s time to build a network that has more than one BGP router in it, starting with the simplest possible topology: a site with two WAN edge routers.

TL&DR: Violating the Betteridge’s Law of Headlines, the answer is “Yes, but the devil is in the details.”

It all started with the following observation by Minh Ha left as a comment to my previous BGP session security blog post:

I’d think it’d be obvious for BGP routers to only accept incoming sessions from configured BGP neighbors, right? Because BGP is the most critical infrastructure, the backbone of the Internet, why would you want your router to accept incoming session from anyone but KNOWN sources?

Following my “opinions are good, facts are better” mantra, I decided to run a few tests before opinionating¹.

A few days after I published the EBGP session protection lab, Jeroen van Bemmel submitted a pull request that added TCP-AO support to netlab. Now that the release 1.6.3 is out, I could use it to build the Protect BGP Sessions with TCP Authentication Option (TCP-AO) lab exercise.

In the BGP Route Aggregation lab you can practice:

• OSPF-to-BGP route redistribution
• BGP route aggregation
• Suppression of more-specific prefixes in the BGP table
• Prefix-based filtering of outbound BGP updates

A while ago I explained how Generalized TTL Security Mechanism could be used to prevent denial-of-service attacks on routers running EBGP. Considering the results published in Analyzing the Security of BGP Message Parsing presentation from DEFCON 31 I started wondering how well GTSM implementations work.

TL&DR summary: