Linux カーネルの近隣キャッシュはそれほど単純ではありません。
ネイバー キャッシュ エントリが実際に完全にキャッシュから除外されるか、単に古い/無効としてマークされるかには微妙な違いがあります。 base_reachable_time の間のある時点 /2 と 3* base_reachable_time /2、エントリは引き続きキャッシュに残りますが、STALE の状態でマークされます。 「ip -s neighbor show」で状態を確認できるはずです。
上記のような STALE 状態のときに、10.64.42.121 に ping を実行すると、すぐにパケットが b8:20:00:00:00:00 に送信されます。 1 秒ほど後に、キャッシュを更新して REACHABLE 状態に戻すために、通常は 10.64.42.121 を持つユーザーに対して ARP 要求を送信します。しかし、問題をさらに混乱させるために、カーネルはより高いレベルのプロトコルからの肯定的なフィードバックに基づいてタイムアウト値を変更することがあります。これが意味することは、10.64.42.121 に ping を実行して応答があった場合、カーネルは、pong が ARP キャッシュ エントリが有効であることを意味していると想定するため、わざわざ ARP 要求を送信しない可能性があるということです。エントリが STALE 状態にある場合、たまたま見た非請求 ARP 応答によっても更新されます。
現在、ほとんどの場合、心配する必要があるのはエントリが STALE 状態であることだけです。 エントリをキャッシュから完全に削除する必要があるのはなぜですか?カーネルは、キャッシュ エントリを実際に削除して常にキャッシュに追加するのではなく、キャッシュ エントリの状態を変更するだけで、メモリをスラッシングしないように多大な努力を払っています。
STALE としてマークされるだけでなく、近隣キャッシュによって使用されるハッシュマップから実際に削除されることを本当に強く主張する場合は、いくつかのことに注意する必要があります。まず、エントリが使用されておらず、gc_stale_time の間古い場合 秒、それは削除される資格があるはずです。 gc_stale_time の場合 通過し、エントリを削除してもよいとマークした場合、ガベージ コレクタの実行時に削除されます (通常は gc_interval の後)。 秒）
ここでの問題は、参照されている場合に近隣エントリが削除されないことです。 .問題が発生する主なものは、ipv4 ルーティング テーブルからの参照です。ガベージ コレクションには複雑なものがたくさんありますが、注意すべき重要なことは、ルート キャッシュのガベージ コレクタがエントリを 5 分ごとに期限切れにするだけであるということです (/proc/sys/net/ipv4/route/gc_timeout)。 秒) 多くのカーネルで。これは、ネイバー エントリが古いものとしてマークされる必要があることを意味します (base_reachable_time に応じて、おそらく 30 秒) )、ルート キャッシュがエントリの参照を停止するまでに 5 分かかる必要があります (運が良ければ)。その後、gc_stale_time の組み合わせが続きます。 および gc_interval 実際にクリーンアップされる前に通過します (したがって、全体として、5 ～ 10 分程度が経過します)。
まとめ:/proc/sys/net/ipv4/route/gc_timeout を減らしてみてください 値を短くしますが、多くの変数があり、すべてを制御することは困難です。キャッシュ内のエントリを早期に削除しないようにすることで、物事がうまく機能するように多くの努力が払われています (代わりに、それらを STALE または FAILED としてマークするだけです)。
gc_stale_time ARP テーブルから STALE エントリを削除するために微調整する適切なパラメータです。しかし、もっとあります:
ARP ガベージ コレクションは定期的な neigh_periodic_work で実行されます 関数。間隔は /proc/sys 変数 gc_interval で微調整できます .
次に、少なくとも gc_thresh1 があることを確認します。 ARP テーブルのエントリ。これにより、テーブルが小さすぎてメモリに関して実際の利点が見られない場合に、余分な CPU サイクルを消費することを回避できます。
あなたの場合、私は gc_thresh1 を疑います 微調整する変数です。値を下げると、GC の実行頻度が高くなります。ただし、実行間隔によっては、パフォーマンスに悪影響を及ぼす可能性があります。
注:gc_thresh3 ハードしきい値です。テーブルは、この値よりも多くのエントリを保持しません。注意して微調整してください。