BGP Routing: An In-Depth Tutorial and Examples

Learn the essentials of BGP routing with our comprehensive tutorial and examples. From autonomous systems, routes, peering, and BGP configuration, our four-part tutorial provides key insights into how BGP can improve network performance and security.

What is BGP Routing?

BGP routing (Border Gateway Protocol routing) is a fundamental component of the internet infrastructure that establishes and controls data paths across the internet. BGP is a policy-based routing protocol that ensures the efficient and reliable transfer of data packets across different autonomous systems (AS) on the internet. Each autonomous system, representing a distinct network, uses BGP to advertise its network reachability information to other systems, essentially informing them about the routes data packets can take to reach specific destinations within the network.

BGP routing involves key elements like autonomous systems, routes, border routers, and peering. Here’s a brief explanation of these components:

1. Autonomous Systems (AS): An AS is a network or a collection of connected IP routing prefixes under the control of one or multiple network operators that present a common routing policy to the internet.

2. Routes: A route in BGP is a path that data packets take from one host on the internet to another. Routes are known as Network Layer Reachability Information (NLRI).

3. Border Routers: These are routers situated at the edge of an AS, responsible for connecting to at least one router from a different AS and advertising routes through peering sessions.

4. Peering: Peering is the reciprocal data exchange between two different ASs through their border routers. Peering ensures data packets find their way to the right destination.

BGP routing plays a pivotal role in determining the most optimal path for data transmission across the internet, contributing to the efficiency and integrity of the global internet.

Ultimate Guide to BGP Routing

An effective BGP configuration is pivotal to controlling your organization’s destiny on the internet. Learn the basics and evolution of BGP.

Get Your Copy

BGP Routing Tutorial Part 1 - BGP Basics: Routes, Peers, and Paths

In Part 1 of this BGP Routing Tutorial, we lay down the fundamental concepts of the Border Gateway Protocol (BGP). This policy-based routing protocol forms the backbone of the internet infrastructure. The tutorial explores why understanding BGP is crucial for controlling your organization’s destiny on the internet, leading to several key benefits, such as revenue growth, infrastructure uptime, and enhanced security. Key concepts introduced include Autonomous Systems (AS), routes, peering, and AS_PATH.

We also detail how routes are created and advertised, leading to the formation of the global routing table and the role of eBGP and iBGP in this process. Finally, we delve into the importance and use cases of the AS_PATH attribute, including loop detection and setting policy. This foundational knowledge sets the stage for future, more in-depth discussions about BGP and its role in network connectivity.

BGP History and Evolution

Designed before the dawn of the commercial internet, Border Gateway Protocol (BGP) is a policy-based routing protocol that has long been an established part of the internet infrastructure. In fact, I wrote a series of articles about BGP, internet connectivity, and multi-homing back in 1996, and more than two decades later, the core concepts remain basically the same. There have been a few changes at the edge (which we’ll cover later). Still, these have been implemented as the designers anticipated by adding “attributes” to the BGP specification and implementations. In general, BGP’s original design still holds today, including its strengths (describing and enforcing policy) and weaknesses (lack of authentication or verification of routing claims).

Why You Should Understand BGP

Why is an understanding of BGP helpful in understanding internet connectivity and interconnectivity? Because effective BGP configuration is part of controlling your organization’s destiny on the internet. And that can benefit your organization in several key areas:

• Preserve and grow revenue.
• Protect the availability and uptime of your infrastructure and applications.
• Use the economics of the internet to your advantage.
• Protect against the global security risks that can arise when internet operators don’t agree on how to address security problems.

BGP and internet connectivity is a big subject, so this article has a lot of ground to cover. The following list will give you a sense of the range of the topics we’ll be looking at:

• The structure and state of the internet
• How BGP has evolved and what its future might hold
• DDoS detection and prevention
• Additional topics such as MPLS and global networking, internal routing protocols and applications, and other topics

Let’s first get our feet wet with some basic concepts related to BGP: Autonomous Systems, routes, peering, and AS_PATH.

Routes, Autonomous Systems (ASes), and Autonomous System Numbers (ASNs)

What is a BGP Route?

To fully understand BGP, we’ll first get familiar with some underlying concepts, starting with what it means to be connected to the internet. For a host to be connected, there must be a path or “route” over which it is possible for you to send a packet that will ultimately wind up at that host and for that host to have a path over which to send a packet back to you.

That means that the provider of internet connectivity to that host has to know of a route to you. They must have a way to see routes in the section of the IP space that you are using. For reasons of enforced obfuscation by RFC writers, routes are also called Network Layer Reachability Information (NLRI).

As of May 2023, there are over 940,000 IPv4 routes and more than 182,000 IPv6 routes.

What are Autonomous Systems (ASes) and Autonomous System Numbers (ASNs)?

Another foundational concept is the Autonomous System (AS), which is a way of referring to some specific network. That network could be yours or belong to any other enterprise, service provider, or nerd with her own network. Each network on the internet is referred to as an AS, and each AS has at least one Autonomous System Number (ASN). There are tens of thousands of ASNs in use on the internet. Normally the following elements are associated with each AS:

• An entity (a point of contact, typically called a NOC or Network Operations Center) that is responsible for the AS.
• An internal routing scheme so every router in a given AS knows how to get to every other router and destination within the same AS. This would typically be accomplished with an interior gateway protocol (IGP) such as Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS).
• One or multiple border routers. A border router is a router that is configured to peer with a router in a different AS, meaning that it creates a TCP session on port 179 and maintains the connection by sending a keep-alive message every 60 seconds. This peering connection is used by border routers in one AS to “advertise” routes to border routers in a different AS (more on this below).

BGP (Border Gateway Protocol): The Internet’s Routing Protocol

As explained previously, the interconnections that are created to carry traffic from and between Autonomous Systems result in the creation of “routes” (paths from one host to another). Each route is made up of the ASN of every AS in the path to a given destination AS. BGP (more explicitly, BGPv4) is the routing protocol that is used by your border routers to “advertise” these routes to and from your AS to the other systems that need them in order to deliver traffic to your network:

• Peer networks, which are the ASs with which you’ve established a direct reciprocal connection
• Upstream or transit networks, which are the providers that connect you to other networks

Route Advertisements

Specifically, your border routers advertise routes to the portions of the IPv4 and IPv6 address space that you and your customers are responsible for and know how to get to, either on or through your network. Advertising routes that “cover” (include) your network is what enables other networks to “hear” a route to the hosts within your network. In other words, every IP address that you can get to on the internet is reachable because someone, somewhere, has advertised a route that covers it. If there is not a generally advertised route to cover an IP address, then at least some hosts on the internet will not be able to reach it.

The advertising of routes helps a network operator do two very important things. One is to make semi-intelligent routing decisions concerning the best path for a particular route to take outbound from your network. Otherwise, you would simply set a default route from your border routers into your providers, which might cause some of your traffic to take a sub-optimal external route to its destination. Second, and more importantly, you can announce your routes to those providers for them to announce in turn to others (transit) or just use internally (in the case of peers).

In addition to their essential role in getting traffic to its destination, advertised routes are used for several other important purposes:

• To help track the origin and path of network traffic
• To enable policy enforcement and traffic preferences
• To avoid creating routing (and thus packet) loops

The Global Routing Table

Besides being used to advertise routes, BGP is also used to listen to the routes from other networks. The sum of all of the route advertisements from all of the networks on the internet contributes to the “global routing table,” which is the internet’s packet directory system. If you have one or more transit providers, you will usually be able to hear that full list of routes.

One further complication: BGP actually comes in two flavors depending on what it’s used for:

• External BGP (eBGP) is the form used when routers that aren’t in the same AS advertise routes to one another. From here on out, you can assume that, unless otherwise stated, we’re talking about BGP.
• Internal BGP (iBGP) is used between routers within the same AS.

The AS_PATH attribute

BGP supports a number of attributes, the most important of which is AS_PATH. Every time a route is advertised by one BGP router to another over a peering session, the receiving router prepends the remote ASN to this attribute. For example, when Verizon hears a route from NTT America, Verizon “stamps” the incoming route with NTT’s ASN, thereby building the route in AS_PATH. (Note that when a route is advertised between routers in the same AS, using iBGP, the ASN for both routers is the same, and so AS_PATH is left unchanged.)

When multiple routes are available, remote routers will generally decide which is the best route by picking the route with the shortest AS_PATH, meaning the route that will traverse the fewest ASes to get traffic to a given destination AS. That may or may not be the fastest route, however, because there’s no information about the network represented by a given AS — nothing about that network’s bandwidth, the number of internal routers and hop count, or how congested it is. From the standpoint of BGP, every AS is pretty much the same.

Additional uses for AS_PATH include:

• Loop detection: When a border router receives a BGP update (path advertisement) from its peers, it scans the AS_PATH attribute for its own ASN. If found, the router will ignore the update and will not advertise it further to its iBGP neighbors. This precaution prevents the creation of routing loops.
• Setting policy: BGP allows providers to express “policy” decisions, such as preferring Verizon over NTTA to get to Comcast.
• Visibility: AS_PATH provides a way to understand where your traffic is going and how it gets there.

Key BGP Terms from Part 1

So far, we’ve just scratched the surface of BGP, but we’ve learned a few core concepts that will serve as a foundation for future exploration:

• Internet connectivity: The ability of a given host to send packets across the internet to a different host and to receive packets back from that host.
• Autonomous System (AS): A network that is connected to other networks on the internet and has a unique AS number (ASN).
• Route: The path traveled by traffic between Autonomous Systems.
• Border router: A router that is at the edge of an AS and connects to at least one router from a different AS.
• Peering: A direct connection between the border routers of two different ASs in which each router advertises the routes of its AS.
• eBGP: The protocol used by border routers to advertise routes.
• AS_PATH: The BGP attribute used to specify routes.

Next, we’ll go deeper into the uses and implications of the above concepts. We’ll also look at single-homed and multi-homed networks, how using BGP changes the connectivity between a network and the internet, and who can benefit from using BGP. When we’ve got those topics down, we can then look at the ins and outs of BGP configuration.

BGP Routing Tutorial Part 2 - More BGP Basics: Advertising, Homing, and Cardinal Sins

In the second part of our BGP routing tutorial, we delve further into the intricacies of Border Gateway Protocol (BGP) — the system that directs traffic across the interconnected Autonomous Systems (AS) making up the internet. This section explores how routes are advertised and the important distinction between single- and multi-homed networks. It illustrates the practical value of BGP, especially for multi-homed networks or networks with multiple connections to a single internet Service Provider (ISP). The tutorial also stresses the importance of proper BGP configuration, as mistakes can have wide-ranging and disruptive impacts across the internet. Finally, the article warns against the cardinal sins of BGP routing, namely “route hijacking” or “blackholing” and insufficient filtering, while offering advice to avoid such pitfalls.

In part 1 of this tutorial, we established that BGP is the protocol used to route traffic across the interconnected Autonomous Systems (AS) that make up the internet. We also looked at why effective BGP configuration is an important part of controlling your destiny on the internet, and we covered some of the basic building-block concepts needed to understand what BGP does and how it does it. We’ll continue on that path in this section, adding more concepts and digging deeper into how BGP works and what makes it of value.

How Advertising Routes Work in BGP

The core function of BGP is to provide a mechanism through which any Autonomous System — a network connected to the internet — can get traffic to any other AS. As discussed in Part 1, the path traveled by traffic is referred to as a route, and BGP is the protocol by which one “advertises” to the internet the routes available to get traffic to your AS.

One way of thinking about the BGP routes that you advertise to other entities is as promises to carry data to the IP space represented by the advertised route. For example, if you advertise 192.204.4.0/24 (in class C terms, the block starting at 192.204.4.0 and ending at 192.204.4.255), you promise that you know how to carry to its ultimate destination, data that is destined for any address in 192.204.4.0/24.

Single-homed vs. Multi-homed Networks

Another important BGP-related concept is “single-homed” versus “multi-homed,” which is a major determinant of who uses BGP and who doesn’t:

• Single-homed means that you have only one upstream provider giving your network transit to the rest of the internet.
• multi-homed means that you connect to multiple providers to provide transit to the rest of the world.

When you’re single-homed, you usually won’t want to use BGP for your upstream providers because you only have one path out of your network. So filling your router with 500,000+ BGP routes isn’t going to do you any good since all of those routes point to the same place (your one upstream provider). You can get the same result much more simply by using a “default route” to point all packets that aren’t otherwise matched in your internal routing table to your upstream provider.

Also, if you have one upstream provider, it’s almost guaranteed that your IP space is a sub-allocation (CIDR delegation, to be precise) of their larger IP blocks (aggregates). So you won’t be advertised to the outside world specifically. Instead, your provider will just advertise the overall block. If you have any other networks (e.g., an old Class C, customers with address space, etc.), then your provider will statically announce those routes to the world and statically route them inside their network to your router interface(s). So even if you did advertise to your provider the routes to your IP space, they’re not going to re-advertise them to the rest of the world because there already is a route to your provider for one of the larger aggregates of address space that you are inside of.

Despite the above, there is one circumstance where you might wind up using BGP as a single-homed customer, which is if you have multiple connections to a single ISP. In some cases, you will use BGP to manage the load balancing across these links. Often, your provider will want to help configure, monitor, and manage BGP since it will affect the service they deliver.

Connecting With and Without BGP

To better understand the practical value of BGP if you’re either multi-homed or you have multiple connections to a single ISP, let’s look at what happens when you connect to the internet without speaking BGP to your provider:

• You create a default route toward your upstream provider, and all non-local packets go out of the interface specified by that route.
• Your provider probably puts static routes toward you on their side and redistributes those static routes into their interior gateway protocol (IGP). Then — unless all of their BGP is done statically — they probably redistribute their IGP into BGP.

What happens differently if you do use BGP? Your provider will give you all of the routes that they have (that’s the easy part), will listen to your route announcements, and will then redistribute some or all of those to their peers and customers (that’s the hard part for them). The net differences boil down to this:

• They may start advertising a more specific route, which is no mean task in a complicated network designed, as most networks are, to prevent the accidental leaking of more specific routes.
• The routes that they normally advertise for you under just their ASN will now have your ASN attached as well.

So what’s the most important benefit to you of using BGP? It’s not that you get full or partial routes from your providers. That’s cool — and maybe even useful — but you can do almost as well by just load-balancing all outgoing traffic in either a round-robin or route-caching manner. The most important thing for you about BGP will actually be the ability to have your routes advertised to your providers and by them to their providers and peers (i.e., to the rest of the internet).

Cardinal Sins of BGP Routing

So now we understand why you might want to use BGP. Does that mean that you’re now ready to start configuring? Doing a basic level of route advertisement using BGP is not hard, but if you screw it up, you may get slapped down pretty hard because screw-ups with BGP route advertisements can be felt all over the internet. That’s right: screw-ups with BGP route advertisements can be felt all over the internet!

What is Blackholing or Route Hijacking in BGP?

The first cardinal sin of BGP is advertising routes to which you are not actually able to deliver traffic. This is called “blackholing,” which is one form of “route hijacking.” If you advertise some part of the IP space that is owned by someone else, and that advertisement is more specific than the one made by the owner of that IP space, then all of the data on the internet destined for that space will flow to your border router. This will effectively disconnect that blackholed address space from the rest of the internet. Let’s say, for example, that you announce a route for Instagram’s servers that’s more specific than the otherwise-best route. The result is that you’ve just blackholed Instagram for a period of time. Needless to say, that will make many people very unhappy.

BGP Route Filtering

The second cardinal sin of BGP routing is not having strict enough filters on the routes you advertise. If you don’t filter well and have a BGP-speaking customer, you can pass on their poor hygiene and be an inadvertent vector for disrupting networks far from you on the internet. If your provider is smart, there are filters in place to prevent you from a spectacular failure, which would hurt them and everyone else. But don’t count on it.

The key to avoiding these sins is multi-level:

• Implement good filtering on your end.
• Check that your provider is also doing excellent filtering wherever possible.
• Be paranoid when configuring your BGP: Test your configs and watch out for typos! Think through everything that you do in terms of how it could screw things up and land you on the front page of the New York Times.

Remember: the vast majority of the route hijacking on the internet is due to misconfiguration! That doesn’t mean that someone couldn’t be attempting to disrupt service or intercept packets, but usually, the issue is a typo in someone’s config. Focusing on the points listed above is your best defense against shooting yourself in the foot when configuring BGP.

In our next sections, we’ll cover more BGP fundamentals: peering sessions, injecting routes, basic filtering, and best-path selection. Because the adverse consequences of not quite knowing what you’re doing are so severe, I don’t advise that you go ahead and start playing with BGP yet. But if you just can’t wait, and you’re implementing BGP for the first time, then please at least get a friend or another provider to review your proposed configs for you before implementing them.

BGP Routing Tutorial Part 3 - BGP Configuration

In this third part of our BGP routing tutorial, we delve into configuring Border Gateway Protocol on routers, explaining Autonomous Systems, ASNs, and the nuances of internal and external BGP. We demonstrate how routers establish peering sessions using ASN identification and stress the importance of careful route filtering. Finally, we guide readers through using and interpreting Cisco’s show ip bgp summary command to view peering sessions.

Configuring Peering for Neighbor Autonomous Systems

So far in this article, we’ve looked at a number of basic concepts about BGP, covering both who would want to use it and why. In particular, we’ve learned that speaking or advertising BGP to your service providers and/or peers lets you do two things:

Make semi-intelligent routing decisions concerning the best path for a particular route to take outbound from your network (otherwise, you would simply set a default route from your border routers into your service providers). Advertise your routes to those providers for them to advertise in turn to others (for transit connectivity) or just use internally (in the case of peering).

We also pointed out some of the negative consequences of careless BGP configuration. In this section, we’ll delve deeper into the mechanics of BGP by looking at how you actually configure BGP on routers.

Autonomous Systems and ASNs

As discussed in Part 1, the term Autonomous System (AS) refers to a network such as a private enterprise network or a service provider network. Each AS is assigned at least one Autonomous System Number (ASN), which identifies the network to the world. Most networks use (or at least show to the world) only one ASN.

ASNs were originally 2-byte values allowing for 65,536 possible numbers. As the number of available ASNs dwindled, a newer 4-byte format was adopted which extended the number of possible ASNs by 4,294,967,295.

• ASNs 0 and 65,535 are reserved values
• The block of ASNs from 64,512 through 65,534 is designated for private use
• The remainder of possible ASN values available for internet routing range from 1 through 64,511 (except 23456 which is used for the 4-byte extension).
• Lumen’s AS3356 is an example of a 2-byte ASN, while Leaseweb’s AS395954 is an example of a 4-byte ASN.

eBGP vs. iBGP

One more clarification before we start configuring: BGP can be used internally (via iBGP) within an AS to manage routes or externally (via eBGP) to route between ASes (which is what makes the internet possible). In this article, when we say “BGP,” we’re talking about eBGP, not iBGP. eBGP and iBGP share the same low-level protocol for exchanging routes and also share some algorithms. But eBGP is used to exchange routes between different ASes, while iBGP is used to exchange routes within the same AS. In fact, iBGP is one of the “interior routing protocols” that you can use to do “active routing” inside your network/domain.

The major difference between eBGP and iBGP is that eBGP tries like crazy to advertise every BGP route it knows to everyone, and you have to put “filters” in place to stop it from doing so. iBGP, on the other hand, tries like crazy not to reconfigure routes. In fact, iBGP can actually be a challenge to get working because to make it work, you have to peer all of the iBGP “speakers” inside your network with all of the other iBGP speakers. This is called a “routing mesh,” and, as you can imagine, it can get to be quite a mess when you have 20 routers that each have to peer with every other router. The solution to this is “BGP confederations,” a topic we’ll cover in a future article.

BGP Peering Sessions: An Example Configuration

So now, let’s look at the actual configuration. BGP-speaking routers exchange routes with other BGP-speaking routers via peering sessions using ASN identification. At a technical level, this is what it means for one network or organization to peer with another. Here’s a simplified Cisco code snippet of a router BGP clause:

router bgp 64512
<omitted lines...>
neighbor 207.106.127.122 remote-as 701

The clause starts out by saying router bgp 64512. This means that what follows is a list of commands that describe how to speak BGP on behalf of ASN 64512. (We’re using 64512 in our examples because it’s not a live ASN, so if anyone uses a configuration straight from this article and uses this made-up ASN, automated route-examination programs will detect it.)

All that’s required to bring up a peering session is that one neighbor line under the router bgp clause. In this example, this line specifies 207.106.127.122 as the remote IP address (with respect to the customer’s route) of a router in the AS with ASN 701.

The purpose of neighbor commands is to initiate peering sessions with neighbors. It’s possible to have BGP peering sessions that go over multiple hops, but eBGP multi-hop is a more advanced topic and has many potential pitfalls. So, for now, let’s assume that all neighbors must be on a LAN interface (Ethernet, Fast Ethernet, FDDI). In practice, you nearly always use more than one line to specify how to exchange routes with a given neighbor in a given peering session. So a typical neighbor command sequence would look more like this:

router bgp 64512
<omitted lines...>
neighbor 207.106.127.122 remote-as 4969
neighbor 207.106.127.122 next-hop-self
neighbor 207.106.127.122 send-communities
neighbor 207.106.127.122 route-map prepend-once out
neighbor 207.106.127.122 filter-list 2 in
<omitted lines...>

Every time a neighbor session comes up, each router will evaluate every BGP route it has by running it through any filters you specify in the BGP neighbor command. Any routes that pass the filter are sent to the remote end. This filtering is a critical process. The most dangerous element of BGP is the risk that your filtering will go awry, and you’ll announce routes that you shouldn’t to your upstream providers.

How to See BGP Routes

While the session is up, BGP updates will be sent from one router to the other each time one of the routers knows about a new BGP route or needs to withdraw a previous route announcement. To see a list of all current peering sessions, you can use the Cisco sho ip bgp sum command line:

brain.companyx.com# sho ip bgp summ

The command typically returns results like the following, which is a session summary from a core router at an ISP. The 6451x Autonomous Systems are BGP sessions to other routers at the same ISP whose ASNs are not shown to the world. The 205.160.5.1 session is a session that is down, and the sessions where the remote Autonomous Systems are 4231, 3564, and 6078 are external peering sessions with routers from another ISP.

The BGP table version is 1159873, and the main routing table version is 1159873
44796 network entries (98292/144814 paths) using 9596344 bytes of memory
16308 BGP path attribute entries using 2075736 bytes of memory
12967 BGP route-map cache entries using 207472 bytes of memory
16200 BGP filter-list cache entries using 259200 bytes of memory

Neighbor        V  AS     MsgRcvd  MsgSent  TblVer   InQ  OutQ  Up/Down   State  
205.160.5.1     4  6313   0        0        0        0    0     never     Active  
207.106.90.1    4  64514  1145670  237369   1159873  0    0     4d03h     
207.106.91.5    4  64515  6078     5960     1159869  0    0     4d03h     
207.106.92.16   4  64512  6128     6782     1159870  0    0     4d03h     
207.106.92.17   4  64512  5962     6894     1159870  0    0     10:08:46      
206.245.159.17  4  4231   161072   276660   1159870  0    0     2d05h     
207.44.7.25     4  3564   6109     310292   1159867  0    0     22:40:50      
207.106.33.3    4  64513  164708   724571   1159866  0    0     3d23h     
207.106.33.4    4  3564   6086     274182   1159853  0    0     4d03h     
207.106.127.6   4  6078   5793     310011   1159869  0    0     2d03h  

Most of the above table is fairly self-explanatory:

• The neighbor column gives the IP address of the neighbor with which the router is peered.
• The V column is the BGP version number. If it is not 4, something is very wrong! BGP version 3 doesn’t understand Classless (CIDR) routing and is thus dangerous.
• The AS column is the remote ASN.
• InQ is the number of routes left to be sent to us.
• OutQ is the number of routes left to be sent to the other side.
• The Up/Down column is the time that the session has been up (if the State field is empty) or down (if the State field is not empty).
• Anything in a State field indicates that the session for that row is not up. In just one of the nomenclature flaws of BGP, a state of Active actually indicates that the session is inactive.

In our next section, we’ll be looking at what to keep in mind when configuring BGP, as well as topics such as route withdrawal, route flaps, route selection, load balancing, and BGP metrics.

BGP Routing Tutorial Part 4 - Further Thoughts on Advertising Your Routes with BGP

In part 3 of this BGP routing tutorial, we looked at how to establish peering sessions with neighbor networks. This time we’ll look at the impact of using BGP with upstream service providers, whether you have only one (single-homed) or several (multi-homed).

If you’ve only got a single upstream service provider, why might you want to bother speaking BGP to them? Well, you could say “for practice,” but configuring BGP generally involves a fair amount of behind-the-scenes work on the part of upstream providers, so they typically aren’t going to waste their time unless you have a good reason.

If you’re single-homed, you also don’t really need to “run defaultless” by accepting all routes. Since every packet destined for the internet (as opposed to your internal network) will go out the same router interface, it doesn’t matter whether it does so via one default route or via searching a list of 45,000 or more routes heard via BGP.

That leaves only one valid reason for single-homed networks to use BGP: to have more control over advertising routes. To make a compelling case to your provider, you’ll have to understand two concepts that they will likely ask you about. One is “flaps,” which require a bit of explanation and is covered in the following section. The other is routing-table space. If you’re in your service provider’s IP space or “aggregate announcement,” they will likely ask why it makes sense to pollute the routing tables with an extra few routes by announcing your routes more specifically. You’re on your own for the answer to that one, but if you think you have a good case, talk to your current or potential provider.

Route Flapping and Damping

When you assert a route, you are saying, “I know how to get to 192.204.4.0/24,” based on some internal knowledge that you actually do know how to get to 192.204.4/0. When you no longer know how to get to that route, the natural — and previously considered correct — thing to do is to withdraw that assertion. Advertising a route and then withdrawing that route is called “flapping.”

One downside of flapping is that it’s contagious. When you withdraw an assertion, your providers must also withdraw that assertion, and their providers and peers must do the same. All in all, thousands of routers worldwide will have to look at that route, decide if they have the next-best path in their BGP table, and if so, insert it into their IP routing table as the current best path.

Route flapping consumes many CPU seconds on routers that are sometimes very busy. In fact, it was consuming so much CPU time years ago that Sean Doran of Sprintlink said, “This must stop.” So several people came up with an idea, which Cisco implemented in record time, to dampen the route flaps (you’ll hear people say “damp” and “dampen”; there’s no real consensus about which is the correct term.) In practice today, this means that if you flap a route more than once or twice, many providers will dampen that route for at least an hour or so. In other words, the route is suppressed, meaning that it will not be advertised even if it is up.

If you’re single-homed, you will be dampened if your provider withdraws your routes because someone resets the router. So if you want to have more control in advertising your routes, and you ask your upstream provider to announce you, you’ll likely be asked to explain why it makes a difference to you, meaning why the benefit of being multiply-announced outweighs the possible adverse effects of being dampened due to instability in either your or your provider’s network. After all, if you’re singly- connected to the ’net, the whole internet doesn’t need to know if you lost connectivity to your provider since there’s no other path to get to you. So why bother all the routers in the world by telling them whether or not you’re currently reachable?

BGP for the Multi-homed

Many networks have business-critical needs for assured internet connectivity, and a common way to achieve this connectivity is by multihoming, which means using the services of two or more upstream service providers. Generally, the goal of multihoming is to use both upstream provider connections in a sane manner and “load-balance” them. Ideally, you’d like roughly half the traffic to go in and out of each connection. You’d also like “failover” routing, where if one link goes down, the other one keeps you connected to the internet. In an ideal network, you’d be able to have any one of your connections to the ’net go down and still maintain connectivity and speed.

You don’t need BGP to load-balance: you can do that almost as well with a “round-robin” or “route-caching.” What’s most important about BGP to you if you’re multi-homed is the ability to advertise routes. In multi-homed situations, the network operator may want to express different routing policies to each upstream provider, which it can do using BGP by using its own ASN and advertising these routing policies to each upstream destination, which are then advertised in turn to their providers and peers (i.e., to “the rest of the internet”).

As noted in Part 2, doing this basic level of route advertisement is not hard, but you have to do it in a paranoid way because if you screw up your BGP route advertisements, it can be felt all over the internet.

One nice thing about using BGP to advertise routes if you are multi-homed is that if you do have connectivity issues, BGP is pretty smooth about handling them. For example, if your providers are announcing specific prefixes for you, they would normally stop announcing you when they don’t know how to get to you anymore. The beauty of speaking BGP to your providers is that when you lose connectivity to them, the BGP session will also go down, and all of those route advertisements will be automatically withdrawn.

Routes and AS-PATHs

The AS-PATH attribute is a key concept to understand when you decide to advertise and receive routes via BGP. Every time a router advertises a route via BGP, that route is stamped with the Autonomous System Number (ASN) of the Autonomous System (AS) to which the router belongs (see Routes and Autonomous Systems in Part 1). As a route moves from AS to AS, it builds up an AS-PATH, which is useful for the following reasons:

• AS-PATH provides a diagnostic trace of routing on the net. If you have full routes in one of your routers, or have query access to a router that does (such as telnet://route-server.cerf.net), you can find the route that encompasses a particular IP address and see which ASNs have advertised it. If you do some poking around, you can even see how a provider is actually connected.
• AS-PATH is one of several metrics that determine how routes heard via BGP are inserted into the IP routing table. We’ll be talking more about metrics in the future.
• AS-PATH can be used for filtering that enables policy routing. You’d want to filter based on the AS-PATH for many reasons, including, for example, to make sure that you only send routes that originate in your network. AS-PATH filtering is the best first step that you can work with to get comfortable with filtering routes. And if your network is relatively simple (as 90 percent of networks are), you won’t need anything fancier for quite some time.

For now, keep in mind that unless you do any tuning on your own:

• The most specific route always wins, whether it’s a BGP route or a static internal route.
• If there’s a choice between multiple BGP routes, the one with the shortest AS_PATH wins.

To sum up, here are the most important questions to keep in mind for each peer when you’re either considering how to do BGP in general or explicitly bringing up a new BGP session:

• What routes do you want the peer to hear? The most important thing is to ensure that you do not reconfigure routes to which you are not providing internet connectivity.
• What do you want to do with the routes that you hear via the session? Do you want to tune them? Only take some? Take them all?

Conclusion

BGP used to be primarily of interest only to ISPs and hosting providers, whose revenue depends on delivering traffic. It then became the business of web businesses to manage their connectivity to the internet in a more intelligent way since their user experience and revenue streams depend on reliable, high-performance internet traffic delivery. Now, with the adoption of cloud solutions by many enterprises to meet their IT needs, as well as the overall trend to digital business models, BGP and internet routing is becoming something with which all network engineers (including not just NetOps but DevOps professionals and SREs) should get familiar.

It would be naive to think that we’ve done complete justice to the topic of BGP in the four parts of this article, but I hope you’ve found this tutorial helpful. If we’ve piqued your interest in how the routes used by your traffic affect network performance and costs, you’ll find that Kentik’s network observability platform provides deep insights into BGP monitoring, configuration, and peering.

BGP Monitoring Tools from Kentik

Kentik provides powerful BGP analytics and monitoring features to help your organization gain insights into BGP operations, identify potential peering opportunities, and optimize routing decisions.

With Kentik, you can stay ahead of network challenges and ensure the smooth performance of your BGP infrastructure. Discover the benefits of Kentik’s network analytics and monitoring solutions for BGP by starting a free 30-day trial or requesting a demo today.

Beyond monitoring BGP routes, Kentik offers a suite of advanced network monitoring solutions designed for today’s complex, multicloud network environments. The Kentik Network Observability Platform empowers network pros to monitor, run and troubleshoot all of their networks, from on-premises to the cloud. Kentik’s network monitoring solution addresses all three pillars of modern network monitoring, delivering visibility into network flow, powerful synthetic testing capabilities, and Kentik NMS, the next-generation network monitoring system.