MPLS

Overview

MPLS (Multiprotocol Label Switching) is a forwarding technology used inside service provider networks. Rather than making a full IP routing decision at every hop, the provider adds a short label to the packet at the edge of its network. Within the MPLS core, routers normally forward packets based on that label rather than performing a customer-IP routing lookup.

That is the technology. When enterprises say “MPLS”, they almost always mean a service built on it: MPLS L3VPN, a carrier-delivered private WAN. The provider connects each of your sites to its backbone, keeps your traffic in its own virtual network, logically separate from other customers, and sells you bandwidth with SLAs and quality-of-service classes. On this page, “MPLS” means the L3VPN service unless stated otherwise.

The one-line version: MPLS gives you a private, carrier-managed network between sites, with predictable performance where the carrier commits to it. It does not get you to the internet or the cloud by itself.

Private ≠ encrypted. MPLS keeps your traffic logically separate from other customers and off the public internet. MPLS itself does not encrypt it. You are relying on the carrier’s network and configuration for that separation, so treat MPLS as private transport, not as a security control. Where confidentiality matters, add encryption such as IPsec on top.

MPLS dominated enterprise WANs from the early 2000s because it was one of the best ways to get any-to-any connectivity with contractual performance commitments for voice and business-critical applications. It is still widely deployed. Today most organisations are keeping it for some sites, replacing it at others, or running it alongside SD-WAN over broadband.

Where it fits

MPLS is an underlay connectivity service. It provides private connectivity between sites and can provide predictable performance and carrier-managed QoS. Technologies such as SD-WAN can run over MPLS, broadband, DIA, or other transports.

MPLS is one of the transports the overlay runs on, not the overlay itself. Security services sit above both, working on whatever the overlay delivers.

• What it provides: private connectivity between sites (and to data centres) across the carrier’s backbone and, depending on the contract, predictable performance and carrier-managed QoS.
• What it is not: an overlay like SD-WAN, or a security control. Encryption, inspection and access to the internet and cloud are separate decisions.
• What runs over it: SD-WAN, for example, can run over MPLS, broadband, DIA or other transports, often several at once. The overlay decides how traffic is steered, and MPLS is one of the transports it can use.

Why MPLS still matters

Every year someone declares MPLS dead, and every year enterprises renew their contracts. Some of that is inertia and some of it is risk aversion. But a good part of it is a sound engineering and business decision. The useful skill is telling the two apart.

Guaranteed performance you can put in a contract

The public internet is best effort. Providers do not typically commit to latency, jitter or loss for a path that crosses several networks, and when it degrades there is often nobody clearly accountable. An MPLS carrier can commit to latency, jitter and packet loss per traffic class across its backbone, with credits when it misses.

SD-WAN narrows this gap a lot by steering traffic across several internet links and away from bad paths. But it can only choose between paths that exist. It cannot create priority on a congested ISP link or at a peering point it does not control. For voice, video and contact-centre traffic, where two per cent loss ruins a call, a contractual guarantee is worth something.

The honest caveat: plenty of voice and video now runs well over good broadband with SD-WAN. The guarantee earns its price where degraded performance is expensive and good alternatives are few.

Predictability, not just speed

A stable path matters more than a fast one for some workloads. MPLS typically gives you a consistent route and similar latency at 3 a.m. and at 3 p.m. Chatty legacy applications, terminal and thin-client sessions, synchronous database replication and older ERP systems tend to break when latency varies, even if the average is fine.

It also makes life simpler for the people running it. Capacity planning is easier, and troubleshooting means one provider and one path instead of a chain of ISPs. Predictable is not the same as fast, though. An MPLS path that hauls cloud traffic through a distant data centre is predictably slow.

Private network characteristics

Traffic on an MPLS L3VPN normally stays inside the carrier’s private backbone instead of crossing the public internet. This means the MPLS L3VPN is not normally directly reachable by arbitrary internet hosts, which reduces direct internet exposure to the WAN path. It does not make the network immune to DDoS or other attacks: the access circuit and carrier infrastructure can still be disrupted, and sites with their own internet connectivity remain exposed there.

Some organisations, and some regulators and customers, also expect private connectivity for sensitive flows such as payments, health data, public-sector systems and critical infrastructure.

The caveat, as flagged in the overview, is that private is not encrypted. You are trusting the carrier, so what you gain is reduced exposure, not confidentiality. Many organisations still add encryption on top.

OT and manufacturing

Plants, warehouses, utilities and energy sites often have different priorities from the office network. Availability matters more than cost, and changes are rare and planned. Devices can stay in service for 15 to 25 years and speak protocols that were never designed for the internet. Traffic such as supervisory control, MES synchronisation and vendor remote access is time-sensitive, and it is unforgiving when a link misbehaves.

MPLS suits that world for practical reasons:

• A carrier-managed last mile with an SLA gives OT teams someone to call and a clear owner for the fault.
• Separate VPNs or VRFs make it easy to keep OT and IT traffic apart at the WAN level.
• OT traffic is usually low bandwidth, so the price premium per site is modest compared to the cost of an outage.
• The real barrier to change is risk. Nobody wants to redesign a working plant network for a saving that shows up on a different budget line.

None of this removes the need for OT security controls on the plant side, and a private WAN does not protect a flat plant network. [REVIEW: add concrete OT examples from your own customers.]

Geographic reach and local conditions

Internet quality is very uneven. Cross-border internet paths can be slow or unstable, and in parts of Asia-Pacific, the Middle East, Africa and Latin America a private carrier backbone can be far more reliable than public transit. A global carrier also gives you one contract, one set of SLAs and one escalation path across many countries, where the alternative is stitching together local ISPs country by country.

Some countries also restrict how cross-border connectivity can be delivered. China is the best-known example, where cross-border links are expected to run over licensed operators, which can rule out a simple internet-based overlay. [REVIEW: confirm the current position and wording for China and any other regions you deal with.]

A private backbone also gives you more control over the path. If you need to know which countries your traffic crosses, that is much easier to answer for a carrier network than for the open internet. And reach cuts both ways: in countries where your carrier has no presence, a partner delivers the local access, and that is often where service levels get weaker.

Operations and risk

Some reasons are not technical, and they are still legitimate. A small IT team may prefer a carrier to run the WAN. A single accountable provider is simpler than a mix of ISPs and an overlay to manage. Multi-year contracts are already signed, and migrating hundreds of stores or plants carries real risk to revenue. “If it works, do not touch it” is a rational position for systems that carry cash or production.

When the case is weak

MPLS is a poor fit, and hard to justify, when:

• Most of a site’s traffic goes to SaaS and the public cloud, so it gets backhauled for no benefit.
• Reliable broadband or dedicated internet is available and the applications are tolerant of some variation.
• Bandwidth needs are growing faster than the budget.
• The business needs to open, move or close sites quickly.

A practical test

Before renewing or replacing MPLS at a site, ask three questions:

1. What breaks, and what does it cost, if this site has a bad hour?
2. Can a broadband and SD-WAN design meet that need, proven by a measured pilot rather than a promise?
3. Is anything forcing private or carrier-delivered connectivity, such as regulation, geography or OT constraints?

If the answer to the first is “a lot” and the third is “yes”, keep MPLS at that site. If not, it is probably a cost worth challenging. Most enterprises end up with a hybrid: MPLS where a guarantee matters, internet-based connectivity everywhere else.

How it works

The players

Every MPLS network has the same cast of characters:

Role	Full name	Where it sits	What it does
CE	Customer Edge	At your site	Your router (or the carrier-managed one). Speaks normal IP and routing protocols to the provider.
PE	Provider Edge	Edge of the carrier network	Faces the customer. Adds labels on the way in, removes or hands off on the way out. Also called an LER (Label Edge Router).
P	Provider (core)	Inside the carrier network	Only forwards by label. Knows nothing about customer networks. Also called an LSR (Label Switching Router).

Following one packet

The diagram shows a packet crossing the provider network from Site A to Site B.

One packet crossing an MPLS network. Amber = MPLS label, cyan = your IP packet. Simplified MPLS forwarding example: the customer IP packet remains unchanged while MPLS labels are added, swapped and removed.

1. Site A sends a normal IP packet to its CE, which forwards it to the provider.
2. PE1 (ingress) classifies the packet and adds an MPLS label, putting it onto the appropriate Label Switched Path (LSP).
3. P1 swaps the label. Core routers look up the incoming label in a small table, replace it with the outgoing label and forward. They normally do not perform a customer-IP routing lookup.
4. P2 performs penultimate-hop popping: the second-to-last router removes the MPLS label before the packet reaches PE2.
5. PE2 (egress) removes the MPLS information and forwards the plain IP packet toward the destination CE.

The label itself is a 32-bit header (often called the “shim”) inserted between layer 2 and layer 3, which is why MPLS is sometimes called “layer 2.5”:

Field	Size	Purpose
Label	20 bits	The value used for forwarding
Traffic Class (TC)	3 bits	Quality-of-service marking (formerly “EXP”)
Bottom of Stack (S)	1 bit	Set on the last label in a stack
TTL	8 bits	Loop protection, like IP TTL

How the labels get there

Labels are not configured by hand. The carrier’s routers learn them using a label distribution mechanism, typically LDP (Label Distribution Protocol), RSVP-TE (when traffic engineering is needed) or, in newer networks, Segment Routing. Which one your carrier uses is their business, but it decides what traffic engineering options they can offer.

How customers are kept separate (L3VPN)

The same provider network carries thousands of customers, and many of them use the same private address ranges such as 10.0.0.0/8. Separation works like this:

• Each customer gets its own VRF (Virtual Routing and Forwarding table) on the PE routers, essentially a private routing table per customer.
• PEs exchange customer routes with each other using MP-BGP, and tag them with a Route Distinguisher (to make overlapping addresses unique) and Route Targets (to control which sites can see which routes).
• Packets carry two labels: an outer transport label that gets the packet across the core, and an inner VPN label that tells the egress PE which customer VRF to deliver into.

You do not need to configure any of this as a customer. But it explains why the carrier controls your routing, why any-to-any connectivity is “free” and why a handoff to your own routers is done with BGP or static routes.

Quality of service

The carrier maps your traffic into a small number of classes of service (commonly three to six) using DSCP markings at the handoff, and honours them across the backbone via the TC bits. That is how voice and video can be protected from bulk transfers, and it is one of the main reasons MPLS was worth paying for.

Flavors & variants

“MPLS” on a quote can mean several different services. Always ask which one.

Variant	Layer	What you get	Typical use
L3VPN (RFC 4364)	3	Carrier routes between your sites. Any-to-any by default.	The standard enterprise MPLS WAN
VPLS	2	The provider network behaves like one big Ethernet switch across sites	Sites that need to share a Layer 2 domain. Older, declining
VPWS / E-Line	2	A point-to-point Ethernet pseudowire	Replacing a leased line, data centre interconnect
EVPN	2/3	Modern replacement for VPLS with better multi-homing	Newer carrier services
MPLS-TE	n/a	Explicit paths through the core with bandwidth reservation	Carrier-side feature, sometimes sold as premium routing
Segment Routing (SR-MPLS)	n/a	Simpler, newer way to build the label paths	Carrier-side technology, invisible to you

Other choices that change how it feels to operate:

• Managed vs unmanaged CE. With a managed service, the carrier owns and configures the router at your site. With unmanaged, they hand you a port and you run your own router. Managed is simpler to start with and harder to change later.
• Single carrier vs multi-carrier. One provider’s MPLS network only reaches where that provider has a presence. Global companies often stitch several carriers together through Inter-AS interconnects, or buy from a global carrier that in turn uses local partners. Each stitch is a place for slower fixes and finger-pointing.
• Access type. The MPLS service still needs a physical last-mile circuit: fibre, Ethernet, copper or occasionally cellular backup. The MPLS product and the access circuit may have different SLAs and even different owners.

Pros & considerations

What it does well

• Predictable performance. Latency, jitter and loss are typically managed inside one carrier backbone, with SLAs behind them.
• Carrier-managed QoS. Voice, video and business-critical applications can be prioritised across the carrier’s backbone in a way the public internet generally does not offer.
• Private by design. Traffic is logically isolated in your own VPN and normally stays off the public internet.
• Simple for the customer. Typically one handoff, one routing relationship, and any-to-any connectivity without building tunnels.
• Operationally mature. It has been running enterprise WANs for over twenty years, and most of its failure modes are well understood.

Trade-offs

• Cost per megabit. It is typically much more expensive than broadband or dedicated internet for the same bandwidth. [REVIEW: add a rough ratio from field experience]
• Long lead times. New sites and upgrades depend on carrier provisioning and last-mile installation, often measured in months rather than days. [REVIEW: typical ranges by region]
• Not encrypted. Private is not the same as secure. MPLS separates traffic logically but does not itself provide confidentiality or integrity. See the key distinction in the overview and the security considerations below.
• Not built for cloud and SaaS. It connects sites to sites (and to data centres). Traffic to Microsoft 365, Salesforce or a public cloud has to be hauled back to a central internet breakout, or connected some other way.
• Reach and lock-in. You can only connect where your carrier can reach, and switching carriers usually means re-doing every site.
• Carrier controls the routing. Changes go through a ticket, not a config commit.

Common pitfalls

“It’s private, so it’s secure.” This is the big one. Traffic on an MPLS VPN is isolated, not encrypted. A carrier misconfiguration, a compromised PE or a wrongly imported Route Target can expose one customer’s routes to another. Many organisations still run IPsec over their MPLS for exactly this reason, and every site still needs its own firewall.

QoS that stops working at the edge. Class-of-service only works if markings are right at the handoff. Common failures: the carrier’s classes do not match the customer’s DSCP plan, traffic gets re-marked to best effort, or there is no QoS on the LAN or on the access circuit, so the priority queue exists in the core but not where the congestion is.

BGP handoff surprises. When several sites use the same AS number, routes can be rejected because of AS-path loop prevention, which needs as-override or allowas-in to fix. Route limits, default-route behaviour and asymmetric routing between two links are other regulars.

MTU and fragmentation. Every label adds 4 bytes and a double-labelled VPN packet adds 8. If you also run IPsec or tunnels over the top, the MTU shrinks again. Broken applications with “it works for small pages but hangs on large ones” are a classic sign.

SLA fine print. The SLA usually covers the carrier’s backbone, not your whole path. Last-mile circuits and off-net sites (where a partner carrier delivers the local access) often carry weaker commitments, and credits are rarely worth the outage.

Overlapping and undocumented address space. Carrier VRFs will happily carry overlapping ranges, and then a merger or a cloud connection makes them collide.

Not knowing what you have. Circuit inventories are often out of date: forgotten sites, unused ports still billing, and contract renewal dates nobody is tracking.

What companies struggle with

These are the conversations that come up again and again.

• “We’re paying more every year and getting less.” Bandwidth needs grow faster than MPLS budgets. Video calls, SaaS and cloud backups push sites past what they can afford to upgrade.
• Cloud and SaaS traffic taking the scenic route. Branch traffic goes across MPLS to a data centre, out through a central firewall and back again, adding latency to exactly the applications users complain about most. See the diagram below.
• Slow rollout of new sites. A new shop, plant or pop-up site waits weeks or months for a circuit. The business does not accept that timeline any more.
• Contract lock-in. Multi-year terms, per-site pricing and co-terminating renewals make it hard to move even when the technology case is clear.
• Migration risk. Nobody wants to cut over 200 sites at once. The realistic path is a hybrid period with MPLS and internet-based SD-WAN side by side, which brings its own routing and policy complexity.
• Loss of visibility. With a managed service, the customer often cannot see per-application performance or troubleshoot without opening a ticket.
• Security ownership gaps. Many MPLS-only networks depend on a small number of central internet breakouts for security. When traffic moves to local breakout or SASE, the security model has to be redesigned, not just the network.

Multiply it by every branch: each one backhauls its internet and SaaS traffic to HQ before it can reach Microsoft 365, Salesforce or anything else out there.

Use cases & stories

Unreliable local internet at a manufacturing site

A manufacturer with a production facility in the Dominican Republic found local internet and ISP connectivity too unreliable to support the plant’s operations. MPLS was the right fit: the carrier-managed backbone provided a stable, predictable path where local broadband and internet alternatives were simply not dependable enough. The customer extended the same approach to other facilities where local connectivity quality was a concern, using MPLS specifically at the sites where it solved a genuine reliability problem rather than applying it everywhere by default.

Payment traffic requiring guaranteed reliability

A financial services customer needed their payment processing traffic to run over a network they could fully trust for reliability and protection. Given the sensitivity and criticality of financial transaction data, they chose to route this traffic over MPLS specifically, valuing the private, carrier-managed characteristics and the predictability that comes with it, rather than relying on internet-based alternatives for that particular workload.

The hybrid migration

[REVIEW: replace this story with a real customer example.]

A company with 150 sites moves to SD-WAN. MPLS is kept on the 20 most critical sites and at the data centres, and the rest move to dual broadband. For a year, both networks run together, with BGP redistribution between them. The lesson: the hard part of leaving MPLS is rarely the technology. It is the routing between old and new, the contract end dates and the order in which sites move.

Selective MPLS retention alongside other transports

A customer chose to keep MPLS in place only where it added genuine value, while introducing DIA and broadband at locations where reliability requirements were less critical and appetite to move away from MPLS was higher. SD-WAN made it straightforward to manage both transport types in parallel across the network. Once the customer had confidence that DIA or broadband performed comparably to MPLS at those sites, they had a real choice: transition away from MPLS entirely at that location, or simply leave it in place if there was no pressing reason to change. The key takeaway: MPLS does not have to be all-or-nothing. It can be scoped to exactly the sites where its cost and provider-backed SLA genuinely earn their keep, running alongside other transports elsewhere.

Security & compliance considerations

Most security questions about MPLS come down to what it provides and what it leaves to you. This section is not a compliance guide: what a specific framework or regulation requires depends on its version, your scope and your assessor. [REVIEW: check all points below against your field experience.]

• What MPLS provides. Logical separation of your traffic from other customers, per-customer routing separation on the carrier’s edge routers (VRFs), and normally a path that stays off the public internet. That reduces exposure, which is a real but limited security property.
• What it does not provide. Confidentiality, integrity protection or authentication of traffic in transit, traffic inspection or threat prevention, and access control between your own sites. With any-to-any connectivity, a compromised site can potentially reach others unless you segment.
• Encryption status. MPLS itself does not encrypt traffic. Some carriers offer encryption as an optional managed add-on, and many customers run IPsec over MPLS themselves. Some frameworks and regulations set expectations for protecting data in transit, for example PCI DSS and GDPR. Whether an unencrypted private carrier network is acceptable depends on the data, your risk assessment and your assessor, so “it’s private” should not be treated as the answer on its own.
• Segmentation. Separate VRFs or separate MPLS services can keep traffic classes apart at the WAN level. Ask how the carrier enforces and evidences that separation, and remember that segmentation inside each site is still your job.
• Carrier and provider risks. The carrier runs the network that carries your traffic and controls your routing. Misconfiguration, compromised provider equipment or a wrongly imported Route Target can weaken isolation. Treat the carrier as a critical supplier: many frameworks and sector rules, such as ISO 27001, SOC 2, DORA and NIS2, ask organisations to manage supplier risk, so look for security commitments in the contract, incident notification terms and an exit plan.
• Data location. Traffic stays within the provider’s backbone, but that backbone can cross borders. If data-sovereignty or residency questions apply, ask the carrier which countries the traffic transits and where its equipment sits, not just where the endpoints are.
• Visibility and logging. With a managed service, check that you can get flow data and change history from the carrier, since you will likely be asked to show monitoring and logs.

Related topics

• Underlay Design: start here before choosing a connectivity technology — design drivers, site classification and the comparison table this page feeds into.
• Broadband / DIA: the usual partner or replacement (coming soon)
• SD-WAN concepts: the overlay that runs over MPLS and internet (coming soon)
• Underlay vs overlay: where MPLS fits in the model (coming soon)