Information Technology Reference
In-Depth Information
original design accomplishes the goal, with the caveat of no redundancy for R3 and R4. If
R1 and R2 are in different clusters, redundant BGP sessions do not add much value without
the physical links. Examples of clustering design are discussed in the following sections.
A Session Between an RR and a Nonclient Should Not Traverse a Client
The problem in Figure 7-14 is similar to that in Figure 7-12, except that the iBGP connec-
tion traversing the client is between an RR and a nonclient. Additionally, R2 peers with R4
(a client of R1) via iBGP.
Figure 7-14
iBGP Session Between a Client and a Nonclient
R1
R2
R1
R2
R1
R2
RR
RR
RR
Client
R3
R4
R3
R4
R3
R4
RR
Client
Client
Client
Client
Client
Physical
iBGP
Logical Connections
Physical and Logical Connections
Following Physical Topology
First of all, an iBGP peering between a client and a nonclient is generally not recommended.
Because a client acts like a regular iBGP peer to another nonclient (Rule 3), routes received
by the client from a nonclient are not advertised to other peers. Additionally, other clients
would receive the routing information from RRs, which must peer with nonclients. Extra
iBGP sessions also lead to extra paths on the client. Thus, the iBGP session between R2
and R4 is not recommended.
Similar to the problem shown in Figure 7-12, failure of the physical link between R1 and
R4 breaks both BGP sessions: the session between R1 and R4 and the one between R1
and R2. This topology is also similar to the one that causes a persistent forwarding loop,
as shown later in Figure 7-28.
One solution (as shown in Figure 7-14's center topology) is to move the link between R4
and R2 to between R1 and R2. This solution also removes the iBGP session between
R4 and R2.
