Route selection rules

The current BGP implementation supports the following route selection sequence:

  • Prefer the route with the lowest Administrative Distance.

  • Prefer the route with the larger weight.

  • Prefer the route with the highest LOCAL_PREF value.

  • Prefer the path that was locally originated via a network or through redistribution from an IGP.

  • Prefer the route with the shortest path, excluding confederation segments.

  • Prefer the route with the “best” ORIGIN. IGP is better than EGP, which is better than Incomplete.

  • If bgp always-compare-med is not configured, prefer any routes that do not have an inferior MED. If bgp always-compare-med has been configured, prefer the route with the lowest MED.

  • Prefer the route with the lowest IGP cost to the BGP next hop. IGP cost is determined by comparing the preference, then the weight, then the metric, and finally the metric2 of the two resolving routes.

  • If “ip load-sharing” is enabled, BGP inserts up to n most recently received paths in the IP routing table. This allows eBGP multipath load sharing. The maximum value of n is currently 4. The default value of n, when “ip load-sharing” is disabled, is 1. The oldest received path is marked as the best path in the output of show ip bgp prefix/len .

  • Prefer routes received from external peers.

  • If bgp tie-break-on-age has been specified, prefer the older route.

  • If bgp bestpath compare-router-id has been specified, prefer the route learned with the lowest router ID. The router ID is taken from the Open message of the peering session over which the route was received, unless bgp bestpath compare-originator-id has been specified, and the route was received with an ORIGIN_ID. In the latter case, the ORIGIN_ID is used instead of the router ID from the Open message.

  • If bgp bestpath compare-cluster-list-length has been specified, prefer the route with the lowest CLUSTER_LIST length.

  • Prefer the route with the lowest neighbor address.

NOTE:

CLUSTER_IDs of route reflectors form a CLUSTER_LIST. If a route reflector receives a route that contains its own CLUSTER ID in the CLUSTER_LIST, the router discards the route to avoid routing loops.