Now that we have an IGP running between all of the provider routers, we can enable MPLS on the links connecting all of the routers together. Before we do that, it’s probably a good time to discuss some MPLS basics.
MPLS is a way of label-switching packets through a network. The basic idea being that it was faster to look up a label than to look up a destination IP prefix. When you enable MPLS the router assigns a locally significant label to each prefix. Let’s take a quick look at a label on a router so you can see what I mean…
P1#show mpls ldp bindings
lib entry: 1.1.1.1/32, rev 2
local binding: label: 16
lib entry: 2.2.2.2/32, rev 4
local binding: label: imp-null
lib entry: 3.3.3.3/32, rev 6
local binding: label: 17
lib entry: 4.4.4.4/32, rev 8
local binding: label: 18
lib entry: 5.5.5.5/32, rev 10
local binding: label: 19
lib entry: 6.6.6.6/32, rev 12
local binding: label: 20
lib entry: 7.7.7.7/32, rev 14
local binding: label: 21
lib entry: 172.172.172.0/30, rev 16
local binding: label: imp-null
lib entry: 172.172.172.4/30, rev 18
local binding: label: imp-null
lib entry: 172.172.172.8/30, rev 20
local binding: label: 22
lib entry: 172.172.172.12/30, rev 22
local binding: label: 23
lib entry: 172.172.172.16/30, rev 24
local binding: label: imp-null
lib entry: 172.172.172.20/30, rev 26
local binding: label: imp-null
lib entry: 172.172.172.24/30, rev 28
local binding: label: 24
lib entry: 172.172.172.28/30, rev 30
local binding: label: 25
lib entry: 172.172.172.32/30, rev 32
local binding: label: 26
lib entry: 172.172.172.36/30, rev 34
local binding: label: 27
lib entry: 172.172.172.40/30, rev 36
local binding: label: 28
In this case, I have enabled MPLS on P1 (don’t worry, we are still going to walk through how to do that). As you can see, the router has applied a label to each prefix in the routing table. Pretty straight forward huh? To confuse the matter, let’s look at the same command output from P2 which I’ve also configured for MPLS.
P2#show mpls ldp bind
lib entry: 1.1.1.1/32, rev 2
local binding: label: 16
remote binding: lsr: 2.2.2.2:0, label: 16
lib entry: 2.2.2.2/32, rev 4
local binding: label: 17
remote binding: lsr: 2.2.2.2:0, label: imp-null
lib entry: 3.3.3.3/32, rev 6
local binding: label: 18
remote binding: lsr: 2.2.2.2:0, label: 17
lib entry: 4.4.4.4/32, rev 8
local binding: label: 19
remote binding: lsr: 2.2.2.2:0, label: 18
lib entry: 5.5.5.5/32, rev 10
local binding: label: imp-null
remote binding: lsr: 2.2.2.2:0, label: 19
lib entry: 6.6.6.6/32, rev 12
local binding: label: 20
remote binding: lsr: 2.2.2.2:0, label: 20
lib entry: 7.7.7.7/32, rev 14
local binding: label: 21
remote binding: lsr: 2.2.2.2:0, label: 21
lib entry: 172.172.172.0/30, rev 16
local binding: label: 22
remote binding: lsr: 2.2.2.2:0, label: imp-null
lib entry: 172.172.172.4/30, rev 18
local binding: label: 23
remote binding: lsr: 2.2.2.2:0, label: imp-null
lib entry: 172.172.172.8/30, rev 20
local binding: label: 24
remote binding: lsr: 2.2.2.2:0, label: 22
lib entry: 172.172.172.12/30, rev 22
local binding: label: imp-null
remote binding: lsr: 2.2.2.2:0, label: 23
lib entry: 172.172.172.16/30, rev 24
local binding: label: 25
remote binding: lsr: 2.2.2.2:0, label: imp-null
lib entry: 172.172.172.20/30, rev 26
local binding: label: imp-null
remote binding: lsr: 2.2.2.2:0, label: imp-null
lib entry: 172.172.172.24/30, rev 28
local binding: label: imp-null
remote binding: lsr: 2.2.2.2:0, label: 24
lib entry: 172.172.172.28/30, rev 30
local binding: label: 26
remote binding: lsr: 2.2.2.2:0, label: 25
lib entry: 172.172.172.32/30, rev 32
local binding: label: imp-null
remote binding: lsr: 2.2.2.2:0, label: 26
lib entry: 172.172.172.36/30, rev 34
local binding: label: 27
remote binding: lsr: 2.2.2.2:0, label: 27
lib entry: 172.172.172.40/30, rev 36
local binding: label: imp-null
remote binding: lsr: 2.2.2.2:0, label: 28
Notice anything odd? It appears that the labels for each prefix aren’t globally unique. The labels are in fact, only locally significant to the router. For the longest time, this just didn’t make sense to me. For now, just keep in mind that the labels are only locally significant to the router.
It’s also important to know where the labels are being stored. Labels are stored in the CEF table with the prefix. Let’s take a quick look at that as well…
P2# show ip cef 1.1.1.1 detail
1.1.1.1/32, epoch 0, per-destination sharing
local label info: global/16
nexthop 172.172.172.21 FastEthernet0/0.6 label 16
nexthop 172.172.172.26 FastEthernet0/0.7 label 16
As you can see, the router has two equal cost paths (two routes in the FIB) for 1.1.1.1/32. The prefix itself has been assigned the label of 16.
Now that we know that the router is assigning a label to each router we need a way to distribute these labels to other MPLS enabled routers. This is where LDP comes in to the picture. LDP stands for label distribution protocol and it’s the protocol used to distribute labels between all of the routers. When talking about LDP and MPLS there are a couple of key terms to keep in mind.
General MPLS terminology
FEC – Forwarding Equivalence Class. The FEC is a set of similar packets which are forwarded the same way and bound to the same label
LSP – Label Switched Path. The LSP is the path that traffic takes through the MPLS network for a particular FEC
LSR – Label Switching Router. A router that has MPLS enabled and performs label based operations.
LIB – Label Information Base. Similar to the RIB in IP speak, holds all of the labels received.
LFIB – Label Forwarding Information Base. Similar to the FIB in IP speak. The label forwarding information that is used to forward traffic.
Label Distribution Modes
Downstream on demand – In this mode each LSR requests a label for a particular FEC from the next hop router. Each LSR only receives one binding per FEC from its downstream LSR. The downstream LSR is the next hop router found in the IP routing table.
Unsolicited Downstream – In this mode each LSR distributes a binding to all of its adjacent LSRs without those LSRs requesting the label.
Label Retention Modes
Liberal Label Retention Mode – Only one label binding is put in the LFIB but the rest are kept in the LIB.
Conservative Label Retention Mode – Only the remote binding that is associated with the next-hop LSR is stored in the LIB.
LSP Control Modes
Independent LSP Control Mode – The LSR created a local binding for a FEC independently from other LSRs. The binding is created as soon as a new FEC is recognized by the LSR.
Ordered LSP control Mode – The LSR only creates a local binding for the FEC is it recognizes that it is the egress LSR for the FEC or if the LSR has received a label binding from the next hop for the FEC. In this manner, it would only create bindings for routes that show as connected in the routing table or for IGP prefixes in which it has already received a label binding from the next hop router.
LSP Label operations
Swap – The top label in the label stack is replaced with another
Push – The top label is replaced with another and then on or more additional labels are pushed onto the label stack
Pop – The top label is removed
Untagged/No Label – The stack is remove and the packet is forwarded unlabeled
Aggregate – The stack is removed and an IP lookup is done on the IP packet
Ok, so that was a lot, but I think it’s best just to use the definitions to describe label distribution and some of the general LSP terminology. So let’s summarize the key parts of those definitions…
-Labels are assigned to FECs
-FECs take the same LSP through the MPLS network
-Labels are distributed between LDP neighbors. Unsolicited downstream distribution mode is the default distribution method on Cisco IOS.
-LSRs create a local binding for a FEC. Independent LSP control mode is the default LSP control method on Cisco IOS.
-LSRs have three main MPLS operations. Swap, push, and pop.
Configuring MPLS
Alright, well that was a somewhat brief explanation of MPLS with some key term definitions. Now, let’s take a look at the very complex configuration of MPLS.
P1
interface FastEthernet0/0.1
mpls ip
interface FastEthernet0/0.2
mpls ip
interface FastEthernet0/0.5
mpls ip
interface FastEthernet0/0.6
mpls ip
P2
interface FastEthernet0/0.4
mpls ip
interface FastEthernet0/0.6
mpls ip
interface FastEthernet0/0.7
mpls ip
interface FastEthernet0/0.9
mpls ip
interface FastEthernet0/0.11
mpls ip
P3
interface FastEthernet0/0.8
mpls ip
interface FastEthernet0/0.9
mpls ip
interface FastEthernet0/0.10
mpls ip
P4
interface FastEthernet0/0.3
mpls ip
interface FastEthernet0/0.5
mpls ip
interface FastEthernet0/0.7
mpls ip
interface FastEthernet0/0.8
mpls ip
PE1
interface FastEthernet0/0.1
mpls ip
interface FastEthernet0/0.3
mpls ip
PE2
interface FastEthernet0/0.2
mpls ip
interface FastEthernet0/0.4
mpls ip
PE3
interface FastEthernet0/0.10
mpls ip
interface FastEthernet0/0.11
mpls ip
That’s it! All you need to do is issue the ‘mpls ip’ command on any interface you want to talk LDP and use MPLS. Now let’s look at a couple of commands to verify the MPLS configuration.
P1#show mpls ip binding
1.1.1.1/32
in label: 16
out label: 16 lsr: 5.5.5.5:0
out label: 16 lsr: 4.4.4.4:0
out label: imp-null lsr: 1.1.1.1:0 inuse
out label: 16 lsr: 3.3.3.3:0
2.2.2.2/32
in label: imp-null
out label: 17 lsr: 5.5.5.5:0
out label: 17 lsr: 4.4.4.4:0
out label: 16 lsr: 1.1.1.1:0
out label: 17 lsr: 3.3.3.3:0
3.3.3.3/32
in label: 17
out label: 18 lsr: 5.5.5.5:0
out label: 18 lsr: 4.4.4.4:0
out label: 17 lsr: 1.1.1.1:0
out label: imp-null lsr: 3.3.3.3:0 inuse
4.4.4.4/32
in label: 18
out label: 19 lsr: 5.5.5.5:0
out label: imp-null lsr: 4.4.4.4:0 inuse
out label: 18 lsr: 1.1.1.1:0
out label: 18 lsr: 3.3.3.3:0
5.5.5.5/32
in label: 19
out label: imp-null lsr: 5.5.5.5:0 inuse
out label: 19 lsr: 4.4.4.4:0
out label: 19 lsr: 1.1.1.1:0
out label: 19 lsr: 3.3.3.3:0
<Extra output removed…>
As you can see here, this shows the IP to label binding that is configured on P1. This is where the labels can get confusing. Let’s take a look at the binding for the prefix 1.1.1.1/32 and another quick copy of our network diagram so that this make’s sense.
So in the case of LSR P1 (2.2.2.2) we can see from the output….
1.1.1.1/32
in label: 16
out label: 16 lsr: 5.5.5.5:0
out label: 16 lsr: 4.4.4.4:0
out label: imp-null lsr: 1.1.1.1:0 inuse
out label: 16 lsr: 3.3.3.3:0
That we have three LDP neighbors P2 (5.5.5.5), P4 (4.4.4.4), PE1 (1.1.1.1), and PE2 (3.3.3.3). By chance, all of these routers also have label ‘16’ as their local binding for the prefix which is denoted by the ‘out’ label’ for that particular ldp neighbor. The best path to 1.1.1.1/32 is to PE1 since that’s where the loop back lives. This is denoted by the ‘inuse’ keyword next to that label binding. It should also be noted that the out label for the best route shows as ‘imp-null’. Imp-Null actually means implicit null and indicates that the router will actually pop the label off before forwarding the traffic towards PE1. This is a function of PHP (Penultimate Hop Popping). PHP pops the MPLS label off before sending the label to the next router. It does this since it knows that the next router (PE1) owns that IP address. In order to save PE1 the trouble of doing a label lookup as well as a IP lookup, P1 pops the label off and sends the packet layer 3 so that PE1 just has to process a standard IP packet rather than a label and a IP packet. This feature is on by default in Cisco IOS. This can also be confirmed by looking at the LFIB…
P1#show mpls forwarding-table 1.1.1.1 32
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
16 Pop Label 1.1.1.1/32 0 Fa0/0.1 172.172.172.1
As you can see, P1 will pop the label before sending it on it’s way. This output also shows that the LFIB knows where to send the traffic once it performs its LSR operations on the packet. It knows to send it out interface F10/0.1 once it pops the packet. This also explains how we can have 4 neighbors who all have the same label for the same prefix. The label is locally significant so once the LSR performs it’s MPLS operations, the traffic is forwarded out the correct interface towards the correct router.
Summary
So I know that was a lot to swallow but I’m hoping that was enough to at least give you a base understanding of MPLS. In the next post, we’ll be talking about how carriers use MPLS and MP-BGP to carry multiple different customers traffic across the same MPLS core network.