path: root/ja_JP.eucJP/man/man8/traceroute.8

.\" Copyright (c) 1989, 1995, 1996
.\"	The Regents of the University of California.  All rights reserved.
.\"
.\" Redistribution and use in source and binary forms are permitted
.\" provided that the above copyright notice and this paragraph are
.\" duplicated in all such forms and that any documentation,
.\" advertising materials, and other materials related to such
.\" distribution and use acknowledge that the software was developed
.\" by the University of California, Berkeley.  The name of the
.\" University may not be used to endorse or promote products derived
.\" from this software without specific prior written permission.
.\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
.\" IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
.\" WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
.\"
.\"	$Header: traceroute.8,v 1.7 96/09/27 20:02:41 leres Exp %
.\"	%FreeBSD: src/usr.sbin/traceroute6/traceroute6.8,v 1.1.2.7 2001/08/16 15:56:37 ru Exp %
.\"
.\" $FreeBSD: doc/ja_JP.eucJP/man/man8/traceroute.8,v 1.13 2001/07/29 05:15:30 horikawa Exp $
.\"
.TH TRACEROUTE 8 "27 September 1996"
.UC 6
.SH 名称
traceroute \- パケットがネットワーク上のホストまでにたどる経路を表示する
.SH 書式
.. while ((op = getopt(argc, argv, "dnrvg:M:m:P:p:q:s:t:w:")) != EOF)
.na
.B traceroute
[
.B \-Sdnrv
] [
.B \-g
.I gw_host
] [
.B \-M
.I min_ttl
]
.br
.ti +8
[
.B \-m
.I max_ttl
] [
.B \-P
.I proto
] [
.B \-p
.I port
]
.br
.ti +8
[
.B \-q
.I nqueries
] [
.B \-s
.I src_addr
] [
.B \-t
.I tos
]
.br
.ti +8
[
.B \-w
.I waittime
]
.I host
[
.I packetlen
]
.ad
.SH 解説
インターネットはネットワーク機器の巨大で複雑な集合体で、
ゲートウェイによって互いに接続されています。
パケットの流れを追跡すること (あるいはパケットを破棄する悪い
ゲートウェイを見つけること) は大変難しい仕事になり得ます。
.I traceroute
は IP プロトコルの `time to live' フィールドを利用して、
あるホストまでの経路上の全てのゲートウェイから
ICMP TIME_EXCEEDED
レスポンスを引き出そうと試みます。
.PP
唯一の必須パラメータは目的地のホスト名 (IP アドレスでも可) です。
プローブパケットの長さはデフォルトで 40 バイトですが、
目的のホスト名の後にパケットサイズを (バイト単位で) 指定することによって
大きくすることもできます。
.PP
その他のオプションを以下で説明します。
.TP
.B \-S
各ホップについて、
どれだけの確認パケットに返答が無かったかのまとめを表示します。
.TP
.B \-g
粗く、ソースルーティングのためのゲートウエイを指定します。
最大 8 つ指定できます。
.TP
.B \-M
送出されるプローブパケットの time-to-live の初期値を設定します。
デフォルトは 1 であり、最初のホップから開始することを意味します。
.TP
.B \-m
送出されるプローブパケットの最大 time-to-live (最大ホップ数) をセットします。
デフォルトは
.I net.inet.ip.ttl
ホップ (TCP と同じデフォルト値) です。
.TP
.B \-n
ゲートウェイのアドレスをホスト名と IP アドレスではなく
IP アドレスだけで表示します
(ネームサーバへの IP アドレスからホスト名への変換問い合わせを省きます)。
.TP
.B \-P
指定した IP プロトコルのパケットを送出します。
現在サポートされているプロトコルは UPD, TCP, GRE です。
他のプロトコルも (名前または数値で) 指定可能ですが、
.I traceroute
はこれらのパケットフォーマットに関する特別な知識は実装していません。
経路上のどのルータが IP プロトコル番号に従ってブロックしているかを
判定する場合、このオプションが有用です。
後述のバグを参照してください。
.TP
.B \-p
プローブに使用する UDP ポート番号 (デフォルトは 33434) の
基準値 (base) を指定します。
.I traceroute
は目的のホストにおいて、
.I base
から
.I base+nhops-1
までの UDP ポートで listen していないことを期待します
(そして ICMP PORT_UNREACHABLE
メッセージが経路追跡を終了させるために返って来ます)。
デフォルトの範囲のポートで listen されているものがある場合は、
このオプションを用いて使用されていない範囲のポートを
使用することができます。
.TP
.B \-q
ホップ毎のプローブ回数を指定します (デフォルトは 3 回です)。
.TP
.B \-r
通常のルーティングテーブルを使用しません。
プローブパケットを接続されているネットワーク上のホストに直接送出します。
そのホストが直接接続されたネットワーク上にない場合には
エラーが返ります。
このオプションは、
経路を持たないインタフェースを介してローカルホストに ping する場合
(たとえば、
.IR routed 8
によってインタフェースが消された後) に使用することができます。
.TP
.B \-s
送出されるプローブパケットのソースアドレス (送出するアドレス) として、
引数の IP アドレス (ホスト名ではなく、数字で指定して下さい) を用います。
複数の IP アドレスを持つホストで、
プローブパケットに別のソースアドレスを
持たせるのに使用することができます。
指定した IP アドレスが、このホストのインタフェースのアドレスのうちの
1 つでない場合、エラーが返され何も送出されません。
.TP
.B \-t
プローブパケットの
.I type-of-service
に引数の値 (デフォルトは 0) を指定します。
値は 0 から 255 までの十進数です。
.I type-of-service
の値によって、経路が異なるのかを見るために、
このオプションを使用することができます。
(telnet や ftp のような通常のネットワークサービスは、
TOS を制御することはできないので、
4.4bsd
以降のシステムでなければ、このオプションの実際的な意味はありません。)
全ての TOS の値に意味があるわけではありません。
定義については IP の詳細を参照してください。
おそらく、`\-t 16' (low delay) や `\-t 8' (high throughput) が
有益な値でしょう。
.TP
.B \-v
冗長モードです。
TIME_EXCEEDED と UNREACHABLE
以外の受信した ICMP パケットを表示します。
.TP
.B \-w
プローブパケットの応答時間 (デフォルトは 5 秒) を (秒単位で) 指定します。
.PP
このプログラムは、IP パケットが
あるホストに到達するまでにたどる経路を追跡するものです。
UDP プローブパケットを小さな ttl (time to live) で送出し、
ゲートウェイから ICMP "time exceeded" が返ってくるのを待ちます。
まず、プローブを ttl 1 から始め、(ホストに到達したことを意味する)
ICMP "port unreachable" を受け取るまで、
あるいは最大 (デフォルトは
.I net.inet.ip.ttl
ですが、 \-m フラグで変更できます)
になるまで ttl を 1 づつ増やします。
各 ttl に対して、3 個 (\-q フラグで変更可能です) のプローブが送出され、
ttl、ゲートウェイのアドレス、各プローブの往復時間を 1 行に表示します。
異なるゲートウェイからプローブが返ってきた場合は、
それぞれのシステムのアドレスを表示します。
5 秒 (\-w フラグで変更します) 以内に反応がない場合は、
各プローブに対して "*" を表示します。
.PP
目的のホストのポートが不適当な値に設定されているために、
UDP プローブパケットが処理されてしまうことを我々は望みません。
(目的のホストがその値を使用している場合、\-p フラグで
変更することができます。)
.PP
使用と出力の例 :

.RS
.nf
[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
.fi
.RE

2 行目と 3 行目が同じであることに注意して下さい。
これは、2番目のシステム \- lbl-csam.arpa \- が、
ttl 0 のパケットを転送するという (4.3BSD に含まれる) バグを
持ったカーネルであることによるものです。
また、NSFNet (129.140) はアドレスをホスト名に変換してくれないので、
パケットがどの経路をたどったのかを
推測する必要があることに注意して下さい。
.PP
もっと興味深い例 :

.RS
.nf
[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
.fi
.RE

l2, 14, 15, 16, 17 番目のゲートウェイが
ICMP "time exceeded" メッセージを送出していないか、
あるいは送出された ICMP "time exceeded" メッセージの ttl が小さいために、
こちらに到達しないのでしょう。
14 から 17 番目のホストでは、"time exceeded" を送出しない
MIT C Gateway コードが稼動しています。
12 番目で何が起こっているのかは、神のみぞ知るところです。
.PP
上記の 12 番目のゲートウェイが反応しないのは、4.[23] BSD
ネットワークコード (かその派生プログラム) のバグのせいでしょう。
4.x (x <= 3) では、元のデータグラムに残っている ttl がどんな値であっても、
それを用いて unreachable メッセージを送出します。
よって、ゲートウェイに対して残っている ttlは 0 なので、
ICMP "time exceeded" が戻ってこないことが保証されます。
このバグが目的のシステム上であらわれた場合、
さらにもう少し興味深いものとなります。

.RS
.nf
 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 !
.fi
.RE

12 のゲートウェイ (13 番目は最終目的のホストです) があり、
ちょうど半分のゲートウェイが失敗しています。
これは、rip (Sun OS3.5 の稼働している Sun-3) が、
到着したデータグラムの ttl を ICMP 応答の ttl としてそのまま使用すること
によるものです。
経路の長さの少なくとも 2 倍の ttl のプローブが送出されるまで、(
ICMP に対して ICMP は送出されないので、誰にも気付かれずに)
帰りの経路上で応答がタイムアウトします。
すなわち、実際には rip までに 7 ホップしかありません。
ttlが 1 の応答は、問題解決の糸口になります。
ttlが 1 以下の場合、
.I traceroute
は時間の後に "!" を表示します。
ベンダは旧式の (DEC の Ultrix、Sun 3.x) あるいは標準でない
(HPUX) ソフトウェアを多く使用しているので、
しばしばこの問題が起こることを承知して、
プローブの目標のホストは注意して選んでください。

時間の後に付くその他の注釈には、
.BR !H ,
.BR !N ,
.BR !P
(それぞれホスト、ネットワーク、プロトコルに到達不能というメッセージを
受け取った) や、
.BR !S ,
.BR !F
(ソースルーティングに失敗とフラグメンテーションが必要) や、
.B !X
(管理上、通信が禁止されている) や、
.B !<N>
(ICMP は コード N では到達できない) があります。
ほとんど全てのプローブが到達不能であれば、
.I traceroute
は送出を止め終了します。
.PP
このコマンドはネットワークの検査、測定、管理のために使用するものです。
本来は手動で障害を切り離すために使用されるべきものです。
ネットワークにかかる負荷が大きいので、
.I traceroute
を通常の操作や自動的なスクリプトで使用することは愚かなことです。
.SH 関連項目
netstat(1), ping(8)
.SH 作者
Steve Deering の提案に基づき Van Jacobson によって実装されました。
デバッグは何千もの人々、特に C.Philip Wood、 Tim Seaver と Ken Adelman
による説得力のある提案と修正によって行なわれました。
.LP
現在のバージョンは匿名 ftp を使って以下のところから入手できます。
.LP
.RS
.I ftp://ftp.ee.lbl.gov/traceroute.tar.Z
.RE
.SH バグ
UDP 以外のプロトコルを使用する場合、機能が制限されます。
特に、最後のパケットがしばしば失われたように見えます。
なぜなら、最後のパケットが宛先ホストに到達したとしても、
ICMP メッセージは送り返されないため、
それを知る方法が無いためです。
TCP の場合、
.I traceroute
は宛先ホスト (またはパケットをフィルタしている中間ルータ) からの RST
を見るべきですが、まだ実装されていません。
.PP
バグレポートは、traceroute@ee.lbl.gov に送ってください。