mtrace man page on OSF1

Man page or keyword search:  
man Server   12896 pages
apropos Keyword Search (all sections)
Output format
OSF1 logo
[printable version]

mtrace(8)							     mtrace(8)

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

SYNOPSIS
       /usr/bin/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]

OPTIONS
       Sends  the  trace query directly to the multicast router gateway 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 the mrouted daemon will crash if a trace
	      query is received in a unicast packet and mrouted has  no	 route
	      for  the	source	address.   Therefore, do not use the -g option
	      unless the target version of mrouted is  Version	3.4  or	 later
	      than  Version  3.5.   Specifies  if_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.
	      Loops indefinitely printing the packet rate and loss  statistics
	      for  the	multicast path every 10 seconds.  Use the -S option to
	      change the time interval.	 Sends the response using a  multicast
	      path  rather  than attempting a unicast first.  Sets the maximum
	      number of hops to be traced from the receiver  back  toward  the
	      source  to  max_hops.  The  default is 32 hops (infinity for the
	      DVMRP  routing  protocol).   Prints  hop	addresses  numerically
	      rather  than  symbolically  and  numerically (saves a nameserver
	      address-to-name lookup for each router found on the path).  Sets
	      the  maximum  number  of query attempts for any hop to nqueries.
	      The default is 3.	 Listens  passively  for  multicast  responses
	      from  traces initiated by others.	 This works best when run on a
	      multicast router.	 Sends 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).   Prints  a	 short	form output including only the
	      multicast path and not the  packet  rate	and  loss  statistics.
	      Sets   the  interval  between  statistics	 gathering  traces  to
	      stat_int seconds.	 The default is	 10  seconds.	Sets  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.  Prints a
	      verbose form output, displaying hop times on initial  trace  and
	      statistics.   Sets  the  time  to wait for a trace response to n
	      seconds. The default is 3 seconds.

DESCRIPTION
       The mtrace program utilizes a tracing feature implemented in  multicast
       routers	(mrouted  Version 3.3 and later) that is accessed by 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.
       The response is then returned to the requester.

       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.  You can  specify
       the  receiver  and  group  parameters  to  test	the path to some other
       receiver in a particular group, subject to some constraints as detailed
       in  the	following  sections.   The two parameters can be distinguished
       because the receiver is a unicast address and the group is a  multicast
       address.

   How mtrace Works
       The  technique  used  by	 the  traceroute tool to trace unicast network
       paths does not work for IP multicast because Internet  Control  Message
       Protocol	 (ICMP)	 responses  are	 specifically  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 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  a  multicast router along the path does not implement the multicast
       traceroute feature or if there is an outage, no response	 is  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 the address of the hop, the
       ttl required to forward, some options to indicate routing  errors,  and
       the  counts of the total number of packets on the incoming and outgoing
       interfaces and those forwarded for the specified group.	Taking differ‐
       ences  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 sta‐
       tistics 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),  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 the
       same group as the receiver.  Therefore you must 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 you want to
       trace  a	 group that the receiver has not joined, but you know that the
       last-hop router is a member of another group, you can use the -g option
       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, explicitly specify the desired interface 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), an asterisk (*) is printed and the	 prob‐
       ing  switches  to  hop-by-hop  mode.  Trace queries are issued starting
       with a maximum hop count of 1 and increasing by 1 until the  full  path
       is traced or no response is received.  At each hop, multiple probes are
       sent (default is 3, changed with -q option).  The  first	 half  of  the
       attempts	 (default  is 1) 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 that needed to pass the thresholds encountered so far
       along the path to the receiver.	For the last quarter of	 the  attempts
       (default	 is  1),  the ttl is increased by another 32 each time up to a
       maximum of 192.	Alternatively, you can set the ttl explicitly with the
       -t  option  or the initial unicast attempts can be forced to use multi‐
       cast instead with the -M option.	 For each attempt, if no  response  is
       received	 within	 the  timeout,	an asterisk (*) is printed.  After the
       specified number of attempts have failed, mtrace	 tries	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
       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 that shows the hop number (counted negatively to indi‐
       cate that this is the reverse path);  the  multicast  routing  protocol
       (DVMRP,	MOSPF, or PIM); 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 synchronized).  This first section ends with a line that
       shows  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: # mtrace -l car‐
       away.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 shows 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  differ‐
	      ent,  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.  In the right half of this section are  several  columns
	      of statistics in two groups.  Within each group, the columns are
	      the number of packets lost, the number of packets sent, the per‐
	      centage  lost,  and  the average packet rate at each hop.	 These
	      statistics are calculated from differences  between  traces  and
	      from  hop	 to  hop. The first group shows the statistics for all
	      traffic flowing out of the interface at one  hop	and  into  the
	      interface	 at  the next hop.  The second group shows the statis‐
	      tics only for traffic forwarded from the specified source to the
	      specified group.

	      These  statistics	 are  shown  on one or two lines for each hop.
	      With no options, the second section of  the  output  is  printed
	      once,  approximately  10	seconds	 after the initial trace.  For
	      each hop, one line is printed that  shows	 the  statistics  over
	      that  10-second  period.	 If the -l option is given, the second
	      section repeats every 10 seconds and two lines are  printed  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 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 change as the trace	 query	propa‐
	      gates,  there  may be small errors (off by 1 or 2) in these sta‐
	      tistics.	However, those errors should not  accumulate,  so  the
	      cumulative statistics 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 multiaccess 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 some 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 previous example.

	      Note that these negative losses may mask positive losses.

	      In the example, there is also one negative hop time.  This 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.
	      The following 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  tracer‐
	      oute  function,  so  mtrace  switched  to	 hop-by-hop mode.  The
	      “Route pruned” error  code  indicates  that  traffic  for	 group
	      224.2.143.24  will  not  be forwarded.  # 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

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

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.

								     mtrace(8)
[top]
                             _         _         _ 
                            | |       | |       | |     
                            | |       | |       | |     
                         __ | | __ __ | | __ __ | | __  
                         \ \| |/ / \ \| |/ / \ \| |/ /  
                          \ \ / /   \ \ / /   \ \ / /   
                           \   /     \   /     \   /    
                            \_/       \_/       \_/ 
More information is available in HTML format for server OSF1

List of man pages available for OSF1

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net