| TRACEROUTE(8) | FreeBSD System Manager's Manual | TRACEROUTE(8) |
名称
traceroute — パケットがネットワークのホストを経由する経路を印刷 (表示) する書式
| traceroute | [ -adDeFISnrvx][ -f first_ttl][ -g gateway][ -M first_ttl][ -m max_ttl][ -P proto][ -p port][ -q nqueries][ -s src_addr][ -t tos][ -w waittime][ -A as_server][ -z pausemsecs] host [ packetlen] |
解説
インターネットは、ゲートウェイによってお互いに接続されたネットワークハードウェアの大きくて複雑な集合体です。 1 つのパケットのフローの経路を追跡すること (または、利用者のパケットを廃棄している邪悪なゲートウェイを見つけること) は、困難であるかもしれません。 traceroute は、IP プロトコルの `有効期間 (time to live)' フィールドを利用して、あるホストへの経路に沿った各ゲートウェイからの ICMP TIME_EXCEEDED 応答を引き出すことを試みます。ただ一つの必須パラメータは、宛先 (終点) のホスト名または IP 番号です。デフォルトのプローブデータグラムの長さは、40 バイトですが、これは、宛先のホスト名の後にパケット長を (バイト単位で) 指定することによって増加されます。
他のオプションは、次の通りです:
- -a
- 遭遇した各中継点 (hop) のための AS# 検索をオンにします。
- -A as_server
- AS# 検索をオンにし、デフォルトの代わりに与えられたサーバを使用します。
- -e
- ファイアウォール回避モード。 UDP と TCP プローブのために固定された宛先 (終点) ポートを使用します。宛先 (終点) ポートは、パケットの送信ごとに増加「しません」。
- -f first_ttl
- 最初の発信プローブパケットで使用される最初の有効期間 (time-to-live) を設定します。
- -F
- "破片化しない"ビットを設定します。
- -d
- ソケットレベルデバッグを有効にします。
- -D
- プローブデータグラムへの ICMP 応答が受信されたとき、 ICMP 応答によって転送されたパケットとクォートされたパケットの違いを印刷 (表示) します。転送されたパケット内のフィールドの位置を示すキーが印刷 (表示) され、 16 進数でオリジナルのパケットが続き、16 進数でクォートされたパケットが続きます。クォートされたパケット内の変更されていないバイトは、下線を付けて表示されます。注意、IP チェックサムとクォートされたパケットの TTL は、適合しないはずです。デフォルトで、1 つの中継点 (hop) ごとに 1 つのプローブだけが、このオプションを付けて送信されます。
- -g gateway
- ゆるい (loose) 発信元 (始点) 経路のゲートウェイ (最大 8) を指定します。
- -i iface
- 発信プローブパケットのための発信元 IP アドレスを取得するためのネットワークインタフェースを指定します。これは、通常マルチホームのホストでのみ役に立ちます。 (これを行う別の方法については、 -s フラグを参照してください。)
- -I
- UDP データグラムの代わりに ICMP ECHO を使用します。 ("-P icmp"と同義語です)。
- -M first_ttl
- 発信プローブパケットで使用される最初の有効期間 (time-to-live) の値を設定します。デフォルトは、1 であり、すなわち、最初の中継点 (hop) から開始します。
- -m max_ttl
- 発信プローブパケットで使用される最大の有効期間 (中継点の最大数) を設定します。デフォルトは、 net.inet.ip.ttl sysctl(8) (TCP 接続のために使用されるデフォルトと同じ) の値です。
- -n
- シンボル的でも数値的でもなく、数値的な中継点のアドレスを印刷 (表示) します (経路で見つかった各ゲートウェイのためにネームサーバのアドレスから名前 (address-to-name) 検索を保存します)。
- -P proto
- 指定された IP プロトコルのパケットを送信します。現在サポートされているプロトコルは、次の通りです: UDP、TCP、GRE と ICMP。他のプロトコルも (名前または数値で) 指定できますが、 traceroute は、それらのパケット形式についての特別の知識を実装していません。このオプションは、経路に沿ったどのルータが IP プロトコル番号に基づいてパケットをブロックしているかを判断するために役に立ちます。しかし、下記の「バグ」を参照してください。
- -p port
- プロトコル特有です。 UDP と TCP に関して、プローブで使用される基本の (base) port 番号を設定します (デフォルトは、33434 です)。 traceroute は、宛先ホストで base から base + nhops * nprobes - 1 までの UDP ポートで listen (接続を受け付け) していないことを期待します (それで、ICMP PORT_UNREACHABLE メッセージが、経路追跡を終了するために返されます)。デフォルトの範囲のポートで listen (接続を受け付け) しているものがあるなら、未使用のポート範囲を取り出すために、このオプションを使用することができます。
- -q nqueries
- 中継点 (hop) ごとのプローブの数を設定します (1 であるとき、 -D が指定されなければ、デフォルトは、3 です)。
- -r
- 通常の経路表 (ルーティングテーブル) を迂回して、アタッチされたネットワークのホストに直接送信します。ホストが直接アタッチされたネットワークにないなら、エラーが返されます。 (例えば、インタフェースが routed(8) によって落された後に) それを通す経路がないインタフェースを通してローカルホストを ping するために、このオプションを使用することができます。
- -s src_addr
- 発信プローブパケットの発信元アドレスとして、(通常、ホスト名ではなく、 IP 番号として与えられる) 続く IP アドレスを使用します (2 つ以上の IP アドレスがある) マルチホームのホストにおいて、プローブパケットが送信されるインタフェースの IP アドレス以外への発信元アドレスに強制的に、このオプションを使用することができます。 IP アドレスがこのマシンのインタフェースのアドレスの 1 つでないなら、エラーが返され、何も送信されません。 (これを行う別の方法については、 -i フラグを参照してください。)
- -S
- どれだけのプローブが各中継点に対して応答しなかったかの要約を印刷 (表示) します。
- -t tos
- プローブパケットの type-of-service に続く値 (デフォルトは、0) に設定します。値は、範囲 0 から 255 の 10 進整数でなければなりません。デフォルトの types-of-service が異なる経路の結果となるかどうか調べるために、このオプションを使用することができます。 (4.4bsd を実行していないなら、telnet と ftp のような通常のネットワークサービスが TOS を制御しないので、学術的であるかもしれません)。 TOS のすべての値が、正しく意味があるとは限りません-定義については、IP の仕様を参照してください。有用な値は、おそらく -t 16 (低い遅延) と -t 8 (高いスループット) です。
- -v
- 冗長な出力。 TIME_EXCEEDED と UNREACHABLE 以外の受信 ICMP パケットがリストされます。
- -w waittime
- プローブ (デフォルトは、5 秒) に対する応答のためにウェートする (秒単位の) 時間を設定します。
- -x
- IP チェックサムを切り替えます。通常、これは、traceroute が IP チェックサムを計算することを抑制します。ある場合には、オペレーティングシステムは、発信パケットの部分を上書きすることができますが、チェックサムを再計算しません (それで、ある場合には、デフォルトは、チェックサムを計算しないことであり、 -x を使用することによって、それらは、計算されます)。 ICMP ECHO プローブ ( -I) を使用するとき、チェックサムは、通常、最後の中継点のために必要であることに注意してください。したがって、ICMP を使用するとき、それらは、常に計算されます。
- -z pausemsecs
- プローブの間に停止する時間を (ミリ秒単位で) 設定します (デフォルトは、0)。 Solaris のようないくつかのシステムと Ciscos のようなルータは、 ICMP メッセージの速度を制限します。これと共に使用する良い値は、500 (例えば、1/2 秒) です。
このプログラムは、IP パケットが、小さな ttl (有効期間) で UDP プローブパケットを開始することによって、いくつかのインターネットホストに続く、経路を追跡することを試みます。 1 の ttl でプローブを開始し、("ホスト"に到達したことを意味する) ICMP "port unreachable"を取得するか、または最大 (デフォルトは、 net.inet.ip.ttl sysctl(8) によって指定された中継点の量で、 -m フラグで変換することができる) に到達するまで、1 づつ増加します。 ( -q フラグで変更される) 3 つのプローブは、各 ttl の設定で送信され、ttl、ケートウェイのアドレスと各プローブの往復 (ラウンドトリップ) 時間を示す 1 行に印刷 (表示) します。プローブの答えが異なるゲートウェイから来るなら、各応答システムのアドレスが印刷 (表示) されます。 ( -w フラグで変更される) 5 秒のタイムアウトの間隔以内に応答がないなら、そのプローブに対して "*"が印刷 (表示) されます。
UDP プローブパケットを処理する宛先のホストを必要としないので、宛先のポートは、ありそうもない値に設定されます (宛先の一部のばか者が、その値を使用しているなら、 -p フラグで変更することができます)。
使用と出力の例は、次の通りです:
% 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 番目の中継点のシステム- lilac-dmc.Berkeley.EDU -で、0 の ttl でパケットを転送する (4.3BSD で配布されたバージョンのバグ) というバグのあるカーネルのためです。 NSFNet (129.140) は、その NSSes のためにアドレスから名前の変換を供給していないので、パケットがどの経路 (path) 巡ったかを推測しなければならないことに注意してください。
もっと興味深い例は、次の通りです:
% 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
ゲートウェイ 12、14、15、16 と 17 の遠くの中継点は、 ICMP "time exceeded"メッセージを送信しないか、または我々に到達するのに小さすぎる ttl で、それらを送信することに注意してください。 14 から 17 は、"time exceeded"を送信しない MIT C ゲートウェイコードを実行しています。 12 で何が起こっているかは、誰も知りません (神のみぞ知る)。
上記の寡黙なゲートウェイ 12 は、4.[23]BSD ネットワークコード (と、その派生物) のバグの結果であるかもしれません。 4.x (x <= 3) は、オリジナルのデータグラムに残っている ttl は何でも使用して、到達しないメッセージを送信します。ゲートウェイについて、残りの 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 は、最終の宛先) があり、正確に、それらの最後の半分が "失われている (missing)"であることに注意してください。実際に何が起こっていることは、rip (Sun-3 は、Sun OS3.5 を実行しいる) がその ICMP 応答で ttl として到着するデータグラムから ttl を使用していることです。それで、応答は、少なくとも 2 倍の経路の長さの ttl でプローブするまで、 (ICMP が ICMP のために送信されないので、誰のもとへ送信するかの通知なしで) 戻りの経路でタイムアウトします。すなわち、rip は、実際に 7 の中継点離れているのみです。 1 の ttl で返る応答は、存在する、この問題の手掛かりです。 traceroute は、ttl が <= 1 であるなら、時間の後に "!"を印刷 (表示) します。ベンダは、多くの旧式の (DEC の Ultrix, Sun 3.x) または非標準の (HP-UX) ソフトウェアを出荷しているので、この問題を頻繁に調べ、および/または利用者のプローブのターゲットのホストを注意して選ぶことを期待します。
時間の後に指定できる他の注釈は、次の通りです:
- !H
- ホスト到達不能。
- !N
- ネットワーク到達不能。
- !P
- プロトコル到達不能。
- !S
- 発信元 (始点) 経路失敗。
- !F-<pmtu>
- 必要な断片化 (fragmentation)。 RFC1191 Path MTU Discovery 値が表示されます。
- !U
- 宛先 (終点) ネットワークが未知。
- !W
- 宛先 (終点) ホストが未知。
- !I
- 発信元 (始点) ホストが分離されている。
- !A
- 管理上禁止される宛先ネットワークとの通信。
- !Z
- 管理上禁止される宛先ホストとの通信。
- !Q
- この ToS について、宛先ネットワークは、到達不能。
- !T
- この ToS について、宛先ホストは、到達不能。
- !X
- 管理上禁止される通信。
- !V
- ホスト優先順位違反。
- !C
- 優先順位効果遮断。
- !<num>
- ICMP 到達不能コード <num>。
これらは、(RFC1716 に取って代わる) RFC1812 によって定義されます。ほとんどすべてのプローブがある種類の到達不能の結果であるなら、 traceroute は、断念して、終了します。
このプログラムは、ネットワークの検査、測定と管理で使用するためのものです。それは、主として手動の障害の分離に使用されるべきです。ネットワークで負荷をかけるかもしれないので、通常の動作の間または自動化されたスクリプトから traceroute を使用することは愚かなことです。
作者
Steve Deering による提案から Van Jacobson によって実装されました。 C. Philip Wood、Tim Seaver と Ken Adelman からの特に適切な提案または修正とともに何千ものキャストによってデバッグされました。バグ
UDP 以外のプロトコルを使用するとき、機能性は、縮小されます。特に、たとえ、それが宛先ホストに到達したとしても、 ICMP メッセージが送り返されないので、それを知る方法がなく、最後のパケットは、しばしば失われたように思われます。 TCP の場合に、 traceroute は、宛先ホスト (またはパケットをフィルタリングしている中間ルータ) から RST を listen (接続を受け付け) するべきですが、これは、まだ実装されていません。AS 番号ケーパビリティは、経路制御データベースサーバの内容とインターネットの現在の状態の相違のために時々不正確であるかもしれない情報を報告します。
| June 19, 2012 | FreeBSD |