Outbound path selection with BGP

Recently I was involved in a BGP implementation project and it was a nice opportunity to recall the old good CCNP days and to expand my knowledge a bit. It was quite nice working on this project. Except for RIPE paper works, of course Smile

After completing it, I thought it would be nice to  share some things on this blog. Yes, I know that BGP is around for eons and that all about it was said, but when I try to learn something, often I need to find more than one document, the one that is written “for me”. So, perhaps this blog will find a reader out there.

For the sake of this blog, I created this topology in GNS3:

SNAGHTML12f041b

We have AS65001, which is an enterprise, AS65002 – the ISP and AS65003 – some Internet organization we are connecting to. We are using private AS numbers here. In real world we would go for something public.

The enterprise is using EIGRP for routing, and ISP is using OSPF. These IGP protocols are used for exchanging Loopback0 IP addresses which are used for BGP connections and next-hop reachability.

Here is a problem definition: CE1 router is connected to ISP with 64Kbps link. I know this is (almost) impossible now days, but the point here is that this link is way to slower compared to CE2’s link of 100Mbps. Because BGP does NOT care about link speeds, this is what could happen – we could send some of our traffic using 64Kbps link, instead of 100Mbps. This is perhaps not what we would like to happen. And is happening in our case:

image

We would like our outbound traffic to take another path, via CE2-PE2.

There are two ways of doing this:

  • Weight
  • Local preference

Weight
Weight is a Cisco proprietary way of choosing one BGP route over another. It can be used only on Cisco gear and is locally significant. This means that it won’t be sent with prefix updates like other attributes. The weight can have a value 0-65535 with a default of 32768 for local routes and zero for other routes. The larger number, the better. Here is our BGP table on CORE router:

image

We have a green-underlined local route with a default weight of 32768 and a red-underlined route received from CE1 with a default weight of zero. Although we have received 4.0.0.0/8 prefix from both CE1 and CE2, BGP for some reason selected one from CE1 and marked it as best (BGP best route is marked with a > sign). Only this prefix or a route will be installed in a routing table:

image

Of course this means that our traffic will leave our AS using 64Kbps link, as demonstrated above. We will now change this by using weight.

We can do that two ways:

  • Per neighbor weight
  • Route maps
  • Per neighbor weight

Per neighbor weight is easy: we can change weight on CE2 for a neighbor PE2 to be higher that the weight on CE1 for neighbor PE1. In order for CE1 to take the right path we need to change a weight on CE1 for neighbor CE2 to be higher than a weight on CE1 for PE1. To picture what is just said, let’s take a following screenshot:

image

This is what we have added to a default BGP configs on CE1 and CE2:

image

image

Don’t forget to do a clear ip bgp * soft on CE1 and CE2 after changing weight.

Let’s now verify the traffic flow from CORE:

image

We can see that now traffic is leaving AS65001 via 100Mbps link and CE2. Previously it was leaving via CE1.

  • Route maps

What is wrong with per neighbor weight? Well, one obvious thing is we can prefer one path over another for ALL prefixes. In our case, CORE would go CE2->PE2 for 4.0.0.0/8, but would also take this same path for all other destinations. What if we would want it to take CE2->PE2 for 4.0.0.0/8 and we don’t care about other prefixes?

image

We can see that we take the same path for 7.7.7.7/32. We want to take this path *only* for 4.0.0.0/8:

image

This is how we did it. On CE1:

image
We created a prefix list that matches 4.0.0.0/8 exactly. We could use an access-list as well.

image
Then we use this prefix inside a route map. We match the prefix and set a weight for that prefix to be 555. Please have in mind that we must have an empty match/action entry at the end of a route map. If we didn’t, we would assign a weight of 555 to 4.0.0.0/8 and drop all other prefixes received from a neighbor we applied a route map to.

image
Finally, we applied a route map on CE1 to neighbor CE2.

On CE2, prefix list and route map are the same. We apply a route map to neighbor PE2:

image

Local preference
This is another way of choosing outbound path with BGP. Why would we need yet another way? Well, for starters, weight is Cisco proprietary attribute, which means there is no weight on, say Juniper. And weight has only local significance. This means we may have to apply it on several or all routers, such as in our case, where we applied it on both CE1 and CE2.

Local preference comes right after weight in BGP path selection, so it is still strong mechanism of preferring a path. It is not limited to a local router, but spans the entire autonomous system. This means that we can set a local pref on one router for some prefixes, and it is sent to all internal neighbors along with  prefix updates. It is removed on eBGP sessions, so it stays within a local AS.

Local pref can range from 0-4294967295 with a default of 100. The higher the better. There are also two ways of playing with local pref:

  • Default Local Preference
  • Route Maps
  • Default Local Preference

First we remove weight related config from both CE1 and CE2 and verify that we are using 64Kbps link:

image
And we do.

Now changing this is easy. We go to CE2 and under the BGP process we set default local pref to be higher than a default of 100:

image

Let’s not try to send some traffic from CORE:

image
We are ok now.

Good thing about local pref is that we don’t need to change anything else anywhere within our AS, and all routers will chose CE2 to exit the AS. It’s that easy!

  • Route Maps 

Let’s now repeat our scenario from weight section: we want to take CE2->PE2 route only for 4.0.0.0/8 and don’t care about anything else. We are now going CE2->PE2 for all destinations:

image

Let’s change that… We do all our config on CE2:

image
Now we match our prefix with an ACL instead of prefix list.

image
Then we use this ACL inside a route map. Again, don’t forget an empty permit statement, otherwise we will block all other traffic.

image
And we use this route map to apply local pref of 555 to all prefixes matched with an ACL DESTINATION4 that are coming from PE2. Now it is only 4.0.0.0/8, but can be anything we place inside this ACL. After a clear ip bgp * soft we should be ready to test this:

image
And sure enough, this is exactly what we wanted to accomplish.
Ok, that’s all about outbound path selection. I will try to find some time to blog about inbound path selection with AS path prepend, communities and MED.

I hope this blog will have positive reviews as my first BGP blog Smile

Thanks for reading!

Advertisements
This entry was posted in BGP, Cisco, IOS, Routing and tagged , , , . Bookmark the permalink.

2 Responses to Outbound path selection with BGP

  1. MUSH says:

    Thank you very much, it’s really help me to understand the configuration well.

  2. Sanal says:

    Good work man

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s