あなたのIPv4アドレス:
オペレーティングシステム:
プロバイダー:

tracerouteの見方:ホップ、タイムアウト、ネットワーク経路

tracerouteは、パケットが宛先へ向かう際に通りうる経路を診断用に表示するツールです。応答したホップと、プローブへの応答にかかった時間が一覧で表示されます。トレース結果は特定のネットワーク条件下でのスナップショットであり、インターネットの恒久的な地図でも、アプリケーションのすべてのパケットが通る経路の証明でもありません。

tracerouteがホップを見つける仕組み

このプログラムは、ホップ数の上限を少しずつ増やしながらプローブを送ります。上限はIPv4ではTTL、IPv6ではHop Limitです。上限を0まで減らしたルーターは、ICMP Time Exceededの応答を返すことがあります。これを繰り返すことで、往路上で応答した機器の並びが明らかになります。

OSやオプションによって、プローブにはUDP、ICMP、TCPのいずれかが使われます。ファイアウォールやネットワークのポリシーはこれらを別々に扱うため、プローブの種類を変えるとトレース結果も変わることがあります。サービスのポート宛てにTCPのプローブを送ると、デフォルトのUDPプローブより有益な情報が得られる場合もあります。

時間とアスタリスクの読み方

各行はホップの番号を表し、その行に並ぶ複数の時間はそれぞれ別のプローブの結果で、1回の連続した測定ではありません。アスタリスクは通常、タイムアウトまでに応答が届かなかったことを意味します。そのルーターは、診断用のメッセージに応答しなかったり応答数を制限したりしているだけで、通常の通信は問題なく転送しているかもしれません。

途中の1つのホップで応答時間が長くても、そこがボトルネックとは限りません。その後のホップや最終的な宛先でも同じように時間が増えているかを確認しましょう。戻りの通信が別の経路を通ることもありますし、負荷分散によってプローブが往路の別々の経路に振り分けられることもあります。こうした影響があるため、1回のトレースだけでは結果を読み誤りやすいのです。

トラブルシューティングの実践的な手順

Linuxや多くのmacOSではtraceroute example.comを、Windowsではtracert example.comを試してください。宛先、選んだプロトコル、時刻、使ったネットワークを記録します。トレースを何度か実行し、アプリケーションを直接テストした結果と比べましょう。対象には、自分が管理しているドメインか、診断を許可されているドメインを使ってください。

すべてのプローブが1つのホップで止まっていてもWebサイトが表示されるなら、応答がないのは診断上の制約にすぎません。宛先にもつながらない場合は、別のネットワークからのトレースと比べ、DNS、ファイアウォールのルール、サービスそのものを調べます。プロバイダーには結果を簡潔にまとめて伝えましょう。トレースだけでは、障害の原因が誰にあるかは判断できません。

最後に応答したホップだけでなく、出力全体を保存しておきましょう。途中のホップの応答がなくても最終的な宛先から応答がある場合と、宛先がまったく応答しない場合とでは、意味がまるで違います。

BGP、エニーキャスト、経路の変化

tracerouteが観測するのは特定のプローブの経路であり、BGPのポリシーを直接見ているわけではありません。ピアリングが変わればホップの並びも変わりますし、エニーキャストでは同じIPアドレスでも別の拠点につながることがあります。tracerouteの仕組み、BGPとASN、エニーキャストの記事もご覧ください。