[Contents]
[Prev]
[Next]
[Index]
[Report an Error]
Fast Reconvergence
by Means of Reachability Checking
You might not want to assign different RDs for
each VRF in some circumstances, such as the following:
- Allocating a unique RD for each VRF might be an administrative
burden.
- If the network is already in operation and configured
with the same RD for all VRFs in a given VPN, then changing the RDs
might affect service.
- Each route reflector might act as an arbiter for a geographic
area and be responsible for maintaining a list of all feasible paths
to egress PE routers that can be used to reach a given prefix. Because
the route reflector selects only one best path and reflects that single
best path toward its clients and nonclients, the amount of state in
the network is reduced. The core of the network and other geographic
areas need only the one best route to each prefix in a given remote
geographical area.
You can use the check-vpn-next-hops command to avoid the slow reconvergence problem without having to
configure a unique RD for each VRF. When you issue this command, BGP
verifies the reachability of the next hop on VPNv4 routes received
from MP-IBGP peers before it imports those routes into a VRF. This
behavior enables the VPNv4 route reflectors to take into account the
reachability of the next hop when they select the best route to reflect.
Consider a topology similar to that discussed in
the previous section. As before, the route through PE 1 is considered
to be the best. VRFs share the same RD, but reachability checking
has been enabled. In Figure 100, PE 1 has
already failed, and tunnels PE 3–PE 1 and PE 4–PE
1 have gone down.
Figure 100: Topology for Fast Reconvergence by Means
of Reachability Checking, After Tunnels Go Down
When the MPLS tunnel (RSVP-TE or LDP) to the next
hop of the best route goes down, the VPNv4 route reflector immediately
advertises the next-best route (if any) without waiting for the MP-IBGP
session to go down. In this example, that route is through PE 2.
check-vpn-next-hops
- Use to enable a BGP speaker to consider the reachability
of the next hop when the speaker determines which VPNv4 or VPNv6 route
is the best path to a prefix.
- Verifying the reachability of the next hop is disabled
by default.
- This command is available only in the context of the VPNv4
unicast and VPNv6 unicast address families. The behavior is the same
for both address families.
- Use the show ip bgp vpnv4 all summary or show bgp ipv6 vpnv6 all summary command to view the status of next hop reachability
checking.
- This command takes effect immediately.
- Example
- host1:pe1(config-router-af)#check-vpn-next-hops
- Use the no version to halt
the verification of next-hop reachability by the BGP speaker.
- See check-vpn-next-hops.
[Contents]
[Prev]
[Next]
[Index]
[Report an Error]
