Reliability and redundancy are important issues when using route reflection because the members of a cluster are not fully meshed so its very much necessary for the route-reflectors to be peers to each other.Each cluster has an identifying number, the cluster ID. For clusters with a single route reflector, the cluster ID is the router ID of the route reflector, otherwise you configure the cluster ID.its basically for cluster list to prevent looping
"Usually a cluster of clients will have a single route reflector. In that case, the cluster is identified by the router ID of the route reflector. To increase redundancy and avoid a single point of failure, a cluster might have more than one route reflector. In this case, all route reflectors in the cluster must be configured with the 4-byte cluster ID so that a route reflector can recognize updates from route reflectors in the same cluster. All the route reflectors serving a cluster should be fully meshed and all of them should have identical sets of client and nonclient peers.
If the cluster has more than one route reflector, configure the cluster ID by using the following command in router configuration mode: "
Let me tell u first that it is not just a practice,it plays a very important role in handling many BGP attributes like next-hop,local-preference,MED etc like as iBGP is used between RR's,the attributes mentioned above are not changed,they are preserved actually and are passed as it is.Because there is fully-meshed iBGP peering between RR's,a RR does not readvertise the learned prefix from a non-client peer to another.
I still do not see the reason why there must be a full mesh of the route-reflectors within a cluster. Now for multiple clusters, I will expect the full mesh since we can look at each cluster as a BGP router. Then the iBGP full mesh requirement kicks in.
But within a cluster, lets assume we have 3 route reflectors, with the cluster id rightly configured, and they have identical peers and clients. If this route reflectors peer with each other, they will not reflect the routes to their clients because they will notice that it is from their cluster. Neither will they advertise it to other peers, which is a standard iBGP operation.
So, I do not even see the advantage of mesh of the route-reflector within a cluster.
Like John and Anand mentioned, the RRs will reflect the route to the neighbours in same cluster too. This would mean RR1 will send an update to RR2. RR2 will reject the route noticing that it is from the same cluster id.
Please note that that RR will also send the udpate to the neighbor from which it received the route. It is then job of the PE router to reject the route noting its own id as Originator id.
1. Introduction Internet security is important with the increasing
attacks that are happening every day. Many internet and browsing
security solutions exist, but some are not very easy to use or maybe the
question is how can I enable them? In this referen...
Cisco Software Manager Server API Guide This document describes the
programmatic interfaces, RESTful APIs, which are supported by Cisco
Software Manager Server (CSM Server). Overview CSM Server supports a set
of finite RESTful APIs. The first step to use ...
If you are using Cisco's new linux-based Cisco Software Manager server,
then you probably want to make sure there is a startup service for
it.I'll assume that you've already installed the CSM server on a
systemd-based linux system. The commands given belo...