The current BGP implementation supports the following route selection sequence:
-
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 -
If
bgp tie-break-on-agehas been specified, prefer the older route. -
If
bgp bestpath compare-router-idhas 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, unlessbgp bestpath compare-originator-idhas 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-lengthhas been specified, prefer the route with the lowest CLUSTER_LIST length.
|
|
|
![[NOTE: ]](images/note.gif) |
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. |
|
|
The nexthop of an iBGP route may not always be directly connected. One of the reasons is next hops in routing information exchanged between iBGPs are not modified. In this case, the BGP router needs to find the directly connected next hop via IGP. The matching route with the direct next hop is called the recursive route. The process of finding a recursive route is route recursion.
BGP differs from IGP in the implementation of load balancing in the following:
-
IGP routing protocols such as RIP and OSPF compute metrics of routes, and then implement load sharing over routes with the same metric and to the same destination. The route selection criterion is metric.
-
BGP has no route computation algorithm, so it cannot implement load sharing according to metrics of routes. However, BGP has abundant route selection rules, through which it selects available routes for load sharing and adds load sharing to route selection rules.
|
|
|
|
|
NOTE:
|
|
|
In Network diagram for BGP load sharing, Router D and Router E are iBGP peers of Router C. Router A and Router B both advertise a route destined for the same destination to Router C. If load sharing is configured and the two routes have the same AS_PATH attribute, ORIGIN attribute, LOCAL_PREF and MED, Router C installs both the two routes to its route table for load sharing. After that, Router C forwards to Router D and Router E the route that has AS_PATH unchanged but has NEXT_HOP changed to Router C; other BGP transitive attributes are those of the best route.
The current BGP implementation supports the following route advertisement rules:
-
When multiple feasible routes to a destination exist, the BGP speaker advertises only the best route to its peers.
-
A BGP speaker advertises routes learned from an eBGP peer to all its peers, both eBGP and iBGP.
-
A BGP speaker does not advertise routes learnt from an iBGP peer to its other iBGP peers.
-
A BGP speaker advertises routes learnt from iBGP to eBGP peers. Note that BGP and IGP synchronization is disabled always and those routes are advertised to eBGP peers directly.