This will be a short post. This post is just to supply a somewhat detailed answer to a tweet I sent out earlier this evening.
When you have 3 iBGP routers. One of them is a route reflector. The other two are clients. If the cluster-id of the route reflector is the same as the router-id of one of the clients. What will happen when the client receives an update from the route reflector?
So, two clients, one RR. Configured as follows:
Route Reflector (R7): router bgp 678 bgp cluster-id 18.104.22.168 bgp log-neighbor-changes neighbor 192.168.76.6 remote-as 678 neighbor 192.168.76.6 route-reflector-client neighbor 192.168.87.8 remote-as 678 neighbor 192.168.87.8 route-reflector-client ! R7#show ip bgp BGP table version is 3, local router ID is 22.214.171.124 ! R7#show ip bgp cluster Global cluster-id: 126.96.36.199 (configured: 188.8.131.52) Client 1(R6): router bgp 678 bgp log-neighbor-changes network 184.108.40.206 mask 255.255.255.255 neighbor 192.168.76.7 remote-as 678 ! R6#show ip bgp BGP table version is 2, local router ID is 220.127.116.11 Client 2(R8): router bgp 678 bgp log-neighbor-changes network 18.104.22.168 mask 255.255.255.255 neighbor 192.168.87.7 remote-as 678 ! R8#show ip bgp BGP table version is 2, local router ID is 22.214.171.124
The question is whether R6 know the route to R8’s loopback. We can see from the configuration and the show commands that the BGP cluster-id on R7 is the same as the BGP router-id on R6. We also see that the router-id on R7 is 126.96.36.199.
Normally, when you don’t configure anything the cluster-id of a route reflector is set to the router-id of the router.
The cluster ID is used by BGP route reflectors to drop updates it receives that it has reflected itself earlier. So it’s a loop prevention method.
What happens when you configure a cluster-id that is used somewhere else in the network…?
The answer is: It gets dropped by the receiving client. Even though the client has not been configured as a route reflector it still has a cluster-id:
R6#show ip bgp clus Global cluster-id: 188.8.131.52 (configured: 0.0.0.0)
When enabling debugging we can see R6 dropping the update with the message “DENIED due to: reflected from the same cluster”
*Feb 26 20:44:29.349: BGP: 192.168.76.7 RR in same cluster. Reflected update dropped *Feb 26 20:44:29.349: BGP(0): 192.168.76.7 rcv UPDATE w/ attr: nexthop 192.168.87.8, origin i, localpref 100, metric 0, originator 184.108.40.206, clusterlist 220.127.116.11, merged path , AS_PATH , community , extended community , SSA attribute *Feb 26 20:44:29.349: BGPSSA ssacount is 0 *Feb 26 20:44:29.349: BGP(0): 192.168.76.7 rcv UPDATE about 18.104.22.168/32 -- DENIED due to: reflected from the same cluster;