Information Technology Reference
In-Depth Information
Figure 7-7
Example of a Routing Information Loop with RR
Client
Client
Client
Client
R1
R2
R1
R2
RR/
Client
RR/
Client
RR/
Client
RR/
Client
Weight: 100
Weight: 100
R3
R4
R3
R4
RR/
Client
RR/
Client
R5
R5
172.16.0.0/16
172.16.0.0/16
Client
Client
R6
R6
Initial Updates
R3's Best Path Via R4
When R5 receives the prefix 172.16.0.0/16 from its client R6, it reflects to both R3 and R4.
The prefix is then reflected from R4 to R3. Now R3 has two paths for the prefix: one from
R5 and one from R4.
The best path is via R4, because R3 prefers the path with a higher WEIGHT. This causes
R3 to withdraw the route sent to R4 and readvertise the new best path to R5 and R1. So R5
receives the same route via R3 that it previously sent to R4. Without a loop-prevention
mechanism, R5 accepts the route and installs it into the BGP RIB, forming a routing
information loop.
To prevent routing information loops in an RR environment, as described in the previous
paragraphs, two BGP path attributes are specifically created: ORIGINATOR_ID and
CLUSTER_LIST.
ORIGINATOR_ID
Chapter 2 explained the ORIGINATOR_ID attribute and how it is set in an RR environment.
This chapter builds on that explanation to focus on how ORIGINATOR_ID prevents loops.
Consider the topology shown in Figure 7-8, in which two RRs of different clusters share
the same client. When the client R5 receives an update for 172.16.0.0/16 from external peer
R6, it readvertises the prefix via iBGP to R3 and R4. In turn, R3 and R4 readvertise the
prefix to each other. Because R3 and R4 are in different clusters (the default behavior in
IOS), the prefix from each other is accepted. Now both R3 and R4 have two paths to the
same destination. Now suppose a higher WEIGHT is set in R3 for the session with R4. R3
prefers the path via R4.
