TraceRoute

``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.

How Traceroute Works

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.

Problems you might encounter

Since TCP/IP was not designed to support traceroute, several kinds of problems might arise.

Changing paths

Always remember - you are not tracing the path of one packet, but of many. Hopefully, all those packets will follow the same route, but this is by no means assured. What if a link fails during the traceroute? Your packets may be rerouted, and traceroute's output becomes a confused combination of two separate routes.

No sending addresses

You only see one IP address from each router - the address closest to you. To put it another way, traceroute can't tell you which interfaces routers are sending the packets on. It only shows the interfaces packets are being received on. The sending interfaces can often be deduced by matching each router with the next one in line - typically only one interface could be used between them.

Routing problems

TCP/IP's sinister and ubiquitous routing problems may cause the router not to have a route back to the sender, or to have a route through some interface other than the one it received the packet on. In these cases, you will either receive no reply at all (no route), or a reply showing an IP address that never handled the original packet (it was handled by some other interface on the same router). In short, don't completely trust traceroute.

Buggy TCP/IP implementations

Traceroute depends on a rather obscure feature that often doesn't work correctly. Some of the problems people have found: code that fails to decrement TTL, code that incorrectly forwards packets with zero TTL, code that does not generate ICMP Timeouts, and code that sends ICMPs with the same TTL as the original packet. This last problem, of course, results in our ICMP Timeouts being sent with zero TTL - guaranteed not to make it back to us.

Traceroute options

Here's a list of common traceroute options:

-m max-ttl

At some TTL value, traceroute expects to get a reply from the target host. Of course, if the host is unreachable for some reason, this may never happen, so max-ttl (default 30) sets a limit on how long traceroute keeps trying. If the target host is farther than 30 hops away, you'll need to increase this value.

-n

Numerical output only. Use this if you're having nameserver problems and traceroute hangs trying to do inverse DNS lookups.

-p port

Base UDP port. The packets traceroute sends are UDP packets targeted at strange port numbers that nothing will be listening on (we hope). The target host should therefore ignore the packets after generating port unreachable messages. Port is the UDP port number that traceroute uses on its first packet, and increments by one for each subsequent packet. My traceroute uses 33434 (yours probably does too). Change this if a program on the target host might be using ports in roughly the 33434-33534 range.

-q queries

How many packets should be sent for each TTL value. The default is 3, which is fine for finding out the route. If you're more interested in seeing RTT values from each hop, I'd suggest increasing this number to 10.

-w wait

Wait is the number of seconds packets have to generate replies before traceroute assumes they never will and moves on. The default is 3. Increase this if pings to the target host show round trip times longer than this.

Sample Traceroute Session

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 (128.8.10.90), 30 hops max, 40 byte packets
 1  cisco (199.2.50.1)
      3.08 ms  2.391 ms  2.653 ms
 2  sl-stk-3-S17-128k.sprintlink.net (144.228.202.1)
      232.955 ms  195.828 ms  309.079 ms
 3  sl-stk-5-F0/0.sprintlink.net (144.228.40.5)
      187.623 ms  24.72 ms  24.545 ms
 4  icm-fix-w-H2/0-T3.icp.net (144.228.10.22)
      28.927 ms  27.511 ms  34.684 ms
 5  fix-west-cpe.SanFrancisco.mci.net (192.203.230.18)
      124.641 ms  225.516 ms  192.667 ms
 6  border3-hssi2-0.SanFrancisco.mci.net (204.70.34.9)
      127.727 ms  29.322 ms  30.108 ms
 7  core-fddi-0.SanFrancisco.mci.net (204.70.2.161)
      227.059 ms  112.441 ms  29.868 ms
 8  core-hssi-2.Denver.mci.net (204.70.1.37)
      52.881 ms  53.632 ms  53.18 ms
 9  core-hssi-3.Washington.mci.net (204.70.1.13)
      93.393 ms  120.491 ms  92.691 ms
10  border1-fddi0-0.Washington.mci.net (204.70.2.2)
      242.042 ms  94.312 ms  265.366 ms
11  suranet-cpe.Washington.mci.net (204.70.56.6)
      193.482 ms  224.183 ms  93.427 ms
12  wtn8-wtn-cf.sura.net (128.167.7.8)
      105.636 ms  92.919 ms  93.663 ms
13  sura9-wtn8-c3.sura.net (128.167.212.1)
      92.88 ms  92.708 ms  98.033 ms
14  sura2-sura-ce.sura.net (128.167.1.2)
      105.182 ms  115.759 ms  130.195 ms
15  umd-sura2-c1.sura.net (192.221.61.2)
      132.248 ms  145.699 ms  182.908 ms
16  csc1hub-gw.umd.edu (128.8.1.224)
      168.827 ms  192.669 ms  191.198 ms
17  terp.umd.edu (128.8.10.90)
      118.98 ms  156.011 ms  160.125 ms
access$