doc/ja/man/man8/mtrace.8

.\" Copyright (c) 1995 by the University of Southern California
.\" All rights reserved.
.\"
.\" Permission to use, copy, modify, and distribute this software and its
.\" documentation in source and binary forms for non-commercial purposes
.\" and without fee is hereby granted, provided that the above copyright
.\" notice appear in all copies and that both the copyright notice and
.\" this permission notice appear in supporting documentation, and that
.\" any documentation, advertising materials, and other materials related
.\" to such distribution and use acknowledge that the software was
.\" developed by the University of Southern California, Information
.\" Sciences Institute.  The name of the University may not be used to
.\" endorse or promote products derived from this software without
.\" specific prior written permission.
.\"
.\" THE UNIVERSITY OF SOUTHERN CALIFORNIA makes no representations about
.\" the suitability of this software for any purpose.  THIS SOFTWARE IS
.\" PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES,
.\" INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
.\"
.\" Other copyrights might apply to parts of this software and are so
.\" noted when applicable.
.\"
.\" This manual page (but not the software) was derived from the
.\" manual page for the traceroute program which bears the following
.\" copyright notice:
.\"
.\" Copyright (c) 1988 The Regents of the University of California.
.\" All rights reserved.
.\"
.\"	mtrace.8,v 5.1 1996/12/19 21:31:26 fenner Exp
.\"
.\" jpman %Id: mtrace.8,v 1.3 1997/08/20 12:03:14 horikawa Stab %
.TH MTRACE 8 "May 8, 1995"
.UC 6
.SH 名称
mtrace \- 発信元から受信側へのマルチキャストのパスを表示する
.SH 形式
.B mtrace
[
.B \-e
.I extrahops
] [
.B \-g
.I gateway
] [
.B \-i
.I if_addr
] [
.B \-l
] [
.B \-M
] [
.B \-m
.I max_hops
] [
.B \-n
] [
.B \-O
] [
.B \-p
] [
.B \-P
] [
.B \-q
.I nqueries
] [
.B \-r
.I resp_dest
] [
.B \-s
] [
.B \-S
.I stat_int
] [
.B \-t
.I ttl
] [
.B \-T
] [
.B \-U
] [
.B \-v
] [
.B \-w
.I waittime
]
.I source
[
.I receiver
] [
.I group
]
.SH 解説
IP マルチキャストのトラフィックの配送における問題点を突き止めるのは困
難な作業です。
.B mtrace
は IGMP プロトコルの拡張機能によってアクセスされる、マルチキャストルー
タに実装されたトレース機能を利用します。
.I receiver
から
.I source
への逆のパスに沿ったホップごとにトレースの問い合わせを行ない、パス上の
ホップのアドレス、パケット数、ルーティングのエラー状況の情報を収集し、
要求者へ応答を返します。
.PP
唯一必須であるパラメータは
.I source
のホスト名もしくはアドレスです。デフォルトの
.I receiver
は mtrace を実行しているホストとなり、デフォルトの
.I group
は "MBone Audio" (224.2.0.1) となります。特定のマルチキャストグループ
でのパケット消失の統計が必要でなければ、これで十分です。以下に解説され
ているいくつかの制約を条件として、特定の group でのいくつかの他の 
receiver をテストするために、これらの 2 つのオプションのパラメータを指
定することができます。
.I receiver
はユニキャストアドレスであり、
.I group
はマルチキャストアドレスであることより、これらの 2 つのパラメータは区
別することができます。
.B \-g
フラグが指定されると、source アドレスには mtrace が実行されているホス
トがデフォルトとして使われ、 receiver には
.B \-g
フラグで指定されるルータがデフォルトとして使われます。この場合、必須の
パラメータはありません。
.PP
注釈: Solaris 2.4/2.5 ではマルチキャストインタフェースがデフォルトの
インタフェースでなければ、 -i オプションによってローカルアドレスをセット
しなければなりません。
.SH オプション
.TP 8 8
.BI \-e\  extrahops
応答がないルータを越えて、
.I extrahops
だけのホップ数のトレースを試みます。
.TP 8 8
.BI \-g\  gwy
トレースの問い合わせを、マルチキャストではなく、ユニキャストによって直
接マルチキャストルータ
.I gwy
へ送ります。
このマルチキャストルータは意図する
.I source
から
.I receiver
へのパス上の最後のホップのルータでなければなりません。
.RS 8
.TP 12 12
.I 注意!!
バージョン 3.3 と 3.5 の
.B mrouted
は、トレースの問い合わせがユニキャストパケットによって受信されかつ、
.B mrouted
に
.I source
への経路がないと、クラッシュします。そのためターゲットの
.B mrouted
が 3.4 であるか、3.5 より新しいことが分かっていなければ、
.B \-g
オプションを使わないでください。
.RE
.TP 8 8
.BI \-i\  addr
.I addr
をトレースの問い合わせを送る (マルチホームホスト上の) ローカルインタ
フェイスアドレス、および
.I receiver
と応答先のデフォルトアドレスとして使用します。
.TP 8 8
.B \-l
10 秒ごとにマルチキャストパスのパケットレートと消失の統計を表示して、
無限ループします。
(
.B \-S
.I stat_int
参照)
.TP 8 8
.B \-M
試みの後半は、ユニキャストではなく、常にマルチキャストを使って応答を要
求します。
.TP 8 8
.BI \-m\  n
.I receiver
から
.I source
へ遡ってトレースされる最大ホップ数を
.I n
にセットします。
デフォルトは 32 ホップ (DVMRP ルーティングプロトコルについては無限) で
す。
.TP 8 8
.B \-n
ホップアドレスをシンボル名および数字ではなく数字で表示します。(パス上に発見された
各ルータに対するネームサーバでのアドレス-名前検索を省くことができます。)
.TP 8 8
.BI \-q\  n
すべてのホップに対して試みる問い合わせの最大の回数を
.I n
にセットします。デフォルトは 3 です。
.TP 8 8
.B \-O
router-alert IP オプションを、これが必要な要求においても使用しません。
Cisco の IOSのいくつかのバージョンでは IP オプションつきのマルチキャス
トトレースルートが扱えないため、最後のホップのルータが Cisco のもので
ある時は、-O フラグが必要となることがあります。
.TP 8 8
.B \-p
他から起動されたトレースによるマルチキャストの応答を受動的に聴取します。
これはマルチキャストルータ上で動作している場合に最も良く動作します。
.TP 8 8
.B \-P
10 秒おきにパス情報を収集しながら無限ループし
(
.B \-S
.I stat_int
参照)、
パス情報が変化するとそれを表示します。統計情報は表示しません。
.TP 8 8
.BI \-r\  host
トレースの応答を、
.B mtrace
が実行されているホストや
この目的で登録されている他のマルチキャストアドレス (224.0.1.32) ではなく、
.I host
へ送ります。
.TP 8 8
.B \-s
マルチキャストパスのみを含む短い形式の表示を行ない、パケットレートと
消失統計は表示しません。
.TP 8 8
.BI \-S\  n
統計情報を収集する間隔を
.I n
秒 (デフォルトは 10 秒) に変更します。
.TP 8 8
.BI \-t\  ttl
マルチキャストトレースの問い合わせと応答の
.I ttl
(time-to-live もしくはホップ数) をセットします。ttl に 1 を使用する "全
てのルータ" へのローカルな問い合わせの場合を除き、デフォルトは 127 で
す。
.TP 8 8
.B \-T
"トンネル統計" モードです。全てのトラフィックでのロスレートを表示しま
す。これらの統計は非常に誤解を招くおそれのあるものです。
.TP 8 8
.B \-U
マルチキャストから試みるのではなく、常にユニキャストによる応答を要求し
ます。
.TP 8 8
.B \-v
冗長モードです。最初のトレースのホップ時間と統計情報を表示します。最初
のトレースを転送するのに使用した経路も表示します。
.TP 8 8
.BI \-w\  n
トレースの応答の待ち時間を
.I n
秒 (デフォルトは 3 秒) にセットします。
.SH 使用方法
.SS どのように動作するか ?
.B traceroute
ツールでユニキャストのネットワーク経路をトレースするために使用している
技法は IP マルチキャストでは動作しません。それは、ICMP 応答が
マルチキャストトラフィックでは禁止されているためです。そのかわりに、
トレースの機能はマルチキャストルータにおいて実装されています。
この技法は送出するパケット数を最小にしながら、
パケットレートやロスを計測できる点で優れています。
.PP
マルチキャストでは逆経路転送が使われているため、トレースは
.I receiver
から
.I source
へ逆方向に実行されます。
トレースの問い合わせパケットは最終ホップのマルチキャストルータ (
.I receiver
アドレスでの末端ルータ) へ送られます。最終ホップのルータではトレースの
応答パケットを生成し、それにそのホップでのレポートを詰め込み、
ユニキャストを使って、指定された
.I source
から送られてくるパケットにおける、そのルータの前段のホップであると思わ
れるルータへ、生成したパケットを転送します。
経路上の各ルータはそのパケットにレポートを追加して転送します。
トレースの応答パケットが最初のホップのルータ ( source のネットワークに
直結されているルータ) に到達すると、そのルータはトレースの問い合わせに
指定されている応答の送り先アドレスへ最終的な形の応答を送ります。
.PP
経路上のいくつかのマルチキャストルータにマルチキャストのトレースルート
機能が実装されていなかったり、停止しているものがあると、応答は返されま
せん。この問題を解決するには、応答が返されるまでにトレースされるホップ
数を制限するための最大ホップ数フィールドを、トレースの問い合わせに
含ませます。これによって、部分的な経路のトレースが可能となります。
.PP
各ルータによって挿入されるレポートには、ホップのアドレスだけでなく、転
送のために必要な ttl とルーティングのエラーを示すいくつかのフラグ、そ
れに受信と送信インタフェース上および指定された
.I group
へ転送されたパケット数の合計が含まれます。時間をあけて 2 回トレースを
行なってこれらのパケット数の差分をとり、あるホップからの送信パケット
数とその次のホップでの受信パケット数を比較することにより、パケットレートと
パケット消失の統計が計算でき、ネットワークへの過負荷による問題を切
り離すことができます。
.SS 最終ホップルータを見つける
トレースの問い合わせは
.I source
から
.I receiver
へ到る経路上の最後のホップであるマルチキャストルータへ送られなければな
りません。もし、receiver がローカルサブネット上にあれば (これはサブネットマスク
によって決定されます)、デフォルトの方法ではトレースの問い合わせ
を ttl を 1 にして all-routers.mcast.net (224.0.0.2) へマルチキャスト
します。receiver がサブネット上になければ、
.I group
へトレースの問い合わせをマルチキャストします。それは receiver がその
グループのメンバであれば、最後のホップルータもグループのメンバであるため
です。そのため、意図している receiver が属しているグループを指定する必
要があります。このマルチキャストは ttl をデフォルトの 127 にして送られ
ます。この ttl は全ての場合では十分でないかもしれません。(
.B \-t
オプションで変更可能です。) もし最後のホップルータが分かっていれば、
.B \-g
オプションを使用して直接指定することもできます。また、最後のホップのルータが
別のグループのメンバであるということが分かっており、receiver が属
していないグループのトレースを行ないたい場合、
.B \-g
オプションを使用してトレースの問い合わせに別のマルチキャストアドレスを
指定することもできます。
.PP
マルチホームであるホストやルータからのトレースを行なう場合は、デフォルトの
receiver のアドレスは source からの経路での意図したインタフェース
でないかも知れません。インタフェースを指定したい場合は、
.I receiver
によって明示的に指定しなければなりません。
.SS 応答の誘導
.B \-m
オプションによってトレースするホップ数が明示的に指定されている場合を除
き、
.B mtrace
はデフォルトではまず逆経路全てに渡ったトレースを試みます。もしタイムアウト
時間である 3 秒 (これは
.B \-w
オプションで変更できます) 以内に応答がなければ、"*" が表示され、プローブ方式を
hop-by-hop モードに切り替えます。
トレースの問い合わせは最大ホップ数を 1 から開始し、応答を受信しなくなる
か全ての経路を網羅するまでホップ数を 1 づつ増やして行きます。
各ホップでは、複数のプローブ (デフォルトでは 3、
.B \-q
オプションで変更可)
が送られます。トレースの試みの前半 (デフォルトでは 2 回) では、応答
アドレスを標準のマルチキャストアドレス mtrace.mcast.net (224.0.1.32) に
セットし、ttl を receiver までの経路上で今までにあった最大のスレッショルド
である 32 にセットして行なわれます。引き続く各々の試みについては 
ttl は最大 192 まで 32 づつ増やされます。
目的のルータはマルチキャスト応答を送ることができないかもしれないので、
残りの試みでは
.B mtrace
が動作しているホストへユニキャストを使って応答することを要求します。
また、マルチキャストの ttl は
.B \-t
オプションを使って明示的に指定することができ、最初のマルチキャストの試
みは
.B \-U
オプションを使ってユニキャストに強制的に変更することができ、最後の
マルチキャストの試みは
.B \-M
オプションを使って強制的にマルチキャストにすることができ、また
.B \-UM
を指定することにより、
.B mtrace
は最初はユニキャストで試み、次にマルチキャストを試みます。各々の試みで
はタイムアウトとなるまで応答が受信できなければ "*" が表示されます。指
定された回数の試みが失敗すると、
.B mtrace
は次のホップのルータへ (
.B mrinfo
プログラムで使われているように) DVMRP_ASK_NEIGHBORS2 要求で問い合わせ
を試み、そのルータの種類を調べます。
.B mtrace
は応答がないルータを越えて 3 ホップ (これは
.B \-e
オプションで変更可能) へ、応答を返す能力がないとしてもその要求の転送は
できるであろうと想定して、問い合わせを試みます。
.SH 使用例
.B mtrace
の出力は 2つのセクションからなります。最初のセクションではホップが問い
合わされた順、すなわち
.I source
から
.I receiver
への逆順で簡潔にリストされます。各々のホップについて、ホップ番号 (逆パス
であることを示すように負の数でカウントされる)、マルチキャスト
ルーティングプロトコル (DVMRP、MOSPF、PIM など)、データの転送 (上向きの矢印で
示されたリストでの前のホップへの転送) 要求のスレッショルド、問い合わせ
がそのホップへ届くまでの遅れの累積 (クロックが同期している時のみ有効)
が 1 行で表示されます。最初のセクションの最後には、問い合わせが発行さ
れてから応答を受信するまでの間隔をローカルのシステムクロックで計測した
ラウンドトリップ時間と、パケットがこの経路を通って行き来するのに必要な 
ttl の合計が表示されます。以下に使い方とその出力の例を示します。
.PP
.nf
.ft C
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; total ttl of 6 required.
.fi
.PP
あるホップがパケットを転送するのにデフォルトの経路を使っていることを報
告すれば、
.B [default]
がそのホップの後に表示されます。
.B \-v
フラグが指定されていれば、そのパケットを転送するのに使われた経路が
.B [18.26.0/24]
の形式で表示されます。
.PP
2 番目のセクションでは転送のパスが図によって表示されます。データの流れ
は下向きの矢印で表され、問い合わせのパスは上向きの矢印で表されます。各
ホップでは、ルータの入力アドレスと出力アドレスが違っていれば、それらの
アドレスが、そのホップパケットを転送するのに必要な ttl の初期値と、両
端のルータのクロックが同期していると想定した場合のホップにまたがった伝
搬遅れとともに表示されます。このセクションの右半分は 2 組の統計情報か
ら構成されます。最初のカラムには各ホップでの全てのトラフィックについて
の平均のパケットレートが表示されます。残りのカラムでは消失したパケット
の数、送信したパケットの数、消失したパーセンテージ、それに平均パケット
レートが各ホップについて表示されます。これらの統計情報は上で解説したよ
うにトレース間の差とホップ間の差から計算されます。最初のグループでは、
あるホップでのインタフェースにおける全流出トラフィックと次のホップでの全流入
トラフィックの統計情報が表示されます。2 番目のグループでは、指定された
.I source
から指定された
.I group
への転送トラフィックのみについての統計情報が表示されます。統計の最初の
グループは
.B \-T
オプションを使って消失レートを含ませることもできます。しかし、これらの
数字は大幅な誤差を含む可能性があり、これらを適切に解釈するためには
ルータについての詳細な知識が要求されるでしょう。
.PP
これらの統計情報は各々のホップにつき 1 行か 2　行で表示されます。
オプションが何も指定されていないと、この出力中の 2 番目のセクションは最初
のトレースからおよそ 10 秒後に 1 度のみ表示されます。各ホップにつき 1 
行にその 10 秒間での統計情報を表示します。もし
.B \-l
オプションが指定されていると、2 番目のセクションは 10 秒ごとに繰り返さ
れ、各ホップにつき 2 行が表示されます。最初の行ではそれまでの 10 秒間
における統計が表示され、2 番目の行で最初のトレースからの累積の統計情報
が表示されます。下の例ではこれは 101 秒間での統計となっています。
.B \-s
オプションが指定されるか、マルチキャストグループが指定されていると、こ
の出力での 2 番目のセクションは省略されます。
.ie t \{\
.ft C
.  ie \w'i'<>\w'm' \{\" looks like this is not proper Courier font
(If this example is not properly columned with a fixed-width font, get
.B groff
and try again.)
.  \}
.\}
.PP
.ft C
.nf
Waiting to accumulate statistics... Results after 101 seconds:

  Source       Response Dest    Overall   Packet Statistics For Traffic From
18.26.0.170    128.9.160.100    Packet    18.26.0.170 To 224.2.0.3
     |       __/ rtt  125 ms     Rate     Lost/Sent = Pct  Rate
     v      /    hop   65 ms    -------   ---------------------
18.26.0.144    
140.173.48.2   mit.dart.net          
     |     ^     ttl    1         0 pps      0/2  = --%  0 pps
     v     |     hop    8 ms      0 pps      0/18 =  0%  0 pps
140.173.48.1   
140.173.32.1   bbn.dart.net
     |     ^     ttl    2         0 pps      0/2  = --%  0 pps
     v     |     hop   12 ms      0 pps      0/18 =  0%  0 pps
140.173.32.2   
140.173.64.1   dc.dart.net 
     |     ^     ttl    3        27 pps      0/2  = --%  0 pps
     v     |     hop   34 ms     26 pps      0/18 =  0%  0 pps
140.173.64.2   
140.173.128.1  la.dart.net
     |     ^     ttl    4        83 pps      0/2  = --%  0 pps
     v     |     hop   11 ms     79 pps      0/18 =  0%  0 pps
140.173.128.2  
128.9.160.153  cub.isi.edu
     |      \\__  ttl    5        83 pps      ?/2         0 pps
     v         \\ hop   -8 ms     79 pps      ?/18        0 pps
128.9.160.100  128.9.160.100
  Receiver     Query Source
.fi
.PP
パケットのカウント数はトレースの問い合わせが伝搬するとともに変化するた
め、統計情報中には小さな誤差 (1 か 2 のずれ) が含まれることがあります。
しかし、これらの誤差は累積されるべきではないため、累積統計行ではあらた
なトレースが 10 秒ごとに実行されるたびに精度が増さなければなりません。
大きな誤差の要因としては 2 つあり、このいずれもマイナスのロスとして現
われます。
.LP
.RS
.PD 0
.TP 3
\(bu
あるノードへの入力カウントが他のノードがアタッチされているマルチアクセス
ネットワークからのものであれば、入力カウントはアタッチされている全てのノード
からの出力カウントの総和となります (もしくは近くなります) が、トレースし
ているパス上のその前のホップからの出力カウントはその単なる一部分となり
ます。そのため、出力カウントから入力カウントを引いたものはマイナスの値
になります。
.TP 3
\(bu
SunOS およびその他のシステムにおける DVMRP マルチキャスト転送ソフトウェアの
リリース 3.3 では、ルータにおいて生成されたマルチキャストパケット
はインタフェースに入力されていない場合においても、入力されたものとし
てカウントされます。これは上の例において見ることのできるマイナスのロス
となります。
.PD
.RE
.LP
これらのマイナスのロスはプラスのロスを隠してしまうことが
あることに注意してください。
.PP
この例ではまた、1 つマイナスのホップの時間が表示されています。これは
単にそのホップ間でのシステムクロックが同期していないことを示しています。
この例ではまた、送られたパケットの数が 10 より少ない時には、パーセンテー
ジの値は統計的に有効ではないため、ロスのパーセンテージが 2 つのダッシュ
として表示されることも示しています。
.PP
2 番目の例では ローカルでない receiver へのトレースを示します。問い合
わせは
.B \-g
オプションによって最終ホップのルータに送られます。この例では、全逆パス
のトレースが、マルチキャストトレースルート機能が実装されていない古いバー
ジョンの
.B mrouted
が動作しているノードがあるために応答なしの結果となっており、そのため
.B mtrace
は hop-by-hop モードに切り替わっています。\*(lqOutput pruned\*(rq の
エラーコードはグループ 224.2.143.24 へのトラフィックが転送されていないこ
とを示しています。
.PP
.nf
.ft C
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  Output 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
.fi
.SH 作者
Ajit Thyagarajan によって書かれた最初のプロトタイプをベースにして、
Steve Casner によって実装されました。マルチキャストトレースルートの
メカニズムは Steve Casner、Steve Deering、Dino Farinacci、Deb Agrawal の
助けを得て、Van Jacobson によって設計され、Ajit Thyagarajan と Bill
Fennerによって
.B mrouted
に実装されました。オプションのシンタックスと
.B mtrace
の出力フォーマットは、Van Jacobson によって書かれたユニキャストの
.B traceroute
をモデルにしています。
.SH 関連項目
.BR mrouted (8) ,
.BR mrinfo (8) ,
.BR map-mbone (8) ,
.BR traceroute (8)
.SH バグ
.PP
パッシブモードでの統計収集は、活発にデータを収集しているときと常に同じ
出力とはなりません。