unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (OSF1-V5.1-alpha)
Page:
Section:
Apropos / Subsearch:
optional field



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

  -g gateway
      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.

  -i if_addr
      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.

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

  -M  Sends the	response using a multicast path	rather than attempting a uni-
      cast first.

  -m max_hops
      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).

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

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

  -p  Listens passively	for multicast responses	from traces initiated by oth-
      ers.  This works best when run on	a multicast router.

  -r resp_dest
      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).

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

  -S stat_int
      Sets the interval	between	statistics gathering traces to stat_int
      seconds.	The default is 10 seconds.

  -t ttl
      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.

  -v  Prints a verbose form output, displaying hop times on initial trace and
      statistics.

  -w waittime
      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 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 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 statistics 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 particu-
  lar group, subject to	some constraints as detailed in	the following sec-
  tions.  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 minim-
  ized.

  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 a multicast router	along the path does not	implement the multicast	tra-
  ceroute 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 inter-
  faces	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), 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 probing 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 multicast 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

   1.  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	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 shows	the path in the	forward	direction with data
       flow indicated by arrows	pointing downward and the query	path indi-
       cated 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.  In the right half of this sec-
       tion are	several	columns	of statistics in two groups.  Within each
       group, the columns are the number of packets lost, the number of	pack-
       ets 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. 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 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.  With no
       options,	the second section of the output is printed once, approxi-
       mately 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 statis-
       tics 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 propagates,
       there may be small errors (off by 1 or 2) in these statistics.  How-
       ever, 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	nega-
       tive 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 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.

   2.  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 traceroute 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 Jacob-
  son 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.