Can anyone answer why does BGP RR only reflect the best path?

  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer. – Ron Maupin Jan 3 at 2:24

To conserve memory at destination, it was not important to micro-optimize forwarding path in the past. This is quote from RFC4456:

One of the key component of the route reflection approach in
addressing the scaling issue is that the RR summarizes routing
information and only reflects its best path.

While scaling is always important, clearly there are today scenarios where we'll rather spend RIB memory than choose suboptimal path.

To address this issue there is BGP AddPath and BGP optimal reflection. AddPath is available from both Cisco and Juniper, while optimal reflection currently is not implemented by major vendors.

AddPath allows BGP to send more than single best path. Optimal reflection will use SPF (ISIS, OSPF) to reflect best route from POV of receiver, not from route reflectors own point of view.


Bear in mind that the idea with iBGP and route reflection has been to distribute path information with the idea that specific routing/forwarding decisions would be accommodated by the underlying IGP (particularly including multipathing, internal failover, etc). As such, a pointer to what ought to be fairly static next-hops can be kept in table while avoiding the churn associated with localized network information.

Scalability and stability were (and arguably should be) the primary objectives of BGP - even at the price of suboptimal path choice and fast convergence. The traditional implementation of the RR epitomizes this. Ideally the information on RR's should be as static as possible and timers should be kept on the long side.

BTW - There are circumstances in which an RR might send multiple paths to the same v4/v6 destination - both the AddPath feature mentioned above as well as in the MPLS VPN case where a given prefix is associated with the RD's of multiple PE's.

  • Not sure I'd lump RR in with the original iBGP design goals (which you're totally right about, especially regarding scalability and stability); RR was proposed in a separate RFC to alleviate the scaling issues someone would run into with iBGP full mesh and the desire to have synchronization disabled. Otherwise a great answer, and upvoted as such. – John Jensen May 28 '13 at 2:21
  • I'd like to point out that prefix with different RD is unique prefix, reflector has no idea it it'll be non-unique at receiver PE at receiver VRF. This is exactly the function of RD, without it, you couldn't have overlapping prefixes in VRFs. – ytti May 28 '13 at 7:33

To add to the previous answers, you have a new feature called BGP path diverse to allow the RR to advertise a diverse path. For more detail, please check RFC6774 or Cisco implementation at http://www.cisco.com/en/US/docs/ios/ios_xe/iproute_bgp/configuration/guide/irg_diverse_path_xe.html


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.