Tabla conntrack del servidor llena conntrack table full

ID de la causa so-conntrack · Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo), Desarrollo de cliente (Equipo de desarrollo)

Abrir la ficha interactiva con gráficos y simulaciones →

Cuando la tabla de seguimiento de conexiones (conntrack), donde el firewall de Linux registra todas las conexiones, llega a su límite, se descartan paquetes nuevos.

Por qué Una avalancha de conexiones o conexiones cortas repetidas multiplican las entradas de seguimiento → Efecto La tabla se llena y se descartan conexiones nuevas y algunos paquetes → En pantalla El juego no conecta, y la pérdida de paquetes sin causa aparente provoca teletransporte

Síntomas: No conecta / carga infinita, Teletransporte
Factores: Pérdida de paquetes
A quién afecta: Todo el servidor
Cuándo: Al conectar o tras un mantenimiento, Cuando se junta mucha gente
Responsable: Responsable principal Infraestructura de servidores (Equipo de infraestructura) · También Desarrollo de servidor (Equipo de desarrollo), Desarrollo de cliente (Equipo de desarrollo)
Tareas (Equipo de desarrollo): Servidor: reducir las conexiones cortas (reutilizar conexiones en las llamadas entre servidores). Cliente: si la conexión falla o se corta, reintentar con intervalos crecientes y repartidos al azar.
Tareas (Equipo de infraestructura): Aumentar el tamaño de la tabla (nf_conntrack_max), excluir del seguimiento los puertos del juego (NOTRACK en la tabla raw), alertar sobre el uso.
Cifras de referencia: El límite predeterminado va de unas 60,000 a unas 260,000 entradas según la memoria del servidor. Si se desborda, en el log del kernel aparece “nf_conntrack: table full, dropping packet”.
En el gráfico: Topa con el límite · Entradas de conntrack (nf_conntrack_count)
Dónde mirar: net.netfilter.nf_conntrack_count (entradas actuales) de sysctl en el mismo gráfico que nf_conntrack_max; buscar “nf_conntrack: table full, dropping packet” en dmesg
Se confirma si: nf_conntrack_count se aplana en el máximo y, desde ese momento, aparece table full en el log del kernel
Se descarta si: Si las entradas quedan muy por debajo del máximo, no es esta causa. El límite de seguimiento de conexiones de la propia instancia de AWS se mira con conntrack_allowance_exceeded (ver “Límite de PPS de la nube superado”)
Se verifica con: Con herramientas de infraestructura (no hace falta código del juego)

Fuentes

Netfilter Conntrack Sysfs variables Linux kernel
El valor predeterminado de nf_conntrack_max es igual al número de buckets del hash (nf_conntrack_buckets), que depende del tamaño de la memoria
net/netfilter/nf_conntrack_core.c (Linux v6.12) Linux kernel
Tamaño predeterminado: 65,536 con más de 1 GB de memoria y 262,144 con más de 4 GB (64 bits); al llenarse, registra “nf_conntrack: table full, dropping packet” y descarta
iptables-extensions(8) — Linux manual page netfilter
Excluir del seguimiento de conexiones con CT --notrack en la tabla raw

Ver también

Misma capa: L7 SO del servidor (kernel)

Causas de otras capas con el mismo síntoma (No conecta / carga infinita)

Inspección de paquetes del software de seguridad L2 SO y dispositivo del cliente
Router poco potente o sobrecalentado L3 Red doméstica
Restricciones en Wi-Fi público y redes corporativas L3 Red doméstica
Restricciones de UDP e inspección de paquetes por país o ISP L4 Ruta por internet
Fallos y lentitud del DNS L4 Ruta por internet
Enlaces compartidos saturados por un DDoS L4 Ruta por internet
IP compartida del ISP (CGNAT) L4 Ruta por internet
Paso por una VPN o un acelerador de juegos L4 Ruta por internet

Ver la ficha interactiva con gráficos y simulaciones