*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->IRIX man pages -> traceroute (1)              



NAME    [Toc]    [Back]

     traceroute	- print	the route packets take to a network host

SYNOPSIS    [Toc]    [Back]

     /usr/etc/traceroute [ -g addr ] [ -l ] [ -m max_ttl ]
	  [ -M min_ttl ] [ -n ]	[ -p port ] [ -q nqueries ]
	  [ -r ] [ -s src_addr ] [ -t tos ] [ -w waittime ]
	  host [ datalen ]

DESCRIPTION    [Toc]    [Back]

     The Internet is a large and complex aggregation of	network	hardware,
     connected by gateways.  Tracking the route	your packets follow (or
     finding the miscreant gateway that's discarding your packets) can be
     difficult.	 traceroute utilizes the IP protocol ``time-to-live'' (TTL)
     field and attempts	to elicit an ICMP TIME_EXCEEDED	response from each
     gateway along the path to some host.

     The only mandatory	parameter is the destination host name or IP address.
     The default probe datagram	length is 40 bytes, but	this may be increased
     by	specifying the additional length (in bytes) after the destination host

     The options are:

     -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
	  addr,	(either	an IP address or a hostname) reaches a particular

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

     -m	  Set the maximum time-to-live (maximum	number of hops)	used in
	  outgoing probe packets.  The default is 30 hops or the minimum TTL
	  plus 1, whichever is larger.

     -M	  Set the minimum time-to-live used in outgoing	probe packets.	The
	  default is 1 hop.

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

									Page 1


     -q	  Set the number of probe packets to send. The default is 3 packets.

     -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 (for
	  example, after the interface was dropped by routed(1M)).

     -s	  Use the following IP address (which must be given as a number, not a
	  hostname) as the source 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.

     -t	  Set the type-of-service (TOS)	in probe packets to the	following
	  value	(default zero).	 The value must	be a decimal integer in	the
	  range	0 to 255.  This	option can be used to see if different typesof-service
 result in different paths.	 Not all values	of TOS are
	  legal	or meaningful: see the IP RFC for definitions.	Useful values
	  are probably -t 16 (low delay) and -t	8 (high	throughput).

     -v	  Verbose output.  Received ICMP packets other than TIME_EXCEEDED and
	  PORT_UNREACHABLEs are	listed.

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

     This program attempts to trace the	route an IP packet would follow	to
     some Internet host	by launching UDP probe packets with a small TTL	then,
     listening for an ICMP TIME_EXCEEDED reply from a gateway.	The probes
     begin with	a TTL of one and increase by one until an ICMP
     PORT_UNREACHABLE message is received, which means we got to ``host'' or
     hit the maximum (which defaults to	30 hops	but can	be changed with	the -m
     flag).  Three probes (changed with	-q flag) are sent at each TTL setting
     and a line	is printed showing the TTL, address of the gateway and round
     trip time of each probe.  If the probe answers come from different
     gateways, the address of each responding system will be printed.  If
     there is no response within a 3-second timeout interval (changed with the
     -w	flag), a ``*'' is printed for that probe.

     So	that the destination host will not process the UDP probe packets, the
     destination port is set to	an unlikely value.  If someone on the
     destination is using that value, it can be	changed	with the -p flag.

     A sample use and output might be:

	% traceroute nis.nsf.net.
	traceroute to nis.nsf.net (, 30 hops max, 56 byte packet
	 1  helios.ee.lbl.gov (  19	ms  19 ms  0 ms
	 2  lilac-dmc.Berkeley.EDU (  39 ms  39 ms	 19 ms

									Page 2


	 3  lilac-dmc.Berkeley.EDU (  39 ms  39 ms	 19 ms
	 4  ccngw-ner-cc.Berkeley.EDU (  39 ms  40 ms  39	ms
	 5  ccn-nerif22.Berkeley.EDU (  39 ms  39	ms  39 ms
	 6 (	 40 ms	59 ms  59 ms
	 7	(  59 ms  59 ms  59	ms
	 8 (  99 ms  99 ms	 80 ms
	 9 (	 139 ms	 239 ms	 319 ms
	10 (	 220 ms	 199 ms	 199 ms
	11  nic.merit.edu (  239 ms  239 ms  239 ms

     Notice that lines 2 and 3 are the same because of 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).  You	have to	guess what
     path the packets are taking cross-country since the NSFNet	(129.140)
     doesn't supply address-to-name translations for its NSSes.

     A more interesting	example	is:

	% traceroute allspice.lcs.mit.edu.
	traceroute to allspice.lcs.mit.edu (, 30 hops max
	 1  helios.ee.lbl.gov (  0 ms  0 ms	 0 ms
	 2  lilac-dmc.Berkeley.EDU (  19 ms  19 ms	 19 ms
	 3  lilac-dmc.Berkeley.EDU (  39 ms  19 ms	 19 ms
	 4  ccngw-ner-cc.Berkeley.EDU (  19 ms  39 ms  39	ms
	 5  ccn-nerif22.Berkeley.EDU (  20 ms  39	ms  39 ms
	 6 (	 59 ms	119 ms	39 ms
	 7	(  59 ms  59 ms  39	ms
	 8 (  80 ms  79 ms	 99 ms
	 9 (	 139 ms	 139 ms	 159 ms
	10 (	 199 ms	 180 ms	 300 ms
	11 (  300 ms  239 ms  239 ms
	12  * *	*
	13 (  259 ms  499 ms  279 ms
	14  * *	*
	15  * *	*
	16  * *	*
	17  * *	*
	18  ALLSPICE.LCS.MIT.EDU (	339 ms	279 ms	279 ms

     Notice 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.	14 - 17	are running the	MIT C Gateway code that	doesn't	send

     The silent	gateway	12 in the above	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.  The	behavior of this bug is
     slightly more interesting when it appears on the destination system:

									Page 3


	% traceroute rip.berkeley.edu
	 1  helios.ee.lbl.gov (  0 ms  0 ms	 0 ms
	 2  lilac-dmc.Berkeley.EDU (  39 ms  19 ms	 39 ms
	 3  lilac-dmc.Berkeley.EDU (  19 ms  39 ms	 19 ms
	 4  ccngw-ner-cc.Berkeley.EDU (  39 ms  40 ms  19	ms
	 5  ccn-nerif35.Berkeley.EDU (  39 ms  39	ms  39 ms
	 6  csgw.Berkeley.EDU (	39 ms  59 ms  39 ms
	 7  * *	*
	 8  * *	*
	 9  * *	*
	10  * *	*
	11  * *	*
	12  * *	*
	13  rip.Berkeley.EDU (  59 ms !  39 ms !	39 ms !

     Notice of the 12 ``gateways'' (13 is the final destination), exactly the
     half of them are ``missing''.  In this example, rip, a Sun-3 running Sun
     OS3.5, is using the TTL from the arriving datagram	as the TTL in its ICMP
     reply.  The reply will then time out on the return	path, with no notice
     sent to anyone since ICMP packets aren't sent for ICMP packets, until we
     probe with	a TTL that's at	least twice the	path length - that is, rip is
     really only 7 hops	away.  A reply that returns with a TTL of 1 is a clue
     this problem exists.  Traceroute prints a ``!'' after the time if the TTL
     is	<= 1.  Since some vendors ship obsolete	or nonstandard software,
     expect to see this	problem	frequently and/or take care selecting the
     target host of your probes.

     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 - neither of these should ever occur, and
     the associated gateway is broken if you see one).	If almost all the
     probes result in some kind	of unreachable,	traceroute will	give up	and

     (ttl=n!) indicates	that the TTL value in the ICMP TIME_EXCEEDED packet
     that we received was "unexpected".	 What we expect	is that	the value will
     be	(some initial value - the number of routers between us).  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	(some initial value - 4).
     Unfortunately, there are several common "initial value"s for ICMP TTLs.
     The most common are 255, 60, 59, 30, 29.  (IRIX, 4.3BSD-tahoe and cisco
     routers use 255, Proteon routers use either 59 or 29 depending on
     software release, several other implementations use 60 and	30.)
     Traceroute	checks against all of these, making it hard to detect some
     "off by one" routing asymmetries.	If you want to see all the TTL values
     in	all the	packets, use the -l option.

     For example,

	  % traceroute -g

     will show the path	from the Cambridge Mailbridge to PSC while

									Page 4


	  % traceroute -g -g

     shows how the Cambridge Mailbrige reaches Merit, by using PSC to reach
     the Mailbridge.

     This program is intended for use in network testing, measurement, and
     management.  It should be used primarily for manual fault isolation.  It
     is	unwise to use traceroute during	normal operations or from automated
     scripts due to the	load it	could impose on	the network.

AUTHORS    [Toc]    [Back]

     Van Jacobson, Steve Deering, C. Philip Wood, Tim Seaver, and Ken Adelman.

SEE ALSO    [Toc]    [Back]

     netstat(1), ping(1M)

									PPPPaaaaggggeeee 5555
[ Back ]
 Similar pages
Name OS Title
traceroute FreeBSD print the route packets take to network host
traceroute OpenBSD print the route packets take to network host
traceroute Tru64 Prints the route that packets take to a network host
traceroute6 FreeBSD print the route IPv6 packets will take to the destination
traceroute6 OpenBSD print the route IPv6 packets will take to the destination
ping HP-UX send ICMP Echo Request packets to network host
nsip OpenBSD software network interface encapsulating NS packets in IP packets
spray OpenBSD send many packets to host
spray FreeBSD send many packets to host
ipresend FreeBSD resend IP packets out to network
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service