PE router must be able to choose from all available paths, which in turn requires
that each VRF have a unique RD.
■
If each VRF has a unique RD and the ingress PE router has all feasible paths to
choose from, you can configure IBGP multipath and ECMP traffic over multiple
PE-to-PE MPLS tunnels. This configuration is not possible if you use the same
RD on multiple VRFs, because the ingress PE router in that case picks a single
route that resolves to a single MPLS tunnel that is used end-to-end.
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 on page 451, 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
Configuring BGP VPN Services
■
451
Chapter 5: Configuring BGP-MPLS Applications
Summary of Contents for JUNOSE
Page 6: ...vi...
Page 8: ...viii JUNOSe 11 0 x BGP and MPLS Configuration Guide...
Page 24: ...xxiv Table of Contents JUNOSe 11 0 x BGP and MPLS Configuration Guide...
Page 37: ...Part 1 Border Gateway Protocol Configuring BGP Routing on page 3 Border Gateway Protocol 1...
Page 38: ...2 Border Gateway Protocol JUNOSe 11 0 x BGP and MPLS Configuration Guide...
Page 234: ...198 Monitoring BGP JUNOSe 11 0 x BGP and MPLS Configuration Guide...
Page 236: ...200 Multiprotocol Layer Switching JUNOSe 11 0 x BGP and MPLS Configuration Guide...
Page 298: ...262 Point to Multipoint LSPs Configuration JUNOSe 11 0 x BGP and MPLS Configuration Guide...
Page 536: ...500 Monitoring BGP MPLS VPNs JUNOSe 11 0 x BGP and MPLS Configuration Guide...
Page 538: ...502 Layer 2 Services Over MPLS JUNOSe 11 0 x BGP and MPLS Configuration Guide...
Page 604: ...568 Virtual Private LAN Service JUNOSe 11 0 x BGP and MPLS Configuration Guide...
Page 618: ...582 VPLS References JUNOSe 11 0 x BGP and MPLS Configuration Guide...
Page 674: ...638 Virtual Private Wire Service JUNOSe 11 0 x BGP and MPLS Configuration Guide...
Page 718: ...682 Monitoring MPLS Forwarding Table for VPWS JUNOSe 11 0 x BGP and MPLS Configuration Guide...
Page 719: ...Part 6 Index Index on page 685 Index 683...
Page 720: ...684 Index JUNOSe 11 0 x BGP and MPLS Configuration Guide...