I have written about MPLS in my previous blogs but this time I want to highlight one crucial concept in case of MPLS within Service Provider environment. I hope you already know how TTL (Time to Live) works in IP network and its usage in helping the network by disallowing any mis-routed packet to loop indefinitely inside the Service Provider or Enterprise Network. Plus we know Traceroute command also uses TTL functionality to get the Intermediate hops towards the destination.
As you must know that inside MPLS environment we don’t use any IP functionality and IP packets gets encapsulated with MPLS packets. There is one TTL field which is part of IP Packet Header and when IP packets from customer comes to Service Provider; those IP packets gets encapsulated with MPLS packets and IP TTL fields gets hidden. Then how TTL in this case will prevent the Loop in MPLS environment? MPLS needs a loop prevention mechanism as does any other forwarding protocol. And instead of having to modify the IP header of every packet that passes through an interface on an LSR (Label Switch Router like P and PE) within the cloud, “it copies the IP packet’s TTL header information into a new label being pushed onto the IP packet” as it enters the MPLS cloud; Thus preventing having to touch the IP header information on the ingress packets.
As the packet traverses the MPLS cloud, each LSR will decrement the TTL within the MPLS header, just like in a typical IP network. As the packet reaches the egress Edge LSR, the E-LSR will pop the label on that packet, subtract the cost of one interface (the egress interface) from the current TTL value, and then apply/copy that value to the header of the IP packet that will be forwarded on.
Service Providers are usually providing some sort of L3 services, and their customers sit outside of their MPLS network. The result of the traceroute command with MPLS’s default configuration (i.e. copy of IP TTL to MPLS TTL field) allows for customers to see every next-hop in the path that one of their packets traverses. This can cause some headache for customers, as they don’t need to know what the provider’s topology consists of, but it also poses potential security risk for the Service Provider themselves.
The output below shows what it looks like for a customer to run the traceroute command with the default TTL copy behavior of MPLS.
1 192.168.15.1 44 msec 12 msec 24 msec
2 192.168.14.4 [MPLS: Labels 16/16 Exp 0] 80 msec 496 msec 88 msec
3 192.168.37.3 [MPLS: Label 16 Exp 0] 48 msec 60 msec 48 msec
4 192.168.37.6 56 msec 60 msec *
As you can see, the LSP’s or next-hops are present in the output. Again, it may be that the SP doesn’t want the customer to have that type of insight into their network, or the customer doesn’t want to see the next-hops while attempting to troubleshoot issues.
Thankfully, we have one solution. Under Cisco IOS we can use the “no mpls ip propagate-ttl [local | forwaded]” command to suppress the copying of the TTL from the IP packet’s header. For Junos no-propagate-ttl under protocol mpls does the same thing. When this command is issued, the ingress Edge LSR will assign a generic TTL value of 255 to the label, instead of copying the IP packet’s current TTL.
As a result, the entire MPLS network will look as though it is just a single hop to the customer. As you can see below 🙂
1 192.168.15.1 28 msec 36 msec 16 msec
2 192.168.37.6 108 msec 108 msec *
The “local” option in the command above references traffic originated by the LSR itself. Such as when a Service Provider’s engineer logs into a router and issues the traceroute command, this would let SP engineer to see the LSR’s within the MPLS cloud. Whereas the forwarded option pertains to traffic that is originated external to the MPLS cloud, usually within the customer sites.
So, that’s all for MPLS TTL, I hope you have liked this blog 🙂