traceroute(8) manページ

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

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

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

-f 最初に送出するプローブパケットの初期の有効期間 (time-to-live) を設定します。

-F 「フラグメント不許可」ビットをセットします。

-d パケットレベルデバッグを有効にします。

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

-i 送出するプローブパケットに使用するための、始点 IP アドレスを取得するネットワークインタフェースを指定します。通常、マルチホームホストでのみ有用です (同じことを行う他の方法については -s を参照してください)。

-I UDP データグラムの代りに ICMP ECHO を使用します ("-P icmp" と同じです)。

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

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

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

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

-p プローブに使用する UDP ポート番号 (デフォルトは 33434) の基準値 (base) を指定します。 traceroute は目的のホストにおいて、 base から base+nhops-1 までの UDP ポートで listen していないことを期待します (そして ICMP PORT_UNREACHABLE メッセージが経路追跡を終了させるために返って来ます)。デフォルトの範囲のポートで listen されているものがある場合は、このオプションを用いて使用されていない範囲のポートを使用することができます。

-q ホップ毎のプローブ回数を指定します (デフォルトは 3 回です)。

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

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

-S 各ホップに対し、何個のプローブに対する応答が無かったかのまとめを表示します。

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

-x IP チェックサムを切り替えます。通常これは、traceroute による IP チェックサムの計算を抑止します。オペレーティングシステムが出力パケットの一部を書き換えることがありますが、チェックサムを再計算しません (そのためデフォルトがチェックサムを計算しないことになっていて、 -x を使用することによりチェックサム計算が有効になる場合があります)。 ICMP ECHO プローブ使用時 (-I) には、最終ホップでは通常チェックサムが必要なことに注意してください。このため、ICMP 使用時には常にチェックサムが計算されます。

-z プローブ間の休止時間 (ミリ秒単位) を設定します (デフォルトは 0)。例えば Solaris のようなシステムや Cisco のようなルータでは、 ICMP メッセージの頻度に制限をかけています。この値には 500 (1/2 秒) を指定すると良いでしょう。

このプログラムは、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 プローブパケットが処理されてしまうことを我々は望みません (目的のホストがその値を使用している場合、 -p フラグで変更することができます)。

使用と出力の例 :

[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

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" が戻ってこないことが保証されます。このバグが目的のシステム上であらわれた場合、さらにもう少し興味深いものとなります。

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 番目は最終目的のホストです) があり、ちょうど半分のゲートウェイが失敗しています。これは、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-<pmtu> (フラグメンテーションが必要 - RFC1191 Path MTU Discovery 値を表示) や、 !X (管理上、通信が禁止されている) や、 !V (ホスト順序違反) や、 !C (順序カットオフがなされた), や、 !<num> (ICMP はコード num では到達できない) があります。これらは RFC1812 (RFC1716 に取って代りました) で定義されています。ほとんど全てのプローブが到達不能であれば、 traceroute は送出を止め終了します。

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

“	A typical Unix /bin or /usr/bin directory contains a hundred different kinds of programs, written by dozens of egotistical programmers, each with its own syntax, operating paradigm, rules of use ... strategies for specifying options, and different sets of constraints.	”
— The Unix Haters' handbook

manページ — TRACEROUTE

名称

内容

書式

解説

関連項目

作者

バグ

-f	最初に送出するプローブパケットの初期の有効期間 (time-to-live) を設定します。
-F	「フラグメント不許可」ビットをセットします。
-d	パケットレベルデバッグを有効にします。
-g	粗く、ソースルーティングのためのゲートウェイを指定します。最大 8 つ指定できます。
-i	送出するプローブパケットに使用するための、始点 IP アドレスを取得するネットワークインタフェースを指定します。通常、マルチホームホストでのみ有用です (同じことを行う他の方法については -s を参照してください)。
-I	UDP データグラムの代りに ICMP ECHO を使用します ("-P icmp" と同じです)。
-M	送出されるプローブパケットの time-to-live の初期値を設定します。デフォルトは 1 であり、最初のホップから開始することを意味します。
-m	送出されるプローブパケットの最大 time-to-live (最大ホップ数) をセットします。デフォルトは net.inet.ip.ttl ホップ (TCP と同じデフォルト値) です。
-n	ゲートウェイのアドレスをホスト名と IP アドレスではなく IP アドレスだけで表示します (ネームサーバへの IP アドレスからホスト名への変換問い合わせを省きます)。
-P	指定した IP プロトコルのパケットを送出します。現在サポートされているプロトコルは UDP, TCP, GRE, ICMP です。他のプロトコルも (名前または数値で) 指定可能ですが、 traceroute はこれらのパケットフォーマットに関する特別な知識は実装していません。経路上のどのルータが IP プロトコル番号に従ってブロックしているかを判定する場合、このオプションが有用です。後述のバグを参照してください。
-p	プローブに使用する UDP ポート番号 (デフォルトは 33434) の基準値 (base) を指定します。 traceroute は目的のホストにおいて、 base から base+nhops-1 までの UDP ポートで listen していないことを期待します (そして ICMP PORT_UNREACHABLE メッセージが経路追跡を終了させるために返って来ます)。デフォルトの範囲のポートで listen されているものがある場合は、このオプションを用いて使用されていない範囲のポートを使用することができます。
-q	ホップ毎のプローブ回数を指定します (デフォルトは 3 回です)。
-r	通常のルーティングテーブルを使用しません。プローブパケットを接続されているネットワーク上のホストに直接送出します。そのホストが直接接続されたネットワーク上にない場合にはエラーが返ります。このオプションは、経路を持たないインタフェースを介してローカルホストに ping する場合 (たとえば、 routed(8C) によってインタフェースが消された後) に使用することができます。
-s	送出されるプローブパケットのソースアドレス (送出するアドレス) として、引数の IP アドレス (通常、ホスト名ではなく、数字で指定します) を用います。マルチホームホスト (複数 IP アドレスを持つホスト) で、プローブパケットに別のソースアドレスを持たせるのに使用することができます。指定した IP アドレスが、このホストのインタフェースのアドレスのうちの 1 つでない場合、エラーが返され何も送出されません (同じことを行う他の方法については -i を参照してください)。
-S	各ホップに対し、何個のプローブに対する応答が無かったかのまとめを表示します。
-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 秒) を (秒単位で) 指定します。
-x	IP チェックサムを切り替えます。通常これは、traceroute による IP チェックサムの計算を抑止します。オペレーティングシステムが出力パケットの一部を書き換えることがありますが、チェックサムを再計算しません (そのためデフォルトがチェックサムを計算しないことになっていて、 -x を使用することによりチェックサム計算が有効になる場合があります)。 ICMP ECHO プローブ使用時 (-I) には、最終ホップでは通常チェックサムが必要なことに注意してください。このため、ICMP 使用時には常にチェックサムが計算されます。
-z	プローブ間の休止時間 (ミリ秒単位) を設定します (デフォルトは 0)。例えば Solaris のようなシステムや Cisco のようなルータでは、 ICMP メッセージの頻度に制限をかけています。この値には 500 (1/2 秒) を指定すると良いでしょう。
このプログラムは、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 プローブパケットが処理されてしまうことを我々は望みません (目的のホストがその値を使用している場合、 -p フラグで変更することができます)。
使用と出力の例 :
	[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 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" が戻ってこないことが保証されます。このバグが目的のシステム上であらわれた場合、さらにもう少し興味深いものとなります。
	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 番目は最終目的のホストです) があり、ちょうど半分のゲートウェイが失敗しています。これは、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-<pmtu> (フラグメンテーションが必要 - RFC1191 Path MTU Discovery 値を表示) や、 !X (管理上、通信が禁止されている) や、 !V (ホスト順序違反) や、 !C (順序カットオフがなされた), や、 !<num> (ICMP はコード num では到達できない) があります。これらは RFC1812 (RFC1716 に取って代りました) で定義されています。ほとんど全てのプローブが到達不能であれば、 traceroute は送出を止め終了します。