Traceroute は、他のネットワーク上のホストへの接続問題を診断しようとしているときに、非常に貴重なツールになります。しかし、効果的に使用するためには、その仕組みと出力の意味を理解する必要があります。
Traceroute は、IP ヘッダの TTL (Time-To-Live) 値を操作することで動作する (図 1)。今回は Stratus の内部ネットワークを使用して例を作成する必要があったので、パケットトレースの IP アドレスの 16 進数表現を X'ed out し、ドット付き 10 進数表記のすべてのオクテットを A から W までのユニークな文字コードに変換した。つまり、AAAは3桁の数字を表し、Jは1桁の数字を表します。
Xmit IP Ver/HL 45, ToS 0, Len 5c, ID 5447, Flg/Frg 0, TTL 3c, Prtl 1 |
図 1 - TTL が強調された packet_monitor フレーム
パケットを処理するすべてのルータはTTL値を1ずつデクリメントし、TTL値が0より大きい場合は次のルータか最終的な宛先にパケットを渡します。TTL値が0の場合、ルータはパケットを破棄し、*may* ICMP time exceededメッセージを送信者に送り返します。重要なのは *may* で、一部のルータは時間超過メッセージを送信しないか、ビジー状態でない場合にのみ送信します。さらに、いくつかのファイアウォールは ICMP メッセージをブロックするので、ルータが時間超過メッセージを送信しても、traceroute を実行しているホストはそれを見ることができないかもしれません。
Tracerouteは、TTL値が1のメッセージを送信することから始まり、メッセージを送信してから応答を得るまでの時間を計測します。
17:07:07.797 Xmit IP Ver/HL 45, ToS 0, Len 28, ID 1, Flg/Frg 0, TTL 1, Prtl 11 17:07:07.799 Rcvd IP Ver/HL 45, ToS c0, Len 38, ID 4a39, Flg/Frg 0, TTL 80, Prtl 1 |
図 2 - packet_monitor traceroute フレームとレスポンス
デフォルトでは、tracerouteコマンドはTTLを1にして3つのメッセージを送信し、3回すべてを報告し、返信を送信したルータの名前とIPアドレスを報告します。私はいつも -numeric 引数を使っているので、名前の解決を待つ必要はありません (図 3)。Tracerouteはその後、TTLを1ずつインクリメントして、それを繰り返します。ターゲット先からの応答が返ってくるか、30 (デフォルトでは) に達するまで TTL をインクリメントし続けます。すべての traceroute 引数については、OpenVOS STREAMS TCP/IP Administrator's Guide (R419 ) のマニュアルを参照してください。
traceroute -numeric EEE.FFF.GGG.HHH |
図 3 - トレースルート出力
図3のホップ6(79 ms)とホップ5(80 ms)の3回目の報告時間を比較してみてください。これにはいくつかの理由があります。第一に、ネットワークは決定論的ではなく、単に時間がかかることがあります。第二に、ホップN-1でのルータは、ホップNでのルータよりも忙しく、ICMPメッセージを送信するために周りを取得するために時間がかかることがあります。最後に、ルータNからの戻りパスは、ルータN-1からの戻りパスよりも速いかもしれません。例えば、4 番目のルータがルータ 3, 2, 1 を経由してソースに応答を送り返す必要はありません。 ルータ 1 に直接応答を送ることができますが、これはかなり速いかもしれません。これは、トレースルートが送信ホストからターゲットホストへのパケットの経路を報告するのに非常に優れている一方で、ターゲットホストから送信ホストへ送られたパケットが同じ経路を逆に取っているだけでは頼りにならないことを意味します。これは非対称ルーティングとして知られています。
Traceroute は、期待された時間超過メッセージ以外のものを受信したことを示すフラグを時刻に追加することができます。フラグは以下の通りです。
!H - ホストにアクセスできません。
N - ネットワークにアクセスできません。
!P - プロトコルにアクセスできません。
N - ネットワークにアクセスできません。
!P - プロトコルにアクセスできません。
例えば、図4では、最初のルータはターゲットネットワークに到達する方法を知らないため、ネットワーク到達不能メッセージを返し、その時点でtracerouteが終了していることを示しています。
traceroute EEE.FFF.GGG.HHH -numeric |
図4 ネットワーク未到達メッセージ
時間の代わりにアスタリスク (*) が付いている場合は、 traceroute が応答を受信しなかったことを示しています。上で述べたように、ルータが ICMP 時間超過メッセージを送信していない可能性もありますし、 ファイアウォールが帰りの時間超過メッセージをブロックしているか、 ファイアウォールが発信メッセージをブロックしている可能性もあります。また、ネットワークが発信メッセージか返信メッセージのどちらかを落としている可能性もあります。
ホップのタイムアウトが1回、あるいは2回あった場合 (図5) は、おそらくルータがビジー状態でメッセージを送信しなかったか、ネットワークがパケットを落としていたか (あるいはその両方) のどちらかを示していると思われます。図5の8番目のホップに注目してください。IPアドレスの前のアスタリスクは、セットの最初のメッセージがタイムアウトしたことを意味します。
traceroute to EEE.FFF.GGG.HHH (EEE.FFF.GGG.HHH), 30 hops max, 40 byte packets ready 14:43:16 |
図5 -ビジー状態のルーターまたはドロップパケット
3つのメッセージがすべてタイムアウトしても、それ以降のホップが時間を報告している場合(図6)、そのホップのルータがICMP時間超過メッセージを送信していないだけである可能性が高いです。
traceroute to EEE.FFF.GGG.HHH (EEE.FFF.GGG.HHH), 30 hops max, 40 byte packets ready 14:47:01 |
図6 - 応答しないルータ
すべてのホップがあるポイントのタイムアウトを過ぎた場合(図7)は、送信または返信メッセージをブロックしているファイアウォールが存在する可能性が高いです。
traceroute to EEE.FFF.GGG.HHH (EEE.FFF.GGG.HHH), 30 hops max, 40 byte packets |
図 7 - ファイアウォールのブロッキング
もう一つ、あるポイントを過ぎるとタイムアウトする理由があります。それは、ターゲットが反応しない場合です。すべてのターゲットが応答するわけではありません。図7と図8の違いは、図8では最後に応答を送信したルータがターゲットにローカルにいるルータであることです。これはどうやってわかるのでしょうか?例えば、ターゲットが192.168.1.12で、192.168.1.1が最後に応答するルータです。図9では、EEEE.FFF.W.XXXがEEEE.FFF.GGG.HHHより前の最後のルータであることがわかりますが、彼らは最初の16ビットの共通点を持っています。しかし、ターゲットのネットワークで使用されているサブネット方式を知らなければ、尋ねてみなければ確かめる方法はありません。
traceroute to EEE.FFF.GGG.HHH (EEE.FFF.GGG.HHH), 30 hops max, 40 byte packets |
図8 - ターゲットが反応しない
また、同じホップに対して2つ以上のルータから応答を得ることも可能です(図9)。これは、ルータが負荷分散をしているか、ネットワークが不安定でルートが変化している場合に起こる可能性がありますし、図9のケースのように、ルータAAA.BBB.CC.KKKが最適なルータではなく、パケットをAAA.BBB.II.Jに転送した後、ルーティングテーブルを変更するためにソースに戻ってリダイレクトメッセージを送信した場合に起こります。
traceroute EEE.FFF.GGG.HHH -numeric |
図9 - 同じホップに対する2つの応答
tracerouteコマンドには、送信するメッセージの種類によって区別される2つのタイプがあります。MicrosoftWindows システムに搭載されているような、ICMP エコーリクエスト(ping)メッセージを送信するトレースルートもあれば、STCP で動作するような UDP メッセージを送信するトレースルートもあります。パケットを通過させるためにファイアウォールを設定したり、プロトコルアナライザーのフィルタを書き込む必要がある場合、どのタイプのトレースルートを使用しているかを知ることは重要である。また、ターゲットの反応も違ってきます。ターゲットがpingリクエストを受信した場合、pingの応答を返します。UDPメッセージを受信した場合、応答はポート番号に依存します。もしポートが使用中であれば、リスニングしているアプリケーションは、そのパケットがアプリケーションのメッセージ構造の要件に適合しないため、ほとんどの場合パケットを破棄します。ポートが使用中でない場合、ホストはICMP destination port unreachableメッセージを送り返すかもしれない。このため、tracerouteは通常使用されていないポートを選択する。
ターゲットホストがどのポート番号を見るかは、それに到達するために必要なホップ数に依存します。Traceroute は宛先ポートを 33435 (デフォルト) から開始し、メッセージごとにポート番号をインクリメントします (図 10)。したがって、ターゲットは3つの異なるポートを見ていますが、3つすべてが使用されているとは限りません。送信元ポートは、送信プロセスのプロセスIDに基づいています。特定のプロセスは常に同じソースポートを使用します。
dir len proto source destination src port dst port |
Figure 10 - (edited) packet traces showing port number changes
最後に、最初のホップに問題がない限り、問題を修正するためにできることはおそらく多くはありません。STCP(または任意のホストのネットワークスタック)がローカルルータにパケットを送信すると、それは(あなたの)手の届かないところにあります。しかし、もしあなたが応答する最後のホップのIPアドレスやタイムアウトが突然起こり始めるホップを知っていれば、問題がどこにあるのか見当がつき、ネットワーク管理者の正しいグループに連絡して問題を解決することができます。