ARPキャッシュの「迷信」を破壊せよ：L2の足元をすくわれないための深層トポロジー考察
ネットワークのトラブルシューティングにおいて、最も厄介なのは「なぜか通信が繋がらない」「パケットがブラックホールに消える」という不可解な現象です。その多くが、実は上位レイヤーのアプリケーションコードではなく、OSの足元である ARP（Address Resolution Protocol）キャッシュの挙動に起因していることを、皆さんはご存知でしょうか。
今日は、Web APIのレスポンスタイムアウトや、クラスター構成での切り替え失敗に頭を抱えるエンジニア諸君のために、OSがARPテーブルをどう解釈し、どう裏切るのかという「泥臭い現実」を深掘りします。
—
ARPテーブルは「地図」である：静的 vs 動的
OSが保持するARPテーブルは、いわば「IPアドレスという名前を、MACアドレスという物理的な住所に変換する地図」です。しかし、この地図は常に書き換わります。
なぜ、ARPテーブルは「更新」されるのか？
多くのエンジニアは arp -a コマンドで表示される一覧を「確定した事実」だと誤解しがちです。しかし、実際には以下の条件でエントリは生き死にを繰り返しています。
1. 通信発生時のリフレッシュ: 該当IPへの通信が発生すると、エントリの生存期間（reachable状態）が延長される。
2. Gratuitous ARP (GARP) の受信: 自身のIPとMACをブロードキャストするGARPを受信すると、OSはテーブルを強制的に上書きします。これは冗長化構成（KeepalivedやVRRP）において、フェイルオーバーを即座に認識させるための生命線です。
3. タイムアウトによる削除: gc_stale_time（後述）を超過すると、エントリは「怪しい（Stale）」状態へ遷移し、最終的に削除されます。
—
現場で役立つカーネルパラメータの最適化
LinuxサーバーのARP挙動を制御しているのは、/proc/sys/net/ipv4/neigh/ 配下のファイル群です。大規模なマイクロサービス環境では、デフォルト設定が仇となることがあります。
特に確認すべきは、以下のパラメータです。
# 特定のインターフェース(eth0)の挙動を確認する例
# 1. gc_stale_time: ARPキャッシュが「古くなった」とみなされるまでの秒数
cat /proc/sys/net/ipv4/neigh/eth0/gc_stale_time
# 2. base_reachable_time_ms: 到達可能とみなされる期間のベース値（ミリ秒）
cat /proc/sys/net/ipv4/neigh/eth0/base_reachable_time_ms【実務Tips】フェイルオーバーが遅いと感じたら
GARPを受け取っても切り替わりが遅い場合、locktime が悪さをしている可能性があります。locktime は、同じIPに対して異なるMACアドレスが短期間で通知された際に、その更新を拒否する期間です。高可用性構成を組む際は、この値を小さく（あるいは0に）設定しておくのが定石です。
# ロック時間を0にして、GARPを即座に受け入れるように設定
sysctl -w net.ipv4.neigh.eth0.locktime=0—
通信フローを可視化する：PythonによるARP追跡
「ARPテーブルがどう変化したか」をリアルタイムで追うのは難しいですが、Pythonの scapy を使えば、ネットワークを流れるARPパケットを監視し、OSの挙動をシミュレートできます。
from scapy.all import sniff, ARP
# ARPパケットのみをキャプチャし、誰が誰のMACを知りたがっているか監視する
def arp_monitor_callback(pkt):
if pkt[ARP].op == 1: # WHO-HAS (要求)
print(f"要求: {pkt[ARP].psrc} が {pkt[ARP].pdst} のMACを探しています")
elif pkt[ARP].op == 2: # IS-AT (応答/GARP)
print(f"応答/GARP: {pkt[ARP].psrc} は {pkt[ARP].hwsrc} です")
# 特定のインターフェースでキャプチャ開始
sniff(iface="eth0", filter="arp", prn=arp_monitor_callback, store=0)これを実行しながら curl で外部リクエストを送ると、対象サーバーへのARP要求と応答が次々と流れてくる様子が観察できます。この「パケットの呼吸」を感じることが、トラブルシューティングの第一歩です。
—
Web APIエンジニアへの警鐘
API設計において、Keep-Alive を活用するのは当然ですが、ロードバランサー（LB）配下のバックエンドが頻繁に切り替わる構成では、「コネクションプーリング」と「ARPキャッシュの生存期間」のミスマッチが致命的な503エラーを引き起こします。
1. クライアント側のキャッシュ: curl や Fetch API が接続先のIPを長く保持しすぎると、切り替わった後のLBのMACアドレスを見失います。
2. OSの解決: アプリケーション層でIPが固定されていても、OSのARPキャッシュが古ければ、ARP要求の再送（retrans_time）により、通信に数秒のラグが発生します。
結論として：
高トラフィックなAPI環境であれば、OSレベルでのタイムアウトを短縮するよりも、LB側のヘルスチェックとGARPの発行タイミングを精査し、OSが「疑心暗鬼」にならないネットワーク設計を心がけるべきです。
—
最後に：ネットワークは「生き物」である
教科書に書かれたRFCの仕様は、あくまで「理想」です。実際のネットワークでは、NICのバッファオーバーフロー、スイッチのMACアドレステーブルのフラッシュ、そしてOSのカーネルパラメータの微妙な設定の差が、複雑に絡み合っています。
arp -n で表示される行の裏側に、どのようなパケットが流れているのか。その想像力を働かせることが、障害を未然に防ぐ唯一の道です。皆さんの環境でも、ぜひ一度 sysctl の設定を覗き、パケットをキャプチャしてみてください。そこに、トラブル解決のヒントが隠れているはずです。
それでは、また次回の深層エンジニアリングでお会いしましょう。
コメント