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

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. Page 443

4 PREVIOUS

< Free Open Study >

BSD

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. 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 Page 446

4 PREVIOUS

< Free Open Study >

BSD

Was this article helpful?

0 0

Post a comment