MPLS is a common technology that many people use, but that the majority of people neither configure nor support on a day-to-day basis. MPLS stands for multi protocol label switching. Fortunately, MPLS is not as complex as its name might suggest. Or, perhaps more accurately, a basic understanding of MPLS is not as complex as many people think it is. In this article, we will look at what MPLS is, some of the benefits it provides, the inner workings of a MPLS layer 3 VPN, and touch briefly on how to enable it.
So to start, let’s go ahead and break down the acronym. Multi protocol—all this means is that it is going to work for multiple protocols. MPLS works with protocols at both layer 2 and layer 3 of the OSI model. For layer 3, it supports IP, IPv6, and IPX, for example. At layer 2, it supports multiple standards as well—Ethernet being the most common example, of course—but also PPP, frame-relay, and ATM, among others. Label switching is the second part. All this means is that, rather than using the destination address in the IP header, you are going to determine where and how to send it based on a label in the MPLS header. This MPLS header is added to a packet when it enters the MPLS network.
So, why go through all the hassle of the new header? The answer is actually relatively easy to understand. Imagine you are mailing a letter. When you send a letter, you write where you need it sent to. Now, the post office could hire millions of people to work at their sorting centers taking each letter, reading the address on each letter one at a time, and taking it to a specific truck for transit to the next postal sorting office. But, as you can imagine, this becomes extremely inefficient as soon as they have more than a few letters to process. Instead, when the postal service first receives the letter, they stick a unique code on the letter. All processing for that letter from that moment until it reaches your local courier’s truck is based on that unique code. This allows the postal office to add efficient machinery that can sort billions of pieces of mail with minimal human intervention. MPLS at its inception was attempting to solve the same problem. It’s far more efficient from a processing perspective to look at a small label than it is to look at an entire IPv4 destination address.
Now, with all this talk of efficiency, it should be noted that the MPLS technology has been widely used for some time, and was a standard long before it began being widely used. When developed, the creators of MPLS had a vastly different level of processing power available to them. As you can tell from the above explanation, MPLS was written to make forwarding a packet more efficient. In many—though by no means all—of the modern-day MPLS networks, all forwarding is done by powerful hardware ASICs, without ever even having to touch the CPU of the device. Knowing that forwarding efficiency is not as much of an issue today as it was at the time MPLS was developed by no means discounts the benefits of MPLS. Think of it this way—if cold fusion ever becomes a reality, it doesn’t mean we will stop using light bulbs—but it would mean that getting everyone to use the ultra-efficient models probably will not be quite as high a priority as it otherwise would have been.
Aside from forwarding efficiency, remember that, in traditional packet-switched IP networks, almost everything is done based solely on the destination IP address in the packet. Since an MPLS label is added to the packet after a host sends it, you can associate a label with more than just the specific destination of the end host. For example, if you wanted, you could associate traffic that needed low latency service with destination ABC with label 12345. You could also associate traffic only requiring normal service with the same destination ABC with label 23456. Going back to the post office example, one series of digits might be media mail to your house, whereas another series of digits represents next day air to your home. Both labels point to the same destination, but they represent different ways of being handled as they are being sent there.
Another non-efficiency-related benefit that MPLS brings to those who use it is its flexibility in controlling the path that a given packet will take. To understand this further, we have another acronym to define. It is LSP, which stands for label switched path. An LSP is a specific path from the ingress MPLS router to the egress MPLS router. When you add a MPLS header to a packet, the label in that header is associated with a specific LSP. All packets going over the same LSP are going to follow the exact same path through the network, with a few exceptions outside the scope of this document. Through the use of traffic-engineering mechanisms (also beyond the scope of this document), or by simply adjusting some underlying protocols, you can influence what that path will be, on both a primary and secondary basis. There are many ramifications of being able to control the end-to-end path through the MPLS network. For example, let’s say you have two tiers of service, gold and silver. Your gold service is supposed to provide enhanced throughput with lower latency and jitter to customers. Your silver service provides service to customers where the consistently greater throughput and enhanced forwarding are not guaranteed. By using MPLS LSPs, you can specify that the gold traffic uses your more expensive backbone circuits, whereas the silver traffic uses the less expensive ones.
As stated above, MPLS also provides a carrier the ability to specify backup LSPs. In other words, if, for example, your “gold” circuits went down, you could have them instantly fail to the silver circuits. And not only that, but you can also ensure that, if there isn’t enough bandwidth to serve both gold and silver traffic, the gold traffic would take precedence, and the silver traffic would be dropped.
As you can see, the real reason MPLS has caught on and is used so widely is its flexibility.
The next acronym to define in relation to MPLS is LDP. LDP (label distribution protocol) is the protocol responsible for the distribution of labels between MPLS routers. LDP works by having MPLS routers establish neighborships with other adjacent MPLS routers.
Over these neighborships, MPLS label information is exchanged. There are two router types within an MPLS domain: PE (provider edge), and P (provider). Provider edge routers handle adding and/or removing the MPLS header from a normal IP packet and are the entry and exit points to a MPLS domain. Provider devices merely manipulate the MPLS header, usually either just changing the label number (swap), or removing the topmost label (pop). Likening it to the post office, PEs are the home and/or destination post offices, and P routers are the trucks that carry it from office to office.
If you noticed that the word “topmost” was used here, well done. You can—and often do—have multiple labels in a MPLS label stack. More on this later. Once LDP is enabled, all devices allocate a label for every prefix in their IGP table. IGP is the key word here since, by default, labels are not assigned to any BGP-learned routes. To exchange labels for BGP-learned routes, you normally use a special type of BGP peering called a VPNv4 peering. Again, we’ll be touching more on this later. The labels assigned to each prefix are then advertised to whatever LDP neighbors a device has. So, for example, let’s say you have one PE device that has a neighborship with another P device. Both the PE and P routers have a route in their IGP table for 188.8.131.52. Both routers allocate a locally significant label to 184.108.40.206 and send that mapping to their neighbor. Essentially this message tells the other neighbor that to reach 220.127.116.11 via them, you send that packet with a certain label. This process is repeated on each device within the MPLS domain, with the label being either changed or popped at each hop, until the packet arrives at the destination address associated with the topmost label.
It is critical to understand that LDP itself is not a substitute for an interior routing protocol. In fact, LDP is pointless without one. LDP relies on routes being in the routing table of a device so it can allocate labels to each of those and send those label bindings to adjacent MPLS neighbors.
It doesn’t necessarily matter how you get the routes in the routing table, but they have to be there, otherwise, LDP is not going to allocate a label for each of them. You can even use static routes rather than a dynamic routing protocol, though that would be a lot of work!
Now that we’ve touched on the higher-level points, we can dig a little deeper into understanding exactly how the labels employed by MPLS work. Being able to follow a specific label is critical to being able to troubleshoot a wide variety of issues relating to MPLS. For the purpose of this document, we will assume we are using a MPLS Layer 3 VPN.
In a typical MPLS Layer 3 VPN, all your PE devices have VPNv4 peerings with one another. All the PE devices know about actual customer routes over this BGP peering. The labels associated with the actual end-customer routes become the labels used in the inner MPLS header (also known as the VPN label).
The label associated with the BGP next hop of the remote PE device advertising that customer route is what becomes the outer label (also known as the path label). Going back to our post-office analogy, the VPN label is the address of the person receiving the letter. The path label is the name of the destination post office.
So the ingress PE actually appends two MPLS labels in the header. First, a lookup is done in the BGP table to find the VPN label. Then, the path label is put on top of that. The path label is what you use to get to the egress PE router, and the VPN label is what the egress PE uses to send it out the right interface.
Now, on to yet another acronym! Next up is PHP. PHP stands for penultimate hop popping. Before we define what PHP is, we need to understand a problem seen by the developers of MPLS. To get a packet ready to send toward a customer, two things have to be done. First, you have to remove the path label. Second, you have to do a lookup on the VPN label to determine which interface to send it out through. Rather than have the egress PE router do both of these tasks, PHP is done. All PHP does is have the router connected to the egress PE remove the path label prior to sending it to the egress PE. In this way, the workload is distributed. The last P router before the egress PE removes the outer path label, while the egress PE removes the inner VPN label and sends it towards its final destination.
So, how do you configure MPLS? Well, as we have learned above, there is more than just a single component to MPLS. But, to simply enable an interface to carry MPLS frames, you use the “mpls ip” command under the interface. But, to have a truly functioning MPLS network, remember that you will also need IGP and LDP neighborships between your P and PE routers, BGP VPNv4 peerings between your PE routers—and, of course, some way to learn about the actual end-customer routes.
Hopefully, this article has dispelled some of the fear and confusion around MPLS. The theory behind MPLS is really not all that complicated. For all the reasons listed above, MPLS provides efficiency, features, and flexibility. Although, as with almost everything, it’s a lot easier to understand the theory behind MPLS than it is to have an extensive understanding of its configurations and inner workings, it is by no means impossible. MPLS is not going to go away any time soon, so having a basic understanding of it can be immensely beneficial to you as a network engineer, regardless of whether or not you work for a service provider using MPLS on their backbone.