mtrace - Print multicast path from a source to a receiver
/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]
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.
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 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 [Toc] [Back]
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 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 lasthop
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 firsthop
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 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 [Toc] [Back]
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 [Toc] [Back]
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.
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 indicate
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 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. 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 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, 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 propagates, there may be small errors (off by
1 or 2) in these statistics. 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 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. 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
Commands: map-mbone(8), mrinfo(8), mrouted(8), traceroute(8)
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 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.
mtrace(8)
[ Back ] |
