On Friday 19 March 2010 03:13:55 pm Lucas Nogueron wrote: > El día 19 de marzo de 2010 13:55, Luciano Ruete > > <[email protected]> escribió: > > On Wednesday 17 March 2010 12:38:31 pm Lucas Nogueron wrote: > >> El día 17 de marzo de 2010 12:13, Alfredo Daniel Rezinovsky > >> > >> <[email protected]> escribió: > >> > El mié, 17-03-2010 a las 12:01 -0300, Luciano Ruete escribió: > >> >> On Wednesday 17 March 2010 09:44:39 am Lucas Nogueron wrote: > >> >> > Hola! > >> >> > > >> >> > Estoy usando BrazilFW 2.31.10 para compartir inet y tengo este > >> >> > inconveniente, me sale este error "dst cache overflow", y eso hizo > >> >> > que se bloqueara mi red. El FW deja de responder y no queda mas que > >> >> > reseteralo. He googleado bastante y lo unico que encontre es q es > >> >> > un bug de kernel. Otros sugieren q es por el tamaño de cache. La > >> >> > cuestiion es que despues de un tiempo aparece el mensajito en la > >> >> > consola y el fw se muere. > >> >> > >> >> Te estás quedando sin entradas en el cache de la tabla de ruteo, para > >> >> agrandarlo tenés varias opciones: > >> >> -si tenés memoria disponible podés agrandar el cache: max_size > >> >> -si no tenés memoria tenes que aumentar la agresividad del garbage > >> >> collector para que libere y expire más pronto las entradas. > >> >> Te paso mis anotaciones de cuando tuve ese problema, mi solución fue > >> >> aumentar el max_size y un valor más que van en relacion (gc_treash) > >> >> para relajar al garbage collector ahora que la tabla está más grande. > >> >> > >> >> Suerte! > >> >> > >> >> #pareciera ser el promedio maximo de profundidad x hash entry > >> >> #que el kernel acepta antes de empezar a expirar hashentrys(y sus > >> >> rutas) # default 8, mi valor por ahora es 8 > >> >> up echo 8 > /proc/sys/net/ipv4/route/gc_elasticity > >> >> # determina el limite aceptable de entradas en la tabla > >> >> # antes hacer gc real > >> >> # default 4096, mi valor max_size/2 > >> >> up echo 65536 > /proc/sys/net/ipv4/route/gc_thresh > >> >> # cada cuanto se ejecuta explicitamente el gc > >> >> # default 60(seg) > >> >> up echo 60 > /proc/sys/net/ipv4/route/gc_interval > >> >> # el timeout de una ruta antes de ser candidata a ser borrada > >> >> # default es 300(seg) > >> >> up echo 300 > /proc/sys/net/ipv4/route/gc_timeout > >> >> # tamano maximo de entradas en la tabla de routeo > >> >> # default 65536?, mi valor 2*r_hash (podria ser 8*r_hash para ser > >> >> coherente con gc_elast) > >> >> up echo 131072 > /proc/sys/net/ipv4/route/max_size > >> >> # cada cuanto se hace una limpieza _completa_ (equivale a un flush) > >> >> # default 600(seg, son 5min), mi valor 1hora > >> >> up echo 3600 > /proc/sys/net/ipv4/route/secret_interval > >> > > >> > Estos parametros se suelen configurar solos en base a la RAM. > >> > Podes tocarlos pero una buena idea si realmente necesitas tanto ruteo > >> > simultaneo sería poner más ram > >> > >> Exacto, le puse mas RAM y se modificó: > >> > >> max_size:16384 > >> > >> Ahora, Luciano dice que aumente max_zise, la cuestion es ¿hasta cuanto > >> se podria? Tengo 180 MB ram. > > > > podes aumentar un montón porque las entradas en la tabla de ruteo no > > ocupan demasiada memoria, en un momento había sacado la cuenta pero ya no > > recuerdo, googlealo(o busca en el fuente del kernel y sumá el struct). > > > > El tema es que esa memoria es de kernel no swapeable así que conviene no > > exagerar. aumentá la tabla tranquilo a 65mil y fijate si te soluciona. > > > >> Otra cosa, no creo que sea problema de memoria, puesto que > >> proc/meminfo me indica que me sobra mucha. La maquina es solo un > >> router que natea y no tiene nada raro. > > > > Por más que en meminfo veas que te sobrán varios megas eso no significa > > que el kernel los pueda usar para la tabla de ruteo, se lo tenes que > > declarar vos explicitamente. > > No hace falta que compres más ram, ya que la tenes libre dasela a quien > > la necesita en este caso la tabla de ruteo (max_size). > > > > Saludos! > > Gracias Luciano > > La cuestion es que pasé los parametros que posteaste, los > verifique en funcionamiento. Pero no hay caso , no hay solucion, al > menos en inet hablan de los mismo y no hay caso, pareceria que es un > bug de kernel con el bridge.... con mas o menos memoria o lo que venga > tarde o temprano lo tira al errror. Falto probar la solucion de Ruben > que era hacer dos subnets separadas y sin bridge.. Por ahora mi > solucion fue pasarme a la distro Pfsense , hacer un par de clicks en > la interfaz wlan para que actue como ap , y listo, salió andando . > Faltaria probarlo a toda maquina pero pareceria mas robusto que > brazilfw. Si todo sale bien comento la experiencia. Salutos.
El otro cache que se puede estar llenando y más en un bridge es el de neighborhood (MAC address vecinas), pero si mal no recuerdo el mensaje en syslog sería otro (igual la memoria en estas cosas no es de confiar). r...@sistecom:~# grep . /proc/sys/net/ipv4/neigh/default/gc_t* /proc/sys/net/ipv4/neigh/default/gc_thresh1:2048 /proc/sys/net/ipv4/neigh/default/gc_thresh2:4096 /proc/sys/net/ipv4/neigh/default/gc_thresh3:8192 seguro tus numeros son más bajos por la poca RAM que tenés, los podes aumentar a mano tranquilo. Cambiar de distro ante un error así es la solución menos geek, deberías querer aprender y entender como solucionar de _verdad_ el problema que tenés. Saludos! -- Luciano
