Re: Linux router para ISP con posibles problemas
El 09/08/13 04:36, Mauro Antivero escribió:
> Estimados:
>
> En mi lugar de trabajo tenemos un router Linux (Debian Squeeze corriendo
> en un Dell PowerEdge R210-II) por el cual cursa todo el tráfico de la
> red de usuarios del ISP.
>
> El problema que estamos teniendo es que pareciera ser que cuando el
> tráfico total que atraviesa al servidor llega a los 550 Mbps se
> "estanca", es decir no suele crecer mucho más que ese valor. Esto nos
> parece extraño puesto que según estimamos el tráfico debería estar
> llegando a los 650 Mbps aprox.
>
> En su momento se modificó lo que es el valor de:
>
> /proc/sys/net/ipv4/netfilter/ip_conntrack_max
>
> Puesto que cuando el tráfico llegaba a 200 Mbps aprox. el mismo en lugar
> de subir comenzaba a bajar y con dmesg obteníamos el siguiente mensaje:
>
> nf_conntrack: table full, dropping packet
si, quizas haya algun valor mas a nivel de /proc que se podria mirar,
aunque ahora a bote pronto no sabria decirte, pero el de "ip_conntrack"
era el que yo tambien mire en su dia.
> Posteriormente a esto, en un servidor mucho menos potente que el actual
> hubo que "jugar" con los parámentros de la placa de red (Intel Gigabit,
> no recuerdo bien el modelo ahora) para que pueda manejar las
> interrupciones y además hubo que hacer un bondig entre dos de estas
> placas de red para que pueda manejar todo el tráfico.
>
> En el servidor por el cual ahora les consulto no fue necesario hacer un
> bonding, pero si modificar el valor de ip_conntrack_max.
bueno, obviamente tienes que ver cual es el tráfico generado y hasta
donde "da" la tarjeta de red, en cualquier caso, teniendo un equipo como
router corporativo, si tienes alguna tarjeta adicional, yo pondria
bonding SI o SI, no solo por el balanceo sino como alta disponibilidad
> El tema es que ahora como les decía, a simple vista, no estamos teniendo
> ninguno de estos problemas, pero tenemos la sensación de que "algo" está
> pasando.
>
> Les quería consultar entonces qué parámetros tendría que ir mirando y
> controlando para ver si realmente estamos teniendo un problema en el
> servidor o no.
>
> Un detalle que creo muy importante es que a veces, sin razón aparente,
> la interfaz de red dropea paquetes. Pero como les decía esto, si bien no
> tiene que pasar, pasa poco. Acá van los datos de la interfaz por la cual
> ingresa el tráfico:
>
> ifconfig eth0
>
> eth0 Link encap:Ethernet HWaddr d0:67:e5:e7:d7:45
> inet addr:172.30.0.1 Bcast:172.30.0.255 Mask:255.255.255.0
> inet6 addr: fe80::d267:e5ff:fee7:d745/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:232816986602 errors:462 dropped:1606 overruns:0
> frame:462
> TX packets:337849634947 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:67228041135161 (61.1 TiB) TX bytes:317032238655465
> (288.3 TiB)
> Interrupt:16 Memory:c0000000-c0012800
>
> Les agradecería mucho sus comentarios y ayuda para así determinar si el
> problema está en el servidor o no.
>
> Espero no haber omitido cualquier dato que sea útil, cualquier cosa me
> avisan.
el ifconfig no dice nada del otro barrio, si hay paquetes "dropped" pero
no sabemos ni la velocidad, si esta a full duplex, el TSO... en fin.
la salida completa de ethtool, por ejemplo
hay muchos valores que podrian influir, fijate lo que he sacado del mio...
/proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout
600
-----
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_sent
120
-----
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_sent2
120
-----
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_recv
60
-----
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
432000
-----
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait
120
-----
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait
60
-----
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_last_ack
30
-----
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait
120
-----
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close
10
-----
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_max_retrans
300
-----
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_loose
1
-----
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal
0
-----
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_max_retrans
3
-----
/proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
30
-----
/proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream
180
-----
/proc/sys/net/ipv4/netfilter/ip_conntrack_icmp_timeout
30
-----
/proc/sys/net/ipv4/netfilter/ip_conntrack_max
65536
-----
/proc/sys/net/ipv4/netfilter/ip_conntrack_count
269
-----
/proc/sys/net/ipv4/netfilter/ip_conntrack_buckets
16384
-----
/proc/sys/net/ipv4/netfilter/ip_conntrack_checksum
1
-----
/proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid
0
-----
Como puedes ver hay muchas variables, y desde luego no te aconsejo que
toques sin saber exactamente que.
Una prueba sencilla que puedes hacer es resetear los contadores de la
placa de red, no estoy seguro pero creo que hay que descargar el modulo
y volverlo a cargar (o un reinicio supongo) y monitorizar desde ahi, de
esta forma puedes ir viendo los "dropped", cuando y cuantos se producen...
Reply to: