Understanding Traceroute (Part 3 of 4)

* * *s (or other equivalent 100% packet loss) in the route usually is not a sign of any problems

Certain hosts in the path will simply show a misleading 100% packet loss using applications such as Ping Plotter, which run a trace and then do multiple pings of each hop directly afterwards, despite the fact that often there is no packet loss; instead, the destination host may not be publicly routable. For example, the HopOne network that Superb uses exclusively is entirely secure, and its whole network device IP address space is not routable and not accessible from anywhere on the Internet (for security, performance, and DoS and intrusion mitigation measure); when pinging any of its routers using a traceroute imitation application, one will get apparent 100% packet loss. However, it is simply not reachable – e.g. result of a ping of a non-routable IP:

Reply from Destination host unreachable.

This does not indicate a problem – as the hops in-between the origin and destination host do not need to be accessible to either host – they only need to be accessible to each other, as they, of course, are, if the traceroute completes at the end host (if they were not, then the trace would not complete and would not reach the end host).

Using the real tracert/traceroute commands will overcome most (but not all) of these issues, and will usually show even those unreachable to plain ping hosts and the latency to them – something the traceroute imitation applications using plain ICMP ping are not able to do.

In short, the most important measure (unless the end host rejects ICMP ping and also real traceroutes due to its firewalling, as many major sites do – e.g. EBay2) is to see if the end host was reached without excessive latency or packet loss. If it is reached without problems appearing at the end host itself, then any apparent issues in the route in between are irrelevant, and may be due to low priority or rejection of ICMP ping requests in the route. Any issue seen in a traceroute that does not carry through to the end host (e.g. packet loss or increased latency) is not a real issue. Any issue that does carry through, however (that is, starts at one hop and happens at all the subsequent hops), may be an issue with the route.

If one prefers to use a traceroute imitation application, then it is suggested to still use the real tracert/traceroute command if the application shows some packet loss or latency issues somewhere in the route in between but not at the end host to verify if there really is an issue or if it is due to the limitations of the application being used.

Understanding Traceroute: A Four-part Series

Part 1: Traceroute can be used to measure performance

Part 2: Traceroute/tracert-like applications or commands will provide accurate results

Part 3: * * * s (apparent packet loss) somewhere in the route is always bad and a sign of problems

Part 4: A uni-directional traceroute (run only in one direction) can be used to accurately spot a problem area in a route

Tags from the story
Written By
More from Haralds Jass

Understanding Traceroute – A Four-part Series

There are a number of popular misconceptions and misunderstandings about traceroutes. Traceroutes...
Read More