Traceroute - Linuxコマンド - Unixコマンド

traceroute - ネットワークホストへのパケットのルートを出力する

シノプシス

traceroute [ -dFInrvx ] [ -f first_ttl ] [ -g ゲートウェイ ]

[ -i iface ] [ -m max_ttl] [ -p port ]

[ -q nqueries ] [ -s src_addr ] [ -t tos ]

[ -w waittime ] [ -z pausemsecs ]

ホスト [ packetlen ]

説明

インターネットは、ネットワークハードウェアの大規模かつ複雑な集約であり、ゲートウェイによって接続されています。 パケットのルートを追跡する(またはパケットを破棄する邪魔なゲートウェイを見つける)のは難しいかもしれません。 tracerouteは、 IPプロトコルの `time to live 'フィールドを利用して、あるホストへのパスに沿って各ゲートウェイからICMP TIME_EXCEEDED応答を引き出すことを試みます。

唯一の必須パラメータは、宛先ホスト名またはIP番号です。 デフォルトのプローブ・データグラムの長さは40 バイトですが、宛先ホスト名の後にパケット長(バイト単位)を指定することで、これを増やすことができます。

その他のオプションは次のとおりです。

-f

最初の発信プローブパケットで使用された初期生存時間を設定します。

-F

「断片化しない」ビットを設定します。

-d

ソケットレベルのデバッグを有効にします。

-g

ルースソースルートゲートウェイを指定します(最大8)。

-私

発信プローブパケットの送信元IPアドレスを取得するネットワークインターフェイスを指定します。 通常、これはマルチホームホストでのみ有効です。 (これを行う別の方法については、 -sフラグを参照してください)。

-私

UDPデータグラムの代わりにICMP ECHOを使用してください。

-m

発信プローブパケットで使用される最大存続可能時間(ホップの最大数)を設定します。 デフォルトは30ホップです(TCP接続で使用されるデフォルトと同じ)。

-n

記号的および数値的ではなく数値的にホップアドレスを出力します(パス上にある各ゲートウェイのネームサーバーのアドレスから名前へのルックアップを保存します)。

-p

プローブで使用される基本UDPポート番号を設定します(デフォルトは33434)。 Tracerouteは、目的地ホストでUDPポートベースの ベース+ nhops-1をリッスンするものは何もないと考えています(ルートトレースを終了するためにICMP PORT_UNREACHABLEメッセージが返されます)。 既定の範囲のポートで何かをリッスンしている場合、このオプションを使用して未使用のポート範囲を選択できます。

-r

通常のルーティングテーブルをバイパスし、接続されたネットワーク上のホストに直接送信します。 ホストが直接接続されたネットワーク上にない場合、エラーが返されます。 このオプションは、経路を持たないインターフェース(例えば、インターフェースが経路指定された (8C)によってドロップされた後など)を介してローカルホストにpingするために使用できます。

-s

発信プローブパケットの送信元アドレスとして、次のIPアドレス(通常はホスト名ではなくIP番号として指定されます)を使用します。 マルチホームホスト(複数のIPアドレスを持つホスト)では、このオプションを使用して、送信元アドレスをプローブパケットが送信されるインターフェイスのIPアドレス以外のものにすることができます。 IPアドレスがこのマシンのインタフェースアドレスの1つでない場合、エラーが返され、何も送信されません。 (これを行う別の方法については、 -iフラグを参照してください)。

-t

プローブパケットのサービスタイプを次の値(デフォルトは0)に設定します。 この値は、0〜255の範囲の10進整数でなければなりません。このオプションを使用すると、サービスの種類によってパスが異なるかどうかを確認できます。 (4.4bsdを実行していない場合は、telnetやftpのような通常のネットワークサービスがあなたにTOSを制御させないので、これは学術的かもしれません)。 TOSのすべての値が合法であるか意味があるわけではありません - 定義のIP仕様を参照してください。 有用な値はおそらく ` -t 16 '(低遅延)と` -t 8 '(高スループット)です。

-v

冗長出力。 受信したTIME_EXCEEDEDおよびUNREACHABLE以外のICMPパケットが一覧表示されます。

-w

プローブへの応答を待つ時間(秒)を設定します(デフォルトは5秒です)。

-バツ

IPチェックサムを切り替えます。 通常、これはtracerouteがIPチェックサムを計算するのを防ぎます。 場合によっては、発信パケットの一部を上書きしてチェックサムを再計算することはできません(デフォルトでは、チェックサムを計算しないで、 -xを使用すると計算されます)。 ICMP ECHOプローブ( -I )を使用するときは、通常、最後のホップにチェックサムが必要であることに注意してください。 したがって、ICMPを使用するときは常に計算されます。

-z

プローブ間で一時停止する時間(ミリ秒単位)を設定します(デフォルトは0)。 Solarisなどの一部のシステムやCiscosなどのルータでは、icmpメッセージのレート制限があります。 これと一緒に使うのに良い値は500です(例えば1/2秒)。

このプログラムは、小さなttl(存続時間)のUDPプローブパケットを起動し、ゲートウェイからのICMP「時間超過」応答をリッスンすることによって、IPパケットがいくつかのインターネットホストに従うルートをトレースしようとします。 ICMPの "到達不能"(つまり "ホスト"する)またはmaxを打つ(デフォルトでは30ホップになり、 -mで変更できる)まで、ttlでプローブを開始し、フラグ)。 各ttl設定で3つのプローブ( -qフラグで変更)が送信され、ttl、ゲートウェイのアドレス、および各プローブの往復時間を示す行が印刷されます。 プローブの応答が異なるゲートウェイから来た場合、応答する各システムのアドレスが出力されます。 5秒以内に応答がない場合。 タイムアウト間隔( -wフラグで変更)、そのプローブには「*」が表示されます。

宛先ポートがUDPプローブパケットを処理しないように、宛先ポートが設定されていない値に設定されていないようにしてください(宛先の一部のclodがその値を使用している場合は、 -pフラグを使用して変更できます)。

サンプルの使用と出力は次のようになります。

[yak 71]%traceroute nis.nsf.net。 traceroute to nis.nsf.net(35.1.1.48)、最大30ホップ、38バイトパケット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 (128.32.168.22)39ms 39ms 39ms 6 128.32.197.4(128.32.197.4)40ms 59ms 59ms 7 131.119.2.5(131.119.2.5)59ms 59ms 59ms 8 129.140。 70.13(129.140.70.13)99ms 99ms 80ms 9 129.140.71.6(129.140.71.6)139ms 239ms 319ms 10 129.140.81.7(129.140.81.7)220ms 199ms 199ms 11nic.merit.edu(35.1 1.148)239ms 239ms 239ms

2行目と3行目は同じであることに注意してください。 これは、第2ホップシステムのバグのあるカーネル(lbl-csam.arpa)が、ゼロttlでパケットを転送するためです(4.3BSDの分散バージョンのバグ)。 NSFNet(129.140)がNSSのアドレスから名前への変換を提供していないので、パケットがクロスカントリーでどのような経路をとっているかを推測しなければならないことに注意してください。

もっと興味深い例があります:

[yak 72]%traceroute allspice.lcs.mit.edu。 traceroute to allspice.lcs.mit.edu(18.26.0.115)、30ホップ最大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)20ms 39ms 39ms 6 128.32.197.4(128.32.197.4)59ms 119ms 39ms 7 131.119.2.5(131.119.2.5)59ms 59ms 39ms 8 129.140.70.13( 129.140.70.13)80ms 79ms 99ms 9 129.140.71.6(129.140.71.6)139ms 139ms 159ms 10 129.140.81.7(129.140.81.7)199ms 180ms 300ms 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)339ms 279ms 279ms

ゲートウェイ12,14,15,16、および17は、ICMPの「時間超過」メッセージを送信しないか、小さすぎて私達に届くことはないことに注意してください。 14〜17が「時間超過」を送信しないMIT Cゲートウェイコードを実行しています。 神は12で何が起こっているかだけ知っています。

上記のサイレントゲートウェイ12は、4のバグの結果かもしれません。[23] BSDネットワークコード(およびその派生物):4.x(x <= 3)は、オリジナルに残っているttlを使用して到達不能メッセージを送信しますデータグラム。 ゲートウェイのために残りのttlはゼロであるので、ICMP「時間超過」はそれを私達に戻さないことが保証されます。 このバグの動作は、宛先システムに表示されるときに少し面白いです:

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ミズ ! 39ミリ秒! 39ミリ秒!

12の「ゲートウェイ」(13が最終的な宛先です)があり、まさに最後の半分が「欠落」であることに注意してください。 本当に起こっているのは、rip(サン3 OSを実行しているSun 3が、到着するデータグラムからのttlをICMP応答のttlとして使用しているということです)。 したがって、パスの長さの少なくとも2倍のttlでプローブするまで、応答はリターンパスでタイムアウトします(ICMPはICMPのために送信されないため、誰にも通知されません)。 つまり、リッピングは実際にわずか7ホップです。 1のttlで返される返信は、この問題が存在するという手がかりです。 tracerouteは "!" (DECのUltrix、Sun 3.x)または非標準(HPUX)ソフトウェアを多く出荷しているので、この問題を頻繁に見て、そして/またはターゲットを慎重に選ぶことを期待してくださいあなたのプローブのホスト。

!H!N 、または!P (ホスト、ネットワークまたはプロトコルに到達できません)、! S (ソースルートが失敗しました)、! F- (断片化が必要 - RFC1191 Path MTU Discovery値が表示されます) !X (管理上の通信禁止)、! V (ホスト優先違反)、! C (優先順位カットオフ)、または (ICMP到達不能コード)。 これらはRFC1812(RFC1716に代わるもの)によって定義されています。 ほとんどすべてのプローブが何らかの到達不能になった場合、tracerouteはあきらめて終了します。

このプログラムは、ネットワークのテスト、測定、および管理に使用することを目的としています。 主に手動障害分離に使用する必要があります。 ネットワーク上に負荷がかかる可能性があるため、通常の操作や自動スクリプトではtracerouteを使用するのは賢明ではありません。

も参照してください

pathchar(8)、netstat(1)、ping(8)