TRACEROUTE

Section: Maintenance Commands (8)
Updated: 21 September 2000
索引 jman
 

索引

名称

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 に送ってください。

 

索引

Index

名称
書式
解説
関連項目
作者
バグ

jman


Time: 07:07:46 GMT, January 12, 2009