Museum

Home

Lab Overview

Retrotechnology Articles

Online Manuals

⇒ traceroute(1) — NEWS-os 4.1C

Media Vault

Software Library

Restoration Projects

Artifacts Sought

Related Articles

netstat(1)

ping(8)

TRACEROUTE(1)  —  NEWS-OS Programmer’s Manual

名称

traceroute − パケットの通ったホスト名を表示する

形式

traceroute [ −m max_ttl ] [ −n ] [ −p port ] [ −q nqueries ] [ −r ] [ −s src_addr ] [ −g addr ] [ −t tos ] [ −w ] [ −w waittime ] host [ packetsize ]

解説

現在のインターネットは、ゲートウエイをかいして ネットワークデバイスがつながっている非常に大きく複雑な構成となって います。 パケットがどのようなルートを通っているのか(あるいは、パケットを捨てた ゲートウエイを探す)ことは、難しくなっています。 Traceroute は、IP プロトコルの "time to live" フィールドを利用し、 ICMP TIME_EXCEEDED リスポンスからどのゲートウエイを通ってホストまで 着いたかを引きだそうとするものです。

必ず指定しなければならない引数は、ディスティネーションホストの ホスト名か IP アドレスです。 デフォルトのプローブデータの大きさは、38 バイトです。 ディステネーションホスト名の後ろにバイト単位でパケットサイズを 指定することによって大きくすることも出来ます。 オプションは:

−m time-to-tive (最大ホップ数)を、プローブパケットに設定します。 デフォルトは、30 です。(これは、TCP と同じです)

−n 途中のゲートウェイ名を数値で表示します。(デフォルトはシンボルと数値) これは、ネームサーバーにそれぞれのゲートウエイ名を聞く手間を省きます。

−p ベースとなる UDP のポート番号を設定します。 デフォルトは、33434 です。 Traceroute 自身は、ディステネーションホストかにおいて (ベース値) から (ベース値 + ホップ数 - 1) の範囲にあるポートは、使われていないことを期待しています。(これにより、 ルートのトレースが終了した場合は ICMP PORT_UNREACHABLE が来るのです。) デフォルトでこの範囲のポートを使っているときに、 このオプションによりポート番号を換えてください。

−r 普通のルーティングテーブルをパスして、直接接続のネットワークに送るよう 設定します。 そのホストに直接接続にネットワークがないときには、エラーが 返ります。 このオプションは、そのインターフェースを使うルートがないようなローカル ホストに ping するときのように使います。 (たとえば、 routed(8C) などが、インターフェースを消した場合など ).

−s 次に指定される IP アドレス (このときは、ドット記法をつかってください ホスト名ではありません) を、出力されるパケットのソースアドレスとして使います。 そのホストが、一つ以上の IP アドレスを持っている場合には、 このオプションによって他のインターフェースから送りだされることなく 指定されたアドレスを使うように設定します。 もし、その IP アドレスがそのマシンのインターフェースでない場合には、 エラーが返され何も送られません。

−g IP の LSRR (Loose Source Record Route) を使用を可能にします。 これは、この後に指定されたホスト (あるいは IP アドレス) を経由して、 目的地までをどのように届くかを表示することが出来ます。

−t プローブパケットの type-of-service を、次に与えられた値に設定します。(デフォルトは 0 です) ここで指定する値は、十進で 0 から 255 までの値を設定します。 このオプションは、types-of-service によって異なる結果が出る 場合に使われます。 (4.4BSD でなければ、これは単なる興味本位な ものでしかありません。telnet/ftp などのネットワークサービスでは TOS の値は制御できません。) すべての TOS の値に意味があるわけではありません。 − IP のスペックをご覧下さい。 おそらく、意味があるものは "-t 16" (low delay) と "-t 8" (high throughput) だけのようです。

−v Verbose モードにセットします。 TIME_EXCEEDED と UNREACHABLE 以外の ICMP パケットを受信すると リストアップします。

−w リスポンスの待時間を秒単位で設定します。(デフォルトは 3 秒です)

このコマンドでは、IP パケットがどのようなルートでゲートウエイを 通過していくかをトレースしていくものです。 これは、UDP のプローブパケットを小さな ttl (Time-to-Live) で発信し、 ゲートウエイからの ICMP "time exceeded" のリプライを待つものです。 最初に、ttl 1 で出力し ICMP "port unreachable" を受信する (これはホストに着いたことを示します)まで、ttl の値を一つずつ 増やしながら、最大ホップ数に到達するまでプローブパケットを出し続けます。 最大ホップ数は、デフォルトで 30 そして −m フラグで指定できます) 3 回のプローブ (この回数は、−q フラグで変えられます) が送られて、それぞれに対するリスポンス毎に ttl, ゲートウエイアドレス ラウンドトリップタイムが表示されます。 プローブのリプライが異なったゲートウエイから来た場合には、 それぞれのリプライをプリントします。 3 秒のタイムアウト(−w フラグで変更可能)でリプライがない場合には、 "∗" がプリントされます。

ディスティネーションホストが、この UDP プローブパケットを処理する必要 ありません。 (もし、そのポートが使われている場合には、−p フラグで 変更可能です)

例:

[yak 71]% traceroute nis.nsf.net.
traceroute to nis.nsf.net (35.1.1.48), 30 hops max, 56 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 行目が同じことに注意してください。 これは、二番目のシステム −lbl-csam.arpa − が、 ttl が 0 のパケットを forward するというバグによります。 (このバグは、4.3BSD の distribution に含まれているものです) また、NSFNet (129.140) の大陸横断の部分は、アドレスと 名前の変換が出来ないのでこのようになっています。

例:

[yak 72]% traceroute allspice.lcs.mit.edu.
traceroute to allspice.lcs.mit.edu (18.26.0.115), 30 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 は、MIT の C Gateway コードでこれらは、"time exceeded" を 返しません。12 で何が起こったのかは、正確には分かりませんが。。

上記の 12 では、おそらく 4.[23] BSD のネットワークコードの バグです。4.x (x <= 3) では、元のデータグラムでの ttl 値が なんであれそれを使って unreachable のメッセージを返そうとします。 なぜなら、ゲートウエイでは、ttl がゼロのばあいに、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 OS3.5 の Sun-3 のもの) でも起こります。 これは、到着したデータグラムの ttl 値を ICMP リプライ の ttl として使っていることにあります。 そのために、途中でタイムアウトします。 (ICMP が着かないからといって ICMP を送らないことに注意してください) このため、パスの長さの 2 倍の ttl で送らねばなりません。 参考までに rip は 7 ホップ間でしか送ることはできません。 ttl 1 のパケットに対してもこのような問題が起こります。 traceroute は、 ttl <= 1 のパケットに対して "!" をプリントします。 ベンダーの中には、古いバージョンのもの (DEC’s Ultrix, Sun 3.x) や 標準でないもの (HPUX) などを出荷しているので、 このような問題がしばしば起こります。 そのほかには、 !H, !N, !P (それぞれホスト、ネットワーク、プロトコル unreachable を示します。) また、 !S と !F (source route failed と fragmentation needed を示します) − どちらも起こることはまずありません。もし、起こったとしたら その途中のゲートウェイでなにか起こったと思われます。 もし、すべてのプローブに対していくつかの unreachable がおこると、 traceroute は、終了します。

また、
traceroute -g 10.3.0.5 128.182.0.0
は、Cambridge Mailbridge (10.3.0.5) から PSC (128.182.0.0) への ルートを示します。同様に
traceroute -g 192.5.146.4 -g 10.3.0.5 35.0.0.0
は、PSC (192.5.146.4) から Cambridge Mailbridge (10.3.9.5) を経由して Merit (35.0.0.0) へのルートを表示します。

このコマンドは、ネットワークのテスト、性能評価、管理のためのものです。 これは、また手動の fault isolation のために主に用いられるものです。 これは、ネットワークの負荷を強いるものなので これを通常用いることや自動化されたスクリプトで traceroute を用いることは止めてください。

著者

Steve Deering の助言の基、Van Jacobson によりインプリメントされました。 C. Philip Wood, Tim Seaver, Ken Adelman は、非常に多くの 助言を与えてくれたため、デバックの大きな助けとなりました。

関連事項

netstat(1) ping(8)

NEWS-OSRelease 4.1C

Typewritten Software • bear@typewritten.org • Edmonds, WA 98026