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

  man pages->OpenBSD man pages -> mtrace (8)              



NAME    [Toc]    [Back]

     mtrace - print multicast path from a source to a receiver

SYNOPSIS    [Toc]    [Back]

     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    [Toc]    [Back]

     Assessing problems in the distribution of IP multicast traffic can be
     difficult.  mtrace utilizes a tracing feature implemented in
     routers (mrouted version 3.3 and later) that is accessed via
an extension
     to  the  IGMP  protocol.  A trace query is passed hop-by-hop
along the reverse
 path from the receiver to the source,  collecting  hop
     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" (, which  is  sufficient  if  packet
loss statistics
     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.

     The options are as follows:

     -g  gwy    Send  the trace query via unicast directly to the
              router gwy  rather  than  multicasting  the  query.
This must be the
              last-hop  router  on  the  path  from  the intended
source to the
              receiver.  NOTE: Read the BUGS section below.

     -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

     -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

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

     -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
              trace  queries  and  responses.  The default is 64,
except for local
 queries to the "all  routers"  multicast  group
which use ttl

     -v        Verbose  mode; show hop times on the initial trace
and statistics

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

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

     Since multicast uses reverse path forwarding, the  trace  is
run backwards
     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 multicast
     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
     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    [Toc]    [Back]
     The trace query must be sent to the multicast  router  which
is the last
     hop  on  the path from the 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
( 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
     receiver  is  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 lasthop 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

   Directing the Response    [Toc]    [Back]
     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
     -m  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
     (  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 multicast 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 program) to see what kind of router it is.

EXAMPLES    [Toc]    [Back]

     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 to the 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 previous 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
     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 system clock.  A  sample use and
     output might be:

     oak.isi.edu 80# mtrace -l caraway.lcs.mit.edu
     Mtrace from to via group
     Querying full reverse path...
       0  oak.isi.edu (
      -1  cub.isi.edu (  DVMRP  thresh^ 1  3 ms
      -2  la.dart.net (  DVMRP  thresh^ 1  14 ms
      -3  dc.dart.net (  DVMRP  thresh^ 1  50 ms
      -4  bbn.dart.net (  DVMRP  thresh^ 1  63 ms
      -5  mit.dart.net (  DVMRP  thresh^ 1  71 ms
      -6  caraway.lcs.mit.edu (
     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  number 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 statistics only
for traffic
     forwarded from the specified source to the specified  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 statistics 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

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

       Source        Response  Dest   Packet Statistics For  Only
For Traffic  All  Multicast  Traffic   From
          |        __/  rtt   125 ms  Lost/Sent = Pct  Rate    To
          v       /      hop     65   ms    ---------------------
------------------   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   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   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  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  cub.isi.edu
          |       __   ttl     5         833         83 pps     2
0 pps
          v          hop   -8 ms     8075         79  pps      18
0 pps
       Receiver     Query Source

     Because the packet counts may be changing as the trace query
is propagating,
 there may be small errors (off by  1  or  2)  in  these
statistics.  However,
  those errors should not accumulate, so the cumulative
     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

         +o   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.

         +o    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

     Note that these negative losses may mask positive losses.

     In  the  example, there is also one negative hop time.  This
simply indicates
 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
example, 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 implement the multicast
 traceroute function, so mtrace switched to hop-by-hop
mode.  The
     "Route pruned" error code indicates that traffic  for  group
     would not be forwarded.

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

SEE ALSO    [Toc]    [Back]

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

AUTHORS    [Toc]    [Back]

     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
Farinacci, and
     Deb Agrawal; it was implemented in mrouted by Ajit Thyagarajan and Bill
     Fenner.  The option syntax and the output format  of  mtrace
are modeled
     after  the  unicast traceroute program written by Van Jacobson.

BUGS    [Toc]    [Back]

     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
     Therefore, do not  use  the  -g  option  unless  the  target
mrouted has been
     verified to be 3.4 or newer than 3.5.

OpenBSD      3.6                            May      8,      1995
[ Back ]
 Similar pages
Name OS Title
cstr Linux print out string literals in C source code
recserv HP-UX HP SharedX Receiver Service
readcomponent IRIX sets the component source within the framebuffer source for pixels that various routines read, useful primaril
uart FreeBSD driver for Universal Asynchronous Receiver/Transmitter (UART) devices
cdptrec Tru64 Read Path Table Record from the CD-ROM Path Table
multicast FreeBSD Multicast Routing
map-mbone OpenBSD Multicast connection mapper
mrouted HP-UX IP multicast routing daemon
mrouted IRIX IP multicast routing daemon
map-mbone FreeBSD multicast connection mapper
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service