LogoفارسیFA

MPLS Fundamentals: Label Switching Explained

Traditional IP routing requires every router along a path to perform a full routing table lookup on every packet, but MPLS takes a fundamentally different approach by making that forwarding decision once and attaching a simple label that every subsequent router can use instead. This article explains the core label-switching concept, walks through how the Label Distribution Protocol builds the label forwarding tables that make this possible, and covers the practical benefits MPLS provides in real provider networks.

MPLS Label SwitchingLDPLabel Switch Router

~6 min read · Updated Sep 12, 2026

Why Traditional IP Forwarding Has Limitations at Provider Scale

The CEF-based forwarding discussed earlier in this series makes IP forwarding decisions extremely efficient by precomputing the FIB and adjacency table, but every router along a packet's path still independently performs its own longest-prefix-match lookup, discussed earlier in this series regarding routing fundamentals, based purely on the destination IP address. In large service provider networks carrying immense traffic volumes, and needing fine-grained traffic engineering control over exactly which physical path traffic takes, this per-hop independent lookup model has real limitations.

The Core MPLS Idea: Label Once, Switch Repeatedly

MPLS (Multiprotocol Label Switching) changes this model fundamentally: rather than every router along the path making an independent forwarding decision based on the IP header, a short, fixed-length Label is attached to each packet at the network's ingress, and every subsequent router forwards the packet using this simple label rather than re-examining the IP header at all.

MPLS label structure (a 32-bit field inserted
between the Layer 2 header and the IP header,
discussed earlier in this series regarding
encapsulation):

Label: 20 bits (the actual label value, 0-1,048,575)
EXP:   3 bits (used for QoS marking, similar
       in purpose to the DSCP marking discussed
       earlier in this series)
S:     1 bit (indicates the bottom of the label
       stack, since multiple labels can be stacked)
TTL:   8 bits (functions like the IP TTL field,
       preventing infinite loops)

MPLS Router Roles

Label Edge Router (LER): sits at the boundary of
  the MPLS network, performing the initial IP
  lookup and attaching (or removing) labels --
  this is the only point where a full traditional
  IP routing table lookup, discussed earlier in
  this series, actually happens

Label Switch Router (LSR): sits within the core
  of the MPLS network, making forwarding
  decisions based purely on the label value,
  without ever examining the underlying IP
  header at all

This division of labor is the source of MPLS's core efficiency benefit: the computationally simpler label lookup replaces the more complex IP lookup for every router except the ones at the network's edge, where that complexity genuinely cannot be avoided.

How Labels Get Assigned: LDP

LDP (Label Distribution Protocol) is how neighboring MPLS routers automatically agree on which label value represents which destination network, building the Label Forwarding Information Base (LFIB) that LSRs use to make their simple, label-based forwarding decisions.

Router(config)# mpls ip

Router(config)# interface gigabitethernet 0/0
Router(config-if)# mpls ip

-- Enabling MPLS on an interface automatically
-- triggers LDP to begin discovering neighbors
-- and exchanging label bindings for routes
-- already known via the underlying IGP
-- (OSPF or EIGRP, discussed earlier in this
-- series), since MPLS relies entirely on the
-- existing IP routing table to determine
-- reachability -- it does not replace IP
-- routing, only the forwarding mechanism

Label Distribution: Downstream Unsolicited Advertisement

How a label binding actually gets created:

1. Router B has a route to network 192.168.1.0/24
   in its IP routing table (learned via OSPF,
   for example)
2. Router B assigns a local label (e.g., 100)
   for this destination
3. Router B advertises this binding to its LDP
   neighbor, Router A: "use label 100 when
   sending traffic to 192.168.1.0/24 through me"
4. Router A records this in its own LFIB,
   and will attach label 100 to any traffic
   destined for that network before forwarding
   it to Router B

This "downstream" labeling convention -- the router closer to the destination assigns and advertises the label -- allows each router along the path to build up a simple table mapping incoming labels to outgoing labels and interfaces, without needing any awareness of the full end-to-end path.

Following a Labeled Packet Through the Network

Router# show mpls forwarding-table

Local  Outgoing   Prefix           Outgoing   Next Hop
Label  Label      or Tunnel Id     interface
100    102        192.168.1.0/24   Gi0/1      10.0.0.2

-- This shows label swapping in action: a packet
-- arriving with local label 100 gets its label
-- SWAPPED to 102 before being forwarded out
-- GigabitEthernet0/1 toward 10.0.0.2 -- each
-- LSR along the path performs this same simple
-- swap operation, never re-examining the
-- original IP header at all

This label-swapping mechanism, rather than a full IP lookup at each hop, is computationally simpler and was historically significantly faster in hardware, though modern CEF-based IP forwarding, discussed earlier in this series, has largely closed this specific raw-speed gap -- MPLS's more enduring practical value today lies elsewhere.

Where MPLS's Real Value Lies Today

Traffic Engineering: MPLS labels can represent
  a specific, explicitly engineered path through
  the network rather than simply the shortest
  IGP path, allowing traffic to be steered along
  a deliberately chosen route for load-balancing
  or avoiding specific links

VPN Services: MPLS is the foundation for
  provider-based Layer 3 VPN services, allowing
  a single service provider network to carry
  traffic for many separate customers while
  keeping each customer's routing information
  and traffic completely isolated from every
  other customer, using additional labels to
  distinguish between customer VPNs

This VPN application is arguably MPLS's most significant real-world use case: enterprise customers purchasing an "MPLS VPN" service from a provider are relying on exactly this label-based isolation mechanism to keep their traffic securely separated from every other customer sharing that same provider's physical infrastructure.

Why Understanding MPLS Matters for Enterprise Networking

While MPLS core internals are primarily configured and managed by service providers rather than enterprise network administrators directly, understanding how it works underneath is essential for anyone purchasing, troubleshooting, or designing around MPLS-based WAN connectivity, discussed earlier in this series regarding traditional WAN design and its SD-WAN alternative. Recognizing that an "MPLS circuit" represents a labeled, engineered path through a provider's network -- rather than simply a generic point-to-point connection -- clarifies why MPLS services carry specific guarantees and limitations that a simple internet connection does not.

Written & researched by Dr. Shahin Siami

Related Articles

Systematic Network Troubleshooting: A Methodology Tying Everything Together

Every protocol and technology covered throughout this series is only useful if a problem involving it can actually be diagnosed and fixed efficiently under real-world pressure. This article presents a systematic troubleshooting methodology built around the OSI layers, walks through applying it to a realistic connectivity problem, and shows how the specific verification commands covered throughout this entire series fit into a structured diagnostic process.

Continue

NETCONF, YANG, and Python: Programmatic Network Configuration at Scale

The REST APIs and JSON/YAML formats covered earlier in this series represent one approach to network automation, but NETCONF and YANG provide a more structured, standards-based alternative purpose-built for network device configuration. This article explains what distinguishes NETCONF from a simple REST API, covers how YANG models define exactly what configuration data looks like, and walks through using Python to programmatically interact with network devices.

Continue

IPsec VPN Fundamentals: Securing Traffic Across Untrusted Networks

Connecting two sites across the public internet exposes traffic to interception unless it is properly encrypted, and IPsec provides the standard framework for building secure, authenticated tunnels between sites. This article explains the two-phase IKE negotiation process, covers the distinction between AH and ESP protocols, walks through configuring a basic site-to-site IPsec VPN, and covers essential verification commands.

Continue

BGP Route Reflectors and Confederations: Scaling iBGP Beyond Full Mesh

The iBGP full-mesh requirement, briefly mentioned earlier in this series, becomes a serious scaling problem as an autonomous system grows, requiring a number of sessions that increases quadratically with router count. This article explains exactly why full mesh does not scale, walks through how route reflectors solve this by relaxing BGP's normal route-propagation rules, and covers confederations as an alternative approach that divides a single AS into smaller sub-autonomous systems.

Continue

OSPF Area Types Deep Dive: Stub, Totally Stubby, and NSSA

Multi-area OSPF, covered earlier in this series, already reduces database size by separating a network into areas, but OSPF offers further specialized area types that reduce routing table size even more aggressively by filtering out unnecessary external routes entirely. This article explains the LSA types that must be suppressed to create each specialized area type, walks through configuring stub, totally stubby, and not-so-stubby areas, and covers the specific trade-offs each design choice involves.

Continue

BGP Path Manipulation: Route Maps and Communities for Traffic Engineering

The basic BGP path selection process, covered earlier in this series, follows a fixed order of attributes, but real networks need to actively influence which path gets chosen rather than passively accepting the default outcome. This article explains how route maps filter and modify BGP routing information, covers Local Preference and MED as the two primary levers for influencing path selection, and introduces BGP communities as a flexible tagging mechanism for coordinating policy across an entire network.

Continue
Previous ArticleNext Article