There are a number of popular misconceptions and misunderstandings about traceroutes. Traceroutes are used by computer networks, small ones like in your office or large-scale ones like the Internet, to determine which route will be taken by packets (a block of data) sent across IP (Internet Protocol suite) networks. Traceroutes are often used for network troubleshooting; by reviewing the path taken, it is possible to find out problems with routing or firewalls that might be blocking access.
In this four-part series, I will go through four common misconceptions about traceroute:
- Traceroute can be used to measure performance.
- Traceroute/tracert-like applications or commands will provide accurate results.
- * * * s (apparent packet loss) somewhere in the route is always bad and a sign of problems.
- A uni-directional traceroute (run only in one direction) can be used to accurately spot a problem area in a route.
Each of these points will be addressed in an individual post, and will help provide a better understanding of traceroute and related concepts.
These articles should help dispel the popular myths and misunderstandings about traceroutes, traceroute-like applications, and related (simple) performance measurement. If you have any questions or comments on this, please feel free to leave such in the comments area.
1 Beware of some companies who list uni-directional latency in their SLAs, as unfortunately a few do, hoping to mislead their prospective customers. Typically in SLAs latency will be bi-directional (time for packets to travel there and back), as seen in a traceroute. However, some may represent only ½ of the actual time, only half of the trip (in one direction only, not returning – as is, of course, required, for any two way communications, such as sending a web request and receiving the data back, or playing an online game), thus making their SLA seem ‘better” than that of others with “lower guaranteed latency.”
2 While Ebay is reachable (using a web browser), its whole internal network is set-up to reject all types of ping and traceroutes (doubtlessly due to constant hack-in and attack attempts, ebay does not want any of its network topology or hosts to be publicly known). In these two traceroutes, we see the route going on the origin networks (hopone.net and shawcable.net, respectivley) to their router on which they peer with ebay, and all being “in the dark” (* * *) after that, both using a *nix traceroute (first) and Windows tracert (second).
traceroute to hp-core.ebay.com (188.8.131.52), 64 hops max, 40 byte packets
1 vl102-d2.acc.sea2.hopone.net (184.108.40.206) 0.337 ms 0.251 ms 0.306 ms
2 ge6-0.core2.sea2.hopone.net (220.127.116.11) 0.194 ms 0.156 ms 0.147 ms
3 ge6-0.core1.sea2.hopone.net (18.104.22.168) 0.200 ms 0.162 ms 0.164 ms
4 pos3-1.core1.pao1.hopone.net (22.214.171.124) 22.565 ms 22.532 ms 22.542 ms
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
Tracing route to hp-core.ebay.com [126.96.36.199]over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms fw.yvr1.superb.net [188.8.131.52]
2 3 ms 3 ms 3 ms ra1wh-ge4-3-12.vc.bigpipeinc.com [184.108.40.206]
3 3 ms 3 ms 3 ms rc1wh-ge1-2-0.vc.shawcable.net [220.127.116.11]
4 7 ms 6 ms 6 ms rc2wt-pos7-0.wa.shawcable.net [18.104.22.168]
5 27 ms 27 ms 27 ms rc1sj-pos1-0-0.cl.shawcable.net [22.214.171.124]
6 28 ms 27 ms 28 ms rc2sj-ge1-0-0.cl.shawcable.net [126.96.36.199]
7 * * * Request timed out.
8 * * * Request timed out.
9 * * * Request timed out.
10 * * * Request timed out.
3 Latency is governed by the same laws of physics as everything else in our universe. In this particular instance, by the speed of light [going over fibre], that, of course, ties in with the distance the light has to travel. It is also important to keep in mind that Internet links are almost never direct, and typically travel along railroad tracks from one major city to another, so same as driving is not direct, so are Internet packet routes indirect. Think of Internet packets as taking multiple transfer trains, vs. flying in a direct line from point A to point B.As a guideline, one can typically expect, with a good and fairly direct route, the following latencies (anything 20-40% higher than these is a cause for concern, and likely a poor more than normally indirect route):
East Coast <-> West Coast North America: 70ms – 90ms
East Coat N.A. <-> Western Europe: 70ms – 80ms
Within Europe: up to 40ms (depending on the distance)
West Coast N.A. <-> East Asia: 100ms (Japan, closest) – 160ms Taiwan, Hong Kong,
For example, from a peer of hopone.net in Australia to a server of ours in
traceroute to slsdemo.dca2.superb.net (188.8.131.52), 30 hops max, 38 byte packets
1 gigabitethernet2.bb1.a.suv.aarnet.net.au (184.108.40.206) 0.212 ms 0.181 ms 0.115 ms
2 so-3-3-0.bb1.a.syd.aarnet.net.au (220.127.116.11) 36.220 ms 36.200 ms 36.221 ms
3 so-2-1-0.bb1.a.pao.aarnet.net.au (18.104.22.168) 193.410 ms 193.333 ms 193.380 ms
4 ge4-0-6.core1.pao1.hopone.net (22.214.171.124) 193.495 ms 193.659 ms 193.445 ms
5 ge4-0-4.core1.iad1.hopone.net (126.96.36.199) 271.970 ms 271.971 ms 271.759 ms
6 ge6-1.core1.dca2.hopone.net (188.8.131.52) 270.976 ms 271.061 ms 271.106 ms
7 vl2.msfc1.distb2.dca2.hopone.net (184.108.40.206) 272.923 ms 272.796 ms 272.850 ms
8 220.127.116.11 (18.104.22.168) 272.544 ms 272.417 ms 272.724 ms
Interpreting the route:
hop 1: <1ms to local gateway
hop 2: 36ms for latency from Suva, Australia to Sydney, Australia on the AARNet network
hop 3: 157ms from Sydney, Australia to Palo Alto, California on the AARNet networkhop 4: <1ms from AARNet Palo Alto, CA to HopOne Palo Alto, CA
hop 5: 78ms from Palo Alto, CA to Ashburn, VA on the HopOne network
hop 6: 2ms from Ashburn, VA to McLean, VA on the HopOne network
hops 7-8: <1ms within the DCA2 data center (from router to distribution switch to end server)This is near a perfect route, that has no packet loss, and has close to ideal latencies given the distance traveled.
Note: The number of hops in a route typically does not make a difference and is largely irrelevant to performance and reliability. Often routes with less hops will be using MPLS to “hide” the extra hops in the way (e.g. GlobalCrossing is well known for doing that), though there are still more hops there in the background (more segments the route takes that are not shown in the trace). Both networks that show all the hops in the routes (such as ELI, Verio, Sprint, etc.) and ones that don’t (such as GlobalCrossing, and often but not always UUnet and Level 3) perform generally equally, it is simply a different network set-up methodology, but neither is superior to the other. It should be noted, however, that the hopone.net network shows all the hops in the route, without using MPLS to hide them, yet it is designed in a highly efficient way to minimize single points of failure and maximize efficiency, and almost all the sites reach each other directly, thus ensuring the highest number of redundant paths and the highest possible reliability, redundancy and performance.