Modifying the BGP Path Selection Process on IOS
By stretch | Thursday, October 21, 2010 at 3:29 a.m. UTC
The implementation of Border Gateway Protocol (BGP) on Cisco IOS provides a number of ways to manipulate the default best path selection process. This article does not discuss ways to influence the selection of one BGP route over another (for example, by AS prepending), but rather examines how the path selection process itself can be modified.
Default BGP Path Selection
Before we dig into modifications, let's review the default BGP path selection process. An in-depth analysis of the BGP path selection mechanism on Cisco IOS can be found here. A simplified summary of the process follows.
- Prefer the route with the highest weight (a local, Cisco-proprietary parameter).
- Prefer the route with the highest local preference.
- Prefer locally-originated routes over those learned from a neighbor.
- Prefer the route with the shortest AS path.
- Prefer IGP-learned routes over those with an unknown origin.
- Prefer the route with the lowest MED (per AS).
- Prefer EBGP-learned routes over IBGP-learned routes.
- Prefer the route whose next-hop address has the lowest IGP metric.
- Multipath determination
- If a best path exists, prefer it over newer routes.
- Prefer the route from the router with the lowest router ID.
- If the router IDs match, prefer the lowest neighbor IP address.
Modifying BGP Path Selection Logic
Ignoring BGP Cost Communities
BGP cost communities are a non-standardized type of non-transitive extended BGP community that allow for arbitrary customization of the BGP path selection process. Cost communities can be ignored with the command
bgp bestpath cost-community ignore.
Ignoring AS Path Length
Evaluation of AS path length is the fourth step in BGP path selection. Routes with shorter AS paths are preferred over those with longer AS paths. (An AS_SET counts as 1, regardless of how many ASNs it contains.) Although not typically desired, the AS path evaluation step of BGP path selection can be disabled with the command
bgp bestpath as-path ignore.
In the example below, R1 is receiving a route for 172.16.0.0/16 from each of three EBGP neighbors. The path through 10.0.14.4 is preferred because it has the shortest AS path.
R1# show ip bgp BGP table version is 2, local router ID is 10.0.14.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 172.16.0.0 10.0.14.4 0 0 65004 ? * 10.0.12.2 0 0 65002 65003 65004 ? * 10.0.13.3 0 0 65003 65004 ?
After disabling AS path length evaluation, and assuming all other attributes are equal among the routes, the router defaults to preferring the route from the EBGP neighbor with the lowest router ID. (Note that step 10 in the process does not apply in this case because the previous best path was removed when the BGP neighbor adjacencies were reset with
clear ip bgp.)
R1(config)# router bgp 65001 R1(config-router)# bgp bestpath as-path ignore R1# clear ip bgp * R1# show ip bgp BGP table version is 2, local router ID is 10.0.14.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 172.16.0.0 10.0.12.2 0 0 65002 65003 65004 ? * 10.0.14.4 0 0 65004 ? * 10.0.13.3 0 0 65003 65004 ?
Force MED Comparison Across All Neighboring ASes
By default, multi-exit discriminator (MED) values are only compared among routes advertised by the same neighboring autonomous system. The BGP configuration command
bgp always-compare-med forces evaluation of the MED of all routes for a destination, regardless of the AS from which they were learned. When enabling this feature, it is advisable to enable deterministic MED computation as well, using the command
R1# show ip bgp BGP table version is 2, local router ID is 10.0.14.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * 172.16.0.0 10.0.13.3 100 0 65003 ? * 10.0.14.4 200 0 65004 ? *> 10.0.12.2 300 0 65002 ?
Because the above routes are all learned from different autonomous systems, their MED (metric) values are not compared. After enabling the command
bgp always-compare-med, we can see that the route with the lowest MED is now preferred.
R1(config)# router bgp 65001 R1(config-router)# bgp always-compare-med R1(config-router)# bgp deterministic-med R1# clear ip bgp * R1# show ip bgp BGP table version is 2, local router ID is 10.0.14.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * 172.16.0.0 10.0.14.4 200 0 65004 ? *> 10.0.13.3 100 0 65003 ? * 10.0.12.2 300 0 65002 ?
Force MED Comparison Inside a Confederation
By default, MED values are not compared among routes from BGP confederation peers. The command
bgp bestpath med confed can be used to force evaluation of the MED attribute so long as no external (non-confederation) ASNs are present in the AS path.
Punish Routes Without a MED
BGP routes without a MED attribute are considered to have a MED of zero by default. The command
bgp bestpath med missing-as-worst can be used to reverse this behavior, assigning routes with no MED a MED of "infinity" (the highest possible and therefore least favorable MED value). However, testing shows that most types of BGP routes are assigned a MED of zero before being advertised.
Disable Step 10
Step 10 in the path selection process instructs the BGP router to prefer a current best path, if it has one, over a newer route with equal attributes. This behavior can be disabled by issuing the command
bgp bestpath compare-routerid, which will force comparison of advertising router IDs (and, if they are equal, neighbor IP addresses) even if a current best route exists (steps 11 and 12).
Posted in Routing
October 21, 2010 at 7:26 a.m. UTC
I've gotta say, this site has always been great, but some of the recent blogs have been outstanding. I'm loving some of these hints/tips/configuration exercises, this and the password recovery one are great.
October 21, 2010 at 11:38 a.m. UTC
I would like to add little more, hope you won't mind :-)
- Neighbor with valid Next hop(accessible) will be preferred over neighbor with in-accessible next hop.
October 21, 2010 at 1:25 p.m. UTC
Nice writeup but I'm still curious about the issue you tweeted about yesterday with BGP preferring a newer route when it shouldn't have.
Did you ever determine what the issue was with that?
October 22, 2010 at 12:02 p.m. UTC
October 22, 2010 at 12:22 p.m. UTC
I think, (please correct me if I'm wrong) that if you use "bgp always-compare-med" you force MED to be compared first.
October 22, 2010 at 12:46 p.m. UTC
To my knowledge the "bgp always-compare-med" and "bgp deterministic-med" commands only affect how the MED comparison is done, not when.
Here is a bit more info on the commands:
August 21, 2011 at 10:52 p.m. UTC
Great write-up here.
In this instance would the second route be preferred since it is "i" instead of unknown?
*> 192.168.101.0 xxx.xxx.xxx.xxx 0 65000 65000 ?
*> 192.168.101.0 xxx.xxx.xxx.xxx 0 65000 65000 i
December 8, 2014 at 10:58 a.m. UTC