Debian 13 MTU/MSS desajuste: por qué los archivos grandes se detienen y cómo arreglarlo correctamente

Qué está pasando realmente (sin cuentos)

MTU es la Unidad Máxima de Transmisión (Maximum Transmission Unit): el tamaño máximo de paquete IP que un enlace puede llevar sin fragmentación. Ethernet suele ser 1500 bytes.
PPPoE a menudo fuerza 1492. Los túneles (WireGuard, VXLAN, GRE, IPsec) restan cabeceras y reducen la MTU efectiva aún más.

MSS es el Tamaño Máximo de Segmento (Maximum Segment Size): el mayor tamaño de carga útil TCP (sin contar las cabeceras IP/TCP) que un host pondrá en un segmento TCP.
MSS se negocia durante el apretón de manos TCP mediante opciones en SYN y SYN-ACK. Si la MTU del camino es 1500, la MSS típica será 1460 (1500 menos 20 bytes de cabecera IPv4 y 20 bytes de cabecera TCP).
En IPv6, la MSS suele ser ~1440 debido a la cabecera base mayor.

El patrón del bloqueo: por qué “lo pequeño funciona, lo grande falla”

Aquí está el patrón central:

• Las peticiones pequeñas y las sesiones interactivas mantienen los paquetes por debajo de la MTU real del camino. Funcionan.
• Las transferencias masivas llenan la tubería, envían segmentos TCP de tamaño completo y eventualmente alcanzan un paquete que excede la MTU real. Esos paquetes se descartan.
• Si el remitente nunca aprende la MTU correcta (o la ignora), sigue retransmitiendo los mismos segmentos demasiado grandes. Ahora tienes un “agujero negro”.
• El rendimiento TCP colapsa. A veces parece que la transferencia “se cuelga”, otras veces corre a 3 KB/s, y otras expira por tiempo.

El mecanismo que debería salvarte es el Descubrimiento de MTU de Ruta (Path MTU Discovery, PMTUD). En IPv4, el remitente pone el bit DF (Don’t Fragment). Cuando un router no puede reenviar
un paquete porque es demasiado grande, debería enviar de vuelta un ICMP “Fragmentation Needed” con la MTU del siguiente salto. El remitente reduce su tamaño de paquete y reintenta.

En un mundo perfecto, PMTUD es aburrido e invisible. En el mundo real, ICMP se filtra (“por seguridad”) por firewalls que fueron revisados por última vez cuando
la gente todavía enviaba solicitudes de cambio por fax. Ahora el remitente nunca recibe la pista “fragmentation needed” y obtienes un agujero negro de PMTUD.

Debian 13 no es especial en esto—pero las configuraciones modernas pueden hacer que esto aparezca más a menudo:
más VPNs, más superposiciones, más redes de contenedores, más IPv6, más bordes en la nube, más middleboxes “útiles”. Estás apilando cabeceras como si fuera lasaña,
y luego te sorprende que una suposición de 1500 bytes deje de encajar.

MTU vs MSS: ¿cuál está “mal”?

El desajuste de MTU es una propiedad del enlace/camino. El desajuste de MSS es un comportamiento TCP del host final que puede ajustarse para adaptarse al camino.
Si la MTU del camino es más pequeña de lo que crees, puedes arreglar el camino (ideal) o forzar (clamp) la MSS para que TCP nunca emita paquetes demasiado grandes para el camino (pragmático).

Si operas toda la red, corrige la MTU en el origen: haz el camino consistente, configura MTU correctas en túneles, asegura que PMTUD funcione.
Si solo controlas un lado (común en la realidad corporativa), el clamp de MSS en tu borde suele ser la solución más limpia “que podemos desplegar hoy”.

Una idea parafraseada de Werner Vogels (confiabilidad/operaciones): “Todo falla; diseña para que las fallas sean rutinarias y se recuperen automáticamente.”
Los problemas de MTU son exactamente ese tipo de fallo—rutinarios, predecibles y solucionables con medidas de protección.

Chiste #1: PMTUD es como el chisme de oficina—si alguien bloquea ICMP, nadie se entera de la noticia importante y todos siguen tomando la misma mala decisión.

Hechos e historia que explican este comportamiento

Un puñado de hechos concretos explica por qué este problema sigue reapareciendo, incluso entre equipos experimentados:

1. La MTU de Ethernet de 1500 bytes se volvió un estándar de facto porque equilibraba eficiencia y límites de hardware en el diseño temprano de LAN; no es sagrada, solo común.
2. La MTU clásica de PPPoE es 1492 porque añade 8 bytes de sobrecarga encima del framing de Ethernet, reduciendo lo que IP puede transportar.
3. Los routers IPv6 no fragmentan paquetes en tránsito. Si excedes la MTU del camino, dependes de ICMPv6 “Packet Too Big” para corregirlo, o tienes un agujero negro.
4. La fragmentación en IPv4 existe pero se evita ampliamente porque el tráfico fragmentado aumenta la amplificación de pérdida y crea problemas de seguridad/monitorización.
5. Los agujeros negros de PMTUD fueron lo suficientemente comunes como para que las implementaciones TCP añadieran heurísticas como Packetization Layer PMTUD (PLPMTUD), intentando inferir la MTU sin depender de ICMP.
6. El clamp de MSS se popularizó en dispositivos de borde en escenarios ISP/VPN porque funciona incluso cuando ICMP se filtra; es un parche que se convirtió en movimiento estándar.
7. Jumbo frames (MTU 9000) pueden aumentar el rendimiento en redes de almacenamiento, pero solo si todos los saltos los soportan—un único salto a 1500 convierte todo en una fábrica de fallos silenciosos.
8. VXLAN y overlays similares suman ~50 bytes de sobrecarga (a menudo más, según el underlay), lo que significa que una MTU de underlay de 1500 implica ~1450 utilizable en el overlay.
9. La MTU efectiva de WireGuard depende del transporte y la ruta; “1420” es un valor común por defecto porque evita fragmentación en rutas típicas de Internet, pero no es universal.

Esos no son trivialidades. Son las razones por las que tu red “que funcionó el año pasado” empieza a fallar tras desplegar una VPN, migrar a la nube o renovar un firewall.

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

El objetivo es responder una pregunta rápidamente: ¿Estamos descartando paquetes grandes porque la MTU real del camino es más pequeña de lo que el remitente piensa?
Aquí está el orden que ahorra más tiempo en producción.

Primero: confirma que el síntoma depende del tamaño y no es pérdida genérica

• Intenta una descarga pequeña y una descarga grande desde el mismo endpoint.
• Usa un ping DF (IPv4) o un ping grande (IPv6) para encontrar el tamaño máximo que funciona.
• Observa retransmisiones y el comportamiento de “agujero negro” con ss y tcpdump.

Segundo: identifica dónde cambia la MTU (túneles, overlays, PPPoE, bordes en la nube)

• Revisa las MTU de las interfaces: NIC física, VLAN, bridge, VPN, veth de contenedor, túnel.
• Revisa rutas en busca de pistas de MTU.
• Confirma la encapsulación real en uso (¿WireGuard? ¿IPsec? ¿VXLAN? ¿GRE?).

Tercero: decide el límite de corrección más limpio

• Si puedes arreglar el camino, hazlo (MTU consistente de extremo a extremo; permite mensajes ICMP necesarios para PMTUD).
• Si no puedes, aplica clamp de MSS en el borde más cercano al remitente para los flujos afectados.
• Verifica con una prueba repetible y captura evidencia (antes/después).

Este playbook es intencionalmente aburrido. Aburrido es bueno. Aburrido significa que dejas de hacer “configura MTU 1400 en todas partes” en modo cultista y empiezas a hacer un cambio correcto.

Tareas prácticas: comandos, salida esperada y decisiones

A continuación hay tareas prácticas que puedes ejecutar en Debian 13 (o en cualquier derivado moderno de Debian) mientras estás en la reunión de incidente. Cada tarea incluye:
un comando, lo que significa la salida y qué decisión tomar a continuación.

Task 1: Check interface MTUs quickly

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp3s0           UP             3c:ec:ef:12:34:56 <BROADCAST,MULTICAST,UP,LOWER_UP>
wg0              UNKNOWN        9a:bc:de:f0:12:34 <POINTOPOINT,NOARP,UP,LOWER_UP>
br0              UP             02:42:ac:11:00:01 <BROADCAST,MULTICAST,UP,LOWER_UP>

cr0x@server:~$ ip link show dev enp3s0 | grep -i mtu
mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000

Significado: Estás buscando diferencias sospechosas: una NIC física en 1500, pero un túnel/overlay esperando 1420; o un bridge en 1500 mientras
una interfaz miembro es más pequeña.

Decisión: Si alguna interfaz “superior” (bridge/túnel) tiene una MTU mayor que lo que el camino encapsulado puede llevar, has encontrado un sospechoso principal.

Task 2: Inspect routes for MTU hints

cr0x@server:~$ ip route get 1.1.1.1
1.1.1.1 via 192.0.2.1 dev enp3s0 src 192.0.2.10 uid 1000
    cache

Significado: Linux puede almacenar MTU por ruta, pero no siempre lo mostrará a menos que esté configurado. Aun así es útil para verificar qué interfaz se usa.

Decisión: Si el tráfico sale por una interfaz de túnel o un VRF que no esperabas, detente. Diagnostica ese camino primero.

Task 3: Confirm the stall is size-dependent with curl

cr0x@server:~$ curl -o /dev/null -s -w "time=%{time_total} size=%{size_download}\n" https://repo.example.net/small.bin
time=0.18 size=1048576

cr0x@server:~$ curl -o /dev/null -v https://repo.example.net/large.iso
* Connected to repo.example.net (203.0.113.20) port 443
> GET /large.iso HTTP/1.1
> Host: repo.example.net
...
< HTTP/1.1 200 OK
...
  0 4096M    0 1024k    0     0   890k      0  1:18:33  0:00:01  1:18:32  0:00:00
  0 4096M    0 1024k    0     0      0      0 --:--:--  0:00:10 --:--:--     0

Significado: La transferencia grande empieza y luego el rendimiento colapsa. Eso es el clásico “algunos paquetes pasan y luego hay un agujero negro”.

Decisión: Pasa a las pruebas de PMTUD y capturas de paquetes. No pierdas tiempo en DNS, certificados CA o “quizá el servidor está lento”.

Task 4: IPv4 PMTUD test using DF ping (find max payload)

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

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

Significado: Tu host ya sabe (o alguna interfaz hace cumplir) MTU=1492 en algún punto de la salida. Payload 1472 implica MTU 1500;
falla y sugiere 1492.

Decisión: Vuelve a probar con -s 1464 (1492-28) y mira si pasa. Si pasa, estás en territorio PPPoE o túnel.

Task 5: Binary search the path MTU (IPv4)

cr0x@server:~$ ping -M do -s 1464 -c 2 203.0.113.20
PING 203.0.113.20 (203.0.113.20) 1464(1492) bytes of data.
1472 bytes from 203.0.113.20: icmp_seq=1 ttl=51 time=22.1 ms
1472 bytes from 203.0.113.20: icmp_seq=2 ttl=51 time=22.0 ms

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

Significado: La MTU end-to-end del camino es como mucho 1492 (para IPv4 en ese camino).

Decisión: Si tus hosts emisores usan MTU 1500 y no se adaptan, aplica clamp de MSS o ajusta la MTU para coincidir con esta realidad.

Task 6: IPv6 PMTU sanity test

cr0x@server:~$ ping -6 -s 1452 -c 2 2001:db8:100::20
PING 2001:db8:100::20(2001:db8:100::20) 1452 data bytes
From 2001:db8:200::1 icmp_seq=1 Packet too big: mtu=1420
From 2001:db8:200::1 icmp_seq=2 Packet too big: mtu=1420

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

Significado: IPv6 te está diciendo la MTU del camino (1420). Eso es el mejor escenario: ICMPv6 no está bloqueado y PMTUD está funcionando.

Decisión: Alinea la MTU del túnel/interfaz y/o aplica clamp de MSS para IPv6 también. No “arregles solo IPv4” y creas que ya terminaste.

Task 7: Observe TCP retransmits on the client during the stall

cr0x@server:~$ ss -ti dst 203.0.113.20:443
ESTAB 0 0 192.0.2.10:52144 203.0.113.20:https
	 cubic wscale:7,7 rto:1000 rtt:24.1/4.2 ato:40 mss:1460 pmtu:1500 rcvmss:536 advmss:1460 cwnd:10 bytes_sent:1048576 bytes_acked:1048576 bytes_retrans:65536 retrans:12

Significado: Las retransmisiones están subiendo. MSS es 1460 y PMTU muestra 1500, pero tus pruebas anteriores sugerían menos. Ese desajuste es la historia.

Decisión: Prueba si falta el ICMP “frag needed” o si la MTU de un túnel está mal configurada. Pasa a tcpdump.

Task 8: Capture PMTUD-related ICMP while reproducing

cr0x@server:~$ sudo tcpdump -ni enp3s0 '(icmp and (icmp[0]=3 and icmp[1]=4)) or (tcp and host 203.0.113.20 and port 443)'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:01:10.112233 IP 192.0.2.10.52144 > 203.0.113.20.443: Flags [P.], seq 1:1449, ack 1, win 501, length 1448
12:01:10.212244 IP 192.0.2.10.52144 > 203.0.113.20.443: Flags [P.], seq 1449:2897, ack 1, win 501, length 1448
12:01:11.312255 IP 192.0.2.10.52144 > 203.0.113.20.443: Flags [P.], seq 1449:2897, ack 1, win 501, length 1448
12:01:12.412266 IP 192.0.2.10.52144 > 203.0.113.20.443: Flags [P.], seq 1449:2897, ack 1, win 501, length 1448

Significado: Ves retransmisiones repetidas del mismo segmento, pero no vuelve ningún ICMP tipo 3/código 4. Esa es la firma de un agujero negro de PMTUD.

Decisión: O permites el ICMP necesario de vuelta, o aplicas clamp de MSS para que nunca envíes segmentos demasiado grandes en primer lugar.

Task 9: Check if a local firewall is blocking PMTUD ICMP

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
		tcp dport { 22 } accept
	}
	chain forward {
		type filter hook forward priority filter; policy drop;
	}
	chain output {
		type filter hook output priority filter; policy accept;
	}
}

Significado: La política de entrada descarta por defecto, pero acepta established,related. Los errores ICMP suelen ser “related” a un flujo existente;
eso es bueno, pero no garantizado dependiendo de la configuración de conntrack y del tipo de ICMP.

Decisión: Si ves descartes explícitos para ICMP o ICMPv6, arregla eso primero. PMTUD depende de esos mensajes.

Task 10: Confirm tunnel overhead and MTU on WireGuard

cr0x@server:~$ ip link show dev wg0 | grep -i mtu
mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000

cr0x@server:~$ sudo wg show wg0
interface: wg0
  public key: 3rY...redacted
  listening port: 51820

peer: q8S...redacted
  endpoint: 198.51.100.77:51820
  allowed ips: 10.10.0.0/16
  latest handshake: 1 minute, 2 seconds ago
  transfer: 1.32 GiB received, 2.01 GiB sent

Significado: wg0 ya está en 1420. Si las interfaces internas están en 1500 y enrutan hacia wg0, aún puedes emitir paquetes demasiado grandes dentro de un namespace/bridge
antes de alcanzar el límite del túnel.

Decisión: Asegura que la interfaz emisora del tráfico tunelizado tenga una MTU ≤ MTU de wg0 (o aplica clamp de MSS para el tráfico que entra en wg0).

Task 11: Check bridge/veth MTUs for container hosts

cr0x@server:~$ ip -d link show br0 | sed -n '1,25p'
7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether 02:42:ac:11:00:01 brd ff:ff:ff:ff:ff:ff
    bridge forward_delay 1500 hello_time 200 max_age 2000 stp_state 0 priority 32768

cr0x@server:~$ ip -br link | grep veth | head
veth9f2a2c3       UP             9a:3c:1d:aa:bb:cc <BROADCAST,MULTICAST,UP,LOWER_UP>
veth6a1b7d8       UP             4e:55:66:77:88:99 <BROADCAST,MULTICAST,UP,LOWER_UP>

Significado: br0 está en 1500. Si el path underlay es ~1450 debido a un overlay, tus pods/contenedores podrían generar paquetes de 1500 bytes que luego se descartan.

Decisión: En entornos overlay, establece la MTU de pods/bridge apropiadamente (o aplica clamp de MSS en la salida del nodo).

Task 12: Verify negotiated MSS in an actual connection (tcpdump SYN options)

cr0x@server:~$ sudo tcpdump -ni enp3s0 -c 6 'tcp port 443 and host 203.0.113.20 and (tcp[tcpflags] & (tcp-syn|tcp-ack) != 0)'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:05:01.000111 IP 192.0.2.10.52210 > 203.0.113.20.443: Flags [S], seq 111111111, win 64240, options [mss 1460,sackOK,TS val 123 ecr 0,nop,wscale 7], length 0
12:05:01.020222 IP 203.0.113.20.443 > 192.0.2.10.52210: Flags [S.], seq 222222222, ack 111111112, win 65160, options [mss 1440,sackOK,TS val 456 ecr 123,nop,wscale 8], length 0

Significado: Tu host ofreció MSS 1460. El servidor respondió con 1440. Si la MTU real del camino es más pequeña (por ejemplo 1492 o 1420),
quieres que la MSS lo refleje (1460 es demasiado grande para 1492? En realidad 1460 cabe en 1500; para 1492, la MSS debería ser 1452).

Decisión: Si no puedes confiar en PMTUD, aplica clamp de MSS a un valor seguro basado en la MTU del camino medida (y hazlo tanto para v4 como para v6 donde sea necesario).

Task 13: Check kernel PMTU/MTU probing behavior

cr0x@server:~$ sysctl net.ipv4.tcp_mtu_probing net.ipv4.ip_no_pmtu_disc
net.ipv4.tcp_mtu_probing = 0
net.ipv4.ip_no_pmtu_disc = 0

Significado: tcp_mtu_probing=0 significa que el kernel no sondará proactivamente MTUs más pequeñas cuando hay un agujero negro; ip_no_pmtu_disc=0 significa que PMTUD está habilitado.

Decisión: No “arregles” esto deshabilitando PMTUD globalmente. Considera habilitar la sondeo de MTU en TCP selectivamente si no puedes arreglar la red rápidamente, pero trátalo como respaldo.

Task 14: Validate that ICMP is permitted through your firewall (IPv4 + IPv6)

cr0x@server:~$ sudo nft list chain inet filter input
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 ipv6-icmp accept
		tcp dport 22 accept
	}
}

Significado: Este es el conjunto de reglas “deja de ser listo”: permitir ICMP e ICMPv6 entrantes, al menos para errores y mensajes PMTUD, idealmente con límites razonables.

Decisión: Si ICMP no está permitido, arréglalo. Si no puedes (firewall corporativo aguas arriba), el clamp de MSS se convierte en tu solución confiable.

Task 15: Implement MSS clamping with nftables (IPv4/IPv6) and verify counters

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

cr0x@server:~$ sudo nft -a list chain inet mssclamp forward
table inet mssclamp {
	chain forward {
		type filter hook forward priority mangle; policy accept;
		tcp flags syn tcp option maxseg size set rt mtu # handle 2
		ip6 nexthdr tcp tcp flags syn tcp option maxseg size set rt mtu # handle 3
	}
}

Significado: Esto clampa la MSS en paquetes SYN al MTU de la ruta automáticamente. Suele ser más limpio que codificar un número, porque se adapta por ruta.

Decisión: Usa clamp de MSS basado en la ruta en gateways/routers. En hosts individuales, puedes clamar en output si el propio host inicia los flujos.

Task 16: If you must hardcode, clamp to a known safe MSS

cr0x@server:~$ sudo nft add rule inet mssclamp forward ip protocol tcp tcp flags syn tcp option maxseg size set 1360
cr0x@server:~$ sudo nft add rule inet mssclamp forward ip6 nexthdr tcp tcp flags syn tcp option maxseg size set 1360

Significado: MSS 1360 suele ser segura para “Internet + túneles + desconocidos”, pero es un instrumento contundente. Cambia rendimiento por fiabilidad.

Decisión: Prefiere el clamp basado en ruta. Codifica solo cuando no puedas obtener información de MTU por ruta de forma consistente.

Task 17: Make MTU changes persistent on Debian (systemd-networkd example)

cr0x@server:~$ sudo sed -n '1,120p' /etc/systemd/network/10-enp3s0.network
[Match]
Name=enp3s0

[Network]
DHCP=yes

[Link]
MTUBytes=1492

cr0x@server:~$ sudo systemctl restart systemd-networkd
cr0x@server:~$ ip link show dev enp3s0 | grep -i mtu
mtu 1492 qdisc mq state UP mode DEFAULT group default qlen 1000

Significado: Has alineado la MTU del host con el requisito real del camino (común con PPPoE o un túnel conocido).

Decisión: Si solo ciertos destinos están afectados (algunos caminos sí, otros no), no bajes la MTU global en todas las interfaces. Usa MTU por ruta o clamp de MSS en el borde.

Task 18: Validate the fix with a repeatable transfer test

cr0x@server:~$ curl -o /dev/null -s -w "time=%{time_total} speed=%{speed_download}\n" https://repo.example.net/large.iso
time=43.22 speed=101234567

Significado: La transferencia se completa y la velocidad es estable. El síntoma de bloqueo desapareció.

Decisión: Captura un tcpdump corto “después” y registra el cambio con una nota de incidente clara: qué falló, qué cambiaste y cómo lo probaste.

Chiste #2: Los problemas de MTU son el único tipo de incidencia de red donde “simplemente hazlo más pequeño” es a la vez un mal consejo y, molesta pero cierta, a veces la solución correcta.

Tres historias corporativas desde el frente

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

Un equipo desplegó una nueva VPN sitio a sitio entre dos oficinas. El nuevo appliance “soportaba jumbo frames”, y alguien decidió que como la LAN ya
usaba MTU 9000 para tráfico de almacenamiento, la VPN debería igualarla. Consistencia, ¿no?

El cambio fue fluido la primera hora. La monitorización mostraba pings limpios y latencia normal. SSH estaba bien. La gente celebró en voz baja porque nadie
confía en celebrar en voz alta. Entonces la copia de seguridad nocturna empezó y el trabajo se congeló al pocos por ciento. El software de backup registró reintentos y mensajes de “connection reset”.
El equipo de almacenamiento juró que no era culpa suya. El equipo de red juró que el túnel estaba arriba. Ambos tenían razón y aun así estaban equivocados.

El problema: la interfaz VPN estaba en 9000, pero el uplink del ISP en medio no lo estaba. PMTUD debería haberlo gestionado, excepto que el firewall upstream
filtró los mensajes ICMP fragmentation-needed. Así que el remitente siguió transmitiendo paquetes enormes que desaparecían silenciosamente. El tráfico de control pequeño funcionaba.
El plano de datos grande moría.

La solución fue casi insultante: poner la MTU del VPN a un valor que encajara en la ruta real (o clamp de MSS en el ingreso del túnel), y permitir los tipos ICMP adecuados.
La causa raíz no era “la VPN es inestable”. Era “asumimos que Internet respeta nuestra MTU LAN”. Internet no comparte tus suposiciones.

Lo que cambió culturalmente fue más importante que la corrección técnica: añadieron un paso de validación MTU/PMTU a cada despliegue de túnel, y dejaron de tratar
ICMP como ruido opcional. Sin heroísmos. Solo menos reuniones a las 2 a.m.

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

Otra compañía tenía un servicio interno de alto rendimiento para mover artefactos entre agentes de build y una caché central. Alguien notó que las NICs,
switches y hypervisors soportaban jumbo frames. El servicio era sensible al rendimiento, así que habilitaron MTU 9000 en los servidores. Rindió bien
en benchmarks en el mismo rack. Todos asintieron.

Semanas después, un nuevo conjunto de agentes en otro DC empezó a reportar timeouts intermitentes al subir artefactos grandes. Lo doloroso:
fallaba solo para los builds “grandes”. Los builds pequeños pasaban. El equipo persiguió CPU steal, ajustes TLS y la configuración del balanceador.
Actualizaron kernels. Incluso cambiaron el nivel de compresión de artefactos. Las fallas persistieron.

La ruta de red entre DCs tenía un único segmento que seguía en MTU 1500. Los servidores con jumbo enviaban segmentos grandes,
que se fragmentaban o descartaban según el salto. Algunos flujos sobrevivían por rutas distintas. Otros morían por ECMP que elegía un camino más estricto.
Los nuevos agentes resultaron “desafortunados” con más frecuencia.

Lo arreglaron revirtiendo los jumbo frames en el servicio de artefactos y estandarizando la MTU en la ruta inter-DC antes de reactivarlo.
Los jumbo frames no eran intrínsecamente malos; eran malos como “optimización” aplicada solo a parte de la topología. La ganancia de rendimiento era real,
pero el coste de fiabilidad fue mayor del calculado.

La conclusión del postmortem fue contundente: no despliegues cambios de MTU parcialmente. O te comprometes con un diseño de extremo a extremo, o te quedas en 1500 y
gastas el presupuesto de rendimiento en otra cosa.

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

Una organización de servicios financieros tenía la costumbre que parecía burocrática: siempre que un cambio de red involucraba túneles, overlays o circuitos WAN,
exigían una lista de verificación pre-flight. Incluía una línea que a los ingenieros les encantaba odiar:
“Verificar PMTUD o aplicar clamp MSS; adjuntar evidencia.”

Durante una migración a una nueva plataforma de acceso remoto, un ingeniero ejecutó la checklist y descubrió que los pings DF grandes fallaban a través de cierta ruta de proveedor.
Los paquetes pequeños estaban bien. El borde del proveedor filtraba ciertos tipos ICMP (porque claro que sí), pero solo en una región. El ingeniero añadió clamp de MSS
en el concentrador VPN para esa región y adjuntó las capturas antes/después. La migración continuó.

Dos semanas después, otro equipo reportó “las subidas grandes se quedan colgadas” desde esa región. El de guardia abrió las notas de migración, vio el clamp de MSS y la
evidencia de prueba, y descartó de inmediato el agujero negro de MTU como causa nueva. Se centraron en una regresión de la aplicación y la arreglaron rápido.

La práctica aburrida no solo previno un outage. Previno una diagnosis errónea durante un incidente posterior, lo cual casi vale lo mismo. Buenas notas son un multiplicador operativo.

Arréglalo de forma limpia: soluciones preferidas por orden

Puedes “arreglar” desajustes MTU/MSS de muchas maneras. Solo unas pocas son limpias. Aquí está el orden que recomiendo en producción, con fuerte sesgo hacia
cambios que puedas explicar a las 3 a.m. y revertir al mediodía.

1) Corregir la consistencia de la MTU del camino (mejor, más difícil)

Si controlas la red end-to-end, estandariza la MTU a través del camino. Para overlays, incrementa la MTU del underlay para que el overlay pueda permanecer en 1500.
Ejemplo: si VXLAN añade ~50 bytes, fija la MTU del underlay a 1550+ para que el overlay pueda seguir en 1500 sin fragmentación.

Esta es la solución “hazlo bien”. También es la que requiere coordinación entre equipos y proveedores, por eso no es la única.

2) Asegurar que PMTUD funcione (permitir los ICMP correctos)

PMTUD no es opcional si esperas que las redes modernas se comporten. Permite ICMP tipo 3/código 4 en IPv4 (“fragmentation needed”).
Permite ICMPv6 “packet too big” y otros mensajes de control necesarios en IPv6.

La clave no es “permitir todo ICMP para siempre”. La clave es “no romper el protocolo y luego sorprenderte”.
Si debes limitar la tasa, hazlo con cuidado y prueba.

3) Clamp de TCP MSS en el borde (mejor solución pragmática)

El clamp de MSS ajusta el valor MSS durante SYN para que los endpoints acuerden segmentos más pequeños que quepan en la MTU del camino.
Funciona incluso cuando ICMP se filtra. No requiere cambios en hosts. Es reversible. Es fácil de acotar.

Usa clamp de MSS basado en la ruta donde sea posible (como se mostró en la tarea de nftables). Codificar MSS es aceptable cuando el entorno está desordenado,
pero trátalo como vendaje temporal.

4) Bajar la MTU del host solo cuando el host viva realmente en ese camino constreñido

Bajar la MTU en una interfaz host es limpio cuando el egress principal del host está realmente constreñido (clásico PPPoE a 1492).
No es limpio cuando solo algunos destinos están constreñidos. Entonces penalizas todo para arreglar un camino.

5) Habilitar la sondeo MTU de TCP como arreglo táctico, no como estrategia

Habilitar net.ipv4.tcp_mtu_probing puede permitir que Linux se recupere de agujeros negros sondeando MTUs más pequeñas.
Puede ayudar si no controlas el firewall en medio y necesitas alivio rápido.

Pero no confundas “el kernel sortea el problema” con “la red está sana”. Si puedes clamar MSS o arreglar ICMP, haz eso.

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

Estos son los patrones que veo en organizaciones reales. Las soluciones son específicas porque el consejo vago es como los outages se convierten en “misterios”.

1) Grandes descargas HTTPS se cuelgan, pero las páginas pequeñas cargan

Síntoma: El navegador carga el sitio; descargar un ISO se queda en unos pocos MB y se detiene.

Causa raíz: Agujero negro PMTUD: ICMP fragmentation-needed bloqueado en algún punto; el remitente sigue usando MSS/MTU demasiado grandes.

Solución: Permitir ICMP tipo 3/código 4 (IPv4) y ICMPv6 Packet Too Big; o aplicar clamp de MSS en el gateway para TCP/443.

2) SSH funciona, scp/rsync se atasca o va muy lento

Síntoma: SSH interactivo bien; copia de archivos atascada o extremadamente lenta.

Causa raíz: Paquetes de datos golpean el límite de MTU del camino; las retransmisiones explotan; los paquetes interactivos pequeños se escapan.

Solución: Confirma con ping DF; aplica clamp de MSS para TCP/22 en el camino; valida que las retransmisiones desaparecen tras el arreglo.

3) Kubernetes: algunos pods pueden descargar imágenes, otros hacen timeout

Síntoma: Nodo A bien; Nodo B falla al tirar capas grandes; reinicios “arreglan” el problema a veces.

Causa raíz: MTU mezcladas en CNI overlay/underlay; ECMP selecciona rutas distintas con MTUs efectivas diferentes.

Solución: Alinea la MTU del CNI con el underlay; o aplica clamp de MSS en la salida del nodo; estandariza MTU entre nodos.

4) “Habilitamos jumbo frames y ahora la replicación inter-DC es inestable”

Síntoma: Sesiones de replicación se reinician, transferencias grandes fallan de forma intermitente.

Causa raíz: Jumbo frames habilitados solo en algunos segmentos; un salto a 1500 causa fragmentación/descartes.

Solución: Revertir a 1500 hasta que todo el camino soporte jumbo; luego reintroducir con validación end-to-end.

5) IPv6 es más lento o falla solo para transferencias grandes

Síntoma: Host dual-stack prefiere IPv6; transferencias grandes se cuelgan mientras IPv4 funciona.

Causa raíz: ICMPv6 Packet Too Big bloqueado; routers IPv6 no fragmentan; ocurre un agujero negro.

Solución: Permitir ICMPv6 correctamente; clamp de MSS para IPv6; verifica con ping -6 y tcpdump.

6) “Pusimos MTU 1400 en todas partes” y el rendimiento se desplomó

Síntoma: Todo funciona, pero el rendimiento cayó y la CPU subió.

Causa raíz: Sobre-corrección: redujiste la MTU mucho más de lo que el camino requiere, aumentando la sobrecarga y la tasa de interrupciones.

Solución: Mide la PMTU real; establece MTU/MSS en el mínimo necesario para restaurar corrección, no en un valor supersticioso arbitrario.

Listas de verificación / plan paso a paso

Checklist A: Cuando una transferencia grande se cuelga ahora mismo

1. Reproduce con un comando (curl o scp) y registra la hora.
2. Ejecuta ping DF (IPv4) o ping grande (IPv6) al mismo destino; encuentra el payload máximo que funciona.
3. Revisa ss -ti por retransmisiones y valores MSS/PMTU durante el bloqueo.
4. Ejecuta un tcpdump corto buscando retransmisiones repetidas y faltantes mensajes ICMP “too big”.
5. Si ICMP está bloqueado y controlas el borde: aplica clamp de MSS (basado en ruta si es posible).
6. Vuelve a probar la transferencia; captura la evidencia “después”; compromete el cambio de configuración de forma persistente.

Checklist B: Antes de desplegar un túnel/overlay

1. Calcula la sobrecarga (túnel + encapsulación + posibles etiquetas VLAN) y decide la MTU objetivo.
2. Configura la MTU del underlay para soportar la MTU del overlay (preferido), o establece la MTU del overlay más baja (aceptable).
3. Confirma que ICMP/ICMPv6 necesarios para PMTUD están permitidos a través de límites de seguridad.
4. Valida con ping DF y una prueba real de transferencia masiva a través del túnel.
5. Documenta la MTU elegida, dónde se aplica y qué evidencia capturaste.

Checklist C: Guía para seleccionar la “solución limpia”

• Tú controlas todo el camino: estandariza MTU end-to-end; mantiene el overlay en 1500 si es posible; mantiene PMTUD funcionando.
• Controlas solo tu borde: clamp de MSS basado en ruta + verifica PMTU; opcionalmente ajusta MTU local para enlaces conocidos y constreñidos.
• Controlas solo un host: ajusta la MTU en la interfaz relevante si ese host siempre usa el camino constreñido; de lo contrario considera clamp local de MSS en output.

Preguntas frecuentes

1) ¿Por qué los pings tienen éxito mientras las transferencias TCP grandes fallan?

Porque los pings típicos son pequeños (payload por defecto 56 bytes). Nunca exceden la MTU del camino. Las transferencias TCP grandes usan segmentos casi MTU,
que desencadenan descartes cuando la MTU real del camino es menor.

2) ¿Esto es realmente MTU/MSS, o podría ser pérdida genérica de paquetes?

La pérdida genérica normalmente afecta todo: sesiones interactivas, descargas pequeñas, llamadas a APIs. Los agujeros negros de MTU son selectivos: lo pequeño está bien, lo grande se atasca.
Pruébalo con tests DF ping y tcpdump mostrando retransmisiones repetidas sin respuestas ICMP “too big”.

3) ¿Cuál es la diferencia entre arreglar la MTU y clamar la MSS?

Arreglar la MTU hace que el camino de red pueda llevar los paquetes que envías, de forma consistente. Clampear la MSS le dice a los endpoints TCP que envíen cargas útiles más pequeñas
para que los paquetes quepan en el camino existente. La corrección de MTU es arquitectónica; el clamp de MSS es pragmático y operativo.

4) ¿Debería simplemente poner MTU a 1400 en todas partes?

No. Puede ocultar el síntoma, pero es un impuesto al rendimiento y puede romper caminos internos que realmente soportan 1500 o jumbo frames.
Mide la PMTU real y haz el cambio más pequeño que restaure la corrección.

5) ¿Debian 13 cambia algo respecto al comportamiento de MTU?

Debian 13 usa kernels y herramientas modernas (systemd-networkd, nftables, comportamientos TCP contemporáneos). El problema no es específico de Debian.
Pero Debian 13 facilita implementar soluciones limpias (clamp MSS con nftables, configuración de red consistente) si usas la pila nativa adecuadamente.

6) ¿Es seguro permitir ICMP a través de firewalls?

“Permitir todo ICMP” es vago. “Bloquear todo ICMP” es peor. Deberías permitir los tipos esenciales de ICMP/ICMPv6 para reportes de error y PMTUD,
idealmente con límites de tasa. Si los bloqueas, rompes comportamiento básico de Internet y lo pagarás en incidentes.

7) ¿A qué valor de MSS debo clamar?

Prefiere el clamp de MSS basado en ruta (set rt mtu) para que se adapte. Si debes codificar, calcula a partir de la MTU del camino:
MSS IPv4 ≈ MTU-40, MSS IPv6 ≈ MTU-60 (dependiendo de opciones). Si dudas, elige un valor conservador y luego afina con mediciones.

8) ¿Por qué falla solo con algunos destinos?

Diferentes destinos pueden atravesar rutas distintas (ECMP, peers distintos, puntos de salida VPN distintos), cada uno con un cuello de botella MTU o comportamiento de filtrado ICMP distinto.
Por eso un host puede “funcionar hacia A y fallar hacia B”.

9) ¿Pueden los middleboxes reescribir ya la MSS?

Sí. Algunos firewalls y balanceadores de carga clampan MSS automáticamente. Eso puede ocultar el problema—o hacerlo más extraño si solo algunas rutas clampan.
Trata la MSS como algo que puede cambiar en tránsito y verifica con capturas tcpdump de opciones SYN.

10) ¿Y si esto es UDP (como tráfico de almacenamiento o streaming)?

El clamp de MSS es solo para TCP. Para cargas UDP necesitas un dimensionamiento correcto de MTU y/o control de fragmentación a nivel de aplicación.
En la práctica, arregla la MTU del camino o configura la aplicación para usar datagramas más pequeños.

Próximos pasos que puedes hacer hoy

Si ves que las transferencias grandes se cuelgan en Debian 13, trátalo como un fallo real de red, no como una historia de fantasmas.
Haz tres cosas, en este orden:

1. Prueba la MTU del camino. Ejecuta tests DF ping (IPv4) y/o pruebas IPv6 “packet too big”. Captura el tamaño máximo que funciona.
2. Captura evidencia. Un tcpdump de 30 segundos mostrando retransmisiones repetidas y faltantes ICMP vale más que mil discusiones en Slack.
3. Aplica una solución limpia. Preferido: arreglar la consistencia de MTU y permitir ICMP de PMTUD. Si no puedes, aplica clamp de MSS en el borde con nftables.

Después del arreglo, vuelve a ejecutar la misma prueba de transferencia masiva, guarda las salidas y las capturas con el registro del cambio. La diferencia entre
“lo arreglamos” y “tuvimos suerte” es documentación y repetibilidad. Además, el tú del futuro estará cansado.