LSP Traceroute
We saw in the previous article, that if there is a break anywhere in an LSP, the LSP ping will not succeed. However the LSP ping will not tell us exactly where the break is.
LSP traceroute uses the same MPLS echo requests and replies as LSP ping. LSP traceroute increments the TTL value, starting at 1, just like the regular traceroute utility. The big difference between LSP traceroute and LSP ping is that LSP traceroute is also concerned with knowing each hop’s downstream mapping. Think of the downstream mapping as the outgoing label stack and forwarding information. You may seen downstream mapping also called DSMAP. Each hop that generates an MPLS echo reply TTL exceeded message includes its own downstream mapping information. This allows you as the operator to visually see the MTU and label stack information at each hop in your traceroute results.
Lab
We’ll use the same topology as before:
Currently our LSP is fully functional. Let’s run an mpls traceroute to see what the expected behavior is. Just like mpls ping, you must specify a target FEC, not an IP address.
MPLS traceroute shows the 0th hop, which is the local router’s downstream mapping information. MRU stands for Maximum Receive Unit. This is the max size of a labeled packet that can be forwarded, including the label headers. The penultimate hop should have a label value of “implicit-null” which explicitly shows us that it is preforming PHP.
We can see that this router’s own outgoing label is 19 at index=0. The 1st hop (index=1) is P3, and its own FIB entry swaps 19 for 24003. So its downstream mapping is label 24003, which we see in the traceroute output.
When we get to PE2 at 10.2.4.2, it is the originator of 2.2.2.2/32, so it has no downstream mapping. The traceroute stops at that point.
Here is a capture of the MPLS echo request with TTL set to 1, captured at the PE1-P3 link:
Just like the LSP ping, the IPv4 destination is 127.0.0.1
The MPLS TTL is 1
The own router’s downstream mapping is included in the Echo Request
This is included so that the receiving router can verify it received the packet on the correct interface and with the correct label for the FEC. Basically it allows the next-hop router to verify that it is the intended node.
This changes as the TTL is incremented. When TTL=1, the downstream mapping is the local router’s own mapping. The first hop router replies with its own downstream mapping to the local router. The local router then uses this received downstream mapping and uses it for the echo request with TTL=2. That way the second hop router receives the request with the first hop router’s downstream mapping, and the second hop router can verify it is the intended node for the LSP. This process continues as the TTL increments.
Here is a capture of the MPLS echo reply from P3 to PE1:
P3 includes its own downstream mapping information (MTU, label, next-hop router 10.3.4.4)
The reply is IP forwarded, with the source interface set to the interface address that received the TTL=1 packet. Just like LSP ping, LSP traceroute only verifies the unidirectional LSP.
Breaking the LSP
Let’s bring LDP down between P4 and PE2 again, and test LSP traceroute when the LSP is broken.
Here we see one annoying thing about LSP traceroute. If the LSP is broken, the traceroute will continue until hop 30 by default. We can specify a max TTL value to avoid this:
Why is every last hop P4? This is because P4 has an unlabelled entry for 2.2.2.2/32, so it continually returns an error code no matter how high the TTL goes.
Here is P4’s Echo Reply:
You can see that there is no label information under the downstream mapping section
LSP traceroute tells us where the LSP is broken, which we could not figure out with LSP ping alone. We see that the 0th hop and 1st hop have label values. However the 2nd hop, P4 shows no label, and a code of B indicated unlabaled output interface. With LSP ping, we saw five Bs but no indication of which hop sent the error. With LSP traceroute we can see that the first hop has code L (labeled output interface) as normal, and P4 specifically is the one sending the B error code.
Using LSP ping to verify MTU
Let’s re-enable LDP between P4 and PE2 again.
With LSP traceroute, you cannot specify the size, I believe largely because there is so much information contained in the DSMAP field.
However, with LSP ping we can verify end-to-end MTU. Currently all links have the default MTU of 1500. What is the maximum LSP ping size that will succeed?
The answer is 1496. The four bytes of the MPLS header count towards the total MTU.
The Q error code indicates request not sent. PE1 did not even attempt to send the packet out its egress interface, and the packet size is too large. Let’s set MTU on PE1 to 1508, which will allow two MPLS headers, and see what the error code is in that case. We must also set MTU on P3 so that OSPF stays up.
The LSP pings are simply timing out now. If we run an LSP traceroute, we can easily see the MTU of every outgoing interface in the path.
There is one interesting difference in MTU behavior with IOS-XR. When you set the MTU to a value that is not 1500, the router appears to subtract 14 bytes, the size of an ethernet header, from the MRU value.
To see this, set P4 and PE2 to mtu 1508 on their Gi0/0/0/1 links:
If we run the LSP traceroute again, the MTU at the P4 hop is 1494 (1508-14).
Interestingly, the LSP ping with size 1496 no longer works. The largest ping size is now 1494.
This is just something to be aware of when operating IOS-XR routers in your core. In IOS-XR, the mtu command configures the MTU including the L2 header. This is why the router subtracts 14 bytes from the MRU. In IOS-XE, the mtu command configures the MTU without including the L2 header. The default interface MTU in IOS-XR is actually 1514.
What we really wanted to do when we set MTU to 1508 is actually set the mpls mtu to 1508. This allows an IPv4 packet up to 1500 bytes with two mpls header. In order to accomplish this on IOS-XR it is a little confusing. You have to set the interface overall MTU to 1500 + 14 + 8 (ethernet header plus two MPLS headers), and then manually reduce the ipv4 MTU down to 1500. Otherwise IPv4 packets could take up that 8 bytes we are allocating for MPLS.
Strangely the MRU is still 1500 in the LSP traceroute. This may be an issue with XRv.
See this article for more information: https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-xr-software/116350-trouble-ios-xr-mtu-00.html
Conclusion
In this article we explored LSP traceroute and saw how it provides downstream mapping information at each hop. It uses the same MPLS request and reply messages as LSP ping, but adds additional information which helps with troubleshooting. With LSP traceroute, you can see the exact hop that an LSP fails, and you see an error code that tells you why it failed. Additionaly the outgoing interface MTU is included at each hop, enabling you to troubleshot end-to-end LSP MTU. The outgoing mapping information generated at each hop is based on that hop’s outgoing interface if it were to continue to send the packet down the LSP.
Last updated