Chapter 19: Multiprotocol Label Switching

I. MPLS Unicast IP Forwarding

1. MPLS Unicast IP Forwarding forwards packets based on labels. However, when
choosing the interfaces out which to forward the packets, MPLS still relies on
routing protocols and only considers routes in the unicast ip routing table.
2. MPLS requires protocols like OSPF and LDP to learn labels.

2. MPLS IP Forwarding: Data Plane

1. Hosts do not par0ticipate in MPLS and should not send or receive labels. There
need to be routers that add the labels and also routers that remove them. Pushing
and Popping.
2. MPLS relies on CEF and also expands the logic and data structures of CEF.
2. CEF Review
1. Control plane uses routing protocols, static routes and connected routes to create the
RIB. The RIB is downloaded into extremely fast hardware thus creating the
Forwarding Information Base (FIB) and the Adjacency table. The FIB and
Adjacency table take the place of the RIB and the ARP table. Any changes in the
RIB and ARP table are synchronized with the FIB and Adjacency table. Traffic is
packet switched through hardware without using the cpu, with virtually no delay.

3. Overview of MPLS Unicast IP Forwarding

1. The diagram shown below illustrates how hosts computers, and even the customer
routers (in this example) are not aware of MPLS, and do not send or receive labels.

2. The steps from the figure are explained as follows:

1. Host A generates and sends an unlabeled packet destined to host 10.3.3.3
2. Router CE1, with no MPLS features configured, forwards the unlabeled packet
based on the destination IP address, as normal, without any labels. (Router CE1
may or may not use CEF.)
3. MPLS router PE1 receives the unlabeled packet and decides, as part of the
MPLS forwarding process, to impose (push) a new label (value 22) into the
packet and forwards the packet.
4. MPLS router P1 receives the labeled packet. P1 swaps the label for a new label
value (39) and then forwards the packet.
5. MPLS router PE2 receives the labeled packet, removes (pops) the label, and
forwards the packet toward CE2.
6. Non-MPLS router CE2 forwards the unlabeled packet based on the destination
IP address, as normal. (CE2 may or may not use CEF.)

4. MPLS Forwarding Using the FIB and LFIB

1. FIB - Used for incoming unlabeled packets. Cisco IOS matches the packet's
destination IP address to the best prefix in the FIB and forwards the packet based on
that entry.
2. LFIB - Used for incoming labeled packets. Cisco IOS compares the label in the
incoming packet to the LFIB's list of labels and forwards the packet based on that
LFIB entry.

1. What happens in the above diagram:

1. PE1 - When the unlabeled packet arrives at PE1, PE1 uses the FIB. PE1
finds the FIB entry and matches the packet's destination address of 10.3.3.1 namely, the entry for 10.3.3.0/24 in this case. Among other things, the FIB
entry includes the instructions to push the correct MPLS label in front of the
packet.
2. P1 - Because P1 receives a labeled packet, P1 uses its LFIB, finding the label
value of 22 in the LFIB, with that entry stating that P1 should swap the label
value to 39.
3. PE2 - PE2 uses the LFIB as well, because PE2 receives a labeled packet; the
matching LFIB entry lists a pop action, so PE2 removes the label, forwarding
an unlabeled packet to CE2.
2. MPLS can enable forwarding processes based on something other than the
destination IP address, such as forwarding based on the VPN from which the
packet originated, forwarding to balance traffic with traffic engineering, and
forwarding over different links based on QoS goals.

5. The MPLS Header and Label

1. The MPLS header is a 4-byte header. Some refer to it as the MPLS label (a
misnomer) Also known as an MPLS shim header.

Field

Length
(Bits)

Purpose

Label

20

Identifies the portion of a label switched

path (LSP).

Experimental (EXP)

Used for QoS marking; the field is no

longer used for truly experimental purposes

Bottom-of-Stack (S)

Flag, which when set to 1, means that this is

the label immediately preceding the IP
header.

Time-to-Live (TTL)

Used for the same purposes as the IP

header's TTL field.

2.
6. The MPLS TTL Field and MPLS TTL Propagation
1. The diagram below shows how MPLS TTL field is used. Remember that the IP
header is not used in MPLS, therefore the ip headers TTL field is not decremented.
However, when a label is pushed for the first time on the ingress PE router, the IP
TTL field is copied over to the MPLS TTL field and the MPLS field is decremented
at each router along the LSP until the label is popped. Once the label is popped, the
now decremented MPLS TTL Field is copied back over to the IP header TTL field
thus reflecting the number of hops traversed through the MPLS network in the IP
header.

2. The diagram below illustrates a disabled TTL propagation on the MPLS network;
effectively making the MPLS network invisible to the customers for traceroute. The
ingress PE router does not copy over the IP TTL field to the MPLS TTL field and the
MPLS TTL field is set to 255. The egress PE router does not modify the IP TTL
field when popping the label and forwarding the packet to the customer.
3. If disabling TTL propagation, it is best practice to disable it on all routers within the
MPLS network for consistent output of the TTL propagation.

7.

3. MPLS IP Forwarding: Control Plane

1. Many control plane protocols can be used with MPLS; however the protocol used
depends on the MPLS application used. While multiple control plane protocols may
be used for some MPLS applications, MPLS unicast IP forwarding uses an IGP and
one MPLS-specific control plane protocol: LDP.
2. MPLS VPNs use MP-BGP and LDP.
2. MPLS LDP Basics
1. LDP advertises a label for each prefix in the RIB. LDP advertisements are triggered
by a new IP route appearing in the RIB. When a new route is learned a local label is
allocated to it and advertised to all neighbors

2. PE2 receives an update for a prefix from CE2. A local label that hasn't been used yet
is allocated to it and the prefix along with it's label is advertised out. IF PE2 starts to
get labeled packets with 39 in the label, PE2 will see that the LFIB says to pop the
label and forward it out to CE2.

3. As you can see above, starting off where the last diagram left off, P1 and P2 receive
the routing updates and label information, and allocate their own local labels and
advertise it out to ALL neighbors, even though advertising it back out to PE2 isn't all
that useful. The control plane protocols (eigrp in this case) take care of loop
avoidance.

3. The MPLS Label Information Base Feeding the FIB and LFIB
1. The Label Information Base (LIB) contains all label information, but only the best
Label Switch Path (LSP) is used to populate the FIB and LFIB.
2. LSRs rely on routing protocols for choice of best route and loop avoidance. The
best route from the RIB is used for MPLS. The label information is found with each
best route and is used to dynamically populate the FIB and LFIB.
3. The below diagram shows a sample MPLS unicast IP forwarding network.

4. The below is how to enable MPLS unicast ip forwarding.

5. The below shows some interesting information.

1. show ip route 10.0.0.0 - Shows the best path for 10.0.0.0 which will be used to
populate the FIB and LFIB.
2. show mpls ldp bindings 10.3.3.0/24 - Shows LIB information regarding
10.3.3.0/24. The local binding which was locally assigned and advertised via
LDP to all neighbors. Also shows the two remote bindings which are the LSPs
through P1 and P2 to get to 10.3.3.0/24

4. f

1. The above the process to determine the outgoing label

1. The routing table entry to 10.3.3.0/24 lists a next-hop IP address of 192.168.12.2.
PE1 compares that next-hop information to the list of interface IP addresses on
each LDP peer and finds the LDP neighbor who has IP address 192.168.12.2.
2. That same stanza of the show mpls ldp neighbor command output identifies the
LDP ID (LID) of this peer, namely 2.2.2.2.
3. PE1 notes that for that same prefix (10.3.3.0/24), the LIB contains one local
label and two remote labels.
4. Among the known labels listed for prefix 10.3.3.0/24, one was learned from a
neighbor whose LID is 2.2.2.2, with label (tag) value of 22.
5. As a result of these steps, PE1 knows it should use outgoing interface S0/0/1,
with label 22, when forwarding packets to subnet 10.3.3.0/24.

5. Examples of FIB and LFIB Entries

1. As mentioned earlier, the RIB and LIB is not used for the actual packet-forwarding
process, but is used to populate the tables located in hardware that do: The FIB and
LFIB.
2. The FIB is used for non-labeled packets and the LFIB is used for labeled packets.
1. PE1 simply adds information to the FIB stating that PE1 should impose an
MPLS header with label value 22. PE1 also populates the LFIB, with an entry
for 10.3.3.0/24, using that same label value of 22 and an outgoing interface of
S0/0/1.
3. The below shows the FIB and LFIB contents respectively.
1. show ip cef 10.3.3.0 - The interesting information shown here in regards to
MPLS is the local label, the outgoing interface, and the tag that should be pushed
(imposed). The FIB is also used to forward the packet, even though there is also
an LFIB entry for it as well. The reason the FIB is used as the packet came into
the router unlabeled and the FIB was used for the label imposition. The FIB has
the information to forward the packet as well so sending the packet to the LFIB
is not necessary and would only delay the packet forwarding process.
2. show mpls forwarding-table 10.3.3.0 24 - shows the local label for 10.3.3.0/24
along with the outgoing label, prefix and outgoing interface.

6. f

1. In the last example, PE1 received an unlabeled packet and ended up sending it, with
an imposed label, to P1.
2. Below, P1's LFIB and LIB is shown using the following show commands:
1. show mpls forwarding-table 10.3.3.0 24 - The labeled packet is received with a
label of 22, which is the local label on P1 due to the fact that P1 allocated label
22 locally and advertised it out to all neighbors. Because the label is 22, P1
knows to pop this label and push outgoing label 39 and send it out S0/1/0.
2. show mpls ldp bindings 10.3.3.0 24 - P1's LIB showing all Labels advertised to
P1 via LDP, as well as the local label 22.

3. The below shows PE2's LFIB, which shows that PE2 must pop the label and send it
out interface Fa0/1 untagged (without a label).

7. Label Distribution Protocol Reference

1. LDP uses multicast hellos (UDP 646 for LDP and UDP 711 for TDP) 224.0.0.2 for
neighbor discovery and to determine what IP address the ensuing TCP connection
should be made. Can optionally list a transport address in the Hello messages for
what ip address to use for the LDP ID for the TCP connections.
2. The TCP connections use unicast, so these destinations must be in the RIB.
3. LDP ID is chosen just like OSPF ID is chosen.
1. Configured
2. Highest of any up/up loopback when LDP comes up
3. Highest of any up/up non-loopback when LDP comes up
LDP Reference
LDP Feature
LDP Implementation
Transport protocols

UDP (Hellos), TCP (updates)

Port numbers

646 (LDP), 711 (TDP)

Hello destination address

224.0.0.2

Who initiates TCP connection

Highest LDP ID

TCP connection uses this address

Transport IP address (if configured), or LDP ID if

no transport address is configured

LDP ID determined by these rules, in order

or precedence

Configuration
Highest IP address of an up/up loopback when LDP
comes up
Highest IP address of an up/up non-loopback when
LDP comes up

4. f

II. MPLS VPNs

1. The Problem: Duplicate Customer Address Ranges
1. The diagram shows the issue with migrating to L3 WAN services for an SP. Many
customers are using the same private address space.

2.
3. The Solution: MPLS VPNs
1. Use multiple routing tables in a single router, called Virtual Routing and Forwarding
(VRF) tables, which separate customer routes.
2. MPLS three main terms to describe MPLS router roles
1. Customer edge (CE) - A router that has no knowledge of MPLS protocols and
does not send any labeled packets but is directly connected to an LSR (PE) in the
MPLS VPN.
2. Provider edge (PE) - An LSR that shares a link with at least one CE router,
thereby providing function particular to the edge of the MPLS VPN, including
IBGP and VRF tables
3. Provider (P) - An LSR that does not have a direct link to a CE router, which
allows the router to just forward labeled packets, and allows the LSR to ignore
customer VPNs' routes
3. Provider LSRs have no knowledge of customer routes and are pure provider IGP
LSR routers. PE routers are the routers that know about customer routes and use the
provider MPLS network to transport from an ingress PE to an egress PE router from
customer to customer; again using the provider network consisting the P routers
which know only the internal routing, and the PE routers which know of the internal
provider routing and also have separate routing tables for customer routes.
4. PE routers keep track of customer routes by connecting to customers via EBGP, RIP2, OSPF or EIGRP noting which routes are learned from which customers, keeping
them separate via multiple per-customer routing tables called VRFs. PEs use IBGP
(MP-BGP) to exchange these routes never advertising them to the internal provider
routers.

5. Diagram below - PE ingress routers; aside form keeping track of VRFs, customer
routing protocols and IBGP between PE routers must also push two labels
1. An outer MPLS header (S-bit = 0), with a label value that causes the packet to be
label switched to the egress PE
2. An inner MPLS header (S-bit = 1), with a label that identifies the egress VRF on
which to base the forwarding decision.

6. Diagram above steps

1. CE1 forwards an unlabeled packet to PE1.
2. PE1, having received the packet in an interface assigned to VRF-A, compares
the packet's destination (10.3.3.3) to the VRF-A CEF FIB, which is based on
VRF-A's routing table. PE1 adds two labels based on the FIB and forwards the
labeled packet.
3. P1, acting just the same as with unicast IP routing, processes the received labeled
packet using its LFIB, which simply causes a label swap. P1 forwards the packet
to PE2.
4. PE2's LFIB entry for label 2222 lists a pop action, causing PE2 to remove the
outer label. PE2's LFIB entry for label 3333, populated based on the VRF for
customer A's VPN, also lists a pop action for the outgoing interface. As a result,

PE2 forwards the unlabeled packet to CE2.

5. NOTE - Penultimate hop popping (PHP) is on by default which makes the
provider router pop the outer label before sending it on it's way to the egress PE
router. This allows the PE egress router to do less work.

4.
5. MPLS VPN Control Plane
1. Virtual Routing and Forwarding Tables
1. Each VRF has three main components, as follows:
1. An IP routing table (RIB)
2. A CEF FIB, populated based on that VRF's RIB
3. A separate instance or process of the routing protocol used to exchange routes
with the CEs that need to be supported by the VRF.

2. Steps above 1. The CE router, which has no knowledge of MPLS at all, advertises a route for
10.3.3.0/24 as normal - in this case with RIP-2.
2. In the top instance of step 2, the RIP-2 update arrives on PE2's S0/1/0, which has
been assigned to customer A's VRF, VRF-A. PE2 uses a separate RIP process
for each VRF, so PE2's VRF-A RIP process interprets the update. Similarly, the
VRF-B RIP process analyzes the update received on S0/1/1 from CE-B2.
3. In the top instance of step 3, the VRF-A RIP process adds an entry for
10.3.3.0/24 to the RIB for VRF-A. Similarly, the bottom instance of step 3
shows the RIP process for VRF-B adding a route to prefix 10.3.3.0/24 to the
VRF-B RIB.
2. MP-BGP and Route Distinguishers
1. IBGP is used (MP-BGP) to advertise routes for VRFs between PE routers. However
some customers will have overlapping routes, therefore the use of a Route
Distinguisher (address family).
2. RDs allow BGP to advertise and distinguish between duplicate IPv4 prefixes by
adding another number to the IPv4 prefix (RD).
3. The new NLRI format, called VPN-V4, has the following two parts:
1. A 64-bit RD
2. A 32-bit IPv4 prefix.

4. The above shows the following steps:

1. PE2 redistributes from each of the respective per-VRF routing protocol instances
(RIP-2 in this case) into BGP
2. The redistribution process pulls the RD from each respective VRF and includes
that RD with all routes redistributed from the VRF's routing table.
3. NOTE - Every VRF must be configured with an Route Distinguisher (RD); the
IOS rd VRF subcommand configures the value.
5. The RD itself is 8 bytes with some required formatting conventions. The first 2
bytes identify which of the three formats is followed. Incidentally, because IOS can
tell which of the three formats is used based on the value, the IOS rd VRF
subcommand only requires that you type the integer values for the last 6 bytes, with
IOS inferring the first 2 bytes (the type) based on the value. The last 6 bytes, as
typed in the rd command and seen in show commands, follow one of these formats:
1. 2-byte-integer:4-byte-integer
2. 4-byte-integer:2-byte-integer
3. 4-byte-dotted-decimal:2-byte-integer
6. In all three cases, the first value (before the colon) shoudl be either an ASN or an
IPv4 address. The second value, after the colon, can be any value you wish. For
example, you might choose an RD that lists an LSR's BGP ID using the third format,
like 3.3.3.3:100, or you may use the BGP ASN, for example, 432:1.
7. At this point in the ongoing example, PE1 has learned about the two routes for
10.3.3.0/24 - one for VPN-A and one for VPN-B - and the routes are in the BGP
table. The next section describes how PE1 then chooses the VRFs into which to add
these routes, based on the concept of a Route Target.

3. Route Targets
1. MPLS uses Route Targets to determine into which VRFs a PE places IBGP-learned
routes.
2. Route Targets are advertised with NLRI via Extended Communities.
3. One prefix can only have one RD, but can have one or multiple RTs.

4. Steps Above 1. The two VRFs on PE2 are configured with an export RT value
2. Redistribution out of the VRF into BGP occurs
3. This step simply notes that the export process - the redistribution out of the VRF
into BGP - sets the appropriate RT values in PE2's BGP table.
4. PE2 advertises the routes with IBGP.
5. PE1 examines the new BGP table entries and compares the RT values to the
configured import RT values, which identifies which BGP table entries should go
into which VRF.
6. PE1 redistributes routes into the respective VRFs, specifically the routes whose
RTs match the import RT configured in the VRFs, respectively.

4. Overlapping VPNs
1. By virtue of the RT concept, different sites could share certain routes, as shown
below. CE-A1 and CE-B2 both can access CE-Serv, however the other routers
cannot. This is accomplished by having at least two VRFs for Customer B, and two
VRFs for Customer A. CE-Serv, in this example, would simply need to import
routes from the VRF of CE-A1 and CE-B2 (the same VRF that is used to allow CEA1 and CE-B2 to have routes to CE-Serve, but not the normal customer VRF which
only has routes to other routers of the same customer.

5. g

6. MPLS VPN Configuration

1. What's already configured in the below diagram before going into MPLS VPN
configuration.
1. All links between P and PE routers are configured with IP addresses, the IP
addresses on the other end of each link is pingable, and these interfaces have
been enabled for frame mode MPLS with the mpls ip interface subcommand.
2. All P and PE routers use a common IGP (EIGRP with ASN 200 in this case),
with all loopbacks and subnets between the P and PE routers being advertised.
As a result, all P and PE routers can ping IP addresses of all interfaces on those
routers, including the loopback interfaces on those routers.
3. Between each PE and CE, IP addresses have been configured, and the links
work, but these subnets are not currently advertised by any routing protocol.
4. The PE router interfaces that connect to the CE routers do not have the mpls ip
interface subcommand, because these interfaces do not need to be MPLSenabled. (The mpls ip command tells IOS that IP packets should be forwarded
and received with an MPLS label.)
5. None of the features specific to MPLS VPNs have yet been configured.

2. Major areas of configuration to remember 1. Creating each VRF, RD, and RT, plus associating the customer-facing PE
interfaces with the correct VRF.
2. Configuring the IGP between PE and CE
3. Configuring mutual redistribution between the IGP and BGP
4. Configuring MP-BGP between PEs
1. The above configuration steps are also shown in the below diagram

7. f

1. Configuring the VRF and Associated Interfaces

1. PE routers are the only routers that need to be configured for MPLS VPNs, while the
P routers only know about MPLS unicast ip forwarding, and the customer routers
have no awareness of MPLS at all.
2. Description of the configuration steps below 1. Configuring the VRF with the ip vrf vrf-name command
2. Configuring the RD with the rd rd-value VRF subcommand
3. Configuring the RT with the route-target {import | export} rt-value VRF
subcommand
4. Associating an interface with the VRF using the ip vrf forwarding vrf-name
interface subcommand.
5. NOTE - The rout-target both command could be used instead of typing out
import and export. The configuration will show import and export though. Also,
the ip vrf forwarding interface subcommand actually removes the IP address
from the interface, so you will need to re-configure the ip address after issuing
the vrf command.

2. f

3. f

4. Configuring the IGP Between PE and CE

1. Configure an IGP or BGP between PE and CE routers.
2. CE router configuration is nothing special; however PE configuration is where all
the MPLS VPN configuration takes place.

3. Configuration steps for above 1. Configuring the EIGRP process, with an ASN that does not need to match the
CE router, using the router eigrp asn global command.
2. Identifying the VRF for which additional commands apply, using the addressfamily ipv4 vrf vrf-name router subcommand
3. From VRF configuration submode (reached with the address-family ipv4 vrf
command), configure the ASN to match the CE router's router eigrp asn global
command.
4. From VRF configuration submode, configure the network command. This
command only matches interfaces that include an ip vrf forwarding vrf-name

interface subcommand, with a VRF name that matches the address-family ipv4
vrf command.
5. From VRF configuration submode, configure any other traditional IGP router
subcommands (for example, no auto-summary, redistribute).

5. f

6. f

7. Configuring Redistribution Between PE-CE IGP and MP-BGP

8. f

9. f

10. f

11. f
12.
13. Configuring MP-BGP Between PEs
1.

14. f

15. f

16.

8. MPLS VPN Data Plane

9. f

10.
1. Building the (Inner) VPN Label
2. f

3.
4. Creating LFIB Entries to Forward Packets to the Egress PE
5. f

6.
7. Creating VRF FIB Entries for the Ingress PE
8. f

9.
10. Penultimate Hop Popping
11. f

12. f

13.

III. Other MPLS Applications

IV. VRF Lite
1. VRF Lite, Without MPLS
2. f

3. f

4. f

5.
6. VRF Lite with MPLS
7. f

8.