Usually, a cluster of clients will have a single RR. In this case, the cluster will be identified by the router ID of the RR. In order to increase redundancy and avoid single points of failure, a cluster might have more than one RR. All RRs in the same cluster need to be configured with a 4 byte cluster−id so that a RR can recognize updates from RRs in the same cluster.
A cluster−list is a sequence of cluster−ids that the route has passed. When a RR reflects a route from its clients to non−clients outside of the cluster, it will append the local cluster−id to the cluster−list. If this update has an empty cluster−list the RR will create one. Using this attribute, a RR can identify if the routing information is looped back to the same cluster due to poor configuration. If the local cluster−id is found in the cluster−list, the advertisement will be ignored.
In the above diagram, RTD, RTE, RTF and RTH belong to one cluster with both RTD and RTH being RRs for the same cluster. Note the redundancy in that RTH has a fully meshed peering with all the RRs. In case RTD goes down, RTH will take its place. The following are the configuration of RTH, RTD, RTF and RTC:
RTH#Note that we did not need the cluster command for RTC because only one RR exists in that cluster. An important thing to note, is that peer−groups were not used in the above configuration. If the clients inside a cluster do not have direct IBGP peers among one another and they exchange updates through the RR, peer−goups should not be used. If peer groups were to be configured, then a potential withdrawal to the source of a route on the RR would be sent to all clients inside the cluster and could cause problems.
router bgp 100
neighbor 4.4.4.4 remote−as 100
neighbor 5.5.5.5 remote−as 100
neighbor 5.5.5.5 route−reflector−client
neighbor 6.6.6.6 remote−as 100
neighbor 6.6.6.6 route−reflector−client
neighbor 7.7.7.7 remote−as 100
neighbor 3.3.3.3 remote−as 100
neighbor 9.9.9.9 remote−as 300
bgp route−reflector 10 (This is the cluster−id)
RTD#
router bgp 100
neighbor 10.10.10.10 remote−as 100
neighbor 5.5.5.5 remote−as 100
neighbor 5.5.5.5 route−reflector−client
neighbor 6.6.6.6 remote−as 100
neighbor 6.6.6.6 route−reflector−client
neighbor 7.7.7.7 remote−as 100
neighbor 3.3.3.3 remote−as 100
neighbor 11.11.11.11 remote−as 400
bgp route−reflector 10 (This is the cluster−id)
RTF#
router bgp 100
neighbor 10.10.10.10 remote−as 100
neighbor 4.4.4.4 remote−as 100
neighbor 13.13.13.13 remote−as 500
RTC#
router bgp 100
neighbor 1.1.1.1 remote−as 100
neighbor 1.1.1.1 route−reflector−client
neighbor 2.2.2.2 remote−as 100
neighbor 2.2.2.2 route−reflector−client
neighbor 4.4.4.4 remote−as 100
neighbor 7.7.7.7 remote−as 100
neighbor 10.10.10.10 remote−as 100
neighbor 8.8.8.8 remote−as 200
The router sub−command bgp client−to−client reflection is enabled by default on the RR. If BGP
client−to−client reflection were turned off on the RR and redundant BGP peering was made between the clients, then using peer groups would be alright.
