Theoretical foundations and architecture

BGP/MPLS IP VPN (RFC 4364) relies on two distinct architectural constructs: Route Distinguishers (RD) and Route Targets (RT). 1. Route Distinguisher (RD) is an 8-byte (64-bit) prefix prepended to a tenant's 32-bit IPv4 route at the ingress PE, creating a globally unique 96-bit VPNv4 prefix (e.g., RD 65000:1 + 192.168.1.0/24 = 65000:1:192.168.1.0/24). The sole purpose of the RD is to disambiguate identical customer routes in the BGP control plane on Route Reflectors. 2. Route Target (RT) is an extended BGP community that dictates VPN membership and routing topology. When a PE exports a VRF route into MP-BGP, it tags it with one or more Export RTs. Receiving egress PEs evaluate incoming routes against local VRF Import RT filters; matching routes are installed into the corresponding tenant FIB. For IPv6, the exact same mechanism forms 192-bit VPNv6 prefixes (RFC 4659), prepending the 64-bit RD to 128-bit IPv6 prefixes.

RD and RT solve different problems

The Route Distinguisher (RD) makes a prefix unique in the shared MP-BGP table: 8 bytes of RD + an IPv4 prefix = a VPNv4 NLRI (AFI 1, SAFI 128), 8 bytes of RD + an IPv6 prefix = a VPNv6 NLRI (AFI 2, SAFI 128). The RD says nothing about who may see the route. The Route Target (RT) is the policy: an extended BGP community (8 bytes: type/subtype + global administrator + local value) that the exporting VRF attaches to the route and the importing VRF uses as a filter. One route can carry several RTs, and one VRF can import and export several RTs. It is the RT combinations that create full mesh, hub-and-spoke and extranet topologies.

Formats and numbers

  • RD/RT type 0: 2-byte ASN + 4-byte number (65000:100); type 1: IPv4 address + 2 bytes (10.255.0.1:100); type 2: 4-byte ASN + 2 bytes (for 4-byte ASNs).
  • The VPN label is 20 bits and is carried inside the NLRI (MP_REACH_NLRI); the next hop is the PE loopback (10.255.0.2), unreachable without a transport LSP.
  • For VPNv6 (6VPE, RFC 4659) the next hop is an IPv4-mapped IPv6 address (::ffff:10.255.0.2); the transport stays IPv4 LDP, so the core is not required to support IPv6.
  • The RT is carried in the Extended Communities attribute, so the BGP session must forward it: on Cisco an explicit send-community extended is needed in vpnv4/vpnv6, on Junos extended communities are sent by default.

What happens to a route from CE to CE

  1. CE-A2 advertises 192.168.20.0/24 to PE2 (static/eBGP/OSPF).
  2. PE2 places the route in VRF A, sets RD 65000:2, allocates a VPN label, adds the export RT 65000:100 and advertises the VPNv4 NLRI towards the RR (next hop 10.255.0.2).
  3. The RR reflects the route to all clients without checking the RT: on Cisco bgp default route-target filter is disabled on the RR for this, on Junos all routes are kept (keep all or no local VRFs).
  4. PE1 accepts the VPNv4 NLRI and checks the RT: if no local VRF imports 65000:100, the path is discarded (Cisco: the RT filter is on by default, Junos: bgp.l3vpn.0 without keep all). This protects PE memory but creates a trap when a new customer is added.
  5. If the RT matches, the route lands in VRF A.inet.0 as a BGP route with next hop 10.255.0.2, a VPN label and an LDP transport label.

RD: unique per PE or shared per customer

  • One RD per VPN (65000:1 on all PEs): the RR sees one NLRI from two PEs and reflects only one best path, so load balancing and instant backup are unavailable (add-path is needed).
  • Unique RD per (VRF, PE) (65000:1 on PE1, 65000:2 on PE2): two NLRIs live in parallel, the RR sends both, and the PE gets ECMP/backup. This is the recommended practice for multihoming.
  • The RD must not be the same for different customers: otherwise overlapping prefixes will overwrite each other (see the previous lesson).

RT assignment scheme

A typical standard: ASN:100 - customer A, ASN:200 - customer B, ASN:1xx - hub-and-spoke, ASN:9xx - shared services. Keep a registry of RTs and RDs and maintain it as data (not in an engineer's head): a one-digit mistake causes a leak between customers. Several RTs on one VRF are allowed (extranet), but every additional value widens the visibility scope.

VPNv6

IPv6 in a VRF is configured with a separate address-family ipv6 (Cisco: inside vrf definition, Huawei: ipv6-family in ip vpn-instance, Junos: the same instance, table A.inet6.0). The RD/RT can be the same for v4 and v6 (simpler), but different ones are allowed too. The session to the RR must activate vpnv6 separately from vpnv4: a missing activation is a frequent cause of "IPv4 works, IPv6 does not". The VPNv6 label is allocated using the same per-prefix/per-VRF modes as for VPNv4.

Layered diagnostics

  1. Is there an Established session with the RR and is the AFI/SAFI negotiated (show bgp vpnv4 unicast all summary).
  2. Is the route in the VPNv4 table and which RTs does it carry.
  3. Does the RT match the VRF import.
  4. Is the next hop reachable over an LSP (transport label).
  5. Is the VPN label visible in the CEF/forwarding output.

If the route is missing at step 2 - the problem is in the export/session; at step 3 - in the RT; at step 4 - in IGP/LDP.

Architecture Diagram & Topology

text
+---------------------+      MP-BGP VPNv4 / VPNv6 Update (PE-1 -> PE-2)     +---------------------+
|        PE-1         | ==================================================> |        PE-2         |
| RD: 65000:1 (Unique)| [96-bit VPNv4 Prefix: 65000:1:10.0.0.0/24]          | Match Import RT     |
| RT: 65000:100(Export)| [Extended Community: Target: 65000:100]             | Imports into VRF    |
+---------------------+ [Service Label: 24001] [Next-Hop: 10.255.0.1]       +---------------------+

Traffic Flow & Label Stack Scheme