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$
