BGP Route Reflector Clusters

BGP route reflectors, used as an alternate method to full mesh IBGP, help in scaling.

BGP route reflector clustering is used to provide redundancy in a BGP RR design. BGP Route reflectors and RR clients create a cluster. (Cluster = BGP RR + BGP RR Clients)

I am explaining this topic in deep detail in my Onsite CCDE Live/Webex CCDE  Self Paced CCDE  and also my specialized “Live/Webex BGP Zero to Hero” course.

In IBGP topologies, every BGP speaker has to be in a logical full mesh. So, every BGP router has to have a direct IBGP neighborship with each other. However, route reflector is an exception.


If you place a BGP Route Reflector , IBGP router sets up BGP neighborship with only the route reflectors.


In this article, I will specifically mention the route reflector clusters and its design.


For those who want to understand BGP Route Reflectors, I highly recommend my ‘ BGP Route Reflector in Plain English ‘ post.


If you want to learn Route Reflector Loop Problem , check this post


Also, I explained BGP Route Reflectors, Route Reflector Design Options and many other Service Provider Design topic in my Service Provider Design Workshop.



What is BGP Route Reflector Cluster ID ?



Route Reflector Cluster ID is a four-byte BGP attribute, and, by default, it is taken from the Route Reflector’s BGP router ID.


If two routers share the same BGP cluster ID, they belong to the same cluster.


Before reflecting a route, route reflectors append its cluster ID to the cluster list. If the route is originated from the route reflector itself, then route reflector does not create a cluster list.


If the route is sent to EBGP peer, RR removes the cluster list information.


If the route is received from EBGP peer, RR does not create a cluster list attribute.


Why Cluster list it used ?


Cluster list is used for loop prevention by only the route reflectors. Route reflector clients do not use cluster list attribute, so they do not know to which cluster they belong.



If there are two Route Reflectors, Is same or different cluster IDs better on the Route Reflectors ?


If RR receives the routes from an IBGP neighbor which has the same cluster ID, routes are discarded.


Let’s start with the basic topology.


BGP Route Reflector Cluster Same CLuster ID

Figure-1  Route Reflector uses same cluster id



In the diagram shown above in fig.1, R1 and R2 are the route reflectors, and R3 and R4 are the RR clients. Both route reflectors use the same cluster ID.


Green lines depict physical connections. Red lines show IBGP connections.


Assume that we use both route reflectors as cluster ID which is R1’s router ID.


R1 and R2 receive routes from R4.

R1 and R2 receive routes from R3.



Both R1 and R2 as route reflectors appends as cluster ID attributes that they send to each other. However, since they use same cluster, they discard the routes of each other.


That’s why, if RRs use the same cluster ID, RR clients have to connect to both RRs.



In this topology, routes behind R4 is learned only from the R1-R4 direct IBGP session by the R1 (R1 rejects from R2). Of course, IGP path goes through R1-R2-R4, since there is no physical path between R1-R4.


If the physical link between R2 and R4 goes down, both IBGP sessions between R1-R4 and R2-R4 goes down as well. Thus, the networks behind R4 cannot be learned.


Since, the routes cannot be learned from R2 (the same cluster ID), if physical link is up and IBGP session goes down between R1 and R4, networks behind R4 will not be reachable either, but if you have BGP neighborship between loopbacks and physical topology is redundant , the chance of IBGP session going down is very hard.


Note : Having redundant physical links is a common network design best practice. Thats why below topology is a more realistic one.



What if we add a physical link between R1-R4 and R2-R3 ?


BGP Route Reflector Clusters Same Cluster-ID with excessive redundancy


 Figure-2 Route Reflector uses same cluster-ID, physical cross-connection is added between the RR and RR clients



In Figure-2  physical cross-connections are added between R1-R4 and R2-R3.


Still, we are using the same BGP cluster ID on the route reflectors.


Thus, when R2 reflects R4 routes to R1, R1 will discard those routes. In addition, R1 will learn R4 routes through direct IBGP peering with R4. In this case, IGP path will change to R1-R4 rather than to R1-R2-R4.


In a situation in which R1-R4 physical link fails, IBGP session will not go down if the IGP converges to R1-R2-R4 path quicker than BGP session timeout (By default it does).


Thus, having the same cluster ID on the RRs saves a lot of memory and CPU resource on the route reflectors even though link failures do not cause IBGP session drop if there is enough redundancy in the network.


If we would use different BGP cluster ID on R1 and R2, R1 would accept reflected routes from R2 in addition to the routes from direct peering with R4.





Orhan Ergun recommends Same BGP Cluster ID for the Route Reflector redundancy if there is a resource issue on the Route Reflectors. If there is no resource problem , having different Cluster ID provides faster convergence in some cases (Depend on the topology)


Otherwise, Route reflectors would keep an extra copy for each prefix which wouldn’t be advertised to Route Reflector clients anyway.

To have a great understanding of SP Networks, you can check my new published “Service Provider Networks Design and Perspective” Book. It covers the SP network Technologies with also explaining in detail a factious SP network.  Click here




29 Replies to “BGP Route Reflector Clusters”

  1. We have a MAN consisting of eight routers runnning iBGP and using two route reflectors within the same cluster. This MAN is connected to two other autonomous systems. Although there are many improvements possible in the rather bad design (I did not design in) I did not yet look into the decision of whether to use a single cluster with two route reflectors or two clusters with one RR each. There is physical redundancy in place however, so maybe there is no real need for two clusters.

    1. @Tom, If there is physical redundancy for the BGP next hop having one cluster is sufficient as I explained in the post as well.

      1) Two questions to you, Why for the 8 routers you use Route reflectors ?
      2) What do you mean improvements for the RR ( advertisement multiple path ?, separating services ? ) ?

  2. We have a MAN consisting of eight routers runnning iBGP and using two route reflectors within the same cluster. This MAN is connected to two other autonomous systems. Although there are many improvements possible in the rather bad design (I did not design in) I did not yet look into the decision of whether to use a single cluster with two route reflectors or two clusters with one RR each. There is physical redundancy in place however, so maybe there is no real need for two clusters.

  3. Juicy article Cluster list save us from loop while having same cluster id on RR, problem will get increase and what i understand same cluster id would be bad design and resources intensive.

    1. @Haroon Same cluster ID is not a bad design, in contrast it is a better design. Since you will not need extra memory and CPU to handle the prefixes which would come from the other RR, it is nice.
      On the other hand, If it is IP only network, IBGP topology should follow the physical topology of the network. Otherwise, if you are lucky you have suboptimal routing. Worse, it creates persistent routing loop.
      In our topology it is not a problem , do you see why ?

      1. @Orphan, why did you say IP only network in regards to loops and suboptimal routing. Wouldn’t it be the case for any destination-based forwarding network?
        BTW, it’d be interesting to see a post highlighting bad RR designs and the specific errors they may lead to.

  4. Hi Orhan,

    Nice post !! you cannot have a persistent loop because you follow the physical topology.
    With MPLS RR you don’t have this problem the packets toward the BGP next hops always carry an LDP-generated label for the BGP next hop.


  5. “If the routes received with the same cluster ID by the RR, it is discarded” so why do we need an ibgp session between R1 and R2 if they each discard routes learned from eachother, in this specific topology with 4 routers only

    1. Hi Djahem,

      You need an IBGP session between R1 and R2 to send their client BGP routes.You can either use same or different cluster IDs. Use same cluster ID for the same tier route reflectors as per my suggestion.


      1. Hi Orhan,

        Continuing djahem question…
        From figure2, R1 has IBGP session with R3 and R4. R2 also has IBGP session with R3 and R4. Why still we need IBGP between R1 and R2?


        1. @Niko, thanks for the comment. If the physical connections between RR and RR Clients fail , then how you would send the traffic between the RR Clients ? That’s why you need that. Unless you redistribute BGP into IGP, which you don’t do except specific applications.


          1. Hi Orhan,

            Thanks for your response. I hope you don’t mind if I want to discuss more about this. In figure 2, enable IBGP session between RR1 and RR2. If R1 lose connections with R3 and R4, R1 will not accept any bgp routes from R2 since they have same Cluster ID.


        2. In case of 2 RR’s in BGP domain using different Cluster-ID, on each RR peer full-mesh with clients. Is peering between two RR’s nesscessary?

          1. Yes, Regular IBGP session is created between RRs , preferably for each NLRI (IPv4, IPv6 etc).

            We create that IBGP session , because for certain failure scenarios , Other RRs , RR Clients or Non-Clients may not be able to receive the prefixes and they can be isolated.

  6. Hi Orphan,

    Having redundant RR is good but here it’s not giving us the failover functionality. Like you mentioned, let’s say if the link between R2 – R4 is up but IBGP between R1-R4 is not forming, then R1 will not learn the route from R2 because of loop prevention.

    Are there any way to fix this by giving failover?


    1. Thanks Uday for the comment, if there is no IBGP session between R1-R4 in the same cluster ID case , then there is no fix for failover, you need to use a different cluster ID.
      By the way it is Orhan 🙂

      1. Hello Orhan,

        Nice post. But isn’t the point of having multiple RRs,is to have redundancy ? What good does it do me if the iBGP session between R1-R4 fails and networks behind R4 are still unreachable because R1 will discard routes from R2? I might as well just have one RR.

  7. Orhan,
    How would you overcome double failure between the RR and the RR clients if you use the same cluster-id? So, If R4 loses the iBGP to R1 and R3 loses the IBGP to R2, How will R3 get the routes that R4 advertises.

  8. Hi Orhan,

    Do the RRs have to be clients of each other? What will happen if the two RRs are in the same cluster and configured as clients of each other as well?


Leave a Reply

Your email address will not be published.