Route Distinguisher vs Route Target

Quick Difference

1. MPLS L3VPN Mental Model

MPLS L3VPN allows multiple customers to use overlapping IPv4 prefixes across the same Service Provider backbone. PE routers isolate customer routing using VRFs, while MP-BGP carries VPNv4 routes between PEs.

flowchart LR
  CEA["CE-A
Customer A
10.0.0.0/24"] --> PEA["PE
VRF-A"]
  CEB["CE-B
Customer B
10.0.0.0/24"] --> PEB["PE
VRF-B"]

  PEA <--> CORE["MP-BGP VPNv4 Core"]
  PEB <--> CORE

  CORE --> RD["RD
Creates unique VPNv4 prefixes"]
  CORE --> RT["RT
Controls VRF import/export"]

  classDef customer fill:#061116,stroke:#10d4ee,color:#f4f7fb;
  classDef core fill:#1b1238,stroke:#8162d6,color:#ffffff;
  classDef policy fill:#052b31,stroke:#39ff88,color:#ffffff;

  class CEA,CEB,PEA,PEB customer;
  class CORE core;
  class RD,RT policy;
          

2. Route Distinguisher

The Route Distinguisher has one purpose: make customer IPv4 prefixes globally unique inside the provider control plane. It does not control route import, export, or route leaking policy.

A Route Distinguisher is an 8-octet value prepended to an IPv4 prefix. The result is a VPNv4 prefix. This allows two customers to use the same IPv4 prefix without creating ambiguity inside MP-BGP.

flowchart LR
  RD["Route Distinguisher
64 bits"] --> VPNV4["VPNv4 Prefix
96 bits"]
  IPV4["IPv4 Prefix
32 bits"] --> VPNV4
  VPNV4 --> MBGP["MP-BGP VPNv4 NLRI"]

  classDef rd fill:#1b1238,stroke:#8162d6,color:#ffffff;
  classDef ip fill:#061116,stroke:#10d4ee,color:#f4f7fb;
  classDef result fill:#052b31,stroke:#39ff88,color:#ffffff;

  class RD rd;
  class IPV4 ip;
  class VPNV4,MBGP result;
          

Customer A prefix:
10.0.0.0/24

Customer B prefix:
10.0.0.0/24

With RD:
100:1:10.0.0.0/24
200:1:10.0.0.0/24

Result:
Both prefixes can coexist in MP-BGP VPNv4.

3. Route Target

Route Target is different. It is a BGP Extended Community used to control which VPN routes are exported from a VRF and which routes are imported into another VRF.

RFC 4360 defines BGP Extended Communities as Attribute Type Code 16. Route Target is a specific subtype inside Extended Communities and is heavily used in MPLS L3VPN designs.

"The BGP Extended Communities attribute provides a mechanism for tagging routes with information that can be used for policy decisions."

flowchart TD
  UPDATE["BGP UPDATE"] --> ATTR["Attribute Type Code 16
Extended Communities"]
  ATTR --> EXT["Extended Community
8 octets"]
  EXT --> TYPE["Type
0x00 / 0x01 / 0x02"]
  EXT --> SUBTYPE["Subtype
0x02 Route Target"]
  EXT --> VALUE["Value
100:1"]
  VALUE --> POLICY["VRF import/export policy"]

  classDef bgp fill:#061116,stroke:#10d4ee,color:#f4f7fb;
  classDef rt fill:#1b1238,stroke:#8162d6,color:#ffffff;
  classDef policy fill:#052b31,stroke:#39ff88,color:#ffffff;

  class UPDATE,ATTR,EXT bgp;
  class TYPE,SUBTYPE,VALUE rt;
  class POLICY policy;
          

4. RD vs RT

A common mistake is thinking the RD controls which VRF receives a route. It does not. Route leaking behavior is controlled by Route Targets through import and export policy.

5. Route Target Encoding

Route Target is always subtype 0x02. The high-order octet of the Type field can be 0x00, 0x01, or 0x02 depending on the format used.

6. CLI Configuration Examples

Cisco IOS / IOS-XR

route-target export 100:1
route-target export 192.168.1.1:100
route-target export 65546:100
route-target export 1.10:100

Junos OS

set routing-instances VRF_A vrf-target target:100:1
set routing-instances VRF_A vrf-target target:192.168.1.1:100
set routing-instances VRF_A vrf-target target:65546:100

7. Static PE-CE Routing in MPLS L3VPN

In a simple MPLS L3VPN lab, the PE can learn customer routes using static routing toward the CE. The important detail is that the static route must be configured inside the correct VRF, not in the global routing table.

• The CE usually does not know anything about VRFs.
• The PE interface facing the CE belongs to the customer VRF.
• Static routes learned inside the VRF must be redistributed into BGP.
• MP-BGP carries those routes as VPNv4 routes between PE routers.

router bgp 65000
 address-family ipv4 vrf SPCOR
  redistribute static
  redistribute connected

8. Complete MPLS L3VPN Flow

flowchart LR
  CE1["CE
Customer Routes"] --> PE1["PE
VRF + RD + RT"]
  PE1 --> VPNV4["VPNv4 Route
RD + IPv4 Prefix"]
  VPNV4 --> MBGP["MP-BGP
VPNv4 Address Family"]
  MBGP --> PE2["Remote PE
RT Import Check"]
  PE2 --> VRF["Destination VRF"]
  VRF --> CE2["Remote CE
IPv4 Forwarding"]

  classDef edge fill:#061116,stroke:#10d4ee,color:#f4f7fb;
  classDef control fill:#1b1238,stroke:#8162d6,color:#ffffff;
  classDef result fill:#052b31,stroke:#39ff88,color:#ffffff;

  class CE1,CE2 edge;
  class PE1,VPNV4,MBGP,PE2 control;
  class VRF result;
          

1. Create the VRF on the PE with RD and RT values.
2. Assign the PE-CE interface to the correct VRF.
3. Learn customer routes from the CE using static routing or a routing protocol.
4. Redistribute the VRF routes into MP-BGP.
5. The PE converts IPv4 customer routes into VPNv4 routes using the RD.
6. The PE attaches Route Targets as BGP Extended Communities.
7. MP-BGP advertises VPNv4 routes to remote PE routers.
8. The remote PE checks RT import policy to decide whether the route enters a VRF.
9. The MPLS core forwards traffic using transport labels and VPN labels.
10. The egress PE removes the VPN label and forwards pure IPv4 traffic to the CE.

9. Operational Notes and Troubleshooting

If connectivity fails, the issue is often not the RD itself. Most failures are related to missing VRF routes, missing redistribution, incorrect RT import/export, or ICMP sourcing from the wrong interface.

The commands below are a study checklist. Exact syntax can vary between Cisco IOS, IOS-XR, and Junos, but the troubleshooting logic is the same: verify the VPNv4 route, the VRF route table, label forwarding, and RT policy.

show bgp vpnv4 unicast all
show route vrf SPCOR
show mpls forwarding-table
show bgp vpnv4 unicast vrf SPCOR

• If the CE only has one exit point, a default route may be enough.
• If the PE learns static VRF routes, redistribute them into BGP.
• If the remote PE does not install the VPNv4 route, check RT import policy.
• If ping fails, verify the source interface and VRF context.

References

• RFC 4360 - BGP Extended Communities Attribute
• RFC 4364 - BGP/MPLS IP VPNs