MPLS Layer 3 VPNs are the backbone of enterprise WAN connectivity and service provider networks worldwide. If you’ve ever wondered how a large organization connects dozens of branch offices over a carrier’s network while keeping each customer’s traffic completely isolated, MPLS L3VPN is the answer. In this guide, I’ll walk through building and verifying an MPLS L3VPN from scratch on Cisco IOS-XE — with real CLI output at every step.
Before diving in, it helps to have solid BGP fundamentals in place. The BGP protocol guide covers the mechanics we’ll rely on heavily here, particularly for the VPNv4 address family and community attributes. If you’re also running OSPF in your provider core and hit adjacency issues, the OSPF troubleshooting guide is an excellent companion reference.
MPLS L3VPN Architecture: The Three-Tier Model
MPLS L3VPN uses three distinct router roles:
- Provider (P) routers: Core routers that forward labeled packets. They never see customer routes — only MPLS labels and provider IGP prefixes.
- Provider Edge (PE) routers: The intelligence of the design. Each PE maintains a separate VRF per customer, exchanges VPN routes with other PEs via MP-BGP, and imposes or strips MPLS labels at the network edge.
- Customer Edge (CE) routers: Customer-owned devices that connect to PE routers. CEs have no MPLS awareness whatsoever — they simply run a standard routing protocol or static routes toward the PE.
Three additional concepts tie everything together:
- VRF (Virtual Routing and Forwarding): A separate routing and forwarding table on the PE, isolated per customer. Traffic in VRF A is completely invisible to VRF B, even on the same physical router.
- Route Distinguisher (RD): A 64-bit value prepended to customer IPv4 prefixes to make them globally unique inside BGP. Two customers can use the same 10.0.0.0/8 space — the RD makes their routes distinguishable in the shared BGP table.
- Route Target (RT): Extended BGP community values that control which VRFs import and export routes. RT is how you implement hub-and-spoke, full-mesh, or extranet topologies without touching the core configuration.
Lab Topology
This guide uses a minimal but realistic three-node provider core:
Site A Provider Core Site B
------ ------------- ------
CE1 PE1 PE2 CE2
192.168.1.0/24 Lo: 10.0.0.1 Lo: 10.0.0.3 192.168.2.0/24
| | | |
+--172.16.1.x---+ +--172.16.2.x---+
| |
10.1.0.0/30 10.1.0.4/30
| |
+----P1---------+
Lo: 10.0.0.2Customer: ACME Corp
Provider AS: 65001
CE1 AS: 65100 | CE2 AS: 65200
PE-CE routing: eBGP
Step 1: Provider IGP — OSPF in the Core
P and PE routers need full reachability to each other’s loopbacks before LDP can form adjacencies. We use OSPF in the provider backbone for this purpose:
! On PE1
router ospf 1
router-id 10.0.0.1
network 10.0.0.1 0.0.0.0 area 0
network 10.1.0.0 0.0.0.3 area 0
! On P1
router ospf 1
router-id 10.0.0.2
network 10.0.0.2 0.0.0.0 area 0
network 10.1.0.0 0.0.0.3 area 0
network 10.1.0.4 0.0.0.3 area 0
! On PE2
router ospf 1
router-id 10.0.0.3
network 10.0.0.3 0.0.0.0 area 0
network 10.1.0.4 0.0.0.3 area 0Verify OSPF neighbors are FULL before proceeding:
PE1# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.0.0.2 1 FULL/DR 00:00:32 10.1.0.2 GigabitEthernet0/1Step 2: Enable MPLS and LDP on Core Interfaces
Enable MPLS label switching and LDP on every provider-facing interface. Do not enable MPLS on CE-facing interfaces — that would expose MPLS signaling to the customer.
! On PE1 — provider-facing interface only
interface GigabitEthernet0/1
mpls ip
! On P1 — both provider-facing interfaces
interface GigabitEthernet0/0
mpls ip
interface GigabitEthernet0/1
mpls ip
! On PE2 — provider-facing interface only
interface GigabitEthernet0/0
mpls ipLDP automatically discovers neighbors via multicast hello messages and establishes TCP sessions on port 646. Verify the adjacency:
PE1# show mpls ldp neighbor
Peer LDP Ident: 10.0.0.2:0; Local LDP Ident 10.0.0.1:0
TCP connection: 10.0.0.2.51392 - 10.0.0.1.646
State: Oper; Msgs sent/rcvd: 28/27; Upstream/Downstream: 0/3
Up time: 00:04:12
LDP discovery sources:
GigabitEthernet0/1, Src IP addr: 10.1.0.2
Addresses bound to peer LDP Ident:
10.0.0.2 10.1.0.2 10.1.0.5Check the MPLS forwarding table to confirm label bindings for all loopbacks exist:
PE1# show mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
16 Pop Label 10.0.0.2/32 0 Gi0/1 10.1.0.2
17 17 10.0.0.3/32 0 Gi0/1 10.1.0.2PE1 can reach PE2’s loopback (10.0.0.3/32) via label 17 through P1. The label-switched path is in place.
Step 3: Configure VRFs on PE Routers
Each PE needs a VRF for the ACME customer. For a full-mesh topology where all sites can communicate freely, export and import the same RT value on every PE:
! On PE1
ip vrf ACME
rd 65001:100
route-target export 65001:100
route-target import 65001:100
! On PE2 — identical VRF definition
ip vrf ACME
rd 65001:100
route-target export 65001:100
route-target import 65001:100Now assign the CE-facing interface into the VRF. Critical: assigning an interface to a VRF removes any existing IP address — always set the VRF before the IP:
! On PE1 — CE1 connects to Gi0/0
interface GigabitEthernet0/0
ip vrf forwarding ACME
ip address 172.16.1.1 255.255.255.252
no shutdown
! On PE2 — CE2 connects to Gi0/1
interface GigabitEthernet0/1
ip vrf forwarding ACME
ip address 172.16.2.1 255.255.255.252
no shutdownVerify the VRF is present with its connected route:
PE1# show ip route vrf ACME
Routing Table: ACME
172.16.1.0/30 is variably subnetted, 2 subnets, 2 masks
C 172.16.1.0/30 is directly connected, GigabitEthernet0/0
L 172.16.1.1/32 is directly connected, GigabitEthernet0/0Step 4: MP-BGP Between PE Routers (VPNv4 Address Family)
Standard BGP cannot carry VPN routes. We need Multiprotocol BGP with the VPNv4 address family. PEs peer using loopback addresses so the session survives any single link failure in the core:
! On PE1
router bgp 65001
bgp router-id 10.0.0.1
bgp log-neighbor-changes
no bgp default ipv4-unicast
!
neighbor 10.0.0.3 remote-as 65001
neighbor 10.0.0.3 update-source Loopback0
!
address-family vpnv4
neighbor 10.0.0.3 activate
neighbor 10.0.0.3 send-community both
exit-address-family
! On PE2
router bgp 65001
bgp router-id 10.0.0.3
bgp log-neighbor-changes
no bgp default ipv4-unicast
!
neighbor 10.0.0.1 remote-as 65001
neighbor 10.0.0.1 update-source Loopback0
!
address-family vpnv4
neighbor 10.0.0.1 activate
neighbor 10.0.0.1 send-community both
exit-address-familyThe send-community both statement is non-negotiable. Without it, the RT extended communities are stripped from VPN updates and route import never functions — a common and frustrating gotcha.
Verify the VPNv4 peering is established:
PE1# show bgp vpnv4 unicast all summary
BGP router identifier 10.0.0.1, local AS number 65001
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.0.3 4 65001 12 12 1 0 0 00:03:41 0Step 5: PE-CE Routing with eBGP
With the VPNv4 fabric established, connect the customer edge routers. eBGP is the most common and operationally clean choice for PE-CE routing in service provider environments:
! On PE1 — eBGP toward CE1 in VRF ACME context
router bgp 65001
address-family ipv4 vrf ACME
neighbor 172.16.1.2 remote-as 65100
neighbor 172.16.1.2 activate
neighbor 172.16.1.2 as-override
exit-address-family
! On CE1
router bgp 65100
bgp router-id 192.168.1.1
neighbor 172.16.1.1 remote-as 65001
!
address-family ipv4
neighbor 172.16.1.1 activate
network 192.168.1.0 mask 255.255.255.0
exit-address-family! On PE2 — eBGP toward CE2 in VRF ACME context
router bgp 65001
address-family ipv4 vrf ACME
neighbor 172.16.2.2 remote-as 65200
neighbor 172.16.2.2 activate
neighbor 172.16.2.2 as-override
exit-address-family
! On CE2
router bgp 65200
bgp router-id 192.168.2.1
neighbor 172.16.2.1 remote-as 65001
!
address-family ipv4
neighbor 172.16.2.1 activate
network 192.168.2.0 mask 255.255.255.0
exit-address-familyThe as-override command replaces the CE’s AS number in the AS_PATH with the PE’s AS when advertising routes onward. Without it, BGP loop prevention drops routes at the far-end CE because they appear to have transited that CE’s own ASN — a detail that bites almost everyone the first time they build this.
Verification: Confirming End-to-End Connectivity
Start from the VRF routing table on each PE:
PE1# show ip route vrf ACME bgp
B 192.168.1.0/24 [20/0] via 172.16.1.2, 00:02:14
B 192.168.2.0/24 [200/0] via 10.0.0.3, 00:01:58, MPLS label 18PE1 has CE1’s prefix via eBGP (administrative distance 20) and CE2’s prefix via iBGP from PE2 (distance 200) with an MPLS label for transport across the core.
Check the full VPNv4 BGP table to see both sites’ prefixes with RT communities attached:
PE1# show bgp vpnv4 unicast all
BGP table version is 5, local router ID is 10.0.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 65001:100 (default for vrf ACME)
*> 192.168.1.0/24 172.16.1.2 0 0 65100 i
*>i 192.168.2.0/24 10.0.0.3 0 100 0 65200 iThe *>i marker on the second route indicates it’s an iBGP-learned best path. Now the definitive test — ping across sites from CE1:
CE1# show ip route bgp
B 192.168.2.0/24 [20/0] via 172.16.1.1, 00:01:44
CE1# ping 192.168.2.1 source 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/3/5 msFull reachability between ACME’s two sites, over the shared MPLS core, with zero leakage into any other VRF.
Troubleshooting: Common Failure Points
MPLS L3VPN has multiple independent layers, which means failures can be isolated to a specific tier. Work from the bottom up:
LDP adjacency not forming: Confirm MPLS is enabled on the correct interfaces and that the router IDs are reachable via the provider IGP. LDP uses TCP port 646 — check ACLs if interface-level config looks right but the session won’t establish.
PE1# show mpls ldp discovery
Local LDP Identifier:
10.0.0.1:0
Discovery Sources:
Interfaces:
GigabitEthernet0/1 (ldp): xmit/recv
LDP Id: 10.0.0.2:0VPNv4 session up but no routes exchanged: Almost always send-community both is missing on one side. Without the extended community, RT values aren’t transmitted, and import policy on the receiving PE never matches. Also verify the address-family vpnv4 neighbor activation exists on both ends.
PE1# show bgp vpnv4 unicast all neighbors 10.0.0.3 advertised-routesRoutes present in VRF table but pings fail: Verify the VPN label stack end-to-end. The egress PE should have a valid inner label (VPN label) for the route:
PE2# show bgp vpnv4 unicast all labels
Network Next Hop In label/Out label
Route Distinguisher: 65001:100
192.168.1.0/24 10.0.0.1 nolabel/18
192.168.2.0/24 172.16.2.2 18/nolabelTraceroute shows unlabeled hops mid-path: A P router missing mpls ip on an interface will drop labeled packets. The TTL-exceeded ICMP response will reveal exactly where the label stack is being lost.
as-override forgotten: If the far-end CE isn’t receiving routes and you’re using different private ASNs per site, missing as-override is the first thing to check. The BGP table on the CE will show the prefix with its AS path, and the CE’s own AS appearing in that path triggers the loop-prevention drop.
Scaling to Production: Route Reflectors and Inter-AS
This lab uses direct PE-to-PE iBGP peering, which doesn’t scale. A network with 20 PEs would require 190 iBGP sessions — full mesh becomes unmanageable fast. The standard solution is deploying Route Reflectors, typically on dedicated devices or on P routers with sufficient memory, to distribute VPNv4 routes between PEs without requiring every pair to peer directly.
For deployments that span multiple autonomous systems — connecting customer sites across two different service providers, or across separate AS domains within a single carrier — Inter-AS MPLS VPN extends the L3VPN model. Option B (using eBGP to redistribute labeled VPN routes between ASBRs) is the most common production choice, though it introduces additional complexity in the label exchange between AS boundaries.
Hub-and-spoke topologies are straightforward to implement purely through RT manipulation: spoke PEs export one RT and import only the hub’s RT, while the hub PE imports all spoke RTs and exports a separate hub RT. No code changes — just RT values — make the hub the forced transit point for all inter-spoke traffic, which is useful for centralizing firewall inspection or policy enforcement.
Final Thoughts
MPLS L3VPN elegantly solves the fundamental problem of running multiple customers’ routing domains over shared infrastructure without complexity bleeding between tenants. The layered design — OSPF for loopback reachability, LDP for label distribution, MP-BGP for VPN route exchange — means each layer can be built, verified, and troubleshot independently.
The configuration looks dense on first read, but once you’ve assembled the three layers and seen that first cross-site ping succeed, the architecture becomes intuitive. From there, adding more VRFs, deploying route reflectors, or implementing extranet RT policies is incremental work on a solid foundation. If you’re managing control plane security on these PE routers as well, the Cisco CoPP guide covers how to rate-limit and protect the PE’s control plane from traffic arriving over the MPLS core — an important hardening step in any multi-tenant environment.
