El día 20 de marzo de 2010 08:53, Luciano Ruete <[email protected]> escribió: > 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.
Bueno te agradezco, lo voy a intentar en casa. El fw es para el laburo y no puedo hacerme el "geek" y tener a 100 personas sin internet por "x" tiempo hasta que solucione el problema que no se tampoco sè si tendrá solución. De todas maneras pasarme a BSD-pfsense y tratar de aprender algo que nunca toquè me parece mas geek todavia. Saludos -- Hay 10 tipos de personas, las que saben binario y las que no. Luxas
