1 .\" Copyright (c) 1995 by the University of Southern California
2 .\" All rights reserved.
4 .\" Permission to use, copy, modify, and distribute this software and its
5 .\" documentation in source and binary forms for non-commercial purposes
6 .\" and without fee is hereby granted, provided that the above copyright
7 .\" notice appear in all copies and that both the copyright notice and
8 .\" this permission notice appear in supporting documentation, and that
9 .\" any documentation, advertising materials, and other materials related
10 .\" to such distribution and use acknowledge that the software was
11 .\" developed by the University of Southern California, Information
12 .\" Sciences Institute. The name of the University may not be used to
13 .\" endorse or promote products derived from this software without
14 .\" specific prior written permission.
16 .\" THE UNIVERSITY OF SOUTHERN CALIFORNIA makes no representations about
17 .\" the suitability of this software for any purpose. THIS SOFTWARE IS
18 .\" PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES,
19 .\" INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
20 .\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
22 .\" Other copyrights might apply to parts of this software and are so
23 .\" noted when applicable.
25 .\" This manual page (but not the software) was derived from the
26 .\" manual page for the traceroute program which bears the following
29 .\" Copyright (c) 1988 The Regents of the University of California.
30 .\" All rights reserved.
39 .Nd print multicast path from a source to a receiver
65 Assessing problems in the distribution of IP multicast traffic
69 utility utilizes a tracing feature implemented in multicast routers that is
70 accessed via an extension to the IGMP protocol.
72 passed hop-by-hop along the reverse path from the
76 collecting hop addresses, packet counts, and routing error conditions
77 along the path, and then the response is returned to the requestor.
79 The only required parameter is the
84 is the host running mtrace, and the default
86 is 0.0.0.0, which is sufficient if packet loss
87 statistics for a particular multicast group are not needed.
89 optional parameters may be specified to test the path to some other
90 receiver in a particular group, subject to some constraints as
92 The two parameters can be distinguished because the
94 is a unicast address and the
96 is a multicast address.
99 flag is specified, the source address defaults to the host running
101 and the receiver defaults to the router being addressed with
105 In this case, there are no required parameters.
107 NOTE: For Solaris 2.4/2.5, if the multicast interface is not the default
110 option must be used to set the local address.
112 The following options are available:
113 .Bl -tag -width indent
114 .It Fl e Ar extrahops
117 hops past a non-responding router.
119 Send the trace query via unicast directly to the multicast router
121 rather than multicasting the query.
122 This must be the last-hop router on the path from the intended
128 Versions 3.3 and 3.5 of
130 will crash if a trace query is received via a
136 Therefore, do not use the
138 option unless the target
140 has been verified to be 3.4 or newer than 3.5.
144 as the local interface address (on a multi-homed host) for sending the
145 trace query and as the default for the
147 and the response destination.
149 Loop indefinitely printing packet rate and loss statistics for the
150 multicast path every 10 seconds (see
151 .Fl S Ar stat_int ) .
153 Always request the response using multicast rather than attempting
154 unicast for the last half of the tries.
158 the maximum number of hops that will be traced from the
162 The default is 32 hops (infinity for the DVMRP routing protocol).
164 Print hop addresses numerically rather than symbolically and numerically
165 (saves a nameserver address-to-name lookup for each router found on the
168 Set the maximum number of query attempts for any hop to
172 Do not use the Router-Alert IP option on those requests which need it.
173 Some versions of Cisco's IOS cannot handle
174 multicast traceroutes with IP options, so it may be necessary to use the
176 flag if the last-hop router is a Cisco.
178 Listen passively for multicast responses from traces initiated by
180 This works best when run on a multicast router.
182 Loop indefinitely collecting the path every 10 seconds (see
184 and printing it when it changes.
185 Do not print any statistics.
187 Send the trace response to
189 rather than to the host on which
191 is being run, or to a multicast address other than the one registered
192 for this purpose (224.0.1.32).
194 Print a short form output including only the multicast path and not
195 the packet rate and loss statistics.
197 Change the interval between statistics gathering traces to
199 seconds (default 10 seconds).
203 (time-to-live, or number of hops) for multicast trace queries and
205 The default is 127, except for local queries to the "all
206 routers" multicast group which use ttl 1.
208 "Tunnel statistics" mode; show loss rates for overall traffic.
209 These statistics can be extremely misleading.
211 Always request the response using unicast rather than attempting
214 Verbose mode; show hop times on the initial trace and statistics display.
215 Also show the route that was used to forward the initial trace.
217 Set the time to wait for a trace response to
219 seconds (default 3 seconds).
223 The technique used by the
225 utility to trace unicast network paths will not work for IP multicast
226 because ICMP responses are specifically forbidden for multicast traffic.
227 Instead, a tracing feature has been built into the multicast routers.
228 This technique has the advantage that additional information about
229 packet rates and losses can be accumulated while the number of packets
233 reverse path forwarding, the trace is run backwards from the
237 A trace query packet is sent to the last
238 hop multicast router (the leaf router for the desired
241 The last hop router builds a trace response packet, fills in
242 a report for its hop, and forwards the trace packet using unicast to
243 the router it believes is the previous hop for packets originating
246 Each router along the path adds its report and forwards the packet.
247 When the trace response packet reaches the first hop router (the router
248 that is directly connected to the source's net), that router sends the
249 completed response to the response destination address specified in
252 If some multicast router along the path does not implement the
253 multicast traceroute feature or if there is some outage, then no
254 response will be returned.
255 To solve this problem, the trace query
256 includes a maximum hop count field to limit the number of hops traced
257 before the response is returned.
258 That allows a partial path to be
261 The reports inserted by each router contain not only the address of
262 the hop, but also the ttl required to forward and some flags to indicate
263 routing errors, plus counts of the total number of packets on the
264 incoming and outgoing interfaces and those forwarded for the specified
266 Taking differences in these counts for two traces separated in time
267 and comparing the output packet counts from one hop with the input
268 packet counts of the next hop allows the calculation of packet rate
269 and packet loss statistics for each hop to isolate congestion
271 .Ss Finding the Last-Hop Router
272 The trace query must be sent to the multicast router which is the
273 last hop on the path from the
277 If the receiver is on the local subnet (as determined using the subnet
278 mask), then the default method is to multicast the trace query to
279 all-routers.mcast.net (224.0.0.2) with a ttl of 1.
281 trace query is multicast to the
283 address since the last hop router will be a member of that group if
285 Therefore it is necessary to specify a group that
286 the intended receiver has joined.
287 This multicast is sent with a
288 default ttl of 127, which may not be sufficient for all cases (changed
292 If the last hop router is known, it may also be addressed directly
296 Alternatively, if it is desired to trace a group that the
297 receiver has not joined, but it is known that the last-hop router is a
298 member of another group, the
300 option may also be used to specify a different multicast address for the
303 When tracing from a multihomed host or router, the default receiver
304 address may not be the desired interface for the path from the source.
305 In that case, the desired interface should be specified explicitly as
308 .Ss Directing the Response
311 first attempts to trace the full reverse path, unless the number of
312 hops to trace is explicitly set with the
315 If there is no response within a 3 second timeout interval
318 option), a "*" is printed and the probing switches to hop-by-hop mode.
319 Trace queries are issued starting with a maximum hop count of one and
320 increasing by one until the full path is traced or no response is
322 At each hop, multiple probes are sent (default is three,
326 The first half of the attempts (default is two) are made with
327 the reply address set to standard multicast address, mtrace.mcast.net
328 (224.0.1.32) with the ttl set to 32 more than what is needed to pass the
329 thresholds seen so far along the path to the receiver.
331 additional attempt, the ttl is increased by another 32 each time up to
333 Since the desired router may not be able to send a
334 multicast reply, the remainder of the attempts request that the
335 response be sent via unicast to the host running
337 Alternatively, the multicast ttl may be set explicitly with the
339 option, the initial multicast attempts can be forced to use unicast
342 option, the final unicast attempts can be forced to use multicast
345 option, or if you specify
348 will first attempt using unicast and then multicast.
350 if no response is received within the timeout, a "*" is printed.
352 the specified number of attempts have failed,
354 will try to query the next hop router with a DVMRP_ASK_NEIGHBORS2
355 request (as used by the
357 program) to see what kind of router it is.
360 utility will try to query three (changed with the
362 option) hops past a non-responding router, in the hopes that even
363 though it is not capable of sending a response, it might be capable of
364 forwarding the request on.
369 The first section is a short listing of the hops
370 in the order they are queried, that is, in the reverse of the order
375 For each hop, a line is printed showing the hop number (counted
376 negatively to indicate that this is the reverse path); the multicast
377 routing protocol (DVMRP, MOSPF, PIM, etc.); the threshold required to
378 forward data (to the previous hop in the listing as indicated by the
379 up-arrow character); and the cumulative delay for the query to reach
380 that hop (valid only if the clocks are synchronized).
382 section ends with a line showing the round-trip time which measures
383 the interval from when the query is issued until the response is
384 received, both derived from the local system clock, and the total
385 ttl required for a packet to travel along this path.
390 oak.isi.edu 80# mtrace -l caraway.lcs.mit.edu 224.2.0.3
391 Mtrace from 18.26.0.170 to 128.9.160.100 via group 224.2.0.3
392 Querying full reverse path...
393 0 oak.isi.edu (128.9.160.100)
394 -1 cub.isi.edu (128.9.160.153) DVMRP thresh^ 1 3 ms
395 -2 la.dart.net (140.173.128.1) DVMRP thresh^ 1 14 ms
396 -3 dc.dart.net (140.173.64.1) DVMRP thresh^ 1 50 ms
397 -4 bbn.dart.net (140.173.32.1) DVMRP thresh^ 1 63 ms
398 -5 mit.dart.net (140.173.48.2) DVMRP thresh^ 1 71 ms
399 -6 caraway.lcs.mit.edu (18.26.0.170)
400 Round trip time 124 ms; total ttl of 6 required.
403 If a hop reports that it is using the default route to forward packets,
406 is printed after that hop.
409 flag is supplied, the route being used to forward packets is printed
413 The second section provides a pictorial view of the path in the
414 forward direction with data flow indicated by arrows pointing downward
415 and the query path indicated by arrows pointing upward.
417 both the entry and exit addresses of the router are shown if
418 different, along with the initial ttl required on the packet in order
419 to be forwarded at this hop and the propagation delay across the hop
420 assuming that the routers at both ends have synchronized clocks.
421 The right half of this section is composed of two sets of statistics.
422 The first column contains the average packet rate for all traffic at
424 The remaining columns are the
425 number of packets lost, the number of packets sent, the percentage
426 lost, and the average packet rate at each hop.
428 calculated from differences between traces and from hop to hop as
430 The first group shows the statistics for all traffic
431 flowing out the interface at one hop and in the interface at the next
433 The second group shows the statistics only for traffic forwarded
438 The first group of statistics may be expanded to include loss rates
442 However, these numbers can be extremely misleading and require
443 detailed knowledge of the routers involved to be interpreted properly.
445 These statistics are shown on one or two lines for each hop.
447 any options, this second section of the output is printed only once,
448 approximately 10 seconds after the initial trace.
450 for each hop showing the statistics over that 10-second period.
454 option is given, the second section is repeated every 10 seconds and
455 two lines are shown for each hop.
456 The first line shows the statistics
457 for the last 10 seconds, and the second line shows the cumulative
458 statistics over the period since the initial trace, which is 101
459 seconds in the example below.
460 The second section of the output is
463 option is set or if no multicast group is specified.
466 Waiting to accumulate statistics... Results after 101 seconds:
468 Source Response Dest Overall Packet Statistics For Traffic From
469 18.26.0.170 128.9.160.100 Packet 18.26.0.170 To 224.2.0.3
470 | __/ rtt 125 ms Rate Lost/Sent = Pct Rate
471 v / hop 65 ms ------- ---------------------
473 140.173.48.2 mit.dart.net
474 | ^ ttl 1 0 pps 0/2 = --% 0 pps
475 v | hop 8 ms 0 pps 0/18 = 0% 0 pps
477 140.173.32.1 bbn.dart.net
478 | ^ ttl 2 0 pps 0/2 = --% 0 pps
479 v | hop 12 ms 0 pps 0/18 = 0% 0 pps
481 140.173.64.1 dc.dart.net
482 | ^ ttl 3 27 pps 0/2 = --% 0 pps
483 v | hop 34 ms 26 pps 0/18 = 0% 0 pps
485 140.173.128.1 la.dart.net
486 | ^ ttl 4 83 pps 0/2 = --% 0 pps
487 v | hop 11 ms 79 pps 0/18 = 0% 0 pps
489 128.9.160.153 cub.isi.edu
490 | \\__ ttl 5 83 pps ?/2 0 pps
491 v \\ hop -8 ms 79 pps ?/18 0 pps
492 128.9.160.100 128.9.160.100
493 Receiver Query Source
496 Because the packet counts may be changing as the trace query is
497 propagating, there may be small errors (off by 1 or 2) in these
499 However, those errors should not accumulate, so the
500 cumulative statistics line should increase in accuracy as a new trace
501 is run every 10 seconds.
502 There are two sources of larger errors, both
503 of which show up as negative losses:
505 If the input to a node is from a multi-access network with more than
506 one other node attached, then the input count will be (close to) the
507 sum of the output counts from all the attached nodes, but the output
508 count from the previous hop on the traced path will be only part of
510 Hence the output count minus the input count will be negative.
512 In release 3.3 of the DVMRP multicast forwarding software for SunOS
513 and other systems, a multicast packet generated on a router will be
514 counted as having come in an interface even though it did not.
516 creates the negative loss that can be seen in the example above.
518 Note that these negative losses may mask positive losses.
520 In the example, there is also one negative hop time.
522 indicates a lack of synchronization between the system clocks across
524 This example also illustrates how the percentage loss is
525 shown as two dashes when the number of packets sent is less than 10
526 because the percentage would not be statistically valid.
528 A second example shows a trace to a receiver that is not local; the
529 query is sent to the last-hop router with the
532 In this example, the trace of the full reverse path resulted
533 in no response because there was a node running an old version of
535 that did not implement the multicast traceroute function, so
537 switched to hop-by-hop mode.
541 indicates that traffic for group 224.2.143.24 would not be forwarded.
544 oak.isi.edu 108# mtrace -g 140.173.48.2 204.62.246.73 \\
545 butter.lcs.mit.edu 224.2.143.24
546 Mtrace from 204.62.246.73 to 18.26.0.151 via group 224.2.143.24
547 Querying full reverse path... * switching to hop-by-hop:
548 0 butter.lcs.mit.edu (18.26.0.151)
549 -1 jam.lcs.mit.edu (18.26.0.144) DVMRP thresh^ 1 33 ms Output pruned
550 -2 bbn.dart.net (140.173.48.1) DVMRP thresh^ 1 36 ms
551 -3 dc.dart.net (140.173.32.2) DVMRP thresh^ 1 44 ms
552 -4 darpa.dart.net (140.173.240.2) DVMRP thresh^ 16 47 ms
553 -5 * * * noc.hpc.org (192.187.8.2) [mrouted 2.2] didn't respond
554 Round trip time 95 ms
565 based on an initial prototype written by
566 .An Ajit Thyagarajan .
567 The multicast traceroute mechanism was designed by
575 it was implemented in
581 The option syntax and the output format of
583 are modeled after the unicast
588 Statistics collection in passive mode does not always produce the same output
589 as when actively collecting data.