はじめに
ARP テーブルに相手のエントリが表示されない、INCOMPLETE のまま変わらない、ARP Request に応答がないといった状況では、原因の候補が L2 の経路、相手機器の設定、セキュリティ機能など複数の範囲にまたがります。「Reply が返ってこない」という状態だけでは、どこを調べればよいかが決まりません。
本記事では、観測できた事実から「まだ分からないこと」と「次に確認する場所」を整理し、原因候補を絞る手順を解説します。手順は RFC や各ベンダーの公式資料を基に編集部で整理したものであり、特定ベンダーの公式手順ではありません。
- ARP の異常と判断する前に確認すること
- 送信元のキャプチャから ARP の往復を観測する手順
- 観測結果ごとの、次に確認する場所と原因候補
- VLAN・STP・DAI・IP 重複などの確認ポイント
- 完了の判断と、問い合わせ時に残す情報
結論として、ARP が解決しないときは、観測地点を明確にしたうえで Request と Reply がどこまで届いているかを比較するのが近道です。送信元で Request が見えない、応答側で Request が見えない、応答側の Reply が送信元で見えないなど、途切れた区間によって確認する場所が変わります。キャッシュの削除やセキュリティ機能の無効化は、原因の範囲を絞ってから判断することをおすすめします。
最初に確認すること｜本当に ARP の異常か
ARP の問題に見えても、確認する対象や読み方が違うだけの場合があります。キャプチャを始める前に、次の点を確認します。
確認する対象を合わせる
説明には、本記事群で共通の構成例を使います。PC-A（192.168.10.10/24）、PC-B（192.168.10.20/24）、R1（LAN1 側 192.168.10.1/24、LAN2 側 192.168.20.1/24）、SV-C（192.168.20.30/24）の構成で、PC-A・PC-B・R1 LAN1 側は L2 スイッチの SW1 に接続されています。本記事では、SW1 の 192.168.10.0/24 を VLAN 10 として説明します。説明用の構成であり、実機検証の結果ではありません。
- IPv4 の通信であること（IPv6 は ARP ではなく Neighbor Discovery を使う）
- 確認している OS・機器・インターフェース・VRF が、実際に通信に使われるものであること
- ARP で解決する対象が、経路選択で決まった次ホップの IP アドレスであること
3 点目は特に重要です。PC-A から別セグメントの SV-C（192.168.20.30）へ通信する場合、PC-A が ARP で解決するのは次ホップである R1 LAN1 側の 192.168.10.1 です。PC-A の ARP テーブルに 192.168.20.30 がないのは正常な結果です。宛先が同一セグメントかどうかは、IP アドレスとサブネットマスクから判断します。マスクの食い違いが起きた場合の症状は、サブネットマスクの計算方法で解説しています。
エントリがないことや状態表示だけで障害と判断しない
ARP テーブルにエントリが表示されない理由は、障害だけではありません。まだ通信していない、キャッシュの期限が切れた、表示コマンドで別のインターフェースや VRF を見ているといった場合にも、エントリは表示されません。確認は、対象への通信を発生させてから行います。
Linux の近隣エントリの状態も、単独では原因を示しません。STALE は到達性の確認から時間が経った状態であり、MAC アドレスが誤っていることや通信障害を意味するものではありません。INCOMPLETE は解決の途中であることを示します。
参考: ip-neighbour(8) — Linux manual page
“the neighbour entry has not (yet) been validated/resolved.”
（近隣エントリは、まだ検証・解決されていない）
https://man7.org/linux/man-pages/man8/ip-neighbour.8.html
INCOMPLETE が続く場合や、プローブの上限を超えて FAILED になった場合は、応答を得られていないことは分かりますが、物理断・VLAN・相手機器のどれが原因かまでは分かりません。次の章の観測で区間を絞ります。各 OS・機器でエントリを表示するコマンドは、本記事群の「ARP テーブルの確認と削除（Windows・Linux・Cisco）」で解説しています。
ARP の往復を観測する｜送信元のキャプチャから始める
最初の観測は、送信元の 1 か所で十分です。複数地点での同時キャプチャは、送信元の結果から必要になった場合に追加します。ここでは PC-A から PC-B（192.168.10.20）への通信で説明します。
送信元の ARP テーブルで、対象 IP のエントリの有無・MAC アドレス・状態を記録します。有効なキャッシュがあると、通信を発生させても新しい Request は送られません。RFC 826 でも、送信側はまず表の中から対応関係を探すと説明されています。
観測のためにエントリを削除する場合は、記録を取ったうえで、対象 IP とインターフェースに限定して削除します。手順は「ARP テーブルの確認と削除（Windows・Linux・Cisco）」を参照してください。
通信に使うインターフェースを選んでキャプチャを開始します。キャプチャフィルターを使う場合は arp とし、IP 通信だけに絞るフィルターは使いません。GUI のない Linux サーバーでは、tcpdump でも同じ観測ができます。
sudo tcpdump -ni eth0 -e arpping やアプリケーションの接続など、対象への通信を発生させます。ping が失敗しても、ARP の解決まで失敗したとは限りません。ICMP がフィルタリングされていても、ARP の往復は成立している場合があります。
Wireshark では、表示フィルターで ARP の送信元 IP とターゲット IP の両方を指定すると、対象の Request と Reply をまとめて表示できます。
arp.src.proto_ipv4 == 192.168.10.20 or arp.dst.proto_ipv4 == 192.168.10.20Request のターゲット IP が想定した解決対象か、Request を送ったインターフェースが想定どおりか、Reply が届いているか、Reply の送信元 MAC アドレスが期待する機器のものかを確認します。フィールドの読み方はハブ記事「ARP とは」で解説しています。
結果は「PC-A の eth0 で Request は見えるが Reply は見えない」のように、観測地点を付けて記録します。観測地点を省いて「Reply が返っていない」と書くと、次に調べる場所を誤る原因になります。
キャプチャで誤判断しないための注意点
- 表示フィルターとキャプチャフィルターは構文が異なります。表示フィルターは取得後の表示を絞り、キャプチャフィルターは取得そのものを絞ります。
- ARP は IP パケットではないため、
ipやip.addr == 192.168.10.20のようなフィルターでは表示されません。 - Reply は通常ユニキャストで返るため、送信元以外の無関係な端末でキャプチャしても見えない場合があります。
- 端末内のキャプチャで Request の送信が見えても、NIC から送出されてスイッチに届いたことまでは確認できません。
- ミラーポートを使う場合は、送信元・宛先のポートや VLAN、受信・送信の方向、キャプチャする NIC の設定を確認します。
- 複数地点で比較する場合は、機器間の時刻のずれを確認します。
「キャプチャにない」ことは、「送信されていない」ことと同じではありません。フィルターの書き方については、Wireshark のフィルタ書き方と複数条件の使い分けも参考になります。
観測結果から次の確認場所を絞る
送信元の観測結果を起点に、必要に応じて応答側やスイッチのミラーポートでも観測し、Request と Reply がどこまで届いているかを比較します。
| 観測できたこと | まだ分からないこと | 次の確認場所 | 主な原因候補 |
|---|---|---|---|
| 送信元のキャプチャで Request が見えない | 送信元が対象を解決しようとしたか | 送信元の経路と解決対象、ARP キャッシュ、キャプチャした NIC とフィルター | 想定外の IP を解決している、有効なキャッシュがある、キャプチャ位置・フィルターの誤り |
| 送信元では Request が見えるが、応答側では見えない | どの区間で届かなくなったか | 区間上のスイッチのポート状態・VLAN・trunk・STP・DAI、仮想スイッチ | VLAN の不一致、ポートの停止・err-disable、DAI による破棄、ポートグループの不一致 |
| 応答側では Request が見えるが、Reply が見えない | 応答側が応答しない理由 | 応答側の IP アドレス設定、インターフェースの状態、機器固有の ARP 関連設定 | 対象 IP が設定されていない、別のインターフェースに設定されている |
| 応答側では Reply が見えるが、送信元では見えない | 戻り方向のどこで届かなくなったか | 戻り方向のスイッチのポート・VLAN・DAI、ミラーの方向 | DAI による Reply の破棄、戻り方向の L2 経路の問題 |
| 送信元で Reply が見えるが、期待する対応関係が登録されない | どの機器が、どのインターフェースで応答したか | Reply の送信元 MAC アドレス、Reply の数、受信インターフェース、送信元の静的エントリ | 想定外の機器からの応答、IP アドレスの重複、静的エントリとの競合 |
| 期待する MAC アドレスへの解決を確認できるが、目的の通信ができない | ARP 以外の要因 | 経路、ACL やファイアウォール、戻りの経路、サービスの待ち受け | L3 以上の問題（ARP は正常） |
表の原因候補は、観測結果と矛盾しない候補の例であり、確認できた事実ではありません。候補ごとに次の章の確認ポイントで裏付けを取ります。
応答側のキャプチャが取れない場合
対向機器やサーバーでキャプチャできない場合は、「応答側に届いたか」は断定できない範囲として扱います。そのうえで、次の情報で補います。
- スイッチの MAC アドレステーブルで、対象機器の MAC アドレスを学習しているポートと VLAN
- スイッチのインターフェースの状態、エラーカウンター、err-disable の有無
- DAI などのセキュリティ機能のドロップ統計とログ
- 対象機器側の管理画面やコンソールで確認できる IP 設定とリンク状態
スイッチでミラーポートを設定できる場合は、応答側を接続したポートを送受信の両方向でミラーすると、応答側でのキャプチャに近い観測ができます。
別セグメント宛ての場合は区間ごとに分ける
PC-A から SV-C への通信では、ARP の往復は PC-A と R1 LAN1 側の区間と、R1 LAN2 側と SV-C の区間で別々に行われます。まず PC-A と R1（192.168.10.1）の区間を本章の手順で確認し、問題がなければ R1 の ARP テーブルで 192.168.20.30 のエントリを確認します。ARP のブロードキャストはルーターを越えないため、PC-A でキャプチャしても R1 と SV-C の間の ARP は観測できません。
原因候補ごとの確認ポイント
ここでは、前章の表で挙げた原因候補を確認する際のポイントを整理します。スイッチのコマンド例は Cisco Catalyst 9300（IOS XE 17.x）を想定しています。他の製品や OS では、同等の情報を各製品の資料で確認してください。
アドレス・マスク・経路の誤りで想定外の IP を探している
送信元で見えた Request のターゲット IP が、想定した解決対象と異なる場合は、送信元の IP アドレス・サブネットマスク・デフォルトゲートウェイ・個別ルートを確認します。マスクの誤りで同一セグメントと判断すれば、ルーターではなく宛先そのものを ARP で探し、応答が得られない状態になります。
相手機器に対象 IP がない、インターフェースが停止している
応答側で Request が届いているのに Reply がない場合は、相手機器に対象 IP が設定されているか、そのインターフェースが有効かを確認します。複数のインターフェースを持つ機器では、対象 IP が別のインターフェースに設定されていないかも確認します。
VLAN・trunk・仮想スイッチの設定が一致していない
Request が区間の途中で届かなくなる場合は、送信元と応答側を接続したポートの access VLAN、スイッチ間の trunk で許可された VLAN、タグの扱いを確認します。Cisco の VLAN 設定ガイドでは、trunk の許可リストから外した VLAN の通信はその trunk を通過しないと説明されています（VLAN Configuration Guide, Cisco IOS XE 17.17.x（Catalyst 9300））
show vlan briefshow interfaces trunk仮想マシンの場合は、仮想スイッチのポートグループの VLAN 設定と、物理スイッチ側の設定を突き合わせます。vSphere では、ポートグループの VLAN ID が 1〜4094 なら仮想スイッチがタグを付け外しし、4095 なら仮想マシン側でタグを扱います（vSphere Security: Secure VLANs）
Broadcom のナレッジでは、ポートグループに物理スイッチのネイティブ VLAN と同じ VLAN ID を割り当てる構成はサポートされないと説明されています（Sample configuration of virtual switch VLAN tagging）
VLAN の設計については、VLAN 設計の基礎で解説しています。
ポートの停止・err-disable・STP の状態
区間上のポートが停止していたり、err-disable になっていたりすると、想定した L2 経路が成立しません。
show interfaces status err-disabledshow spanning-tree vlan 10STP でポートがブロックされていること自体は、ループを防ぐための正常な動作です。確認するのは、送信元から応答側まで転送状態のポートで経路がつながっているかどうかです。
MAC アドレステーブルに対象機器の MAC アドレスが登録されていることは、その機器から何らかのフレームを受信したことを示すにとどまります。ARP の往復や IP 通信が成功した証拠にはならないため、キャプチャの結果とあわせて判断します。
show mac address-table address 0000.5e00.5314Dynamic ARP Inspection で ARP が破棄されている
Dynamic ARP Inspection（DAI）は、信頼されていないポートで受信した ARP を検査し、IP アドレスと MAC アドレスの対応が正しくないと判断したパケットを破棄する機能です。Catalyst 9300 のセキュリティ設定ガイドでは、検証には DHCP snooping のバインディングデータベースを使い、DHCP を使わない環境では ARP ACL で許可・拒否を定義すると説明されています。
たとえば、DAI を有効にした VLAN 10 で、PC-B が固定 IP アドレスを使っており、DHCP snooping のバインディングにも ARP ACL にも PC-B の対応関係がない場合、PC-B の ARP は破棄される可能性があります。説明用の例です。確認は、統計・ログ・バインディングの順に進めます。
show ip arp inspection statistics vlan 10show ip arp inspection logshow ip dhcp snooping bindingshow ip arp inspection interfacesDAI は ARP の受信レートも制限し、上限を超えたポートを err-disable にします。既定では信頼されていないインターフェースで 15 pps です。
参考: Security Configuration Guide, Cisco IOS XE 17.18.x (Catalyst 9300) — Configuring Dynamic ARP Inspection
“the switch places the port in the error-disabled state”
（スイッチはそのポートを error-disabled 状態にする）
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-18/configuration_guide/sec/b_1718_sec_9300_cg/configuring_dynamic_arp_inspection.html
同ガイドでは、スイッチ間の接続など本来信頼すべきインターフェースを信頼されていない状態にすると、通信が失われる場合があるとも注意されています。ドロップ理由とカウンターで DAI の影響を確認したら、ARP ACL・バインディング・信頼設定のどれを見直すかを判断します。
DAI を一時的に無効化して通信が戻っても、原因が DAI の設定のどこにあるかは分かりません。無効化を最初の対処にせず、ドロップ統計とログで該当する対応関係を特定してから設定を見直すことをおすすめします。
なお、ACL やファイアウォールで IP 通信や ICMP を止める設定は、ARP 自体を止める機能とは別です。ping が通らないことと ARP が解決しないことは、分けて確認します。
IP 重複や想定外の応答で異なる MAC アドレスが学習される
送信元で期待と異なる MAC アドレスからの Reply が見える場合や、同じ IP アドレスに複数の Reply が返る場合は、IP アドレスの重複や想定外の機器からの応答が考えられます。Reply の送信元 MAC アドレスをスイッチの MAC アドレステーブルで追跡し、どのポートにつながる機器かを確認します。
ただし、MAC アドレスの変化だけで IP 重複や攻撃と断定しないことをおすすめします。冗長構成の切り替えによる仮想 MAC アドレスの変化、Proxy ARP による代理応答、機器交換など、構成上の理由で変わる場合もあります。冗長構成と ARP の関係は、FortiGate VRRP の設定手順でも触れています。
完了の判断と記録する情報
完了とする条件
作業の完了は、次の 2 点で判断します。
- 送信元の ARP テーブルで、解決対象の IP アドレスに期待する MAC アドレスが、意図したインターフェース（VRF）で登録されていること
- 業務で使うアプリケーションや管理接続など、目的の通信が回復していること
期待する MAC アドレスへの解決を確認できても目的の通信ができない場合は、ARP の範囲の切り分けは終わっています。経路、ACL やファイアウォール、戻りの経路、サービスの待ち受けといった次の切り分けへ進みます。
問い合わせ・エスカレーション時に残す情報
ベンダーや他チームへ引き継ぐ場合は、次の情報を残すと、観測のやり直しを減らせます。
| 項目 | 記録する内容の例 |
|---|---|
| 対象 | 解決対象の IP アドレスと、期待する MAC アドレス |
| 場所 | 送信元の機器とインターフェース、VLAN、VRF |
| 時刻 | 発生時刻と観測した時刻（機器間の時刻のずれを含む） |
| 観測結果 | 観測地点ごとの Request / Reply の有無と、キャプチャファイル |
| 状態 | 作業前後の ARP テーブルの表示と、実施した削除などの操作 |
| 関連情報 | スイッチのポート状態、DAI の統計・ログ、関連する設定変更の履歴 |
まとめ
ARP が解決しないときは、原因の一覧から推測するのではなく、観測地点ごとに Request と Reply がどこまで届いているかを比較することで、確認する場所を絞れます。キャッシュの削除やセキュリティ機能の無効化は、区間と原因候補を絞ってから判断します。
- 最初に解決対象が経路上の次ホップであるかを確認する。
- エントリがないことや STALE だけで障害と判断しない。
- 観測は送信元のキャプチャから始め、必要に応じて地点を増やす。
- 結果は観測地点を付けて記録し、途切れた区間を特定する。
- ARP は IP パケットではないため、IP だけのフィルターでは見えない。
- DAI はドロップ統計とログで影響を確認してから設定を見直す。
- 正しく解決できても通信できなければ ARP 以外の切り分けへ進む。
以上、最後までお読みいただきありがとうございました。
