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 <[EMAIL PROTECTED]>
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
