【実務・中級編】 ICMPパケットタイプ0(Echo Reply)とタイプ8(Echo Request)の識別仕様 – トラブルシューティング＆ネットワーク運用監視実践ガイド

なぜ「pingが通らない」と焦るのか？ICMPの深淵とパケットの呼吸を理解する

夜中の3時、アラートメールの着信音で叩き起こされる。画面に映るのは「Node Unreachable」の赤い文字。君がまず叩くコマンドはなんだ？そう、pingだ。

だが、少し待ってほしい。君は単に「パケットが返ってきたからOK」と確認しているだけではないか？もし、君がネットワークエンジニアやインフラ担当として一段上のステージを目指すなら、pingの裏側で何が起きているのか、ICMPパケットがどういう「会話」をしているのかを理解しなければならない。

今日は、疎通確認の基本にして極意である ICMP Echo Request（Type 8）と Echo Reply（Type 0）について、現場の視点から掘り下げていこう。

1. パケットの顔つき：TypeとCodeの真実

ICMP（Internet Control Message Protocol）は、IP層の「補佐役」だ。決して主役ではないが、彼らがいなければインターネットは暗闇になる。

pingでやり取りされるのは、以下の2つのパケットだ。

Type 8 (Echo Request): 「そこにいるか？」と問いかけるパケット。
Type 0 (Echo Reply): 「ここにいるぞ！」と返すパケット。

ここで重要なのが、Codeフィールドだ。エコー要求の場合、Codeは必ず 0 である必要がある。もし君がファイアウォールを設計していて、「とりあえずICMPを通せ」と設定しているなら注意が必要だ。Type 8以外にも、Type 3（Destination Unreachable）のような重要な制御信号がある。これらを一括で遮断すると、Path MTU Discoveryが機能せず、TCPのハンドシェイクすら完遂できないという「謎の通信断」を引き起こすことになる。

2. チェックサム：ネットワークの「誠実さ」を測る

パケットが壊れていないことを証明する仕組み、それが Checksum だ。

送信側は、ICMPヘッダとペイロード（データ部分）を合わせたビット列から計算値を導き出し、ヘッダの Checksum フィールドに書き込む。受信側は、同じアルゴリズムで再度計算し、値が一致しなければパケットを静かに破棄する。

現場で「なぜか一部のパケットだけロスする」という事象に遭遇したことはないか？その場合、経路上のルーターやスイッチのNICでパケット化けが発生している疑いがある。tcpdump でキャプチャし、怪しいパケットがあれば Checksum を確認してみる。これが、ベテランが障害の切り分けで見せる「地味だが強力な一手」だ。

3. 実務で役立つデバッグ：CLIからコードまで

理論ばかりでは腹は膨れない。エンジニアとして明日から使えるTipsを共有しよう。

CLIでの調査：pingだけが全てじゃない

pingが通らないとき、君は次に何をする？traceroute（あるいは mtr）だ。

# -n: DNS逆引きを無効化（DNS遅延で迷子にならないため）
# -I: ICMP Echoを使用（デフォルトのUDPと使い分ける）
sudo traceroute -n -I 8.8.8.8

もし traceroute もダメなら、次は scapy（Python）を使って、特定のパケットだけを投げてみるのが定石だ。

Pythonによる「生」のパケット送信

API開発をしていると、特定のポートやプロトコルだけが通らないケースに遭遇する。そんな時、最小構成で疎通確認を書けるスキルは武器になる。

from scapy.all import IP, ICMP, sr1

# 宛先IPを指定してICMP Echo Requestを1つだけ送信
def check_connectivity(target_ip):
    # IPヘッダとICMPヘッダを構築
    packet = IP(dst=target_ip) / ICMP(type=8, code=0)
    
    # タイムアウト1秒で応答を待つ
    reply = sr1(packet, timeout=1, verbose=False)
    
    if reply:
        print(f"成功: {target_ip} から応答あり (Type: {reply.type})")
    else:
        print(f"失敗: {target_ip} は沈黙しています")

# 実行例
check_connectivity("192.168.1.1")

4. Web API設計における注意点

最後に、インフラからアプリ層へ少し視点を移そう。クラウド環境（AWSやGCP）において、pingの応答速度とWeb APIのレイテンシは別物だ。

ICMPは優先度が低い: ルーターは輻輳時、ICMPパケットを真っ先に捨てる設定になっていることが多い。pingが遅いからといって、アプリケーションのパフォーマンスが悪いとは限らない。
ヘルスチェックの罠: ロードバランサーのヘルスチェックに ICMP を使うのは推奨しない。アプリケーションが「プロセスは生きているが、データベースとの接続が切れている」ような状態でも、ICMPは Reply を返してしまうからだ。必ず HTTP/TCP レベルのヘルスチェックを併用すること。

終わりに：パケットが見えるエンジニアになれ

ネットワークは、魔法のように動いているのではない。ルールに基づいて、一秒間に何億ものパケットが、それぞれの役割（TypeとCode）を背負って走り回っている。

トラブルシューティングの極意は、「目に見えないパケットの挙動を、頭の中で可視化すること」に尽きる。コマンドを叩くたびに、それがどういうパケットとなってNICから飛び出しているのかを想像してほしい。

もし今度、ネットワークトラブルで頭を抱える後輩がいたら、まずは教科書を閉じて tcpdump を開かせろ。そして一緒にパケットを眺めてやるんだ。それが、真のシニアエンジニアの流儀だ。

健闘を祈る。また次の現場で会おう。