Information Technology Reference
In-Depth Information
Figure 7-27
RR Clustering Design
AS 100
AS 100
R1
R1
RR
RR
RR
RR
R2
Cluster
192.168.1.1
R3
R2
Cluster
192.168.1.1
R3
Cluster
192.168.1.2
Client
Client
Client
R4
R4
172.16.0.0/16
172.16.0.0/16
AS 200
AS 200
R5
R5
Improper Clustering
Recommended Clustering
Now assume that the BGP next hop can be reached via two equal-cost IGP paths. R1 load-
shares the packets using these two IGP paths. So far everything is fine. Now assume that
the iBGP session between R4 and R3 is down, perhaps due to misconfiguration or admin-
istrative shutdown. While R2 continues to forward the traffic as before, the traffic via R3 is
discarded because it has no path for the prefix, even though the physical link between R3
and R4 is still functioning. This results in about 50% packet loss.
To correct the problem, consider the design on the right of Figure 7-27. In this design, two
RRs are in different clusters. In the case of iBGP session failure between R4 and R3, R3
continues to forward the traffic, because the prefix is also learned from R2. This design not
only provides physical redundancy against a link failure but also provides logical redundan-
cy against a failure of the iBGP session between a client and an RR. Note however that this
design leads to more memory use due to the extra path.
Resetting the Next Hop
An iBGP speaker, including an RR, is required to preserve BGP attributes such as NEXT_
HOP. The requirement is put in place to avoid routing loops when attributes are incorrectly
modified. Consider the topology shown in Figure 7-28. When the prefix 172.16.0.0/16 is
advertised to R1 (an RR), R2 sets itself as the BGP next hop, because it is configured with
