インフラ構築に携わっている方にとって「ARP」という単語はよく見聞きする言葉だと思います。
ネットワーク環境において、同じブロードキャストドメインに存在する機器間の通信フローとして、ARPパケットをブロードキャスト送信して宛先IPアドレスのMACアドレスを確認します。ARPはこのように宛先IPアドレスのMACアドレスを解決する機能が一般的ですが、その他にもGARP(Gratuitous ARP)と呼ばれる機能があります。
本記事では、GARPの概要説明と、GARPの機能の一つである対向機器のARPテーブル更新に関わるトラブルを実例と合わせて説明します。実例をもとに「ARPテーブル更新に失敗するとどうような事象が発生するのか」についてもご紹介します。
GARPの機能
GARPには主に以下2つの機能があります。
自身のIPアドレスが他の機器と競合していないか確認する
ある端末が利用したいIPアドレスが他の機器と競合していないか確認するために、GARPを送信します。
WindowsでIPアドレスを固定で設定する際に、同じIPアドレスが他の機器で利用されていると警告メッセージが表示されます。このメッセージはGARPによる確認の結果として表示されます。
このGARPはARP Requestとして送信されます。同じIPアドレスを利用している機器がいた場合、ARP Replyを応答することで重複していると認識します。
パケットキャプチャソフトのWiresharkでは「ARP Probe」または「ARP Announcement」として識別されます。
他の機器のARPテーブルを更新する
冗長構成のネットワーク機器でよく用いられる機能です。
Active-Standby構成でActive機が障害やメンテナンス等でDownした場合に、StandbyがActiveに昇格し、周囲の機器に対してARPテーブルを自身のMACアドレスへ更新するよう促します。パケットキャプチャソフトのWiresharkでは「Gratuitous ARP」として識別されます。
本記事では、紹介した2つのGARPの機能のうち、「他の機器のARPテーブルを更新する」機能が失敗するケースにフォーカスします。
GARPによるARPテーブル更新が失敗するケース
構成について
では、ARPテーブル更新に関わる失敗するケースを紹介します。
以下の図は、実際にトラブルが起きた環境を元に、本記事用にIPアドレスやMACアドレスを置き換えて図示したものです。
本構成では、仮想アプライアンスがActive-Standby構成で別々の物理サーバー内に存在します。この仮想アプライアンスは仮想ルーターとしてSNAT機能を有効にしています。
仮想マシンが外部へアクセスする場合、SNAT IPに変換されて上位ルーター経由で外部と通信します。上位ルーターのARPテーブルにはSNAT IPがActive機のMACアドレスで登録されています。
障害試験と結果
この構成で、仮想アプライアンスの障害試験として、Active-Standby構成の仮想アプライアンスにてActive機をDownさせて、SNAT IPから上位ルーターのGateway IPに対する通信復旧時間を計測しました。
想定では数秒程度で通信復旧するはずが、Active機のDownから復旧まで最長で20分近くかかってしまう、という結果になりました。
原因切り分け
GARPが対向機器に届いているかどうかの確認
まず、GARPが対向機器に届いていない可能性を考えました。
上位ルーターにてパケットキャプチャ実施を提案しましたが、上位ルーターはプロバイダー管理機器のため直接操作はできません。仮想アプライアンスから正常にGARPが送信されている事を確認してから、プロバイダーにキャプチャ実施の依頼をすることになりました。
そこで、仮想アプライアンスの物理サーバーにてパケットキャプチャを実施しました
大量にあるパケットの中からGARPを見つけなければなりません。パケット解析ソフトのWiresharkにてGARPをフィルタするには以下の文字列で検索します。
arp.isgratuitous
先に述べた通りGARPには２種類の機能があります。対向機器のARPテーブルを更新するGARPはARP Replyとして送信されます。Requestに対する応答としてのReplyではなく、Replyパケットを直接送信します。
パケットキャプチャの結果、仮想アプライアンスからは正常にGARPパケットが送信されていることが確認できました。
対向のL2スイッチの確認
次の被疑ポイントとして対向のL2スイッチが考えられます。
今回試験で用いた仮想アプライアンスは仮想MACアドレスは持たず、Active機とStandby機で別々のMACアドレスを用いて通信します。StandbyからActiveに昇格した仮想アプライアンスのMACアドレスはそのままなので、対向L2スイッチのMACアドレステーブルに変更は発生しません。そのためL2スイッチはいったん被疑ポイントから外しました。
L2スイッチの上位ルーターの確認
この結果をふまえ、L2スイッチの上位にあるルーターにて、GARPパケットを受信しているかプロバイダーに確認してもらいましたが、結果として受信していることがわかりました。
それにも関わらず上位ルーターのARPテーブルは更新されず、結果として通信復旧に時間がかかっていました。
追加で調査したところ、上位ルーターにて「GARPパケット受信によるARPエントリーの更新設定」のデフォルト設定が無効になっていることが判明しました。
無効になっていると、ARPエントリーはARPエージングタイマー（保持時間）が経過するまで更新されません。
上位ルーターのARPエージングタイマーは20分であることがわかりました。通信復旧まで最長で20分近くかかっている結果を考慮すると、ARPエージングタイマーでARPエントリーが削除された後に学習して復旧したと推測されます。
対応後の再障害試験と結果
プロバイダー側での設定変更実施後、改めて障害試験を実施したところ数秒程度で正常に通信復旧することができ、トラブルの原因が上位ルーターのデフォルト設定であることが確認できました。
おわりに
GARPパケットに関わるトラブルを、実例をもとにご紹介しました。
今回の事例では上位ルーターと結合して初めて判明したケースとなります。可用性要件を満たすためにはその機器のみならず、接続する周辺機器との連携も考慮に入れる必要があることを改めて学ぶ機会となりました。
また機会がございましたら、今回のように事例を交えた記事を執筆したいと思います。
