Category: BGP

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.

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).

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.

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 ;)

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.

One of the few beauties of most “industry standard CLI” implementations¹ is that they’re idempotent: nothing changes (apart from ACLs) if you configure the same stuff a dozen times. Most of these implementations allow you to deconfigure the same stuff multiple times; FRRouting is one of the unfortunate exceptions.

What Am I Talking About?

Imagine you have a bunch of IP prefixes you want to advertise with BGP. You could use network statements within the router bgp configuration to get that done:

Can you use BGP to connect to the global Internet without having a public BGP AS number? Of course, assuming your Internet Service Provider is willing to run BGP with a network using a private AS number. But what happens if you want to connect to two ISPs? It’s ridiculous to expect you’ll be able to persuade them to use the same private AS number.

That’s one of the many use cases for the local-as functionality available in most BGP implementations. You can practice it in the Use Multiple AS Numbers on the Same Router lab exercise.

When I described the need to turn off the BGP AS-path loop prevention logic in scenarios where a Service Provider expects a customer to reuse the same AS number across multiple sites, someone quipped, “but that should be fixed by the Service Provider, not offloaded to the customer.”

Not surprisingly, there’s a nerd knob for that (AS override), and you can practice it in the next BGP lab exercise: Fix AS-Path in Environments Reusing BGP AS Numbers.

FRR or (pre-NVUE) Cumulus Linux are the best bets if you want to run BGP labs in a resource-constrained environment like your laptop or a small public cloud instance. However, they both behave a bit differently from what one might expect from a networking device, including:

• Interfaces are created through standard Linux tools;
• You have to start the FRR management CLI from the Linux shell;
• If you need a routing daemon (for example, the BGP daemon), you must enable it in the FRR configuration file and restart FRR.

A new lab exercise covers these intricate details and will help you get fluent in configuring BGP on FRR or Cumulus Linux virtual machines or containers.

A networking engineer with a picture-perfect implementation of a dual-homed enterprise site using BGP communities according to RFC 1998 to select primary- and backup uplinks contacted me because they experienced unacceptably long failover times.

They measured the failover times caused by the primary uplink loss and figured out it takes more than five minutes to reestablish Internet connectivity to their site.

When I published the Bidirectional Route Redistribution lab exercise, some readers were quick to point out that you’ll probably have to reuse the same AS number across multiple sites in a real-life MPLS/VPN deployment. That’s what you can practice in today’s lab exercise – an MPLS/VPN service provider allocated the same BGP AS number to all your sites and expects you to deal with the aftermath.

It’s that time of the year when we create unreachable goals and make empty promises to ourselves (or others) that we subconsciously know we’ll fail.

I tried to make that process a bit more structured and create external storage for my lab ideas – I started publishing more details on future BGP lab scenarios. The lab descriptions contain a high-level overview of the challenge and the lab topology; the details will be filled in later.

Want to know what’s coming in 2024? Check out the Upcoming Labs page of the BGP Labs project.

Here’s a challenge in case you get bored during the Christmas break: merge two networks running BGP (two autonomous systems) without changing anything but the configurations of the routers connecting them (the red BGP session in the diagram). I won’t give you any hints; you can discuss it in the comments or a GitHub discussion.

Hopefully, you won’t have to deal with something similar in real life, but then we know that crazy requirements trump good designs any day of the week.

A previous BGP lab focused on the customer side of BGP communities: adding them to BGP updates to influence upstream ISP behavior. Today’s lab focuses on the ISP side of the equation: using BGP communities in a routing policy to implement RFC 1998-style behavior.

In the previous BGP labs, we built a network with two adjacent BGP routers and a larger transit network using IBGP. Now let’s make our transit network scalable with BGP route reflectors, this time using a slightly larger network:

Kristijan Taskovski asked an interesting question related to my BGP AS-prepending lab:

I’ve never personally done this on the net but….wouldn’t the BGP origin code also work with moving one’s ingress traffic similarly to AS PATH?

TL&DR: Sort of, but not exactly. Also, just because you can climb up ropes using shoelaces instead of jumars doesn’t mean you should.

Let’s deal with the moving traffic bit first.