manページ  — MTRACE

mtrace – 発信元から受信側へのマルチキャストの経路を表示する

書式 解説 使用法 どのように動作するか ? 最終ホップルータを見つける 応答の誘導 使用例 作者 関連項目 バグ

mtrace [-e extrahops] [-g gateway] [-i if_addr] [-l] [-M] [-m max_hops] [-n] [-O] [-p] [-P] [-q nqueries] [-r resp_dest] [-s] [-S stat_int] [-t ttl] [-T] [-U] [-v] [-w waittime] source [receiver] [group]

IP マルチキャストのトラフィックの配送における問題点を突き止めるのは困難な 作業です。 mtrace ユーティリティは IGMP プロトコルの拡張機能によってアクセスされる、 マルチキャストルータに実装されたトレース機能を利用します。 receiver から source への逆経路に沿ったホップごとにトレースの問い合わせを行い、経路上の ホップのアドレス、パケット数、ルーティングのエラー状況の情報を収集し、 要求者へ応答を返します。

唯一必須である引数は source のホスト名もしくはアドレスです。 デフォルトの receiver は mtrace を実行しているホストとなり、デフォルトの group は 0.0.0.0 となります。特定のマルチキャストグループ でのパケット消失の統計が必要でなければ、これで十分です。 以下に解説されているいくつかの制約を条件として、 特定の group でのいくつかの他の receiver をテストするために、これらの 2 つのオプションの引数を 指定することができます。 receiver はユニキャストアドレスであり、 group はマルチキャストアドレスであることより、これらの 2 つの引数を 区別することができます。 -g フラグが指定されると、source アドレスには mtrace が実行されているホストがデフォルトとして使われ、 receiver には -g フラグで指定されるルータがデフォルトとして使われます。この場合、必須の 引数はありません。

注: Solaris 2.4/2.5 ではマルチキャストインタフェースがデフォルトの インタフェースでなければ、 -i オプションによってローカルアドレスをセットしなければなりません。

以下のオプションが使用できます:

-e extrahops
	応答がないルータを越えて、 extrahops だけのホップ数のトレースを試みます。
-g gwy
	トレースの問い合わせを、マルチキャストではなく、ユニキャストによって 直接マルチキャストルータ gwy へ送ります。 このマルチキャストルータは意図する source から receiver への経路上の最後のホップのルータでなければなりません。 注意 !! バージョン 3.3 と 3.5 の mrouted は、トレースの問い合わせがユニキャストパケットによって受信されかつ、 mrouted に source への経路がないと、クラッシュします。 そのためターゲットの mrouted が 3.4 であるか、3.5 より新しいことが分かっていなければ、 -g オプションを使わないでください。
-i addr
	addr をトレースの問い合わせを送る (マルチホームホスト上の) ローカルインタフェースアドレス、および receiver と応答先のデフォルトアドレスとして使用します。
-l
	10 秒ごとにマルチキャスト経路のパケットレートと消失の統計を表示して、 無限ループします。 ( -S stat_int 参照)
-M
	試みの後半は、ユニキャストではなく、常にマルチキャストを使って応答を 要求します。
-m n
	receiver から source へ遡ってトレースされる最大ホップ数を n にセットします。 デフォルトは 32 ホップ (DVMRP ルーティングプロトコルについては無限) です。
-n
	ホップアドレスをシンボル名および数字ではなく数字で表示します (経路上に発見された各ルータに対する ネームサーバでのアドレス-名前検索を省くことができます)。
-q n
	すべてのホップに対して試みる問い合わせの最大の回数を n にセットします。デフォルトは 3 です。
-O
	router-alert IP オプションを、これが必要な要求においても使用しません。 Cisco の IOS のいくつかのバージョンでは IP オプションつきのマルチキャスト トレースルートが扱えないため、最後のホップのルータが Cisco のものである時は、 -O フラグが必要となることがあります。
-p
	他から起動されたトレースによるマルチキャストの応答を受動的に聴取します。 これはマルチキャストルータ上で動作している場合に最も良く動作します。
-P
	10 秒おきに経路情報を収集しながら無限ループし ( -S stat_int 参照)、 経路情報が変化するとそれを表示します。 統計情報は表示しません。
-r host
	トレースの応答を、 mtrace が実行されているホストや この目的で登録されている他のマルチキャストアドレス (224.0.1.32) ではなく、 host へ送ります。
-s
	マルチキャスト経路のみを含む短い形式の表示を行い、パケットレートと 消失統計は表示しません。
-S n
	統計情報を収集する間隔を n 秒 (デフォルトは 10 秒) に変更します。
-t ttl
	マルチキャストトレースの問い合わせと応答の ttl (time-to-live もしくはホップ数) をセットします。 ttl に 1 を使用する "全てのルータ" へのローカルな問い合わせの場合を除き、 デフォルトは 127 です。
-T
	"トンネル統計" モードです。全てのトラフィックでのロスレートを表示します。 これらの統計は非常に誤解を招くおそれのあるものです。
-U
	マルチキャストから試みるのではなく、常にユニキャストによる応答を要求します。
-v
	冗長モードです。最初のトレースのホップ時間と統計情報を表示します。最初 のトレースを転送するのに使用した経路も表示します。
-w n
	トレースの応答の待ち時間を n 秒 (デフォルトは 3 秒) にセットします。

traceroute ユーティリティでユニキャストのネットワーク経路をトレースするために使用している 技法は IP マルチキャストでは動作しません。それは、ICMP 応答が マルチキャストトラフィックでは禁止されているためです。そのかわりに、 トレースの機能はマルチキャストルータにおいて実装されています。 この技法は送出するパケット数を最小にしながら、 パケットレートやロスを計測できる点で優れています。

マルチキャストでは逆経路転送が使われているため、トレースは receiver から source へ逆方向に実行されます。 トレースの問い合わせパケットは最終ホップのマルチキャストルータ ( receiver アドレスでの末端ルータ) へ送られます。最終ホップのルータではトレースの 応答パケットを生成し、それにそのホップでのレポートを詰め込み、 ユニキャストを使って、指定された source から送られてくるパケットにおける、そのルータの前段のホップであると 思われるルータへ、生成したパケットを転送します。 経路上の各ルータはそのパケットにレポートを追加して転送します。 トレースの応答パケットが最初のホップのルータ (source のネットワークに 直結されているルータ) に到達すると、そのルータはトレースの問い合わせに 指定されている応答の送り先アドレスへ最終的な形の応答を送ります。

経路上のいくつかのマルチキャストルータにマルチキャストの トレースルート機能が実装されていなかったり、停止しているものがあると、 応答は返されません。 この問題を解決するには、応答が返されるまでにトレースされる ホップ数を制限するための最大ホップ数フィールドを、 トレースの問い合わせに含ませます。 これによって、部分的な経路のトレースが可能となります。

各ルータによって挿入されるレポートには、ホップのアドレスだけでなく、 転送のために必要な ttl とルーティングのエラーを示すいくつかのフラグ、 それに受信と送信インタフェース上および指定された group へ転送されたパケット数の合計が含まれます。時間をあけて 2 回トレースを 行ってこれらのパケット数の差分をとり、あるホップからの送信パケット 数とその次のホップでの受信パケット数を比較することにより、パケットレートと パケット消失の統計が計算でき、ネットワークへの過負荷による問題を切 り離すことができます。

トレースの問い合わせは source から receiver へ到る経路上の最後のホップであるマルチキャストルータへ送られなければな りません。もし、receiver がローカルサブネット上にあれば (これはサブネットマスク によって決定されます)、デフォルトの方法ではトレースの問い合わせ を ttl を 1 にして all-routers.mcast.net (224.0.0.2) へ マルチキャストします。 receiver がサブネット上になければ、 group へトレースの問い合わせをマルチキャストします。 それは receiver がそのグループのメンバであれば、 最後のホップルータもグループのメンバであるためです。 そのため、意図している receiver が属しているグループを指定する 必要があります。 このマルチキャストは ttl をデフォルトの 127 にして送られます。 この ttl は全ての場合では十分でないかもしれません ( -t オプションで変更可能です)。 もし最後のホップルータが分かっていれば、 -g オプションを使用して直接指定することもできます。 また、最後のホップのルータが別のグループのメンバであるということが 分かっており、receiver が属していないグループのトレースを行いたい場合、 -g オプションを使用してトレースの問い合わせに別のマルチキャストアドレスを 指定することもできます。

マルチホームであるホストやルータからのトレースを行う場合は、デフォルトの receiver のアドレスは source からの経路での意図したインタフェース でないかも知れません。 インタフェースを指定したい場合は、 receiver によって明示的に指定しなければなりません。

-m オプションによってトレースするホップ数が明示的に指定されている場合を除き、 mtrace はデフォルトではまず逆経路全てに渡ったトレースを試みます。 もしタイムアウト時間である 3 秒 (これは -w オプションで変更できます) 以内に応答がなければ、"*" が表示され、プローブ方式を hop-by-hop モードに切り替えます。 トレースの問い合わせは最大ホップ数を 1 から開始し、応答を受信しなくなる か全ての経路を網羅するまでホップ数を 1 づつ増やして行きます。 各ホップでは、複数のプローブ (デフォルトでは 3、 -q オプションで変更可) が送られます。 トレースの試みの前半 (デフォルトでは 2 回) では、応答 アドレスを標準のマルチキャストアドレス mtrace.mcast.net (224.0.1.32) に セットし、ttl を receiver までの経路上で今までにあった最大のスレッショルド である 32 にセットして行われます。 引き続く各々の試みについては ttl は最大 192 まで 32 づつ増やされます。 目的のルータはマルチキャスト応答を送ることができないかもしれないので、 残りの試みでは mtrace が動作しているホストへユニキャストを使って応答することを要求します。 また、マルチキャストの ttl は -t オプションを使って明示的に指定することができ、最初のマルチキャストの試みは -U オプションを使ってユニキャストに強制的に変更することができ、最後の マルチキャストの試みは -M オプションを使って強制的にマルチキャストにすることができ、また -UM を指定することにより、 mtrace は最初はユニキャストで試み、次にマルチキャストを試みます。 各々の試みではタイムアウトとなるまで応答が受信できなければ "*" が表示されます。 指定された回数の試みが失敗すると、 mtrace は次のホップのルータへ ( mrinfo プログラムで使われているように) DVMRP_ASK_NEIGHBORS2 要求で問い合わせ を試み、そのルータの種類を調べます。 mtrace ユーティリティは応答がないルータを越えて 3 ホップ (これは -e オプションで変更可能) へ、応答を返す能力がないとしてもその要求の転送は できるであろうと想定して、問い合わせを試みます。

mtrace の出力は 2つのセクションからなります。 最初のセクションではホップが問い合わされた順、すなわち source から receiver への逆順で簡潔にリストされます。 各々のホップについて、ホップ番号 (逆経路 であることを示すように負の数でカウントされる)、マルチキャスト ルーティングプロトコル (DVMRP、MOSPF、PIM など)、データの転送 (上向きの矢印で 示されたリストでの前のホップへの転送) 要求のスレッショルド、問い合わせ がそのホップへ届くまでの遅れの累積 (クロックが同期している時のみ有効) が 1 行で表示されます。 最初のセクションの最後には、問い合わせが発行されてから 応答を受信するまでの間隔をローカルのシステムクロックで計測した ラウンドトリップ時間と、パケットがこの経路を通って行き来するのに必要な ttl の合計が表示されます。 以下に使い方とその出力の例を示します。

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.

あるホップがパケットを転送するのにデフォルトの経路を使っていることを報 告すれば、 [default] がそのホップの後に表示されます。 -v フラグが指定されていれば、そのパケットを転送するのに使われた経路が [18.26.0/24] の形式で表示されます。

2 番目のセクションでは転送の経路が図によって表示されます。 データの流れは下向きの矢印で表され、問い合わせの経路は上向きの矢印で表されます。 各ホップでは、ルータの入力アドレスと出力アドレスが違っていれば、それらの アドレスが、そのホップパケットを転送するのに必要な ttl の初期値と、 両端のルータのクロックが同期していると想定した場合のホップにまたがった 伝搬遅れとともに表示されます。 このセクションの右半分は 2 組の統計情報から構成されます。 最初のカラムには各ホップでの全てのトラフィックについての 平均のパケットレートが表示されます。 残りのカラムでは消失したパケットの数、送信したパケットの数、 消失したパーセンテージ、それに平均パケットレートが 各ホップについて表示されます。 これらの統計情報は上で解説したように トレース間の差とホップ間の差から計算されます。 最初のグループでは、 あるホップでのインタフェースにおける全流出トラフィックと次のホップでの全流入 トラフィックの統計情報が表示されます。 2 番目のグループでは、指定された source から指定された group への転送トラフィックのみについての統計情報が表示されます。 統計の最初のグループは -T オプションを使って消失レートを含ませることもできます。 しかし、これらの数字は大幅な誤差を含む可能性があり、 これらを適切に解釈するためにはルータについての詳細な知識が要求されるでしょう。

これらの統計情報は各々のホップにつき 1 行か 2　行で表示されます。 オプションが何も指定されていないと、この出力中の 2 番目のセクションは最初 のトレースからおよそ 10 秒後に 1 度のみ表示されます。 各ホップにつき 1 行にその 10 秒間での統計情報を表示します。 もし -l オプションが指定されていると、2 番目のセクションは 10 秒ごとに繰り返さ れ、各ホップにつき 2 行が表示されます。最初の行ではそれまでの 10 秒間 における統計が表示され、2 番目の行で最初のトレースからの累積の統計情報 が表示されます。下の例ではこれは 101 秒間での統計となっています。 -s オプションが指定されるか、マルチキャストグループが指定されていると、 この出力での 2 番目のセクションは省略されます。

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

パケットのカウント数はトレースの問い合わせが伝搬するとともに変化するた め、統計情報中には小さな誤差 (1 か 2 のずれ) が含まれることがあります。 しかし、これらの誤差は累積されるべきではないため、累積統計行では あらたなトレースが 10 秒ごとに実行されるたびに精度が増さなければなりません。 大きな誤差の要因としては 2 つあり、このいずれもマイナスのロスとして現われます。

あるノードへの入力カウントが他のノードがアタッチされているマルチアクセス ネットワークからのものであれば、入力カウントはアタッチされている全てのノード からの出力カウントの総和となります (もしくは近くなります) が、 トレースしている経路上のその前のホップからの出力カウントは その単なる一部分となります。 そのため、出力カウントから入力カウントを引いたものはマイナスの値になります。

SunOS およびその他のシステムにおける DVMRP マルチキャスト転送ソフトウェアの リリース 3.3 では、ルータにおいて生成されたマルチキャストパケット はインタフェースに入力されていない場合においても、入力されたものとして カウントされます。 これは上の例において見ることのできるマイナスのロスとなります。

これらのマイナスのロスはプラスのロスを隠してしまうことが あることに注意してください。

この例ではまた、1 つマイナスのホップの時間が表示されています。 これは単にそのホップ間でのシステムクロックが同期していないことを示しています。 この例ではまた、送られたパケットの数が 10 より少ない時には、パーセンテージの 値は統計的に有効ではないため、ロスのパーセンテージが 2 つのダッシュ として表示されることも示しています。

2 番目の例では ローカルでない receiver へのトレースを示します。 問い合わせは -g オプションによって最終ホップのルータに送られます。 この例では、全逆経路のトレースが、マルチキャストトレースルート機能が実装されていない 古いバージョンの mrouted が動作しているノードがあるために応答なしの結果となっており、そのため mtrace は hop-by-hop モードに切り替わっています。 "Output pruned" のエラーコードは グループ 224.2.143.24 へのトラフィックが転送されていないことを示しています。

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

Ajit Thyagarajan によって書かれた最初のプロトタイプをベースにして、 Steve Casner によって実装されました。 マルチキャストトレースルートのメカニズムは Steve Casner, Steve Deering, Dino Farinacci, Deb Agrawal の助けを得て、 Van Jacobson によって設計され、 Ajit Thyagarajan と Bill Fenner によって mrouted に実装されました。 オプションの構文と mtrace の出力形式は、 Van Jacobson によって書かれたユニキャストの traceroute をモデルにしています。

受動モードでの統計収集は、能動的にデータを収集しているときと常に同じ 出力とはなりません。