traceroute(1M) TCP/IP R4.11 traceroute(1M)
NAME
traceroute - print the route packets take to network host
SYNOPSIS
traceroute [ -m max_ttl ] [ -n ] [ -p port ] [ -q nqueries ] [ -r ]
[ -s src_addr ] [ -g addr ] [ -t tos ] [ -w waittime ] host
[ packetsize ]
DESCRIPTION
The Internet is a large and complex aggregation of network hardware,
connected together by gateways. Tracking the route one's packets
follow (or finding the miscreant gateway that's discarding your
packets) can be difficult. Traceroute utilizes the IP protocol time-
to-live field and attempts to elicit an ICMP TIME_EXCEEDED response
from each gateway along the path to some host.
This program is intended for use in network testing, measurement and
management. It should be used primarily for manual fault isolation.
Because of the load traceroute could impose on the network, do not
use it repeatedly during normal operations or from automated scripts.
The only mandatory parameter is the destination host name or IP
number. The default probe datagram length is 38 bytes, but this may
be increased by specifying a packet size (in bytes) after the
destination host name.
Other options are:
-m Set the maximum time to live (maximum number of hops) used in
outgoing probe packets to max_ttl. The default is 30 hops (the
same default used for TCP connections).
-n Print hop addresses numerically rather than symbolically and
numerically (saves a nameserver address-to-name lookup for each
gateway found on the path).
-p Set the base UDP port number used in probes to port (default is
33434). Traceroute hopes that nothing is listening on UDP ports
base to base+nhops-1 at the destination host (so an ICMP
PORT_UNREACHABLE message will be returned to terminate the route
tracing). If something is listening on a port in the default
range, this option can be used to pick an unused port range.
-q Set the number of probes sent at each ttl setting.
-r Bypass the normal routing tables and send directly to a host on
an attached network. If the host is not on a directly attached
network, an error is returned. This option can be used to ping
a local host through an interface that has no route through it
(e.g., after the interface was dropped by routed(1M)).
-s Use src_addr (which must be an IP number, not a hostname) as the
source IP address in outgoing probe packets. On hosts with more
than one IP address, this option can be used to force the source
address to be something other than the IP address of the
interface the probe packet is sent on. If the IP address is not
one of this machine's interface addresses, an error is returned
and nothing is sent.
-g Enable the IP LSRR (Loose Source Record Route) option in
addition to the TTL tests. This is useful for asking how
somebody else, at IP address addr, reaches a particular target.
-t Set the type-of-service in probe packets to tos (default zero).
The value must be a decimal integer in the range 0 to 255. This
option can be used to see if different types of service result
in different paths. Not all values of TOS are legal or
meaningful; see RFC 791 for definitions. Useful values are -t
16 (low delay) and -t 8 (high throughput).
-v Verbose output. Received ICMP packets other than TIME_EXCEEDED
and UNREACHABLEs are listed.
-w Set the time to wait for a response to a probe to waittime
seconds (default is 3).
Traceroute traces the route an IP packet would follow to some
Internet host by launching UDP probe packets with a small ttl (time
to live) then listening for an ICMP ``time exceeded'' reply from a
gateway. Traceroute starts its probes with a ttl of 1 and increases
by 1 until it gets an ICMP ``port unreachable'' (this means it got to
host) or reaches the maximum number of hops (changed with -m
max_ttl). Traceroute sends three probes (changed with -q nqueries) at
each ttl setting, and prints a line showing the ttl, address of the
gateway, and round trip time of each probe. If the probe answers
come from different gateways, traceroute prints the address of each
responding system. If no response occurs within a 3-second timeout
interval (changed with -w waittime), traceroute prints a * for that
probe.
To avoid the destination host processing the UDP probe packets, the
destination port is set to an unlikely value. If someone on the
destination is using that value, use -p port to change it.
A sample use and output might be:
% traceroute nis.nsf.net.
traceroute to nis.nsf.net (35.1.1.48), 30 hops max, 56 byte packet
1 helios.ee.lbl.gov (128.3.112.1) 19 ms 19 ms 0 ms
2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms
3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms
4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 39 ms
5 ccn-nerif22.Berkeley.EDU (128.32.168.22) 39 ms 39 ms 39 ms
6 128.32.197.4 (128.32.197.4) 40 ms 59 ms 59 ms
7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 59 ms
8 129.140.70.13 (129.140.70.13) 99 ms 99 ms 80 ms
9 129.140.71.6 (129.140.71.6) 139 ms 239 ms 319 ms
10 129.140.81.7 (129.140.81.7) 220 ms 199 ms 199 ms
11 nic.merit.edu (35.1.1.48) 239 ms 239 ms 239 ms
Note that lines 2 and 3 are the same. This is due to a buggy kernel
on the second-hop system (lbl-csam.arpa) that forwards packets with a
zero ttl (a bug in the distributed version of 4.3BSD).
A more interesting example is:
% traceroute allspice.lcs.mit.edu.
traceroute to allspice.lcs.mit.edu (18.26.0.115), 30 hops max
1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms
2 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 ms 19 ms 19 ms
3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 19 ms 19 ms
4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 19 ms 39 ms 39 ms
5 ccn-nerif22.Berkeley.EDU (128.32.168.22) 20 ms 39 ms 39 ms
6 128.32.197.4 (128.32.197.4) 59 ms 119 ms 39 ms
7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 39 ms
8 129.140.70.13 (129.140.70.13) 80 ms 79 ms 99 ms
9 129.140.71.6 (129.140.71.6) 139 ms 139 ms 159 ms
10 129.140.81.7 (129.140.81.7) 199 ms 180 ms 300 ms
11 129.140.72.17 (129.140.72.17) 300 ms 239 ms 239 ms
12 * * *
13 128.121.54.72 (128.121.54.72) 259 ms 499 ms 279 ms
14 * * *
15 * * *
16 * * *
17 * * *
18 ALLSPICE.LCS.MIT.EDU (18.26.0.115) 339 ms 279 ms 279 ms
Note that the gateways 12, 14, 15, 16, and 17 hops away either don't
send ICMP ``time exceeded'' messages or send them with a ttl too
small to reach us. Gateways 14 to 17 are running the MIT C Gateway
code that doesn't send ``time exceeded.''
The silent gateway 12 may be the result of a bug in the 4.[23]BSD
network code (and its derivatives). Some revisions send an
unreachable message using whatever ttl remains in the original
datagram. Since, for gateways, the remaining ttl is zero, the ICMP
``time exceeded'' is guaranteed to not make it back to traceroute.
The behavior of this bug is slightly more interesting when it appears
on the destination system:
1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms
2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 19 ms 39 ms
3 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 ms 39 ms 19 ms
4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 19 ms
5 ccn-nerif35.Berkeley.EDU (128.32.168.35) 39 ms 39 ms 39 ms
6 csgw.Berkeley.EDU (128.32.133.254) 39 ms 59 ms 39 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 rip.Berkeley.EDU (128.32.131.22) 59 ms ! 39 ms ! 39 ms !
There appear to be 12 gateways (13 is the final destination) but the
last half of them are missing. In reality, rip is using the ttl from
the arriving datagram as the ttl in its ICMP reply. Therefore, the
reply will time out on the return path (with no notice sent to
anyone, since ICMPs aren't sent for ICMPs) until we probe with a ttl
that's at least twice the path length. That is, rip is actually only
7 hops away. A reply that returns with a ttl of 1 indicates that
this problem exists. Traceroute prints a ! after the time if the ttl
is <= 1. You may see this problem with obsolete or nonstandard
software.
Other possible annotations after the time are !H, !N, !P (got a host,
network, or protocol unreachable, respectively), !S or !F (source
route failed or fragmentation needed; these should never occur). If
almost all the probes result in some kind of unreachable, traceroute
will give up and exit.
traceroute -g 10.3.0.5 128.182.0.0
shows the path from the Cambridge Mailbridge to PSC while
traceroute -g 192.5.146.4 -g 10.3.0.5 35.0.0.0
shows how the Cambridge Mailbridge reaches Merit by using PSC to
reach the Mailbridge.
SEE ALSO
netstat(1M).
Licensed material--property of copyright holder(s)