Ubuntu 24.04: Los jumbo frames rompen “solo parte” del tráfico — cómo probar y arreglar MTU de forma segura

octubre 28, 2025 • febrero 3, 2026 • Lectura: 28 min • Views: 7

¿Te fue útil?

Cambias el MTU a 9000 porque el almacenamiento está “lento” y de repente el mundo se vuelve extraño: SSH sigue bien, DNS responde, pero “algunos” sitios HTTPS se quedan
colgados, ciertas llamadas a APIs se bloquean indefinidamente y tu tráfico de Ceph o NFS se convierte en una obra dramática de esperando ACK.

Esta es la señal de una falla parcial de MTU: los paquetes grandes mueren silenciosamente en algún punto del camino, mientras los paquetes pequeños pasan sin problema
y te hacen cuestionar tus decisiones profesionales. Arreglémoslo como adultos: medir, aislar, cambiar una cosa a la vez y mantener la reversión fácil.

Por qué los jumbo frames rompen “solo parte” del tráfico

Que “solo parte del tráfico” falle no es un paradoja. Es lo que pasa cuando la red puede transportar tramas pequeñas (como ACKs TCP, SYNs, paquetes DNS, pequeñas
peticiones HTTP), pero descarta o deja en negro tramas más grandes (como registros TLS, respuestas gRPC, lecturas SMB, replicación de almacenamiento, cargas de
superposición de contenedores).

El patrón raíz suele parecer uno de estos:

Desajuste de MTU entre interfaces en un mismo dominio L2 (un salto atascado en 1500 y otros en 9000). Resultado: las tramas grandes se descartan en
ese salto. Las tramas pequeñas sobreviven. Obtienes tráfico “funciona para mí”… hasta que la carga útil es grande.
Path MTU Discovery (PMTUD) roto: en algún punto se descartan mensajes ICMP “Se necesita fragmentación”, por lo que los endpoints nunca aprenden
el MTU real. TCP sigue intentando segmentos grandes que van muriendo. La conexión no siempre falla rápido; se queda estancada. Por eso este fallo parece embrujado.
Túneles/overlays reducen el MTU efectivo (VXLAN, GRE, WireGuard, IPsec, VPN de nube). Tu NIC puede estar en 9000, pero el túnel necesita overhead.
Si no bajas el MTU en consecuencia, acabas de construir una trituradora de paquetes.
Interacciones con offloads (TSO/GSO/GRO/LRO) que pueden ocultar el comportamiento de fragmentación y hacer que las capturas de paquetes sean engañosas.
El kernel puede “fingir” que envió paquetes enormes mientras la NIC los segmenta realmente—hasta que el camino no lo permite.
Dispositivos de políticas (firewalls, balanceadores, gateways NAT) que manejan mal ICMP, ajustan MSS incorrectamente o imponen un MTU inesperado en
una sola dirección. Las rutas asimétricas son donde las verdades simples vienen a morir.

La conclusión práctica: los jumbo frames no son una simple opción; son un contrato de extremo a extremo. Si algún salto no está de acuerdo, solo los paquetes que
exceden el MTU más pequeño serán castigados. Todo lo demás sigue funcionando y te gaslightea.

Chiste #1: Los fallos de MTU son como los microondas de oficina—bien para cosas pequeñas, pero mete algo grande y de repente hay humo y culpas.

Hechos y contexto histórico (lo que explica el dolor)

El “MTU 1500” de Ethernet es una convención, no física. Se convirtió en el valor por defecto en parte porque equilibraba eficiencia con límites de buffer en equipos antiguos.
Los “jumbo frames” nunca tuvieron un tamaño universal. 9000 es común, pero 9216 y 9600 también aparecen porque los proveedores querían margen para etiquetas VLAN y framing interno.
PMTUD depende de ICMP, que las redes empresariales tienden a bloquear. Este ha sido un modo de fallo recurrente desde los 90 y todavía gana premios al “incidente más evitable”.
RFC 4821 (Packetization Layer PMTUD) existe porque PMTUD clásico era frágil cuando ICMP se filtra; muchas pilas solo implementan parcialmente el enfoque “más robusto”.
El etiquetado VLAN reduce el MTU útil si no lo tienes en cuenta. Una etiqueta 802.1Q añade 4 bytes; QinQ añade 8. Algunos switches lo compensan; otros no.
VXLAN y similares hicieron la aritmética de MTU operativa. Las redes overlay desplazaron el MTU de “característica de switch” a “cada nodo debe estar de acuerdo”, especialmente en Kubernetes y entornos multi-tenant.
Los jumbo frames ayudan sobre todo con la eficiencia de CPU, no con la tasa bruta. Menos paquetes para los mismos bytes significan menos interrupciones y sobrecarga por paquete—útil en throughput alto.
Las redes de almacenamiento abrazaron los jumbo frames temprano (iSCSI, NFS, replicación Ceph) porque tienden a mover cargas secuenciales grandes y se benefician de menos paquetes.

Guía rápida de diagnóstico

Cuando estás contra el reloj, no necesitas teoría. Necesitas un camino rápido hacia “cuál es el MTU más pequeño en este camino y quién no está de acuerdo”.

Primero: confirma que es MTU y no “la app”

Ejecuta una prueba de ping con DF desde el cliente al servidor con un tamaño de carga que debería pasar en 1500 y fallar en jumbo (detalles en la sección de tareas).
Si 1472 funciona pero ~8972 no, enhorabuena: es MTU.
Si las solicitudes pequeñas funcionan pero las descargas grandes se estancan, prueba con curl --http1.1 y una respuesta grande conocida. Estancamientos
durante la transferencia más fallos en el ping DF son clásicos.

Segundo: encuentra el MTU de salto más pequeño en el camino real

Revisa el MTU en la NIC del host, bond, subinterfaz VLAN, bridge y endpoints de túnel. El más pequeño manda, te guste o no.
Confirma que el perfil del puerto del switch realmente permita jumbo. No confíes en “lo configuramos el año pasado.” Esa frase ha terminado carreras.

Tercero: verifica que PMTUD funcione

Busca ICMP “se necesita fragmentación” cuando envías paquetes DF que son demasiado grandes. Si falta, algo lo está descartando.
Temporalmente ajusta el MSS de TCP en los límites (firewall, VPN, túnel) como mitigación, y luego corrige el alineamiento real de MTU.

Cuarto: revisa overlays y offloads

En Kubernetes/VXLAN, ajusta el MTU de los pods por debajo del MTU del nodo según el overhead de encapsulación.
Desactiva TSO/GSO brevemente para troubleshooting si las capturas son confusas, y luego reactívalas para rendimiento una vez entiendas el camino.

Un modelo mental práctico de MTU (capas, overhead y dónde falla)

MTU es el tamaño máximo de la carga útil L3 que tu interfaz llevará sin fragmentación. En Ethernet, la gente dice informalmente “MTU 1500” refiriéndose a 1500 bytes
de payload IP dentro de un frame Ethernet. El frame Ethernet en sí es más grande (headers, FCS, preámbulo), pero el MTU que tocas en Linux es típicamente el tamaño
de la carga útil L3.

Lo más útil para recordar es que MTU es por salto y por interfaz. Puedes tener:

NIC MTU = 9000
Bond MTU = 9000
Subinterfaz VLAN MTU = 9000
Bridge Linux MTU = 1500 (ups)
Dispositivo VXLAN MTU = 1450 (probablemente correcto para un underlay de 1500)

Y entonces todos discuten sobre “el MTU”, como si hubiera uno solo. No lo hay. Hay una cadena, y el eslabón más débil fija tu MTU efectivo.

Por qué TCP “en cierto modo funciona” aun cuando MTU está roto

TCP puede evitar la fragmentación eligiendo segmentos más pequeños. Aprende cuán grande puede enviar de forma segura mediante PMTUD: envía paquetes con DF (no fragmentar),
y si un salto no los puede llevar, ese salto devuelve ICMP “se necesita fragmentación” con el MTU del siguiente salto. Entonces TCP reduce su tamaño de segmento.

Cuando ICMP está bloqueado, TCP no recibe el memo. Sigue enviando segmentos grandes que son descartados. Ocurren reintentos. Sucede backoff. Las aplicaciones agotan tiempo.
Mientras tanto, los paquetes pequeños (ACKs, keepalives, consultas pequeñas) siguen fluyendo, haciendo que todo parezca “mayormente bien” desde el monitoreo básico.

Por eso los fallos de MTU aparecen como:

Bloqueos intermitentes (no fallos duros)
Picos de latencia en la cola larga
Funciona en un camino de red pero no en otro (ruteo asimétrico, diferentes políticas de firewall)
“Se rompe solo cuando subimos/bajamos algo grande”

Overhead de overlay: tu impuesto MTU oculto

La encapsulación añade cabeceras. Esos bytes deben caber dentro del MTU del underlay. Si tu underlay es 1500 y usas VXLAN, tu MTU efectivo de payload suele estar
alrededor de 1450 (dependiendo de las cabeceras exactas). Si configuras el overlay a 1500 de todos modos, le pides al underlay que transporte >1500, lo que significa
fragmentación (malo) o descartes (peor).

Los jumbo frames pueden ayudar a los overlays también, pero solo si todo el underlay los soporta. De lo contrario, debes bajar el MTU en el overlay y/o ajustar MSS.

Una cita para pegar cerca de tu calendario de cambios: La esperanza no es una estrategia. — Gene Kranz

Tareas prácticas: comandos, salida esperada y qué decisión tomar

Estas son las tareas que realmente ejecuto cuando “parte del tráfico” falla después de un cambio de MTU en Ubuntu 24.04. Cada tarea incluye: comando, qué significa la salida,
y la decisión que tomas.

Tarea 1: Comprobar MTU actual en todas las interfaces (detecta la que difiere)

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> mtu 65536
enp3s0           UP             3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000
bond0            UP             3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000
br-storage       UP             7a:11:22:33:44:55 <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500

Significado: El bridge está a 1500 mientras todo lo demás está a 9000. Ese es un clásico fallo parcial: el tráfico que atraviesa el bridge se ve
forzado a 1500 o es descartado si DF está puesto.

Decisión: Alinear MTU a lo largo de toda la cadena (NIC → bond → VLAN → bridge → veth/tap) o deliberadamente fijar todo al menor valor que puedas soportar de extremo a extremo.

Tarea 2: Confirmar la ruta por defecto y la interfaz real de salida (evita depurar el camino equivocado)

cr0x@server:~$ ip route get 10.50.12.34
10.50.12.34 dev bond0 src 10.50.12.10 uid 1000
    cache

Significado: El tráfico a ese destino sale por bond0. Si estabas mirando la configuración de enp3s0, estarías depurando
fanfiction.

Decisión: Centra las comprobaciones de MTU y las capturas de paquetes en la(s) interfaz(es) de salida reales y en la ruta de retorno desde el par.

Tarea 3: Probar MTU L3 a un par con ping DF (IPv4)

cr0x@server:~$ ping -M do -s 1472 -c 2 10.50.12.34
PING 10.50.12.34 (10.50.12.34) 1472(1500) bytes of data.
1480 bytes from 10.50.12.34: icmp_seq=1 ttl=63 time=0.412 ms
1480 bytes from 10.50.12.34: icmp_seq=2 ttl=63 time=0.401 ms

--- 10.50.12.34 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Significado: Paquetes IP de 1500 bytes funcionan. Esto no demuestra que jumbo funcione; solo prueba que no rompiste Ethernet básico.

Decisión: Ahora prueba un paquete de tamaño jumbo que debería pasar si MTU 9000 es realmente extremo a extremo.

Tarea 4: Probar MTU jumbo con ping DF (IPv4) y observa que falle claramente

cr0x@server:~$ ping -M do -s 8972 -c 2 10.50.12.34
PING 10.50.12.34 (10.50.12.34) 8972(9000) bytes of data.
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500

--- 10.50.12.34 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1018ms

Significado: La pila local cree que la interfaz de salida tiene MTU 1500 para esta ruta, a pesar de lo que pensabas que habías configurado. Eso aún
no es un problema de ruta; es configuración local.

Decisión: Encuentra qué dispositivo en la cadena de salida tiene MTU 1500 (a menudo un bridge, VLAN, VRF o dispositivo de túnel).

Tarea 5: Si falla sin un error local, tienes un agujero negro en la ruta (PMTUD o salto intermedio)

cr0x@server:~$ ping -M do -s 8972 -c 2 10.50.12.34
PING 10.50.12.34 (10.50.12.34) 8972(9000) bytes of data.

--- 10.50.12.34 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1013ms

Significado: El host está dispuesto a enviar 9000, pero nadie responde. Eso suele significar que un salto descartó la trama grande. Si no vuelve
ICMP “se necesita fragmentación”, PMTUD no puede corregirlo.

Decisión: Captura tráfico y busca errores ICMP; si están ausentes, corrige el filtrado de ICMP o ajusta MSS como mitigación.

Tarea 6: Probar comportamiento MTU en IPv6 (es distinto; la fragmentación es solo en endpoints)

cr0x@server:~$ ping -6 -M do -s 1452 -c 2 2001:db8:10::34
PING 2001:db8:10::34(2001:db8:10::34) 1452 data bytes
1460 bytes from 2001:db8:10::34: icmp_seq=1 ttl=63 time=0.588 ms
1460 bytes from 2001:db8:10::34: icmp_seq=2 ttl=63 time=0.570 ms

--- 2001:db8:10::34 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Significado: El path IPv6 soporta al menos tamaños ~1500 aquí. Con IPv6, los routers no fragmentan; envían ICMPv6 “Packet Too Big”. Si eso está bloqueado,
IPv6 se vuelve frágil rápidamente.

Decisión: Asegura que ICMPv6 esté permitido extremo a extremo. Bloquearlo rompe tráfico real, no solo “ping”.

Tarea 7: Comprobar MSS de TCP en sesiones activas (detectar clamp o ausencia del mismo)

cr0x@server:~$ sudo ss -ti dst 10.50.12.34 | head -n 20
ESTAB 0 0 10.50.12.10:44218 10.50.12.34:443
	 cubic wscale:7,7 rto:204 rtt:1.21/0.12 ato:40 mss:8960 pmtu:9000 rcvmss:536 advmss:8960 cwnd:10 bytes_acked:12983 bytes_received:44112 segs_out:112 segs_in:98 data_segs_out:64 data_segs_in:71

Significado: Este flujo cree que PMTU es 9000 y MSS es 8960. Si el camino no puede realmente llevar 9000, esto es una receta para estancamientos.

Decisión: O haces que el camino sea verdaderamente 9000 extremo a extremo o ajustas MSS en la frontera a un valor seguro.

Tarea 8: Vigila mensajes ICMP de PMTUD con tcpdump

cr0x@server:~$ sudo tcpdump -ni bond0 'icmp and (icmp[0]=3 and icmp[1]=4)'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:22:31.201983 IP 10.50.12.1 > 10.50.12.10: ICMP 10.50.12.1 unreachable - need to frag (mtu 1500), length 556

Significado: La red te está diciendo que un salto tiene MTU 1500. PMTUD está funcionando, pero tus endpoints aún pueden comportarse mal si las políticas
descartan algunos ICMP o si solo algunos caminos devuelven el error.

Decisión: Arregla el desajuste: o bajas MTU/MSS a valores seguros para esa ruta, o actualizas el camino a jumbo de forma consistente.

Tarea 9: Comprobar si ICMP se filtra localmente (reglas de firewall)

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

Significado: ICMP/ICMPv6 están aceptados. Eso es bueno. Si no ves esas aceptaciones, PMTUD puede fallar incluso si la red está enviando los mensajes correctos.

Decisión: Permite ICMP “se necesita fragmentación”/“packet too big” y tráfico relacionado. No “asegures” tu red rompiéndola.

Tarea 10: Comprobar offloads de NIC que pueden confundir la investigación (no necesariamente la causa raíz)

cr0x@server:~$ sudo ethtool -k enp3s0 | egrep 'tcp-segmentation-offload|generic-segmentation-offload|generic-receive-offload'
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on

Significado: Los offloads están habilitados. Las capturas de paquetes en el host pueden mostrar “super-paquetes” grandes que nunca existen en el cable.

Decisión: Si la depuración es poco clara, desactiva TSO/GSO temporalmente en un nodo de prueba, valida el comportamiento y luego restáuralos. No dejes el rendimiento en el suelo permanentemente.

Tarea 11: Desactivar temporalmente TSO/GSO/GRO (movida diagnóstica)

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

Significado: Ahora las capturas de paquetes coinciden más con el comportamiento en el cable. El throughput puede bajar; está bien para diagnóstico.

Decisión: Reprueba los pings DF y la aplicación real. Si los síntomas cambian drásticamente, incorpora el entendimiento de los offloads en tu solución y luego vuelve a activarlos.

Tarea 12: Comprobar MTU del bridge y sus miembros (culpable común “1500 oculto”)

cr0x@server:~$ ip -d link show br-storage
7: br-storage: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 7a:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 9000 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

Significado: El bridge tiene MTU explícito 1500 aunque podría subir a 9000. Ese bridge limitará el tráfico que lo atraviesa.

Decisión: Fija el MTU del bridge para que coincida con el underlay si todos los segmentos adjuntos soportan jumbo; de lo contrario mantenlo en 1500 y acepta esa realidad.

Tarea 13: Confirmar que las interfaces VLAN estén alineadas (las VLAN son donde las suposiciones mueren)

cr0x@server:~$ ip -d link show bond0.120
12: bond0.120@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:aa:bb:cc brd ff:ff:ff:ff:ff:ff promiscuity 0
    vlan protocol 802.1Q id 120 <REORDER_HDR>

Significado: El dispositivo VLAN está a 9000. Si estuviera a 1500 mientras el padre está a 9000, tendrías fallos específicos de ruta y extraña asimetría.

Decisión: Mantén MTU consistente para el padre y las subinterfaces VLAN salvo que tengas una razón específica y un diagrama que lo pruebe.

Tarea 14: Medir comportamiento real de la aplicación con curl (los patrones de estancamiento importan)

cr0x@server:~$ curl -v --max-time 10 http://10.50.12.34:8080/largefile.bin -o /dev/null
*   Trying 10.50.12.34:8080...
* Connected to 10.50.12.34 (10.50.12.34) port 8080
> GET /largefile.bin HTTP/1.1
> Host: 10.50.12.34:8080
> User-Agent: curl/8.5.0
> Accept: */*
* Request completely sent off
* Operation timed out after 10000 milliseconds with 0 bytes received
curl: (28) Operation timed out after 10000 milliseconds with 0 bytes received

Significado: El establecimiento de conexión tuvo éxito, la petición salió, la respuesta nunca llegó. Eso es consistente con paquetes grandes del servidor
al cliente descartados, o fallo de PMTUD en la dirección inversa.

Decisión: Prueba también la dirección inversa (ejecuta lo mismo desde el otro host) y captura en ambos extremos; sospecha de MTU/ICMP asimétricos.

Tarea 15: Comprobar contadores del kernel relacionados con MTU/PMTUD (¿vemos fragmentación o errores?)

cr0x@server:~$ netstat -s | egrep -i 'fragment|reassembl|MTU|icmp.*frag' | head -n 30
Ip:
    0 outgoing packets dropped
    12 fragments dropped after timeout
    0 reassemblies required
Icmp:
    4 destination unreachable messages received

Significado: Contadores relacionados con fragmentos moviéndose pueden indicar fragmentación real o agujeros negros. No es perfecto, pero da una pista.

Decisión: Si ves reensamblados o drops de fragmentos que aumentan durante pruebas, alinea MTU y evita depender de fragmentación para tráfico de rendimiento.

Tarea 16: Validar la configuración persistente de MTU en Ubuntu 24.04 (netplan)

cr0x@server:~$ sudo cat /etc/netplan/01-bond.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      mtu: 9000
    enp4s0:
      mtu: 9000
  bonds:
    bond0:
      interfaces: [enp3s0, enp4s0]
      mtu: 9000
      parameters:
        mode: 802.3ad
        mii-monitor-interval: 100

Significado: Netplan está fijando explícitamente MTU. Si el MTU en ejecución no coincide, puede haber otro archivo que lo esté sobreescribiendo o un cambio en tiempo de ejecución.

Decisión: Consolida la configuración de netplan y aplícala con cuidado (ver el plan de despliegue seguro) para evitar reconfiguraciones sorpresa en medio de un incidente.

Cómo arreglar MTU de forma segura (sin salidas “ups”)

Hay dos estrategias generales. Elige una y cúmplela. Medio-jumbo es como conseguir una red medio rota.

Estratagema A: Hacer que jumbo sea realmente extremo a extremo (preferido para clústeres de almacenamiento)

Esto es correcto cuando controlas todo el camino L2/L3: NICs, bonds, bridges, switches y cualquier appliance intermedio.

Fija MTU de forma consistente en cada interfaz Linux que transporte el tráfico: NIC físicas, bonds, subinterfaces VLAN, bridges y cualquier veth/tap para VMs/contenedores.
Asegura que los puertos y trunks del switch estén configurados para aceptar jumbo frames. Fíjate en los ajustes de “baby giant” si hay etiquetas VLAN involucradas.
Valida que PMTUD siga funcionando (no bloquees ICMP), incluso con jumbo activado. Quieres PMTUD como red de seguridad, no como baja colateral.
Ejecuta pruebas DF ping para 1500 y tamaños jumbo entre todos los pares críticos (no solo un par).

Estratagema B: Mantener el underlay en 1500, ajustar overlays y clamp MSS (preferido para redes corporativas mixtas)

Si atraviesas VPNs, gateways cloud o middleboxes desconocidos, los jumbo frames suelen perder la discusión con la realidad.

Deja el MTU del underlay en 1500 (o el menor salto requerido).
Configura el MTU del túnel/overlay correctamente (usualmente menor que el underlay por el overhead).
Ajusta (clamp) el MSS de TCP en la frontera para que TCP nunca intente segmentos que no caben. Esto mitiga los agujeros negros de PMTUD.

Mecánica de cambio seguro en Ubuntu 24.04

Ubuntu 24.04 típicamente usa netplan con systemd-networkd o NetworkManager. En servidores suele ser networkd. Cambios de MTU pueden reiniciar interfaces. Si esta es
la misma interfaz por la que estás conectado por SSH, necesitas un arnés de seguridad.

Reglas de oro para cambios de MTU en producción

Nunca cambies MTU en tu único camino de gestión sin una consola fuera de banda o una reversión programada.
Cambia primero el dominio más estrecho: si el puerto del switch está en 1500, subir el host a 9000 no te aporta nada excepto confusión.
Despliega en anillos: un host, luego un par, luego un rack/zona, luego la flota.
Mide con tráfico real: replicación de almacenamiento, tráfico overlay de contenedores, transferencias HTTP grandes—no solo pings.

Chiste #2: “Simplemente subimos MTU a 9000 en todas partes” es el equivalente en redes de “solo reinicio producción rápido”.

Tres mini-relatos corporativos desde las trincheras del MTU

Mini-relato 1: El incidente causado por una suposición equivocada

Una empresa mediana tenía un clúster de virtualización privado: hipervisores en Ubuntu, tráfico de almacenamiento en una VLAN dedicada y un stack de top-of-rack que
“soportaba jumbo.” Alguien decidió habilitar jumbo frames para reducir CPU en los hipervisores porque los gráficos mostraban softirq altos durante ventanas de backup.

El ingeniero cambió MTU a 9000 en los bonds de los hipervisores y en las interfaces VLAN de almacenamiento. Unos pings de prueba a 1500 tuvieron éxito, las VMs siguieron
funcionando y todos se fueron a casa. A la mañana siguiente, solo algunas VMs tenían backups rotos. Algunos mounts NFS estaban bien. Otros colgaban durante lecturas grandes.
Parecía un array de almacenamiento inestable, que es un chivo expiatorio popular.

La suposición equivocada: “El stack de switches soporta jumbo, así que los puertos deben estar configurados.” En realidad, el switch tenía jumbo habilitado globalmente, pero
un trunk concreto hacia la red de almacenamiento aún tenía un perfil legado con un máximo cercano a 1500. El tráfico dentro del rack siguió con jumbo; el que cruzó ese trunk
se topó con el MTU más pequeño y empezó a crear agujeros negros para tramas grandes.

El diagnóstico tomó más tiempo del necesario porque las comprobaciones básicas estaban verdes: SSH, RPCs pequeñas, heartbeats del clúster. La primera pista verdaderamente útil
fue un ping DF que falló solo entre racks, y un tcpdump mostrando ICMP “se necesita fragmentación” en una dirección pero no en la otra (filtrado asimétrico).

La solución fue aburrida: alinear el MTU del trunk del switch, verificar con pings DF entre nodos representativos y dejar de tratar “soporta jumbo” como “configurado para jumbo.”
La acción post-incident fue igual de aburrida: mantener una matriz simple de MTU por VLAN y hacer cumplir comprobaciones de configuración. Funcionó.

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

Otra organización ejecutaba Kubernetes en Ubuntu con un CNI basado en VXLAN. Tenían una red este-oeste rápida y querían “máximo rendimiento”, así que pusieron el MTU de
la NIC del nodo a 9000 y asumieron que todo lo demás se beneficiaría automáticamente. Los pods mantuvieron el MTU por defecto, y la auto-detección de MTU del CNI acertó mal
en un subconjunto de nodos.

Durante una semana nada se rompió de forma obvia. Luego desplegaron un servicio que transmitía respuestas grandes (piensa: artefactos, blobs de modelos ML, payloads JSON grandes—elige tu veneno).
De repente, solo algunos pods en algunos nodos experimentaron latencias enormes y timeouts. Los reintentos enmascararon el problema, así que los gráficos mostraron “más lento pero en su mayoría ok”,
que es exactamente el tipo de problema que quema dinero en silencio.

La optimización salió mal por el overhead de encapsulación. Algunas rutas pod-a-pod excedían efectivamente el MTU del underlay debido a las cabeceras VXLAN, y PMTUD era poco fiable
debido a reglas de firewall que trataban algunos ICMP como sospechosos. Así que los pods enviaban paquetes que estaban bien en el nodo, pero demasiado grandes fuera del nodo.

La corrección fue establecer un MTU explícito y correcto en el CNI (más bajo que el underlay por el peor overhead), y mantener el MTU del underlay consistente en todas las interfaces
relevantes. Los jumbo frames seguían usándose en la red física, pero el MTU del overlay se eligió deliberadamente, no “porque más grande es mejor.”

La lección más valiosa no fue “no uses jumbo.” Fue: no despliegues cambios de rendimiento que no puedas validar con pruebas extremo a extremo y un plan de rollback. El trabajo
de rendimiento es trabajo de producción. Trátalo con la misma disciplina.

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

Un equipo de servicios financieros tenía la costumbre: cada cambio que afectara a la red venía con una pequeña “prueba de contrato de ruta.” Era un script que corría desde un host canario:
pings DF a varios tamaños, una descarga HTTPS grande y una comprobación de sanity de replicación de almacenamiento. Registraba resultados en un sitio visible para todos.

Un trimestre, el equipo de red reemplazó un par de firewalls. El plan de migración era sólido, pero en medio de una ventana de cambio larga, alguien restauró una política por defecto que
sin querer bloqueó ciertos mensajes ICMP unreachable. La conectividad permaneció. El monitoreo se mantuvo verde. Ese tipo de verde que miente.

La prueba canaria saltó de inmediato. Los pings DF a tamaños jumbo dejaron de recibir respuestas “se necesita fragmentación”; las descargas grandes se estancaron; el comportamiento de PMTUD cambió.
Nadie tuvo que esperar a que los clientes llamaran. La decisión de rollback se tomó sobre evidencia, no por intuiciones.

Ni siquiera necesitaron abandonar el corte del firewall. Ajustaron la política para permitir ICMP esencial, volvieron a correr las pruebas y siguieron adelante.
La práctica no era glamorosa. No dio charlas en conferencias. Aun así salvó el día.

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

1) Síntoma: SSH funciona, pero descargas grandes cuelgan o se reinician

Causa raíz: Agujero negro de PMTUD. Segmentos TCP grandes exceden un MTU de salto; ICMP “se necesita fragmentación” está bloqueado.

Solución: Permite ICMP fragmentation-needed/packet-too-big en los firewalls. Como mitigación, ajusta (clamp) el MSS de TCP en el dispositivo fronterizo.

2) Síntoma: Solo el tráfico entre subredes falla después de habilitar jumbo

Causa raíz: Un dispositivo L3 (router, firewall, gateway) sigue en 1500 mientras el L2 local es jumbo.

Solución: O haces la ruta enrutada jumbo-capable extremo a extremo, o mantienes MTU del servidor en 1500 para ese segmento enrutado y usas jumbo solo en VLANs de almacenamiento aisladas.

3) Síntoma: Tráfico east-west de pods en Kubernetes es inestable; ping nodo-a-nodo está bien

Causa raíz: MTU del overlay no reducido por el overhead de VXLAN/Geneve, o MTU del CNI inconsistente entre nodos.

Solución: Establece un MTU consistente en el CNI (por ejemplo, 1450 para underlay 1500, o mayor si el underlay es jumbo). Valida con pruebas DF entre pods en diferentes nodos.

4) Síntoma: VMs en un bridge Linux se rompen, pero el host está bien

Causa raíz: Bridge o dispositivos tap/vnet en 1500; NIC del host en 9000. El tráfico de la VM golpea el MTU más pequeño.

Solución: Ajusta el MTU en el bridge y en las interfaces frente a las VMs de forma consistente, o mantén todo en 1500 si el camino físico no puede garantizar jumbo.

5) Síntoma: Una dirección va lenta, la otra está bien

Causa raíz: Ruteo asimétrico o filtro ICMP asimétrico; PMTUD funciona en una dirección pero no en la inversa.

Solución: Captura en ambos extremos; alinea políticas MTU; permite ICMP en ambos sentidos; verifica simetría de ruta para flujos críticos.

6) Síntoma: “Pusimos MTU a 9000 pero ping dice mtu=1500”

Causa raíz: La ruta usa una interfaz diferente (VRF, VLAN, bridge) aún en 1500, o un override de configuración resetea MTU en link up.

Solución: Usa ip route get para confirmar el dispositivo de salida; revisa MTU en toda la pila de interfaces; corrige netplan/systemd-networkd para persistir correctamente.

7) Síntoma: El rendimiento empeoró después de habilitar jumbo

Causa raíz: Microbursting y presión de buffers en switches/NICs, o problemas de offload/driver. Jumbo reduce paquetes, pero puede aumentar la latencia por serialización y la ráfaga.

Solución: Valida con pruebas de throughput y latencia, vigila drops en switches/NICs, considera un jumbo ligeramente más pequeño (por ejemplo 9000 vs 9600) y ajusta colas; no asumas “más grande siempre más rápido”.

Listas de verificación / plan paso a paso

Checklist: antes de tocar MTU

Define el alcance: ¿qué VLAN/subnet/túnel está cambiando?
Lista cada salto: NICs de servidor, bonds, bridges, vSwitch de hipervisor, switchports, trunks, routers, firewalls, VPNs, load balancers.
Decide tu MTU objetivo por dominio: solo 1500, o jumbo extremo a extremo.
Confirma que tienes una ruta de rollback: acceso por consola, NIC de mgmt alterna o un job temporizado que revierta netplan.
Prepara pruebas: pings DF a tamaños, una transferencia HTTP grande y una prueba de carga real (replicación de almacenamiento, job de backup, etc.).

Paso a paso: despliegue seguro de jumbo en Ubuntu 24.04 (servidores)

Elige un host canario con acceso fuera de banda.
Mide la línea base:
ejecuta pings DF a 1472 y 8972 hacia pares clave; realiza una transferencia grande; captura un tcpdump corto para ICMP “se necesita fragmentación.”
Valida la red primero:
configura switchports/trunks para jumbo, confirma con el equipo de red usando sus herramientas. No cambies hosts hasta que la red esté lista.
Cambia MTU en el host canario en netplan para todas las interfaces relevantes (físicas + bond + VLAN + bridge).
Aplica de manera controlada:
prefiere una ventana de mantenimiento; si solo tienes acceso remoto, usa un mecanismo de rollback temporizado (ver más abajo).
Vuelve a ejecutar pruebas inmediatamente:
el ping DF jumbo debe tener éxito extremo a extremo; la transferencia de la aplicación debe completarse; revisa ss -ti para MSS/PMTU sensatos.
Expande a un anillo pequeño:
un par de hosts que se comuniquen mucho; luego un rack; luego la flota.
Mantén el monitoreo enfocado:
vigila retransmisiones, timeouts y latencia de almacenamiento. Las fallas de MTU a menudo aparecen como tormentas de retransmisión, no como enlaces caídos.

Patrón de rollback temporizado (para que duermas tranquilo)

Si vas a cambiar el MTU en la interfaz que transporta tu sesión SSH, programa una reversión temporizada antes de aplicar netplan. Ejemplo: programa un reboot o una reversión
de netplan en 5 minutos, luego cancélalo una vez confirmes conectividad. Hay muchas maneras; la idea es: no apuestes la producción a tu Wi‑Fi.

cr0x@server:~$ sudo systemd-run --on-active=5m --unit=mtu-rollback.service /usr/sbin/netplan apply
Running as unit: mtu-rollback.service

Significado: Este ejemplo es intencionalmente simplista y no es una reversión completa; en la práctica ejecutarías un script que restaura un YAML netplan conocido y lo aplica.

Decisión: Usa un script real de rollback en tu entorno. El punto es el patrón operacional: aplica el cambio con un temporizador de seguridad y cancélalo una vez verificado.

Preguntas frecuentes

1) ¿Por qué ping funciona pero mi aplicación se rompe?

El ping por defecto usa paquetes pequeños. Tu aplicación probablemente envía segmentos TCP más grandes. Los problemas de MTU solo aparecen cuando los paquetes exceden el MTU más pequeño
en el camino, y entonces PMTUD puede o no rescatarte según las políticas ICMP.

2) ¿Qué MTU debo elegir para jumbo frames: 9000 o 9216?

Elige el valor que tus switches y NICs soporten de forma consistente. 9000 es común para “IP MTU.” Algunos dispositivos anuncian 9216 como tamaño de frame. La única respuesta correcta
es: elige uno, documéntalo por VLAN y prueba extremo a extremo incluyendo el etiquetado VLAN y trunks.

3) ¿Los jumbo frames siempre mejoran el rendimiento?

No. A menudo reducen la sobrecarga de CPU en throughput alto, pero también pueden aumentar la ráfaga y estresar buffers. Si tu cuello de botella es disco, cifrado, serialización de la aplicación
o un proceso de usuario de un solo hilo, los jumbo frames no te salvarán.

4) ¿La fragmentación es realmente tan mala?

Fragmentación ocasional para tráfico raro es tolerable. Confiar en la fragmentación para tráfico masivo es una carga: CPU extra, complejidad de reensamblado, mayor sensibilidad a drops y depuración más dolorosa.
La mayoría de diseños modernos intentan evitarla.

5) ¿Cuál es la mejor manera de detectar agujeros negros de PMTUD?

Pruebas de ping DF más captura de paquetes para ICMP “se necesita fragmentación” / “packet too big.” Si los grandes paquetes DF desaparecen y nunca ves el error ICMP, algo lo está filtrando.
También busca flujos TCP estancados con retransmisiones altas y sin progreso hacia adelante.

6) En Kubernetes, ¿debería poner MTU del nodo a 9000?

Solo si tu underlay realmente soporta jumbo extremo a extremo y configuras el MTU del CNI/overlay de forma apropiada. De lo contrario, mantén el underlay en 1500 y usa un MTU de overlay más bajo
que contemple la encapsulación.

7) ¿Por qué el problema aparece solo para algunos destinos?

Distintos destinos pueden tomar rutas de red diferentes con MTUs diferentes (routers distintos, firewalls, túneles VPN, bordes en la nube). Los desajustes de MTU dependen del camino por naturaleza.

8) ¿Cómo lo arreglo rápido si no puedo cambiar la red hoy?

Mitiga bajando el MTU en las interfaces afectadas al valor seguro más pequeño, o ajustando MSS de TCP en la frontera para que los endpoints dejen de enviar segmentos demasiado grandes.
Luego programa la solución real: alinear MTU extremo a extremo o arreglar la política ICMP.

9) ¿Hace Ubuntu 24.04 algo “especial” con MTU?

La complejidad habitual viene de netplan que renderiza hacia systemd-networkd o NetworkManager, más interfaces apiladas (bonds, bridges, VLANs, túneles). El SO no es especial; tu topología sí.
Verifica el MTU en tiempo de ejecución con ip -br link, no solo en el YAML.

10) ¿Debería permitir todo ICMP a través del firewall?

Debes permitir los tipos de ICMP necesarios para la operación normal, especialmente fragmentation-needed/packet-too-big y mensajes unreachable relacionados. Bloquear todo ICMP es una herramienta tosca
que rompe PMTUD y hace los incidentes más difíciles de diagnosticar.

Conclusión: próximos pasos que no arruinan tu fin de semana

Los jumbo frames no “funcionan más o menos”. O funcionan extremo a extremo, o crean un campo de distorsión selectiva donde los paquetes pequeños prosperan y los grandes desaparecen.
Por eso ves que “solo parte del tráfico” se rompe.

Haz esto a continuación:

Ejecuta pings DF a 1500 y a tamaños jumbo entre los pares que importan.
Encuentra el MTU más pequeño en el camino revisando cada capa de interfaz: NIC, bond, VLAN, bridge, túnel.
Verifica PMTUD capturando ICMP “se necesita fragmentación” / “packet too big”; corrige políticas de firewall que lo bloqueen.
Elige una estrategia: jumbo extremo a extremo para dominios controlados, o underlay conservador de 1500 con MTU de overlay correcto y clamp de MSS.
Despliega en anillos con un canario y un plan de rollback. La producción premia la precaución, no la audacia.