Multiprotocol Label Switching revolutionized service provider networking by separating forwarding from IP routing lookups. Instead of performing longest-prefix-match at every hop, MPLS routers swap short fixed-length labels attached to packets, enabling high-speed forwarding through provider cores. Layer-3 VPN services built on MPLS allow multiple customers to share the same physical infrastructure while maintaining completely isolated routing tables. For engineers moving between enterprise and carrier environments, MPLS L3VPN concepts bridge the gap between familiar VRF-lite designs and full provider-scale implementations.
The fundamental building block is the label switched path — a predetermined sequence of label swaps from ingress to egress provider edge router. Control-plane protocols such as LDP or RSVP-TE distribute label bindings for IGP-learned prefixes. Data-plane forwarding uses these bindings to push, swap, and pop labels without examining customer IP headers in the core. Provider routers in the middle of the network, called P routers, maintain only the IGP and MPLS forwarding tables, not customer VPN routes.
VRF and the PE Router
Provider edge routers instantiate a virtual routing and forwarding table for each customer VPN. Customer CE routers connect to PE interfaces assigned to the appropriate VRF. Routes learned from CE devices via BGP or static configuration populate only that VRF's routing table. The PE never leaks routes between VRFs unless explicitly configured with route leaking for shared services like internet access or DNS. This isolation is the defining characteristic of L3VPN — customers can use overlapping private address space without conflict because each VRF maintains an independent forwarding context.
Each VRF requires its own CE-facing interfaces, route distinguisher, and import-export policy expressed through route targets. Memory and CPU scale with the number of VRFs and routes per VRF, so PE sizing must account for both the global BGP VPNv4 table and per-VRF RIB and FIB entries. Modern PE platforms handle thousands of VRFs, but older hardware may require careful capacity planning before accepting large managed service contracts.
MP-BGP VPNv4 Signaling
PE routers exchange customer routes using Multiprotocol BGP in the VPNv4 address family. A VPNv4 NLRI combines a 64-bit route distinguisher with the customer's IPv4 prefix, making overlapping addresses globally unique in the BGP table. When a PE advertises a customer route, it attaches extended communities including route targets that describe VPN membership. Receiving PE routers compare route targets against their local VRF import policies and install matching routes into the correct VRF.
Route distinguishers must be unique per VRF per PE, but route targets are typically shared among all VRFs belonging to the same VPN. Hub-and-spoke VPN topologies use separate route targets for hub and spoke VRFs, with the hub importing both while spokes import only the hub RT. Full-mesh any-to-any VPNs share a single route target across all sites. Getting route target design wrong is the most common cause of missing routes in MPLS VPN deployments — always verify import and export lists on both PEs when troubleshooting connectivity between sites.
Label Stack and Packet Flow
When a PE forwards a customer packet into the MPLS core, it imposes a label stack. The inner label, called the VPN label, identifies the egress VRF on the remote PE. The outer label corresponds to the IGP prefix of the remote PE's loopback, learned via LDP or RSVP-TE. P routers swap only the outer label at each hop. At the penultimate hop, penultimate hop popping removes the outer label so the egress PE receives the packet with only the VPN label remaining, which it uses to forward into the correct VRF.
Understanding this two-label model is critical for MPLS troubleshooting. Traceroute within a VPN shows only customer-facing hops because core P routers are invisible at the IP layer. MPLS TTL propagation settings and MTU issues — especially the 12-byte label overhead per stack entry — cause subtle problems when customer packets are already near path MTU. Ensure CE interfaces account for MPLS overhead or enable fragmentation control at the PE.
CE Routing Options
Customer edge routers can learn routes through BGP or static configuration. BGP between CE and PE allows dynamic route exchange with the provider advertising VPN routes to the customer and the customer advertising its local prefixes to the provider. Static routing suits small sites with a single default route toward the PE. OSPF or EIGRP between CE and PE with PE-CE protocol extensions is supported on many platforms for customers who want to extend their IGP into the provider edge without running BGP on the CE.
When using BGP on the CE, the PE typically assigns the CE a unique AS number or uses allowas-in for sites that must receive routes with their own AS in the path. SOO — site of origin — extended communities prevent routing loops in hub-and-spoke designs where the hub advertises routes back to spokes that might otherwise prefer the hub path over their direct spoke-to-spoke paths through the provider.
Operations and Troubleshooting
Verify end-to-end VPN connectivity by checking VRF route tables on both PEs, confirming VPNv4 BGP sessions are established, and validating that route targets match. Use MPLS ping and traceroute utilities that inject labeled probes through the LSP to isolate core forwarding failures from BGP signaling problems. Monitor label binding tables on P routers for missing or stale entries that indicate LDP session issues with IGP synchronization.
MPLS L3VPN remains the backbone of many enterprise WAN services even as SD-WAN overlays grow. Carrier-managed VPNs, wholesale services, and cloud interconnects frequently terminate on MPLS PE routers. Engineers who understand VRF isolation, MP-BGP signaling, and label stack forwarding can diagnose problems that span customer premises, provider edge, and provider core — a skill set that transfers directly to modern segment routing and EVPN deployments built on the same MPLS foundations.
Inter-AS VPN Options
Option A connects CE routers directly to PE routers in adjacent ASes with eBGP VPNv4 or separate eBGP IPv4 sessions per VRF. Simple but requires managing many CE-PE connections at AS boundaries. Option B connects PE routers directly via eBGP VPNv4 between ASes, carrying all customer VPN routes across the boundary. Option C uses route reflectors exchanging VPNv4 routes between ASes without PE-PE sessions, scaling better for many VPNs crossing provider boundaries.
Carrier supporting carrier models allow a smaller provider to offer MPLS VPN services using a larger provider's MPLS core as transport. The customer-facing provider runs VRFs on its PE while the carrier provides label switched connectivity between those PE routers. Understanding inter-AS options matters when enterprise VPNs span multiple service providers or when troubleshooting routes that cross provider boundaries with different signaling implementations.
Segment routing MPLS and SRv6 represent the evolution path from LDP-signaled LSPs toward source-routed label stacks programmed through BGP extensions. Many providers migrate PE connectivity toward segment routing while maintaining VPNv4 service offerings. Engineers familiar with classic MPLS L3VPN operation can extend knowledge to SR-MPLS VPN deployments as providers upgrade core signaling without changing the VRF and route target concepts customers interact with.