Problem: Convergence Time Improvement for RR and Clients-Cause: Use of Peer Groups

Problem: Convergence Time Improvement for RR and Clients ‚ Cause: Use of Peer Groups

When an RR is serving many clients, any update that it receives from IBGP/EBGP peers must be generated and propagated as separate updates for each RRC. If the number of BGP updates and RRCs is large, this process could become CPU- intensive for the RR. This results in slower propagation of BGP updates and hence results in slower convergence in the network overall. Peer- group clubs configure BGP neighbors in one group. Any common update that needs to go to all members of the peer group are processed only once, and all members receive the copy of that processed update. A router that has a peer group does not process update for all members of the group, resulting in huge CPU processing savings. Overall convergence of the networks improves greatly.

Figure 15-30 shows a route-reflection environment in which peer groups can be used.

Figure 15-30. Peer Group Efficiency in Advertising Routes

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

Figure 15-31. Problem-Resolution Flowchart

Debugs and Verification

Typically, peer groups contain several clients to explain the peer group usage. Example 15-64 shows the necessary configuration required by R1 to put R8 and R6 in a peer group named INTERNAL.

Example 15-64 Configuring R8 and R6 as Peer Group Members

 R1#  router bgp 109   no synchronization   neighbor INTERNAL peer-group   neighbor 131.108.10.8 remote-as 109   neighbor 131.108.10.8 update-source Loopback0   neighbor 131.108.10.8 peer-group INTERNAL   neighbor 131.108.10.6 remote-as 109   neighbor 131.108.10.6 update-source Loopback0  neighbor 131.108.10.6 peer-group INTERNAL 

R1 calculates one update for the first member of the peer group INTERNAL and replicate to others. Output in Example 15-65 shows that 131.108.10.8 (R8) is the first member in the list; therefore, R1 calculates updates for R8 and replicates to the rest of the members in the list INTERNAL, to avoid calculating for the rest.

In Example 15-65, R6 is the other member in the list INTERNAL.

Example 15-65 Displaying Peer Group Members

 R1#  show ip bgp peer-group INTERNAL  BGP peer-group is INTERNAL   BGP version 4   Default minimum time between advertisement runs is 5 seconds   BGP neighbor is INTERNAL, peer-group internal, members:        131.108.10.8  131.108.10.6   Index 1, Offset 0, Mask 0x2 Update messages formatted 4, replicated 2 

Solution

When peering to several neighbors, use the Cisco IOS Software BGP peer group feature to avoid the processing duplication required to generate the same update to every neighbor. In peer groups, BGP neighbors (in this case, all RRCs) are listed as members of a peer group that share the same outbound policy. RR computes an update for the first member of the peer group and simply replicates the same update to all members. This greatly reduces the number of CPU cycles that the RR has to spend to compute update for each RRC. In addition, using peer groups speeds up the process of propagating BGP updates to RRCs; therefore, RRCs converge faster in case of any churn. Peer groups can be used in normal IBGP and EBGP scenarios to get this benefit, with the condition that all peer-group members are configured with same outbound policy.