Agujero negro de MTU (solo los paquetes grandes se pierden una y otra vez) PMTU black hole
ID de la causa rt-mtu · Responsable principal Infraestructura de red (Equipo de infraestructura) · También Infraestructura de servidores (Equipo de infraestructura), Desarrollo de servidor (Equipo de desarrollo)
Si un tramo intermedio pasa a aceptar paquetes más pequeños y el aviso de “demasiado grande” (ICMP) está bloqueado, los paquetes grandes siguen desapareciendo por muchas veces que se reenvíen.
Por qué El tamaño máximo se reduce en un tramo con VPN o túnel, y un firewall bloquea los avisos de tamaño excedido → Efecto El emisor, sin saber por qué, retransmite una y otra vez el mismo paquete grande, y el RTO se duplica cada vez → En pantalla Todo va bien normalmente, pero en cuanto se mueven datos grandes (inventario, zonas con mucha gente, carga al entrar) se detiene todo, incluidos los paquetes pequeños que vienen detrás (congelamiento); al final, desconexión o carga infinita
Al hacer ciertas acciones, Al conectar o tras un mantenimiento
Responsable
Responsable principal Infraestructura de red (Equipo de infraestructura) · También Infraestructura de servidores (Equipo de infraestructura), Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Para bajarlo directamente desde el servidor, configurar en el socket el tamaño máximo de segmento (TCP_MAXSEG); partir los mensajes en trozos más pequeños en el código del juego no basta para evitarlo (TCP vuelve a agrupar los datos en bloques del tamaño del MSS).
Tareas (Equipo de infraestructura)
Red: aplicar ajuste de MSS (clamping) en los dispositivos de borde, permitir el ICMP de tamaño excedido (tipo 3 código 4, fragmentation needed) en los firewalls y las ACL de red en la nube. Servidores/SO: configurar la MTU de la ruta, comprobar que el ICMP de tamaño excedido tampoco quede bloqueado en los firewalls de los servidores ni en los grupos de seguridad en la nube y, como última red de seguridad, poner tcp_mtu_probing=1 en Linux.
Cifras de referencia
Normalmente 1,500 bytes; al pasar por un túnel, unos 1,400. Si el mismo paquete se retransmite 5–6 veces, la pausa supera los 10 segundos.
En el gráfico
Alto solo en algunos · RTO y backoff por conexión, desconexiones por región/ISP
Dónde mirar
Retransmisiones de la conexión afectada con una captura de paquetes en el servidor o con bcc tcpretrans -s (muestra el número de secuencia), y mss, pmtu y backoff de esa conexión con ss -ti. Desde el servidor, enviar a la dirección del jugador un ping pequeño y otro de 1,500 bytes con DF activado (ping -M do -s 1472) y comparar
Se confirma si
Los paquetes llenos hasta el MSS se retransmiten una y otra vez con el mismo número de secuencia, duplicando el intervalo cada vez, mientras que los paquetes más pequeños sí pasan. No llega el ICMP de tamaño excedido (filtro de Wireshark icmp.type == 3 and icmp.code == 4), y el ping pequeño responde, pero el ping grande con DF desaparece sin respuesta
Se descarta si
Si también desaparecen los paquetes pequeños, es una pérdida que no depende del tamaño (“Desbordamiento de la cola en el cuello de botella (pérdida por congestión)”, “Cambio de ruta o ruta ECMP defectuosa”). Si llega el ICMP de tamaño excedido y baja el pmtu de ss -ti, el descubrimiento de la MTU de la ruta funciona bien
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
Con tcp_mtu_probing=1, Linux solo da por hecho que hay un agujero negro después de varios segundos de timeouts de retransmisión (lo que equivale a tcp_retries1=3), y entonces baja el MSS a 1,024 bytes. Mientras tanto la conexión se queda parada, así que esta opción es la última red de seguridad; lo primero es el ajuste de MSS, que evita el problema de antemano.
Fuentes
RFC 1191: Path MTU discoveryIETF Descubrimiento de la MTU de la ruta: los paquetes demasiado grandes se notifican con el ICMP “fragmentation needed and DF set” (tipo 3 código 4)
IP SysctlLinux kernel tcp_mtu_probing: 0 desactivado, 1 solo cuando se detecta un agujero negro, 2 siempre (el MSS inicial es tcp_base_mss). tcp_retries1: 3 por defecto
net/ipv4/tcp_timer.cLinux kernel Si las retransmisiones por RTO se repiten tcp_retries1 veces, se considera detectado un agujero negro y se activa el sondeo de MTU para bajar el MSS
iptables-extensions(8) — Linux manual pagenetfilter TCPMSS --clamp-mss-to-pmtu: evita, ajustando el MSS en el SYN, que los paquetes grandes se atasquen por tramos que bloquean el ICMP
tcp(7) — Linux manual pageLinux man-pages TCP_MAXSEG: tamaño máximo de segmento de los paquetes salientes; si se configura antes de conectar, también cambia el MSS que se anuncia al otro extremo
MTU considerations | Cloud VPNGoogle Cloud MTU de 1,460 bytes en el gateway de Cloud VPN y MTU de carga útil de 1,406 bytes en túneles IPv4 (al pasar por un túnel, unos 1,400)
ss(8) — Linux manual pageiproute2 mss, pmtu (MTU de la ruta) y backoff (veces que se ha duplicado el RTO) de ss -i
ping(8) — Linux manual pageiputils -M do activa DF y no envía paquetes mayores que la MTU de la ruta que conoce el kernel; -s es el tamaño de los datos (sin contar los 8 bytes de la cabecera ICMP)