Der Nachbar-Cache im Linux-Kernel ist nicht so einfach.
Es gibt subtile Unterschiede zwischen einem Nachbar-Cache-Eintrag, der tatsächlich vollständig aus dem Cache fällt oder nur als veraltet/ungültig markiert wird. Irgendwann zwischen base_reachable_time /2 und 3* base_reachable_time /2, befindet sich der Eintrag weiterhin im Cache, wird jedoch mit dem Status STALE gekennzeichnet. Sie sollten in der Lage sein, den Status mit "ip -s Neighbor Show" anzuzeigen.
Wenn ich im STALE-Zustand wie oben gezeigt 10.64.42.121 pinge, wird das Paket sofort an b8:20:00:00:00:00 gesendet. Ungefähr eine Sekunde später sendet es normalerweise eine ARP-Anfrage, wer 10.64.42.121 hat, um seinen Cache wieder auf einen REACHABLE-Zustand zu aktualisieren. ABER um die Sache noch verwirrender zu machen, ändert der Kernel manchmal Timeout-Werte basierend auf positivem Feedback von Protokollen höherer Ebene. Das bedeutet, dass, wenn ich 10.64.42.121 pinge und es antwortet, der Kernel sich möglicherweise nicht die Mühe macht, eine ARP-Anfrage zu senden, weil er annimmt, dass das Pong bedeutet, dass sein ARP-Cache-Eintrag gültig ist. Wenn sich der Eintrag im STALE-Zustand befindet, wird er auch durch unaufgeforderte ARP-Antworten aktualisiert, die er zufällig sieht.
Nun brauchen Sie sich in den meisten Fällen nur um den Eintrag mit dem Status STALE zu kümmern. Warum muss der Eintrag vollständig aus dem Cache entfernt werden? Der Kernel gibt sich große Mühe, den Speicher nicht zu ruinieren, indem er einfach den Status von Cache-Einträgen ändert, anstatt sie tatsächlich ständig zu entfernen und dem Cache hinzuzufügen.
Wenn Sie wirklich darauf bestehen, dass es nicht nur als STALE markiert, sondern tatsächlich aus der vom Nachbarcache verwendeten Hashmap entfernt wird, müssen Sie einige Dinge beachten. Erstens, wenn der Eintrag nicht verwendet wurde und seit gc_stale_time veraltet ist Sekunden sollte es entfernt werden können. Wenn gc_stale_time bestanden und den Eintrag zum Entfernen als in Ordnung markiert, wird er entfernt, wenn der Garbage Collector ausgeführt wird (normalerweise nach gc_interval Sekunden).
Nun besteht das Problem darin, dass der Nachbareintrag nicht gelöscht wird, wenn darauf verwiesen wird . Die Hauptsache, mit der Sie Probleme haben werden, ist die Referenz aus der IPv4-Routing-Tabelle. Es gibt eine Menge kompliziertes Garbage-Collection-Zeug, aber das Wichtigste ist, dass der Garbage-Collector für den Routen-Cache Einträge nur alle 5 Minuten ablaufen lässt (/proc/sys/net/ipv4/route/gc_timeout Sekunden) auf vielen Kerneln. Das bedeutet, dass der Nachbareintrag als veraltet markiert werden muss (vielleicht 30 Sekunden, abhängig von base_reachable_time ), dann müssen 5 Minuten vergehen, bevor der Routen-Cache aufhört, auf den Eintrag zu verweisen (wenn Sie Glück haben), gefolgt von einer Kombination aus gc_stale_time und gc_interval vergehen, bevor es tatsächlich aufgeräumt wird (insgesamt werden also zwischen 5 und 10 Minuten vergehen).
Zusammenfassung:Sie können versuchen, /proc/sys/net/ipv4/route/gc_timeout zu verringern auf einen kürzeren Wert, aber es gibt viele Variablen und es ist schwierig, sie alle zu kontrollieren. Es wird viel Aufwand betrieben, damit die Dinge gut funktionieren, indem Einträge im Cache nicht zu früh entfernt werden (sondern stattdessen einfach als STALE oder sogar FAILED markiert werden).
gc_stale_time ist der richtige Parameter, um STALE-Einträge aus der ARP-Tabelle zu entfernen. Aber es gibt noch mehr:
Die ARP-Garbage-Collection wird regelmäßig neigh_periodic_work ausgeführt Funktion. Das Intervall kann über die /proc/sys-Variable gc_interval angepasst werden .
Es wird dann überprüft, ob mindestens gc_thresh1 vorhanden ist Einträge in der ARP-Tabelle. Dadurch wird vermieden, dass zusätzliche CPU-Zyklen verbraucht werden, wenn die Tabelle zu klein ist, um einen wirklichen Vorteil in Bezug auf den Speicher zu sehen.
In Ihrem Fall vermute ich gc_thresh1 ist die Variable, die Sie anpassen möchten. ein niedrigerer Wert zwingt den GC dazu, häufiger zu laufen. Dies kann sich jedoch je nach Ausführungsintervall negativ auf die Performance auswirken.
Hinweis:gc_thresh3 ist eine harte Schwelle. Die Tabelle enthält nie mehr Einträge als diesen Wert. Optimieren Sie es mit Sorgfalt.