はじめに
機器交換や冗長構成の切り替えの後に、一部の端末だけ通信が戻らないことがあります。このとき話題に上がりやすいのが Gratuitous ARP（GARP）です。ただし、GARP が何を更新するかは、交換や切り替えの方式によって異なります。IP アドレスに対応する MAC アドレスが変わる場合もあれば、MAC アドレスは変わらず、スイッチがその MAC アドレスへ転送するポートだけが変わる場合もあります。
本記事では、GARP の役割と ARP Probe・ARP Announcement との違いを整理したうえで、機器交換と仮想 MAC を引き継ぐ冗長切り替えを比較し、どの機器のどのテーブルを確認するかを解説します。
- GARP（Gratuitous ARP）の役割と、通常の ARP・ARP Probe との違い
- 機器交換と冗長切り替えで、更新が必要になる対応関係の違い
- 端末の ARP キャッシュとスイッチの MAC アドレステーブルの確認の分け方
- Wireshark で GARP と VRRP Advertisement を観測する際の注意点
- GARP が観測できても通信が戻らない場合の考え方
結論として、GARP は ARP を使って自分の IP アドレスと MAC アドレスの対応を周囲へ通知する仕組みです。機器交換では、通信相手が持つ IP → MAC の対応の更新が中心になります。仮想 IP と仮想 MAC を引き継ぐ冗長切り替えでは、通信相手の IP → MAC は変わらない場合があり、確認の中心はスイッチが仮想 MAC を学習するポートです。どちらの場合も、GARP の送信、受信機器への到達、テーブルへの反映、業務通信の復旧は分けて判断します。
GARP とは｜通常の ARP との違い
GARP は独立したプロトコルではなく、ARP のパケットを使った通知です。通常の ARP が「この IP アドレスの MAC アドレスは何か」という問い合わせと応答で成り立つのに対し、GARP は先行する問い合わせを受けていない状態で、自分の IP アドレスと MAC アドレスの対応を同じリンクへ知らせる用途で使われます。ARP の基本動作はハブ記事「ARP とは」で解説しています。
Request 形式と Reply 形式がある
GARP には、ARP Request の形式で送るものと、ARP Reply の形式で送るものがあります。Mobile IPv4 の仕様である RFC 5944 は、GARP をどちらの形式でも送れるものとして定義しています。
参考: RFC 5944 — IP Mobility Support for IPv4, Revised（Section 4.6）
“A gratuitous ARP MAY use either an ARP Request or an ARP Reply packet.”
（GARP は ARP Request と ARP Reply のどちらのパケットを使ってもよい）
https://www.rfc-editor.org/rfc/rfc5944
同 RFC では、送信元 IP とターゲット IP の両方に更新させたい IP アドレスを入れ、送信元 MAC に新しい MAC アドレスを入れる形が示されています。一方、RFC 5227 は、多くの OS が Request 形式を使っていることに触れています。キャプチャで GARP を探す場合は、Opcode だけで判断せず、送信元 IP とターゲット IP の組み合わせを確認します。
ARP Probe・ARP Announcement との違い
RFC 5227 は、IPv4 アドレスの重複を検出する目的で ARP Probe と ARP Announcement を定義しています。ARP Announcement は GARP と同じ形の通知ですが、ARP Probe は目的が異なります。
参考: RFC 5227 — IPv4 Address Conflict Detection
“both the sender and target IP address fields contain the IP address being announced”
（送信元 IP とターゲット IP の両方に、通知する IP アドレスが入る）
https://www.rfc-editor.org/rfc/rfc5227
| 種類 | 目的 | Opcode | 送信元 IP | ターゲット IP |
|---|---|---|---|---|
| 通常の ARP Request | 相手の MAC アドレスを問い合わせる | 1（Request） | 自分の IP | 問い合わせ先の IP |
| ARP Probe | 使用予定の IP の重複を調べる | 1（Request） | 0.0.0.0 | 使用予定の IP |
| ARP Announcement | 使用を開始する IP を通知する | 1（Request） | 通知する IP | 通知する IP（送信元 IP と同じ） |
| Reply 形式の GARP | IP と MAC の対応を通知する | 2（Reply） | 通知する IP | 通知する IP（RFC 5944 の形） |
ARP Probe は送信元 IP が 0.0.0.0 のため、周囲の ARP キャッシュに対応関係を登録させる目的では使われません。ARP Probe を GARP や Announcement と同一視しないことをおすすめします。また、製品が「GARP」と呼ぶ機能の形式・送信契機・回数は、RFC 5227 の Probe / Announcement の手順と一致するとは限りません。製品ごとに資料で確認します。
GARP は通知であり、応答を求めるものではありません。GARP に対する Reply が見えないことは、通知が失敗したことの根拠になりません。
受信した機器とスイッチが使う情報は異なる
GARP を受信した端末やルーターは、ARP 本文の送信元 IP と送信元 MAC を ARP キャッシュの判断に使います。RFC 826 の受信処理では、送信元 IP のエントリがすでにテーブルにあれば、その MAC アドレスを受信した値で置き換えます。
参考: RFC 826 — An Ethernet Address Resolution Protocol
“the new hardware address supersedes the old one”
（新しいハードウェアアドレスが古いものを置き換える）
https://www.rfc-editor.org/rfc/rfc826
同じ処理手順では、エントリを新しく登録するのは、自分がターゲット IP である場合に限られています。そのため、既存エントリの更新と、未登録のエントリの新規作成は同じ動作として扱えません。実際の扱いは OS や製品の実装と設定にも依存します。
一方、L2 スイッチの MAC アドレステーブルは、受信したフレームの Ethernet ヘッダーにある送信元 MAC アドレスと受信ポートから学習されます。スイッチが ARP 本文の IP や MAC を読んで通常の MAC 学習を行うわけではありません。GARP も、フレームの送信元 MAC アドレスが学習の対象になる点では、他のフレームと同じです。
機器交換と冗長切り替えで変わる対応関係
ここでは、ケース A（機器交換）とケース B（冗長切り替え）を、別々の構成として説明します。どちらも説明用のシナリオであり、実機検証の結果ではありません。
ケース A: IP アドレスを引き継いだ機器交換
本記事群の構成例で、SW1 の VLAN 10 に接続された PC-B（192.168.10.20）を新しい端末へ交換し、IP アドレスを引き継いだ場合です。旧 PC-B の MAC アドレスは 00-00-5e-00-53-14、新 PC-B の MAC アドレスは 00-00-5e-00-53-24 とします。同じ VLAN には PC-A（192.168.10.10）と R1 LAN1 側（192.168.10.1）が接続されています。
説明のため、新 PC-B が IP アドレスの設定時に GARP を送信する前提とします。GARP を送るかどうか、送る契機や形式は OS や機器によって異なり、交換すれば自動的に送られるわけではありません。
- PC-A と R1 が保持する 192.168.10.20 → 00-00-5e-00-53-14 の対応は古くなり、00-00-5e-00-53-24 への更新が必要になります。
- GARP を受信した PC-A と R1 は、既存のエントリを新しい MAC アドレスで更新する可能性があります。
- SW1 は、新 PC-B から受信したフレームの送信元 MAC アドレス 00-00-5e-00-53-24 を、接続されたポートで学習します。
ケース B: 仮想 IP と仮想 MAC を引き継ぐ冗長切り替え
ケース B は、基本構成に R2 を追加し、R1 と R2 で VRRPv3（RFC 9568）を構成した別の構成です。ハブ記事などでは 192.168.10.1 を R1 のインターフェース IP としていましたが、ケース B では R1 と R2 がそれぞれ実 IP を持ち、192.168.10.1 を両者で共有する仮想 IP として使います。PC-A のデフォルトゲートウェイは 192.168.10.1 のままです。
| 項目 | R1 | R2 |
|---|---|---|
| LAN1 側の実 IP | 192.168.10.2/24 | 192.168.10.3/24 |
| インターフェースの MAC | 00-00-5e-00-53-01 | 00-00-5e-00-53-03 |
| 仮想 IP（VRID 1） | 192.168.10.1 | 192.168.10.1 |
| 仮想 MAC | 00-00-5e-00-01-01 | 00-00-5e-00-01-01 |
| SW1 の接続ポート | Gi1/0/1 | Gi1/0/2 |
| 切り替え前の状態 | Active | Backup |
RFC 9568 では、IPv4 の仮想ルーター MAC アドレスは 00-00-5E-00-01-{VRID} の形式で、VRID 1 なら 00-00-5e-00-01-01 になります。Active ルーターは仮想 IP への ARP Request に仮想 MAC で応答するため、PC-A の ARP キャッシュには 192.168.10.1 → 00-00-5e-00-01-01 が登録されます。
R1 が停止して R2 が Active になると、RFC 9568 の手順では R2 は VRRP Advertisement を送信し、仮想 IP ごとに仮想 MAC を含む GARP をブロードキャストします。このとき PC-A から見た 192.168.10.1 → 00-00-5e-00-01-01 の対応は切り替え前後で変わらず、変わるのは SW1 が仮想 MAC を学習するポート（Gi1/0/1 から Gi1/0/2）です。
SW1 の学習を更新するのは、仮想 MAC を送信元とするフレームです。RFC 9568 は、VRRP Advertisement の送信元 MAC アドレスを仮想 MAC にすると定めています。
参考: RFC 9568 — VRRP Version 3 for IPv4 and IPv6
“transmitted with the Virtual Router MAC address as the source MAC address”
（仮想ルーター MAC アドレスを送信元 MAC アドレスとして送信される）
https://www.rfc-editor.org/rfc/rfc9568
つまり、VRRP では GARP だけでなく Advertisement もスイッチの学習に関係します。なお、RFC 9568 は Active ルーターが ARP Request に応答する Reply について、Ethernet フレームの送信元は物理 MAC アドレスであると説明しています。ARP 本文に含まれる MAC アドレスと、フレームの送信元 MAC アドレスは一致するとは限らないため、GARP のフレームの送信元 MAC アドレスは、キャプチャで実際の値を確認します。
比較表と図で見る更新対象
| 項目 | ケース A: 機器交換 | ケース B: 仮想 MAC を引き継ぐ切り替え |
|---|---|---|
| IP | 192.168.10.20（変わらない） | 仮想 IP 192.168.10.1（変わらない） |
| MAC | 00-00-5e-00-53-14 から 00-00-5e-00-53-24 へ変わる | 仮想 MAC 00-00-5e-00-01-01 のまま |
| 端末・ルーターの ARP キャッシュ | PC-A・R1 で 192.168.10.20 の MAC の更新が必要 | PC-A の 192.168.10.1 の MAC は変わらない |
| スイッチの MAC アドレステーブル | 新しい MAC を PC-B のポートで学習 | 同じ仮想 MAC の学習ポートが Gi1/0/1 から Gi1/0/2 へ移る |
| 確認する場所 | PC-A・R1 の ARP キャッシュ、SW1 の新しい MAC の学習ポート | SW1 の仮想 MAC の学習ポート、R2 が Active であること |
ケース B で PC-A の ARP キャッシュが変わらないのは正常な結果です。切り替えの成功を「MAC アドレスが変わったこと」で判断しないことをおすすめします。
仮想 MAC を使わない方式では IP → MAC が変わる
冗長切り替えでも、仮想 MAC を使わない方式では、通信相手から見た IP → MAC が変わります。たとえば FortiOS の VRRP では、仮想 MAC の機能は既定で無効です。
参考: FortiOS 7.6.4 Administration Guide — VRRP virtual MACs
“the VRRP domain uses the MAC address of the primary router”
（VRRP ドメインはプライマリルーターの MAC アドレスを使用する）
https://docs.fortinet.com/document/fortigate/7.6.4/administration-guide/704939/vrrp-virtual-macs
同資料では、この場合に新しいプライマリが GARP を送り、仮想ルーターの IP アドレスを新しいプライマリの MAC アドレスに対応付けると説明されています。この方式では、ケース A と同じく通信相手の ARP キャッシュの更新が確認の中心になります。FortiGate での設定例は、FortiGate VRRP の設定手順で解説しています。VRRP のバージョン（VRRPv2 と VRRPv3）や、FGCP HA のような別方式では動作が異なるため、対象の方式と製品の資料を確認します。
切り替え時の確認手順
機器交換や切り替えの前後では、次の順に確認すると、送信・到達・反映・業務通信の復旧を分けて判断できます。
通信相手の ARP キャッシュにある IP → MAC、スイッチの MAC アドレステーブルにある MAC → ポート、冗長構成では現在の Active（稼働系）を記録します。ケース B なら、SW1 で仮想 MAC がどのポートで学習されているかを確認します。Cisco Catalyst の場合の例です。
show mac address-table address 0000.5e00.0101端末やルーターの ARP キャッシュを確認するコマンドは、「ARP テーブルの確認と削除（Windows・Linux・Cisco）」で解説しています。
製品の資料で、GARP を送る契機（IP アドレスの設定時、Active への遷移時など）、形式、回数、送信する VLAN・インターフェースを確認します。仮想 MAC を使う方式か、インターフェースの MAC を使う方式かも、この段階で確認します。
送信側のインターフェースと、確認したい受信機器の近くでキャプチャします。送信側で見えた通知が、必要な受信機器まで届いたとは限らないため、受信側の観測も必要に応じて加えます。
ケース A では、PC-A や R1 の ARP キャッシュで 192.168.10.20 が新しい MAC アドレスになったかを確認します。ケース B では、PC-A の ARP キャッシュが変わっていないことと、SW1 で仮想 MAC の学習ポートが R2 側へ移ったことを確認します。
新しい機器や新しい Active へ通信が届くこと、業務で使うアプリケーションや管理接続が正常であることを確認します。テーブルが期待どおりでも、ここを確認するまでは完了と判断しません。
Wireshark で GARP を観測する
Wireshark では、表示フィルター arp を入口にし、必要に応じて解析結果のフィールドで絞り込みます。いずれも Wireshark の ARP 表示フィルターリファレンスに記載されたフィールドです。
arparp.isgratuitousarp.isannouncement || arp.isprobearp.isgratuitous などは Wireshark が付ける解析結果のラベルです。送信の目的や正常性は、ラベルだけで判断せず、Opcode、送信元 IP、ターゲット IP、送信元 MAC、Ethernet ヘッダーの送信元 MAC の実際の値で確認します。フィールドの読み方はハブ記事「ARP とは」で、フィルターの組み合わせ方はWireshark のフィルタ書き方と複数条件の使い分けで解説しています。
GARP だけに絞って観測すると、VRRP Advertisement は表示されません。スイッチの学習まで確認する場合は、VRRP の通信や、仮想 MAC を送信元とするフレームを別に観測します。
vrrpeth.src == 00:00:5e:00:01:01
キャプチャに GARP が見えないことや、通信相手の ARP キャッシュが変わらないことは、それだけでは異常の根拠になりません。仮想 MAC を使う方式か、製品がどの契機で GARP を送る仕様かを確認してから判断することをおすすめします。
GARP があっても通信が戻らない場合
GARP は、周囲の機器に更新のきっかけを与える通知です。次の点から、GARP を観測できたことだけで通信の復旧を判断することはできません。
- 送信側で見えた通知が、必要な受信機器まで届いたとは限りません。
- 受信側が通知をどう扱うかは、実装・設定・エントリの状態に依存します。
- 既存エントリの更新と、未登録エントリの新規作成は同じ動作ではありません。
- 静的 ARP エントリが GARP で上書きされるとは限りません。
- VLAN の相違や DAI による破棄があれば、期待どおりに反映されない可能性があります。
- GARP が観測できても、セッションの同期、経路、サービスの準備まで完了したとは限りません。
また、GARP だけで切り替え時間や無停止が保証されるわけではありません。期待するテーブルの更新が確認できない場合や、更新されても通信が戻らない場合は、Request と Reply の観測で区間を絞る「ARP が解決しない原因と確認手順」の手順で切り分けます。
まとめ
GARP は、ARP を使って自分の IP アドレスと MAC アドレスの対応を通知する仕組みです。機器交換と仮想 MAC を引き継ぐ冗長切り替えでは、更新が必要になるテーブルが異なるため、確認する場所も変わります。
- GARP は独立したプロトコルではなく、ARP を使った通知である。
- GARP には Request 形式と Reply 形式がある。
- ARP Probe は重複確認が目的で、送信元 IP は 0.0.0.0
- 機器交換では通信相手の IP → MAC の更新が中心になる。
- 仮想 MAC を引き継ぐ切り替えではスイッチの学習ポートが変わる。
- スイッチは Ethernet ヘッダーの送信元 MAC で学習する。
- 送信・到達・反映・業務通信の復旧は分けて確認する。
以上、最後までお読みいただきありがとうございました。
