「なぜ、あいつは黙っていても喋るのか？」Gratuitous ARPが支えるインフラの現場
ネットワークエンジニアとして現場に立つと、時に「静寂」が最大の敵になることがある。サーバーが死んだ、ロードバランサーが切り替わった……そんな有事の際、ネットワーク機器やエンドホストがその変化を即座に感知できなければ、通信はブラックホールに吸い込まれてしまう。
そこで登場するのが、Gratuitous ARP（無償ARP）だ。教科書的には「自身のIPを通知するARPパケット」の一言で済まされるが、実務においてこいつは、高可用性（HA）を担保するための「命綱」に他ならない。今日は、この泥臭いけれど極めて重要なプロトコルの正体を解き明かしていこう。
—
Gratuitous ARPの正体：ただの「俺様アピール」ではない
Gratuitous ARP（以下、GARP）は、通常のARPリクエストとは少し毛色が違う。
- Sender IP / Target IP: どちらも「自分自身のIPアドレス」がセットされる。
- 宛先MACアドレス:
FF:FF:FF:FF:FF:FF（ブロードキャスト）。
つまり、「誰か僕のMACアドレスを知りませんか？」という問いかけではなく、「僕のIPはこれだけど、MACアドレスはこれだよ。みんな、よろしく！」という、ネットワーク全体への一方的な宣言だ。
これが実務でどう役立つか？主に2つのケースがある。
1. IPアドレスの重複検知: OSが起動時、あるいはIPを割り当てた瞬間にGARPを投げる。もし応答が返ってきたら、「誰か同じIPを使ってる奴がいる！」と判断し、NICをシャットダウンしたりログを吐いたりするわけだ。
2. HA構成のフェイルオーバー: ロードバランサー（LVSやKeepalivedなど）がマスターに昇格した際、スイッチや周囲のホストのARPテーブルを強制的に書き換えさせる。これがないと、切り替わった瞬間に通信が旧ノードのMACへ流れ続け、数分間のダウンタイムが発生する。
—
現場で役立つデバッグ手順とCLI活用術
「切り替えがうまくいかない」というトラブルシューティングで、真っ先にやるべきはパケットキャプチャだ。現場のエンジニアは、tcpdump を魔法の杖のように扱う。
# 特定のインターフェースでARPパケットを監視する
# arpプロトコルを指定し、無駄なログを除外する
tcpdump -i eth0 arp -nもしフェイルオーバー時にGARPが流れているか確認したいなら、以下のようにオプションを組み合わせるのが定石だ。
# 自身のIP(例: 192.168.1.10)に関連するARPだけを追う
tcpdump -i eth0 arp and host 192.168.1.10 -eここで重要なのは、Sender MAC と Target MAC が期待通りかを確認すること。もしここが古いノードのMACを指していれば、スタックしているのはアプリケーションではなく、ネットワークの切り替わりそのものだ。
—
Pythonで見る「GARPを投げる」挙動のシミュレーション
インフラ運用だけでなく、Web API設計やコンテナネットワークを深く理解するために、Pythonの scapy を使ってGARPを自作してみるのも面白い。これは、テスト環境でフェイルオーバーの挙動を検証する際にも使える。
from scapy.all import ARP, Ether, sendp
# 自身のIPとMACを定義
my_ip = "192.168.1.100"
my_mac = "00:11:22:33:44:55"
interface = "eth0"
# Gratuitous ARPパケットの作成
# op=2 は ARP Reply を示す
pkt = Ether(dst="ff:ff:ff:ff:ff:ff") / ARP(
op=2,
psrc=my_ip, # 送信元IP
pdst=my_ip, # 宛先IPも自分自身にするのがGARPの流儀
hwsrc=my_mac, # 自身のMAC
hwdst=my_mac
)
# ネットワークへ向かって叫ぶ
sendp(pkt, iface=interface, count=3)このコードを叩くと、スイッチのMACアドレステーブルが強制的に更新される。実務のロードバランサー構築時、keepalived の設定で garp_master_delay などを調整する際、この挙動を理解しているか否かでトラブル対応の速度が段違いになる。
—
インフラエンジニアへのアドバイス：設定ファイルの「おまじない」に頼るな
最近はクラウド環境（AWSやGCPなど）でインフラを構築することが増えたが、VPC内部ではARPは透過的に処理されることが多く、GARPを意識する機会は減っているかもしれない。
しかし、オンプレミスの物理サーバーや、L2ネットワークを跨ぐ複雑なマルチクラウド環境では、未だにGARPは「最後の砦」だ。Keepalived の設定ファイルで以下のように書くとき、その裏で何が起きているかを想像してほしい。
# /etc/keepalived/keepalived.conf の抜粋
vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 51
# フェイルオーバー時に投げるGARPの回数と間隔
garp_master_repeat 5
garp_master_delay 1
}「なんとなく設定している」のと、「ARPテーブルの更新を確実にスイッチへ伝えたいから、あえて重複して投げさせている」と理解しているのでは、障害時の落ち着きが全く違う。
ネットワークの世界に魔法はない。あるのは、パケットという名の小さなメッセージが、誰の目にも触れず、しかし確実に世界を動かしているという事実だけだ。次にネットワークが繋がらないときは、ログを見る前に、パケットが「誰に、何を」喋っているのか、その耳を澄ませてみてほしい。現場からは以上だ。
コメント