日本語 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.4-RELEASE-K, 8.0-RELEASE-K から 8.4-RELEASE-K, 9.0-RELEASE-K から 9.3-RELEASE-K, 10.0-RELEASE-K から 10.3-RELEASE-K, 11.0-RELEASE-K から 11.4-RELEASE-K, 12.0-RELEASE-K, 12.1-RELEASE-K は、 プライベート版 (小金丸が編集してまとめたもの) ですが、 より多くの翻訳したファイルが含まれています。 (5.4-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.4-RELEASE-K, 8.0-RELEASE-K から 8.4-RELEASE-K, 9.0-RELEASE-K から 9.3-RELEASE-K, 10.0-RELEASE-K から 10.3-RELEASE-K, 11.0-RELEASE-K から 11.4-RELEASE-K, 12.0-RELEASE-K から 12.3-RELEASE-K, 13.0-RELEASE-K から 13.2-RELEASE-K は、全翻訳済み)
13.3-STABLE-K, 15.0-CURRENT-K は現在、作成中で日々更新されています。
Table of Contents
TRACEROUTE(8) FreeBSD システム管理者マニュアル TRACEROUTE(8)
名称
traceroute -- パケットがネットワークのホストを経由する経路を印刷 (表示)
する
書式
traceroute [-adDeFISnrvx] [-f first_ttl] [-g gateway] [-M first_ttl]
[-m max_ttl] [-P proto] [-p port] [-q nprobes] [-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、UDP-Lite、TCP と SCTP プローブの
ために固定された宛先 (終点) ポートを使用します。宛先 (終点) ポー
トは、パケットの送信ごとに増加「しません」。
-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 は、宛先ホストで port + 1 から port + (max_ttl -
first_ttl + 1) * nprobes までの UDP ポートで listen (接続を受け付
け) していないことを期待します (それで、ICMP PORT_UNREACHABLE
メッセージが、経路追跡を終了するために返されます)。デフォルトの範
囲のポートで listen (接続を受け付け) しているものがあるなら、未使
用のポート範囲を取り出すために、このオプションを使用することがで
きます。
-q nprobes
中継点 (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 Dis
covery 値が表示されます。
!U 宛先 (終点) ネットワークが未知。
!W 宛先 (終点) ホストが未知。
!I 発信元 (始点) ホストが分離されている。
!A 管理上禁止される宛先ネットワークとの通信。
!Z 管理上禁止される宛先ホストとの通信。
!Q この ToS について、宛先ネットワークは、到達不能。
!T この ToS について、宛先ホストは、到達不能。
!X 管理上禁止される通信。
!V ホスト優先順位違反。
!C 優先順位効果遮断。
!<num> ICMP 到達不能コード <num>。
これらは、(RFC1716 に取って代わる) RFC1812 によって定義されます。ほとんど
すべてのプローブがある種類の到達不能の結果であるなら、traceroute は、断念
して、終了します。
このプログラムは、ネットワークの検査、測定と管理で使用するためのもので
す。それは、主として手動の障害の分離に使用されるべきです。ネットワークで
負荷をかけるかもしれないので、通常の動作の間または自動化されたスクリプト
から traceroute を使用することは愚かなことです。
関連項目
netstat(1), ping(8), ping6(8), traceroute6(8).
作者
Steve Deering による提案から Van Jacobson によって実装されました。C.
Philip Wood、Tim Seaver と Ken Adelman からの特に適切な提案または修正とと
もに何千ものキャストによってデバッグされました。
バグ
UDP 以外のプロトコルを使用するとき、機能性は、縮小されます。特に、たと
え、それが宛先ホストに到達したとしても、ICMP メッセージが送り返されないの
で、それを知る方法がなく、最後のパケットは、しばしば失われたように思われ
ます。TCP の場合に、traceroute は、宛先ホスト (またはパケットをフィルタリ
ングしている中間ルータ) から RST を listen (接続を受け付け) するべきです
が、これは、まだ実装されていません。
AS 番号ケーパビリティは、経路制御データベースサーバの内容とインターネット
の現在の状態の相違のために時々不正確であるかもしれない情報を報告します。
FreeBSD 12.2 June 20, 2019 FreeBSD 12.2