Information Technology Reference
In-Depth Information
the prefix. Before Cisco IOS Release 12.0, peer groups cannot be used on RRs unless client-
to-client reflection is turned off and all clients are fully meshed. This restriction can be
explained by the following example. In Figure 7-31, the prefix 172.16.0.0/16 is advertised
to R3 (RR) via two paths: through R1 (nonclient) and through R2 (client).
Figure 7-31
Peer Groups with RR Before IOS 12.0
AS 200
AS 200
AS 100
AS 100
R6
R6
RR
RR
R3
R3
R1
R1
Withdraw 172.16.0.0/16
Client
Client
X
X
R5
R5
R2
R2
R4
Client
R4
Client
172.16.0.0/16
172.16.0.0/16
Client
Client
AS 300
AS 300
172.16.0.0/16
172.16.0.0/16
R7
R7
Prefix Propagation
RR's Best Path via R2
Assume that R3's best path is via R2 because it is a shorter AS_PATH. Because all clients
are in the same peer group, R3 reflects the best path to all members of the peer group,
including R2. Because the best path is via R2, R3 also needs to withdraw the route from
R2. When all clients are in a peer group, R3 ends up sending the withdrawal message to R4
and R5 as well. This prefix is removed from the BGP RIB in R4 and R5. If R2, R4, and
R5 are fully meshed and the default client-to-client reflection on R3 is turned off, R4
and R5 receive the prefix from R2 directly.
With Cisco IOS Release 12.0 and later versions, the restriction just described is lifted,
because clients understand the RR-related attributes. When RR needs to withdraw a route
from a client in a peer group, it does not send the withdrawal message. Instead, it sends the
current best path to all its clients. At that point, all other members of the peer group are
properly updated with the prefix. When R2 receives the update, it detects its own
ORIGINATOR_ID and discards the update, as shown in Figure 7-32.
