MPLS L3VPN Route Distinguisher and Route Target Design

An MPLS L3VPN succeeds or fails on two 64-bit values that engineers constantly confuse: the route distinguisher (RD) that makes overlapping customer prefixes unique inside MP-BGP, and the route target (RT) extended community that decides which VRFs may import those routes. Teams that treat them as interchangeable end up with leaked prefixes, routes that never appear in the customer VRF, or hub-and-spoke topologies that quietly turn into any-to-any. This guide separates the two roles, shows the configuration on Cisco IOS XR and Junos, and gives the verification and design rules that keep a multi-VRF provider edge predictable.

RD vs RT: Two Different Jobs

The route distinguisher is a uniqueness mechanism. A PE router learns IPv4 prefixes from a CE and prepends the 64-bit RD configured for that VRF, producing a 96-bit VPN-IPv4 prefix. That is what allows two customers to use 10.0.0.0/8 at the same time without conflicting inside the same BGP table. The RD is local significance only: it is stripped before the route is advertised to the remote CE, and it never influences which VRF receives the route.

The route target is a policy mechanism. It is a BGP extended community carried with the route. Each VRF has an import list and an export list of RTs, and a VPN route is installed into a VRF only when at least one of its RTs matches that VRF's import list. If the RD is wrong you get a conflict or a commit failure; if the RT is wrong you get a route that exists in BGP but is invisible to the customer.

Choosing RD and RT Formats

• ip-address:number (type 1) — use the PE loopback or router ID. This is the easiest format to trace back to the originating PE and is what most designs standardize on.
• as-number:number (type 0/2) — convenient when the service provider already owns a public ASN; with a 4-byte ASN the administrator subfield is 4 bytes.
• Automatic assignment — Cisco IOS XR can allocate a persistent type 1 RD per VRF with rd auto, derived from the BGP router ID and an unused index. Assigned values are checkpointed, so they survive process restarts; an explicitly configured RD always wins.

Junos enforces uniqueness strictly: two routing instances with the same RD fail the commit, and for L2VPN/VPLS with l2vpn-use-bgp-rules a unique RD per PE is mandatory. A useful convention is one unique RD per VRF, per PE — it gives you iBGP load balancing and lets you identify which PE a route came from, while the RT stays a shared, service-wide value.

Cisco IOS XR Configuration

vrf CUSTOMER-A
 address-family ipv4 unicast
  import route-target
   65100:100
  !
  export route-target
   65100:100
  !
 !
!
router bgp 65100
 vrf CUSTOMER-A
  rd 10.255.0.1:100
  address-family ipv4 unicast
   redistribute connected
  !
 !
!

Swap rd 10.255.0.1:100 for rd auto if you prefer automatic allocation; the RT values stay explicit because they carry the service design.

Junos Configuration for the Same Service

set routing-instances CUSTOMER-A instance-type vrf
set routing-instances CUSTOMER-A interface ge-0/0/1.100
set routing-instances CUSTOMER-A route-distinguisher 10.255.0.1:100
set routing-instances CUSTOMER-A vrf-target target:65100:100
set routing-instances CUSTOMER-A vrf-table-label

For asymmetric designs replace vrf-target with explicit vrf-import and vrf-export policies that match on the RT community, which lets a VRF import targets it does not export.

Hub-and-Spoke RT Design Without Leaks

The classic mistake in hub-and-spoke L3VPNs is reusing one RT everywhere. The working pattern is asymmetric:

• Hub VRF: exports RT-hub, imports RT-spoke.
• Spoke VRF: exports RT-spoke, imports RT-hub.

Because no VRF imports the RT that a spoke exports, spoke-to-spoke traffic is forced through the hub, where firewall and NAT policy can be applied. Extranet and shared-services designs simply add a second RT to the import list of the VRFs that need reachability.

Verifying That Routes Actually Land in the VRF

! Cisco IOS XR
show bgp vpnv4 unicast all summary
show bgp vpnv4 unicast all rd 10.255.0.1:100
show route vrf CUSTOMER-A ipv4 unicast
show running-config vrf CUSTOMER-A

! Junos
show route table bgp.l3vpn.0 detail | match target
show route table CUSTOMER-A.inet.0
show route forwarding-table table CUSTOMER-A

If the VPN-IPv4 prefix is present in BGP but missing from the VRF table, the RT import list is wrong or the route arrived from a PE with a different RT policy. If the prefix never appears in bgp.l3vpn.0, check that the remote PE exports the expected RT and that MP-BGP sessions are exchanging the vpnv4 address family. Duplicate RDs show up as prefix conflicts rather than clean errors, which is why RD uniqueness deserves a periodic audit in large networks.

Related reading: Cisco IOS XR MPLS LDP configuration, IS-IS level 2 to level 1 route leaking, and segment routing SR-MPLS with OSPF prefix SIDs.

原文链接：https://www.cisco.com/c/en/us/td/docs/iosxr/cisco8000/l3vpn/l3vpn-config-cisco8000/mpls-l3vpn-fundamentals-and-core-deployment-w/mpls-layer-3-vpn-services.html