BGP Route Reflector Basics


Everyone who ever studied BGP knows that BGP has strong rules to prevent routing and updates loops. In this post I will focus on iBGP loop prevention and specifically route reflectors as a result.

The rule states: that any route received from an iBGP neighbor must not be advertised to any other iBGP neighbor.

This loop prevention mechanism induces a requirement that all iBGP routers in the network should be connected in logical full mesh topology to allow for routing information propagation through out the network. However, full mesh connectivity has never been a scalable solution specially in large networks.

Two mechanisms were introduced to solve the scalability problem, by eliminating the need for the full mesh and in the same time keep the network loop free. The first solution is BGP confederations and the second one is BGP route reflectors, Which is going to be out topic for this post.

BGP route reflectors:

A route reflector is BGP router that is allowed to break the iBGP loop avoidance rule. Route reflectors can advertise updates received from an iBGP peer to another iBGP peer under specific conditions.

By breaking the rules, route reflectors are used to eliminate the full mesh requirement and allow for building iBGP networks that scale easily and cleanly.

How is this accomplished?

BGP Route Reflector follows the below listed rules to achieve this goal:

  • iBGP routers are divided into Route Reflectors, Route Reflector clients and non-client Peers.
  • Routes received from a Route-Reflector-client is reflected to other clients and non-client neighbors.
  • Routes received from non-client neighbors are reflected to Route-Reflector-client neighbors only.
  • Setting the Originator-ID attribute in the reflected update if it is not already set.
  • Adding the Cluster-ID  to the Cluster-list attribute in the reflected update.
  • A Route Reflector reflects routes considered as best routes only. If more than one update is received for the same destination,  only the BGP best route is reflected.
  • A Route Reflector is not allowed to change any attributes of the reflected routes including the next-hop attribute.

Route Reflectors and Loop Prevention:

The following rules are used to detect and avoid routing loops caused by route reflection:

  • If a router received an iBGP route with the Originator-ID attribute set to its own router-id, the route is discarded.
  • If a route reflector receives a route with a cluster-list attribute containing its cluster-id, the route is discarded.

For more information about route reflectors check RFC 2796.

I hope it was simple enough, now lets get to see the configuration and verification section. Watch the video below:

BGP Route Reflectors

This movie requires Flash Player 9

I hope I have been informative in this post, please let me know if any questions, ideas or corrections.


No related posts.


You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

AddThis Social Bookmark Button

18 Responses to “BGP Route Reflector Basics”

  1. It’s a good explanation.

  2. Very concise and clear.

  3. [...] control plane routers like (Route Reflectors) from being used accidentally in the forwarding [...]

  4. Good explanation thanks a lot

  5. Thank you. Its loud and clear :)

  6. Let’s say a 3-router AS contains a single RR. The other 2 routers are clients of the RR. What happens if the RR fails? Will the 2 clients of the RR eventually realize the failure, and revert to full-mesh IBGP with each other?

  7. Nice explaination

  8. Very good explanation…!!!

  9. Trevene Leonard Says:

    This is very informative. Thank you

  10. Kevin: the only neighbor that RR Client is configured to see is the RR as a regular iBGP neighbor (route reflector clients don’t know they are the clients; all the RR specific configuration is on the RR).
    Therefore, in your example the RR is a single point of failure. You may want to configure cluster with two RRs to avoid this.

  11. Brute-force Says:

    Let’s say your route-reflector client has an EBGP peer.
    Does the route-reflector client advertise prefixes received from Route-Reflector automatically to it’s EBGP peer without any network statement?

  12. Good Explanation. Just curious, if there is any involvement of AS-PATH during RR operation.

  13. Dear all,

    It’s a good and simple way of explaning RR and operation of RR.

    I have a question..

    If a RR received a ASN X route from two different clients than is RR reflect route received from one client to other.
    I considered, 1st client route is best.

  14. Brute-Force – Yes, the route reflector client will advertise a route received from the RR to its EBGP peer. No network statement required.

    Sagar – No AS-Path change during IBGP or IBGP RR operation. It will only be prepending when leaving the AS when advertised to an EBGP peer.

  15. Same 30 clients for each RR.

    If 3 RR ( geographically diversed) with independent cluster ID is implemented vs 3 RR with same cluster ID any advantage or major disadvantage ?

  16. To Wael Osama,
    Correct me if am wrong, In the above video for R4 bgp configuration the popup as to say R3 as a normal iBGP peer
    not R4 as a normal iBGP peer.

  17. Noman Malik Says:

    Problem: R1 and R4 not receiving advertised routes from RR’s, also RR’s (R2 and R3) are receiving only single best route.

    Could you please anyone help me to solve this issue:

    Configurations are give below:

    R#1
    router bgp 20
    no synchronization
    bgp log-neighbor-changes
    network 200.100.50.0
    neighbor 1.1.1.2 remote-as 20
    no auto-summary

    R2#
    router bgp 20
    no synchronization
    bgp log-neighbor-changes
    neighbor 1.1.1.1 remote-as 20
    neighbor 1.1.1.1 route-reflector-client
    neighbor 2.1.1.2 remote-as 20
    no auto-summary

    R3#
    router bgp 20
    no synchronization
    bgp log-neighbor-changes
    neighbor 2.1.1.1 remote-as 20
    neighbor 3.1.1.2 remote-as 20
    neighbor 3.1.1.2 route-reflector-client
    no auto-summary

    R4#
    router bgp 20
    no synchronization
    bgp log-neighbor-changes
    network 200.100.200.0
    neighbor 3.1.1.1 remote-as 20
    no auto-summary

    R1# sh ip bgp
    Network Next Hop Metric LocPrf Weight Path
    *> 200.100.50.0 0.0.0.0 0 32768 i

    R2# sh ip bgp
    Network Next Hop Metric LocPrf Weight Path
    *>i200.100.50.0 1.1.1.1 0 100 0 i
    * i200.100.200.0 3.1.1.2 0 100 0 i

    R3# sh ip bgp
    Network Next Hop Metric LocPrf Weight Path
    * i200.100.50.0 1.1.1.1 0 100 0 i
    *>i200.100.200.0 3.1.1.2 0 100 0 i

    R4# sh ip bgp
    Network Next Hop Metric LocPrf Weight Path
    *> 200.100.200.0 0.0.0.0 0 32768 i

  18. very simple and clear. thanks a lot

Leave a Reply