|
|
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. 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.
CAUTION: 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 address. Therefore, do not use the -g option unless the target mrouted has been verified to be 3.4 or newer than 3.5.
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 local network), 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 indicate 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.
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 receiver.
oak.isi.edu 80# 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 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 set.
Waiting to accumulate statistics... Results after 101 seconds: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 statistics 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 losses: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 5833 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
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 224.2.143.24 would not be forwarded.
oak.isi.edu 108# 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