traceroute-nanog


SYNOPSIS
       traceroute [ options ] host [ size ]

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

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

       -m max_ttl
              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.

       -p port
              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)
              (default 3).

       -r     Set Dont Route option, advising routers to drop the packets.  In
              other words, only probe within the local subnet.

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

       -S min_ttl
              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
              probe arrives.

       -$     Send out nothing but a single ping with a  very  large  time-to-
              live.

DIAGNOSTICS
       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-
              able.

       !N     Received  a  reply  telling  that  the  destination  network  is
              unreachable.

       !P     Received a reply telling that the desired protocol  is  unavail-
              able.

       !S     Received  a  reply  telling  that source routing failed.  Should
              never occur--unless the probed gateway is screwed.

               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 & 3 are the same.  This is due to a buggy  kernel  on
       the  2nd  hop  system  -- lbl-csam.arpa -- that forwards packets with a
       zero TTL.

       A more interesting example is:

              [yak 72]% 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

       (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.[23]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-
       tion 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

       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.

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

       RA_SERVER
              Server to issue a RADB whois query on, given either as hostname,
              or dotted-quad IP address.  Defaults to whois.ra.net.

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

       DATA_DELIMITER
              Each  line  containing an ASN starts with this tag.  Defaults to
              origin:.

       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.

       ROUTE_DELIMITER
              Each line containing  a  subnet  entry  starts  with  this  tag.
              Defaults to route:.

       PREFIX_DELIMITER
              The  network  IP  and  the  prefix  are  separated  by this tag.
              Defaults to /.

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

SEE ALSO
       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 - 2017 Hurricane Electric. All Rights Reserved.