When there is BGP scalability issues in a large autonomous system, Route Reflectors (RR) and Confederations are often implemented as a solution. One of the main advantages of RR over confederations is that all routers in a confederation must support this technology but only RR themselves must understand route reflection. What this means is that the client routers see their connection to the RR as just another IBGP peer connection. Route reflection is also simpler to implement, both in terms of configuration and in avoiding topology issues.
Together, a RR and its clients form a cluster. The BGP CLUSTER_LIST attribute is used as a loop-prevention measure when there’s multiple RR in a cluster. By default, the RR enters its own BGP RID in the CLUSTER_LIST and if a router receives an update with its own cluster ID in the CLUSTER_LIST, it understands that a loop has occurred and ignores the route. It is current best practice to leave this attribute as it is, because a router’s RID will usually be unique in a well-designed network topology.
The bgp cluster-id command can be used to set the cluster-id and thus allow all RR in a cluster to recognize updates from peers in the same cluster. It will also reduce the number of updates that need to be stored in the BGP routing tables. If you use this command it will be used as a loop prevention mechanism but it also means that, if a downstream router loses peering to one of the RR, the route will NOT pass the second RR back to the first. This will have for effect of negating the redundancy offered by the second RR in the cluster. So when do we set the cluster-id? Most of the time you won’t and the default settings will suffice as loop prevention mechanism. The only time you would use this is if you were in a situation where you would want to prefer a RR over another for route-selection. This happens because the CLUSTER_LIST attribute comes higher in the decision process over the neighbor address attribute.
Hope this was informative.