「pingが通らない？落ちたか？」その思い込みが、君のデバッグを迷宮入りさせる
現場で若手エンジニアから一番よく聞く悲鳴は、「ルータの疎通確認をしたらpingがロストした。バックボーンの障害に違いない！」というものだ。しかし、ネットワークの現場で障害の一次切り分けを行う際、最も陥りやすい罠がある。それが今回解説する「ICMPレートリミット（Rate Limiting）」だ。
教科書には「pingが返ってこなければ通信断」と書いてあるかもしれないが、現実のネットワーク機器はそんなに単純じゃない。セキュリティ、あるいはCPU保護のために、ICMPは常に「後回し」にされる運命にある。この挙動を知らないと、深夜3時に「障害対応中」という幻を追いかけることになるぞ。
—
なぜICMPは「無視」されるのか：制御プレーンの保護
ネットワーク機器には、パケットを高速に転送する「データプレーン」と、機器自身を制御する「制御プレーン（CPU）」がある。我々が打つ ping や traceroute のパケットは、機器のCPUが処理する「制御プレーン宛て」の通信だ。
もし、悪意あるユーザーや、バグった監視スクリプトが毎秒数万発のICMPを送りつけたらどうなるか？ CPUはそれらへの応答に追われ、本来のルーティング処理やBGPのキープアライブが疎かになる。その結果、ネットワーク全体がダウンする。これを防ぐために、多くの機器には「ICMPの処理数に上限（レートリミット）を設ける」という防衛策が組み込まれているんだ。
tracerouteが途中で星印（*）になる理由
traceroute は TTL（Time To Live）を意図的に減らしてタイムアウトを誘発し、通り道のルータから ICMP Time Exceeded を受け取る仕組みだ。しかし、この「エラーを通知する」という行為自体が、ルータにとってはCPU負荷の高い低優先度タスクとなる。そのため、高負荷なコアスイッチなどは、一定数以上の traceroute パケットを「無言で捨てる」ことがよくある。星印が並んだからといって、必ずしもそこでパケットが物理的に切れているわけじゃない。
—
現場で使える「ICMP頼み」からの脱却手法
「pingが通らないから何も分からない」というのは卒業しよう。我々シニアエンジニアは、ICMPが制限される環境でも通信を確認するための代替手段を常に持っている。
1. TCPベースの疎通確認（TCP SYN Ping）
ICMPがダメならTCPで叩くのが鉄則だ。curl や nmap を使えば、特定のポート（例えば 443 や 80）に対してSYNパケットを送り、SYN/ACKが返ってくるかを見ることで、L4までの疎通を確実に担保できる。
# curlを使用して特定のポートへの到達性を確認する
# -Iでヘッダーのみ取得、--connect-timeoutで待ち時間を指定
curl -I -v --connect-timeout 5 https://192.168.1.1:4432. Pythonによる柔軟なプローブ
自動化監視を組むなら、ICMPに依存しすぎない設計が必要だ。以下は、タイムアウトを細かく制御しつつTCPコネクションを試行するPythonコードの雛形だ。
import socket
def check_port(host, port, timeout=3):
""" 指定したホスト・ポートにTCP接続を試みる """
try:
with socket.create_connection((host, port), timeout=timeout) as sock:
print(f"成功: {host}:{port} は到達可能です")
return True
except (socket.timeout, ConnectionRefusedError, OSError):
print(f"失敗: {host}:{port} に到達できませんでした")
return False
# 監視先リスト
check_port("10.0.0.5", 443)—
対策：運用の現場でどう設定すべきか
もし君が管理するルータ側でレートリミットをかけたい場合、Cisco IOS 等では control-plane ポリシーを使って制御するのが一般的だ。やみくもに遮断するのではなく、正当な監視パケットは通し、異常なパケットのみを落とすのがプロの仕事だ。
! Cisco IOSでの制御プレーン保護設定例
policy-map PROTECT-CONTROL-PLANE
class ICMP-TRAFFIC
! 毎秒50パケットを超えたらレート制限をかける
police 50000 conform-action transmit exceed-action drop
!
control-plane
service-policy input PROTECT-CONTROL-PLANE—
シニアからの提言：データは「多角的」に見ろ
最後に一つだけ伝えておきたい。「pingの応答率が100%ではない」ことと「通信障害である」ことは、イコールではない。
現場では、以下のような事象が頻発する。
- 経路上のどこかでICMPだけが優先度を下げられている（Rate Limit）
- MTUサイズが適切ではなく、特定の大きなパケットだけが破棄されている（Path MTU Discovery問題）
- 特定のVLANでのみQoSポリシーが適用されている
トラブルシューティングの際は、ping だけに頼らず、mtr（My Traceroute）で経路上の損失傾向を可視化したり、tcpdump を使って実際にパケットがインターフェースを通過しているかを「生の目」で確認する癖をつけてくれ。
ネットワークは、パケットという「目に見えない信号」の集合体だ。画面上の文字だけで判断せず、その背後でパケットがどのように処理されているかを想像する。その泥臭い想像力こそが、君を一人前のエンジニアに引き上げてくれるはずだ。
さて、現場に戻ろうか。ログが君を待っているぞ。
コメント