``Traceroute'' is a network debugging utility that attempts to trace the path a packet takes through the network - its route. A key word here is ``attempts'' - by no means does traceroute work in all cases.
If you've been paying attention, you already know that the only facilities TCP/IP provide for tracing packet routes are IP packet options (record route and its variants) that are poorly specified, rarely implemented in a useful way, and often disabled for security reasons. Traceroute does not depend on any of these facilities. Traceroute, to put it simply, is a hack.
Traceroute transmits packets with small TTL values. Recall that the TTL (Time To Live) is an IP header field that is designed to prevent packets from running in loops. Every router that handles a packet subtracts one from the packet's TTL. If the TTL reaches zero, the packet has expired and is discarded. Traceroute depends on the common router practice of sending an ICMP Time Exceeded message, documented in RFC 792, back to the sender when this occurs. By using small TTL values which quickly expire, traceroute causes routers along a packet's normal delivery path to generate these ICMP messages which identify the router. A TTL value of one should produce a message from the first router; a TTL value of two generates a message from the second; etc.
+--------+ +--------+ | SENDER | | TARGET | +--------+ +--------+ | ^| [============( Router )=====( Router )=====( Router )==|====] ^ ^ ^ | | TTL=1 | TTL=2 | TTL=3 | TTL=4 Traceroute | | | | shows these -----+--------------+--------------+------------/ IP addresses
In a typical traceroute session, a group of packets with TTL=1 are sent. A single router should respond, using the IP address of the interface it transmits the ICMP Timeout messages on, which should be the same as the interface it received the original packets on. The user is told this IP address, and DNS is used to convert this into a symbolic domain address. Also, round trip times are reported for each packet in the group. Traceroute reports any additional ICMP messages (such as destination unreachables) using a rather cryptic syntax - !N means network unreachable, !H means host unreachable, etc. Once this first group of packets has been processed (this can take 10 seconds or no time at all), the second group (TTL=2) begins transmitting, and the whole process repeats.
Since TCP/IP was not designed to support traceroute, several kinds of problems might arise.
Here's a list of common traceroute options:
All of the sites along this path can be converted to symbolic names using inverse DNS lookups. Although the details don't all make sense, we can get the general picture. We start on our local net and quickly move to SprintLink. At San Francisco, we switch to MCI for the transcontinental jump to Washington, where we move to SURA, the Southeastern University Research Association, which provides service to the University of Maryland. The wild fluctuations in round trip time are interesting (compare hop 2 with hop 8). Why should an 8-hop trip be faster than a 2-hop trip? Remember that every time measurement corresponds to a different packet. The fluctuations are probably the result of changing network load.
access$ traceroute terp.umd.edu traceroute to terp.umd.edu (220.127.116.11), 30 hops max, 40 byte packets 1 cisco (18.104.22.168) 3.08 ms 2.391 ms 2.653 ms 2 sl-stk-3-S17-128k.sprintlink.net (22.214.171.124) 232.955 ms 195.828 ms 309.079 ms 3 sl-stk-5-F0/0.sprintlink.net (126.96.36.199) 187.623 ms 24.72 ms 24.545 ms 4 icm-fix-w-H2/0-T3.icp.net (188.8.131.52) 28.927 ms 27.511 ms 34.684 ms 5 fix-west-cpe.SanFrancisco.mci.net (184.108.40.206) 124.641 ms 225.516 ms 192.667 ms 6 border3-hssi2-0.SanFrancisco.mci.net (220.127.116.11) 127.727 ms 29.322 ms 30.108 ms 7 core-fddi-0.SanFrancisco.mci.net (18.104.22.168) 227.059 ms 112.441 ms 29.868 ms 8 core-hssi-2.Denver.mci.net (22.214.171.124) 52.881 ms 53.632 ms 53.18 ms 9 core-hssi-3.Washington.mci.net (126.96.36.199) 93.393 ms 120.491 ms 92.691 ms 10 border1-fddi0-0.Washington.mci.net (188.8.131.52) 242.042 ms 94.312 ms 265.366 ms 11 suranet-cpe.Washington.mci.net (184.108.40.206) 193.482 ms 224.183 ms 93.427 ms 12 wtn8-wtn-cf.sura.net (220.127.116.11) 105.636 ms 92.919 ms 93.663 ms 13 sura9-wtn8-c3.sura.net (18.104.22.168) 92.88 ms 92.708 ms 98.033 ms 14 sura2-sura-ce.sura.net (22.214.171.124) 105.182 ms 115.759 ms 130.195 ms 15 umd-sura2-c1.sura.net (126.96.36.199) 132.248 ms 145.699 ms 182.908 ms 16 csc1hub-gw.umd.edu (188.8.131.52) 168.827 ms 192.669 ms 191.198 ms 17 terp.umd.edu (184.108.40.206) 118.98 ms 156.011 ms 160.125 ms access$