Pingが「嘘」をつくとき：NOCの現場で学ぶ、パケットロスの真実とカーネルの深淵
ネットワークエンジニアにとって、pingは呼吸のようなものだ。しかし、障害対応の現場で数万ものパケットを追いかけてきた人間から言わせれば、pingほど「誤解を招く」ツールもない。
「pingでロスが出ているから、回線が不安定だ」
現場で若手がこう報告してきたら、私は必ずこう返す。「そのping、どこで捨てられているか本当に分かっているのか？」と。ICMP Echo Requestは、ネットワークスタックの末端に位置する「お荷物」だ。CPUが忙しければ後回しにされ、QoSが厳しければ真っ先に切り捨てられる。今回は、パケットロスという現象の裏側にある、カーネルの挙動と通信の物理的制約について、少し深く潜ってみよう。
—
1. ICMPレートリミッティング：CPUが発する「黙れ」のサイン
ルーターやスイッチのCPUが高負荷に陥ったとき、最も優先順位が低いのは、ルーティング更新でもトラフィック転送でもなく、管理用インターフェースへのICMP応答だ。
多くの商用ルーターには、Control Plane Policing (CoPP) という仕組みがある。これは制御プレーン（CPU）をDDoSから守るための防波堤だが、これが過剰に働くと、pingに対して意図的なパケットロスを引き起こす。
なぜ「ロス」するのか？
ルーターは、制御プレーンに流れてくるICMPパケットを、ハードウェア（ASIC/NPU）でスイッチングする通常のデータプレーンとは別の扱いにする。この「別扱い」の処理が一定の閾値を超えると、カーネルはパケットを黙ってドロップする。
もしあなたがpingでロスを観測したら、まず疑うべきは回線の品質ではなく、「対象機器の制御プレーンが悲鳴を上げていないか」だ。show process cpuを叩き、割り込み処理（Interrupt）が異常に高まっていないか確認してほしい。
—
2. QoSポリシーと「身分差別」の現実
現代のデータセンターでは、VoIPや高優先度のトランザクションを保護するために、厳格なQoSポリシーが適用されている。ここで重要なのは、ICMPがしばしば「Best Effort」カテゴリに放り込まれるという点だ。
例えば、帯域が輻輳した際、ルーターのキューイングアルゴリズム（CBWFQやLLQなど）は、優先度の低いパケットを優先的にドロップする。このとき、pingのパケットはまさに「捨て駒」になる。
トラブルシューティングの勘所
もしpingでロスが発生しつつも、実通信（TCP/UDP）のアプリケーションパフォーマンスに大きな変化がない場合、それは「QoSによる正常なドロップ」である可能性が高い。この場合、pingのロスはネットワークの健全性を表す指標としては不完全だ。代わりに、mtrやhping3を用いて、特定のポートに対するレイテンシやロスを計測する方が、実際のアプリケーションに近い挙動を可視化できる。
—
3. パフォーマンスの深淵：TCPチューニングとRTT削減
インフラアーキテクトであれば、pingの結果に一喜一憂する前に、カーネルのバッファとトランスポート層の最適化に目を向けるべきだ。特に広域ネットワーク（WAN）を跨ぐ場合、RTT（Round Trip Time）は物理的限界に支配されるが、カーネルレベルのチューニングでスループットは劇的に変わる。
Linuxカーネルのバッファチューニング
TCPウィンドウサイズを適切に設定しないと、帯域幅遅延積（BDP）を埋めきれず、広帯域でも低速な通信になってしまう。/etc/sysctl.confに以下の設定を反映させるのが定石だ。
# TCP最大送受信バッファを拡張（高速回線でのスループット向上）
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# TCPウィンドウ拡大オプションを有効化
net.ipv4.tcp_window_scaling = 1
# BBR輻輳制御アルゴリズムの有効化（パケットロスに強い通信を目指す）
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr特にGoogleが開発したBBRは、パケットロスを「ネットワークの輻輳」ではなく「単なるロス」として扱い、スループットを維持する設計になっている。これを導入するだけで、微細なロス環境下でのパフォーマンスは別物になる。
—
4. セキュリティとヘッダー圧縮のトレードオフ
最後に、TLSハンドシェイクの最適化について触れておく。最近ではTLS 1.3の普及により、1-RTTでのハンドシェイクが可能になった。しかし、パケットロスが頻発する環境では、この1回の手続きさえも命取りになる。
脆弱性対策としてTLS 1.2以下を廃止するのは当然だが、セキュリティを強固にすればするほど、ハンドシェイクのパケットサイズは肥大化する。ここでROHC（Robust Header Compression）のような技術を用いてヘッダーを圧縮し、パケットサイズをMTU内に収める工夫が必要になる場合もある。
—
現場からの提言：Pingは「嘘」をつく、だが「ヒント」はくれる
結論として、pingの結果を額面通りに受け取ってはいけない。pingはあくまで「その瞬間の、その優先度における、その経路の断片」に過ぎない。
- ネットワークが遅いと感じたら、まず
ss -tiで再送パケット数（retrans）を確認せよ。 - カーネルの統計情報 (
/proc/net/snmpなど) を読み解き、どこでドロップが起きているか（InDiscards, OutDiscards）を特定せよ。 - 最後に、QoSポリシーとCPU負荷という「見えない壁」を疑え。
百戦錬磨のエンジニアというのは、ツールが出した数値を信じるのではない。その数値が「なぜ」出たのかという背景にある、パケットが通過するハードウェアの呼吸を感じ取れる者たちのことだ。
さあ、今日もコマンドラインを開こう。パケットの旅は、まだ始まったばかりだ。
コメント