BGP decision process

When a BGP router has multiple paths in its RIB for the same NLRI, its BGP decision process is responsible for deciding which path is the best. The best path can be used by the local router and advertised to other BGP peers.

On 7450 ESS, 7750 SR, and 7950 XRS routers, the BGP decision process orders received paths based on the following sequence of comparisons. If there is a tie between paths at any step, BGP proceeds to the next step.

  1. Select a valid route over an invalid route. If a BGP route is invalid because its next-hop it is not resolved then it may still be advertisable if there are no valid routes. For example, an unresolved route can be reflected by a route reflector if it is not trying to set next-hop-self.

  2. Prefer a route for which disable-route-table-install does not apply over a route for which disable-route-table-install has been specified.

  3. Prefer a non-stale route over a stale route (in the context of long-lived graceful restart).

  4. A default route generated by the send-default command is less preferred than a default route programmed by other means.

  5. Select the route with the lowest origin validation state, where Valid<Not-Found<Invalid.

  6. Select the route with the numerically lowest route-table preference. For VPN-IP routes this also consider the number of VPRNs that imported the route.

  7. Select the route with the highest local preference.

  8. Select the route with an AIGP metric. If they both have an AIGP metric, select the route with the lowest sum of:

    1. AIGP metric value stored with the LOC-RIB copy of the route

    2. route-table or tunnel-table cost between the calculating router and the BGP next-hop in the received route

  9. Select the route with the shortest AS path. AS numbers in AS_CONFED_SEQ and AS_CONFED_SET elements do not count toward the AS path length. This step is skipped if as-path-ignore is configured for the address family.

  10. Select the route with the lowest Origin (IGP<EGP<Incomplete).

  11. Select the route with the lowest MED. Only compare MED for non-imported routes that have the same neighbor AS by default. A missing MED attribute is considered equivalent to a MED value 0 by default. Defaults can be changed by using the always-compare-med command.

  12. Select the route with the lowest owner type (BGP-label < BGP < BGP-VPN).

  13. Prefer routes learned from EBGP peers over routes learned from IBGP and confed-EBGP peers.

  14. Select the route with the lowest route-table or tunnel-table cost to the NEXT_HOP. This step is skipped if ignore-nh-metric is configured, or if the routes are associated with different RIBs. For VPN-IP routes received by a router without any configured VPRN services, next-hop cost is determined from the route-table cost.

  15. Select the route with the lowest next-hop type. Resolutions made in the route table are preferred to resolutions made in the tunnel-table. This step is skipped if ignore-nh-metric is configured, or if the routes are associated with different RIBs.

  16. Select the route received from the peer with the lowest router ID; this comes from the ORIGINATOR_ID attribute (if present) or the BGP identifier of the peer (received in its OPEN message). If ignore-router-id is configured, keep the current best path and skip the remaining steps.

  17. Select the route with the shortest CLUSTER_LIST length.

  18. Select the route received from the peer with the lowest IP address.

  19. For VPN-IP routes imported into a VPRN, select the route with the lowest route-distinguisher value.