NAME
mtrace - print multicast path from a source to a receiver
SYNOPSIS
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 ]
DESCRIPTION
Assessing problems in the distribution of IP multicast traffic can be difficult.
mtrace uses a tracing feature implemented in multicast routers
(
mrouted version 3.3 and later) that is accessed via 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, and then the
response is returned to the requestor.
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.
NOTE: For Solaris 2.4/2.5, if the multicast interface is not the default
interface, the -i option must be used to set the local address.
OPTIONS
- -g gwy
- Send the trace query via unicast directly to the multicast
router gwy 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 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.
- -i addr
- Use 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.
- -l
- Loop indefinitely printing packet rate and loss statistics
for the multicast path every 10 seconds (see -S
stat_int).
- -M
- Always send the response using multicast rather than
attempting unicast first.
- -m n
- Set to n the maximum number of hops that will be
traced from the receiver back toward the source. The default
is 32 hops (infinity for the DVMRP routing protocol).
- -n
- Print hop addresses numerically rather than symbolically
and numerically (saves a nameserver address-to-name lookup for each router
found on the path).
- -q n
- Set the maximum number of query attempts for any hop to
n. The default is 3.
- -p
- Listen passively for multicast responses from traces
initiated by others. This works best when run on a multicast router.
- -r host
- Send 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).
- -s
- Print a short form output including only the multicast path
and not the packet rate and loss statistics.
- -S n
- Change the interval between statistics gathering traces to
n seconds (default 10 seconds).
- -t ttl
- Set 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.
- -v
- Verbose mode; show hop times on the initial trace and
statistics display.
- -w n
- Set the time to wait for a trace response to n
seconds (default 3 seconds).
USAGE
How It Works
The technique used by the
traceroute tool to trace unicast network paths
will not work for IP multicast because 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 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 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.
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), then 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 that group if the
receiver is. Therefore it is necessary to 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 it is desired to trace a group that the
receiver has not joined, but it is known that the last-hop router is a member
of another group, the
-g option may also be used 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, the
desired interface should be specified explicitly 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), a "*" is printed and the probing switches to
hop-by-hop mode. Trace queries are issued starting with a maximum hop count of
one and increasing by one until the full path is traced or no response is
received. At each hop, multiple probes are sent (default is three, changed
with
-q option). The first half of the attempts (default is one) 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 what's needed
to pass the thresholds seen so far along the path to the receiver. For the
last quarter of the attempts (default is one), the ttl is increased by another
32 each time up to a maximum of 192. Alternatively, the ttl may be set
explicitly with the
-t option and/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, a "*" is
printed. After the specified number of attempts have failed,
mtrace
will try 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 showing the hop number (counted negatively to indicate that this is
the reverse path); the multicast routing protocol (DVMRP, MOSPF, PIM, etc.);
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 showing 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:
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:
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 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:
- •
- If the input to a node is from a multi-access 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 SunOS and other 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 example above.
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
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 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.
SEE ALSO
mrouted(8)
, mrinfo(8)
, map-mbone(8)
,
traceroute(8)