Information Technology Reference
In-Depth Information
Figure 7-8
How ORIGINATOR_ID Breaks a Loop
AS 100
AS 100
Weight: 100
Weight: 100
RR
RR
RR
RR
R3
R4
R4
R3
Client
Client
X
192.168.1.1
192.168.1.1
R5
R5
172.16.0.0/16
172.16.0.0/16
AS 200
AS 200
R6
R6
R3's Best Path Via R4
Initial Updates
As soon as R3 selects R4 as the best path, it withdraws the route sent to R4. It also sends a
new update to R5 to inform it of the new best path. R5 rejects this update from R3 because
the update contains R5's ORIGINATOR_ID. Consequently, the loop is prevented.
In an RR environment, the first RR creates the ORIGINATOR_ID attribute and sets it
to the BGP router ID of the router that originated the route. In Figure 7-8, R4 sets the
ORIGINATOR_ID to R5's router ID, which is 192.168.1.1. This attribute is never modified
by subsequent RRs. When R5 receives the update with its own ORIGINATOR_ID, it denies
the update, breaking the routing information loop. This is shown in Example 7-2, as
captured by the debug ip bgp update command.
ORIGINATOR_ID Breaks the Routing Information Loop on R5
Example 7-2
Local router is the Originator; Discard update
rcv UPDATE about 172.16.0.0/16 -- DENIED due to: ORIGINATOR is us;
CLUSTER_LIST
The CLUSTER_LIST is another BGP path attribute that helps break the routing informa-
tion loop in an RR environment. It records the cluster in the reverse order the route has
traversed. If the local CLUSTER_ID is found in the list, the route is discarded. Unlike
the ORIGINATOR_ID, the CLUSTER_LIST is used only by RRs in loop prevention,
because a client or nonclient (if it is not an RR itself) has no knowledge of which cluster
it belongs to.
 
Search WWH ::




Custom Search