Load Balancing Among BGP Routes
Conditions for Load Balancing Among BGP Routes
Unlike an Interior Gateway Protocol (IGP), BGP imports routes from other routing protocols, controls route advertisement, and selects optimal routes, rather than maintaining network topologies or calculating routes by itself.
- By default, static routes or equal-cost IGP routes are used for BGP route recursion to implement load balancing among BGP routes.
BGP route attributes are changed and then routes are selected to implement load balancing when the following conditions are met:
- Original next-hop addresses are different.
The routes have the same origin type (IGP, EGP, or incomplete).
All the routes are EBGP or IBGP routes. After the maximum load-balancing eibgp command is run, BGP ignores this limitation when selecting the optimal VPN route.
The metric values of the IGP routes to which BGP routes within an AS recurse are the same. After the load-balancing igp-metric-ignore command is run, the device does not compare IGP metric values when selecting routes for load balancing.
- All routes are blackhole or non-blackhole routes.
Rules of Selecting BGP Routes for Load Balancing
If the number of BGP routes available for load balancing is greater than the configured maximum number, BGP selects routes for load balancing in the following order:
- Routes with the shortest Cluster_List.
- Routes advertised by the router with the smallest router ID. If the routes carry the Originator_ID attribute, BGP selects the routes with the smallest Originator_ID without comparing router IDs.
- Routes that are learned from the BGP peer with the lowest IP address
EIBGP Load Balancing
This feature is used in a scenario where a CE in a VPN is dual-homed to two PEs. In Figure 1, CE1 is dual-homed to two PEs, which reside in different ASs. In this case, EIBGP load balancing can be configured on PE3 so that VPN traffic is balanced among EBGP and IBGP routes.
UCMP Based on the BGP Link Bandwidth Extended Community Attribute of Routes
In a scenario where load balancing is performed among outbound routes on some devices, equal-cost multi-path (ECMP) results may fail to meet expectations due to uneven outbound link bandwidth. To solve this problem, you can configure the BGP Link Bandwidth extended community attribute function on corresponding devices. With the function, the devices add the BGP Link Bandwidth extended community attribute that reflects link bandwidth to BGP routes so that unequal cost multipath (UCMP) is implemented based on the outbound link bandwidth proportion.
In Figure 2, Device A and Device B reside in AS 100, whereas Device C to Device F reside in AS 200. After Device C receives a route from its directly connected EBGP peer Device A, Device C adds the BGP Link Bandwidth extended community attribute to the route and advertises the route to its IBGP peers. In this route, the BGP Link Bandwidth extended community attribute indicates the bandwidth of the link between Device C and each IBGP peer.
The next hops of the routes to be used for UCMP must be of the same type. For example, UCMP can be implemented only when the next hops of the three routes are all SRv6 TE Policies.
The process to implement UCMP is as follows:
1. Device A and Device B advertise the BGP route 10.10.10.10/32 without the BGP Link Bandwidth extended community attribute to Device C.
2. Device C selects both the links to Device A and Device B to implement load balancing, with each link's outbound bandwidth being 200 Gbit/s.
3. Device C sends the route with the BGP Link Bandwidth extended community attribute (400 Gbit/s) to Device F.
4. Device D and Device E perform similar operations to those performed by Device C.
5. Device F receives three routes destined for 10.10.10.10/32 from Device C, Device D, and Device E, with the bandwidth values being 400 Gbit/s, 200 Gbit/s, and 200 Gbit/s, respectively.
6. Device F implements UCMP among the three links based on the outbound link bandwidth proportion of 2:1:1.