Problem: Loss of Redundancy Between Route Reflectors and Route-Reflector Client-Cause: Cluster List Check in RR Drops Redundant Route from Other RR

Problem: Loss of Redundancy Between Route Reflectors and Route-Reflector Client ‚ Cause: Cluster List Check in RR Drops Redundant Route from Other RR

A cluster is made up of an RR and its clients . A cluster can have one or more RR and is identified by a cluster ID that is the router ID of the RR. Because each RR has a unique router ID, each cluster has only one RR by default. Network operators must manually configure identical cluster IDs on two or more RRs to configure them in the same cluster. When a BGP update traverses from an RR to other neighbors, RR adds its cluster ID in the list called the cluster list, which contains all cluster IDs that any BGP update has traversed. The cluster list is synonymous with the AS_PATH list, which contains AS lists that any update has traversed. Just as in AS_PATH loop detection, in which updates are dropped if the AS_PATH contains a local AS, the cluster list detects loops if they contain a local cluster ID.

When a route-reflector client is connected to two different RRs that are in the same cluster, chances are good that the RR will not see the redundant path to the clients.

Figure 15-32 shows two RRs configured in the same cluster. Any update one received from the other that has its own cluster ID in the cluster list will be dropped.

Figure 15-32. Route Reflectors Configured with the Same Cluster ID, Resulting in Loss of Redundancy

Figure 15-32 shows how an RR and an RRC are connected in a single cluster. Each RR must be configured with same cluster ID, as shown in the "Debugs and Verification" section. R8 is advertising 100.100.100.0/24 to its IBGP neighbors R1 and R2, which are RRs for R6 and R8, and reflects 100.100.100.0/24. R1 reflects to R6 and R2, whereas R2 reflects to R1 and R6. Because they both are configured with the same cluster ID 109, the cluster list from both RRs will contain cluster ID 109, represented as 0.0.0.109 in Cisco IOS Software output.

Figure 15-33 illustrates how the RR loses redundancy to the client.

Figure 15-33. How an RR Rejects Routes That Fail the Cluster ID Check

Debugs and Verification

Example 15-66 shows the configuration of the two RRs when they are configured with identical cluster IDs of 109.

Example 15-66 RRs Configured with Identical Cluster IDs

 R1#  router bgp 109   no synchronization    bgp cluster-id 109    neighbor 172.16.18.8 remote-as 109   neighbor 172.16.18.8 route-reflector-client   neighbor 172.16.126.2 remote-as 109   neighbor 172.16.126.6 remote-as 109   neighbor 172.16.126.6 route-reflector-client  _____________________________________________________________________________________ R2#  router bgp 109   no synchronization    bgp cluster-id 109    neighbor 172.10.28.8 remote-as 109   neighbor 172.10.28.8 route-reflector-client   neighbor 172.16.126.1 remote-as 109   neighbor 172.16.126.6 remote-as 109  neighbor 172.16.126.6 route-reflector-client 

As depicted in Figure 15-33, R8, an RRC, advertises 100.100.100.0/24 to both of its RRs, R1 and R2. When R1 and R2 are configured with the same cluster ID, R1 and R2 have only a single update in their BGP table for 100.100.100.0/24, learned from the RRC itself.

Example 15-67 shows that the RRs have only a single entry in their BGP tables for network 100.100.100.0/24, and this entry is from the RRC.

Example 15-67 RRs R1 and R2 Have Only One Update for 100.100.100.0/24, Resulting in Loss of Redundancy

 R1#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table) Flag: 0x208   Advertised to non peer-group peers:   131.108.10.2 131.108.10.6   Local, (Received from a RR-client)     131.108.10.8 from 131.108.10.8 (131.108.10.8)       Origin IGP, metric 0, localpref 100, valid, internal, best R1# _____________________________________________________________________________________ R2#  show ip bgp  100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table)   Advertised to non peer-group peers:   131.108.10.1 131.108.10.6   Local, (Received from a RR-client)     131.108.10.8 from 131.108.10.8 (131.108.10.8)       Origin IGP, metric 0, localpref 100, valid, internal, best\ 

Each RR has an update for 100.100.100.0/24 only from R8, not from the other RR.

Example 15-68 shows the output of debug ip bgp update from R2. Notice that R2 is dropping the update for 100.100.100.0/24 from R1 because it sees its own cluster ID, 109, (represented as 0.0.0.109) in the cluster list.

Example 15-68 debug ip bgp update Command Output from R2

 R1#  debug ip bgp update  *Mar  3 11:29:11: BGP(0): 172.16.10.8 rcvd UPDATE w/ attr: nexthop 172.16.10.8, origin i, localpref 100, metric 0 *Mar  3 11:29:11: BGP(0): 172.16.10.8 rcvd 100.100.100.0/24 *Mar  3 11:29:11: BGP(0): Revise route installing 100.100.100.0/24 -> 172.16.10. 8 to main IP table *Mar  3 11:29:11: BGP: 172.16.126.1 RR in same cluster. Reflected update dropped *Mar  3 11:29:11: BGP(0): 172.16.126.1 rcv UPDATE w/ attr: nexthop 172.16.10.8, origin i, localpref 100, metric 0, originator 172.16.8.8,  clusterlist 0.0.0.109  ,         path, community, extended community *Mar  3 11:29:11: BGP(0): 172.16.126.2 rcv UPDATE about 100.100.100.0/24  -- DENIED   due to: reflected from the same cluster;  

Solution

If a link or IBGP connection between R8 and R2 goes down, R2 has no way to reach 100.100.100.0/24. This is because R2 has rejected the 100.100.100.0/24 advertisement from R1 as a result of the cluster list check.

It is recommended that in cases similar to those depicted in Figure 15-33, RRs should not be put in the same cluster. The cluster ID will be picked as the router ID (RID) of each RR and is guaranteed to be unique because all RIDs are unique in any network.

Example 15-69 shows the configuration of all RRs and RRCs, which are in different clusters. Example 15-69 also shows the configuration in R8 to advertise 100.100.100.0/24 to R1 and R2. Example 15-69 displays the output from the BGP table. Output from R1 and R2 shows that each has a redundant path for 100.100.100.0/24, one directly to R8 and the other one through each other. If a link or BGP session between R1 and R8 is lost, R1 has a backup path through R2 to reach R8.

Example 15-69 Unique Router ID of Each RR Will Make Unique Cluster ID per RR

 R1#  router bgp 109  no synchronization  neighbor 131.108.10.8remote-as 109  neighbor 131.108.10.8route-reflector-client  neighbor 131.108.10.6remote-as 109  neighbor 131.108.10.6route-reflector-client  neighbor 131.108.10.2remote-as 109 _____________________________________________________________________________________ R2#  router bgp 109  no synchronization  neighbor 131.108.10.8remote-as 109  neighbor 131.108.10.8route-reflector-client  neighbor 131.108.10.6remote-as 109  neighbor 131.108.10.6route-reflector-client  neighbor 131.108.10.1remote-as 109 _____________________________________________________________________________________ R8#  router bgp 109  no synchronization  neighbor 131.108.10.1remote-as 109  neighbor 131.108.10.2remote-as 109 _____________________________________________________________________________________ R6#  router bgp 109  no synchronization  neighbor 131.108.10.1remote-as 109  neighbor 131.108.10.2remote-as 109 _____________________________________________________________________________________ R8#  router bgp 109  no synchronization  network 100.100.100.0 mask 255.255.255.0  neighbor 131.108.10.1 remote-as 109  neighbor 131.108.10.2remote-as 109 ! ip route 100.100.100.0 255.255.255.0 Null0 R8#  show ip bgp  100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 6 Paths: (1 available, best #1, table Default-IP-Routing-Table) Flag: 0x208   Advertised to non peer-group peers:   131.108.10.1 131.108.10.2   Local     0.0.0.0 from 0.0.0.0 (131.108.10.8)   Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local,Best _____________________________________________________________________________________ R1#  show ip bgp  100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 2 Paths: (2 available, best #2, table Default-IP-Routing-Table)   Advertised to non peer-group peers:   131.108.10.2 131.108.10.6  Local  131.108.10.8  (metric 20) from 131.108.10.2 (131.108.10.8)       Origin IGP, metric 0, localpref 100, valid, internal       Originator: 131.108.10.8, Cluster list: 131.108.10.2   Local, (Received from a RR-client)  131.108.10.8  from 131.108.10.8 (131.108.10.8)   Origin IGP, metric 0, localpref 100, valid, internal, best _____________________________________________________________________________________ R2#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 2 Paths: (2 available, best #2, table Default-IP-Routing-Table)   Advertised to non peer-group peers:   172.16.126.1 172.16.126.6   Local  131.108.10.8  (metric 20) from 131.108.10.1 (131.108.10.8) Origin IGP, metric 0, localpref 100, valid, internal       Originator: 131.108.10.8, Cluster list: 131.108.10.1  Local, (Received from a          RR-client)  131.108.10.8  from 131.108.10.8 (131.108.10.8)       Origin IGP, metric 0, localpref 100, valid, internal, best 

Both R1 and R2 have a redundant path to reach 100.100.100.0/24 only because of a unique cluster ID. The example shows picking a unique cluster ID from a unique router ID; an alternate way to ensure cluster ID uniqueness would be to manually configure a unique cluster ID per RR.