One of my favorite things about BGP is how flexible it is. The other thing I love is that it’s really easy to see all of the possible paths the router knows about. However, when it all boils down, BGP has to select the best path (or paths if you select to change the max-paths from 1). What I’d like to do in this post is briefly describe the best path selection process and then talk about some practical examples. Let it be known, there are tons of sites out there that talk about the best path selection process so I don’t want to beat the dead horse. I’ll cover the big hitters and provide examples as I go. As I go through the examples, I’ll be reusing the lab from the last post…
Let’s get right into it…
1 – Weight
Weight is the first value compared in the best path decision. Weight is a Cisco proprietary variable and is only significant to the router in which you configure it on. Weight can be configured for specific prefixes by the use of a route-map inbound on a neighbor or by configuring the weight of a neighbor for all prefixes received from it. Let’s take a look at doing it both ways on router5…
As you recall, router5 was preferring the older path through router4. Let’s increase the weight of the neighbor for the peering to router5…
Above you can see that we set the weight of the neighbor 10.0.0.5 to 5. Once we cleared BGP you can see that the weight for all prefixes learned from 10.0.0.5 is now showing as 5. Also note that this is now the preferred path for router5. Now, lets configure a route-map to change the weight of a specific prefix…
First we configure a prefix list to match just the 192.168.1.1/32 prefix. We then use that on our route-map as the match component, and then set the weight to 10. I then go into BGP and configure the route-map inbound on the 10.0.0.2 neighbor. It takes a second to apply, but in the second ‘show ip bgp’ output you can see that the route-map has been applied and that the 192.168.1.1/32 network is now preferred through 10.0.0.2. Note that since I didn’t add a second permit route-map entry that I no longer receive the 172.64.1.0/24 prefix from router4 since there is no match for it in the prefix list we created.
2 – Local Preference
Local preference is a means to manipulate outbound route preference from an AS. Unlike weight, the local preference attribute is shared with all members of an AS. For instance, say that we want all of the routers in AS 100 to use the path through router5 to get to the prefixes attached to router1. Let’s look at the BGP table on router3 to see the current best path…
As you can see, AS 100 is currently preferring the route up through router2 to the prefixes. We’re using the next-hop-self command so the next hop is showing as the iBGP peer address of router2. Now, let’s make some changes…
Here we specify one of the prefixes being advertised to the AS (172.64.1.0/24) and set the local preference to 200. The default local preference value is 100 so the value we set should be the winner. We configure a second permit route-map entry to pass all non-matching prefixes and then we apply the route-map inbound on the eBGP peer of router4. The result can be seen on router2 and router3…
The first ‘show ip bgp’ in each block was taken before we made the changes and the second was taken directly afterwards. Note how each router is now showing the LocPref of 200 for the 172.64.1.0/24 prefix as well as having selected it as the best path. Much like weight, local preference can also be configured on a more global level. For instance, I can set the default local preference for the entire router. Let’s try that on router2…
The result of this can be seen on all routers in the AS but let’s just take a look at router4…
Note how router4 is now showing the LocPref of 300 for the routes from router2. Also note that the preferred path is now through router2 for both of the prefixes.
3 – Prefer locally originated routes
This one is pretty straight forward. Basically you prefer routes that are locally originated over routes that are learned. This is easy to understand as locally originated routes have a weight of 32768, We can see this on router1…
Routes can be originated using the network, redistribute, and aggregate commands. If there are multiple local BGP routes they are preferred in this order.
1 – Routes introduced with the network command
2 – Routes introduced with the redistribute command
3 – Routes introduced with the aggregate command
In the example below, I introduced the 172.64.1.0/24 prefix on router3 via the aggregate command and the network command…
Looking at the specific BGP table entry we can see that the redistributed route beat out the aggregate route…
If we were to use the network statement to introduce the prefix that would replace the aggregate and become the best path.
4 – Shortest AS-Path
This one is pretty self explanatory. You prefer the path that has the shortest AS-Path count. This attribute is generally used to influence inbound routing through the use of AS-Path prepending. For instance, lets say that router1 would really prefer to have all of the traffic from all the other autonomous systems coming in from router2 under normal operation. We could prepend the advertisement out to router7 to make that path seem not as appealing. Let’s try that out and see what the results are…
Here we create a route-map that prepends ‘400 400 400’ to the AS-Path list. We then set it outbound on the router7 BGP peer. Now let’s take a look at a couple of the BGP tables on other routers…
Router7 still sees the path directly to router1, but now prefers the route down to router6. Note that the path through router1 has a substantially longer AS-Path at this point…
Router5 now prefers thee route through router4. Notice that router5 no longer has a route in the BGP table through router6. This is because router6’s best path is through router5. Router6 will advertise only the best path to the prefix and router5 will drop the advertisement since it sees its own AS in the AS-Path list.
5 – Lowest Origin type
Here we look to see where the prefix came from. As we know, redistributed routes have an incomplete origin and routes originated via the network or aggregate commands have an origin of IGP or ‘i’. There’s also ‘e’ or EGP but that isn’t used anymore. That being said, BGP prefers routes that have an origin of IGP over routes that have an origin of incomplete.
6 – Lowest MED
The MED (Multi-Exit Discriminator) is used to influence inbound routing from a mulithomed AS. The lower the MED the better. Since the MED attribute is non-transitive, it is only of use when you are dual homed to the same AS. For instance, if you have redundant paths to the same AS, you could use MED to tell the neighboring AS which path to use to reach your prefixes. That being said, we can’t really use MED in our existing topology without tweaking it slightly…
Let’s assume that we want traffic from AS 100 to enter AS 400 through the new link we just created. We can do this by advertising a increased metric from router1 to router2.
Since the default metric is 0, we need to advertise a higher metric over the path we’d prefer not be used. In this case, we advertise a metric of 100 to router2. Router2 shares that metric within the AS and all BGP router in AS 100 decide to use the path through router4 on the new link…
The output above shows the BGP table on router2 before and after the change. As you can see the metric is now 100 after we did a soft clear on the BGP session. Router3 and router4 look similar…
Note that neither router3 or router4 actually have a path with the metric set to 100. This is because router2 is no longer advertising the route to 3 and 4 since it isn’t it’s best path.
7 – eBGP over iBGP
This is another rule that just makes sense. An eBGP learned route would be a quicker means to get out of an AS than following an iBGP route somewhere else in the AS to get to the prefix. If you have a eBGP route for a prefix you should use it over any iBGP learned routes for the same prefix.
8 – Prefer the lowest IGP metric to BGP next hop
This one is also pretty straight forward. If you’ve gotten this far compare the IGP metric for the BGP next hop. The lowest one wins. Suppose we advertise the prefix 10.20.30.0/24 from router6. Let’s also remove the next-hop-self commands from router2 and router4 in AS100. In this way, router3 will see the BGP next hop for the prefix as being 10.0.0.1 and 10.0.0.25…
If we look at the route metrics for the BGP next hops, we can see that they are currently the same…
Let’s increase the delay on router2’s interface facing router1…
Doing this will increase the EIGRP cost to get to 10.0.0.25. If we look at router3 again, we’ll see that the cost of the route to 10.0.0.24 has indeed increased and the BGP table now prefers the route through the BGP next hop of 10.0.0.9…
9 – Multipaths
This step really just tells the router to check and see if multipath is turned on. If it is, it can select multiple paths and load balance across them. This doesn’t change the fact that the router will only advertise the best path to it’s BGP peers though.
10 – Prefer the oldest path
Just like it reads. Pick the oldest path and use that one. The one that’s been around longer is likely more stable. We can see this happen in the below example…
In the first output the path through the BGP next hop of 10.0.0.29 is the best path. If we clear the BGP session on router4, the route is withdrawn until the BGP session is rebuilt. In the last output we can now see that the path through 10.0.0.25 is the best path since it’s been there longer than the freshly installed path through 10.0.0.29.
11 – Prefer the lowest Router-ID
The age old tie breaker. If you get this far, your path selection probably isn’t of great concern to you.
The best way you describe. Thank you
Excellent. I have navigated for a few hours and was about to get confused about the Path selection attributes. Luckily found this site with show outputs. Now have a better understanding. Very nice and professional job. Thanks
Thank You sir.
You have explained very well