MPLS (Multiprotocol Label Switching): The Complete Guide

MPLS (Multiprotocol Label Switching, full form: Multiprotocol Label Switching) is the protocol that runs the inside of every major service provider's network and a substantial fraction of large enterprise WANs. It uses fixed-length labels instead of IP lookup to forward packets, decouples the forwarding plane from the routing plane, and serves as the substrate for VPNs (L3VPN, L2VPN), traffic engineering (RSVP-TE), and now segment routing. It is also the protocol that SD-WAN was supposed to replace, except most production networks still run both.

This is the cluster overview for the full PingLabz MPLS series: labels and the label stack, LDP for label distribution, MPLS L3VPN with MP-BGP and VPNv4, traffic engineering, and the segment routing successor story. We will work through what MPLS actually does, how labels move packets through the network, the L3VPN model that made MPLS a service-provider standard, and the modern segment-routing direction. If you are studying for CCIE Service Provider, designing an MPLS deployment, or trying to understand what your carrier is selling you, start here. Every capture on this page comes from a real five-router IOS XE lab (CE1 - PE1 - P - PE2 - CE2) running OSPF as the IGP, LDP across the core, and MP-iBGP carrying VPNv4 between the two PEs.

What MPLS Solves

Two problems drove MPLS in the late 1990s:

1. IP forwarding was slow. Routers had to perform a longest-prefix-match lookup against the full routing table for every packet. CPUs of the era struggled at gigabit speeds. MPLS replaced this with a fixed-length label lookup, which is dramatically faster.
2. Traffic engineering was impossible with pure IP. IP routing picks the shortest path; you cannot easily say "send this customer's traffic over the western backbone, this other customer's traffic over the eastern backbone." MPLS enabled explicit path control.

The hardware-acceleration story for IP eventually caught up - modern routers do longest-prefix-match in silicon at terabit speeds - but by then MPLS had become the substrate for an even more important capability: VPNs. MPLS L3VPN lets a service provider carry many customers' overlapping IP address spaces over one shared backbone, with each customer seeing only their own routes and addresses. That capability is what made MPLS a service-provider standard.

By 2026 the original speed argument is moot, traffic engineering has spawned segment routing as a successor, and SD-WAN has eaten into MPLS's enterprise WAN role. But MPLS still runs underneath most carrier networks and most of the BGP-VPN deployments enterprises buy from carriers.

How MPLS Works (the 10,000-Foot View)

An MPLS network has three router roles:

A packet's journey:

1. The customer's CE router sends an IP packet to the PE router.
2. The PE looks up the destination, decides which Label Switched Path (LSP) to use, pushes one or more labels onto the packet, and forwards.
3. Each P router along the path looks at the outermost label, swaps it for the next hop's expected label (label switching), and forwards.
4. The egress PE pops the label(s) and forwards the original packet (or the inner packet of an L2VPN) to the destination CE.

This is fundamentally different from IP forwarding. The P routers do not look at IP at all - they only see the MPLS label and forward based on that. The label-switched path is determined when the LSP is set up, not per-packet. This is what enables traffic engineering, and what makes the same backbone usable for L3VPNs, L2VPNs, traffic engineering, and IP transit simultaneously.

MPLS Labels and the Label Stack

An MPLS label is a 32-bit shim header inserted between the data-link layer header (e.g. Ethernet) and the IP header. The format:

+-----------------+-----+---+-------------+
|     Label       | EXP | S |     TTL     |
| 20 bits         | 3   | 1 | 8 bits      |
+-----------------+-----+---+-------------+

Multiple labels can be stacked. A typical L3VPN packet has two labels: an outer "transport" label that gets it across the MPLS core, and an inner "VPN" label that identifies which customer VPN it belongs to. The S bit on the inner label is 1; the outer label has S=0.

The lab P router (the one in the middle of the core) shows the label-swap that drives every MPLS diagram. Local label in, outgoing label out, prefix that label maps to:

P#show mpls forwarding-table
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
16         Pop Label  10.255.0.1/32    1548          Et0/0      10.30.30.1
17         Pop Label  10.255.0.2/32    1494          Et0/1      10.30.31.2

P assigns label 16 for PE1's loopback (10.255.0.1/32) and label 17 for PE2's loopback (10.255.0.2/32). When traffic carrying one of those labels arrives, P pops the transport label and forwards the inner packet on - penultimate-hop popping (PHP). PHP saves the egress PE one label lookup; the imp-null binding that triggers it is the default behaviour for the protocol's owner of a connected prefix or loopback.

"Bytes Switched" is the running counter of bytes forwarded against each label entry. After the lab traceroute (below) you will see this counter incrementing.

For the full byte-level walkthrough, see MPLS Labels Explained.

LDP: Label Distribution Protocol

Labels do not appear by magic. Some protocol must distribute them so each router knows which label to use for which destination. Three main label distribution protocols exist:

LDP is the workhorse. Every PE and P router runs LDP, builds a session with each neighbor, and exchanges label mappings: "for prefix X, I will use label Y." The forwarding state derives from the IP routing table - LDP simply assigns labels for each prefix in the IGP and shares those mappings.

Enabling LDP on Cisco IOS XE is two interface-level lines plus a global declaration of the protocol:

! global
mpls label protocol ldp
!
! per core-facing interface
interface Ethernet0/1
 ip address 10.30.30.1 255.255.255.252
 ip ospf 1 area 0
 mpls ip

Run that on every P and PE core-facing interface. LDP discovers neighbors using hello messages on UDP 646, then opens a TCP session on the same port to exchange label mappings. The session is established between the highest IP on the router and the neighbor (often the loopback in production), not necessarily the IP on the link.

The lab P router has two LDP neighbors (PE1 and PE2). Both sessions are Oper, with the peer's loopback as the LDP Ident:

P#show mpls ldp neighbor
    Peer LDP Ident: 10.255.0.1:0; Local LDP Ident 10.255.0.5:0
        TCP connection: 10.255.0.1.646 - 10.255.0.5.37099
        State: Oper; Msgs sent/rcvd: 12/12; Downstream
        Up time: 00:04:04
        LDP discovery sources:
          Ethernet0/0, Src IP addr: 10.30.30.1
        Addresses bound to peer LDP Ident:
          10.30.30.1      10.255.0.1
    Peer LDP Ident: 10.255.0.2:0; Local LDP Ident 10.255.0.5:0
        TCP connection: 10.255.0.2.646 - 10.255.0.5.33181
        State: Oper; Msgs sent/rcvd: 12/12; Downstream
        Up time: 00:03:59
        LDP discovery sources:
          Ethernet0/1, Src IP addr: 10.30.31.2
        Addresses bound to peer LDP Ident:
          10.30.31.2      10.255.0.2

Each Peer LDP Ident is a router-id:label-space-id pair (the label space is almost always 0 for unicast). "Downstream" is the label-distribution method - the downstream router advertises labels for prefixes it is the next hop for. "Addresses bound" is the set of interface IPs the peer announced in its LDP address message, used to map next-hop IPs back to the right LSP.

The Label Information Base (LIB) on PE1 shows the labels PE1 chose locally and the labels its neighbour (P) is willing to receive:

PE1#show mpls ldp bindings
  lib entry: 10.30.30.0/30, rev 4
    local binding:  label: imp-null
    remote binding: lsr: 10.255.0.5:0, label: imp-null
  lib entry: 10.30.31.0/30, rev 8
    local binding:  label: 17
    remote binding: lsr: 10.255.0.5:0, label: imp-null
  lib entry: 10.255.0.1/32, rev 2
    local binding:  label: imp-null
    remote binding: lsr: 10.255.0.5:0, label: 16
  lib entry: 10.255.0.2/32, rev 10
    local binding:  label: 18
    remote binding: lsr: 10.255.0.5:0, label: 17
  lib entry: 10.255.0.5/32, rev 6
    local binding:  label: 16
    remote binding: lsr: 10.255.0.5:0, label: imp-null

Read it as: "for prefix X, I (PE1) will use label A locally; my peer (P) tells me to send packets to X with label B." The imp-null entries are PHP signals - "do not bother imposing my label on packets for this prefix; pop the previous label and send native IP." For the loopback of P (10.255.0.5/32), P is the owner, so P says imp-null and PE1 will pop the label before sending.

For LDP fundamentals, configuration, and verification, see LDP and MPLS Label Distribution.

MPLS L3VPN: The Service That Made MPLS Successful

The L3VPN (Layer 3 VPN) model is what every enterprise customer of "MPLS service" actually buys. The carrier runs an MPLS backbone and offers each customer a private routing instance (VRF) with private label space. Customer routes never mix; customer A and customer B can both use 10.0.0.0/24 without conflict.

The mechanism (RFC 4364):

1. Each customer gets a VRF on the PE.
2. The customer's IPv4 routes are converted to VPNv4 routes by prepending an 8-byte Route Distinguisher (RD) - the same prefix gets a globally unique 12-byte VPNv4 representation.
3. VPNv4 routes are exchanged between PEs via MP-BGP. Route Targets (RTs) attached as extended communities determine which VRFs import which routes.
4. Each VPN route gets a per-VPN label. Two-label stack on the wire: outer transport label (LDP) plus inner VPN label.
5. The egress PE pops both labels and forwards the original IPv4 packet into the customer's VRF.

The PE configuration is the heart of MPLS-VPN. Here is the working PE1 config from the lab - VRF definition with RD and import/export Route Targets, the customer-facing interface in the VRF, the core-facing interface in the global table with LDP, OSPF as the IGP for loopback reachability, and MP-iBGP to the other PE for VPNv4:

! IGP for the core (loopback reachability)
router ospf 1
 router-id 10.255.0.1
 network 0.0.0.0 255.255.255.255 area 0
!
! Core-facing interface: IP + IGP + LDP
interface Ethernet0/1
 ip address 10.30.30.1 255.255.255.252
 ip ospf 1 area 0
 mpls ip
!
! Customer VRF definition
vrf definition CUSTOMER
 rd 65000:1
 route-target export 65000:1
 route-target import 65000:1
 address-family ipv4
 exit-address-family
!
! Customer-facing interface lives in the VRF
interface Ethernet0/0
 vrf forwarding CUSTOMER
 ip address 10.40.10.1 255.255.255.252
!
! MP-iBGP to PE2 for VPNv4 routes
router bgp 65000
 bgp router-id 10.255.0.1
 no bgp default ipv4-unicast
 neighbor 10.255.0.2 remote-as 65000
 neighbor 10.255.0.2 update-source Loopback0
 !
 address-family vpnv4
  neighbor 10.255.0.2 activate
  neighbor 10.255.0.2 send-community both
 exit-address-family
 !
 address-family ipv4 vrf CUSTOMER
  redistribute connected
 exit-address-family

The no bgp default ipv4-unicast stops the BGP session from negotiating the regular IPv4 unicast address-family - we only want VPNv4 between the PEs. send-community both ensures the extended communities (the Route Targets) get propagated, which is how the receiving PE knows which VRFs to import the prefix into.

After OSPF, LDP, and MP-iBGP converge, the VRF shows the local interface and the matched RD:

PE1#show ip vrf
  Name                             Default RD            Interfaces
  CUSTOMER                         65000:1               Et0/0

PE1#show ip vrf detail CUSTOMER
VRF CUSTOMER (VRF Id = 1); default RD 65000:1
  Interfaces:
    Et0/0
Address family ipv4 unicast (Table ID = 0x1):
  Export VPN route-target communities
    RT:65000:1
  Import VPN route-target communities
    RT:65000:1
  VRF label allocation mode: per-prefix

The MP-iBGP VPNv4 session to PE2 is up and exchanging routes. One prefix received: the connected /30 PE2 redistributed from its own CUSTOMER VRF.

PE1#show ip bgp vpnv4 all summary
BGP router identifier 10.255.0.1, local AS number 65000
BGP table version is 4, main routing table version 4
2 network entries using 528 bytes of memory
2 path entries using 272 bytes of memory

Neighbor    V       AS  MsgRcvd MsgSent  TblVer  InQ OutQ Up/Down  State/PfxRcd
10.255.0.2  4    65000        5       4       4    0    0 00:01:37        1

The CUSTOMER routing table on PE1 now has the imported PE2 prefix, marked B for BGP-learned, with the next-hop being PE2's loopback (10.255.0.2). The next-hop is not the PE-CE link - it is the egress PE's loopback. MPLS resolves the egress PE loopback via the IGP and LDP, which is how the packet finds its way across the core.

PE1#show ip route vrf CUSTOMER

Routing Table: CUSTOMER
Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C        10.40.10.0/30 is directly connected, Ethernet0/0
L        10.40.10.1/32 is directly connected, Ethernet0/0
B        10.40.20.0/30 [200/0] via 10.255.0.2, 00:00:42

The BGP entry shows the VPN label PE2 advertised for that prefix. The local label is nolabel (PE1 is not the egress for this prefix); the out label is 19 - the label PE2 expects on packets arriving in the CUSTOMER VRF for 10.40.20.0/30:

PE1#show ip bgp vpnv4 vrf CUSTOMER 10.40.20.0/30
BGP routing table entry for 65000:1:10.40.20.0/30, version 4
Paths: (1 available, best #1, table CUSTOMER)
  Local
    10.255.0.2 (metric 21) (via default) from 10.255.0.2 (10.255.0.2)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:65000:1
      mpls labels in/out nolabel/19

The credibility moment: a traceroute from PE1 into the VRF surfaces both labels in the stack. Hop 1 (P) returns a TTL-exceeded that carries the original label stack as a header copy, so the labels show up in plain text in the IOS traceroute output:

PE1#traceroute vrf CUSTOMER 10.40.20.2
Type escape sequence to abort.
Tracing the route to 10.40.20.2
VRF info: (vrf in name/id, vrf out name/id)
  1 10.30.30.2 [MPLS: Labels 17/19 Exp 0] 2 msec 2 msec 2 msec
  2 10.40.20.1 2 msec 3 msec 2 msec
  3 10.40.20.2 4 msec *  4 msec

Hop 1 is P. The packet arrived at P with the label stack 17/19: outer label 17 is what P expects on packets bound for PE2's loopback (the transport label, learned via LDP); inner label 19 is what PE2 expects on packets for 10.40.20.0/30 in the CUSTOMER VRF (the VPN label, learned via MP-iBGP). Exp 0 is the EXP/Traffic Class bits, zero because we did not mark anything. Hop 2 is PE2 inside the VRF; PE2 popped both labels and forwarded native IP into the customer-facing interface. Hop 3 is CE2.

From the customer's side, a CE1 traceroute to CE2's interface address sees the same label stack. The MPLS layer is not hidden from the customer - on this Cisco platform, by default, the egress PE writes the label stack into the ICMP TTL-exceeded reply, and the customer sees the carrier's labels:

CE1#traceroute 10.40.20.2
  1 10.40.10.1 2 msec 2 msec 1 msec
  2 10.30.30.2 [MPLS: Labels 17/19 Exp 0] 4 msec 3 msec 3 msec
  3 10.40.20.1 3 msec 3 msec 3 msec
  4 10.40.20.2 4 msec *  6 msec

To hide the labels from the customer, carriers usually run no mpls ip propagate-ttl forwarded on the PEs, which makes the customer traceroute show the carrier as a single hop and the labels disappear from view. The PingLabz lab leaves the default in place so the labels are visible for teaching.

End-to-end reachability is the proof that the whole stack works:

CE1#ping 10.40.20.2 source 10.40.10.2 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.40.20.2, timeout is 2 seconds:
Packet sent with a source address of 10.40.10.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/3/5 ms

This is where the BGP cluster connects directly. MP-BGP carries VPNv4 routes via address-family vpnv4 unicast. Route distinguishers and route targets are MPLS-VPN concepts that live in BGP. See the MP-BGP article for the BGP side and MPLS L3VPN with MP-BGP for the MPLS side.

L2VPN: Carrying Layer 2 Over MPLS

L3VPN carries IP routes. L2VPN carries Layer 2 frames over the same MPLS backbone. Two main flavors:

EVPN is rapidly displacing VPLS for new deployments because of its control-plane MAC learning and active-active multihoming features. See the BGP cluster's MP-BGP article for EVPN context.

Traffic Engineering and Segment Routing

RSVP-TE was the original MPLS traffic engineering protocol. Operators would specify constraints (bandwidth, link metrics, explicit paths) and RSVP-TE would signal LSPs through the network meeting those constraints. It worked but the per-LSP state was operationally heavy.

Segment Routing (SR) is the modern direction. Instead of signaling LSPs, the source encodes the path as a list of segments (labels) in the packet itself. The MPLS data plane is unchanged - SR uses the same label format - but the control plane is dramatically simpler. No per-LSP state in the network; only segment-to-prefix mappings advertised by the IGP.

Modern service-provider deployments are migrating from LDP+RSVP-TE to SR-MPLS, with SRv6 being the longer-term direction for greenfield IPv6-only networks.

MPLS vs SD-WAN

The most common framing question for enterprise customers is whether to renew MPLS or migrate to SD-WAN. The honest answer in 2026 is hybrid - run SD-WAN over multiple transports including MPLS for hard-QoS-required flows. See the dedicated SD-WAN vs MPLS article for the cost analysis and migration patterns. The PingLabz position: SD-WAN is the routing layer, MPLS is one of the transports.

MPLS Deep Dives in This Cluster

1. MPLS Labels Explained: Format, Stacking, and Penultimate Hop Popping
2. LDP and MPLS Label Distribution
3. MPLS L3VPN with MP-BGP and VPNv4
4. Cisco MPLS Configuration on IOS XE
5. SD-WAN vs MPLS: When Each Wins in 2026

Frequently Asked Questions

What does MPLS stand for?

MPLS stands for Multiprotocol Label Switching. The "multiprotocol" part means it can carry IPv4, IPv6, Ethernet frames, ATM cells, or any other Layer 3 protocol. The "label switching" part means it forwards based on labels rather than IP destination addresses.

What OSI layer is MPLS?

Layer 2.5. It sits between Layer 2 (the data link, e.g. Ethernet) and Layer 3 (IP). The MPLS shim header inserts between the Ethernet header and the IP header. This is sometimes called the "shim layer."

What is the advantage of MPLS over plain IP?

Three big ones: faster forwarding via fixed-length label lookup (mattered more in the 1990s than today), traffic engineering via explicit paths, and VPN services (L3VPN, L2VPN) over a shared backbone. The forwarding speed advantage is largely gone; the VPN and TE capabilities are why MPLS is still dominant in service-provider networks.

What is the difference between MPLS and MPLS L3VPN?

MPLS is the underlying label-switching protocol. MPLS L3VPN is a service built on top of MPLS that uses MP-BGP to distribute customer routes (in VPNv4 format) across the MPLS backbone, allowing many customers' overlapping IP address spaces to coexist on one provider network. When enterprises buy "MPLS" from a carrier, they almost always buy MPLS L3VPN.

Is SD-WAN replacing MPLS?

Partially. SD-WAN replaces MPLS as the enterprise WAN routing layer, but still uses MPLS as one of the transports for hard-QoS-required flows. Most 2026 enterprise deployments are hybrid: SD-WAN over a mix of MPLS, broadband, and LTE. Pure SD-WAN-internet-only is common at smaller branches.

What is segment routing and is it replacing MPLS?

Segment Routing is a modern source-routing approach where the source router specifies the path as a list of segments (labels). SR-MPLS uses the existing MPLS data plane with a simpler control plane. SRv6 uses IPv6 instead of MPLS. SR is replacing LDP and RSVP-TE in many service-provider networks; SRv6 may eventually replace MPLS itself, but that is a long migration.

Key Takeaways

MPLS is the protocol that runs the inside of every major service provider network and most of the BGP-VPN services enterprises buy. Labels (32 bits, stackable), LDP (label distribution), and MP-BGP (for VPN routes) together make L3VPN possible. Segment Routing is the modern direction; LDP and RSVP-TE are gradually being phased out in service-provider networks.

If you take one thing away from this guide, make it the two-label stack model for L3VPN: outer transport label gets the packet across the MPLS core, inner VPN label tells the egress PE which customer VRF to deliver to. Master that and the rest of MPLS-VPN follows. Bookmark this page, work through the cluster articles in order, and lab every concept.