tracerouteコマンドは、情報パケットがソースから宛先に着手する旅をマップするためにLinuxで使用されます。 tracerouteの用途の1つは、ネットワーク全体でデータ損失が発生したときに、そのノードがダウンしていることを示すことができる場所を特定することです。
レコード内の各ホップは、元のPCと意図したターゲットとの間の新しいサーバーまたはルータを反映するため、tracerouteスキャンの結果を確認することで、ネットワークトラフィックに悪影響を与える低速ポイントを特定することもできます。
使い方
ネットワークトラフィックが追跡する特定のルートを評価する（またはパケットを破棄する悪意のあるゲートウェイを見つける）には、いくつかのトラブルシューティングの課題があります。 tracerouteはIPプロトコルを使用します 有効期間 各ゲートウェイから宛先ホストへのパスに沿ったICMP TIME_EXCEEDED応答を要求します。
tracerouteコマンドの実行時に含める必要がある唯一のパラメーターは、宛先のホスト名またはIPアドレスです。
tracerouteの構文とスイッチ
トレースルート -dFInrvx -f first_ttl -g ゲートウェイ -私 Iface -m max_ttl -p 港 -q nqueries -s src_addr -t トゥース -w 待ち時間 -z 一時停止 ホスト パケットレン
上記はtracerouteコマンドをコマンドラインで動作させるために書き出す必要がありますが、1つまたは複数のオプションスイッチを指定することによって、コマンドのパフォーマンスや出力を変更できます。
- -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： 通常のルーティングテーブルをバイパスし、接続されたネットワーク上のホストに直接送信します。ホストが直接接続されたネットワーク上にない場合、エラーが返されます。このオプションを使用して、ローカルホストを経由するルートがないインターフェイスからローカルホストにpingを行うことができます（たとえば、 ルーティングされた （8C））。
- -s： 発信プローブパケットの送信元アドレスとして、次のIPアドレス（通常はホスト名ではなくIP番号として指定されます）を使用します。マルチホームホスト（複数のIPアドレスを持つホスト）では、このオプションを使用して、送信元アドレスをプローブパケットが送信されるインターフェイスのIPアドレス以外のものにすることができます。 IPアドレスがこのマシンのインタフェースアドレスの1つでない場合、エラーが返され、何も送信されません。 （-私 これを行う別の方法のフラグです）。
- -t： をセットする サービスの種類 プローブパケットを次の値（デフォルトはゼロ）に変換します。この値は、0〜255の範囲の10進整数でなければなりません。このオプションを使用すると、サービスの種類によってパスが異なるかどうかを確認できます。 （4.4bsdを実行していない場合、telnetやftpのような通常のネットワークサービスではTOSを制御することができないので、これは学術的かもしれません。）TOSのすべての値が正当であるか意味があるかは定義されていません。有用な値はおそらく `-t 16 '（低遅延）と `-t 8 '（高スループット）。
- -v： 冗長出力。受信したTIME_EXCEEDEDおよびUNREACHABLE以外のICMPパケットが一覧表示されます。
- -w： プローブへの応答を待つ時間（秒）を設定します（デフォルトは5秒です）。
- -バツ： IPチェックサムを切り替えます。通常、これはtracerouteがIPチェックサムを計算するのを防ぎます。場合によっては、オペレーティングシステムが送信パケットの一部を上書きできますが、チェックサムを再計算することはできません。したがって、デフォルトでは、チェックサムを計算しないで-バツ それらを計算させる。 ICMP ECHOプローブを使用する場合は、通常、最後のホップにチェックサムが必要であることに注意してください（-私）ので、ICMP使用時には常に計算されます。
- -z： プローブ間で一時停止する時間（ミリ秒単位）を設定します（デフォルトは0）。 SolarisやCiscoのルータなどの一部のシステムでは、レート制限のicmpメッセージが送信されます。これを使用するとよい値は500（例えば1/2秒）です。
結果の解釈
tracerouteは、小さなTTL（生存時間）のUDPプローブパケットを起動し、ゲートウェイからのICMP「時間超過」応答をリッスンすることによって、IPパケットがインターネットホストに追従する経路の概要を示します。プローブはTTL 1で始まり、ICMPの「到達不能」（パケットが宛先に到着したことを意味します）または最大値の試行に達するまで増加します。デフォルトは30ホップで、変更可能ですその-m フラグ。
tracerouteが実行されると、各TTL設定で3つのプローブが送信され、TTL、ゲートウェイのアドレス、および各プローブの往復時間を示す行がコンソールに表示されます。プローブの応答が異なるゲートウェイから来た場合、応答する各システムのアドレスが印刷されます。 5秒のタイムアウト間隔内に応答がない場合（-w フラグ）には、そのプローブのアスタリスクが印刷されます。
UDPプローブパケット処理によって宛先ホストが圧倒されないようにするために、宛先ポートは、そのデバイスによって使用される可能性の低い値に設定される。宛先のネットワークまたはサービスがそのポートを使用している場合は、-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.3 BSDの分散バージョンのバグ）のパケットを転送します。 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の「時間超過」メッセージを送信しないか、TTLが小さすぎて私達に届かないことに注意してください。 14〜17行目は、「時間超過」メッセージを送信しないMIT Cゲートウェイコードを実行しています。
上記の例のサイレントゲートウェイ12は、4のバグの結果である可能性があります。23 BSDネットワークコードとその派生物：4.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 （Sun-3が稼動するSun OS 3.5）は、着信するデータグラムのTTLをICMP応答のTTLとして使用しています。したがって、パスの長さの少なくとも2倍のTTLでプローブするまで、リプライパスで応答がタイムアウトします（ICMPがICMPに送信されないため、誰にも通知が送られません）。つまり、リッピングは実際にはわずか7回ですホップ離れています。
TTLが1で返される返信は、この問題が存在するという手がかりです。 tracerouteは "！" （DECのUltrix、Sun 3.x）または非標準（HPUX）ソフトウェアを多く出荷しているため、この問題が頻繁に発生し、プローブのターゲットホスト。
時間の後に可能な他の注釈は！H, ！N、または！P （ホスト、ネットワーク、またはプロトコルに到達できない）！S （送信元経路が失敗した）、！F- （断片化が必要 - RFC1191 Path MTU Discoveryの値が表示されます）。！バツ （管理上の通信が禁止されている）！V （ホスト優先違反）、！C （優先順位カットオフ）、または! （ICMP到達不能コード）。これらのコードは、RFC1716に代わるRFC1812によって定義されています。ほとんどすべてのプローブが何らかの到達不能なホストになった場合、tracerouteはあきらめて終了します。
このプログラムは、ネットワークのテスト、測定、および管理に使用することを目的としています。主に手動障害分離に使用する必要があります。ネットワーク上に負荷がかかる可能性があるため、通常の操作や自動スクリプトではtracerouteを使用するのは賢明ではありません。
