La cache vicina nel kernel di Linux non è così semplice.
Esistono sottili differenze tra una voce della cache adiacente che esce completamente dalla cache o viene semplicemente contrassegnata come obsoleta/non valida. Ad un certo punto tra base_reachable_time /2 e 3* base_reachable_time /2, la voce sarà ancora nella cache, ma sarà contrassegnata con lo stato STALE. Dovresti essere in grado di visualizzare lo stato con "ip -s neighbor show".
Quando nello stato STALE come mostrato sopra, se eseguo il ping 10.64.42.121, invierà immediatamente il pacchetto a b8:20:00:00:00:00. Circa un secondo dopo, di solito invierà una richiesta ARP per chi ha 10.64.42.121 per aggiornare la sua cache a uno stato REACHABLE. MA, per rendere le cose più confuse, il kernel a volte cambierà i valori di timeout in base al feedback positivo dei protocolli di livello superiore. Ciò significa che se eseguo il ping 10.64.42.121 e risponde, il kernel potrebbe non preoccuparsi di inviare una richiesta ARP perché presuppone che il pong significhi che la voce della cache ARP è valida. Se la voce è nello stato STALE, verrà aggiornata anche dalle risposte ARP non richieste che capita di vedere.
Ora, per la maggior parte dei casi, l'unica cosa di cui devi preoccuparti è che la voce sia nello stato STALE. Perché è necessario rimuovere completamente la voce dalla cache? Il kernel fa un grande sforzo per non sovraccaricare la memoria semplicemente cambiando lo stato delle voci della cache invece di rimuoverle e aggiungerle continuamente alla cache.
Se insisti davvero sul fatto che non solo sarà contrassegnato come STALE, ma verrà effettivamente rimosso dalla hashmap utilizzata dalla cache del vicino, devi stare attento ad alcune cose. Innanzitutto, se la voce non è stata utilizzata ed è obsoleta per gc_stale_time secondi, dovrebbe poter essere rimosso. Se gc_stale_time passata e contrassegnata come accettabile per la rimozione, la voce verrà rimossa quando viene eseguito il Garbage Collector (di solito dopo gc_interval secondi).
Ora il problema è che la voce adiacente non verrà eliminata se vi si fa riferimento . La cosa principale con cui avrai problemi è il riferimento dalla tabella di routing ipv4. Ci sono un sacco di cose complicate per la raccolta dei rifiuti, ma la cosa importante da notare è che il Garbage Collector per la route cache fa scadere le voci solo ogni 5 minuti (/proc/sys/net/ipv4/route/gc_timeout secondi) su molti kernel. Ciò significa che la voce del vicino dovrà essere contrassegnata come obsoleta (forse 30 secondi, a seconda del base_reachable_time ), quindi dovranno passare 5 minuti prima che la route cache smetta di fare riferimento alla voce (se sei fortunato), seguita da una combinazione di gc_stale_time e gc_interval passare prima che venga effettivamente ripulito (quindi, nel complesso, passeranno tra i 5 e i 10 minuti).
Riepilogo:puoi provare a diminuire /proc/sys/net/ipv4/route/gc_timeout a un valore più breve, ma ci sono molte variabili ed è difficile controllarle tutte. C'è molto impegno per far funzionare bene le cose non rimuovendo le voci nella cache troppo presto (ma contrassegnandole semplicemente come STALE o addirittura FAILED).
gc_stale_time è il parametro giusto da modificare per eliminare le voci STALE dalla tabella ARP. Ma c'è di più:
La garbage collection ARP viene eseguita nel neigh_periodic_work periodico funzione. L'intervallo può essere modificato tramite la variabile /proc/sys gc_interval .
Verificherà quindi che ci sia almeno gc_thresh1 voci nella tabella ARP. Ciò eviterà di consumare cicli di CPU extra se la tabella è troppo piccola per vedere un reale vantaggio in termini di memoria.
Nel tuo caso, sospetto gc_thresh1 è la variabile che vorrai modificare. abbassandolo si costringerà il GC a funzionare più frequentemente. Tuttavia, ciò potrebbe avere un impatto negativo sulle prestazioni a seconda dell'intervallo di esecuzione.
Nota:gc_thresh3 è una dura soglia. La tabella non manterrà mai più voci di questo valore. Modificalo con cura.