web-dev-qa-db-ja.com

ARPエージングタイムアウトの設定

ARPエージングタイムアウトを設定しようとしています。 /proc/sys/net/ipv4/neigh/default/base_reachable_time_msを希望のタイムアウトに設定する必要があると思います。ただし、これを30000ms（30秒）に設定しても、エントリがARPキャッシュから削除されるまで10分近くかかります。いくつかの記事を読んだ後、タイムアウトに影響する設定がいくつかあります。

/proc/sys/net/ipv4/neigh/default/gc_interval
/proc/sys/net/ipv4/neigh/default/gc_stale_time
/proc/sys/net/ipv4/route/gc_interval
/proc/sys/net/ipv4/route/gc_timeout

これらのために何をプログラムすればよいかわかりません。 Linuxでは、gc_timeoutのデフォルトは5分です。これを30秒に変更しましたが、それでもbase_reachable_time/2または3*base_reachable_time/2内でエントリが削除されないのがわかります。

ARPキャッシュの有効期限を設定するにはどうすればよいですか？

linuxlinux-kernelarp
34
Thomas

Linuxカーネルの隣接キャッシュは、思っているほど単純ではありません。いくつかの癖を説明しようと思います。

近隣のキャッシュエントリが実際に完全にキャッシュから抜け出すか、単に古い/無効としてマークされている間には微妙な違いがあります。 base_reachable_time/ 2と3 *base_reachable_time/ 2の間のある時点で、エントリはキャッシュに残りますが、STALEの状態でマークされます。 「ip -s neighbor show」で状態を表示できるはずです。

pherricoxide@midigaurd:~$ ip -s neighbor list
192.168.42.1 dev eth0 lladdr 00:25:90:7d:7e:cd ref 2 used 184/184/139 probes 4 STALE
192.168.10.2 dev eth0 lladdr 00:1c:23:cf:0b:6a ref 3 used 33/28/0 probes 1 REACHABLE
192.168.10.1 dev eth0 lladdr 00:17:c5:d8:90:a4 ref 219 used 275/4/121 probes 1 REACHABLE

上記のようなSTALE状態で、192.168.42.1にpingを実行すると、すぐにパケットが00：25：90：7d：7e：cdに送信されます。 1秒ほど後、通常、キャッシュを更新してREACHABLE状態に戻すために、192.168.42.1のユーザーにARP要求を送信します。しかし、問題をより混乱させるために、カーネルは時々、より高いレベルのプロトコルからの肯定的なフィードバックに基づいてタイムアウト値を変更します。これが意味するのは、192.168.42.1にpingして応答した場合、pongがARPキャッシュエントリが有効であることを想定しているため、カーネルはARP要求を送信しなくてもよいということです。エントリがSTALE状態にある場合、それは偶然に見られる未承諾のARP応答によっても更新されます。

さて、ほとんどの場合、STALE状態にあるエントリは心配する必要があるすべてです。なぜエントリを削除する必要があるのですかキャッシュから完全に？カーネルは、キャッシュエントリを常に実際に削除してキャッシュエントリに追加するのではなく、キャッシュエントリの状態を変更するだけで、メモリをスラッシングしないように努力しています。

STALEとしてマークされるだけでなく、ネイバーキャッシュによって使用されるハッシュマップから実際に削除されると本当に強く主張する場合は、いくつかの点に注意する必要があります。まず、エントリが使用されておらず、gc_stale_time秒の間失効している場合、削除する資格があります。 gc_stale_timeが渡され、エントリを削除してもよいとマークされた場合、ガベージコレクタの実行時に削除されます（通常はgc_interval秒）。

問題は、隣接エントリが参照されている場合は削除されないことです。主な問題は、 ipv4ルーティングテーブル からの参照です。複雑なガベージコレクションがたくさんありますが、注意すべき重要なことは、ルートキャッシュのガベージコレクタは5分ごとにエントリを期限切れにすることです（/ proc/sys/net/ipv4/route/gc_timeoutseconds）多くのカーネルで。これは、ネイバーエントリを失効としてマークする必要があることを意味します（base_reachable_timeに応じて30秒になる可能性があります）。ルートキャッシュは（幸運なら）エントリの参照を停止し、gc_stale_timeとgc_interval実際にクリーンアップされる前に通過します（したがって、全体として、5〜10分が経過します）。

要約：/ proc/sys/net/ipv4/route/gc_timeoutをより短い値に減らすことを試みることができますが、多くの変数があり、それらをすべて制御することは困難です。キャッシュ内のエントリを削除するのが早すぎないようにすることで、物事をうまく機能させるために多大な労力が費やされます（代わりに、それらをSTALEまたはFAILEDとしてマークするだけです）。

88
PherricOxide
ip link set arp off dev eth0
ip link set arp on dev eth0
2
nyet

Arpキャッシュを完全に消去する最も簡単な方法は、インターフェイスをいったんダウンしてから再びアップすることです。明らかに、これにはもっと多くの意味があります。たとえば、進行中のTCP接続を中断したり、しばらく到達できなかったりする可能性があります）。最新のカーネル:(

0
Marco Mellia