【実務・中級編】 ICMPベースtraceroute(Windows tracert)の動作と仕様 – トラブルシューティング＆ネットワーク運用監視実践ガイド

なぜ「tracert」はあてにならないことがあるのか？―ベテランが教える経路探索の裏側

深夜3時、データセンターの監視画面が赤く染まり、Web APIのレスポンスタイムが急上昇している。そんな時、駆け出しのエンジニアが真っ先に叩くのが tracert（Windows）や traceroute（Unix/Linux）だ。「パケットがどこで詰まっているか一発で分かる」と信じているかもしれないが、その「見えている経路」が真実とは限らない。

今日は、ネットワーク運用現場のリアルな視点から、ICMPベースの経路探索の挙動と、OSによる実装の違い、そして実務で遭遇する「落とし穴」について深掘りしよう。

—

1. Windowsの tracert は「ICMP Echo」の執念で動いている

まず、大前提を整理する。Unix系の traceroute は、デフォルトでUDP（ポート33434以降）を使用する。対して、Windowsの tracert は ICMP Echo Request（Type 8） を主体として経路を探索する。

シーケンスの裏側

tracert が実行されると、以下のようなプロセスが繰り返される。

1. TTLの調整: 最初のパケットは TTL=1 で送出される。
2. ルーターの反応: パケットを受け取ったルーターは、TTLを減算して 0 になったことを検知し、送信元へ ICMP Time Exceeded (Type 11) を返す。
3. ホップの特定: これにより、tracert は「そのルーターがそこにいる」ことを特定する。
4. 終了判定: 最終的な宛先に到達すると、ルーターではなく端末自身が ICMP Echo Reply (Type 0) を返し、探索が終了する。

この「ICMPで始まり、ICMPで終わる」という一貫性がWindows流の美学だが、これが現代のWebインフラでは仇となることも多い。

—

2. 実務で直面する「見えない壁」とトラブルシューティング

なぜ、たまに tracert が途中で星印（* * *）だらけになるのか？それは単なる「ネットワーク断」ではない可能性がある。

ICMPの優先度制御: 多くのルーターは、制御用トラフィック（ICMP）をデータプレーンよりも低優先度で処理する。混雑時にはICMPの応答を意図的に破棄するため、経路は通っているのに * と表示されることが多々ある。
ファイアウォールの遮断: セキュリティポリシーで ICMP をブロックしているホストやセグメントは多い。特にクラウドのロードバランサーやステートフルなファイアウォール越しでは、戻りの Time Exceeded が許可されず、経路が可視化できない。

—

3. 実践：ネットワーク診断の現場から

もし君がAPIの疎通確認を自動化したいなら、tracert や traceroute だけに頼るのではなく、より現代的なツールと組み合わせるべきだ。

Pythonを用いた経路情報取得の自動化

単純な ping だけでなく、scapy を使ってパケットレベルで制御すると、より深い分析が可能になる。

from scapy.all import traceroute

# 特定のドメインへの経路を探索し、結果を可視化する
# 実際の運用では結果をパースして、特定のホップで遅延が増大していないか監視する
target = "api.example.com"
result, unans = traceroute(target, maxttl=30)

# 結果の表示（簡易的なログ出力）
result.show()

開発者向け：curl を使った疎通確認のTips

アプリケーション層の視点では、traceroute より curl での TCP Connect が重要だ。

# 接続先までのTCPハンドシェイクにかかる時間を計測
# -w は出力フォーマットの指定（time_connect: TCP接続までの時間）
curl -o /dev/null -s -w "TCP Connect Time: %{time_connect}s\n" https://api.example.com/health

—

4. エンジニアへのアドバイス：ツールに振り回されるな

最後に、百戦錬磨の経験から一つだけアドバイスを送る。「ツールはあくまで状況証拠の一部」だということだ。

tracert でホップが途切れたからといって、即座に「そのルーターがダウンしている」と判断してはいけない。特にマルチホーミングされた大規模ネットワークや、Anycastが採用されているクラウド環境では、パケットごとに経路が微妙に揺らぐ（ECMP: Equal-Cost Multi-Pathルーティング）ことも珍しくない。

traceroute を実行する際は、必ず複数回試行し、経路のバラつきを観察すること。
ICMPが通らない場所を見つけたら、すぐに TCP/UDP ポートレベルの疎通確認（nc や hping3）に切り替えること。

ネットワークの現場では、コマンド一つで全てが解決することなどあり得ない。CLIの出力結果の「裏」にある、パケットの旅路を想像する力を養ってほしい。それが君を、ただのオペレーターから、真のトラブルシューターへと引き上げてくれるはずだ。

さあ、今日はどのパケットを追いかけに行く？健闘を祈る。