BGP route reflectors, used as an alternate method to full-mesh IBGP, help in scaling.
BGP route reflector cluster 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 our specialized 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 neighbor with each other. However, the route reflector is an exception.
If you place a BGP Route Reflector, the IBGP router sets up a BGP neighborship with only the route reflectors.
In this article, I will specifically mention the route reflector clusters and their design.
For those who want to understand BGP Route Reflectors, I highly recommend my BGP Route Reflector in Plain English post.
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 originated from the route reflector itself, then the route reflector does not create a cluster list. If the route is sent to an EBGP peer, RR removes the cluster list information.
If the route is received from an EBGP peer, RR does not create a cluster list attribute.
Why is BGP Route Reflector Cluster list used?
A RR 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, Are the 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 1.1.1.1 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 1.1.1.1 as cluster ID attributes that they send to each other. However, since they use the 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 are learned only from the R1-R4 direct IBGP session by the R1 (R1 rejects from R2). Of course, the 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 go down as well. Thus, the networks behind R4 cannot be learned.
Since, the routes cannot be learned from R2 (the same cluster-ID), if the physical link is up and the 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. That's why the 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 the 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, the IGP path will change to R1-R4 rather than to R1-R2-R4.
In a situation in which the R1-R4 physical link fails, the IBGP session will not go down if the IGP converges to the R1-R2-R4 path quicker than the BGP session timeout (By default it does).
Thus, having the same cluster-ID on the RRs saves a lot of memory and CPU resources 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 IDs on R1 and R2, R1 would accept reflected routes from R2 in addition to the routes from direct peering with R4.
Conclusion
Orhan Ergun recommends the 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 a different Cluster ID provides faster convergence in some cases (Depending 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 our Service Provider Networks Design and Architecture Perspective Book.