Connected: An Internet Encyclopedia
Connected: An Internet Encyclopedia
``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
Time Exceeded message, documented in
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
| SENDER | | TARGET |
[============( Router )=====( Router )=====( Router )==|====]
^ ^ ^ |
| TTL=1 | TTL=2 | TTL=3 | TTL=4
Traceroute | | | |
shows these -----+--------------+--------------+------------/
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
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.
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.
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
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 (126.96.36.199), 30 hops max, 40 byte packets
1 cisco (188.8.131.52)
3.08 ms 2.391 ms 2.653 ms
2 sl-stk-3-S17-128k.sprintlink.net (184.108.40.206)
232.955 ms 195.828 ms 309.079 ms
3 sl-stk-5-F0/0.sprintlink.net (220.127.116.11)
187.623 ms 24.72 ms 24.545 ms
4 icm-fix-w-H2/0-T3.icp.net (18.104.22.168)
28.927 ms 27.511 ms 34.684 ms
5 fix-west-cpe.SanFrancisco.mci.net (22.214.171.124)
124.641 ms 225.516 ms 192.667 ms
6 border3-hssi2-0.SanFrancisco.mci.net (126.96.36.199)
127.727 ms 29.322 ms 30.108 ms
7 core-fddi-0.SanFrancisco.mci.net (188.8.131.52)
227.059 ms 112.441 ms 29.868 ms
8 core-hssi-2.Denver.mci.net (184.108.40.206)
52.881 ms 53.632 ms 53.18 ms
9 core-hssi-3.Washington.mci.net (220.127.116.11)
93.393 ms 120.491 ms 92.691 ms
10 border1-fddi0-0.Washington.mci.net (18.104.22.168)
242.042 ms 94.312 ms 265.366 ms
11 suranet-cpe.Washington.mci.net (22.214.171.124)
193.482 ms 224.183 ms 93.427 ms
12 wtn8-wtn-cf.sura.net (126.96.36.199)
105.636 ms 92.919 ms 93.663 ms
13 sura9-wtn8-c3.sura.net (188.8.131.52)
92.88 ms 92.708 ms 98.033 ms
14 sura2-sura-ce.sura.net (184.108.40.206)
105.182 ms 115.759 ms 130.195 ms
15 umd-sura2-c1.sura.net (220.127.116.11)
132.248 ms 145.699 ms 182.908 ms
16 csc1hub-gw.umd.edu (18.104.22.168)
168.827 ms 192.669 ms 191.198 ms
17 terp.umd.edu (22.214.171.124)
118.98 ms 156.011 ms 160.125 ms
Connected: An Internet Encyclopedia