Redes: Problemas de MTU que parecen ‘Internet lenta’ (Solución en 15 minutos)

MTU explicado en lenguaje llano (y por qué te engaña)

MTU es la Unidad Máxima de Transmisión: el tamaño máximo de paquete (en bytes) que un enlace llevará sin fragmentación.
En una red Ethernet típica, eso son 1500 bytes. Si usas PPPoE, suele ser 1492. Si vives el sueño de los jumbo frames, puede ser 9000.
Si enrutas dentro de un túnel dentro de otro túnel dentro de un overlay, resta la sobrecarga hasta que vuelvas a la realidad.

La trampa es que TCP no envía “paquetes”. Envía un flujo. El SO trocea ese flujo en segmentos, y la red los trocea en tramas.
Cuando la MTU es incorrecta, no ves un “error MTU”. Ves reintentos, bloqueos,
fallos asimétricos y timeouts que parecen congestión. A veces puedes cargar texto pero no imágenes. A veces
la página de inicio de sesión carga pero la petición POST se queda colgada. A veces solo una dirección está rota porque solo un firewall
bloquea el mensaje ICMP que necesitabas.

Una falla de MTU limpia es obvia: los paquetes grandes nunca pasan. Pero en la práctica, las fallas de MTU a menudo se convierten en
“agujeros negros de PMTUD”, donde la red debería indicar al remitente que reduzca el tamaño del paquete (vía ICMP “Fragmentation Needed”),
pero algún equipo bloquea esos mensajes ICMP. El remitente sigue intentando paquetes grandes, se siguen descartando,
TCP retransmite y tu usuario sigue diciendo “lento”.

Una frase para tener en la cabeza mientras depuras: paraphrased idea — Richard Cook (investigador en seguridad/operaciones):
Los sistemas tienden a parecer bien hasta que de repente no lo están, porque el éxito oculta la complejidad que hace posible el fallo.
Los problemas de MTU son ese tipo de fallo: todo parece bien hasta que una carga cruza la línea invisible.

Chiste corto #1: Los bugs de MTU son como paquetes que “renuncian en silencio”: aparecen, hacen lo mínimo y luego desaparecen cuando el trabajo se pone serio.

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

Cuando tienes 15 minutos y un pager, necesitas una secuencia que reduzca rápidamente el radio de impacto. No “toques” primero.
No reinicies primero. Demuestra dónde falla.

Primero: confirma que depende del tamaño

• ¿El tráfico pequeño funciona de forma fiable (DNS, respuestas HTTP pequeñas, banner de SSH) mientras las transferencias grandes se quedan atascadas?
• ¿ping con DF (no fragmentar) falla a ciertos tamaños?
• ¿Ves retransmisiones TCP y conexiones “atascadas” durante subidas/descargas?

Segundo: identifica el segmento de la ruta que cambia la MTU

• VPN, GRE, IPsec, WireGuard, redes overlay, MPLS, PPPoE, gateways de tránsito en la nube, load balancers.
• Encuentra dónde ocurre la encapsulación. La sobrecarga reduce la MTU efectiva.
• Comprueba si un firewall bloquea ICMP tipo 3 código 4 (“fragmentation needed”). Eso es clásico.

Tercero: aplica la mitigación menos arriesgada

• Clamp de TCP MSS en el borde (parche temporal, a menudo seguro).
• Configura la MTU de la interfaz correctamente en los extremos del túnel (solución permanente si controlas ambos lados).
• Permite el ICMP correcto para PMTUD (solución permanente, pero coordina con los equipos de seguridad).

El objetivo no es “MTU perfecta”. El objetivo es “detener la hemorragia sin causar otro incidente”.

Datos interesantes y contexto histórico

• La MTU de 1500 de Ethernet se convirtió en el valor por defecto temprano, en parte por compensaciones de hardware y memoria en los 80 y 90.
• IPv4 permite que los routers fragmenten paquetes (a menos que DF esté puesto), pero la fragmentación tiene costes de rendimiento y fiabilidad, así que las pilas modernas la evitan.
• Los routers IPv6 no fragmentan en tránsito; el remitente debe usar PMTUD. Eso hace que ICMPv6 “Packet Too Big” sea crítico en operación.
• PPPoE suele usar MTU 1492 por su sobrecarga de encapsulación; esos “8 bytes que faltan” bastan para romper rutas si PMTUD está bloqueado.
• Jumbo frames (a menudo MTU 9000) pueden reducir la CPU y aumentar el rendimiento en LANs de confianza, pero un solo salto no jumbo puede crear fallos parciales extraños.
• Los agujeros negros de PMTUD se documentaron ampliamente en los 90 y 2000 cuando los firewalls empezaron a bloquear ICMP sin entender su propósito.
• TCP MSS no es MTU: MSS es tamaño de carga útil, MTU incluye cabeceras. La gente los confunde y “corrige” el número equivocado.
• Las pilas de encapsulación suman rápido: VXLAN/Geneve, más IPsec, más cabeceras del proveedor en la nube pueden restar cientos de bytes de la MTU efectiva.
• Los centros de datos estandarizaron en 1500 por una razón: la interoperabilidad supera al rendimiento teórico. La mayoría de los fallos nacen de “vamos a cambiar la MTU”.

Cómo se manifiesta el dolor de MTU en producción

Síntomas clásicos

• Algunos sitios web cargan, otros se quedan colgados (a menudo durante el handshake TLS o respuestas grandes).
• La VPN se conecta, pero recursos compartidos y llamadas API grandes se quedan estancadas.
• SSH interactivo funciona, pero scp es dolorosamente lento o se congela.
• Nodos de Kubernetes en Ready, pero la descarga de algunas imágenes de contenedor agota el tiempo.
• HTTP funciona, HTTPS es inestable (tamaños de records TLS, mensajes de handshake más grandes, o rutas diferentes vía CDN).
• Las pruebas de throughput muestran muchos retransmisores; la latencia parece aceptable.

Por qué es engañoso

Con problemas de MTU puedes tener latencia perfecta y buen rendimiento con paquetes pequeños. El monitoreo que comprueba
“ping funciona” marcará en verde. Tus verificaciones sintéticas pueden alcanzar un endpoint diminuto y declararlo sano.
Mientras tanto, usuarios reales intentan subir un PDF o extraer una capa de contenedor y reciben un timeout.

La forma más rápida de perderse es tratarlo como un problema genérico de “red lenta” y empezar a afinar el control de congestión TCP,
buffers o QoS. Las fallas de MTU no son un problema de optimización de throughput. Son un problema de corrección.

Tareas prácticas (comandos, qué significa la salida, qué decidir)

Estas son tareas aptas para producción que puedes ejecutar desde un host Linux. Usa un host de prueba en cada lado del posible
punto de ruptura (cliente y servidor, o dos pods, o dos VMs). La idea es medir, no adivinar.

Tarea 1: Comprueba la MTU de la interfaz y detecta desajustes obvios

cr0x@server:~$ ip -d link show
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
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

Significado: eth0 es 1500, wg0 es 1420 (elección común de WireGuard). Eso no es incorrecto por sí mismo.

Decisión: Si ves una interfaz de túnel con MTU mayor de lo que el underlay puede soportar, eso es sospechoso. Confirma con pings DF a continuación.

Tarea 2: Confirma el comportamiento de PMTUD con ping DF (IPv4)

cr0x@server:~$ ping -M do -s 1472 -c 3 203.0.113.10
PING 203.0.113.10 (203.0.113.10) 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

--- 203.0.113.10 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2044ms

Significado: Tu host ya sabe que la MTU saliente es 1492 en esa ruta/interfaz. Se negó a enviar paquetes de 1500 bytes.

Decisión: Si la aplicación espera 1500 pero la ruta es 1492, necesitas clamp de MSS o configurar correctamente la MTU en el borde del túnel/PPPoE.

Tarea 3: Búsqueda binaria del mayor tamaño de paquete que funciona

cr0x@server:~$ for s in 1472 1464 1452 1440 1432; do echo "size=$s"; ping -M do -s $s -c 1 203.0.113.10 | tail -n 2; done
size=1472
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
size=1464
1 packets transmitted, 1 received, 0% packet loss, time 0ms
size=1452
1 packets transmitted, 1 received, 0% packet loss, time 0ms
size=1440
1 packets transmitted, 1 received, 0% packet loss, time 0ms
size=1432
1 packets transmitted, 1 received, 0% packet loss, time 0ms

Significado: 1464 funciona, 1472 no. Eso sugiere una MTU efectiva de 1492 (porque 1464 + 28 bytes de cabeceras ICMP/IP ≈ 1492).

Decisión: Deja de discutir teoría. Ajusta MTU/MSS para coincidir con lo que realmente funciona.

Tarea 4: Comprueba la ruta MTU / caché PMTU

cr0x@server:~$ ip route get 203.0.113.10
203.0.113.10 via 198.51.100.1 dev ppp0 src 198.51.100.20 uid 1000
    cache mtu 1492

Significado: Linux tiene una PMTU en caché de 1492 para ese destino en ppp0.

Decisión: Si la PMTU es inesperadamente baja, busca dónde ocurre la encapsulación (PPPoE, VPN, overlay). Si la PMTU es alta pero los paquetes siguen atascándose, puede que ICMP esté bloqueado y la caché no se actualice.

Tarea 5: Busca retransmisiones y “atascos” en una conexión real

cr0x@server:~$ ss -ti dst 203.0.113.10:443
ESTAB 0 0 198.51.100.20:53124 203.0.113.10:443
	 cubic wscale:7,7 rto:204 rtt:38.5/4.2 ato:40 mss:1460 pmtu:1500 rcvmss:536 advmss:1460 cwnd:10 bytes_acked:1543 bytes_received:2010 segs_out:35 segs_in:33 retrans:7/18

Significado: Las retransmisiones son distintas de cero y están subiendo. pmtu:1500 puede ser incorrecto si hay un agujero negro. rcvmss:536 también sugiere rarezas en la ruta.

Decisión: Si las retransmisiones suben durante transferencias masivas mientras el tráfico pequeño está bien, sospecha de MTU/PMTUD. Pasa a capturas de paquetes o al clamp de MSS.

Tarea 6: Captura ICMP “fragmentation needed” (o su ausencia)

cr0x@server:~$ sudo tcpdump -ni any '(icmp and (icmp[0]=3 and icmp[1]=4)) or (icmp6 and ip6[40]=2)'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes

Significado: Para IPv4 estás viendo ICMP tipo 3 código 4. Para IPv6 observas ICMPv6 tipo 2 (Packet Too Big).

Decisión: Si reproduces el problema y no ves mensajes ICMP PTB/frag-needed en ningún lado, es posible que un firewall o middlebox los esté descartando. Si los ves, PMTUD funciona y debes centrarte en MTU/MSS local incorrectos.

Tarea 7: Reproduce con curl y observa si se queda en “upload completely sent off”

cr0x@server:~$ curl -v --max-time 10 -o /dev/null https://203.0.113.10/large-object
*   Trying 203.0.113.10:443...
* Connected to 203.0.113.10 (203.0.113.10) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
> GET /large-object HTTP/1.1
> Host: 203.0.113.10
> User-Agent: curl/8.5.0
> Accept: */*
* Operation timed out after 10001 milliseconds with 0 bytes received
* Closing connection 0
curl: (28) Operation timed out after 10001 milliseconds with 0 bytes received

Significado: La conexión TCP y el handshake TLS pueden tener éxito, luego la ruta de petición/respuesta se atasca en paquetes más grandes o en tamaños específicos de record.

Decisión: Confirma con ping DF y luego mitiga (clamp MSS o MTU correcto). No pierdas una hora “optimizando TLS”.

Tarea 8: Mide throughput real y pérdida con iperf3

cr0x@server:~$ iperf3 -c 203.0.113.10 -t 10 -i 1
Connecting to host 203.0.113.10, port 5201
[  5] local 198.51.100.20 port 45436 connected to 203.0.113.10 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  3.12 MBytes  26.2 Mbits/sec   28   61.5 KBytes
[  5]   1.00-2.00   sec  2.50 MBytes  21.0 Mbits/sec   31   52.3 KBytes
[  5]   2.00-3.00   sec  1.75 MBytes  14.7 Mbits/sec   44   43.1 KBytes
[  5]   3.00-4.00   sec  1.12 MBytes  9.40 Mbits/sec   56   32.8 KBytes
[  5]   4.00-5.00   sec  0.88 MBytes  7.38 Mbits/sec   61   26.9 KBytes
[  5]   0.00-10.00  sec  15.2 MBytes  12.8 Mbits/sec  472             sender
[  5]   0.00-10.00  sec  14.5 MBytes  12.1 Mbits/sec                  receiver

Significado: Las retransmisiones son altas y la ventana de congestión colapsa. Eso no es normal para una ruta estable.

Decisión: Si las retransmisiones se correlacionan con MSS/MTU grandes, aplica clamp MSS y vuelve a probar. Si la ruta es realmente ruidosa, ajustar MTU no te salvará.

Tarea 9: Comprueba offloads de NIC que confunden las capturas

cr0x@server:~$ ethtool -k eth0 | egrep 'tso|gso|gro|lro'
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off

Significado: Los offloads están habilitados. Es normal, pero puede hacer que tcpdump muestre “paquetes gigantes” que en realidad no se envían por el cable.

Decisión: No “arregles” la MTU basándote en una captura engañosa. Si necesitas tamaños de paquete limpios para depurar, desactiva temporalmente los offloads en un host de prueba.

Tarea 10: Desactiva temporalmente offloads en un host de prueba (para claridad)

cr0x@server:~$ sudo ethtool -K eth0 tso off gso off gro off

Significado: El kernel ya no coalescerá/segmentará de maneras que confundan tus herramientas de captura.

Decisión: Haz esto solo en una caja de pruebas o durante una ventana controlada. Los offloads pueden ser críticos para el rendimiento en hosts muy cargados.

Tarea 11: Verifica PMTUD en IPv6 (ICMPv6 Packet Too Big) no esté bloqueado

cr0x@server:~$ ping6 -c 2 -s 1452 -M do 2001:db8::10
PING 2001:db8::10(2001:db8::10) 1452 data bytes
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280

--- 2001:db8::10 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1023ms

Significado: Algo en la ruta (o local) está imponiendo una MTU de 1280 (el mínimo de IPv6). Eso existe, pero es un asesino de rendimiento si es inesperado.

Decisión: Si la PMTU de IPv6 se colapsa inesperadamente, encuentra el túnel/segmento que lo causa. No desactives IPv6 salvo que te gusten los incidentes recurrentes.

Tarea 12: Clamp de TCP MSS con iptables (mitigación rápida)

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

Significado: Para conexiones TCP reenviadas, los paquetes SYN se reescribirán para que los pares negocien un MSS que quepa en la PMTU descubierta.

Decisión: Usa esto en los bordes (gateways VPN, routers, firewalls) cuando no puedas arreglar rápidamente el bloqueo de ICMP o el desajuste de MTU. Luego programa la solución real.

Tarea 13: Clamp de TCP MSS con nftables (sistemas modernos)

cr0x@server:~$ sudo nft add table inet mangle
cr0x@server:~$ sudo nft 'add chain inet mangle forward { type filter hook forward priority mangle; policy accept; }'
cr0x@server:~$ sudo nft add rule inet mangle forward tcp flags syn tcp option maxseg size set rt mtu

Significado: Idea similar: ajustar MSS basado en la MTU de la ruta. La sintaxis varía por distro/kernel; prueba cuidadosamente.

Decisión: Prefiere un conjunto de reglas revisado y probado. No improvises nftables en producción a menos que también disfrutes de incidencias improvisadas.

Tarea 14: Configura MTU en una interfaz (permanente cuando es correcto)

cr0x@server:~$ sudo ip link set dev wg0 mtu 1380
cr0x@server:~$ ip link show wg0 | head -n 1
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1380 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000

Significado: Estás reduciendo la MTU del túnel para evitar exceder los límites del underlay tras la sobrecarga.

Decisión: Si controlas ambos extremos, esto suele ser la solución más limpia. Valida con pings DF a través del túnel y una transferencia real de aplicación.

Tarea 15: Comprueba contadores del kernel por fragmentación y estrés en reensamblado

cr0x@server:~$ netstat -s | egrep -i 'fragment|reassembl'
    0 fragments received ok
    0 fragments created
    12 packets reassembled ok
    3 packet reassembly failures

Significado: Los fallos de reensamblado pueden mostrar problemas de fragmentación en ruta o pérdida de paquetes interactuando con fragmentos.

Decisión: La fragmentación huele mal. Evítala configurando MTU/MSS correctos. Si ves fallos de reensamblado durante la ventana del incidente, MTU es un fuerte sospechoso.

Tarea 16: Valida MTU de extremo a extremo desde dentro de Kubernetes (realidad del overlay)

cr0x@server:~$ kubectl run -it --rm netdebug --image=busybox:1.36 -- sh
/ # ip link show eth0 | head -n 1
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP mode DEFAULT group default
/ # ping -M do -s 1422 -c 1 10.96.0.1
PING 10.96.0.1 (10.96.0.1): 1422 data bytes
1430 bytes from 10.96.0.1: seq=0 ttl=64 time=0.632 ms

--- 10.96.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss

Significado: La MTU del pod es 1450 (común en configuraciones VXLAN). Tu suposición “normal 1500” ya es falsa dentro del clúster.

Decisión: Si los pods hablan con servicios externos a través de túneles o gateways, cuenta con la sobrecarga adicional. Corrígelo en la configuración del CNI o con clamp MSS en el gateway.

Patrones de solución que funcionan (y por qué)

Patrón 1: Hacer que PMTUD funcione de nuevo (la solución adulta)

PMTUD existe para que los endpoints se adapten. Cuando funciona, obtienes tamaños máximos de paquete sin afinaciones manuales.
Cuando está roto, la gente empieza a codificar MTUs por todas partes como si fuera 1997.

La rotura típica es el filtrado de ICMP. Para IPv4, quieres que ICMP tipo 3 código 4 sea permitido de vuelta al remitente.
Para IPv6, ICMPv6 Packet Too Big es obligatorio para la operación básica. Bloquearlo no es “seguridad”. Es autolesión.

Qué hacer: permite los mensajes ICMP específicos, aplica rate‑limit sensato y registra descartes. Si tus herramientas de seguridad fuerzan
descartar ICMP de forma global, negocia una excepción con evidencia: capturas de paquete, retransmisiones y una prueba clara antes/después.

Patrón 2: Clamp de TCP MSS en los límites (la solución pragmática)

El clamp de MSS reescribe el SYN TCP para que ambos lados acuerden un tamaño de segmento menor. Es un workaround para rutas donde PMTUD
es poco fiable, a menudo por middleboxes que no controlas (alguna red de un socio, un carrier, un firewall empresarial de terceros).

También es tu “arreglo de 15 minutos” porque puedes aplicarlo en el borde sin tocar cada host.
Inconvenientes: solo ayuda a TCP, no a UDP. También puede ocultar el problema real el tiempo suficiente para que reaparezca tras el siguiente cambio de topología.

Patrón 3: Configurar la MTU correcta en túneles y overlays (la solución estructural)

Los túneles reducen la MTU efectiva porque añaden cabeceras. Si tu underlay es 1500 y tu túnel añade 60 bytes, la MTU del túnel
debe ser 1440 o menor si quieres evitar fragmentación/agujeros negros.

El valor correcto depende del tipo de encapsulación y opciones (la sobrecarga de IPsec ESP varía; WireGuard tiene una sobrecarga típica; VXLAN añade la suya).
No memorices números. Mide con ping DF a través del túnel y elige un valor con un margen de seguridad.

Patrón 4: Deja de tratar los jumbo frames como un rasgo de personalidad

Los jumbo frames pueden ser geniales en un dominio L2 controlado: redes de almacenamiento, HPC, ciertos patrones east‑west.
Pero los jumbo frames a través de infraestructuras mixtas es donde los sueños van a convertirse en reuniones del Change Advisory Board.

Si habilitas MTU 9000 en algunos switches y olvides un hypervisor vSwitch o una interfaz de firewall, has creado
un modo de fallo que parecerá “lentitud intermitente” para siempre. O haz jumbo frames de extremo a extremo en ese segmento,
o no lo hagas.

Chiste corto #2: Si habilitas jumbo frames sin un plan end‑to‑end, no “optimizaste la red”, solo inventaste un nuevo hobby para tu rotación de on‑call.

Tres mini-historias corporativas (anonimizadas, plausibles, técnicamente precisas)

Mini-historia 1: Incidente causado por una suposición equivocada

Una empresa SaaS mediana ejecutaba una configuración híbrida: usuarios de oficina en un circuito ISP gestionado, cargas en la nube pública.
Desplegaron un nuevo appliance “secure web gateway”. El plan era simple: enrutar el tráfico corporativo a través del appliance,
verificar que la navegación web funcionara y luego ampliar.

El primer día, el helpdesk recibió una mezcla rara de tickets. Algunos empleados dijeron “todo está lento”.
Otros dijeron “solo las subidas están rotas”. Algunos informaron que Slack iba bien, pero el CRM interno (detrás de una VPN)
seguía agotando el tiempo durante el login. Las gráficas de red parecían normales. La CPU del gateway normal. El vendor del appliance
sugirió subir buffers TCP. Clásico.

La suposición equivocada fue sutil: el equipo asumió que el appliance era un simple reenviador L3/L4, y por tanto “la MTU se mantiene en 1500”.
En realidad, el appliance establecía un túnel IPsec hacia un POP en la nube para inspección. Eso añadía sobrecarga. El appliance
seguía aceptando paquetes de 1500 bytes en la LAN, pero no podía reenviarlos sin fragmentarlos en el lado del túnel.
Y la ruta del túnel tenía ICMP frag‑needed filtrado por el borde del proveedor.

La solución no fue heroica. Reprodujeron el bloqueo con pings DF, vieron que la MTU efectiva era como 1410 cruzando la nueva ruta,
y aplicaron clamp MSS en el gateway para el tráfico saliente TCP. Inmediatamente, los logins del CRM dejaron de fallar. Luego planificaron la
solución real: ajustar la MTU del túnel y coordinar permisos ICMP con el proveedor.

La lección: “Ethernet es 1500” no es un hecho; es un valor por defecto. En cuanto haces túneles, encapsulaciones o atraviesas equipos de seguridad gestionados,
la MTU deja de ser una nota al pie y pasa a ser un parámetro de diseño.

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

Un equipo de plataforma de datos quería mayor throughput de replicación entre dos centros de datos. Transferían objetos grandes y veían presión de CPU
en hosts durante picos. Alguien propuso jumbo frames: subir MTU a 9000 en la VLAN de almacenamiento, reducir overhead por paquete y ganar.

Hicieron el cambio en los switches ToR y en los servidores de almacenamiento. Las pruebas iniciales en un par de hosts fueron geniales. El throughput mejoró.
La CPU bajó. Celebraron en silencio, porque las celebraciones ruidosas enfurecen a los dioses de redes.

Dos semanas después, otro equipo movió un cluster de hypervisores a esa misma VLAN. Su vSwitch quedó en MTU 1500.
Nada explotó inmediatamente. En su lugar, surgió un desastre: algunas VMs podían montar almacenamiento pero se congelaban intermitentemente durante lecturas grandes.
Las copias de seguridad empezaron a agotarse. Algunos clientes NFS se quedaban colgados al listar directorios con blobs de metadata grandes.

Como muchos paquetes pequeños seguían funcionando, la gente persiguió problemas fantasma: “tuning NFS”, “ZFS arc”, “bug de ESXi”, “tal vez el array está sobrecargado”.
Les llevó un ping DF directo desde una VM para revelar la verdad: la VM no podía pasar paquetes mayores a 1500, pero los servidores de almacenamiento emitían jumbo frames.
En algún punto intermedio, la fragmentación o los descartes ocurrían de forma inconsistente, dependiendo de la ruta y del comportamiento de offload.

La solución fue aburrida: o hacían jumbo frames realmente end‑to‑end (switches, hypervisors, vSwitches, NICs, puntos de almacenamiento),
o mantenían esa VLAN a 1500 y aceptaban algo más de CPU. Eligieron dividir: un segmento de almacenamiento dedicado e aislado con jumbo para hosts que lo soportaban,
y un segmento separado de MTU estándar para entornos mixtos.

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

Un fintech gestionaba docenas de VPN site‑to‑site con partners. Ya habían sufrido antes agujeros negros de PMTUD, así que tenían una política:
cada túnel nuevo debía incluir una prueba documentada de MTU efectiva y una regla MSS clamp explícita en el borde VPN, validada con una transferencia de aplicación.
No “creemos que está bien”. Evidencia.

Un viernes, un partner cambió su modelo de firewall. Sin aviso. De repente, las transferencias de archivos de liquidación empezaron a fallar intermitentemente.
El partner insistía en que no había cambiado nada “en la VPN”. Su monitorización decía que el túnel estaba up. Todos eran técnicamente correctos e inútiles operativamente.

El equipo del fintech tuvo dos ventajas. Primero, ya tenían clamp MSS en su borde, así que la mayor parte del tráfico TCP siguió funcionando.
Segundo, tenían un runbook estándar: pings DF en ambas direcciones, tcpdump para ICMP y una verificación rápida de MSS negociado en una sesión TCP de prueba.
En una hora tenían pruebas de que ICMP frag‑needed ya no volvía desde el lado del partner.

No necesitaron rediseñar la red durante el incidente. La solución temporal ya estaba en su sitio. Simplemente ajustaron ligeramente el clamp MSS
(basado en la MTU medida), restablecieron la fiabilidad de las transferencias y enviaron al partner un informe corto con captura de paquetes de respaldo.
El partner arregló luego su política de firewall para permitir el ICMP correcto, y el fintech revirtió la conservadurismo adicional.

La lección: controles aburridos—pruebas de MTU documentadas, clamp MSS por defecto en bordes VPN y comportamientos “conocidos buenos” capturados—convierten outages misteriosos en mantenimiento rutinario.

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

1) “Algunos sitios cargan, otros se quedan colgados” → agujero negro PMTUD → permitir ICMP / clamp MSS

Síntoma: Navegación inconsistente; páginas grandes cuelgan; las pequeñas funcionan.
Causa raíz: La PMTU es menor de lo asumido, y ICMP frag‑needed / packet‑too‑big está bloqueado.
Solución: Permitir los mensajes ICMP específicos en firewalls; como mitigación rápida, aplicar clamp TCP MSS en el gateway de egress.

2) “La VPN está arriba pero las transferencias de archivos se quedan” → no se tuvo en cuenta la sobrecarga del túnel → reducir MTU del túnel

Síntoma: Pings pequeños y RDP/SSH funcionan; SMB/NFS/HTTPS uploads se congelan.
Causa raíz: La sobrecarga de IPsec/WireGuard/GRE baja la MTU efectiva; los endpoints siguen intentando paquetes cercanos a 1500.
Solución: Ajustar la MTU de la interfaz de túnel a un valor medido seguro; aplicar clamp MSS en el gateway VPN.

3) “Pulls de imágenes en Kubernetes caducan” → MTU de overlay demasiado alta → arreglar MTU del CNI y consistencia en nodos

Síntoma: Los pods pueden resolver DNS y alcanzar endpoints pequeños, pero bajar capas grandes falla.
Causa raíz: MTU del CNI overlay desajustada con el underlay, o MTU mixtas entre nodos.
Solución: Configurar la MTU del CNI correctamente (ej., 1450/1440 dependiendo de la encapsulación); asegurar que nodos y vSwitches concuerden.

4) “Jumbo frames habilitados, congelamientos aleatorios” → no es end‑to‑end jumbo → o hacerlo universal o revertir

Síntoma: Solo algunos hosts/VMs tienen problemas; a menudo durante transferencias grandes; el monitoreo muestra “up”.
Causa raíz: Un salto sigue siendo 1500 (vSwitch, firewall, NIC, switch intermedio).
Solución: Valida MTU en cada salto; si no puedes garantizarlo, mantén el segmento en 1500.

5) “Las capturas muestran tramas gigantes” → artefactos de offload → desactivar offloads para depuración

Síntoma: tcpdump muestra paquetes gigantes que no deberían existir; las conclusiones se vuelven extrañas rápido.
Causa raíz: TSO/GSO/GRO hacen que las capturas parezcan paquetes sobredimensionados en el límite del host.
Solución: Desactiva temporalmente offloads en un host de prueba, o captura en un puerto mirror del switch en su lugar.

6) “La app UDP falla; TCP bien tras clamp MSS” → el clamp solo ayuda TCP → ajustar la app o bajar MTU

Síntoma: VoIP, gaming o protocolo UDP personalizado sigue fallando mientras las apps web se recuperan.
Causa raíz: El clamp MSS no aplica a UDP; datagramas UDP pueden exceder la PMTU y ser descartados.
Solución: Reducir tamaños de payload UDP en la app, habilitar fragmentación con cuidado (rara vez ideal), o bajar MTU en la interfaz/túnel.

7) “IPv6 es inestable; IPv4 bien” → ICMPv6 PTB bloqueado → permitir ICMPv6 correctamente

Síntoma: Hosts dual‑stack muestran colgamientos intermitentes sobre IPv6; IPv4 funciona.
Causa raíz: ICMPv6 Packet Too Big bloqueado; IPv6 no puede confiar en la fragmentación por routers.
Solución: Permitir tipos ICMPv6 requeridos; validar con pings DF (ping6) y tcpdump.

Listas de verificación / plan paso a paso

Plan “detener la hemorragia” de 15 minutos

1. Prueba la dependencia por tamaño: ejecuta pings DF con tamaños crecientes al destino que falla (Tarea 2–3).
2. Comprueba MTUs de interfaz: underlay e interfaces de túnel (Tarea 1).
3. Comprueba PMTU de ruta: ip route get para una pista (Tarea 4).
4. Confirma retransmisiones: ss -ti en un flujo activo (Tarea 5) y opcionalmente iperf3 (Tarea 8).
5. Captura ICMP PTB/frag‑needed: confirma si los mensajes PMTUD existen o desaparecen (Tarea 6).
6. Mitiga rápido: aplica clamp MSS en el borde (Tarea 12 o 13).
7. Verifica con tráfico real: curl de un objeto grande, scp de un archivo, pull de una imagen de contenedor (Tarea 7 + tu carga).
8. Anota la MTU de trabajo medida: no confíes en la memoria; el tú futuro ya está cansado.

Plan de solución permanente (para prevenir recurrencias)

1. Mapea la encapsulación: lista cada segmento de túnel/overlay y su sobrecarga (VPN, VXLAN, Geneve, GRE, IP‑in‑IP).
2. Configura MTU donde corresponde: interfaces de túnel y CNIs a valores que quepan en el underlay con margen (Tarea 14).
3. Restaura señales PMTUD: ajusta políticas de firewall para permitir ICMP tipo 3/4 (IPv4) y ICMPv6 PTB (IPv6).
4. Estandariza clamp MSS en borde: mantenlo como defensa en profundidad para redes de partners que no controlas.
5. Añade una verificación sintética que transfiera bytes reales: no solo ping; algo que falle cuando MTU falla.
6. Documenta la “MTU conocida buena” por segmento: incluye quién la posee y qué proceso de cambios aplica.

Qué evitar durante un incidente

• No aumentes MTU al azar “para mejorar rendimiento” para arreglar lentitud. Así conviertes una falla parcial en una total.
• No desactives ICMP de forma amplia. Si debes filtrar, hazlo con intención y permite los mensajes críticos para PMTUD.
• No des por buena una sola respuesta ping exitosa. Los bugs de MTU adoran tu monitorización simplista.

Preguntas frecuentes

1) ¿Cuál es la diferencia entre MTU y MSS?

MTU es el tamaño máximo de paquete IP en un enlace. MSS (Maximum Segment Size) es el tamaño máximo de carga TCP.
MSS es aproximadamente MTU menos cabeceras IP+TCP. Arreglar la MTU arregla todo; clampear MSS solo arregla TCP.

2) ¿Por qué el desajuste de MTU parece “internet lenta” en lugar de una caída?

Porque solo fallan paquetes por encima de cierto tamaño. Peticiones pequeñas, ACKs, DNS y algunos elementos de página funcionan.
Respuestas grandes, subidas o mensajes de protocolo específicos cuelgan y se reintentan. Las personas interpretan “reintentos” como “lento”.

3) ¿Por qué bloquear ICMP es un problema? ¿No es ICMP inseguro?

Bloquear a lo bruto es el problema. PMTUD depende de errores ICMP para informar a los remitentes sobre límites de MTU.
Para IPv6, ICMPv6 Packet Too Big es esencial. Puedes aplicar rate‑limit y filtrar tipos específicos, pero
“no ICMP” rompe tráfico real de formas que no son obvias.

4) ¿Cómo elijo la MTU correcta para un túnel VPN?

Mide. Empieza con la MTU del underlay (a menudo 1500), resta la sobrecarga de encapsulación y valida con pings DF a través del túnel.
Añade un margen si la ruta incluye equipo de proveedor desconocido. Si no puedes medir de forma fiable, aplica clamp MSS en el borde.

5) ¿El clamp MSS reduce el rendimiento?

Puede aumentar ligeramente la CPU y la tasa de paquetes porque envías más segmentos más pequeños. Pero usualmente mejora el throughput real
frente a un agujero negro donde reintentas segmentos grandes repetidamente. Piensa “menos elegante, más funcional”.

6) ¿Los problemas de MTU pueden afectar solo una dirección?

Sí. Un lado puede poder enviar ICMP PTB de vuelta, el otro puede tenerlo bloqueado. O solo una dirección atraviesa un túnel.
La asimetría es común en redes corporativas con múltiples caminos de salida y appliances de seguridad “útiles”.

7) ¿Por qué IPv6 falla a veces mientras IPv4 funciona?

IPv6 depende de PMTUD porque los routers no fragmentan paquetes en tránsito. Si ICMPv6 PTB está bloqueado, los flujos IPv6 pueden colgar
con paquetes grandes. IPv4 puede sobrevivir gracias a la fragmentación en algunas rutas, enmascarando el problema.

8) ¿Valen la pena los jumbo frames?

Valen la pena en segmentos estrictamente controlados donde cada salto está verificado (redes de almacenamiento, dominios east‑west específicos).
No valen la pena a través de infraestructura heterogénea o redes de partners. Si no puedes garantizar end‑to‑end MTU, mantente en 1500.

9) ¿Cómo pruebo MTU sin romper producción?

Usa pings DF a un objetivo conocido, ejecútalos fuera de pico y no cambies MTU en interfaces muy ocupadas a la ligera.
Para capturas de paquetes, desactiva offloads solo en un host de prueba. Prefiere el clamp MSS en el borde como mitigación reversible.

10) ¿Cuál es la “señal” más rápida de que esto es MTU y no congestión?

Pings DF fallando a un umbral de tamaño consistente, más retransmisiones TCP durante transferencias grandes mientras las peticiones pequeñas tienen éxito.
La congestión no suele crear un cliff de tamaño tan marcado. Los problemas de MTU sí.

Conclusión: siguientes pasos que puedes hacer hoy

Los incidentes de MTU no se anuncian. Se disfrazan de “la red está lenta” y te hacen perder la tarde.
La solución rara vez es complicada, pero sí es específica: mide el tamaño real de paquetes que funciona, identifica dónde se redujo la ruta,
y o bien restablece PMTUD o aplica clamp MSS hasta que puedas.

Pasos siguientes que rinden inmediatamente:

• Añade un paso al runbook: prueba de tamaño DF ping + comprobación de retransmisiones con ss -ti antes de tocar “tuning de rendimiento”.
• Estandariza clamp MSS en gateways VPN/edge como red de seguridad para redes de partners.
• Audita reglas de firewall para ICMP frag‑needed (IPv4) y Packet Too Big (IPv6). Permítelas con rate limits sensatos y logging.
• Documenta la MTU por segmento (underlay, túneles, overlays). Trátala como una dependencia SLO, no como trivia.

Haz eso y la próxima vez que alguien diga “internet está lento”, tendrás una respuesta concreta en minutos—en lugar de una sensación vaga y una creciente adicción al café.