Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    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 1, PE 1 has already failed, and tunnels PE 3–PE 1 and PE 4–PE 1 have gone down.

    Figure 1: Topology for Fast Reconvergence by Means of Reachability Checking, After Tunnels Go Down

    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.

    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.

    Published: 2014-08-18