Information Technology Reference
In-Depth Information
R1 receives the prefix 172.16.0.0/16 from an external peer, R5. The next hop is reset at R1
to itself, and the prefix is advertised to R2 and R3. Both R2 and R3 are RRs in different
clusters, with R4 as a client. When R3 reflects the route to its client R4, it resets itself as the
BGP next hop. This is accomplished in an outbound route map Set-NH. On R2, no next-
hop reset is configured.
As a client to both R2 and R3, R4 receives two paths for the prefix. The path from R3 has
the next hop set to R3, and the path from R2 has the next hop set to R1. So R4 uses the link
with R3 to forward the traffic for the prefix (because of a lower IGP metric to the BGP next
hop), unless the link between R4 and R3 is down or R3 fails. In both cases, R4 forwards the
traffic to R2, which sends it to R1 to exit AS 100.
Two points deserve further discussion. First, what is the benefit of resetting the next hop
at R3? Without the next hop reset, R4 might choose the link to R2 to forward traffic to
172.16.0.0/16. Suppose the policy dictates that the path via R3 is to be used for R4 during
normal operation for one of the following reasons:
•
The link between R3 and R4 has higher bandwidth or lower cost.
•
The link between R2 and R4 has lower bandwidth or higher cost.
•
The link between R1 and R2 is overutilized.
Resetting the next hop on R3 is one way to force the traffic to take the path via R3 (although
changing the IGP metric might also accomplish the goal).
The second significant point is that the distinction between the two methods of setting the
next hop is important, because RRs often set
next-hop-self
for externally learned routes.
With that distinction, the next hop is not modified if routes are from an iBGP peer unless
an outbound route map specifically changes it.
Modifying next hops of iBGP routes at RRs using an outbound route map can cause routing
loops. Use this feature with care.
CAUTION
Route Reflection with Peer Groups
The peer-group concept was discussed in Chapter 3 as a technique to increase update
generation efficiency and thus shorten convergence time. This section does not restate the
benefits of peer groups. Instead, it focuses on the peer-group behavior in an RR-based
architecture.
All members of the peer group inherit the same outbound policy/updates. Likewise, all
members of the peer group receive the same updates—even the original client that sources
