BGP Routing Tutorial Series: Part 4
Summary
BGP used to be primarily of interest only to ISPs and hosting providers, but it’s become something with which all network engineers should get familiar. In this conclusion to our four-part BGP tutorial series, we fill in a few more pieces of the puzzle, including when — and when not — it makes sense to advertise your routes to a service provider using BGP.
For an updated version of all four parts of this series in a single article, see “BGP Routing: A Tutorial” or download our Ultimate Guide to BGP Routing.
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 take 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) is going to 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 really valid reason for single-homed networks to use BGP, which is to have more control in 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 requires 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 make 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 either your current or potential provider.
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 referred to as “flapping.”
One downside of flapping is that it’s contagious. When you withdraw an assertion, your providers must then also withdraw that assertion, and then their providers and peers must do the same. All in all, thousands of routers around the world will have to look at that route, decide if they have a 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.” 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.) What this means in practice today is that if you flap a route more than once or twice that route will be dampened by many providers 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 negative 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 of 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 multi-homing 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 connection 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 really 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. 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 any more. The beauty of speaking BGP to your providers is that when you lose connectivity to them, the BGP session will go down as well and all of those route advertisements will be automatically withdrawn.
Routes and AS-PATHs
A key concept to understand when you decide that you want to advertise and receive routes via BGP is the AS-PATH attribute. 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 a number of metrics that determine how routes heard via BGP are inserted into the actual IP routing table. We’ll be talking more about metrics in the future.
- AS-PATH can be used for filtering that enables policy routing. There are many reasons why you’d want to filter based on the AS-PATH 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 fairly simple (as 90 percent of networks are), then 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, then 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 specifically 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 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 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 series, but I hope you’ve found these tutorials helpful. If we’ve piqued your interest in how the routes used by your traffic affect network performance and costs, you’ll find that a Big Data-based approach to BGP analytics provides the most powerful platform for valuable insights. At Kentik, we’ve incorporated BGP analytics into our cloud-based network visibility SaaS, which you can experience by signing up for a free trial.
