 |
Index for
Section 8 |
|
 |
Alphabetical
listing for M |
|
 |
Bottom of
page |
|
mtrace(8)
NAME
mtrace - 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
-g gateway
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.
-i if_addr
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.
-l 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.
-M Sends the response using a multicast path rather than attempting a
unicast first.
-m max_hops
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).
-n Prints hop addresses numerically rather than symbolically and
numerically (saves a nameserver address-to-name lookup for each router
found on the path).
-q nqueries
Sets the maximum number of query attempts for any hop to nqueries. The
default is 3.
-p Listens passively for multicast responses from traces initiated by
others. This works best when run on a multicast router.
-r resp_dest
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).
-s Prints a short form output including only the multicast path and not
the packet rate and loss statistics.
-S stat_int
Sets the interval between statistics gathering traces to stat_int
seconds. The default is 10 seconds.
-t ttl
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.
-v Prints a verbose form output, displaying hop times on initial trace and
statistics.
-w waittime
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 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
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 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 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), 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 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.
EXAMPLES
1. 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.
2. 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
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 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.
|
Index for
Section 8 |
|
|
Alphabetical
listing for M |
|
 |
Top of
page |
|