You’re Probably Using The Term MPLS Wrong

It sure can be confusing when a word has multiple meanings. You know: like the time I sat on the person in charge of the local Artichoke-Pickling Society, because someone told me they were the meeting’s “chair”. How was I to know?

It didn’t help that for some reason they were wearing a t-shirt that was decorated with a load of pictures of chairs. Frankly they brought that problem on themselves.

It got worse: it turns out that it wasn’t a club dedicated to the pastime of pickling artichokes, but was instead a society dedicated to honouring people with the surname Artichoke-Pickling. That might seem like a niche idea, but there are actually a lot of famous people with that surname, such as the celebrity quantity surveyor Susan Artichoke-Pickling, and the heart-throb accountant Barry Artichoke-Pickling. What? You’ve never heard of them? Not my problem mate. Maybe it’s time you started educating yourself. Maybe read a book sometime, yeah?

Anyway, forget literally everything I just said, because we’re here today to talk about MPLS.

I’ve written a billion blogs about MPLS in the past, whether it be an introduction to how it works, or an introduction to segment routing for MPLS, or an introduction to RSVP, or an explanation of RSVP bandwidth reservations, or RSVP auto-bandwidth, and so many more besides.

There is one thing I’ve yet to touch on though, which is that a great deal of network engineers – the vast majority, in fact – are not quite using the word MPLS correctly. And I know this, because once upon a time I did exactly the same thing myself.

Let me tell you the mistake I made, the mistake you’re probably making right now, and how to spot when people are making it in the future. This is a fairly long post, but I think you’ll be happy with the stuff you learn along the way. Grab a coffee and get ready for some cool new knowledge – and all for free!

 

MY FAILED MPLS INTERVIEW

About 13 years ago I was working in 2nd line support at an ISP. I spent my days supporting customers who had something that everyone around me called an “MPLS circuit”. I didn’t really know what that meant, but I knew that I spent my days repairing these circuits. So, I applied for jobs that involved MPLS.

I remember the first interview I had. Very first question: “tell me how to use MPLS to create a BGP-free core”.

Um. What?

I had no idea what the dude was talking about. He then asked me something about traffic engineering, about something called RSVP… and it’s fair to say that I left that interview confused, and with my mind blown. I’d completely misunderstood what “MPLS” means!

It turns out that when people talk about “buying an MPLS circuit”, they are actually using the term MPLS to refer to one very specific use-case of MPLS – whereas in fact, MPLS is the name of a much broader technology with a wide-ranging list of dozens of use cases. You can imagine the terrible confusion this causes, let alone the danger for poor design and purchasing decisions based on huge misunderstandings.

Based on my own experience over the years, there is an exceedingly high chance that you, through no fault of your own, are also currently making this mistake. To be clear, the mistake isn’t to use the phrase MPLS to mean “MPLS circuits”. The mistake is to then go on to hear conversations about the broader meaning of MPLS, and assume that those conversations are referring to the specific meaning instead.

Don’t worry though: your goth uncle is here to clear up the confusion, and to help you become a better network engineer in the process.

 

THE HEART OF THE CONFUSION

MPLS in its truest sense is the technology that powers pretty much every internet service provider in the world. MPLS in the truest is not going anywhere any time soon, and in fact it gets better every year. In a moment I will teach you exactly why this is.

And yet, when I write blog posts teaching people MPLS, inevitably people will comment to say that “SD-WAN will replace MPLS”. In fact, these people don’t mean MPLS – they mean MPLS VPNs, and Layer 3 MPLS VPNs in particular. Again, by the end of this post you’ll know exactly what this means, and the difference between the two.

In any case though, can you see what’s happened here? They’ve committed what is known as the “fallacy of equivocation” – where someone uses one meaning of a word in the premise, but another in the conclusion.

“The sign said ‘Fine for parking’, so I parked there because the sign said it was fine”.

It will be clear to anyone who works in science and technology how using language imprecisely can have disastrous consequences. As nerds, we correctly put a great deal of effort into clarity when we describe things.

And yet, I know people who wanted to get into the service provider space who have avoided learning about “MPLS” specifically because they’d heard it was a technology that was being replaced with SD-WAN. Unfortunately, they were using the specific VPN meaning of MPLS, and in doing so they missed out on a chance to attend a free course that taught the technology behind the actual, broader meaning of MPLS.

I think that’s a great shame. I feel like the wider networking world has done those people a disservice through this needless confusion.

 

OKAY THEN MR HANDSOME: WHAT DOES MPLS MEAN?

Wow, thank u for calling me handsome. Wow that’s really nice. Thank u very much.

The answer to this question is long, and it’s exactly why I wrote this post giving you a genuine introduction to MPLS. I bet you’d love that post. Open it up in a new tab, and read it after this one. Pretty good advice if you ask me.

For now though, let’s avoid packet captures, and just give the high level overview.

MPLS is a way of massively expanding and improving the ways that a service provider can transport traffic across their network.

You will know already that routers forward packets based on the destination IP address. By default, 100% of all traffic to a particular destination will take the same “best” path through the network.

In a “small” enterprise network, this is all you need. However, Internet service providers are a very different beast.

First, their routers need to be aware of the full internet routing table. At the time of writing this (27th March 2022), the public internet has 916,536 prefixes in it! That’s a lot of prefixes (which by the way, is another word for IP ranges) for every single router in the network to have to learn, to store in their routing tables, to install into the hardware forwarding tables, and to process as things in the internet change (which happens constantly!).

Second, there’s a great chance that a service provider won’t want all traffic to take the metrically best path within their network. In a moment I’ll give you a list of reasons why this is. In any case, how can you forward traffic down a path other than the metrically best one?

Well, what you could do is get two routers at either side of your network to signal some kind of tunnel that takes a very precise path through your network – either a precise path of your own choosing, or a path calculated by your router, based on any constraint you can think of.

What does “sending traffic through a tunnel” involve? There are a few potential answers to that, but one involves adding a kind of tag onto the packet, a tag that tells the next-hop router exactly what tunnel the packet belongs to, and therefore what interface to forward the packet out of. The good thing about such tags is that the receiving router doesn’t even need to look at the destination IP address, because the tag is all that is needed to forward the packet.

For example, in the diagram below you can see ten routers, with two tunnels between R1 and R5. The blue tunnel takes the shortest path, and can be dedicated to your most important traffic. The red tunnel takes a longer path, and can be used by best-effort traffic that you don’t want getting in the way of your most important traffic.

True, you could do something similar with policy-based routing, but that very quickly becomes problematic in a network that uses the entire Internet routing table, not to mention the rules that need to be programed into the hardware forwarding tables of every single box. You’d run out of forwarding space very quickly indeed.

That’s where MPLS comes in.

It stands for Multi-Protocol Label Switching. “Label Switching” refers to the fact that a label is added onto the packet, so that transit routers can forward based on the label. “Multi-Protocol” refers to the fact that you can tunnel anything. IPv4, IPv6, Ethernet, and more. Even drugs and fresh fruit, depending on what your particular crime cartel specializes in.

 

WHY WOULD YOU WANT THESE TUNNELS?

Mate, there are so many reasons! Here is just a small list of the potential use-cases for these MPLS “tunnels”. You could:

– Run routers in the core (like routers 2, 3, 4, 7, 8, and 9 in that picture) that don’t need to host the full internet routing table, and instead just look at the label to forward the packet. This is known as a “BGP-free core”, and it’s a HUGE use-case of MPLS for ISPs.

– Create high priority tunnels that take the best paths, create lower priority tunnels that take a longer way to the destination, and then map certain traffic to those tunnels so that high and low priority traffic can be kept separate. This might sound like policy-based routing, but in practice it’s all done with BGP communities and routing policies, so it’s much more light-weight. The forwarding table still only inspects the destination IP, but the next-hop is just something other than the “best” path.

– Create tunnels that can dynamically change their path when they detect congestion problems in the network.

– Create tunnels that have the ability to automatically move low priority tunnels onto a different path, so the important tunnels get access to the best resources.

– Tag links that a tunnel should avoid, or that should only be used, and then create tunnels that use those tags when calculating their path.

– Tunnel IPv6 traffic over an IPv4 core.

– Run multicast tunnels in your core, for example if you provide IPTV to your customers. Instead of running a multicast protocol in your core, you can simply create point-to-multipoint tunnels through your core, and keep the multicast signaling at the edge of your network.

– Tunnel layer 3 or layer 2 customer VPN traffic across a core network. (Remember this one in particular, because this bad boy right here is where all of the confusion lies.)

– Give a large service provider the ability to join two locations of a smaller service provider together, so that the two sites appear as one, with the larger “carrier of carriers” service provider acting as an invisible tunnel between the two.

– Give a wholesale service provider the ability to take frames from a customer sites, and transport then up to another IP service provider. The wholesaler takes care of the physical WAN, while the IP provider takes care of the routing.

And that’s not even the end of the list. As you can see, MPLS has dozens of essential use cases in a modern service provider network, and is very much one of the protocols that powers the internet.

 

LABEL-SWITCHED PATHS

Another name for these so-called “tunnels” is a label-switched path, and there are a number of protocols that can create them.

One such protocol is LDP, which stands for the Label Distribution Protocol. LDP just creates tunnels that follow the metrically best path, but you can still do things like IPv6 tunneling, customer VPN tunneling, and running BGP-free cores.

Another protocol is RSVP, which stands for the Resource Reservation Protocol. This protocol is famous for its traffic engineering capabilities, and can do everything in the long list above, and more.

A newer method is called segment routing, and SR-MPLS in particular, and this also offers a great number of the features above.

If you’re interested in knowing how these protocols work, then you know already that I’ve written loads of posts to help you on your journey. For now though, I want you to understand this before you move on:

“MPLS is the name of the protocol that lets you add labels onto packet, in order to forward the packet based on that label. MPLS has a massive list of use cases for internet service providers. MPLS, combined with BGP, are the two protocols that power the entire internet. For that reason, MPLS is going to be around for a very long time. Networking always changes, and no-one knows what the future will bring, but it would not surprise me at all if an 18-year-old who starts working in the service provider sector today will still be using MPLS when they retire. That’s how important MPLS is to the modern internet.”

Now that you know the main, broad meaning of MPLS,  let’s look at the alternative, more specific meaning of the word.

 

WHAT DO PEOPLE THINK MPLS MEANS?

One of the use cases I mentioned for MPLS is “to tunnel customer VPN traffic across a core network”. What does that mean?

Imagine a customer that has dozens of sites around the country. Each site has at least one private IP range on their LAN, and each site needs connectivity to various LANs at other sites. This connectivity could be full-mesh with each site having access to every other site, or it could just be between a few select sites, or just to a head-office hub-and-spoke style, or perhaps just to some kind of breakout firewall so that all traffic can be tracked.

Considering that the service provider running MPLS only looks at the labels on a packet, and not the IP itself, this gives service providers the ability to use MPLS to offer VPN services to such a customer. Customer traffic can be tagged with a unique MPLS VPN label, and then tunneled across a label-switched path. The receiving service provider router, at the other end of the tunnel, maps that VPN label to a particular customer, and in doing so keeps that customer’s traffic logically separate from any other customer – even customers who are using exactly the same private IPs.

Broadly speaking, there are two “genres” of MPLS VPN.

A “layer 3 VPN” (sometimes called L3VPN, sometimes called IPVPN, and sometimes called VPNv4) is where the service provider learns the LAN ranges at each sites, and advertises them around its own network, tagging them as belonging to that customer’s specific VPN. The service provider probably talks BGP with the customer, but it could be OSPF, or it might simply use static routes. In any case though, the service provider’s edge routers each have a layer 3 routing table for this customer’s VPN.

A “layer 2 VPN” is where the service provider does not learn layer 3 IP ranges, and instead can do one of two things.

– First, they can act as a virtual wire to connect two sites together, such that frames entering at one end of the network are tunneled to the other end. The service provider doesn’t need to learn MAC addresses here, because all traffic that comes in at one end is spat out at the other end. If you’ve ever heard the phrase “pseudowire”, then you now know what it refers to.

– The other option is to act as a virtual switch, where the service provider actually does learn MAC addresses. As far as the on-site customer device hosting the WAN circuit is concerned, it has directly learned the MAC addresses of devices at other sites. In fact though, just like a physical switch, the service provider is invisibly inspecting the traffic, learning where all the MAC addresses are, and forwarding and flooding traffic accordingly. VPLS (Virtual Private LAN Service) and EVPN (Ethernet VPN) are two different ways of achieving this end goal.

You now know enough about MPLS and MPLS VPNs to understand where the confusion lies.

 

“MPLS CIRCUITS”

At some point in history, someone – I assume marketing people, but who knows – decided to start using the phrase “MPLS circuits” to describe WAN circuits that don’t connect directly to the public internet, but instead go into a customer’s MPLS VPN instance, and probably a Layer 3 VPN in particular.

I can’t say I blame anyone for doing this. After all, ask yourself which is cooler: having an VPN circuit, or having an MPLS circuit? There’s a clear winner there!

Perhaps people started saying “MPLS VPN circuit”, but then they got bored and shortened it even further. Who knows how it all happened. There was almost certainly no one person who decided on all this; it’s just the way things turned out.

Here’s something funny though: the packets going across these so-called MPLS circuits don’t actually have any MPLS labels on them! The labels only happen in the service provider part of the network. The customer router on site doesn’t talk MPLS at all. Instead, the interface at the service provider’s end of the WAN circuit will be taken out of the public internet, and placed into a customer’s private routing instance. The service provider then uses MPLS to transport the VPN traffic across their network.

Kind of ironic that MPLS circuits technically don’t have any MPLS on them, isn’t it?

Anyway, back to our story. A side effect of this term “MPLS circuits” is that many network engineers in the enterprise world have come to incorrectly think that the term “MPLS” has one meaning and one meaning only, which is to refer to an MPLS VPN, and an L3VPN in particular. These engineers are not even aware that there is more than one meaning to the term.

Nor do they have any idea about labels, or label-switched paths, or LDP or RSVP. And nor do they need to! They just know that, once every billing cycle, they give their service provider Cold Hard Cash in exchange for managing their VPN for them, and this VPN involves something called MPLS circuits. As far as many enterprise engineers are concerned, the service provider is just a big cloud on their network diagrams.

The average enterprise engineer knows as much about service provider technologies such as MPLS, as I know about enterprise technologies such as Wi-Fi. Which is to say, nothing.

And let me be crystal clear at this point: this is completely fine! It is okay to not know absolutely everything in the world. You would go mad if you tried. Sure, it’s fun to learn about technology outside of your immediate job. Equally though, we all have limited spare time. It makes a lot of sense to focus on studying technologies that you will actually use in production. And most enterprise networks are unlikely to deploy actual MPLS, in the same way that Wi-Fi isn’t something I immediately need to study.

Nevertheless, MPLS has come to have two meanings – the real, broad use of MPLS labels to create labeled tunnels, and the dozens of use cases it offers, and then the more specific meaning of a customer WAN circuit that goes into an MPLS layer 3 VPN. As much as I dislike this second meaning, the fact is that “MPLS” does now have this second meaning, because that’s how people use it. Words mean what we use them to mean. That’s how language works, baby!!!

But these two meanings have, in my experience, caused a huge amount of confusion and misinformation.

 

THE CONFUSION THIS CAUSES

In my early days, I had no idea that “MPLS” had two meanings, and this cost me a job.

Someone at a conference once told me a similar story about a time they interviewed someone who made the same mistake – but this candidate took it one step further. They were asked about their experience with MPLS, and they replied “Actually, I’ve only used VPLS, not MPLS.” You may recall that VPLS is one of the MPLS VPN applications that works at layer 2 – and now that you’ve read this post, you can see the mistake they made. This highlights how “MPLS” doesn’t even just mean MPLS VPNs, but often means layer 3 MPLS VPNs in particular.

Anyway. This interviewer then clarified that they meant “label switching”. To which the candidate replied “Oh yes, we make sure to label all of our cables.” Oh my!

Clearly, this confusion causes real problems. And yes, in both mine and that other person’s experience, we should have studied more. At the same time, when you are surrounded by people who use MPLS specifically to mean MPLS VPN circuits… well, is it any wonder that this happens?

If you would like to do a kind gesture to your colleagues, consider talking about “MPLS VPN circuits” instead of simply “MPLS” or “MPLS circuit”. That one single change will instantly bring so much clarity to your conversation.

However, the problems this causes don’t end there.

 

“SD-WAN IS AN MPLS KILLER”

You will already be aware of the fact that marketing teams in the 2010s started declaring that “SD-WAN is an MPLS killer”.

Now, you will have your own opinions on SD-WAN in general, and its impact on other technologies. Put those opinions to the side, because that’s not what we’re here to talk about.

Instead, I want to talk about how this use of MPLS to mean “MPLS L3VPN” has led countless people to see conversations about MPLS in general, and jump in to them declaring that MPLS is on its way out – because they don’t realise that the term MPLS has another, broader meaning.

Honestly, at this stage I have lost count of the number of blog posts I’ve written about MPLS traffic engineering, or BGP-free service provider cores (lol, good job I learned about them eventually), that have had comments and tweet responses from people saying “I don’t think MPLS has a future”, or “I think SD-WAN will replace MPLS”.

Now that you are aware of the two meanings of MPLS, you can immediately see the mistake they’re making.

On the one hand, I don’t blame them. As I say, it’s not their fault. Then again, it is interesting that they are jumping into conversations about technologies that they have almost zero knowledge of. They’ve heard some marketing gumph, they’ve believed it, and they’ve felt confident enough to use this thread-bare understanding to join in conversations about MPLS. Was it ever any different in the networking world?

Ultimately, all of this confusion is entirely avoidable simply by using precise terms, by avoiding the use of the phrase MPLS to specifically mean MPLS VPNs, and by kindly helping your colleagues to be clear in their own speech too. Isn’t it wild to think that if everyone started saying “MPLS VPNs” instead of just “MPLS”, that this confusion would entirely disappear overnight?

 

THE CONCLUSION

When we use technical terms imprecisely, it causes confusion at best, and bad design decisions at worst.

And the thing is, we nerds tend to be big fans of science and technology, where such precision is crucial. And yet, we seem to have a blind spot in networking, where there are so, SO many examples of one term meaning different things in different protocols, and the confusion it causes. Anyone who has ever learned about a BGP session being active, or an EIGRP prefix being active, knows exactly what this feels like!

I surely do not need to convince you of the benefits of describing things with clarity, and in such a way that it leaves zero room for ambiguity or misunderstanding. One day I hope to convince the writers of RFCs of this concept, too. (Bit of fun there, loving your work folks.)

“MPLS” is not going anywhere any time soon. It cannot be stressed enough that MPLS is a transport technology that powers almost every single internet service provider in the world, regardless of whether they choose to advertise labels via LDP, RSVP or Segment Routing.

“MPLS Layer 3 VPNs” are one of many applications of MPLS. If enterprise engineers choose to call their circuits “MPLS circuits”, this isn’t technically wrong any more, because the term MPLS has come to have two meanings. Words mean what we use them to mean, after all. Still, hopefully you can see now why you might try to convince them to call it an MPLS VPN instead.

In any case, don’t ever let people do you a disservice by talking to you about MPLS in such a way that it leads to the fallacy of equivocation.

“I heard that MPLS is being killed by SD-WAN, so service providers soon won’t need to run MPLS”. You now know enough to see why that sentence is nonsense.

People who talk like this are hurting your education, and your understanding of networking. If you see it happening, don’t be afraid to ask them for clarity. Also though, don’t be unkind to them. Be generous, give them the benefit of the doubt, assume good faith—they may simply be confused themselves too. But don’t be scared to step in and untangle the confusion. Thanks to your new knowledge, you can be the captain of the conversation. And who knows – you might just help your colleague to level up too.

And for what it’s worth, I don’t think SD-WAN will “kill” MPLS VPNs, which is of course what the marketing people are trying to say. SD-WAN and MPLS VPNs both have their use-cases, both cost different amounts of money in different parts of the world, both come with advantages and trade-offs, both come with elements that are operationally easy and elements that are operationally complex. One solution may become more popular than the other over time, but always beware of anyone telling you that one technology will “kill” another. Chances are that their bonus depends on you believing them.

 

THANKS FOR READING!

Yo, thanks as always for reading my scrappy information super-highway site. If you fancy some more learning, take a look through my other posts. I’ve got plenty of cool new networking knowledge for you on this website, especially covering Juniper tech and service provider goodness.

If you’re on Mastodon, follow me to find out when I make new posts. (2024 edit: I’m also on BlueSky nowadays too. I was once on Twitter, but I’ve given up on it, on account of… well, I don’t need to finish that sentence, do I.)

It’s all free for you, although I’ll never say no to a donation. This website is 100% a non-profit endeavour, in fact it costs me money to run. I don’t mind that one bit, but it would be cool if I could break even on the web hosting, and the licenses I buy to bring you this sweet sweet content.

And of course, please do share this post with anyone who you see being confused about MPLS. Hopefully it will help them to level up, and will help them to bring more precision and accuracy to their conversations, to their network design choices, and their educational choices for the future.

See you next time!