MPLS L3VPN VRF, Route Distinguisher and Route Target

MPLS L3VPN works because two attributes do all the separation work: the route distinguisher makes customer prefixes unique across the provider backbone, and route targets decide which VRFs are allowed to import them. Almost every L3VPN fault traces back to one of those two - a duplicated RD that breaks iBGP load balancing, or an export target on one side that does not match any import target on the other. This guide covers the PE configuration and the verification commands that prove both attributes are correct.

How Routes Flow Through an L3VPN

The PE learns a customer prefix from a CE - statically, or over eBGP, OSPF, EIGRP or RIPv2 - and converts the IPv4 prefix into a VPN-IPv4 prefix by prepending the 64-bit route distinguisher configured for that VRF. That combined prefix is then carried by MP-BGP. When a remote PE receives the update, it compares the attached route target extended communities against the import targets of each local VRF, and imports the route only if at least one matches.

Define the VRF and Its Route Targets

configure
vrf CUSTOMER_A
 address-family ipv4 unicast
  import route-target
   65100:100
  !
  export route-target
   65100:100
  !
 !
!
commit

Matching import and export targets create a standard any-to-any VPN. Asymmetric targets - a different export value on each site - build more complex topologies such as hub-and-spoke, and they are also how leaked routes between VRFs are implemented. Route targets are 8-byte extended communities written as AS:nn or IP:nn; the format must be consistent across every PE that imports the route.

Assign the Route Distinguisher

In IOS XR, rd auto assigns a Type 1 RD of the form router-id:index, and checkpoints the value so it survives process restarts. Every router must have a unique BGP router ID for this to be safe.

router bgp 65100
 vrf CUSTOMER_A
  rd auto
  address-family ipv4 unicast
   redistribute connected
   redistribute static
  !
 !
!

An explicitly configured RD is never overwritten by rd auto. For a design discussion of RD versus RT see route distinguisher and route target design.

Attach Interfaces and PE-CE Routing

interface GigabitEthernet0/0/0/1
 vrf CUSTOMER_A
 ipv4 address 192.0.2.1 255.255.255.252
!
router bgp 65100
 vrf CUSTOMER_A
  neighbor 192.0.2.2
   remote-as 65001
   address-family ipv4 unicast
    route-policy PASS in
    route-policy PASS out
   !
  !
 !
!
route-policy PASS
 pass
end-policy

Every BGP neighbor needs an explicit route policy in this address family on XR. Omitting the inbound policy is a common cause of an empty VRF table even though BGP reports the session as established.

Verifying the Control Plane

show bgp vrf CUSTOMER_A summary
show bgp vrf CUSTOMER_A ipv4 unicast
show bgp vrf CUSTOMER_A ipv4 unicast 192.0.2.0/24
show route vrf CUSTOMER_A ipv4 unicast
show bgp vpnv4 unicast rd auto
show bgp vrf CUSTOMER_A ipv4 unicast neighbors 192.0.2.2 advertised-routes

In the per-prefix output look for the RD line and the extended community list. A prefix that appears in the default table but not in the VRF table means the route target did not match; a prefix missing from the remote PE entirely means the MP-BGP session for the VPNv4 address family is not exchanging routes - check that both PEs are configured as route reflectors or fully meshed, and that the address family is activated on the session.

Verifying the Data Plane

show mpls forwarding-table vrf CUSTOMER_A
show cef vrf CUSTOMER_A 192.0.2.0/24
ping vrf CUSTOMER_A 192.0.2.2
traceroute vrf CUSTOMER_A 192.0.2.2

Two labels are pushed for L3VPN traffic: the transport label from LDP or SR, and the VPN label advertised by the egress PE. If traceroute shows the packet dying at the penultimate hop, the transport LSP is fine but the VPN label was not installed - usually an RD or import target mismatch. For broader troubleshooting, MPLS VPN troubleshooting with VRF and BGP is a useful companion.

原文链接：https://www.cisco.com/c/en/us/td/docs/ios_xr_sw/iosxr_r3-7/mpls/configuration/guide/gc37v3.html