Showing results for 
Search instead for 
Did you mean: 

BGP Equal-cost load-balancing

Topology of AS 10:

R1------------------------R4 (RR)

|                                   |

R2 (RR)-----------------R5

R1 advertises BGP route to R2 and R4. R5 learns IBGP route from RR R2 and RR R4. The route reflected by R2 is the best path and is installed into Routing table.

R5#sh ip bgp

   Network         Next Hop           Metric LocPrf Weight Path

* i168.1.0.0                 0   100     0 i

*>i                        0   100     0 i

R5#sh ip bgp

BGP routing table entry for, version 4

Paths: (2 available, best #2, table Default-IP-Routing-Table)

Not advertised to any peer

Local (metric 21) from (

     Origin IGP, metric 0, localpref 100, valid, internal

     Originator:, Cluster list:

Local (metric 21) from (

     Origin IGP, metric 0, localpref 100, valid, internal, best

     Originator:, Cluster list:

R5#sh ip route

Known via "bgp 10", distance 200, metric 0, type internal

Last update from 00:25:55 ago

Routing Descriptor Blocks:

*, from, 00:25:55 ago

     Route metric is 0, traffic share count is 1

     AS Hops 0

There are 3 conditions in Equal-cost load-balancing: Same IGP cost to NEXT_HOP. Same path attributes: weight, Local Preference, Origin, AS_PATH, MED. Same type.

The 2 paths have same IGP cost to NEXT_HOP 21, same weight 0, same Local Preference 100,

same Origin IGP, same AS_PATH, same MED 0, same type IBGP. So these 2 paths meet the Equal-cost load-balancing requirements.

By default, BGP has 6 equal paths. Why Equal-cost load-balancing is not happening here?

Giuseppe Larosa
Hall of Fame Master

Hello Jingyi,

when RR are involved additional BGP attributes are present like Originator and Cluster List.

Actually, the cluster-list attribute is used to choice a best path, in this case both Cluster-list are made of a single element but is lower then

You can see this as an extension of the criteria that says use the advertisement coming from the device with lowest BGP router id.

In this case becomes pick the advertisement reflected by the RR with the lowest BGP router-id.

What you see is normal and it is the way iBGP works when there are multiple RRs involved.

If you had two clusters each with two RR servers and with their own set of clients, you would a see a client in cluster B receiving only two copies of each BGP advertisement that are those reflected by the primary RR of cluster A instead of four copies.


just to add on why there is no load balancing in this scenario:

actually they are two different reflections of the same original advertisement with the same BGP next-hop (that of the Originator).

There is no actual advantage in installing two copies of the same advertisement.

There are some tricks used with MPLS L3 VPN to be able to install two copies of the VPNv4 routes that is that of using a different route distinguisher on the two PE nodes serving the same VRF site.

In this way RR servers in the middle in the control plane will treat the two set of advertisements as different and both will be propagated within the domain.

Hope to help


Experiment 1: without RR:



My observations:

  • •1.      BGP route learned from R1 is best path in R2’s Routing table because of R1’s lower advertising BGP RID.
  • •2.      After “R2(config-router)#maximum-paths 2”, both routes are installed in R2’s Routing table.
  • •3.      If these 3 are IBGP routers, after “R2(config-router)#maximum-paths ibgp 2”, both routes are installed in R2’s Routing table.

Experiment 2: with RR

R1------------------------R4 (RR)

|                                       |

R2 (RR)-----------------R5

These 2 paths meet equal-cost load balancing’s 3 conditions. Even though “R5(config-BGP)#maximum-paths IBGP 2” is configured, equal-cost load balancing still does not happen. So RR kills equal-cost load balancing.

Hello Jingyi,

you are right this is the price to pay for scalability in the iBGP control plane.

RR servers as any standard BGP speaker propagates only the best path from their own point of view.

As I have written in my first previous post for MPLS L3 VPN services there is a workaround, but there is no workaround for services that uses address-family ipv4 unicast as your tests show.

Hope to help