unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (OSF1-V5.1-alpha)
Page:
Section:
Apropos / Subsearch:
optional field



traceroute(8)							traceroute(8)



NAME

  traceroute - Prints the route	that packets take to a network host

SYNOPSIS

  /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]

OPTIONS

  Additional traceroute	options	are:

  -A  Looks up the AS-number (Autonomous System) for each hop's	network
      address at the whois server specified by the -h option.

  -a  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.

  -c stoptime
      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.

  -d  Enables socket debugging.

  -f  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 gate-
      way 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.

  -g gateway
      [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.

  -G @addr1@addr2...
      [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.

  -h server
      Specifies	the name or IP address of the whois server that	is contacted
      for the AS-number	lookup,	if the -A option is given.

  -i initial_ttl
      Sets the starting	time-to-live value to initial_ttl, to override the
      default value of 1.  Effectively this skips processing for those inter-
      mediate hosts that are less than initial_ttl hops	away.

  -k  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.

  -l  Prints the value of the ttl field	in each	received packet	(this can be
      used to help detect asymmetric routing).

  -m max_ttl
      Sets the max time-to-live	(max number of hops) used in outgoing probe
      packets.	The default is 30 hops,	which is the same default used for
      TCP connections.

  -N  [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.

  -n  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).

  -p port
      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 pro-
      cess is listening	on a port in the default range,	use this option	to
      pick an unused port range.

  -Q maxquit
      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.

  -q nqueries
      Sets the number of probes	launched at each ttl setting (default is 3).

  -r  Bypasses the normal routing tables and sends 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	(for example, after the
      interface	was dropped by routed(8) or gated(8)).

  -S  Prints a per-hop minimum/average/maximum rtt (round-trip time) statis-
      tics 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.

  -s source_addr
      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.

  -t tos
      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).

  -v  Produces verbose output. Lists any received ICMP packets other than
      "time exceeded" and "unreachable".

  -V version
      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.

  -w waittime
      Sets the time (in	seconds) to wait for a response	to a probe.  The
      default is 3 seconds.

DESCRIPTION

  The Internet is a large and complex aggregation of network hardware, con-
  nected together by gateways.	The traceroute command tracks the route	pack-
  ets 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 (indi-
  cating 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 destina-
  tion port value with the -p option, if necessary.

SPECIAL	ANNOTATIONS

  Other	possible annotations after the time are:

  !H  Host is unreachable.

  !N  Network is unreachable.

  !P  Protocol is unreachable.

  !F  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.

  !S  Source route failed.

      This should not occur under normal circumstances and the associated
      gateway might be broken if you see one.

  !T  Host or network is unreachable for the given tos.

  !U  Destination is unreachable.

      This indicator is	printed	for some of the	new unreachable	subcodes as
      defined in RFC 1812.

  !A  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.

  !G  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.

TTL INDICATION

  (ttl=n!)
      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 implemen-
      tations use 60 and 30. Tru64 UNIX	uses an	initial	ttl of 64. The tra-
      ceroute 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.

NOTES

  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.

EXAMPLES

   1.  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, lbl-csam.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.

   2.  The following is	another	example	of output from the traceroute com-
       mand.  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" mes-
       sages.

       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


  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 infor-
  mation 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 prob-
  able 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 frag-
  ments.  The traceroute display shows that the	first probe to the tunnel was
  dropped, but all others succeeded.

SEE ALSO

  Commands: netstat(1),	ping(8)

  Daemons: gated(8), routed(8)