|
traceroute − パケットがネットワーク上のホストまでにたどる経路を表示する |
|
traceroute [ −dFISdnrvx ] [ −f first_ttl ] [ −g gateway ] |
|
[ −i iface ] [ −M first_ttl ] |
|
[ −m max_ttl ] [ −P proto ] [ −p port ] |
|
[ −q nqueries ] [ −s src_addr ] [ −t tos ] |
|
[ −w waittime ] [ −z pausemsecs ] |
|
host [ packetlen ] |
|
インターネットはネットワーク機器の巨大で複雑な集合体で、ゲートウェイ に よっ て互いに接続されています。パケットの流れを追跡すること (あるいはパ ケットを破棄する悪いゲートウェイを見つけること) は大変難しい仕事にな り 得 ます。 traceroute は IP プロトコルの ‘time to live’ フィールドを利用 して、あるホストまでの経路上の全てのゲートウェイから ICMP TIME_EXCEEDED レスポンスを引き出そうと試みます。 唯一の必須パラメータは目的地のホスト名 (IP アドレスでも可) です。プロー ブパケットの長さはデフォルトで 40 バイトですが、目的のホスト名の後に パ ケッ トサイズを (バイト単位で) 指定することによって大きくすることもでき ます。 その他のオプションを以下で説明します。 |
|
−f |
最初に送出するプ ロー ブ パ ケッ ト の 初 期 の 有 効 期 間 (time-to-live) を設定します。 |
||
|
−F |
「フラグメント不許可」ビットをセットします。 |
||
|
−d |
パケットレベルデバッグを有効にします。 |
||
|
−g |
粗く、ソースルーティングのためのゲートウェイを指定します。 最大 8 つ指定できます。 |
||
|
−i |
送出するプローブパケットに使用するための、始点 IP アドレ ス を 取得するネットワークインタフェースを指定します。通常、マルチ ホームホストでのみ有用です (同じことを行う他の方法については −s を参照してください)。 |
||
|
−I |
UDP データグラムの代りに ICMP ECHO を使用します ("-P icmp" と同じです)。 |
||
|
−M |
送出されるプローブパケットの time-to-live の初期値を設定 し ます。デフォルトは 1 であり、最初のホップから開始することを意味 します。 |
||
|
−m |
送出されるプローブパケットの最大 time-to-live (最大 ホッ プ 数) をセットします。デフォルトは net.inet.ip.ttl ホップ (TCP と 同じデフォルト値) です。 |
||
|
−n |
ゲートウェイのアドレスをホスト名と IP アドレスではな く IP ア ドレスだけで表示します (ネームサーバへの IP アドレスからホス ト名への変換問い合わせを省きます)。 |
||
|
−P |
指定した IP プロトコルのパケットを送出します。現在サポー ト されているプロトコルは UDP, TCP, GRE, ICMP です。他のプロトコル も (名前または数値で) 指定可能ですが、 traceroute はこれらの パ ケッ トフォーマットに関する特別な知識は実装していません。経路上 のどのルータが IP プロトコル番号に従ってブロックしているかを 判 定 する場合、このオプションが有用です。後述のバグを参照してくだ さい。 |
||
|
−p |
プローブに使用する UDP ポート番号 (デフォルトは 33434) の基 準 値 (base) を指定します。 traceroute は目的のホストにおいて、 base から base+nhops-1 までの UDP ポートで listen していない こ とを期待します (そして ICMP PORT_UNREACHABLE メッセージが経路追 跡を終了させるために返って来ます)。デフォルトの範囲のポー ト で listen されているものがある場合は、このオプションを用いて使用さ れていない範囲のポートを使用することができます。 |
||
|
−q |
ホップ毎のプローブ回数を指定します (デフォルトは 3 回 で す)。 |
||
|
−r |
通常のルーティングテーブルを使用しません。プローブパケット を接続されているネットワーク上のホストに直接送出します。その ホ ス トが直接接続されたネットワーク上にない場合にはエラーが返りま す。このオプションは、経路を持たないインタフェースを介して ロー カ ルホストに ping する場合 (たとえば、 routed(8C) によってイン タフェースが消された後) に使用することができます。 |
||
|
−s |
送出されるプローブパケットのソースアドレス (送出するアド レ ス) として、引数の IP アドレス (通常、ホスト名ではなく、数字で 指定します) を用います。マルチホームホスト (複数 IP アドレス を 持 つホスト) で、プローブパケットに別のソースアドレスを持たせる のに使用することができます。指定した IP アドレスが、このホス ト のインタフェースのアドレスのうちの 1 つでない場合、エラーが返さ れ何も送出されません (同じことを行う他の方法については −i を 参 照してください)。 |
||
|
−S |
各ホップに対し、何個のプローブに対する応答が無かったかのま とめを表示します。 |
||
|
−t |
プローブパケットの type-of-service に引数の値 (デフォルトは 0) を 指 定 し ま す。 値 は 0 から 255 までの十進数です。 type-of-service の値によって、経路が異なるのかを見るために、 こ の オプションを使用することができます (telnet や ftp のような通 常のネットワークサービスは、 TOS を制御することはできないので、 4.4bsd 以降のシステムでなければ、このオプションの実際的な意味は ありません)。全ての TOS の値に意味があるわけではありません。 定 義 に つ いては IP の詳細を参照してください。おそらく、 ‘-t 16’ (low delay) や ‘-t 8’ (high throughput) が有益な値でしょう。 |
||
|
−v |
冗長モードです。 TIME_EXCEEDED と UNREACHABLE 以外の受信 し た ICMP パケットを表示します。 |
||
|
−w |
プローブパケットの応答時間 (デフォルトは 5 秒) を (秒単位 で) 指定します。 |
||
|
−x |
IP チェックサムを切り替えます。通常これは、traceroute に よ る IP チェックサムの計算を抑止します。オペレーティングシステム が出力パケットの一部を書き換えることがありますが、チェックサ ム を 再計算しません (そのためデフォルトがチェックサムを計算しない ことになっていて、 −x を使用することによりチェックサム計算が 有 効 になる場合があります)。 ICMP ECHO プローブ使用時 (−I) には、 最終ホップでは通常チェックサムが必要なことに注意してくださ い。 このため、ICMP 使用時には常にチェックサムが計算されます。 |
||
|
−z |
プローブ間の休止時間 (ミリ秒単位) を設定します (デフォルト は 0)。例えば Solaris のようなシステムや Cisco のようなルータで は、 ICMP メッセージの頻度に制限をかけています。この値には 500 (1/2 秒) を指定すると良いでしょう。 |
|
このプログラムは、IP パケットがあるホストに到達するまでにたどる経路を追 跡するものです。 UDP プローブパケットを小さな ttl (time to live) で送出 し、ゲートウェイから ICMP "time exceeded" が返ってくるのを待ちます。 ま ず、 プ ロー ブを ttl 1 から始め、(ホストに到達したことを意味する) ICMP "port unreachable" を受け取るまで、ある い は 最 大 ( デ フォ ル ト は net.inet.ip.ttl ですが、 −m フラグで変更できます) になるまで ttl を 1 づつ増やします。各 ttl に対して、3 個 ( −q フラグで変更可能です) の プ ロー ブが送出され、 ttl、ゲートウェイのアドレス、各プローブの往復時間を 1 行に表示します。異なるゲートウェイからプローブが返ってきた場合は、 そ れ ぞれのシステムのアドレスを表示します。 5 秒 ( −w フラグで変更します) 以内に反応がない場合は、各プローブに対して "*" を表示します。 目的のホストのポートが不適当な値に設定されているために、 UDP プローブパ ケッ トが処理されてしまうことを我々は望みません (目的のホストがその値を 使用している場合、 −p フラグで変更することができます)。 使用と出力の例 : |
[yak 71]% traceroute nis.nsf.net. traceroute to nis.nsf.net (35.1.1.48), 64 hops max, 38 byte packet 1 helios.ee.lbl.gov (128.3.112.1) 19 ms 19 ms 0 ms 2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms 3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 39 ms 5 ccn-nerif22.Berkeley.EDU (128.32.168.22) 39 ms 39 ms 39 ms 6 128.32.197.4 (128.32.197.4) 40 ms 59 ms 59 ms 7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 59 ms 8 129.140.70.13 (129.140.70.13) 99 ms 99 ms 80 ms 9 129.140.71.6 (129.140.71.6) 139 ms 239 ms 319 ms 10 129.140.81.7 (129.140.81.7) 220 ms 199 ms 199 ms 11 nic.merit.edu (35.1.1.48) 239 ms 239 ms 239 ms |
|
2 行目と 3 行目が同じであることに注意して下さい。これは、2番目のシス テ ム − lbl-csam.arpa − が、 ttl 0 のパケットを転送するという (4.3BSD に含 まれる) バグを持ったカーネルであることによるも の で す。 ま た、NSFNet (129.140) はアドレスをホスト名に変換してくれないので、パケットがどの経 路をたどったのかを推測する必要があることに注意して下さい。 もっと興味深い例 : |
[yak 72]% traceroute allspice.lcs.mit.edu. traceroute to allspice.lcs.mit.edu (18.26.0.115), 64 hops max 1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms 2 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 ms 19 ms 19 ms 3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 19 ms 19 ms 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 19 ms 39 ms 39 ms 5 ccn-nerif22.Berkeley.EDU (128.32.168.22) 20 ms 39 ms 39 ms 6 128.32.197.4 (128.32.197.4) 59 ms 119 ms 39 ms 7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 39 ms 8 129.140.70.13 (129.140.70.13) 80 ms 79 ms 99 ms 9 129.140.71.6 (129.140.71.6) 139 ms 139 ms 159 ms 10 129.140.81.7 (129.140.81.7) 199 ms 180 ms 300 ms 11 129.140.72.17 (129.140.72.17) 300 ms 239 ms 239 ms 12 * * * 13 128.121.54.72 (128.121.54.72) 259 ms 499 ms 279 ms 14 * * * 15 * * * 16 * * * 17 * * * 18 ALLSPICE.LCS.MIT.EDU (18.26.0.115) 339 ms 279 ms 279 ms |
|
l2, 14, 15, 16, 17 番目のゲートウェイが ICMP "time exceeded" メッセージ を 送出していないか、あるいは送出された ICMP "time exceeded" メッセージ の ttl が小さいために、こちらに到達しないのでしょう。 14 から 17 番目の ホストでは、"time exceeded" を送出しない MIT C Gateway コードが稼動して います。 12 番目で何が起こっているのかは、神のみぞ知るところです。 上記の 12 番目のゲートウェイが反応しないのは、4.[23] BSD ネット ワー ク コー ド ( かその派生プログラム) のバグのせいでしょう。 4.x (x <= 3) で は、元のデータグラムに残っている ttl がどんな値であっても、それを用いて unreachable メッセージを送出します。よって、ゲートウェイに対して残って いる ttlは 0 なので、 ICMP "time exceeded" が戻ってこないことが保証され ま す。このバグが目的のシステム上であらわれた場合、さらにもう少し興味深 いものとなります。 |
1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms 2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 19 ms 39 ms 3 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 ms 39 ms 19 ms 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 19 ms 5 ccn-nerif35.Berkeley.EDU (128.32.168.35) 39 ms 39 ms 39 ms 6 csgw.Berkeley.EDU (128.32.133.254) 39 ms 59 ms 39 ms 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 rip.Berkeley.EDU (128.32.131.22) 59 ms ! 39 ms ! 39 ms ! |
|
12 のゲートウェイ (13 番目は最終目的のホストです) があり、ちょうど半 分 の ゲー トウェイが失敗しています。これは、rip (Sun OS3.5 の稼働している Sun-3) が、到着したデータグラムの ttl を ICMP 応答の ttl としてそのまま 使 用することによるものです。経路の長さの少なくとも 2 倍の ttl のプロー ブが送出されるまで、( ICMP に対して ICMP は送出されないので、誰にも気付 か れ ず に) 帰りの経路上で応答がタイムアウトします。すなわち、実際には rip までに 7 ホップしかありません。 ttlが 1 の応答は、問題解決の糸口 に な ります。 ttlが 1 以下の場合、 traceroute は時間の後に "!" を表示しま す。ベンダは旧式の (DEC の Ultrix、Sun 3.x) あるいは標準でな い (HPUX) ソ フトウェアを多く使用しているので、しばしばこの問題が起こることを承知 して、プローブの目標のホストは注意して選んでください。 時間の後に付くその他の注釈には、 !H, !N, !P (ホスト、ネットワーク、プロ トコルに到達不能) や、 !S (ソースルーティングに失敗) や、 !F−<pmtu> (フ ラグメンテーションが必要 − RFC1191 Path MTU Discovery 値を表示) や、 !X ( 管 理上、通信が禁止されている) や、 !V (ホスト順序違反) や、 !C (順序 カットオフがなされた), や、 !<num> (ICMP は コード num では到達で き な い) があります。これらは RFC1812 (RFC1716 に取って代りました) で定義さ れています。ほとんど全てのプローブが到達不能であれば、 traceroute は 送 出を止め終了します。 こ のコマンドはネットワークの検査、測定、管理のために使用するものです。 本来は手動で障害を切り離すために使用されるべきものです。ネットワーク に か かる負荷が大きいので、 traceroute を通常の操作や自動的なスクリプトで 使用することは愚かなことです。 |
|
pathchar(8), netstat(1), ping(8) |
|
Steve Deering の提案に基づき Van Jacobson によって実装されま し た。 デ バッグは何千もの人々、特に C.Philip Wood、 Tim Seaver と Ken Adelman に よる説得力のある提案と修正によって行なわれました。 現在のバージョンは匿名 ftp を使って以下のところから入手できます。 |
|
ftp://ftp.ee.lbl.gov/traceroute.tar.gz |
|
UDP 以外のプロトコルを使用する場合、機能が制限されます。特に、最後の パ ケッ トがしばしば失われたように見えます。なぜなら、最後のパケットが宛先 ホストに到達したとしても、 ICMP メッセージは送り返されないため、それ を 知る方法が無いためです。 TCP の場合、 traceroute は宛先ホスト (またはパ ケットをフィルタしている中間ルータ) からの RST を見るべきですが、まだ実 装されていません。 バグレポートは、traceroute@ee.lbl.gov に送ってください。 |