トラブルシュート

【ARPトラブル】の原因と対処 ～応答解決しない(incomplete),要求の大量発生～

ネットワークのトラブルシューティングに欠かせない ARP テーブル確認

ARP は NW のトラブルシューティングの切り分け時にも最初の方に着目すべきポイントです。

例えば端末で NW の疎通が取れない場合、私は最初に DGW への ping を試した後、もし ping の応答がなかった場合は ARP テーブルを確認するようにしています。ARP テーブルに載っていれば DGW は正しく動作していると判断してよいでしょう。ACL によって ping が拒否されているだけで、ルーティングはできるはずです。一方、ARP テーブルに載ってこなければその観点で何か問題が発生していることを示しています。

もちろんこれは一例であり、NW の疎通性を確認する上で「同一セグメントで ping ⇒ ARP テーブル確認」というのはとても有用です。

今回はこの ARP に纏わるトラブル事例 2 つをご紹介します。

事象1. ARP 解決に失敗する

概要

Windows の ARP テーブル (arp -a) を確認すると該当の ARP エントリが表示されない、

Cisco 等の NW機器上で ARP テーブル (show ip arp ) を確認すると "incomplete" と表示される、

など、ARP 解決に失敗してしまう。

SW1# show ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.1.1 0 Incomplete ARPA
Internet 192.168.1.2 0 Incomplete ARPA
Internet 192.168.1.3 0 Incomplete ARPA
Internet 192.168.1.254 - 0007.7dfe.fefe ARPA GigabitEthernet1/0/24

原因

端的に、ARP request を送ったのに ARP reply が返って来なかったことが原因です。

例えば同セグメントの IP 機器同士で Ping を打ってみて、相手の IP 機器の MAC アドレスが表示されないようなケースです。

このときの考えうるケースとしては以下があります。

  1. 相手のネットワークインタフェースがダウンしている、もしくはホスト自体がダウンしている
  2. IP 機器間の VLAN が違っている
  3. 対向の IP が NAT 後の IP であったりリモートアクセスVPN で払い出される IP である

なお、相手方で Ping を拒否する設定になっていたとしても、ARP 解決はできるので、これは原因にはなり得ません。

1. については説明は不要かと思います。機器やインタフェースがシャットダウンしていたら応答はありません。

2.についてですが、IP 機器同士で同一セグメントのサブネットを割り当てていても、接続する L2 スイッチ等で VLAN を割り当て間違えていると ARP Request が届かないので当然応答もありません。正しい VLAN に修正しましょう。

3. ですが、NAT 後に使われる IP や IPsec-VPN / SSL-VPN といったリモート VPN で付与された IP はインタフェースに実際に割り当たっているわけではないため、ARP Request が届きません。

このようなケースでは一般に proxy-arp を使うことによって解消されます。(機器によっては自動で設定されます)

事象の詳細や解決へのヒントについては以下をご参照下さい。

【図解】Proxy(プロキシ)-ARPの仕組みと設定(cisco/fortigate)、ローカルProxy-ARP
Proxy-ARP とは Proxy-ARP とは、自分宛ではない ARP 要求...
milestone-of-se.nesuke.com
2022.03.15

事象2. ARP request/reply が大量に発生する

概要

パケットキャプチャで観測すると、大量の ARP request/reply が発生している

原因

シナリオとしてはいろいろ考えられると思いますが、共通して考えられるのは、/16 等の広いレンジのセグメントに非常に多くの IP 機器が配置されていることです。

私が経験したことのあるシナリオとしては、/16のセグメントに安い家庭用の無線 AP を 800 台近く設置し、UPnP 機能を有効にする、といったものです。

UPnP を有効にしていると、Windows のデフォルトで有効になっている『SSDP (Simple Service Discovery Protocol)』のマルチキャストパケットに反応します。

なので、SSDP マルチキャストパケットをトリガーに、無線 AP が一斉に「SSDP の送信元の Windows PC の MAC アドレスは何？」と ARP Request をブロードキャストします。

すると、ARP は実は Request を受信するだけでも学習してしまいますので、互いに800台分の MAC アドレスを ARP テーブルに載せようとします。

ただ、家庭用の安い無線 AP の ARP テーブルはそこまでの台数分のエントリを保存できるようにはなっておらず、ARP 期限切れよりも前にテーブルから溢れていきます。

なので結局また覚え直しで ARP Request を投げる、という悪循環を生み出します。

このシナリオでの解決策は、セグメントを細かく分割すること、無線 AP の UPnP 機能をオフにすることです。

これはケースのうちの1つでしかありません。実際のトラブル発生時では「どの端末が何をトリガーにARPを投げているのか？その端末のARPテーブルのエントリ数の仕様上の制限はどれほどか？ARP の期限 (timeout) はどれくらいか？」といったところを調査していく必要があります。

コメント

タイトルとURLをコピーしました