Este es un error que realmente me tuvo sufriendo varios dias, resuelta que en mi servidor tenia grandes perdidas de paquetes, pese a que el servidor no estaba cargado ni nada, la perdida era grande, revisaba si habia ataques de negacion de servicios y no existian, sin embargo al hacer ping al server la perdida era enorme y los sitios inaccesibles,

El síntoma relativo a este error de kernel o sistema se puede ver perfectamente cuando, nuestro linux es incapaz de devolver todos los paquetes TCP/IP. Si tenemos un servidor web apache, vemos lentitud en la carga de la web o incluso devuelve TimeOut. Si hacemos un ping, veremos que algunos paquetes no reciben respuesta con el típico mensaje.

“Tiempo de espera agotado para esta solicitud”

Luego de revisar el servidor y reiniciar varias veces la tarjeta de red para poder trabajar, pude ejecutar el comando dmesg y fue ahi que tuve el siguiente mensaje.

IP_CONNTRACK: TABLE FULL, DROPPING PACKET

Algo asi como tambla completa, eliminando paqutes.

Lo que provocaba que sea imposible el acceso al server, entonces filtre los ultimos mensajes del kernel.

dmesg | egrep conntrack

Donde pude ver que habia muchas pérdidas.

También pude ver que el patron se repetia viendo los messages.

grep conntrack messages

Teniendo algo como:

Jun 15 22:15:20 mailsswl kernel: ip_conntrack: table full, dropping packet.
Jun 15 22:15:50 mailsswl kernel: NET: 66 messages suppressed.
Jun 15 22:15:51 mailsswl kernel: ip_conntrack: table full, dropping packet.

El servidor comienza a descartar paquetes lo que deriva en que muchas solicitudes se descartadas y esto, en un entorno de servidor web significa un servicio degradado.

Acto seguido deberiamos ver el numero de conexiones activas.

cat /proc/net/ip_conntrack | wc -l

58007

Ahota vamos a ver el límite que tenemos en la configuración.

cat /proc/sys/net/ipv4/ip_conntrack_max
65536

Si bien es cierto el numero de conexiones activas es inferior al maximo permitido, sin embargo al aproximarse al mismo, este nos genera el error causando un alto trafico y derivado en la caida de la red.

Investigado en varios sitios he visto que se pueden efectuar algunas modificaciones en el sysctl.conf para afinar un poco el rendimiento del sistema.

Para ello vamos a ver la configuracion de la maquina y los valores que se relacionan con el problema, para ello ejecutamos el comando siguiente:

sysctl -a | grep conntrack

Modificamos tres de estos valores: ip_conntrack_max, ip_conntrack_timeout_established y ip_conntrack_timeout_close_wait. El primero como ya lo indiqué indica el número total máximo de conexiones permitidas. Este número esta directamente ligado al total de RAM disponible en el sistema. Este ultimo tema es algo que no he logrado aún comprender, ¿qué número total de bytes utiliza el kernel para cada conexión? Algunos documentos hablan de 350 bytes pero, a través del dmesg buscando el error encontré valores distintos, lo que me lleva a pensar que el valor varía segúen el kernel.

Asi que dependiendo de eso tendrémos que hacer un pequeño cálculo a continuación describo un ejemplo de como hacer el cálculo según el problema que se presenta, lo que describo a continuación es de un foro amigo donde exponían el problema.

Tomemos el valor de 228 bytes para hacer las modificaciones, mientras encuentro la confirmación definitiva a esta duda. Si hacemos un pequeño cálculo, tenemos que 65536 x 228 = 14.942.208 de bytes, que en MB son 14.25 MB. Un aumento razonable, teniendo en cuenta las posibilidades de repartir un recurso como la RAM podría ser los 20 MB, que representaría un total de 91980 conexiones. En los momentos de más trabajo, nunca ha estado la memoria por debajo de los 100-70 MB libres con lo cual, un aumento de tan sólo 6 MB parece bastante prudente.

ip_conntrack_timeout_established define el tiempo establecido para conexiones hasta devolver un timeout. El valor por defecto es 432000 segundos, lo cual parece un poco exagerado o al menos, susceptible de ser tuneado. Dejaremos el tiempo establecido en 8 horas, tiempo más que razonable(28800 segundos).

ip_conntrack_timeout_close_wait define el tiempo en segundos hasta devolver un timeout y cerrar la conexión. Un tiempo normal serían unos 60 segundos.

Para modificar estos valores, modificamos el /etc/sysctl.conf

##Limita en segundos el tiempo que permanecen activas las conexiones TCP/IP – por defecto 432000
#net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 28800

##Limita a 20 MB en memoria RAM (no swap) la cantidad de conexiones TCP/IP permitidas – por defecto 65536
#net.ipv4.netfilter.ip_conntrack_max = 91980

##Limita a 60 segundos el tiempo para cerrar la conexion y dar timeout
#net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60

Y para recargar el archivo de configuración modificado:

#sysctl -p.

OTRA FORMA DE RESOLVERLO

Bien esa fue una solución sin embargo otra alternativa y la que yo use en realidad es la de aumentar el limite de peticiones.

sysctl -w net.ipv4.netfilter.ip_conntrack_max=12000

O puedes hacer lo mismo agregando la siguiente línea en el archivo /etc/sysctl.conf

net.ipv4.netfilter.ip_conntrack_max=12000

o también.

echo 131072 > /proc/sys/net/ipv4/ip_conntrack_max

Listo con eso el problema se resolvió y la saturación en la red dessapareció.

MFCP!!!