evilrouters.net

I wanted to follow-up to an earlier post, “Using BGP communities to influence routing”, and show some more ways we can use BGP communities to influence routing on the Internet. What we’re going to see today is very common in the real world, although it does take the cooperation of your service provider.

If you’re lucky, your service provider will have already published a listing of communities that they accept and what effect they have. The ones we’ll be using today come from an old XO Communications document that I found.

Here’s the topology we’re going to be working with today:

We’re going to be the customer, in AS 65001. To keep things simple, we’ll configure a single connection on one service provider, XO Communications in AS 2828. As you can see, XO peers with a number of other providers. We have three loopback interfaces that we’re going to create, and the IP addresses we assign to those will be the ones we’re advertising into BGP.

Under normal circumstances, XO would simply pass along our advertisements to its peers. We’re going to see how we change that, however, by applying some communities to our routes as we send them to XO.

Here we have a small example of the communities a service provider might accept. By tagging our routes with these values, we can control how XO handles those routes. For example, if we send community 2828:1003, XO won’t advertise that route to Sprint. Likewise, if we send community 2828:1308, XO will prepend its own AS number three times. The possibilities are endless.

The bottom half of that diagram shows what we’ll actually accomplish when we’re done. When advertising our routes, we’ll use communities to tell XO:

• don’t advertise 192.168.0.1/32 to Sprint (2828:1003),
• prepend twice when advertising 192.168.0.1/32 to Level3 (2828:1207),
• prepend once when advertising 192.168.0.1/32 to AT&T (2828:1108),
• prepend thrice when advertising 192.168.1.1/32 to Sprint (2828:1303),
• don’t advertise 192.168.1.1/32 to Level3 (2828:1007),
• prepend twice when advertising 192.168.1.1/32 to AT&T (2828:1208), and
• advertise 192.168.2.1 normally (no communities)

That’s a big list of demands, but it’s actually quite easy to do and — even better — it doesn’t require us to deal with another person at our service provider. By using these communities, we can do it ourselves (and change it whenever we want!).

For this lab, the XO, ATT, SPRINT, and LEVEL3 routers have already been configured. I’m intentionally not posting the configuration from XO, as it is out of the scope of this posting. While I may post it later, we’re only worried about how to configure things on the customer side.

Here we go…