RR Clustering Design

Proper clustering is very important to provide desired redundancy in an RR-based architecture. Consider the topology on the left side of Figure, in which two RRs use the same cluster ID. When the prefix 172.16.0.0/16 is advertised from R4, two RRs advertise to R1 and to each other. However, the updates between RRs are discarded because they are in the same cluster.
Obviously two RRs provide redundancy to clients, but is that enough? The answer depends on how RRs are configured, as explained in this section. R1 has two BGP paths to the destination—one learned from R2 and the other learned from R3. Between the two paths, R1 picks one best path—perhaps the path via R2 (it does not make any difference for this
discussion which path is the best path).

Now assume that the BGP next hop can be reached via two equal-cost IGP paths. R1 loadshares the packets using these two IGP paths. So far everything is fine. Lets say that the iBGP session between R4 and R3 is down, perhaps due to misconfiguration or administrative shutdown. While R2 continues to forward the traffic as before, the traffic via R3 is discarded because it has no path for the prefix, even though the physical link between R3 and R4 is still functioning. This results in about 50% packet loss.
To correct the problem, consider the design on the right of Figure. In this design, two RRs are in different clusters. In the case of iBGP session failure between R4 and R3, R3 continues to forward the traffic, because the prefix is also learned from R2. This design not only provides physical redundancy against a link failure but also provides logical redundancy against a failure of the iBGP session between a client and an RR. Note however that this design leads to more memory use due to the extra path.