In part 1 of this series, 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 post, adding more concepts and digging deeper into how BGP works and what makes it of value.
The core function of BGP is 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 18.104.22.168/24 (in class C terms, the block starting at 22.214.171.124 and ending at 126.96.36.199), you promise that you know how to carry to its ultimate destination data that is destined for any address in 188.8.131.52/24.
Another important BGP-related concept is “single-homed” vs. “multi-homed,” which is a major determinant in who uses BGP and who doesn’t:
When you’re single-homed, you usually won’t want to use BGP to 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.
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:
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:
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).
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!
The first cardinal sin of BGP is advertising routes to which you are not actually able to deliver traffic. This is called “black-holing,” 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 black-holed 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 black-holed Instagram for a period of time. Needless to say, that will make many people very unhappy.
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 fail, which would hurt them and everyone else. But don’t count on it.
The key to avoiding these sins is multi-level:
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 future posts 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.