mtrace(8)mtrace(8)NAMEmtrace - 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)