incoming and outgoing interfaces and those forwarded for the specified.IR group .Taking differences in these counts for two traces separated in timeand comparing the output packet counts from one hop with the inputpacket counts of the next hop allows the calculation of packet rateand packet loss statistics for each hop to isolate congestionproblems..SS Finding the Last-Hop RouterThe trace query must be sent to the multicast router which is thelast hop on the path from the.I sourceto the.IR receiver .If the receiver is on the local subnet (as determined using the subnetmask), then the default method is to multicast the trace query toall-routers.mcast.net (224.0.0.2) with a ttl of 1.  Otherwise, thetrace query is multicast to the.I groupaddress since the last hop router will be a member of that group ifthe receiver is.  Therefore it is necessary to specify a group thatthe intended receiver has joined.  This multicast is sent with adefault ttl of 127, which may not be sufficient for all cases (changedwith the.B \-toption).If the last hop router is known, it may also be addressed directlyusing the.B \-goption).  Alternatively, if it is desired to trace a group that thereceiver has not joined, but it is known that the last-hop router is amember of another group, the.B \-goption may also be used to specify a different multicast address for thetrace query..PPWhen tracing from a multihomed host or router, the default receiveraddress may not be the desired interface for the path from the source.In that case, the desired interface should be specified explicitly asthe.IR receiver ..SS Directing the ResponseBy default,.B mtracefirst attempts to trace the full reverse path, unless the number ofhops to trace is explicitly set with the.B \-moption.  If there is no response within a 3 second timeout interval(changed with the.B \-woption), a "*" is printed and the probing switches to hop-by-hop mode.Trace queries are issued starting with a maximum hop count of one andincreasing by one until the full path is traced or no response isreceived.  At each hop, multiple probes are sent (default is three,changed with.B \-qoption).  The first half of the attempts (default is two) are made withthe reply address set to standard multicast address, mtrace.mcast.net(224.0.1.32) with the ttl set to 32 more than what's needed to pass thethresholds seen so far along the path to the receiver.  For eachadditional attempt, the ttl is increased by another 32 each time up toa maximum of 192.  Since the desired router may not be able to send amulticast reply, the remainder of the attempts request that theresponse be sent via unicast to the host running.B mtrace .Alternatively, the multicast ttl may be set explicitly with the.B \-toption, the initial multicast attempts can be forced to use unicastinstead with the.B \-Uoption, the final unicast attempts can be forced to use multicastisntead with the.B \-Moption, or if you specify.B \-UM.B mtracewill first attempt using unicast and then multicast.  For each attempt,if no response is received within the timeout, a "*" is printed.  Afterthe specified number of attempts have failed,.B mtracewill try to query the next hop router with a DVMRP_ASK_NEIGHBORS2request (as used by the.B mrinfoprogram) to see what kind of router it is..B mtracewill try to query three (changed with the.B \-eoption) hops past a non-responding router, in the hopes that eventhough it isn't capable of sending a response, it might be capable offorwarding the request on..SH EXAMPLESThe output of.B mtraceis in two sections.  The first section is a short listing of the hopsin the order they are queried, that is, in the reverse of the orderfrom the.I sourceto the.IR receiver .For each hop, a line is printed showing the hop number (countednegatively to indicate that this is the reverse path); the multicastrouting protocol (DVMRP, MOSPF, PIM, etc.); the threshold required toforward data (to the previous hop in the listing as indicated by theup-arrow character); and the cumulative delay for the query to reachthat hop (valid only if the clocks are synchronized).  This firstsection ends with a line showing the round-trip time which measuresthe interval from when the query is issued until the response isreceived, both derived from the local system clock, and the totalttl required for a packet to travel along this path.  A sample use andoutput might be:.PP.nf.ft Coak.isi.edu 80# mtrace -l caraway.lcs.mit.edu 224.2.0.3Mtrace from 18.26.0.170 to 128.9.160.100 via group 224.2.0.3Querying 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; total ttl of 6 required..fi.PPIf a hop reports that it is using the default route to forward packets,the word.B [default]is printed after that hop.  If the.B \-vflag is supplied, the route being used to forward packets is printedin the form.B [18.26.0/24] ..PPThe second section provides a pictorial view of the path in theforward direction with data flow indicated by arrows pointing downwardand the query path indicated by arrows pointing upward.  For each hop,both the entry and exit addresses of the router are shown ifdifferent, along with the initial ttl required on the packet in orderto be forwarded at this hop and the propagation delay across the hopassuming that the routers at both ends have synchronized clocks.The right half of this section is composed of two sets of statistics.The first column contains the average packet rate for all traffic ateach hop.The remaining columns are thenumber of packets lost, the number of packets sent, the percentagelost, and the average packet rate at each hop.  These statistics arecalculated from differences between traces and from hop to hop asexplained above.  The first group shows the statistics for all trafficflowing out the interface at one hop and in the interface at the nexthop.  The second group shows the statistics only for traffic forwardedfrom the specified.I sourceto the specified.IR group .The first group of statistics may be expanded to include loss ratesusing the.B \-Toption.  However, these numbers can be extremely misleading and requiredetailed knowledge of the routers involved to be interpreted properly..PPThese statistics are shown on one or two lines for each hop.  Withoutany options, this second section of the output is printed only once,approximately 10 seconds after the initial trace.  One line is shownfor each hop showing the statistics over that 10-second period.  Ifthe.B \-loption is given, the second section is repeated every 10 seconds andtwo lines are shown for each hop.  The first line shows the statisticsfor the last 10 seconds, and the second line shows the cumulativestatistics over the period since the initial trace, which is 101seconds in the example below.  The second section of the output isomitted if the.B \-soption is set or if no multicast group is specified..ie t \{\.ft C.  ie \w'i'<>\w'm' \{\" looks like this is not proper Courier font(If this example is not properly columned with a fixed-width font, get.B groffand try again.).  \}.\}.PP.ft C.nfWaiting to accumulate statistics... Results after 101 seconds:  Source       Response Dest    Overall   Packet Statistics For Traffic From18.26.0.170    128.9.160.100    Packet    18.26.0.170 To 224.2.0.3     |       __/ rtt  125 ms     Rate     Lost/Sent = Pct  Rate     v      /    hop   65 ms    -------   ---------------------18.26.0.144    140.173.48.2   mit.dart.net               |     ^     ttl    1         0 pps      0/2  = --%  0 pps     v     |     hop    8 ms      0 pps      0/18 =  0%  0 pps140.173.48.1   140.173.32.1   bbn.dart.net     |     ^     ttl    2         0 pps      0/2  = --%  0 pps     v     |     hop   12 ms      0 pps      0/18 =  0%  0 pps140.173.32.2   140.173.64.1   dc.dart.net      |     ^     ttl    3        27 pps      0/2  = --%  0 pps     v     |     hop   34 ms     26 pps      0/18 =  0%  0 pps140.173.64.2   140.173.128.1  la.dart.net     |     ^     ttl    4        83 pps      0/2  = --%  0 pps     v     |     hop   11 ms     79 pps      0/18 =  0%  0 pps140.173.128.2  128.9.160.153  cub.isi.edu     |      \\__  ttl    5        83 pps      ?/2         0 pps     v         \\ hop   -8 ms     79 pps      ?/18        0 pps128.9.160.100  128.9.160.100  Receiver     Query Source.fi.PPBecause the packet counts may be changing as the trace query ispropagating, there may be small errors (off by 1 or 2) in thesestatistics.  However, those errors should not accumulate, so thecumulative statistics line should increase in accuracy as a new traceis run every 10 seconds.  There are two sources of larger errors, bothof which show up as negative losses:.LP.RS.PD 0.TP 3\(buIf the input to a node is from a multi-access network with more thanone other node attached, then the input count will be (close to) thesum of the output counts from all the attached nodes, but the outputcount from the previous hop on the traced path will be only part ofthat.  Hence the output count minus the input count will be negative..TP 3\(buIn release 3.3 of the DVMRP multicast forwarding software for SunOSand other systems, a multicast packet generated on a router will becounted as having come in an interface even though it did not.  Thiscreates the negative loss that can be seen in the example above..PD.RE.LPNote that these negative losses may mask positive losses..PPIn the example, there is also one negative hop time.  This simplyindicates a lack of synchronization between the system clocks acrossthat hop.  This example also illustrates how the percentage loss isshown as two dashes when the number of packets sent is less than 10because the percentage would not be statistically valid..PPA second example shows a trace to a receiver that is not local; thequery is sent to the last-hop router with the.B \-goption.  In this example, the trace of the full reverse path resultedin no response because there was a node running an old version of.B mroutedthat did not implement the multicast traceroute function, so.B mtraceswitched to hop-by-hop mode.  The \*(lqOutput pruned\*(rq error codeindicates that traffic for group 224.2.143.24 would not be forwarded..PP.nf.ft Coak.isi.edu 108# mtrace -g 140.173.48.2 204.62.246.73 \\                           butter.lcs.mit.edu 224.2.143.24Mtrace from 204.62.246.73 to 18.26.0.151 via group 224.2.143.24Querying 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  Output 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 respondRound trip time 95 ms.fi.SH AUTHORImplemented by Steve Casner based on an initial prototype written byAjit Thyagarajan.  The multicast traceroute mechanism was designed byVan Jacobson with help from Steve Casner, Steve Deering, DinoFarinacci, and Deb Agrawal; it was implemented in.B mroutedby Ajit Thyagarajan and Bill Fenner.  The option syntax and the outputformat of.B mtraceare modeled after the unicast.B tracerouteprogram written by Van Jacobson. .SH SEE ALSO.BR mrouted (8) ,.BR mrinfo (8) ,.BR map-mbone (8) ,.BR traceroute (8).SH BUGS.PPStatistics collection in passive mode doesn't always produce the same outputas when actively collecting data.