Category: BGP

In the next BGP labs exercise, you can practice tweaking BGP timers and using BFD to speed up BGP convergence.

I published another BGP labs exercise a few days ago. You can use it to practice EBGP session protection, including Generalized TTL Security Mechanism (GTSM) and TCP MD5 checksums¹.

In the next BGP labs exercise, you’ll build the customer part of an MPLS/VPN solution. You’ll use bidirectional OSPF-to-BGP route redistribution to connect two sites running OSPF over a Service Provider MPLS backbone.

Talking about BGP routing policy mechanisms is nice, but it’s even better to see how real Internet Service Providers use those tools to implement real-life BGP routing policy.

Getting that information is incredibly hard as everyone considers their setup a secret sauce. Fortunately, there are a few exceptions; Pim van Pelt described the BGP Routing Policy of IPng Networks in great details. The article is even more interesting as he’s using Bird2 configuration language that looks almost like a programming language (as compared to the ancient route-maps used by vendors focused on “industry-standard” CLI).

Have fun!

The first set of BGP labs covered the basics; the next four will help you master simple routing policy tools (BGP weights, AS-path filters, prefix filters) using real-life examples:

• Use BGP weights to prefer one of the upstream providers
• Prevent route leaking between upstream providers with an AS-path filter
• Filter prefixes advertised by your autonomous system with a prefix list
• Minimize the size of your BGP table with inbound filters

The labs are best used with netlab (it supports BGP on almost 20 different devices), but you could use any system you like (including GNS3 and CML/VIRL). For more details, read the Installation and Setup documentation.

The first BGP labs are online. They cover the basic stuff (one has to start with the basics, right?):

• Configuring an EBGP session
• Connecting to multiple upstream ISPs
• Advertise your prefixes
• Configure BGP for IPv6

The labs are supposed to be run on virtual devices, but if you’re stubborn enough it’s possible to make them work with the physical gear. In theory, you could use any system you like to set up the virtual lab (including GNS3 and CML/VIRL), but your life will be way easier if you use netlab – it supports BGP on almost 20 different devices. For more details, read the Installation and Setup documentation.

Emile Aben is describing an interesting behavior observed in the Wild West of the global Internet: someone started announcing BGP paths with an unknown attribute, which (regardless of RFC 7606) triggered some BGP session resets.

One would have hoped we learned something from the August 2010 incident (supposedly caused by a friend of mine 😜), but it looks like some things never change. For more details, watch the Network Security Fallacies and Internet Routing Security webinar.

Ignas Bagdonas sent a phenomenal summary of recent BGP developments to the RIPE Routing WG mailing list. Enjoy!

An anonymous commenter asked this highly relevant question about my Internet routing security lab:

What are the smallest hardware requirements to run the lab?

TL&DR: 2 GB RAM, 2 vCPU

Now for the more precise answer (aka “it depends”).

I created a netlab topology you can use to practice BGP security tools I described in the Internet Routing Security webinar:

• The lab topology mirrors the sample topology I described in the Classification of BGP Route Leaks (RFC 7908) blog post with one router per autonomous system
• BGP is configured on all devices, and EBGP sessions are set up between all directly-connected devices.

Andrei Robachevsky asked me to spread the word about the new MANRS+ customer survey:

MANRS is conducting a survey for organizations that contract connectivity providers to learn more about if and how routing security fits into their broader supply chain security strategy. If this is your organization, or if it is your customers, we welcome you to take or share the survey at https://www.surveymonkey.com/r/BDCWKNS

I hope you immediately clicked on the link and completed the survey. If you’re still here wondering what’s going on, here’s some more information from Andrei:

While preparing the Internet Routing Security webinar, I stumbled upon RFC 7908, containing an excellent taxonomy of BGP route leaks. I never checked whether it covers every possible scenario¹, but I found it a handy resource when organizing my thoughts.

Let’s walk through the various leak types the authors identified using the following sample topology:

One of the most common causes of Internet routing leaks is an undereducated end-customer configuring EBGP sessions with two (or more) upstream ISPs.

Without basic-level BGP knowledge or further guidance from the service providers, the customer network engineer¹ might start a BGP routing process and configure two EBGP sessions, similar to the following industry-standard CLI² configuration:

Nicola Modena had an interesting presentation describing how you can use BGP FlowSpec for traffic steering and service insertion during the recent ITNOG 7 event (more about the event in a few days).

One of the slides explained how to use three different aspects of BGP (FlowSpec, MPLS/VPN and multipathing), prompting me to claim the presentation title should be “BGP is the answer, what was the question?” 😉 Hope you’ll enjoy the PDF version of the presentation as much as we did the live one.

When I reposted a link to xBGP: Faster Innovation in Routing Protocols paper, someone immediately replied

Quite interesting, but it feels like this could become the proverbial 15th standard.

xBGP is an API that allows BGP users to implement routing policies (route selection, filtering, or propagation) that use attributes or mechanisms defined in newer IETF RFCs or drafts, so the proverbial 15th standard is not that far off the mark. However, we must remember that what we call BGP is more than just a set of competing standards.