スポンサーリンク

MTRACE(8) FreeBSD システム管理者マニュアル MTRACE(8)

名称

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 は、トレースの問い合わせ がユニキャストパケットによって受信されかつ、 mroutedsource へ の経路がないと、クラッシュします。そのためターゲットの 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 をモデルにしています。

関連項目

map-mbone(8), mrinfo(8), mrouted(8), traceroute(8)

バグ

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

FreeBSD 10.0 May 8, 1995 FreeBSD 10.0

スポンサーリンク