Foundations of MPLS: Label Switching

In this article I will use the terms LSR, Edge LSR, Ingress LSR, Egress LSR, P, PE, and LSP. I won’t spend much time defining them. For a review of the terminology, here’s a decent summary video. My aim with this piece is to illustrate the fundamentals of label switching by looking inside a functional MPLS network with CLI commands and packet captures.

Whenever you see a packet capture image in this article, you can click on it to go to that packet capture’s location in my github repo to download it. Sometimes it can be handy to explore the packet capture with your local copy of wireshark.

In this post, we will follow an ICMP packet from the time it is sent from router PE3, through the network, to when it lands on its destination,  router PE4. You may want to open the below diagram in another window so that you can keep it in sight as you read through the rest of the article.

The label-switched path (LSP) that our ICMP packet follows looks like this:

A few facts:

  • The LSP only exists in the MPLS domain. In simple, classical MPLS the beginning and end of the LSP are always on an Edge LSR (or PE) router. Even if we were pinging from Host8 to Host7, the LSP would still only exist on routers PE3, P1, P2, and PE4.
  • The LSP is unidirectional. We are concerned only with the path the packet takes towards router PE4. The packet coming back will take a different LSP.

How does traffic know to follow this LSP?

To answer that, let’s see what the packet looks like as it travels along the LSP. Here it is when it exits router PE3’s Gi1 (upstream) interface.

An MPLS header with a label value of 102 has been inserted between the ethernet and IP headers. This is what the router is using to forward the packet.

The forwarding table in the router shows that label 102 is assigned to the prefix that we are pinging, 4.4.4.4/32:

The next time this packet will be on the wire is between P1 and P2. Let’s take a look at it as it leaves P1’s Gi2 (upstream) interface:

An MPLS header is again seen, but this time we see a different label value. Label 102 has been swapped out for Label 201. Now let’s look at the forwarding table on P1.

You’ve probably noticed there are not one but two label values associated with a prefix at each LSR – a Local Label and an Outgoing Label.

This is a good time to stop and ask the question, on that first router, PE3, how did label 102 get picked? Two discrete things are going on with label 102:

  1. The label value 102 (from router PE3’s perspective) has to be assigned by something. That something is the label manager process running on the upstream router, P1. In most vendor implementations, the LDP process is responsible for assigning labels to prefixes.
  2. The label value 102 is chosen by P1 to represent the prefix 4.4.4.4/32. We can clearly see from our show command output above that PE3 knows about that mapping between 4.4.4.4 and label 102. How did it learn that? LDP is one protocol that MPLS LSR’s can use to tell each other about which labels are assigned to which prefixes.

Router P1 allocated label 102 to the prefix 4.4.4.4/32, and then turned around and used LDP to tell router PE3 that if it wants to send packets to 4.4.4.4, it’s going to have to put label 102 in the MPLS header.

LDP Quick Summary

  • LDP discovers neighbors using multicast hellos and then nails up TCP sessions between all discovered neighbors using port 646. This TCP session is what the LSRs use to exchange their label bindings. A label binding is simply the mapping between a prefix and a label value.
  • The most common configuration of LDP will only discover directly-connected neighbors.

The last time we will see the packet on the wire will be as P2 forwards it towards the final destination on PE4. This will reveal an important behavior of MPLS forwarding.

The MPLS header is gone, even though the P2 – PE4 link is an MPLS link. Why is this happening? This behavior is known as Penultimate Hop Popping (PHP). To understand why PHP is useful, check out this and this. We can see that PHP was specifically requested by router PE4 by examining the forwarding table on router P2 and the label bindings table on router PE4.

Router P2 knows that it needs to perform PHP, as shown by Pop Label in the Outgoing Label field. But how did it learn that it needs to pop the label for traffic destined to this prefix? The same way that it learns all of the other labels – the upstream router told it to, by use of a special label called “implicit-null”. Here’s the relevant section of the label bindings table on router PE4:

Router PE4 has allocated a label with a value of 3, which is a reserved label. This label (shown as imp-null in the example above) instructs the downstream router to pop the label and then use its unicast IP routing table to forward the packet to the tail end of the LSP (router PE4).

Let’s run a traceroute to see what the LSP looks like from end to end. Cisco’s implementation shows us which labels are used on each hop.

Now let’s add the labels for 4.4.4.4/32 on each hop to our diagram to show the complete end to end LSP.

The Role of the IGP

You probably have a lingering question in the back of your mind at this point – “How does the router know about the destination prefix (4.4.4.4/32) in the first place?” The answer is simple – the IGP provides the prefixes, like it normally does in a non-MPLS network. In this example, we are using IS-IS as our IGP. Here’s what the routing table looks like on PE3:

Labels are assigned based on which prefixes are in the routing table. If we look at the full label bindings table on PE3 we see that a label has been assigned for each of the above routes:

Which IGP should you use in your MPLS network? Anything will work – even RIP or static routes if it comes down to it. For some of the more advanced features, such as traffic engineering, you’ll need to run a link-state IGP. But for basic implementations, it matters not how the routes get into the routing table, as long as they get there. Choosing an IGP is an entire discussion on its own, so I won’t go in to it here.

So What?

If running label switching in the network results in the packets taking the exact same path as would be accomplished just using a flat IGP, why would you do it?

MPLS applications (such as L3VPN, L2VPN, or Traffic Engineering) run over the top of a label-switched infrastructure. The LSP we have been using in this article is a transport mechanism, and is generally not useful all by itself. For example, if you were going to run L3VPNs on your MPLS network, you would see an additional label on the label stack as the packets transit across the network. But we have to have the label switching foundations laid before we can start using some of these other applications.

Why Does This Matter?

  • Label switching provides the foundations upon which MPLS applications rest.
  • To quickly troubleshoot issues with MPLS forwarding, you must understand how LSPs are built.
  • One control-plane protocol that builds LSP’s for us is LDP – there are other choices, such as RSVP. It’s also possible to build LSP’s by carrying labels inside of BGP, as is the case with L3VPN’s.

 

 

 

 

 

 

 

 

2 thoughts on “Foundations of MPLS: Label Switching”

Leave a Reply

Your email address will not be published. Required fields are marked *