Working through my MPLS labs for my IE studies I came across this little tidbit of information. I like to keep track of these one liners(or generally small sections of information) in all of the documentation that I read, because they seem to be incredibly helpful once committed to memory.
This particular nugget has to do with TTL propagation within an MPLS cloud, from a provider’s perspective. I trust anyone with enough interest in reading this post has experience with the TTL field and how the traceroute command utilizes this header information within a network.
We’ll start with how MPLS handles TTL propagation for the traffic being forwarded within the MPLS cloud. 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 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 E-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 that value to the header of the IP packet that will be forwarded on.
That being said, Service Providers are usually providing some sort of L3 WAN services, and their customers sit outside of their MPLS network. The result of the traceroute command with MPLS’s default configuration allows for customers to see every LSP in the path that one of their packets traverses. This can cause some headache for them, as they don’t need to know what the provider’s topology consists of, but it also poses potential security issues for the SP 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 are present in the output. Again, it may be that the SP doesn’t want to customer to have that type of insight into their network, or the customer doesn’t want to see the LSP’s while attempting to troubleshoot issues.
Thankfully, Cisco grants us the ability to surpress the TTL propagation functions of traffic within the MPLS network. We can use the no mpls ip propagate-ttl [local | forwaded] command to surpress the copying of the TTL from the IP packet’s header. When this command is issued, the ingress E-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 seen below :
1 192.168.15.1 28 msec 36 msec 16 msec
2 192.168.37.6 108 msec 108 msec *
Now, let’s step back to the command again for a minute. I referenced the options at the end of the command to local or forwarded. What this means is, is that the TTL propagation can be disabled either from ingress customer traffic, or locally originated traffic from the LSR’s within the MPLS cloud. The local option references traffic originated by the LSR itself. Such as when a SP engineer logs into a router and issues the traceroute command, this would allow the SP engineer insight into 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.