なぜパケットは「死」を選ぶのか？ICMP Type 11が語るネットワークの深層
エンジニアの皆さん、こんにちは。現場で叩き上げられたネットワークの知見を共有するこの連載、今回はインフラ運用の現場で「お守り」のように使われながら、意外と中身まで突き詰められていない ICMP Type 11、すなわち「Time Exceeded（時間超過）」について深掘りします。
「tracerouteがなぜ経路を特定できるのか？」という問いに対し、「TTLを減らしているから」と即答できる人は多いでしょう。しかし、その背後でルーターがどのような判断を下し、なぜそのパケットが破棄されるのか。この「パケットの終焉」を理解することは、現代の複雑なクラウドネットワークのトラブルシューティングにおいて、最強の武器になります。
1. Time Exceededが発生する二つの「死因」
ICMP Type 11 が生成されるケースは、RFC 792で定義されている通り、主に二つあります。
- Code 0: Time to Live exceeded in transit
パケットの TTL（Time To Live）が0になった場合。ループ防止のためにルーターがパケットを「殺す」時に発生します。
- Code 1: Fragment reassembly time exceeded
受信したフラグメントが、再構築用のタイマー内に揃わなかった場合。断片化したパケットがネットワークのどこかで迷子になったことを示唆します。
実務上、圧倒的に遭遇するのは Code 0 です。ルーターはパケットを受信し、ルーティングテーブルを引く前にまず TTL をデクリメントします。もし値が0になれば、そのパケットは転送されず、送信元に対して「お前のパケットは目的地にたどり着く前に寿命が尽きたぞ」という通知が返されるのです。
2. tracerouteのメカニズム：パケットを「わざと殺す」技法
traceroute は、この「ルーターがパケットを殺す」という仕様を逆手に取った、非常にエレガントなハックです。
1. TTL=1で送信: 最初のルーターがパケットを受け取り、TTL を0にして破棄。ICMP Type 11 を返送する。送信元はこれで最初のホップのIPを知る。
2. TTL=2で送信: 二つ目のルーターまで届き、そこで破棄される。これで二つ目のホップが判明する。
3. 到達まで繰り返す: これを繰り返し、最後に宛先ホップから ICMP Port Unreachable 等が返ってくれば、経路探索は完了です。
しかし、現代のクラウド環境では、セキュリティグループやファイアウォールが ICMP を黙殺（ドロップ）することも珍しくありません。結果として * * * と表示されるのは、単に「ルーターがICMP応答を返さない設定になっている」だけかもしれません。
3. 実践：PythonでICMPの挙動を追う
標準的なCLIコマンドだけでなく、Pythonの scapy ライブラリを使えば、この挙動を自分でシミュレートできます。以下は、特定の宛先に対して TTL を制御しながらパケットを投げるイメージです。
from scapy.all import IP, ICMP, sr1
def trace_hop(destination, ttl_val):
# IPパケットを作成し、TTLを明示的に指定
packet = IP(dst=destination, ttl=ttl_val) / ICMP()
# パケットを送出し、応答を待機（タイムアウトは2秒）
reply = sr1(packet, timeout=2, verbose=0)
if reply is None:
print(f"TTL={ttl_val}: 応答なし（パケットが破棄されたか、ICMPがブロックされています）")
elif reply.type == 11:
print(f"TTL={ttl_val}: ホップ到達! 応答元: {reply.src}")
else:
print(f"TTL={ttl_val}: 予期せぬ応答: {reply.type}")
# 例: 8.8.8.8に対してTTL=1で投げてみる
trace_hop("8.8.8.8", 1)4. 現場のトラブルシューティングTips：パケットは「どこ」で消えたか
Web APIの疎通確認で curl -v を使ってもレスポンスが返ってこない時、私はまず traceroute（あるいは mtr）を打ちます。
- 途中で止まる場合: 経路上の特定のノードで
Time Exceededが返ってこないなら、そこがブラックホール（パケットドロップ）です。 - 宛先直前まで見える場合: 宛先ホップでパケットが止まるなら、それはネットワークの問題ではなく、ターゲットサーバー上の
iptablesやnftables、あるいはクラウドのセキュリティグループ設定ミスである可能性が高いです。
また、MTU サイズの不一致によるパケットドロップを疑うなら、ping に DF（Don’t Fragment）ビットを立ててサイズを調整しながら撃ってみてください。もし ICMP Type 3 Code 4（Fragmentation Needed）が返ってこない場合は、途中のファイアウォールが ICMP をフィルタリングしている可能性を疑いましょう。
まとめ：ネットワークは嘘をつかない
ICMP Type 11 は、パケットがネットワークという荒波を渡る中で力尽きた時に、その身を呈して「現在地」を教えてくれる貴重なシグナルです。教科書的な知識を現場のパケットキャプチャと結びつけられるようになると、トラブルシューティングのスピードは劇的に上がります。
「繋がらない」と嘆く前に、パケットがどこで、なぜ「死」を選んだのか。その理由を ICMP のメッセージから紐解いてみてください。ネットワークのエンジニアリングとは、結局のところ、パケットの最期を看取る仕事なのですから。
コメント