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

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:

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:

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:

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:

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:

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

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:

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?

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:

This is how we did it. On CE1:

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

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.

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:

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:

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:

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

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:

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

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

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

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:

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

Thanks for reading!