In the first part of this blog, we have already discussed MPLS, its benefits, and the terminologies which are used in MPLS. In this article, we will continue with the remaining below pointers:
i) MPLS Architecture & Packet Flow
ii) Several Applications used in MPLS
iii) Prerequisite for Configuring MPLS
MPLS Architecture & Packet Flow
In the above MPLS architecture, we can see those two customers i.e. Customer 1 & Customer 2 are connected to Provider Edge (PE) router in both locations. There are multiple core routers (LSR) deployed between both LER in the MPLS domain.
Now, we will see next how Customers 1&2 from site A do communicate with their respective branches which are deployed in Site B.
In the above topology, we have assumed a scenario where Customer 1 is connected to Provider Edge (PE) router on both locations. The mentioned subnets are being used in this scenario. OSPF is running between all the ISP routers to exchange their prefixes to each other. Thus, all the mentioned prefixes will get updated in the global table of each router.
Now, we will see that how MPLS-enabled routers perform label tagging for the prefixes updated into their global routing table.
Once the label is tagged for the prefixes, these prefixes also get distributed to other adjacent LSR routers with the help of LDP (LDP protocol will be responsible for distributing labeled prefixes to all LSR).
The following LIB & FLIB routing table will be formed by LSR routers:
Acronym
L – Local Label
R – Remote Label
Note: In the LFIB table, no directly connected prefixes will be updated. Also, only the best prefix with the remote label will be updated. The best prefix will be determined by the next hop reachability.
In the above FLIB table, we can see that there is no label tagged for prefix 40.0.0.0/24 on R4. Hence, when R3 will switch the packet to R4, R4 will look up its FLIB table for the remote label of 40.0.0.0/24 prefix to switch the packet. But, when R4 will not find any remote label for 40.0.0.0/24 in its FLIB table, it will look up its CEF table for the best match of the prefix. Here, R4 looked up two routing tables, one FLIB and then CEF. Hence, the recursive look-up occurred.
To prevent this recursive lookup, there is a PHP feature. This PHP functionality uses the “implicit null label” for directly connected prefixes. When the adjacent LSR receives a prefix tagged with “implicit null”, the adjacent LSR will tag that prefix with “POP” and update it into its LIB & FLIB table. POP means, the label has to be removed from the prefix.
Thus, when an LSR router receives a packet without any label, it directly goes to look up into its CEF table and hence no recursive lookup happens. Hence, now the LSR will look up into the CEF table only for directly connected prefixes.
The following LIB & FLIB table will be formed with PHP:
Acronym
Null 0 – Implicit Null Label
Now, the LSR routers have updated their LIB & FLIB table accordingly. Next, we will see how an MPLS packet gets switched over the MPLS domain.
MPLS Packet Flow
AS we know, the MPLS packet uses a label to switch the packets. So, the first thing we need to know is MPLS Label.
An MPLS label is a 20 bit in range.
MPLS Label Range: 0-1048575.
These MPLS label ranges are further segmented as below:
Reserved Label Range: 0-15
Static Label Range: 16-32783 & 321535-331774.
Dynamic Label Range: 32784-321535 & 524288-1048574. These labels are used by dynamic protocol i.e. LDP, RSVP-TE, MP-BGP, IGP.
Other Feature: 331776-524287. These label ranges are used for other features.
MPLS Packet Switching between LSR
In this section, we will see that how an MPLS packet gets switched over LSR. In the above diagram, Customer 1 (Site A) wants to communicate with Customer 1 (Site B).
The following steps will be involved:
Step-1: The below packet will be encapsulated by customer 1 at Site A.
Step-2: PUSH when this packet will be received on ingress LER (R1), the LER will look into its routing table for the best match of the destination IP. Since MPLS is enabled on each LSR, the ingress LER will look into its FLIB table for switching the packet to its adjacent LSR.
In the above LFIB table, we can see that the label value 25 will be used for the prefix 40.0.0.0/24 by
R1.
Note: The TTL value of the IP header will be copied to the MPLS header while generating the MPLS packet.
Step-3: SWAP when this packet will reach on R2, R2 will just look up the MPLS header after de-encapsulating layer 2. R2 can see the label value 25 for 40.0.0.0/24 prefix as a local label into its LIB table. Hence, R2 will look up the remote label value for prefix 40.0.0.0/24 into its LFIB table. In the LFIB table, the remote label value for the 40.0.0.0/24 prefix is 30.
Here, the R2 will swap the label by removing the older label value 25 and add label value 30 and switch the packet to R3.
Step-4: POP when the packet will reach on R3, R3 will look up into its LIB table. The label value 30 for the prefix 40.0.0.0/24 is present in its LIB table. Hence, R3 will look for remote label tagging for the 40.0.0.0/24 prefix. In the LFIB table, R3 will see “POP” for the 40.0.0.0/24 prefix. That means the label has to be removed from the packet. Thus, the label will be removed from the packet and forwarded to R4 just as a normal IP packet.
Note: The TTL value of the MPLS header will be copied to the TTL value of the IP header.
Step-5: When this packet will be received on egress LER (R4) without any label, R4 will directly look up the CEF table for the 40.0.0.0/24 prefix and forward it to the destination IP 40.0.0.1.
Step-6: The vice-versa label-based switching will be followed when the traffic will come from Site B to Site A.
In this blog, we have seen a general MPLS architecture. We also understood, how MPLS uses the label to switch the packet, how LIB & FLIB tables are created by LSR routers and how recursive lookup can be prevented on LSR. We have learned about MPLS label ranges as well.
In the next blog, we will be discussing what several applications are used in the MPLS network and what are the prerequisites for configuring MPLS. You can reach out to us at +919773973971.
Author
Sani Singh
Consultant – Enterprise Networking
