traceroute は、IPv4 の TTL または IPv6 の Hop Limit を徐々に増やしながらプローブを送ります。その値が尽きたルーターは Time Exceeded メッセージを返すことがあり、往路上で応答した地点の一部が明らかになります。
トラブルシューティング · レッスン 3
traceroute
traceroute が応答するホップを検出する仕組みと、欠落、時間、経路変化の解釈方法を学びます。
ホップ検出の仕組み
プローブはホップ上限 1 から始まり、順に増えていきます。最初のルーターが値を一つ減らして 0 にすると、ICMP エラーを返せます。上限 2 なら二番目のルーターで尽きます。この処理を、宛先が応答するか最大値に達するまで続けます。
連続するプローブを、より先のルーターで順に期限切れにするフィールドはどれですか？
プローブ方式
従来の Linux traceroute は、通常、高い宛先ポートへ UDP プローブを送ります。宛先は ICMP Port Unreachable を返して到達を知らせられます。オプションを使えば ICMP Echo や TCP SYN プローブに変更でき、フィルタリングの通過状況が異なる場合があります。
$ traceroute -n example.com
$ traceroute -I -n example.com
$ traceroute -T -p 443 -n example.com
必要な権限と対応オプションは環境ごとに異なります。対象に対して許可された方式だけを使い、結果を比較するときは方式も記録してください。
従来の Linux UDP traceroute は、一般に何を受け取ると終了しますか？
アスタリスクの解釈
アスタリスクは、そのプローブに対応する応答をタイムアウトまでに観測できなかったことを意味します。ルーターが通過トラフィックを転送しながら、診断応答をフィルタリングまたはレート制限している場合もあります。後続ホップが応答したなら、無応答のホップも少なくとも一部のプローブを転送したことは明らかです。
あるホップの * だけから何が証明できますか？
時間と経路の変化
各ホップの時間は制御応答までの往復時間であり、隣り合う表示行の間のリンクが加えた遅延ではありません。ルーターがコントロールプレーンの応答を低優先度にすることもあります。負荷分散によって各プローブが別経路を通る場合があり、名前解決も表示を遅らせます。-n を使えば逆引きを避けられます。
各 ICMP 応答の復路が往路と異なる場合もあります。ボトルネックを特定する前にテストを繰り返し、エンドポイントでのアプリケーション時間と照合してください。
隣接ホップの RTT 値を引いて正確なリンク遅延とすべきでないのはなぜですか？
アプリケーションとの比較
traceroute が宛先へ到達してもサービスが遮断されている場合があり、反対に中継ルーターが応答を隠していてもサービスは動作し得ます。アプリケーションと同じアドレスファミリー、宛先、トランスポートプロトコル、ポートをテストし、traceroute は経路を裏付ける証拠として使ってください。
traceroute が完了すれば、HTTPS サービスが正常だと証明できますか？
レッスン完了
traceroute を完了しました
これで、traceroute を完全な経路を知る万能手段ではなく、ホップ上限付きの連続プローブとして解釈できます。
TTL または Hop Limit の期限切れによるホップ検出を説明する。
UDP、ICMP、TCP のどのプローブを使ったか記録する。
アスタリスクを障害の証明ではなく、応答欠落として扱う。
隣接ホップの RTT から正確なリンク遅延を算出しない。
経路の証拠を実際のアプリケーションと照合する。