BGP route reflector challenge answer

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 6.6.6.6
 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 7.7.7.7
!
R7#show ip bgp cluster
Global cluster-id: 6.6.6.6 (configured: 6.6.6.6)


Client 1(R6):
router bgp 678
 bgp log-neighbor-changes
 network 6.6.6.6 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 6.6.6.6

Client 2(R8):
router bgp 678
 bgp log-neighbor-changes
 network 8.8.8.8 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 8.8.8.8

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 7.7.7.7.

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: 6.6.6.6 (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 8.8.8.8, clusterlist 6.6.6.6, 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 8.8.8.8/32 -- DENIED due to: reflected from the same cluster;