tracepath and tracepath6 trace the path to a network host, discovering MTU and asymmetry along this path. As described below, their applicability for path asymmetry measurements is quite limited, but the tools can still measure MTU rather reliably.
Methodology and Caveats
A path is considered asymmetric if the number of hops to a router is different from how much TTL was decremented while the ICMP error message
was forwarded back from the router. The latter depends on knowing what was the original TTL the router used to send the ICMP error. The tools guess TTL values 64, 128 and 255. Obviously, a path might be asymmetric even if the forward and return paths were equally long, so the tool just catches one case of path asymmetry.
A major operational issue with this approach is that at least Juniper's M/T-series routers decrement TTL for ICMP errors they originate (e.g., the first hop router returns ICMP error with TTL=254 instead of TTL=255) as if they were forwarding the packet. This shows as path asymmetry.
Path MTU is measured by sending UDP packets with DF bit set. The packet size is the MTU of the host's outgoing link, which may be cached Path MTU Discovery for a given destination address. If a link MTU is lower than the tried path, the ICMP error tells the new path MTU which is used in subsequent probes.
As explained in tracepath(8), if MTU changes along the path, then the route will probably erroneously be declared as asymmetric.
This example shows a path from a host with 9000-byte "jumbo" MTU support to a host on a traditional 1500-byte Ethernet.
The router (interface)
swiCS3-P1.switch.ch occurs twice; on the first line (hop 4), it returns an ICMP TTL Exceeded error, on the next (hop 5) it returns an ICMP "fragmentation needed and DF bit set" error. Unfortunately this causes
tracepath to miss the "real" hop 5, and also to erroneously assume that the route is asymmetric at that point. One could consider this a bug, as
tracepath could distinguish these different ICMP errors, and refrain from incrementing TTL when it reduces MTU (in response to the "fragmentation needed..." error).
When one retries the
tracepath , the discovered Path MTU for the destination has been cached by the host, and you get a different result:
Note that hop 5 now shows up correctly and without an "asymm" warning. There is still an "asymm" warning at the end of the path, because a filter on the last-hop router
swiLM1-V610.switch.ch prevents the UDP probes from reaching the final destination.
Here is the same path for IPv6, using
tracepath6 . Because of more relaxed UDP filters, the final destination is actually reached in this case:
Again, once the Path MTU has been cached,
tracepath6 starts out with that MTU, and will discover the correct path:
- Debian package:
iputils-tracepath - Tools to trace the network path to a remote host
- http://www.linuxmanpages.com/man8/tracepath.8.php - online
- http://puck.nether.net/pipermail/juniper-nsp/2005-May/004320.html - Juniper tracepath issues. Note that the mail in error says 'decrements twice' instead of 'decrements once'
-- Main.FrancoisXavierAndreu & Main.SimonMuyal - 06 Jun 2005
-- Main.SimonLeinen - 26 Feb 2006
-- Main.PekkaSavola - 31 Aug 2006