Chapter 19: Multiprotocol Label Switching

I. MPLS Unicast IP Forwarding1. 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 Forwarding1. 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.32. 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 LFIB1. 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 Label1. 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) 3 Used for QoS marking; the field is no longer used for truly experimental purposes

Bottom-of-Stack (S) 1 Flag, which when set to 1, means that this is the label immediately preceding the IP header.

Time-to-Live (TTL) 8 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 LFIB1. 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 label1. 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 Entries1. 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 Reference1. 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. Configured2. Highest of any up/up loopback when LDP comes up3. Highest of any up/up non-loopback when LDP comes up

LDP ReferenceLDP Feature LDP ImplementationTransport protocols UDP (Hellos), TCP (updates)Port numbers 646 (LDP), 711 (TDP)Hello destination address 224.0.0.2Who initiates TCP connection Highest LDP IDTCP connection uses this address Transport IP address (if configured), or LDP ID if

no transport address is configuredLDP 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 VPNs1. 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 roles1. 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, RIP-2, 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 labels1. An outer MPLS header (S-bit = 0), with a label value that causes the packet to be

label switched to the egress PE2. 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 steps1. 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 Tables1. Each VRF has three main components, as follows:

1. An IP routing table (RIB)2. A CEF FIB, populated based on that VRF's RIB3. 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 Distinguishers1. 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 RD2. 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 BGP2. 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-integer2. 4-byte-integer:2-byte-integer3. 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 Targets1. 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 value2. Redistribution out of the VRF into BGP occurs3. 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 VPNs1. 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 CE-A1 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 Configuration1. 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 MPLS-enabled. (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 CE3. Configuring mutual redistribution between the IGP and BGP4. 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 Interfaces1. 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 command2. Configuring the RD with the rd rd-value VRF subcommand3. Configuring the RT with the route-target {import | export} rt-value VRF

subcommand4. 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 CE1. 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 address-

family ipv4 vrf vrf-name router subcommand3. 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-BGP8. f

9. f

10. f

11. f12.13. Configuring MP-BGP Between PEs

1.

14. f

15. f

16.8. MPLS VPN Data Plane9. f

10.1. Building the (Inner) VPN Label2. f

3.4. Creating LFIB Entries to Forward Packets to the Egress PE5. f

6.7. Creating VRF FIB Entries for the Ingress PE8. f

9.10. Penultimate Hop Popping11. f

12. f

13.

III. Other MPLS ApplicationsIV. VRF Lite

1. VRF Lite, Without MPLS2. f

3. f

4. f

5.6. VRF Lite with MPLS7. f

8.