MTRACE(8)                                                            MTRACE(8)



NAME
       mtrace - print multicast path from a source to a receiver

SYNOPSIS
       mtrace [ -g gateway ] [ -i if_addr ] [ -l ] [ -M ] [ -m max_hops ] [ -n
       ] [ -p ] [ -q nqueries ] [ -r resp_dest ] [ -s ] [ -S stat_int ]  [  -t
       ttl ] [ -v ] [ -w waittime ] source [ receiver ] [ group ]

DESCRIPTION
       Assessing  problems  in the distribution of IP multicast traffic can be
       difficult.  mtrace uses a  tracing  feature  implemented  in  multicast
       routers  (mrouted version 3.3 and later) that is accessed via an exten-
       sion to the IGMP protocol.  A trace query is  passed  hop-by-hop  along
       the  reverse  path  from  the  receiver  to  the source, collecting hop
       addresses, packet counts, and routing error conditions along the  path,
       and then the response is returned to the requestor.

       The  only  required  parameter is the source host name or address.  The
       default receiver is the host running mtrace, and the default  group  is
       "MBone  Audio"  (224.2.0.1), which is sufficient if packet loss statis-
       tics for a particular  multicast  group  are  not  needed.   These  two
       optional  parameters  may  be  specified to test the path to some other
       receiver in a particular group, subject to some constraints as detailed
       below.  The two parameters can be distinguished because the receiver is
       a unicast address and the group is a multicast address.

       NOTE: For Solaris 2.4/2.5,  if  the  multicast  interface  is  not  the
       default interface, the -i option must be used to set the local address.

OPTIONS
       -g gwy  Send the trace query via  unicast  directly  to  the  multicast
               router  gwy  rather  than multicasting the query.  This must be
               the last-hop router on the path from the intended source to the
               receiver.

               CAUTION!!   Versions  3.3  and  3.5  of mrouted will crash if a
                           trace query is received via a  unicast  packet  and
                           mrouted  has  no  route  for  the  source  address.
                           Therefore, do not use the -g option unless the tar-
                           get  mrouted  has  been verified to be 3.4 or newer
                           than 3.5.

       -i addr Use addr as the local interface address (on a multi-homed host)
               for sending the trace query and as the default for the receiver
               and the response destination.

       -l      Loop indefinitely printing packet rate and loss statistics  for
               the multicast path every 10 seconds (see -S stat_int).

       -M      Always send the response using multicast rather than attempting
               unicast first.

       -m n    Set to n the maximum number of hops that will  be  traced  from
               the  receiver  back  toward the source.  The default is 32 hops
               (infinity for the DVMRP routing protocol).

       -n      Print hop addresses numerically rather  than  symbolically  and
               numerically (saves a nameserver address-to-name lookup for each
               router found on the path).

       -q n    Set the maximum number of query attempts for any hop to n.  The
               default is 3.

       -p      Listen  passively for multicast responses from traces initiated
               by others.  This works best when run on a multicast router.

       -r host Send the trace response to host rather  than  to  the  host  on
               which mtrace is being run, or to a multicast address other than
               the one registered for this purpose (224.0.1.32).

       -s      Print a short form output including only the multicast path and
               not the packet rate and loss statistics.

       -S n    Change  the  interval  between statistics gathering traces to n
               seconds (default 10 seconds).

       -t ttl  Set the ttl (time-to-live, or number  of  hops)  for  multicast
               trace  queries  and  responses.   The default is 64, except for
               local queries to the "all routers" multicast  group  which  use
               ttl 1.

       -v      Verbose  mode;  show hop times on the initial trace and statis-
               tics display.

       -w n    Set the time to wait for a trace response to n seconds (default
               3 seconds).

USAGE
   How It Works
       The  technique  used  by  the  traceroute tool to trace unicast network
       paths will not work for IP multicast because ICMP responses are specif-
       ically forbidden for multicast traffic.  Instead, a tracing feature has
       been built into the multicast routers.  This technique has  the  advan-
       tage  that  additional information about packet rates and losses can be
       accumulated while the number of packets sent is minimized.

       Since multicast uses reverse path forwarding, the trace  is  run  back-
       wards from the receiver to the source.  A trace query packet is sent to
       the last hop multicast router (the leaf router for the desired receiver
       address).  The last hop router builds a trace response packet, fills in
       a report for its hop, and forwards the trace packet  using  unicast  to
       the router it believes is the previous hop for packets originating from
       the specified source.  Each router along the path adds its  report  and
       forwards  the packet.  When the trace response packet reaches the first
       hop router (the router that is directly connected to the source's net),
       that  router  sends  the completed response to the response destination
       address specified in the trace query.

       If some multicast router along the path does not implement  the  multi-
       cast  traceroute  feature  or if there is some outage, then no response
       will be returned.  To solve this problem, the trace  query  includes  a
       maximum  hop  count field to limit the number of hops traced before the
       response is returned.  That allows a partial path to be traced.

       The reports inserted by each router contain not only the address of the
       hop,  but  also  the ttl required to forward and some flags to indicate
       routing errors, plus counts of the  total  number  of  packets  on  the
       incoming  and outgoing interfaces and those forwarded for the specified
       group.  Taking differences in these counts for two traces separated  in
       time and comparing the output packet counts from one hop with the input
       packet counts of the next hop allows the calculation of packet rate and
       packet loss statistics for each hop to isolate congestion problems.

   Finding the Last-Hop Router
       The  trace query must be sent to the multicast router which is the last
       hop on the path from the source to the receiver.  If the receiver is on
       the  local  subnet  (as  determined  using  the  subnet mask), then the
       default method is to multicast the trace query to all-routers.mcast.net
       (224.0.0.2)  with  a ttl of 1.  Otherwise, the trace query is multicast
       to the group address since the last hop router will be a member of that
       group if the receiver is.  Therefore it is necessary to specify a group
       that the intended receiver has joined.  This multicast is sent  with  a
       default  ttl  of 64, which may not be sufficient for all cases (changed
       with the -t option).  If the last hop router is known, it may  also  be
       addressed  directly  using  the  -g  option).   Alternatively, if it is
       desired to trace a group that the receiver has not joined,  but  it  is
       known  that  the  last-hop  router is a member of another group, the -g
       option may also be used to specify a different  multicast  address  for
       the trace query.

       When  tracing  from  a  multihomed host or router, the default receiver
       address may not be the desired interface for the path from the  source.
       In  that  case, the desired interface should be specified explicitly as
       the receiver.

   Directing the Response
       By default, mtrace first attempts  to  trace  the  full  reverse  path,
       unless  the  number  of  hops  to  trace  is explicitly set with the -m
       option.  If there is no response within a  3  second  timeout  interval
       (changed with the -w option), a "*" is printed and the probing switches
       to hop-by-hop mode.  Trace queries are issued starting with  a  maximum
       hop count of one and increasing by one until the full path is traced or
       no response is  received.   At  each  hop,  multiple  probes  are  sent
       (default  is  three,  changed  with  -q option).  The first half of the
       attempts (default is one) are made with the unicast address of the host
       running  mtrace as the destination for the response.  Since the unicast
       route may be blocked,  the  remainder  of  attempts  request  that  the
       response be multicast to mtrace.mcast.net (224.0.1.32) with the ttl set
       to 32 more than what's needed to pass the thresholds seen so far  along
       the  path  to  the  receiver.   For  the  last  quarter of the attempts
       (default is one), the ttl is increased by another 32 each time up to  a
       maximum  of 192.  Alternatively, the ttl may be set explicitly with the
       -t option and/or the initial unicast attempts can be forced to use mul-
       ticast instead with the -M option.  For each attempt, if no response is
       received within the timeout, a "*" is  printed.   After  the  specified
       number  of  attempts have failed, mtrace will try to query the next hop
       router with a DVMRP_ASK_NEIGHBORS2 request (as used by the mrinfo  pro-
       gram) to see what kind of router it is.

EXAMPLES
       The  output of mtrace is in two sections.  The first section is a short
       listing of the hops in the order they are  queried,  that  is,  in  the
       reverse  of the order from the source to the receiver.  For each hop, a
       line is printed showing the hop number (counted negatively to  indicate
       that  this is the reverse path); the multicast routing protocol (DVMRP,
       MOSPF, PIM, etc.); the threshold required to forward data (to the  pre-
       vious  hop  in the listing as indicated by the up-arrow character); and
       the cumulative delay for the query to reach that hop (valid only if the
       clocks  are synchronized).  This first section ends with a line showing
       the round-trip time which measures the interval from when the query  is
       issued until the response is received, both derived from the local sys-
       tem clock.  A sample use and output might be:

       oak.isi.edu 80# mtrace -l caraway.lcs.mit.edu 224.2.0.3
       Mtrace from 18.26.0.170 to 128.9.160.100 via group 224.2.0.3
       Querying full reverse path...
         0  oak.isi.edu (128.9.160.100)
        -1  cub.isi.edu (128.9.160.153)  DVMRP  thresh^ 1  3 ms
        -2  la.dart.net (140.173.128.1)  DVMRP  thresh^ 1  14 ms
        -3  dc.dart.net (140.173.64.1)  DVMRP  thresh^ 1  50 ms
        -4  bbn.dart.net (140.173.32.1)  DVMRP  thresh^ 1  63 ms
        -5  mit.dart.net (140.173.48.2)  DVMRP  thresh^ 1  71 ms
        -6  caraway.lcs.mit.edu (18.26.0.170)
       Round trip time 124 ms

       The second section provides a pictorial view of the path in the forward
       direction  with data flow indicated by arrows pointing downward and the
       query path indicated by arrows pointing upward.  For each hop, both the
       entry  and  exit  addresses of the router are shown if different, along
       with the initial ttl required on the packet in order to be forwarded at
       this  hop  and  the  propagation delay across the hop assuming that the
       routers at both ends have synchronized clocks.  The right half of  this
       section  is  composed  of  several columns of statistics in two groups.
       Within each group, the columns are the number of packets lost, the num-
       ber  of  packets sent, the percentage lost, and the average packet rate
       at each hop.  These statistics are calculated from differences  between
       traces  and  from hop to hop as explained above.  The first group shows
       the statistics for all traffic flowing out the interface at one hop and
       in  the  interface at the next hop.  The second group shows the statis-
       tics only for traffic forwarded from the specified source to the speci-
       fied group.

       These  statistics  are shown on one or two lines for each hop.  Without
       any options, this second section of the output is  printed  only  once,
       approximately  10  seconds  after the initial trace.  One line is shown
       for each hop showing the statistics over that 10-second period.  If the
       -l option is given, the second section is repeated every 10 seconds and
       two lines are shown for each hop.  The first line shows the  statistics
       for  the last 10 seconds, and the second line shows the cumulative sta-
       tistics over the period since the initial trace, which is  101  seconds
       in  the  example below.  The second section of the output is omitted if
       the -s option is set.

       Waiting to accumulate statistics... Results after 101 seconds:

         Source       Response Dest  Packet Statistics For  Only For Traffic
       18.26.0.170    128.9.160.100  All Multicast Traffic  From 18.26.0.170
            |       __/ rtt  125 ms  Lost/Sent = Pct  Rate    To 224.2.0.3
            v      /    hop   65 ms  ---------------------  ------------------
       18.26.0.144
       140.173.48.2   mit.dart.net
            |     ^     ttl    1      0/6    = --%   0 pps   0/2  = --%  0 pps
            v     |     hop    8 ms   1/52   =  2%   0 pps   0/18 =  0%  0 pps
       140.173.48.1
       140.173.32.1   bbn.dart.net
            |     ^     ttl    2      0/6    = --%   0 pps   0/2  = --%  0 pps
            v     |     hop   12 ms   1/52   =  2%   0 pps   0/18 =  0%  0 pps
       140.173.32.2
       140.173.64.1   dc.dart.net
            |     ^     ttl    3      0/271  =  0%  27 pps   0/2  = --%  0 pps
            v     |     hop   34 ms  -1/2652 =  0%  26 pps   0/18 =  0%  0 pps
       140.173.64.2
       140.173.128.1  la.dart.net
            |     ^     ttl    4     -2/831  =  0%  83 pps   0/2  = --%  0 pps
            v     |     hop   11 ms  -3/8072 =  0%  79 pps   0/18 =  0%  0 pps
       140.173.128.2
       128.9.160.153  cub.isi.edu
            |      \__  ttl    5        833         83 pps     2         0 pps
            v         \ hop   -8 ms     8075        79 pps     18        0 pps
       128.9.160.100  128.9.160.100
         Receiver     Query Source

       Because the packet counts may be changing as the trace query is  propa-
       gating,  there may be small errors (off by 1 or 2) in these statistics.
       However, those errors should not accumulate, so the cumulative  statis-
       tics  line  should  increase in accuracy as a new trace is run every 10
       seconds.  There are two sources of larger errors, both of which show up
       as negative losses:

                If  the  input  to a node is from a multi-access network with
                 more than one other node attached, then the input count  will
                 be  (close  to)  the  sum  of  the output counts from all the
                 attached nodes, but the output count from the previous hop on
                 the  traced path will be only part of that.  Hence the output
                 count minus the input count will be negative.
                In release 3.3 of the DVMRP multicast forwarding software for
                 SunOS  and  other  systems, a multicast packet generated on a
                 router will be counted as having come in  an  interface  even
                 though  it  did not.  This creates the negative loss that can
                 be seen in the example above.

       Note that these negative losses may mask positive losses.

       In the example, there is also one negative hop time.  This simply indi-
       cates  a  lack of synchronization between the system clocks across that
       hop.  This example also illustrates how the percentage loss is shown as
       two  dashes when the number of packets sent is less than 10 because the
       percentage would not be statistically valid.

       A second example shows a trace to a receiver that  is  not  local;  the
       query is sent to the last-hop router with the -g option.  In this exam-
       ple, the trace of the full reverse path resulted in no response because
       there  was a node running an old version of mrouted that did not imple-
       ment the multicast traceroute function, so mtrace switched  to  hop-by-
       hop  mode.   The  "Route  pruned" error code indicates that traffic for
       group 224.2.143.24 would not be forwarded.

       oak.isi.edu 108# mtrace -g 140.173.48.2 204.62.246.73 \
                                  butter.lcs.mit.edu 224.2.143.24
       Mtrace from 204.62.246.73 to 18.26.0.151 via group 224.2.143.24
       Querying full reverse path... * switching to hop-by-hop:
         0  butter.lcs.mit.edu (18.26.0.151)
        -1  jam.lcs.mit.edu (18.26.0.144)  DVMRP  thresh^ 1  33 ms  Route pruned
        -2  bbn.dart.net (140.173.48.1)  DVMRP  thresh^ 1  36 ms
        -3  dc.dart.net (140.173.32.2)  DVMRP  thresh^ 1  44 ms
        -4  darpa.dart.net (140.173.240.2)  DVMRP  thresh^ 16  47 ms
        -5  * * * noc.hpc.org (192.187.8.2) [mrouted 2.2] didn't respond
       Round trip time 95 ms

AUTHOR
       Implemented by Steve Casner based on an initial  prototype  written  by
       Ajit  Thyagarajan.   The multicast traceroute mechanism was designed by
       Van Jacobson with help from Steve Casner,  Steve  Deering,  Dino  Fari-
       nacci, and Deb Agrawal; it was implemented in mrouted by Ajit Thyagara-
       jan and Bill Fenner.  The option syntax and the output format of mtrace
       are  modeled after the unicast traceroute program written by Van Jacob-
       son.

SEE ALSO
       mrouted(8), mrinfo(8), map-mbone(8), traceroute(8)



4.3 Berkeley Distribution         May 8, 1995                        MTRACE(8)

You can also request any man page by name and (optionally) by section:

Command: 
Section: 
Architecture: 
Collection: 
 

Use the DEFAULT collection to view manual pages for third-party software.


©1994 Man-cgi 1.15, Panagiotis Christias <christia@softlab.ntua.gr>
©1996-2014 Modified for NetBSD by Kimmo Suominen