What Is MPLS L3VPN and Why Should You Care?
If you’ve ever wondered how service providers deliver private WAN connectivity to enterprise customers across a shared IP backbone—while keeping each customer’s traffic completely isolated—MPLS Layer 3 VPN is the answer. It’s one of the most widely deployed VPN technologies in carrier and large enterprise networks today, and understanding it deeply separates competent network engineers from truly senior ones.
MPLS L3VPN combines three foundational technologies: Multi-Protocol Label Switching (MPLS) for efficient label-based forwarding in the core, Virtual Routing and Forwarding (VRF) instances on Provider Edge (PE) routers to maintain per-customer routing tables, and Multi-Protocol BGP (MP-BGP) to distribute customer routes between PE routers. The result is a scalable, traffic-isolated VPN service that looks like a private routed network to the customer, while sharing provider infrastructure underneath.
This guide walks through a complete IOS-XE MPLS L3VPN configuration from scratch: LDP setup, VRF definitions, MP-BGP peering, and verification. We’ll use real CLI output throughout so you know exactly what a working deployment looks like. We’ll also cover the most common failure points.
MPLS L3VPN Topology and Roles
Before touching the CLI, make sure you understand the roles in an MPLS L3VPN network:
- P (Provider) routers: Core routers that only do MPLS label switching. They have no knowledge of customer routes or VRFs. Their job is fast label-swap forwarding.
- PE (Provider Edge) routers: The critical devices. They connect to customer sites, maintain per-customer VRF routing tables, and participate in MP-BGP to exchange VPN routes with other PEs.
- CE (Customer Edge) routers: Customer-owned routers that peer with the PE via standard routing protocols (OSPF, EIGRP, BGP, or static). CEs have no awareness of MPLS.
For this lab, we’ll use the following topology:
CE-A (10.10.10.1) ---- PE1 (lo0: 1.1.1.1) ---- P (lo0: 2.2.2.2) ---- PE2 (lo0: 3.3.3.3) ---- CE-B (10.10.20.1)
| |
VRF: CUSTOMER-A VRF: CUSTOMER-APE1 and PE2 will establish an MP-BGP session over the provider backbone. The P router just does label switching—it won’t even see the customer prefixes.
Step 1: Enable MPLS and LDP on the Provider Core
MPLS forwarding relies on Label Distribution Protocol (LDP) to exchange labels for IGP routes. Every router in the provider core (P and PE routers) must have LDP enabled on their core-facing interfaces.
First, enable CEF (required for MPLS) and configure LDP globally:
! On PE1, PE2, and P router:
ip cef
mpls ip
mpls ldp router-id Loopback0 force
! Enable MPLS on core-facing interfaces
interface GigabitEthernet0/0
description TO-P-ROUTER
mpls ipVerify LDP is up and exchanging labels:
PE1# show mpls ldp neighbor
Peer LDP Ident: 2.2.2.2:0; Local LDP Ident 1.1.1.1:0
TCP connection: 2.2.2.2.646 - 1.1.1.1.34982
State: Oper; Msgs sent/rcvd: 52/51; Downstream
Up time: 00:15:23
LDP discovery sources:
GigabitEthernet0/0, Src IP addr: 10.0.12.2
Addresses bound to peer LDP Ident:
10.0.12.2 2.2.2.2Also confirm labels are being assigned to loopback routes—these are critical because PE-to-PE LSPs are built over the loopbacks:
PE1# show mpls ldp bindings 3.3.3.3 32
lib entry: 3.3.3.3/32, rev 22
local binding: label: 100
remote binding: lsr: 2.2.2.2:0, label: 200A missing or incorrect label binding here is one of the most common reasons VPN traffic fails to traverse the core. Make sure your IGP (OSPF, IS-IS) is also advertising all loopback /32 routes correctly before proceeding.
Step 2: Configure VRF Instances on the PE Routers
VRFs are virtual routing tables that segment customer traffic. Each customer gets a dedicated VRF. The two key parameters that make VPN routing work across PE routers are the Route Distinguisher (RD) and Route Targets (RT).
- RD: A 64-bit prefix prepended to customer IPv4 prefixes to make them globally unique in the BGP VPNv4 address family. Even if two customers use the same 10.0.0.0/8 range, their VPNv4 prefixes differ because of the RD.
- RT: Controls route import/export. A route tagged with export RT
65000:100is imported by any VRF configured with import RT65000:100. This is how you control which sites share routes.
! On PE1:
vrf definition CUSTOMER-A
rd 65000:100
!
address-family ipv4
route-target export 65000:100
route-target import 65000:100
exit-address-family
!
! Bind the customer-facing interface to the VRF:
interface GigabitEthernet0/1
description TO-CE-A
vrf forwarding CUSTOMER-A
ip address 172.16.1.1 255.255.255.252
no shutdown! On PE2 (mirror config):
vrf definition CUSTOMER-A
rd 65000:101
!
address-family ipv4
route-target export 65000:100
route-target import 65000:100
exit-address-family
!
interface GigabitEthernet0/1
description TO-CE-B
vrf forwarding CUSTOMER-A
ip address 172.16.2.1 255.255.255.252
no shutdownNotice PE1 uses RD 65000:100 and PE2 uses 65000:101 — different RDs per PE is a common design pattern that simplifies route reflector configurations. Both PEs use the same RT (65000:100) for import and export, which means all sites for CUSTOMER-A see each other’s routes.
Verify the VRF is created correctly:
PE1# show vrf detail CUSTOMER-A
VRF CUSTOMER-A (VRF Id = 1); default RD 65000:100; default VPNID
New Routing Table associated; Tables: IPv4 Unicast
Flags: 0x180C
Interfaces:
GigabitEthernet0/1
Address family IPv4 Unicast (Table ID = 0x1):
Export VPN route-target communities
RT:65000:100
Import VPN route-target communities
RT:65000:100 Step 3: Configure MP-BGP Between PE Routers
MP-BGP carries the VPNv4 routes (customer prefixes + RD) between PE routers. You need to enable the vpnv4 address family explicitly. This is where many engineers get tripped up—forgetting send-community extended is a classic oversight that silently breaks RT-based import filtering.
! On PE1:
router bgp 65000
bgp log-neighbor-changes
bgp router-id 1.1.1.1
!
neighbor 3.3.3.3 remote-as 65000
neighbor 3.3.3.3 update-source Loopback0
!
address-family vpnv4
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 send-community extended
exit-address-family! On PE2 (mirror):
router bgp 65000
bgp router-id 3.3.3.3
!
neighbor 1.1.1.1 remote-as 65000
neighbor 1.1.1.1 update-source Loopback0
!
address-family vpnv4
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 send-community extended
exit-address-familyIf you have more than two PEs, use a Route Reflector to avoid full mesh. The RR needs the vpnv4 address family configured and route-reflector-client set on each PE peer.
Confirm the BGP session is established and VPNv4 prefixes are exchanged:
PE1# show bgp vpnv4 unicast all summary
BGP router identifier 1.1.1.1, local AS number 65000
BGP table version is 7, main routing table version 7
6 network entries using 864 bytes of memory
6 path entries using 504 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
3.3.3.3 4 65000 28 27 7 0 0 00:12:44 2Two prefixes received from PE2 — looking good. Now check that the routes from CUSTOMER-A are being properly imported into the VRF routing table:
PE1# show bgp vpnv4 unicast vrf CUSTOMER-A
BGP table version is 7, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Network Next Hop Metric LocPrf Weight Path
*>i 10.10.20.0/24 3.3.3.3 0 100 0 i
*> 10.10.10.0/24 172.16.1.2 0 0 iYou can see PE1 has a local route for CE-A’s network (10.10.10.0/24) and an iBGP route from PE2 for CE-B’s network (10.10.20.0/24). The route for CE-B points to PE2’s loopback (3.3.3.3) as the next hop—this is the MPLS LSP next hop, not the customer address.
Step 4: Configure Routing Between PE and CE
The PE-CE routing can use any protocol—OSPF, EIGRP, BGP, or static routes. For this lab we’ll use a simple OSPF redistribution into BGP approach, which is common in service provider environments.
! On PE1 — OSPF within the VRF context:
router ospf 100 vrf CUSTOMER-A
router-id 172.16.1.1
redistribute bgp 65000 subnets
network 172.16.1.0 0.0.0.3 area 0
!
! Redistribute OSPF into BGP for this VRF:
router bgp 65000
address-family ipv4 vrf CUSTOMER-A
redistribute ospf 100
redistribute connected
exit-address-family! On CE-A:
router ospf 1
network 10.10.10.0 0.0.0.255 area 0
network 172.16.1.0 0.0.0.3 area 0Verify the OSPF adjacency formed between PE1 and CE-A:
PE1# show ip ospf neighbor vrf CUSTOMER-A
Neighbor ID Pri State Dead Time Address Interface
172.16.1.2 1 FULL/BDR 00:00:36 172.16.1.2 GigabitEthernet0/1Now check the VRF routing table on PE1 to confirm CE-A’s routes are present:
PE1# show ip route vrf CUSTOMER-A
Routing Table: CUSTOMER-A
...
10.0.0.0/24 is subnetted, 2 subnets
O 10.10.10.0 [110/2] via 172.16.1.2, 00:08:14, GigabitEthernet0/1
B 10.10.20.0 [200/0] via 3.3.3.3, 00:05:22
172.16.0.0/30 is subnetted, 2 subnets
C 172.16.1.0 is directly connected, GigabitEthernet0/1
B 172.16.2.0 [200/0] via 3.3.3.3, 00:05:22Both the local OSPF route and the remote BGP VPNv4 route are present. The B entries (BGP) are learned from PE2 via the MP-BGP VPNv4 session.
Step 5: End-to-End Verification
From CE-A, ping CE-B to confirm full end-to-end connectivity:
CE-A# ping 10.10.20.1 source 10.10.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.20.1, timeout is 2 seconds:
Packet sent with a source address of 10.10.10.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 msUse traceroute with the MPLS label stack to see the full forwarding path:
PE1# traceroute vrf CUSTOMER-A 10.10.20.1 source 172.16.1.1
Type escape sequence to abort.
Tracing the route to 10.10.20.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.0.12.2 [MPLS: Labels 200/300 Exp 0] 4 msec 4 msec 4 msec
2 172.16.2.1 [MPLS: Label 300 Exp 0] 5 msec 5 msec 6 msec
3 10.10.20.1 8 msec 8 msec 7 msecThe two labels in the stack are the key: the outer label (200) is the LDP transport label used by P routers to forward through the core, and the inner label (300) is the VPN label assigned by PE2 to identify the correct VRF when the packet arrives. This two-label stack is the heart of how MPLS L3VPN keeps customer traffic isolated.
Common Failure Points and How to Diagnose Them
MPLS L3VPN issues usually fall into a few categories. Here’s how to quickly isolate them:
VPN Routes Not Showing in VRF Table
Run show bgp vpnv4 unicast vrf CUSTOMER-A on the PE. If the remote prefix is missing, check:
- Is the MP-BGP VPNv4 session up? (
show bgp vpnv4 unicast all summary) - Is
send-community extendedconfigured on the BGP neighbor? - Do the import and export RTs match between PE routers?
Traffic Drops in the MPLS Core
If the VRF routing table looks correct but traffic still fails, check the LSP:
PE1# show mpls forwarding-table vrf CUSTOMER-A 10.10.20.0 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
None 300 10.10.20.0/24[V] 0 Gi0/0 10.0.12.2If the outgoing label is No label or the interface shows None, your LDP bindings are broken. Run show mpls ldp bindings and show mpls ldp neighbor to diagnose.
PE-CE OSPF Adjacency Won’t Form
Verify the interface is in the VRF before debugging OSPF. A common mistake is forgetting vrf forwarding on the PE interface—this wipes the IP address, and the interface ends up in the global table instead of the VRF.
PE1# show ip ospf interface GigabitEthernet0/1
! If VRF isn't shown in the output, the interface is in the global table — wrong.Scaling Beyond the Lab: Route Reflectors and Extra-Net VRFs
In production environments with dozens or hundreds of PEs, you’ll need BGP Route Reflectors to avoid full mesh. The RR must be configured with the vpnv4 address family and doesn’t need VRFs—it just reflects VPNv4 NLRIs between clients without processing them. Use two RRs for redundancy and always place them on high-availability P routers.
For inter-VPN connectivity (extranet), you simply import a second customer’s RT into the target VRF:
vrf definition SHARED-SERVICES
rd 65000:999
address-family ipv4
route-target export 65000:999
route-target import 65000:999
route-target import 65000:100 ! Import CUSTOMER-A routes into shared VRF
exit-address-familyThis flexibility is one of the most powerful aspects of the RT mechanism—you can build complex hub-and-spoke or partial-mesh VPN topologies purely through RT import/export policy, with no additional tunnels or GRE overlays required. Since we used OSPF for PE-CE routing in this guide, it’s worth having the OSPF troubleshooting guide bookmarked—redistribution between OSPF and MP-BGP is one of the most common sources of unexpected route behavior in L3VPN deployments.
If you want to automate VRF provisioning across multiple PEs—adding new customers without manual CLI work—Python with Netmiko or NAPALM makes this straightforward. The Python network automation guide covers exactly how to template and push VRF configurations across a fleet of PE routers.
Quick Reference: Key Verification Commands
| Command | What It Checks |
|---|---|
show mpls ldp neighbor |
LDP sessions and peer state |
show mpls ldp bindings |
Label-to-prefix bindings |
show vrf detail |
VRF RD, RT, and interface membership |
show bgp vpnv4 unicast all summary |
MP-BGP VPNv4 session state and prefix counts |
show bgp vpnv4 unicast vrf CUST-A |
VPN routes in a specific VRF |
show ip route vrf CUST-A |
Full VRF routing table |
show mpls forwarding-table vrf CUST-A |
LFIB entries for VPN prefixes |
ping vrf CUST-A IP source IP |
End-to-end VPN connectivity test |
Wrapping Up
MPLS L3VPN is a mature, battle-tested technology that underpins most service provider WAN offerings. Getting it right requires understanding all three layers working together: LDP building the transport LSP through the core, VRFs isolating customer routing on the PEs, and MP-BGP distributing VPNv4 routes with RT-based import/export policy controlling which sites can reach each other.
The most important debugging principle: always work from the data plane up. Confirm MPLS labels are assigned and LDP is functional before chasing BGP or VRF issues. A missing LDP label binding silently breaks everything downstream, so start with show mpls ldp bindings and show mpls forwarding-table before assuming BGP is the culprit.
For deeper context on how this fits into the broader BGP ecosystem—particularly how VPNv4 extends standard IPv4 BGP with the additional address family—the BGP fundamentals guide is worth a read if you haven’t already. And if you’re running a mix of IOS and IOS-XE PEs, the IOS vs IOS-XE vs IOS-XR comparison covers the key configuration differences you’ll encounter.
MPLS L3VPN configurations don’t change much once they’re right, but when they break they break badly. Knowing these verification commands cold is what makes the difference between a 15-minute fix and a 3-hour bridge call.
