Problemas de MTU: la causa oculta de «algunos sitios no cargan»

El modelo mental: por qué MTU rompe «solo cierto» tráfico

MTU (Maximum Transmission Unit) es el tamaño máximo de paquete IP que puede atravesar un enlace sin fragmentarse. El MTU por defecto en Ethernet es 1500 bytes. Ese número es antiguo, práctico y sigue estando por todas partes. El problema es que las redes modernas son una pila de túneles, overlays, VPN y middleboxes «útiles». Cada capa resta bytes para sus cabeceras. Si no presupuestas esa sobrecarga, paquetes que antes cabían dejan de caber.

Cuando un paquete es demasiado grande para el siguiente salto, hay solo unos pocos resultados:

• Ocurre fragmentación (solo IPv4, si está permitida): el router divide el paquete. A menudo funciona, pero es más lento y frágil. Algunos dispositivos manejan mal los fragmentos. Algunas políticas de seguridad los descartan.
• El paquete se descarta y se envía un mensaje ICMP de vuelta: «Fragmentation needed» (IPv4) o «Packet Too Big» (IPv6). Este es el camino saludable para Path MTU Discovery.
• El paquete se descarta y no regresa ICMP útil: este es el infame agujero negro PMTUD. TCP sigue retransmitiendo paquetes grandes que nunca llegan. Desde la perspectiva de la aplicación, las cosas «se quedan colgadas».

¿Por qué afecta solo a algunos sitios? Porque no todos los flujos generan paquetes del mismo tamaño. Una respuesta HTTP pequeña puede caber. Un registro TLS más grande, una solicitud con muchas cookies, o un servidor que envía inmediatamente un segmento de tamaño completo puede exceder el MTU real del camino. Algunas CDNs y algunos sitios simplemente son mejores en disparar tu ruta rota que otros.

Un detalle más importante: TCP MSS (Maximum Segment Size) controla el tamaño de la carga útil TCP, que normalmente es MTU menos cabeceras IP+TCP. Si ajustas (clamp) correctamente el MSS en el borde del túnel, puedes evitar generar paquetes demasiado grandes desde el principio. Es un emplasto con usos médicos legítimos.

Verdad seca y graciosa: los bugs de MTU son el equivalente de red de una puerta que abre hacia adentro cuando el código de incendios exige que abra hacia afuera—solo lo descubres durante el pánico.

Lo que «algunos sitios no cargan» suele significar a nivel de paquetes

Secuencia típica de fallo:

1. El cliente resuelve DNS y se conecta a la IP del servidor: OK.
2. Handshake TCP de tres vías (SYN, SYN/ACK, ACK): OK (paquetes pequeños).
3. Comienza el handshake TLS: a menudo OK al principio.
4. El servidor envía un paquete más grande (cadena de certificados, cabeceras HTTP o contenido inicial): se descarta si excede el PMTU real y PMTUD está roto.
5. El cliente espera, reintenta, el navegador gira el selector y alguien culpa al proveedor SaaS.

Hechos e historia: cómo llegamos aquí

Los problemas de MTU parecen modernos porque los vemos más con VPN y overlays, pero los ingredientes son antiguos. Algunos hechos concretos y puntos históricos que importan operativamente:

1. MTU de Ethernet de 1500 bytes se volvió común porque equilibraba eficiencia y límites de hardware en los diseños tempranos de Ethernet; es efectivamente el «contrato por defecto» de mucho equipo.
2. PPPoE reduce famosamente el MTU a 1492 debido a su sobrecarga de encapsulación; esto ha afectado a DSL y algunas implementaciones de fibra durante décadas.
3. Path MTU Discovery (PMTUD) depende del feedback ICMP «too big»; cuando las redes comenzaron a bloquear ICMP de forma amplia por «seguridad», las fallas de PMTUD se volvieron rutinarias.
4. IPv6 prohíbe la fragmentación en la red; solo los extremos fragmentan. Eso hace que ICMPv6 «Packet Too Big» no sea opcional si quieres un internet que funcione.
5. IPsec, GRE, VXLAN y WireGuard añaden sobrecarga; un MTU seguro dentro de túneles suele ser más bajo de lo que la gente asume, especialmente con capas múltiples de encapsulación.
6. Jumbo frames (MTU 9000) son excelentes dentro de dominios controlados, pero se convierten en un problema cuando se extienden accidentalmente a través de límites que no pueden soportarlos.
7. El clamp de TCP MSS se volvió una solución habitual en firewalls y routers de borde precisamente porque PMTUD era poco fiable en redes reales.
8. «No bloquear ICMP» ha sido un consejo estándar por años, pero muchas redes corporativas todavía lo hacen parcialmente—a menudo permiten echo pero bloquean «fragmentation needed», que es la mitad equivocada.
9. El comportamiento de los navegadores amplifica el dolor: los navegadores modernos abren muchas conexiones, usan HTTP/2 u HTTP/3, y pueden esconder bloqueos por conexión detrás de spinners que parecen fallos de la app.

Una cita que debería estar en el cerebro de todo equipo de operaciones: Everything fails, all the time. — Werner Vogels. Es breve, algo sombría y operativamente correcta.

Guía de diagnóstico rápido (primero/segundo/tercero)

Si tienes diez minutos y un usuario gritando «solo algunos sitios», haz esto en orden. No improvises. Improvisar es como terminar reiniciando el router equivocado a las 2 a.m.

Primero: verifica que sea una falla con forma de MTU

• Reproduce desde un host en el mismo camino de red que el usuario (misma VPN, mismo VLAN, misma Wi-Fi).
• Comprueba si las respuestas pequeñas funcionan pero las más grandes se quedan; eso es un indicio.
• Usa un ping con «no fragmentar» para encontrar el tamaño máximo de paquete que funciona.

Segundo: localiza el límite donde cambia el MTU

• Busca túneles: VPN, IPsec, GRE, WireGuard, transit gateway en la nube, SD-WAN, overlays, optimizadores WAN.
• Compara los MTU de las interfaces en ambos lados: NIC del cliente, interfaz de túnel, firewall inside/outside, ENI en la nube.
• Confirma que ICMP «too big» esté permitido de extremo a extremo (o compensa con clamp de MSS).

Tercero: aplica la corrección menos peligrosa

• Prefiere corregir MTU/PMTUD y permitir el ICMP requerido.
• Si la política o el equipo del proveedor lo bloquea, aplica el clamp de TCP MSS en el borde del túnel como solución pragmática.
• Documenta el MTU elegido e incorpóralo en la provisión, no en la memoria tribal.

Segundo chiste corto (y el último, según las leyes de este documento): La forma más fácil de encontrar un bug de MTU es declarar el incidente «probablemente DNS». Inmediatamente se convertirá en MTU por despecho.

Patrones de síntoma que gritan MTU

1) El handshake TLS se atasca o «cuelga» después del ClientHello/ServerHello

Los paquetes pequeños pasan. Luego una cadena de certificados o un mensaje de handshake más grande dispara un paquete demasiado grande. Si ICMP está bloqueado, ningún extremo aprende el MTU del camino, así que sigue enviando paquetes que nunca llegan.

2) Llegan cabeceras HTTP, pero descargas grandes fallan pronto

La primera respuesta cabe. Segmentos mayores no. Los usuarios informan «la página carga pero las imágenes no», o «iniciar sesión funciona pero el panel no».

3) Funciona con hotspot móvil, falla en Wi‑Fi/VPN corporativa

Camino diferente, MTU diferente, política ICMP diferente. Los operadores móviles también tienen sus propias peculiaridades de MTU, pero el camino es lo bastante distinto para evitar tu agujero negro.

4) SSH conecta, pero scp se queda atascado

Las pulsaciones interactivas son pequeñísimas. Las transferencias de archivos llenan segmentos TCP, exponiendo problemas de MTU rápidamente.

5) IPv4 funciona, IPv6 no (o viceversa)

IPv6 requiere ICMPv6 PTB para funcionar bien. Si un firewall lo bloquea, obtienes miseria selectiva en IPv6. A la inversa, algunas rutas IPv4 «funcionan» mediante fragmentación mientras IPv6 falla contundentemente.

6) Kubernetes/contenerización: pod→externo inestable, nodo→externo bien

Las redes overlay (VXLAN, Geneve) reducen el MTU efectivo dentro del clúster. Si el MTU del CNI es incorrecto, los pods generan paquetes que se descartan en el egress.

Tareas prácticas: comandos, salidas, decisiones (12+)

Estos son los comandos que realmente ejecuto cuando estoy de guardia y cansado. Cada tarea incluye: comando, salida de ejemplo, qué significa y la decisión que tomas.

Task 1: Check the local interface MTU

cr0x@server:~$ ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff

Significado: El host cree que eth0 tiene MTU 1500. Eso es solo el primer salto, no la ruta completa.

Decisión: Si esperas un túnel/overlay, comprueba esa interfaz también. No asumas que 1500 es seguro de extremo a extremo.

Task 2: List tunnel interfaces and their MTU

cr0x@server:~$ ip -d link show | egrep -A2 'mtu|wg0|tun0|gre|vxlan'
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none
7: vxlan.calico: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN mode DEFAULT group default

Significado: WireGuard en 1420, VXLAN en 1450. La sobrecarga se está teniendo en cuenta, al menos localmente.

Decisión: Si los usuarios se quejan sobre la VPN, 1420 puede seguir siendo demasiado alto según el underlay. Verifícalo con pings DF.

Task 3: DF ping to find maximum working MTU (IPv4)

cr0x@server:~$ ping -M do -s 1472 -c 3 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1492
ping: local error: message too long, mtu=1492
ping: local error: message too long, mtu=1492

--- 1.1.1.1 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

Significado: Intentaste enviar un paquete IP de 1500 bytes en total (1472 payload + 28 bytes de cabeceras). El kernel indica que el MTU efectivo es 1492 en algún punto relevante localmente (a menudo PPPoE).

Decisión: Reduce el payload hasta que pase. Luego ajusta el MTU del túnel o aplica clamp MSS según corresponda.

Task 4: Binary search the working payload size

cr0x@server:~$ ping -M do -s 1464 -c 2 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1464(1492) bytes of data.
1472 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=13.4 ms
1472 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=13.2 ms

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms

Significado: La ruta soporta paquetes IP de 1492 bytes (payload 1464 + 28 de cabecera).

Decisión: Si ejecutas una VPN sobre este enlace, resta la sobrecarga del túnel a 1492, no a 1500.

Task 5: Check PMTUD ICMP messages in packet capture

cr0x@server:~$ sudo tcpdump -ni eth0 'icmp and (icmp[0]=3 and icmp[1]=4)'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:01:44.912345 IP 203.0.113.1 > 192.0.2.10: ICMP unreachable - need to frag (mtu 1420), length 36

Significado: Estás recibiendo «need to frag» con una pista de MTU. PMTUD está al menos parcialmente funcionando.

Decisión: Si nunca ves estos cuando los esperas, sospecha reglas de firewall que descarten ICMP tipo 3 código 4 (IPv4) o ICMPv6 PTB.

Task 6: See if ICMP is blocked on your firewall (nftables)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    ip protocol icmp icmp type echo-request accept
    ip6 nexthdr icmpv6 icmpv6 type echo-request accept
  }
}

Significado: Se permiten las echo requests, pero no otros tipos de ICMP. Ese es el clásico escenario de «ping funciona, PMTUD muere».

Decisión: Permite ICMP «fragmentation needed» (IPv4) y «packet too big» (IPv6) como mínimo; idealmente permite los tipos de error ICMP relevantes ampliamente.

Task 7: Confirm TCP MSS advertised on SYN packets

cr0x@server:~$ sudo tcpdump -ni eth0 'tcp[tcpflags] & (tcp-syn) != 0 and host 93.184.216.34' -c 3
12:05:01.100001 IP 192.0.2.10.51544 > 93.184.216.34.443: Flags [S], seq 1234567890, win 64240, options [mss 1460,sackOK,TS val 111 ecr 0,nop,wscale 7], length 0
12:05:01.200002 IP 192.0.2.10.51545 > 93.184.216.34.443: Flags [S], seq 1234567891, win 64240, options [mss 1460,sackOK,TS val 112 ecr 0,nop,wscale 7], length 0
12:05:01.300003 IP 192.0.2.10.51546 > 93.184.216.34.443: Flags [S], seq 1234567892, win 64240, options [mss 1460,sackOK,TS val 113 ecr 0,nop,wscale 7], length 0

Significado: MSS 1460 implica una suposición de MTU 1500 (1460 payload + 40 bytes cabeceras IPv4+TCP).

Decisión: Si tu MTU real de ruta es 1492 o menor (o el túnel lo reduce), deberías clavar el MSS más bajo en el borde para que los endpoints no envíen segmentos sobredimensionados.

Task 8: Apply MSS clamping (iptables) as a workaround

cr0x@server:~$ sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
cr0x@server:~$ sudo iptables -t mangle -S FORWARD | tail -n 3
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Significado: Estás reescribiendo el MSS en paquetes SYN según el MTU de la ruta. Esto suele evitar agujeros negros incluso cuando ICMP está bloqueado.

Decisión: Usa esto cuando no puedas arreglar el filtrado de ICMP rápidamente. Aun así, agenda la corrección real: MTU y política ICMP correctas.

Task 9: Diagnose with tracepath (Linux)

cr0x@server:~$ tracepath 93.184.216.34
 1?: [LOCALHOST]                        pmtu 1500
 1:  192.0.2.1                           0.381ms
 2:  198.51.100.1                        1.992ms pmtu 1492
 3:  203.0.113.9                         6.110ms
 4:  93.184.216.34                      12.834ms reached
     Resume: pmtu 1492 hops 4 back 4

Significado: Path MTU descubierto como 1492 en el salto 2. Eso es valioso y accionable.

Decisión: Si tracepath no puede descubrir PMTU (se queda en 1500 sospechosamente), sospecha PTB/frag-needed de ICMP bloqueado o un problema de ruta asimétrica.

Task 10: Check the route MTU hint in Linux

cr0x@server:~$ ip route get 93.184.216.34
93.184.216.34 via 192.0.2.1 dev eth0 src 192.0.2.10 uid 1000
    cache mtu 1492

Significado: La caché de rutas del kernel cree que el PMTU es 1492 para ese destino.

Decisión: Si las aplicaciones aún se quedan colgadas, el problema podría estar en otro sitio (inspección TLS, proxy) o el PMTU difiere para otros destinos/rutas.

Task 11: Validate IPv6 PMTUD basics

cr0x@server:~$ ping6 -c 2 -s 1452 -M do 2606:4700:4700::1111
PING 2606:4700:4700::1111(2606:4700:4700::1111) 1452 data bytes
1460 bytes from 2606:4700:4700::1111: icmp_seq=1 ttl=57 time=14.1 ms
1460 bytes from 2606:4700:4700::1111: icmp_seq=2 ttl=57 time=14.0 ms

--- 2606:4700:4700::1111 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Significado: Paquetes IPv6 relativamente grandes pasan con semántica DF (IPv6 no hace fragmentación por enrutador). Buena señal.

Decisión: Si IPv6 falla solo para tamaños mayores, comprueba el filtrado de ICMPv6 tipo 2 (Packet Too Big) en los firewalls.

Task 12: Identify container/CNI MTU mismatch (Kubernetes node)

cr0x@server:~$ ip link show dev cni0
9: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether 0a:58:0a:f4:00:01 brd ff:ff:ff:ff:ff:ff
cr0x@server:~$ ip link show dev vxlan.calico
7: vxlan.calico: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN mode DEFAULT group default

Significado: El bridge está en 1500 pero VXLAN en 1450. Los pods podrían intentar usar 1500 y sufrir una vez encapsulados.

Decisión: Ajusta el MTU del CNI/bridge para que coincida con el MTU efectivo del overlay (a menudo 1450) para que los pods nunca generen tramas demasiado grandes.

Task 13: Confirm whether PMTUD is black-holed by testing a big TCP transfer

cr0x@server:~$ curl -I --max-time 10 https://example.com/
HTTP/2 200
content-type: text/html
server: envoy

cr0x@server:~$ curl --max-time 10 -o /dev/null -sS https://example.com/largefile.bin
curl: (28) Operation timed out after 10002 milliseconds with 0 bytes received

Significado: Una petición pequeña funciona; la transferencia grande se atasca. No es prueba definitiva, pero es una señal fuerte de MTU/fragmentación.

Decisión: Ejecuta inmediatamente pings DF / tracepath e inspecciona el filtrado ICMP. No pierdas una hora en teorías de cifrados TLS.

Task 14: Observe retransmissions and “stuck” large segments

cr0x@server:~$ sudo ss -ti dst 93.184.216.34:443 | sed -n '1,20p'
ESTAB 0 0 192.0.2.10:51544 93.184.216.34:443
	 cubic wscale:7,7 rto:204 rtt:52.3/1.2 ato:40 mss:1460 pmtu:1500 rcvmss:536 advmss:1460 cwnd:10 bytes_acked:3456 bytes_received:1200 segs_out:45 segs_in:38 retrans:8/12

Significado: Están ocurriendo retransmisiones. MSS es 1460, PMTU parece 1500, pero pruebas previas sugerían un MTU de ruta menor—algo está inconsistente.

Decisión: Sospecha que este host no recibe ICMP «too big» (o filtrado asimétrico). Implementa clamp MSS y corrige la política ICMP.

Tres micro-historias corporativas desde el campo

Micro-historia 1: El incidente causado por una suposición errónea

La compañía tenía una arquitectura híbrida: oficinas on‑prem, una VPC en la nube y un túnel IPsec «simple» entre ellas. Todos asumían que el túnel era una tubería muda. Se instaló años atrás, «funcionaba» y no era el tema favorito de nadie.

Luego se lanzó una nueva app interna detrás de un reverse proxy en la nube. Los usuarios de una oficina informaron que la página de login cargaba, pero tras introducir credenciales el navegador giraba sin fin. El equipo de la app no vio errores. Las métricas del load balancer en la nube parecían bien. Soporte intentó el ritual clásico: limpiar caché, probar otro navegador, reiniciar el portátil. Nada consistente.

Un SRE finalmente lo reprodujo conectándose desde esa red de oficina específica. El handshake TCP tuvo éxito. TLS empezó. Luego la respuesta murió en mitad del vuelo. El detalle clave: esa oficina había cambiado recientemente a un nuevo ISP usando PPPoE. Su firewall de borde aún suponía 1500, y la sobrecarga de IPsec empujó los paquetes más allá del MTU real del camino.

La suposición errónea fue simple: «Ethernet es 1500, así que la ruta es 1500». La solución también fue simple: ajustar el MTU del túnel y permitir los tipos de ICMP correctos. Un clamp MSS temporal estabilizó las cosas de inmediato. En el postmortem la acción fue aburrida pero esencial: documentar el presupuesto efectivo de MTU por enlace y por túnel, y validarlo durante cambios de proveedor.

Micro-historia 2: La optimización que salió mal

Un equipo distinto decidió «optimizar el rendimiento» en su data center habilitando jumbo frames end‑to‑end. Tenían tráfico de almacenamiento, vMotion, backups, lo habitual. En papel parecía limpio: menos paquetes, menos interrupciones, mayor throughput. El equipo de red lo desplegó gradualmente y parecía funcionar—dentro del data center.

Entonces vino un cambio inocuo: un nuevo par de firewalls en el borde, configurado también para jumbo frames en interfaces internas. La suposición era que a más grande mejor y que todo interno lo soportaba. Excepto un segmento: un appliance de load balancer antiguo en un rack remoto que nunca recibió el memo y seguía en 1500.

La mayoría de servicios no lo notaron. Esa es la trampa de los bugs de MTU: el tráfico de control pequeño funcionaba. Las health checks eran diminutas. El load balancer pasó algunas peticiones. Pero respuestas grandes y algunos registros TLS se esfumaron en el abismo. El patrón de la caída era surrealista: «El sitio me funciona a menos que clickee la pestaña de reportes».

La optimización que salió mal no fueron los jumbo frames en sí. Fue la creencia de que puedes cambiar el MTU como si fuera un ajuste cosmético. No puedes. MTU es un contrato y no puedes renegociarlo unilateralmente. Lo arreglaron haciendo cumplir la consistencia de MTU por dominio L2, añadiendo chequeos automatizados y negándose a mezclar 1500 y 9000 sin un gateway deliberado.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Una fintech tenía varios concentradores VPN para empleados remotos. Nada exótico: split tunnel para algunos servicios, túnel completo para otros. Tenían una regla de change management dolorosamente conservadora: cualquier nuevo perfil de túnel debe incluir una prueba de MTU y una regla de clamp MSS «conocida‑buena» almacenada, aunque no se habilitara por defecto.

Durante una caída de proveedor, conmutaron un endpoint VPN a una ruta de respaldo. De repente, un pequeño porcentaje de usuarios no pudo acceder a un par de apps SaaS. La mayoría estaba bien. Los tickets de helpdesk fueron confusos y contradictorios porque así son las fallas selectivas.

El SRE de guardia sacó el runbook, ejecutó los pings DF desde un host de prueba detrás de la ruta de failover y confirmó que el MTU efectivo había bajado. Activaron el clamp MSS preaprobado para ese perfil VPN y cerraron el incidente rápido, sin debatir política de firewalls en plena crisis.

Después igualmente hicieron la «solución real» (alineación de políticas ICMP y ajustes correctos de MTU), pero la práctica aburrida—tener una solución probada y lista para habilitar—convirtió una misteriosa noche en un incidente corto con una línea temporal clara.

Errores comunes: síntoma → causa raíz → corrección

1) «Ping funciona, así que la red está bien» → Se permite ICMP echo, PMTUD ICMP bloqueado → permitir los tipos ICMP correctos

Síntoma: ping tiene éxito, pero HTTPS se atasca o las descargas grandes fallan.

Causa raíz: Firewall permite echo-request/reply pero descarta ICMP «fragmentation needed» (IPv4 tipo 3 código 4) y/o ICMPv6 Packet Too Big.

Corrección: Permitir los ICMP relacionados con PMTUD. Si no puedes, clampa TCP MSS en el borde.

2) «La VPN está arriba, por tanto puede transportar tráfico normal» → sobrecarga del túnel no presupuestada → reducir MTU del túnel y/o clamp MSS

Síntoma: SSH funciona, scp se detiene; algunas apps web cargan parcialmente.

Causa raíz: Sobrecarga de IPsec/GRE/WireGuard reduce el MTU efectivo. Los endpoints siguen enviando MSS basados en 1500.

Corrección: Establecer MTU seguro para el túnel (comúnmente 1380–1420 según la pila) y validar con pings DF. Añadir clamp MSS si es necesario.

3) «Habilitamos jumbo frames, nada explotó al instante» → MTU mixtos en un dominio L2 → hacer cumplir MTU consistente por segmento

Síntoma: fallos intermitentes, a menudo dependientes del tamaño; monitorización mayormente en verde.

Causa raíz: Algunos enlaces/dispositivos en 9000, otros en 1500; aparecen agujeros negros en los límites.

Corrección: Estandarizar MTU por VLAN/L2. Donde debas interconectar, enruta entre dominios y clampa/fragmenta apropiadamente.

4) «Es un bug de la aplicación» → TCP retransmite, navegador espera → probarlo con tests de tamaño de paquete

Síntoma: solo fallan ciertas páginas o proveedores SaaS; los ingenieros discuten en Slack.

Causa raíz: Segmentos grandes descartados por fallo de PMTUD; la aplicación solo experimenta un bloqueo.

Corrección: Ejecutar tracepath y pings DF; capturar ICMP PTB/frag-needed; arreglar ICMP o clamar MSS.

5) «IPv6 es opcional» → ICMPv6 PTB bloqueado → arreglar la política de firewall para IPv6

Síntoma: conexiones IPv6 se quedan colgadas para algunos sitios; el fallback a IPv4 a veces lo oculta.

Causa raíz: Bloquear ICMPv6 rompe PMTUD; IPv6 depende de ello.

Corrección: Permitir mensajes de error ICMPv6 incluidos Packet Too Big; validar con ping6 -M do.

6) «Los contenedores son solo procesos» → MTU del CNI incorrecto para el overlay → ajustar MTU de pod/bridge a valor seguro para el underlay

Síntoma: el nodo puede alcanzar sitios externos, los pods no (o son inestables).

Causa raíz: El overlay añade encapsulación; si los pods usan 1500 exceden el MTU del underlay tras encapsular.

Corrección: Configurar el MTU del CNI (a menudo 1450 para VXLAN sobre underlay 1500, pero validar). Desplegarlo con cuidado; afecta a la red de pods.

Listas de verificación / plan paso a paso

Checklist de incidente: cuando «algunos sitios no cargan» afecta producción

1. Reproducir en‑camino: prueba desde el mismo segmento de red/VPN que los usuarios afectados.
2. Ejecutar sizing con ping DF: determina el tamaño máximo de paquete que funciona hacia una IP externa estable.
3. Ejecutar tracepath: verifica si PMTU se descubre y dónde cae.
4. Comprobar política ICMP del firewall: confirma que frag-needed/PTB estén permitidos, no solo echo.
5. Comprobar MTU de túnel/overlay: compara MTU de la NIC física, del túnel y de interfaces virtuales.
6. Buscar retransmisiones: usa ss -ti y tcpdump para confirmar segmentos grandes repetidos y ausencia de ICMP.
7. Aplicar solución segura: clamp MSS en el borde apropiado si necesitas alivio inmediato.
8. Verificar con una transferencia grande: curl un objeto grande, scp un archivo o visita un sitio conocido problemático.
9. Apuntar qué cambió: cambio de proveedor, nuevo firewall, nueva configuración CNI, nueva política SD‑WAN—los bugs MTU aman las ventanas de cambio.

Checklist de gestión de cambios: prevenir bugs MTU antes de que existan

1. Definir dominios MTU: por VLAN, por enlace WAN, por tipo de túnel. No mezcles 1500 y 9000 a la ligera.
2. Presupuestar la sobrecarga: documenta la sobrecarga de encapsulación para cada túnel/overlay en tu entorno.
3. Estandarizar MTU del CNI: configúralo explícitamente; no dejes que los valores por defecto difieran entre clusters.
4. Revisión de política ICMP: permite los tipos ICMP relacionados con PMTUD. Trátalos como tráfico de fiabilidad, no como «ruido».
5. Tener un plan probado de clamp MSS: saber dónde aplicarlo y cómo revertirlo.
6. Automatizar la verificación: ejecutar DF ping/tracepath programados desde segmentos clave y alertar sobre cambios en PMTU.
7. Documentar valores «conocidos buenos»: guarda MTU/MSS en infraestructura como código y en runbooks.

Tabla de decisiones: qué arreglar y en qué orden

• Si ICMP PTB/frag-needed está bloqueado: arregla la política del firewall primero; clamp MSS como medida temporal.
• Si el MTU del túnel está por encima del presupuesto del underlay: baja el MTU del túnel; luego retesta. No te fíes solo del clamp MSS salvo que sea necesario.
• Si hay jumbo frames: verifica que cada salto lo soporte. Si no puedes garantizarlo, mantiene los jumbo frames dentro de una zona controlada y enruta en el límite.
• Si solo fallan pods: corrige la configuración MTU del CNI/overlay; no lo «resuelvas» con sysctls aleatorios en los nodos.

Preguntas frecuentes

1) ¿Por qué solo fallan algunos sitios y no todo?

Porque solo ciertos flujos generan paquetes lo bastante grandes para exceder tu MTU real de ruta. Las solicitudes pequeñas funcionan; los registros TLS grandes, cabeceras o respuestas voluminosas no.

2) Si PMTUD existe, ¿por qué sigue siendo un problema?

PMTUD requiere feedback ICMP. Muchas redes bloquean exactamente los mensajes ICMP que PMTUD necesita, creando agujeros negros. El mecanismo está bien; la realidad operativa es desordenada.

3) ¿Bloquear ICMP realmente es «más seguro»?

No en ningún sentido útil moderno. Bloquear selectivamente ICMP rompe diagnósticos y funciones fundamentales (especialmente en IPv6). Buena seguridad es filtrado stateful y privilegio mínimo, no sabotear el plano de control.

4) ¿Debería simplemente clamar TCP MSS en todas partes y olvidarme?

No. El clamp de MSS es una solución válida en bordes de túneles y bordes de red, pero clamar a lo loco puede ocultar problemas subyacentes y reducir rendimiento innecesariamente. Arregla primero ICMP y la corrección del MTU; clampa donde esté justificado.

5) ¿Qué MTU debo poner para WireGuard?

No hay un número universal. 1420 es común porque suele funcionar sobre underlays 1500 típicos, pero PPPoE, túneles adicionales o peculiaridades del proveedor pueden requerir menos. Mide con pings DF y ajusta.

6) ¿Cómo afecta esto a HTTP/3 y QUIC?

QUIC corre sobre UDP y aún depende del MTU de ruta. El comportamiento de fragmentación difiere, pero el problema central persiste: los paquetes sobredimensionados se descartan. Las pilas QUIC suelen usar lógica tipo PMTUD también, y el filtrado ICMP puede seguir doliendo.

7) Mi ISP dice que su MTU es 1500. ¿Por qué tracepath muestra 1492?

Porque algún tramo de tu ruta (a menudo PPPoE u otra encapsulación) reduce el MTU efectivo. La afirmación «ISP MTU» suele referirse a un segmento, no a tu camino extremo a extremo.

8) ¿Los problemas de MTU pueden parecer problemas de DNS?

Sí, indirectamente. Si las respuestas DNS son grandes (DNSSEC, muchos registros) y la ruta maneja mal la fragmentación o bloquea ICMP, DNS sobre UDP puede fallar selectivamente. Pero «algunos sitios no cargan» suele ser más a menudo dolor de MTU en TCP/TLS.

9) ¿Cuál es la mitigación inmediata más segura durante un incidente?

Habilita el clamp MSS en el dispositivo de borde que enruta tráfico hacia el túnel/ruta problemática y luego valida con transferencias grandes. Tras apagar el fuego, arregla la política ICMP y los ajustes de MTU.

10) ¿Cómo puedo demostrar que es MTU ante un equipo escéptico?

Muestra un antes/después: tamaño máximo con ping DF, un tracepath que muestre la caída de PMTU y una captura de paquetes donde grandes segmentos se retransmiten sin recibir ICMP PTB. Luego aplica clamp MSS y demuestra que el problema desaparece.

Siguientes pasos que realmente puedes hacer

Los problemas de MTU no son glamorosos. Ni siquiera son interesantes de la forma divertida. Son interesantes en el sentido de «por qué el portátil del CEO es el único que no puede cargar la nómina».

Haz lo siguiente, en este orden:

1. Añade chequeos MTU/PMTU a tu memoria muscular de incidentes: ping DF y tracepath deberían ser tan rutinarios como comprobar DNS.
2. Corrige la política ICMP deliberadamente: permite ICMP relacionados con PMTUD (frag-needed en IPv4, packet-too-big en IPv6). Deja de celebrar «ping funciona» como prueba de nada.
3. Inventaria túneles y overlays: lista dónde se añade sobrecarga y fija MTUs explícitos allí. Los valores por defecto no son una estrategia.
4. Mantén listo el clamp MSS: trátalo como un extintor: probado, ubicado en el borde y usado cuando hace falta.
5. Documenta los dominios MTU: especialmente si usas jumbo frames. Haz los límites de MTU mixtos explícitos y enrutados, no accidentales.

Si tu organización escucha «algunos sitios no cargan» y de inmediato empieza a discutir sobre navegadores, no necesitas mejores navegadores. Necesitas mejor higiene de MTU.