linux - editar - Configurar el tiempo de espera de la edad de ARP

linux easytag

Question

Estoy tratando de configurar el tiempo de espera de ARP. Creo que debería establecer /proc/sys/net/ipv4/neigh/default/base_reachable_time_ms en el tiempo de espera deseado. Pero aunque configuro esto a 30000ms (30sec), todavía demora cerca de 10 minutos para que una entrada sea eliminada de la memoria caché ARP. Después de leer algunos artículos, veo que hay algunas configuraciones más que afectan el tiempo de espera:

/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

No estoy seguro de qué programar para estos. El valor de gc_timeout de 5 minutos en Linux. Cambié eso a 30 segundos, pero todavía no veo que la entrada se elimine dentro de base_reachable_time/2 o 3*base_reachable_time/2 .

¿Cómo puedo establecer el tiempo de caducidad para el caché ARP?

Answer 1

El caché del vecino en el kernel de Linux no es tan simple como uno pensaría. Trataré de explicar algunas de las peculiaridades con eso.

Existen diferencias sutiles entre una entrada de caché vecina que realmente se cae del caché por completo o simplemente se marca como obsoleto / no válido. En algún momento entre base_reachable_time / 2 y 3 * base_reachable_time / 2, la entrada seguirá estando en el caché, pero se marcará con un estado de STALE. Debería poder ver el estado con "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

Cuando esté en el estado STALE como se muestra arriba, si hago ping a 192.168.42.1, enviará el paquete a 00: 25: 90: 7d: 7e: cd de inmediato. Un segundo más tarde, por lo general, enviará una solicitud ARP para quién tiene 192.168.42.1 con el fin de actualizar su caché a un estado REACHABLE. PERO, para hacer las cosas más confusas, el kernel algunas veces cambiará los valores de tiempo de espera basados ​​en la retroalimentación positiva de los protocolos de nivel superior. Lo que esto significa es que si hago ping a 192.168.42.1 y responde, entonces el kernel puede no molestarse en enviar una solicitud ARP porque asume que pong significa que su entrada en la memoria caché ARP es válida. Si la entrada está en estado STALE, también se actualizará mediante respuestas ARP no solicitadas que se vean.

Ahora, para la mayoría de los casos, la entrada en estado STALE es todo lo que necesita para preocuparse. ¿Por qué necesita que la entrada se elimine del caché por completo? El kernel hace un gran esfuerzo para no dañar la memoria simplemente cambiando el estado de las entradas de caché en lugar de eliminarlas y agregarlas a la caché todo el tiempo.

Si realmente insistes en que no solo se marcará como STALE, sino que se eliminará del hashmap utilizado por el caché vecino, debes tener cuidado con algunas cosas. En primer lugar, si la entrada no se ha utilizado y está obsoleta durante gc_stale_time segundos, debería ser eliminada. Si pasó gc_stale_time y marcó la entrada como correcta para eliminar, se eliminará cuando se ejecute el recolector de elementos no utilizados (generalmente después de segundos gc_interval ).

Ahora el problema es que la entrada del vecino no se eliminará si se está haciendo referencia a ella . Lo principal con lo que tendrá problemas es la referencia de la tabla de enrutamiento ipv4 . Hay muchas cosas complicadas de recolección de basura, pero lo importante es que el recolector de basura para el caché de ruta solo expira las entradas cada 5 minutos ( / proc / sys / net / ipv4 / route / gc_timeout segundos) en muchos núcleos . Esto significa que la entrada del vecino deberá estar marcada como obsoleta (tal vez 30 segundos, dependiendo de base_reachable_time ), luego deberán transcurrir 5 minutos antes de que el caché de ruta deje de referenciar la entrada (si tiene suerte), seguido de alguna combinación de gc_stale_time y gc_interval pasando antes de que realmente se limpie (por lo tanto, en general, en algún lugar entre 5-10 minutos pasará).

Resumen: puede intentar disminuir / proc / sys / net / ipv4 / route / gc_timeout a un valor más corto, pero hay muchas variables y es difícil controlarlas todas. Se requiere un gran esfuerzo para que las cosas funcionen bien al no eliminar las entradas en la memoria caché demasiado pronto (en lugar de marcarlas como STALE o incluso FALLAR).

Answer 2

La forma más sencilla de limpiar por completo la memoria caché de arp es bajar la interfaz y volver a subirla. Claramente, esto tiene muchas más implicaciones, por ejemplo, posiblemente interrumpir las conexiones TCP en curso, ser inalcanzable durante un tiempo, etc. Pero parece ser el único medio para eliminar realmente una entrada de la memoria caché de arp en los últimos núcleos :(

Answer 3

ip link set arp off dev eth0
ip link set arp on dev eth0