traceroute(8) FreeBSD 一般コマンドマニュアル

traceroute

前のページ 上に戻る 次のページ

traceroute




書式

       traceroute [ -Sdnrv ] [ -g gw_host ] [ -M min_ttl ]
               [ -m max_ttl ] [ -P proto ] [ -p port ]
               [ -q nqueries ] [ -s src_addr ] [ -t tos ]
               [ -w waittime ] host [ packetlen ]


解説

       インターネットはネットワーク機器の巨大で複雑な集合体で、ゲ
       ートウェイによって互いに接続されています。パケットの流れを
       追跡すること (あるいはパケットを破棄する悪いゲートウェイを
       見つけること) は大変難しい仕事になり得ます。 traceroute は
       IP プロトコルの `time to live' フィールドを利用して、あ る
       ホ ス ト ま で の 経 路 上 の 全 てのゲートウェイから ICMP
       TIME_EXCEEDED レスポンスを引き出そうと試みます。

       唯一の必須パラメータは目的地のホスト名 (IP アドレスでも可)
       で す。 プローブパケットの長さはデフォルトで 40 バイトです
       が、目的のホスト名の後にパケットサイズを (バイト単位で) 指
       定することによって大きくすることもできます。

       その他のオプションを以下で説明します。

       -S      各ホップについて、どれだけの確認パケットに返答が無
              かったかのまとめを表示します。

       -g     粗く、ソースルーティングのためのゲートウエイを指 定
              します。最大 8 つ指定できます。

       -M      送出されるプローブパケットの time-to-live の初期値
              を設定します。デフォルトは 1 であり、最初のホップか
              ら開始することを意味します。

       -m     送出されるプローブパケットの最大 time-to-live (最大
              ホップ 数)   を セッ ト し ま す。 デ フォ ル ト は
              net.inet.ip.ttl  ホップ (TCP と同じデフォルト値) で
              す。

       -n     ゲートウェイのアドレスをホスト名と IP アドレスで は
              な く IP アドレスだけで表示します (ネームサーバへの
              IP アドレスからホスト名への変換問い合わせを省 き ま
              す)。

       -P      指定した IP プロトコルのパケットを送出します。現在
              サポートされているプロトコルは UPD, TCP, GRE です。
              他 の プ ロトコルも (名前または数値で) 指定可能です
              が、 traceroute はこれらのパケットフォーマットに 関
              す る特別な知識は実装していません。経路上のどのルー
              タが IP プロトコル番号に従ってブロックしているか を
              判 定する場合、このオプションが有用です。後述のバグ
              を参照してください。

              パケットを接続されているネットワーク上のホストに 直
              接 送出します。そのホストが直接接続されたネットワー
              ク上にない場合にはエラーが返ります。このオプショ ン
              は、 経路を持たないインタフェースを介してローカルホ
              ストに ping する場合 (たとえば、 routed8 によってイ
              ン タ フェ ースが消された後) に使用することができま
              す。

       -s     送出されるプローブパケットのソースアドレス (送出 す
              る アドレス) として、引数の IP アドレス (ホスト名で
              はなく、数字で指定して下さい) を用います。複数の IP
              ア ドレスを持つホストで、プローブパケットに別のソー
              スアドレスを持たせるのに使用することができます。 指
              定 した IP アドレスが、このホストのインタフェースの
              アドレスのうちの 1 つでない場合、エラーが返され何も
              送出されません。

       -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 秒) を (
              秒単位で) 指定します。

       こ のプログラムは、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 プローブパケットが処理されてしまうことを我々は望みませ
               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" が戻ってこないことが
       保証されます。このバグが目的のシステム上であらわれた場合、
       さらにもう少し興味深いものとなります。

       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 (ソースルーティングに失敗とフラグ メ
       ンテーションが必要) や、 !X (管理上、通信が禁止されている)
       や、 !<N> (ICMP は コード N では到達できない) があります。
       ほとんど全てのプローブが到達不能であれば、 traceroute は送
       出を止め終了します。

       このコマンドはネットワークの検査、測定、管理のために使用す
       るものです。本来は手動で障害を切り離すために使用されるべき
       ものです。ネットワークにかかる負荷が大きいの で、  tracer-
       oute  を通常の操作や自動的なスクリプトで使用することは愚か
       なことです。


関連項目

       netstat(1), ping(8)


作者

       Steve Deering の提案に基づき Van Jacobson によって実装され
       ま し た。デバッグは何千もの人々、特に C.Philip Wood、 Tim
       Seaver と Ken Adelman による説得力のある提案と修正によって
       行なわれました。

       現 在のバージョンは匿名 ftp を使って以下のところから入手で
       きます。

              ftp://ftp.ee.lbl.gov/traceroute.tar.Z


バグ

       UDP 以外のプロトコルを使用する場合、機能が制限されます。特
       に、最後のパケットがしばしば失われたように見えます。なぜな
       ら、最後のパケットが宛先ホストに到達したとし て も、  ICMP
       メッセージは送り返されないため、それを知る方法が無いためで
       す。 TCP の場合、 traceroute は宛先ホスト (またはパケッ ト
       を フィ ル タしている中間ルータ) からの RST を見るべきです
       が、まだ実装されていません。


ABELNET VPSサービス