Information Technology Reference
In-Depth Information
•
Rule 3
—An RR client follows the regular iBGP loop-prevention rule when
advertising prefixes.
•
Rule 4
—Additional rules must be followed if advertising to iBGP peers, clients, or
nonclients (see Rules 5, 6, and 7). When advertising to iBGP peers, the rules are
dependent on where the prefix is learned.
•
Rule 5
—If an RR learns a prefix from an external peer, it advertises to all its clients
and nonclients.
Consider Figure 7-3, in which the RR (R5) receives the prefix 172.16.0.0/16 from an
eBGP peer (R8). It advertises the route to both its clients, R6 and R7. R5 also adver-
tises the route to its nonclients, R3 and R4. Both R3 and R4 are iBGP peered and are
not allowed to readvertise the route to each other.
Figure 7-3
Prefix Advertisement for External Peers
R3
R4
AS 200
Client
R6
RR
Client
R5
R7
172.16.0.0/16
eBGP
R8
AS 300
Physical
iBGP
•
Rule 6
—If the prefix comes to an RR through a nonclient iBGP peer, the RR reflects
the route to all its clients.
Figure 7-4 shows the prefix advertisement. The prefix 172.16.0.0/16 is advertised to
R5 via iBGP from R3. R5 reflects the prefix to its clients, R6 and R7. An RR does not
reflect the route it learns from an iBGP peer to another nonclient iBGP peer, such as
R4 (standard iBGP requirement). Because R3 and R4 are iBGP peered, R4 receives
the prefix from R3 directly. As indicated in Rule 2, an RR always advertises to an
external peer, such as R8.
