Information Technology Reference
In-Depth Information
If the physical topology cannot be changed, another solution is to make R4 an RR and to
make R2 a client of R4, as shown in the right topology in Figure 7-14. The session between
R1 and R2 is removed.
A Session Between an RR and Its Client Should Not Traverse a Nonclient
In Figure 7-15, the iBGP session between R1 (RR) and R2 (client) traverses a nonclient R4.
If inconsistent routing information exists between R4 and R2 (which could happen because
clients do not have the complete routing information and RRs might have modified path
attributes), packets might be looped. For a hypothetical example, assume that the following
are true:
•
R3 learns a prefix from an external neighbor and advertises it to R1.
•
R2 learns the same prefix from another external peer and advertises it to R1 and R4.
•
R1's best path to the prefix is via R3, and it reflects it to R2 and R4.
•
R2 selects the path from R1 as the best because of its local administrative policy.
Thus, R2 withdraws its previous advertisement to R1.
•
R4 selects the path via R2 as the best path because of its local administrative policy.
Figure 7-15
iBGP Session Between an RR and a Client Traverses a Nonclient
R1
R1
RR
RR
R3
R4
R2
R3
R4
R2
Client
Client
Client
Client
Physical
iBGP
Logical Connections
Physical and Logical Connections
The conflict of BGP next hop between R4 and R2 in this topology leads to a routing loop
as packets forwarded from R2 to the prefix are looped back to R2 from R4. One solution is
to physically connect R1 and R2, as shown in Figure 7-15's right topology.
