BGP route selection

BGP discards routes with unreachable NEXT_HOPs. If multiple routes to the same destination are available, BGP selects the best route in the following sequence:

1. The route with the highest Preferred_value

2. The route with the highest LOCAL_PREF

3. The route originated by the local router

4. The route with the shortest AS-PATH

5. The IGP, EGP, or INCOMPLETE route in turn

6. The route with the lowest MED value

7. The route learned from EBGP, confederation, or IBGP in turn

8. The route with the smallest next hop metric

9. The route with the shortest CLUSTER_LIST

10. The route with the smallest ORIGINATOR_ID

11. The route advertised by the router with the smallest router ID

12. The route advertised by the peer with the lowest IP address

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.

If load balancing is configured, the system selects available routes to implement load balancing.

The next hop of a BGP route may not be directly connected. One of the reasons is next hops in routing information exchanged between IBGPs are not modified. 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.

The system supports BGP load balancing based on route recursion. If multiple recursive routes to the same destination are load balanced (suppose three direct next hop addresses), BGP generates the same number of next hops to forward packets. BGP load balancing based on route recursion is always enabled by the system rather than configured using commands.

BGP differs from IGP in the implementation of load balancing in the following ways:

• IGP routing protocols such as RIP and OSPF compute metrics of routes, and then implement load balancing 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 balancing according to metrics of routes. However, BGP has abundant route selection rules, through which, it selects available routes for load balancing and adds load balancing to route selection rules.

BGP implements load balancing only on routes that have the same AS_PATH, ORIGIN, LOCAL_PREF, and MED.

BGP load balancing is applicable between EBGP peers, between IBGP peers, and between confederations.

If multiple routes to the same destination are available, BGP selects a configurable number of routes for load balancing.

In the above figure, 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 balancing 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 balancing. 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 only advertises routes that it uses.

• A BGP speaker advertises routes learned through EBGP to all BGP peers, including both EBGP and IBGP peers.

• A BGP speaker does not advertise routes from an IBGP peer to other IBGP peers.

• A BGP speaker advertises routes learned through IBGP to EBGP peers. If BGP and IGP synchronization is disabled, those routes are advertised to EBGP peers directly. If the feature is enabled, only after IGP advertises those routes, can BGP advertise the routes to EBGP peers.

• A BGP speaker advertises all routes to a newly connected peer.