Re: neigbourg table overflour
El mar, 06-03-2007 a las 21:04 +0100, Antonio Trujillo Carmona escribió:
> Este mensaje se me repite muchisimo en un enrutador que emula 28 aliases
> en una tarjeta de red y 18 en la otra filtrando y enrutando con iptables
> (nat)
> He buscado en google y no encuentro algo logico, la interfaz lo esta
> correcta (algunas veces le hechan la culpa de este error a una mala
> configuración de lo)
> La tabla de arp suele tener unas 400 entradas.
> ¿Hay que cambiar algun parametro? ¿cual? ¿como?
> Gracias
Me respondo yo mismo (emppieso a pensar que es un vicio)
en el fichero /etc/sysctl.conf se pueden definir parametros por defecto
del sistem, con sysctl se administran "en vivo" con sysctl -a muestra
los valores, en concreto los que afectan a la tabla de arp son
net.ipv6.neigh.default.gc_thresh3 = 1024
net.ipv6.neigh.default.gc_thresh2 = 512
net.ipv6.neigh.default.gc_thresh1 = 128
El primero es el limite fisico que no se puede sabrepasar, el segundo es
el limite a partil del cual el sistema empesara a borrar registros de la
lista y dara el error que a mi me daba y el tercero es el numero donde
dejara de matar una vez que se haya sobrepasado el segundo.
Se puede variar en caliente con:
echo xxx > /proc/sys/net/ipv4/neigh/default/gc_threshx
En mi caso los amplie (doblando el valor, no se porque pero me parecio
una buena idea) hasta 1024, 2048, 4096 y vi que hay una media de 900
lineas en el registro ( lo vi con arp -a |grep -c eth) lo que no deja
claro que un valor menor daba errores, incluso reducirlo a la mitad (el
valor anterior que probe) eliminava los errores permanentes pero en
picos se volvian a dar.
Realmente no se como afecta esto al rendimiento del sistema pero creo
que si esta pensado para 386 imagino que tener que buscar en dosmil
registros seria algo muy pesado y meteria retrasos al trabajo en red,
pero en prolian con dual xeones a 4G y un sistema de 64 bits no debe de
haber prtoblemas.
Imagino que otra forma de encarar el problema habria sido vagando el
tiempo de permanencia de los registros en la tabla (¿parametro
net.ipv4.neigh.default.gc_interval = 30 quizas?) pero me ha parecido
mas correcto la solución dada debido a la capasidad de la maquina y a
que es un cortafuegos para una red de unos 2300 equipos que estan
permanentemente trabajando contra servidores del otro lado de la red,
por lo que no es de estrañar que la mayoria de ellos esten mandando
paquetes simultaneamente.
--
Antonio Trujillo Carmona <trujo@dti2.net>
Reply to: