MPLS L3VPN with MP-BGP and VPNv4

MPLS L3VPN (Layer 3 VPN, RFC 4364) is the service that made MPLS commercially successful. It lets a service provider carry many customers' overlapping IP address spaces over a single shared backbone, with each customer seeing only their own routes. Customer A and customer B both using 10.0.0.0/24 do not conflict because the provider keeps them in separate VRFs and tags VPN routes with route distinguishers and route targets.

This article walks through the L3VPN architecture, VRFs, route distinguishers, route targets, the two-label stack, the MP-BGP control plane, and the Cisco IOS XE configuration. If you are configuring an MPLS L3VPN for the first time, troubleshooting a customer's missing routes, or trying to understand the relationship between BGP and MPLS, this is the reference.

The L3VPN Architecture

The Problem L3VPN Solves

Customer A: site A1 in New York, site A2 in San Francisco. Both use 10.0.0.0/24 internally.

Customer B: site B1 in New York, site B2 in San Francisco. Both also use 10.0.0.0/24 internally.

Both buy MPLS service from the same provider. Both customers' sites need connectivity between their own remote sites without seeing each other's traffic.

Plain IP routing cannot solve this - the routes overlap. L3VPN solves it by:

1. Each customer's routes live in a separate VRF on each PE.
2. The provider's PE prepends an 8-byte Route Distinguisher to each route when sending it to other PEs via MP-BGP. Customer A's 10.0.0.0/24 becomes 65001:1:10.0.0.0/24; customer B's becomes 65001:2:10.0.0.0/24. Globally unique.
3. Each route is also tagged with a Route Target that controls which VRFs import it. Customer A's RT is 65001:100; customer B's is 65001:200. Each customer's VRF only imports its own RT.
4. Each PE assigns a per-VPN label so the egress PE knows which VRF a packet belongs to. The packet on the wire has two labels: outer transport (LDP) and inner VPN.

Result: customer A's packet from A1 goes through the MPLS core to the egress PE, which pops both labels and forwards to A2. Customer B's packet does the same separately. Neither customer sees the other.

VRFs: Per-Customer Routing Instances

A VRF is essentially a separate routing table on the PE. Two flavors of VRF configuration on Cisco IOS XE:

Classic VRF (legacy):

ip vrf CUSTOMER-A
 rd 65001:1
 route-target export 65001:100
 route-target import 65001:100

interface GigabitEthernet0/0/1
 ip vrf forwarding CUSTOMER-A
 ip address 192.168.1.1 255.255.255.0

VRF Definition (modern, IPv4 + IPv6):

vrf definition CUSTOMER-A
 rd 65001:1
 address-family ipv4
  route-target export 65001:100
  route-target import 65001:100
 exit-address-family

interface GigabitEthernet0/0/1
 vrf forwarding CUSTOMER-A
 ip address 192.168.1.1 255.255.255.0

Both achieve the same effect - the interface is in the customer's VRF, isolated from the global routing table and other VRFs. Modern deployments use the vrf-definition form because it cleanly supports IPv4 and IPv6 in one VRF.

Route Distinguishers

An RD is an 8-byte value prepended to a 4-byte IPv4 prefix to produce a 12-byte VPNv4 prefix. Format:

RD = <2-byte Type><6-byte value>

Type 0: 2-byte ASN : 4-byte assigned number
        Example: 65001:1
Type 1: 4-byte IPv4 : 2-byte assigned number
        Example: 192.0.2.1:1
Type 2: 4-byte ASN : 2-byte assigned number
        Example: 4200000000:1

The RD's only job is to make customer prefixes globally unique inside the MPLS network. It does not control import/export behavior - that is the RT's job. Two PEs serving the same customer can use different RDs (and often do for ECMP scenarios where the same prefix needs two BGP best paths).

Route Targets

An RT is an extended community attached to each BGP route. Format mirrors the RD format. The PE attaches RTs on export and matches RTs on import to decide which VRFs receive which routes.

vrf definition CUSTOMER-A
 rd 65001:1
 address-family ipv4
  route-target export 65001:100      ! Tag exported routes with RT 65001:100
  route-target import 65001:100      ! Import any route tagged with RT 65001:100

For a simple "every site of this customer reaches every other" topology, export and import the same RT. Each PE sees every other PE's customer routes (filtered to those tagged with the matching RT) and installs them in the VRF.

For more complex topologies (extranet, hub-and-spoke, partial mesh), use different export and import RTs to control which routes flow where. Example: a hub-and-spoke design might have spokes export RT 65001:100 and import RT 65001:200, while the hub exports RT 65001:200 and imports RT 65001:100. Spokes only see hub routes; the hub sees all spoke routes; spokes do not see each other.

MP-BGP Carries VPNv4

The PEs exchange VPNv4 routes via MP-BGP, specifically address-family vpnv4 unicast. This is where the BGP cluster intersects directly with the MPLS cluster. The MP-BGP article (MP-BGP: Multiprotocol BGP) covers the BGP side; this section covers the MPLS-specific aspects.

iBGP between PEs (typically with route reflectors at scale):

router bgp 65001
 neighbor 10.10.10.10 remote-as 65001
 neighbor 10.10.10.10 update-source Loopback0
 address-family vpnv4 unicast
  neighbor 10.10.10.10 activate
  neighbor 10.10.10.10 send-community extended
 exit-address-family
 address-family ipv4 vrf CUSTOMER-A
  redistribute connected
  redistribute static
 exit-address-family

The send-community extended is critical - RTs are extended communities. Without it, RTs do not propagate and route filtering breaks.

The Two-Label Stack

An L3VPN packet on the wire has two MPLS labels:

The journey:

1. Customer A's CE in New York sends a packet to 10.0.0.5 (somewhere at site A2 in San Francisco).
2. Ingress PE looks up 10.0.0.5 in CUSTOMER-A's VRF, finds the route via egress PE 10.10.10.10 with VPN label 24.
3. Ingress PE looks up 10.10.10.10 in the global RIB, finds LDP transport label 17 to the next P router.
4. Ingress PE pushes both labels: outer 17 (transport), inner 24 (VPN). Sends.
5. P routers along the path swap the outer label as needed; the inner label is invisible to them.
6. The penultimate P router pops the outer label (PHP) and forwards to egress PE.
7. Egress PE sees a packet with one label (24, the VPN label), looks up the label in its forwarding table, finds it maps to CUSTOMER-A's VRF and forwards to the appropriate next-hop CE.

For more on the label stack and PHP, see MPLS Labels Explained.

PE-CE Routing

The PE and CE need a way to exchange customer routes. Several options:

BGP PE-CE is the dominant pattern. The CE runs eBGP with the PE; the PE redistributes BGP into MP-BGP for the rest of the L3VPN backbone. Loop prevention via the AS_PATH is automatic.

Cisco IOS XE Configuration: A Working Example

! VRF definition
vrf definition CUSTOMER-A
 rd 65001:1
 address-family ipv4
  route-target export 65001:100
  route-target import 65001:100

! PE-CE interface
interface GigabitEthernet0/0/1
 vrf forwarding CUSTOMER-A
 ip address 192.168.1.1 255.255.255.0

! IGP for PE-PE reachability (loopbacks, infrastructure)
router ospf 1
 router-id 1.1.1.1
 network 10.0.0.0 0.0.255.255 area 0

! MPLS in the core
mpls ldp router-id Loopback0 force
mpls ldp sync
interface GigabitEthernet0/0/0
 ip address 10.0.12.1 255.255.255.252
 mpls ip
 mpls ldp sync

! BGP for L3VPN
router bgp 65001
 neighbor 10.10.10.10 remote-as 65001
 neighbor 10.10.10.10 update-source Loopback0
 address-family vpnv4 unicast
  neighbor 10.10.10.10 activate
  neighbor 10.10.10.10 send-community extended
 exit-address-family
 address-family ipv4 vrf CUSTOMER-A
  redistribute connected
  ! If using BGP PE-CE:
  neighbor 192.168.1.2 remote-as 65100
  neighbor 192.168.1.2 activate
 exit-address-family

Verification

! VRF routing table
PE# show ip route vrf CUSTOMER-A

! VRF VPN routes received from other PEs
PE# show bgp vpnv4 unicast all summary

! Specific prefix details
PE# show bgp vpnv4 unicast all 10.0.0.0/24

! Forwarding for a specific prefix in a VRF
PE# show ip cef vrf CUSTOMER-A 10.0.0.5

! L3VPN label bindings
PE# show mpls forwarding-table vrf CUSTOMER-A

Anti-Patterns

• Same RD on multiple PEs for the same VRF. Causes BGP best-path issues for ECMP. Use different RDs (e.g. include the PE's loopback in the RD).
• Forgetting send-community extended. RTs do not propagate; route import/export breaks.
• RTs not symmetric. Easy to typo and end up with import 65001:100 but export 65001:1000. Always verify with show vrf detail.
• Mixing classic VRF and vrf-definition. Both work but operationally confusing. Standardize on vrf-definition.
• Skipping LDP-IGP sync. Transient drops on link bring-up; broken L3VPN until LDP catches up.

Summary

MPLS L3VPN combines VRFs (per-customer routing instances), Route Distinguishers (make overlapping prefixes globally unique), Route Targets (control import/export), MP-BGP (carries VPNv4 routes between PEs), and the two-label MPLS stack (outer transport, inner VPN) to deliver private routing services over a shared backbone.

The architecture is more complex than a single concept can capture, but each piece has a single clear job. Master the RD/RT distinction, the two-label stack, and the MP-BGP send-community-extended requirement, and L3VPN troubleshooting becomes tractable. Bookmark this article alongside the MPLS cluster pillar, the MP-BGP article, and the MPLS labels article.