traceroute [ options ] host [ size ]
Traceroute attempts to trace the route an IP packet follows to some
internet host. It finds out intermediate hops by launching probe pack-
ets with a small time-to-live (TTL) value, and then listens for an ICMP
reply of time exceeded from an intermediate router. Traceroute starts
probing with a TTL of one, and increments by one until an ICMP port
unreachable reply is received. This means the probe either got through
to host, or hit the maximum TTL.
host is the only mandatory argument, and specifies the target system,
either as an IP address, or as a host name. Parameter size determines
the size of the probe packets in bytes.
-a Abort after 10 consecutive hops without an answer.
-d Turn on socket level debugging. This option is only available
to the super-user (root).
Set the maximum time-to-live (TTL) value that will be used for
probing. Hosts that are farther than max_ttl hops away will not
be traced (default 30).
-n Report only IP addresses, but no hostnames.
Start probing at an alternate UDP port (default 33434). Tracer-
oute by default sends out UDP packets with increasing port num-
bers starting at port, and listens for ICMP errors returned from
remote hosts. This scheme only works if there are no UDP
servers listening on the probed hosts in the range from port to
port + max_ttl.
-q n Send out n queries for each TTL (each intermediate host)
-r Set Dont Route option, advising routers to drop the packets. In
other words, only probe within the local subnet.
Set source address of outgoing packets to addr, given either as
numeric IP address, or as hostname.
-t tos Set the type-of-service field in the outgoing IP packets
(default 0). tos is valid in the range of 0 to 255.
-u Use microsecond timestamps.
-v Turn on verbose output.
Send out probe packets using IP protocol proto, given either as
name or numerical value (default UDP). Some features like par-
allel probing are only available when using UDP.
-M Determine the maximum transfer unit (MTU) along the path. See
RFC 1191 for details.
-O At each hop, perform a DNS lookup and report the owner as listed
in the SOA record.
-P Send out multiple probes in parallel. The default behaviour
probes each hop in turn, starting from the nearest. Parallel
mode is faster, but less reliable. Many routers rate limit ICMP
packets from a single host, so dropouts are much more likely in
parallel mode, and need not indicate a networking problem.
-Q Report detailed statistics on the round trip times at each hop
(minimum / average +- standard deviation / maximum). The values
are given in milli seconds.
Set the time-to-live (TTL) value in the first packet sent out to
min_ttl (default 1). This option determines the first (nearest)
host that will show up in the trace.
-T t End each line with t instead of a newline. This comes in handy,
for example, when including traceroute's output in an HTML page.
-U Move on to probing the next hop as soon as the first successful
-$ Send out nothing but a single ping with a very large time-to-
Usually the round trip time is printed for each probe at each hop.
Special symbols denote when something went wrong:
* No reply received within wait seconds.
! Reply arrived with a time-to-live value of one or lower.
!H Received a reply telling that the destination host is unreach-
!N Received a reply telling that the destination network is
!P Received a reply telling that the desired protocol is unavail-
!S Received a reply telling that source routing failed. Should
never occur--unless the probed gateway is screwed.
4 ccngw-ner-cc.Berkeley.EDU (188.8.131.52) 39 ms 40 ms 39 ms
5 ccn-nerif22.Berkeley.EDU (184.108.40.206) 39 ms 39 ms 39 ms
6 220.127.116.11 (18.104.22.168) 40 ms 59 ms 59 ms
7 22.214.171.124 (126.96.36.199) 59 ms 59 ms 59 ms
8 188.8.131.52 (184.108.40.206) 99 ms 99 ms 80 ms
9 220.127.116.11 (18.104.22.168) 139 ms 239 ms 319 ms
10 22.214.171.124 (126.96.36.199) 220 ms 199 ms 199 ms
11 nic.merit.edu (188.8.131.52) 239 ms 239 ms 239 ms
Note that lines 2 & 3 are the same. This is due to a buggy kernel on
the 2nd hop system -- lbl-csam.arpa -- that forwards packets with a
A more interesting example is:
[yak 72]% traceroute allspice.lcs.mit.edu.
traceroute to allspice.lcs.mit.edu (184.108.40.206), 30 hops max
1 helios.ee.lbl.gov (220.127.116.11) 0 ms 0 ms 0 ms
2 lilac-dmc.Berkeley.EDU (18.104.22.168) 19 ms 19 ms 19 ms
3 lilac-dmc.Berkeley.EDU (22.214.171.124) 39 ms 19 ms 19 ms
4 ccngw-ner-cc.Berkeley.EDU (126.96.36.199) 19 ms 39 ms 39 ms
5 ccn-nerif22.Berkeley.EDU (188.8.131.52) 20 ms 39 ms 39 ms
6 184.108.40.206 (220.127.116.11) 59 ms 119 ms 39 ms
7 18.104.22.168 (22.214.171.124) 59 ms 59 ms 39 ms
8 126.96.36.199 (188.8.131.52) 80 ms 79 ms 99 ms
9 184.108.40.206 (220.127.116.11) 139 ms 139 ms 159 ms
10 18.104.22.168 (22.214.171.124) 199 ms 180 ms 300 ms
11 126.96.36.199 (188.8.131.52) 300 ms 239 ms 239 ms
12 * * *
13 184.108.40.206 (220.127.116.11) 259 ms 499 ms 279 ms
14 * * *
15 * * *
16 * * *
17 * * *
18 ALLSPICE.LCS.MIT.EDU (18.104.22.168) 339 ms 279 ms 279 ms
(I start to see why I'm having so much trouble with mail to MIT.) Note
that the gateways 12, 14, 15, 16 & 17 hops away either don't send ICMP
"time exceeded" messages or send them with a TTL too small to reach us.
14 - 17 are running the MIT C Gateway code that doesn't send "time
exceeded"s. God only knows what's going on with 12.
The silent gateway 12 in the above may be the result of a bug in the
4.BSD network code (and its derivatives): 4.x (x <= 3) sends an
unreachable message using whatever TTL remains in the original data-
gram. Since, for gateways, the remaining TTL is zero, the icmp "time
exceeded" is guaranteed to not make it back to us. The behavior of
this bug is slightly more interesting when it appears on the destina-
1 helios.ee.lbl.gov (22.214.171.124) 0 ms 0 ms 0 ms
2 lilac-dmc.Berkeley.EDU (126.96.36.199) 39 ms 19 ms 39 ms
3 lilac-dmc.Berkeley.EDU (188.8.131.52) 19 ms 39 ms 19 ms
4 ccngw-ner-cc.Berkeley.EDU (184.108.40.206) 39 ms 40 ms 19 ms
is that rip (a Sun-3 running Sun OS3.5) is using the TTL from our
arriving datagram as the TTL in its icmp reply. So, the reply will
time out on the return path until we probe with a TTL that's at least
twice the path length. I.e., rip is really only 7 hops away.
The lookup process of Autonomous System Numbers (ASN, see option -A
above) can be configured via several environment variables. By default,
traceroute issues a whois query on the Routing Assets Database (RADB)
at whois.ra.net, which should be sufficient in most cases. Chances are
that you don't want to change anything here, unless you know very well
what you are doing.
The contents of the following environment variables are limited to 100
characters at most. Any trailing characters are silently ignored. If
unset, compiled-in defaults are used.
Server to issue a RADB whois query on, given either as hostname,
or dotted-quad IP address. Defaults to whois.ra.net.
TCP port to connect to on the whois server, given either as name
or port number. Defaults to whois.
The following variables determine how traceroute attempts to extract an
ASN from the whois reply.
Each line containing an ASN starts with this tag. Defaults to
The RADB may contain more than one entry for a given IP address. To
find out the correct entry, traceroute has to look up the subnet that
is the most specific to this IP.
Each line containing a subnet entry starts with this tag.
Defaults to route:.
The network IP and the prefix are separated by this tag.
Defaults to /.
This is not the standard version of traceroute (as included in the
netkit package), but an alternative implementation maintained by Ehud
Gavron. It is based on the Van Jacobson/BSD traceroute, and includes
additional features including AS lookup, TOS support, microsecond time-
stamps, path MTU discovery, and parallel probing. It is known as
trACESroute or traceroute-nanog.
mtr(8), netstat(8), pchar(8), ping(8)
tation in the source code. Still, this man page may be used by others.
NANOG traceroute 6.3.10 March 2004 TRACEROUTE(8)
Man Pages Copyright Respective Owners. Site Copyright (C) 1994 - 2019
All Rights Reserved.