Monday, 7 October 2013

Basic Configuration Of MPLS

I would like to share a basic MPLS configuration example where I will explain how MPLS works and what are the different steps in order to configure it. This example is not related to MPLS layer 3 VPNs, this is just going to be the basic underlying logic of how an MPLS tunnel on its own works so I will neither talk about VRF nor MP-BGP which is the VPNv4 address family in order to exchange the customer routes and the MPLS VPN labels.

 Let´s consider the following topology:


PE routers R2 and R4
P router: R3
CE routers R1 and R5

MPLS router functionality is divided into two major parts: The control plane and the data plane.

    At the control plane we have the following protocols in this topology OSPF, BGP and LDP. OSPF is the core IGP which is the base for building the EBGP session between R2 and R4 but also in order for LDP to associate a label to each learned OSPF prefixes in the core. LDP uses the LIB and the LFIB. The LIB is at the control plane and it is the database used to stored prefix/label binding advertised and received by LDP where an IP prefix is assigned a locally significant label that is mapped to a next-hop label that has been learned from a neighbour.

    At the data plane we have the LFIB (Label Forwarding Information Base) and the FIB. The LFIB is used to forward packets based on labels. LDP adds labels to the FIB and the LFIB which means that when a PE router receives an unlabeled packet it will consult its FIB and send the packet as labeled based on the FIB content. On the other hand when a P router receives a labeled packet it will only use its LFIB to forward it.

Let´s enable MPLS on the R2, R3, R4 core interfaces. As soon as we enable MPLS each adjacent router discover each other through LDP (default ). From the debug mpls ldp bindings on R2 we can see the following output:


From the above output we can see that R2 is advertising the labels for all the prefixes it has in its routing table. All the connected routes of R2 like its loopback will be advertised with encoded label of 3. This label instructs upstream routers to remove the label instead of swapping it. What will be displayed in the routing table of the neighbor router will be “imp-null” rather than the value 3 or 1 for TDP. R2 also receives labels information from its LDP neighbor R3 where for example R3 advertises label 17 for prefix 4.4.4.4/32 which is the loopback of R4.

By default LDP peers will advertise a label/prefix binding for all the routes present in the routing table. We can see that from the above output because R2 is advertising LDP entries for networks that it has learned from R3 (for example 4.4.4.4/32 and 10.0.34.0/24).

 Let´s look at the LFIB of R2 now and see which labels it has learned from R3:
 
 10.0.34.0/24 prefix is associated with a Pop tag action which means that all traffic forwarded to this prefix should not be labeled by R2. R2 has been instructed to do that by R3 in the LDP labels exchange process (see the first output where R3 tells R2 that 10.0.34.0/24 should be associated with out label imp-null -> labels for: 10.0.34.0/24; nh 10.0.23.3, Fa0/1, inlabel 18, outlabel imp-null (from 3.3.3.3:0). The Pop tag action means that Penultimate Hop Popping mechanism is in use. PHP optimizes MPLS performance as it eliminates one LFIB lookup, in this case on R4. So R4 will only do a FIB lookup and not a LFIB lookup first and then a FIB look up.













0 comments:

Post a Comment