traceroute - Prints the route that packets take to a network
host
/usr/sbin/traceroute [-A] [-a] [-c stoptime] [-d] [-f] [-g
gateway] [-G @addr1@addr2...] [-h server] [-i initial_ttl]
[-k] [-l] [-m max_ttl] [-N] [-n] [-p port] [-Q maxquit]
[-q nqueries] [-r] [-S] [-s source_addr] [-t tos] [-v] [-V
version] [-w waittime] host [packetsize]
Additional traceroute options are: Looks up the AS-number
(Autonomous System) for each hop's network address at the
whois server specified by the -h option. If the destination
host has multiple addresses, traceroute probes all
addresses if this option is set. Normally only the first
address as returned by the resolver is attempted. Specifies
a delay (in seconds) to pause between probe packets.
This may be necessary if the final destination is a router
that does not accept undeliverable packets in bursts.
Enables socket debugging. Disables IP fragmentation. If
the given packetsize is too big to be handled unfragmented
by a machine along the route, a "fragmentation needed"
status is returned and the indicator !F is printed. If a
gateway returns the value of the proper MTU size to be
used, traceroute decreases the packet size automatically
to this new value. If the proper MTU size is not returned,
traceroute chooses a shorter packet size. [IPv4 only]
Enables the IP LSRR (Loose Source Record Route) option.
This is useful for asking how somebody else, at the specified
gateway, reaches a particular target. [IPv6 only]
Specifies the source route for packets to travel. The
route consists of one or more IPv6 node names or
addresses. Use the at character (@) to separate multiple
addresses. You can specify up to 10 addresses. Specifies
the name or IP address of the whois server that is contacted
for the AS-number lookup, if the -A option is
given. Sets the starting time-to-live value to initial_ttl,
to override the default value of 1. Effectively
this skips processing for those intermediate hosts that
are less than initial_ttl hops away. Keeps the connection
to the whois server permanently open. This makes lookups
considerably quicker because connection setup for each
individual lookup is not necessary. However, all whois
servers do not support this feature. Prints the value of
the ttl field in each received packet (this can be used to
help detect asymmetric routing). Sets the max time-tolive
(max number of hops) used in outgoing probe packets.
The default is 30 hops, which is the same default used for
TCP connections. [IPv4 only] Displays the network name
for each hop. If a DNS/BIND resolver cannot be reached,
network names are retrieved just from the /etc/networks
file only. Prints hop IP addresses numerically rather
than both symbolically and numerically. This saves a nameserver
address-to-name lookup for each gateway found on
the path. It also prevents a reverse lookup for numeric
dotted quad addresses given on the command line (destination
host, or -g gateway addresses). Sets the base UDP
port number used in probes (default is 33434). The traceroute
command presumes that nothing is listening on UDP
ports base to base+nhops-1 at the destination host (so an
ICMP "port unreachable" message is returned to terminate
the route tracing). If another process is listening on a
port in the default range, use this option to pick an
unused port range. Stops probing this hop after maxquit
consecutive timeouts are detected. The default value is
5. Useful in combination with -S if you have specified a
big nqueries probe count. Sets the number of probes
launched at each ttl setting (default is 3). Bypasses the
normal routing tables and sends directly to a host on an
attached network. If the host is not on a directlyattached
network, an error is returned. This option can be
used to ping a local host through an interface that has no
route through it (for example, after the interface was
dropped by routed(8) or gated(8)). Prints a per-hop minimum/average/maximum
rtt (round-trip time) statistics summary.
This suppresses the per-probe rtt and ttl reporting.
For better statistics you need to increase the
default nqueries probe count. See also the -Q option.
Uses the following IP address (which must be given as an
IP number, not a hostname) as the source address in outgoing
probe packets. On hosts with more than one IP
address, use this option to force the source address to be
something other than the IP address of the interface on
which the probe packet is sent. If the IP address is not
one of this machine's interface addresses, an error is
returned and nothing is sent. Sets the type-of-service in
probe packets to the following value (default zero). The
value must be a decimal integer in the range 0 to 255.
Use this option to determine if different types-of-service
result in different paths. Not all values of TOS are
legal or meaningful - see the IP specification for definitions.
Useful values are probably -t 16 (low delay) and
-t 8 (high throughput). Produces verbose output. Lists
any received ICMP packets other than "time exceeded" and
"unreachable". Specifies the Internet Protocol (IP) version
number to enable the resolver to return the correct
address. Use the -V 4 option if you want to issue a
traceroute command to a host name (not IP address) that
has both IPv4 and IPv6 addresses and you want to trace the
route to the IPv4 address. Sets the time (in seconds) to
wait for a response to a probe. The default is 3 seconds.
The Internet is a large and complex aggregation of network
hardware, connected together by gateways. The traceroute
command tracks the route packets follow from gateway to
gateway. The command uses the IP protocol `time to live'
field and attempts to elicit an ICMP "time exceeded"
response from each gateway along the path to a particular
host.
The only mandatory parameter is the destination host name
or IP address.
The default probe datagram length is either 38 bytes
(IPv4) or 72 bytes (IPv6), but you can increase this by
specifying a packet size (in bytes) after the destination
host name. This is useful when the -f option is given for
MTU discovery along the route. You should start with the
maximum packet size for your own network interface (if the
given value is even bigger, traceroute attempts to select
a more appropriate value). If no packet size is given when
using the -f option, traceroute determines the initial MTU
automatically.
To track the route of an IP packet, traceroute launches
UDP probe packets with a small ttl (time to live) and then
listens for an ICMP "time exceeded" reply from a gateway.
Probes start with a ttl of one and increase by one until
either an ICMP "port unreachable" is returned (indicating
that the packet reached the host) or the maximum number of
hops is exceeded (the default is 30 hops and can be
changed with the -m option). At each ttl setting, traceroute
launches three probes (you can change the number with
the -q option) 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 there is
no response within a 3 second timeout interval (which you
can change with the -w option), an asterisk (*) is printed
for that probe.
To prevent the destination host from processing the UDP
probe packets, the destination port is set to an unlikely
value. You can change the destination port value with the
-p option, if necessary.
Other possible annotations after the time are: Host is
unreachable. Network is unreachable. Protocol is
unreachable. Fragmentation needed.
This indicator may show up if the -f command line
option is being used, and the associated gateway
requires further fragmentation. In case the
desired new MTU size is known, it is indicated.
Source route failed.
This should not occur under normal circumstances
and the associated gateway might be broken if you
see one. Host or network is unreachable for the
given tos. Destination is unreachable.
This indicator is printed for some of the new
unreachable subcodes as defined in RFC 1812. Some
routers fail to generate an ICMP "port unreachable"
message, but send an ICMP "time exceeded" message
instead if they are the target host. The indicator
is printed if this is detected. Some routers erroneously
generate ICMP "port unreachable" instead of
"time exceeded" if they are specified as loose
source route gateway hosts. The indicator is
printed if this is detected.
If all the probes result in an unreachable status, traceroute
stops sending probes and exits.
This indicates that the ttl value in the ICMP "time
exceeded" packet that we received was unexpected. We
expected some initial value, for example, the number of
routers between our system and another system. In other
words, if the path from hop 5 to us is the same as the
path from us to hop 5, we expect to receive a ttl value of
4.
There are several common initial values for ICMP
ttls: 255, 60, 59, 30 and 29. 4.3 tahoe BSD and
Cisco routers use 255, Proteon routers use either
59 or 29 depending on software release, several
other implementations use 60 and 30. Tru64 UNIX
uses an initial ttl of 64. The traceroute command
checks against all of these, making it hard to
detect some small routing asymmetries. If you want
to see the ttl values in all the packets, use the
-l option.
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 it could
impose on the network, do not use traceroute during normal
operations or from automated scripts.
By default, traceroute tries to resolve destination host
names as an IPv6 address. If that fails, it resolves the
host name as an IPv4 address. You can override this
behavior with the -V option.
The following command traces the route a packet takes from
localhost to the host nis.nsf.net: localhost> 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 identical. This is due
to a bug in the kernel on the 2nd hop system, lblcsam.arpa,
that forwards packets with a zero ttl (a
bug in the distributed version of 4.3BSD). The
NSFNet (129.140) does not supply address-to-name
translations for its NSSes. Therefore, you cannot
be certain of the path the packets take cross-country.
The following is another example of output
from the traceroute command. Packets from localhost
to the host allspice.lcs.mit.edu are being
traced: localhost> 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 do not send ICMP "time exceeded" messages
or send them with a ttl too small to reach
localhost. Further investigation is required to
determine the cause. For example, by contacting
the system administrators for gateways 14 through
17, you could discover that these gateways are running
the MIT C Gateway code that does not send
"time exceeded" messages.
The silent gateway 12 in the example may be the
result of a bug in the 4.[23]BSD network code (and
its derivatives): 4.x (x <= 3) sends 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 us.
When this bug appears on the destination system it
behaves as follows:
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 !
Note that there are 12 gateways (13 is the final
destination) and the last half of them are missing.
What is happening is that the host rip (a Sun-3
running Sun OS3.5) is using the ttl from our arriving
datagram as the ttl in its ICMP reply. The
reply will time out on the return path (with no
notice sent to anyone since ICMPs are not sent for
ICMPs) until we probe with a ttl that is at least
twice the path length. This means that the host
rip is really only 7 hops away.
A reply that returns with a ttl of 1 is a clue this
problem exists. The traceroute command prints a !
after the time if the ttl is less than or equal to
1. Since many systems continue to run obsolete or
non-standard software, expect to see this problem
frequently.
IPv6 Examples [Toc] [Back]
In the following examples, the backslash and the continuation
of output on to a second line is for display purposes
only. In actual output, the information appears on a single
line.) # traceroute -n host1-v6 traceroute to
host1-v6.corp.com (3ffe:1200:4110:3:a00:2bff:feb4:89c5), \
30 hops max, 24 byte packets
1 fe80::a00:2bff:fe2a:1ed3 130.86 ms 119.141 ms
119.14 ms
2 3ffe:1200:4110:1:a00:2bff:fe2d:2b2 126.014 ms
117.308 ms 116.33 ms
3 3ffe:1200:4110:3:a00:2bff:feb4:89c5 122.195 ms
135.882 ms 119.263 ms
# traceroute 3ffe:1200:4110:3:a00:2bff:feb4:89c5 traceroute
to 3ffe:1200:4110:3:a00:2bff:feb4:89c5 \
(3ffe:1200:4110:3:a00:2bff:feb4:89c5), 30 hops max, 24
byte packets
1 fe80::a00:2bff:fe2a:1ed3 (fe80::a00:2bff:fe2a:1ed3)
123.046 ms \
114.258 ms 117.188 ms
2 host2-v6.corp.com (3ffe:1200:4110:1:a00:2bff:fe2d:2b2)
115.234 ms \
117.188 ms 116.287 ms
3 host1-v6.corp.com
(3ffe:1200:4110:3:a00:2bff:feb4:89c5) 120.241 ms \
113.398 ms 120.24 ms
When the route has an IPv6 over IPv4 tunnel, traceroute
views this as a single hop. It prints the IPv6 addresses
of the nodes at each end of a tunnel only, and none of the
intermediate IPv4 routers between the tunnel source and
destination. If a traceroute command over a tunnel interface
fails, run the command again and specify the tunnel's
IPv4 destination address.
The following command shows a trace across the 6Bone to
tw4.es.net. Note that the intermediate routers appear to
drop every other message. A probable reason for this is
that the routers probably rate limit IPv6 ICMP error messages
to one per second. Rate limiting ICMP error messages
is valid behavior. # traceroute tw4.es.net traceroute
to tw4.es.net (3ffe:780:40:1:a00:2bff:febc:e96c), \
30 hops max, 24 byte packets 1 gw1.ipv6.pa-x.dec.com
(3ffe:1280:1000:1::f842:1428) 83.985 ms * 83.000 ms 2
3ffe:700:20:1::21 (3ffe:700:20:1::21) 108.399 ms *
112.305 ms 3
3ffe:780:40:1:a00:2bff:febc:e96c(3ffe:780:40:1:a00:2bff:febc:e96c)
124.023 ms\
134.766 ms 116.211 ms
The following example is a trace to yogi-gbl using
2000-byte messages, and shows the effect of Path MTU Discovery
on traceroute results: # traceroute yogi-gbl 2000
traceroute to yogi-gbl (fec0:10:60:0:200:f8ff:fe40:d8e6),
\
30 hops max, 2024 byte packets 1 a30rtr-gbl
(fec0:10:30:0:200:f8ff:fe45:cfb2) 5.859 ms 3.906 ms
3.907 ms 2 fec0:10:20:0:a00:2bff:feb0:972d
(fec0:10:20:0:a00:2bff:feb0:972d) 4.882 ms
3.906 ms 3.906 ms 3 * fec0:10:40:1::a0a:283c
(fec0:10:40:1::a0a:283c) 6.836 ms 6.836 ms 4 yogi-gbl
(fec0:10:60:0:200:f8ff:fe40:d8e6) 8.789 ms 8.789 ms
7.812 ms
Hops 1 and 2 are across Ethernet links that have a link
MTU of 1500 bytes. Hop 3 is across a configured tunnel
with an MTU of 1280 bytes.
The 1500-byte message fragments were transmitted without
error until they hit the tunnel. The first fragment
across hop 3 triggered a "message too big" error, which in
turn caused the sender to record a reduced Path MTU for
yogi-gbl. The sender sent all subsequent messages with
smaller fragments. The traceroute display shows that the
first probe to the tunnel was dropped, but all others succeeded.
Commands: netstat(1), ping(8)
Daemons: gated(8), routed(8)
traceroute(8)
[ Back ] |
