日本語 man コマンド類 (ja-man-1.1j_5) と日本語 man ドキュメント (ja-man-doc-5.4 (5.4-RELEASE 用) など) をインストールすると、以下のような man コマンド閲覧、キーワード検索が コンソールからできるようになります。
4.11-RELEASE-K, 5.4-RELEASE-K, 5.5-RELEASE-K, 6.0-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.2-RELEASE-K, 8.0-RELEASE-K は、プライベート版 (小金丸が編集してまとめたもの) ですが、 より多くの翻訳したファイルが含まれています。 (5.4-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.2-RELEASE-K, 8.0-RELEASE-K は、全翻訳済み)
6.4-STABLE-K, 7.2-STABLE-K, 8.0-STABLE-K は現在、 作成中で日々更新されています。 最新の snapshots を元に作成しています。
TRACEROUTE(8) TRACEROUTE(8)
名称
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 つでない場合、エラーが返され何も送
出されません (同じことを行う他の方法については -s を参照してくだ
さい)。
-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 に送ってください。
4.3 Berkeley Distribution 21 September 2000 TRACEROUTE(8)