traceroute コマンド

traceroute コマンドは、ネットワークのテスト、測定、 および管理に使用することを目的としたものです。

ping コマンドが IP ネットワークの到達可能性を確認しているときには、特定された問題の位置を正確に把握し、 改善することはできません。 次の状態を考慮してください。

  • システムと宛先の間にホップ (例えば、ゲートウェイや経路など) が多数存在し、 パス上のいずれかの位置に問題があると考えられるとき。 宛先システムの問題である可能性がありますが、 パケットが実際に失われた位置を確認する必要があります。
  • ping コマンドがハングアップし、パケットが失われた理由が通知されない。
traceroute コマンドは、パケットの位置と経路が失われた理由を通知します。 ほかの組織または企業に属し、 管理されているルーターとリンクをパケットが通過する必要がある場合は、telnet コマンドによって、 関連するルーターを調べるのは困難です。 traceroute コマンドは、ping コマンドを補足します。
注: traceroute コマンドは、主に手動による障害分離のために使用する必要があります。 ネットワークに負荷がかかるので、 通常の操作または自動化されたスクリプトの実行中には traceroute コマンドを使用しないでください。

traceroute の成功例

traceroute コマンドは、UDP パケットを使用し、ICMP エラー報告機能を使用します。 経由する各ゲートウェイまたはルーターごとに 3 回ずつ、UDP パケットを送信します。 最も近いゲートウェイから開始し、1 つのホップによる検索を拡張します。 最後に、 検索が宛先システムに到達します。 出力には、ゲートウェイ名、ゲートウェイの IP アドレス、 およびゲートウェイの 3 つの往復時間が示されます。 次の例を参照してください。
# traceroute aix1
trying to get source for aix1
source should be 10.53.155.187
traceroute to aix1.austin.ibm.com (10.53.153.120) from 10.53.155.187 (10.53.155.187), 30 hops max
outgoing MTU = 1500
 1  10.111.154.1 (10.111.154.1)  5 ms  3 ms  2 ms
 2  aix1 (10.53.153.120)  5 ms  5 ms  5 ms
次にもう 1 つの例を示します。
# traceroute aix1
trying to get source for aix1
source should be 10.53.155.187
traceroute to aix1.austin.ibm.com (10.53.153.120) from 10.53.155.187 (10.53.155.187), 30 hops max
outgoing MTU = 1500
 1  10.111.154.1 (10.111.154.1)  10 ms  2 ms  3 ms
 2  aix1 (10.53.153.120)  8 ms  7 ms  5 ms

アドレス解決プロトコル (ARP) のエントリーの有効期限が切れたあと、 同じコマンドが繰り返し実行されています。 各ゲートウェイまたは宛先に送られた最初のパケットは、 往復する時間が長くかかっていることに注目してください。 これは、ARP によるオーバーヘッドが原因です。 経路に WAN (広域ネットワーク) が含まれている場合は、接続確立のために最初のパケットがメモリーの多くを占有し、 タイムアウトとなる可能性があります。 各パケットのデフォルト・タイムアウトは 3 秒です。 これは -w オプションで変更できます。

最初の 10 ミリ秒は、送信元システム (9.53.155.187) とゲートウェイ 9.111.154.1 間の ARP が原因となっています。 次の 8 ミリ秒は、ゲートウェイと最終宛先 (wave) 間の ARP が原因となっています。 この場合は DNS を使用すると、traceroute コマンドがパケットを送信する前に必ず、DNS サーバーが検索されます。

traceroute の失敗例

宛先または複合ネットワーク経路までのパスが長い場合は、traceroute コマンドで多くの問題を発見できます。 多くの問題はインプリメンテーションに依存するので、問題の検索に時間がかかることがあるだけです。 関係しているすべてのルーターまたはシステムがユーザーの制御下にあるときには、多くの場合、問題を完全に調べることができます。

ゲートウェイ (ルーター) の問題

次の例では、パケットがシステム 9.53.155.187 から送信されています。 ブリッジまでの経路には 2 つのルーター・システムがあります。 no コマンドのオプション ipforwarding を 0 に設定することにより、2 番目のルーター・システムからルーティング機能が意図的に削除されました。 次の例を参照してください。
# traceroute lamar
trying to get source for lamar
source should be 9.53.155.187
traceroute to lamar.austin.ibm.com (9.3.200.141) from 9.53.155.187 (9.53.155.187), 30 hops max
outgoing MTU = 1500
 1  9.111.154.1 (9.111.154.1)  12 ms  3 ms  2 ms
 2  9.111.154.1 (9.111.154.1)  3 ms !H *  6 ms !H

ICMP エラー・メッセージが表示された場合は、Time ExceededおよびPort Unreachableが受信されると、次のように表示されます。

!H
ホストが到達不可能
!N
ネットワークが到達不可能
!P
プロトコルが到達不可能
!S
送信元経路指定障害
!F
フラグメント化が必要

宛先システムの問題

宛先システムが 3 秒のタイムアウト間隔内に応答しない場合は、すべての照会がタイムアウトになり、結果がアスタリスク (*) で表示されます。
# traceroute chuys
trying to get source for chuys
source should be 9.53.155.187
traceroute to chuys.austin.ibm.com (9.53.155.188) from 9.53.155.187 (9.53.155.187), 30 hops max
outgoing MTU = 1500
 1  * * *
 2  * * *
 3  * * *
^C#

問題の原因が通信リンクであると考えられる場合は、-w フラグを指定してタイムアウト期間を長くします。 まれではありますが、照会されたすべてのポートが使用されている可能性があります。 ポートを変更し、再試行してください。

宛先の「ホップ」の数

もう 1 つの出力例を次に示します。
# traceroute mysystem.university.edu (129.2.130.22)
traceroute to mysystem.university.edu (129.2.130.22), 30 hops max
1 helios.ee.lbl.gov (129.3.112.1) 0 ms 0 ms 0 ms
2 lilac-dmc.university.edu (129.2.216.1) 39 ms 19 ms 39 ms
3 lilac-dmc.university.edu (129.2.215.1) 19 ms 39 ms 19 ms
4 ccngw-ner-cc.university.edu (129.2.135.23) 39 ms 40 ms 19 ms
5 ccn-nerif35.university.edu (129.2.167.35) 39 ms 39 ms 39 ms
6 csgw/university.edu (129.2.132.254) 39 ms 59 ms 39 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 rip.university.EDU (129.2.130.22) 59 ms! 39 ms! 39 ms!