Problem: Route-Reflector Client Stores an Extra BGP Update-Cause: Client-to-Client Reflection

Problem: Route-Reflector Client Stores an Extra BGP Update ‚ Cause: Client-to-Client Reflection

The problem here stems from RRCs receiving extra BGP updates, which consume extra memory and take up CPU to process them.

In Figure 15-28, RRC R8 peers IBGP with RR R1; R8 is peering IBGP with RRC R2 as well. Because of this peering relationship, R2 receives an extra BGP update for all the routes originated/propagated by R8. Such a setup typically is done when a physical circuit exists between RRCs and the BGP operator wants to run BGP directly over them. In standard network design, such BGP connections between RRCs do not exist, and all RRCs simply peer with their respective route reflector(s) only.

Figure 15-28. Client-to-Client IBGP Peering in Addition to Route Reflector Setup

Figure 15-29 shows the flowchart to follow to resolve this problem.

Figure 15-29. Problem-Resolution Flowchart

Debugs and Verification

The output in Example 15-61 shows that R2 is receiving two updates for 100.100.100.0, one from R8 and another reflected from R1.

Example 15-61 R2's BGP Table Indicates Updates Received from Both the RR and Another RRC

 R2#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 3 Paths: (2 available, best #1, table Default-IP-Routing-Table)   Not advertised to any peer   Local      131.108.10.8 (metric 20) from 131.108.10.8 (131.108.10.8)       Origin IGP, metric 0, localpref 100, valid, internal, best   Local     131.108.10.8 (metric 20) from 131.108.10.1 (131.108.10.1)       Origin IGP, metric 0, localpref 100, valid, internal       Originator: 131.108.10.1, Cluster list: 0.0.0.109 

Solution

Turning off client-to-client reflection solves this problem. This problem arises only when an RRC peers IBGP with another RRC. When an RRC peers only with the RR, BGP does not run into this issue. Example 15-62 shows the configuration needed on an RR to turn off client-to-client reflection.

Example 15-62 Disabling Client-to-Client Reflection

 R1#  router bgp 109  no bgp client-to-client reflection 

After enabling this command, the RR does not reflect any update from one RRC to another RRC, but it does reflect to normal IBGP and EBGP neighbors. The BGP operator must be certain that RRCs are peering BGP with other RRCs to make this modification.

When R1 is configured in this manner, it does not advertise 100.100.100.0/24 to the other client, R8, but does advertise to other IBGP and EBGP neighbors. Example 15-63 shows that R1 is receiving 100.100.100.0/24 from R8 but is not propagating further to anyone .

Example 15-63 R1's BGP Table Ensures That Disabling Client-to-Client Reflection Is Successful

 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  Not advertised to any peer  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