Starlink MTU size: la path MTU medida fue de 1500 bytes

Los paquetes de 1500 bytes llegaron a los tres hosts de prueba, por IPv4 y por IPv6

La unidad máxima de transmisión (MTU) de un enlace es el paquete más grande que lleva de una sola pieza, y la MTU de una ruta (path MTU) es la menor MTU de enlace a lo largo de ella. RFC 8201 la define como la MTU de enlace mínima de todos los enlaces de una ruta entre un nodo de origen y un nodo de destino ("the minimum link MTU of all the links in a path between a source node and a destination node"; sección 2, consultado en octubre de 2026).

La prueba se hizo en octubre de 2026 desde un equipo conectado por cable a la red de casa, en una conexión doméstica de Starlink, en dos lecturas separadas por unos minutos. Todas las rutas hacia los hosts de prueba salían por la interfaz cableada, así que ni una VPN, ni un nodo de salida ni un túnel llevaron el tráfico. En cada lectura, para cada host, por IPv4 y por IPv6, tracepath se ejecutó hasta el final. Después salieron tres pings del tamaño justo para formar paquetes de 1500 bytes, con DF (no fragmentar) activado y un tiempo de espera de respuesta de 2 segundos. Otros tres, del tamaño justo para formar paquetes de 1501 bytes, los rechazó el equipo antes de enviarlos.

Los tres hosts son máquinas públicas que sus operadores ofrecen para pruebas de red (cada página consultada en octubre de 2026):

• scanme.nmap.org, que el proyecto Nmap montó para que la gente pueda probar y asegurarse de que su instalación de Nmap (o su conexión a internet) funciona bien ("test and make sure that their Nmap installation (or Internet connection) is working properly");
• speedtest.newark.linode.com, cuya página principal se titula "Linode, now Akamai, Speedtest";
• proof.ovh.net, un host de OVHcloud para pruebas de velocidad de red.

El descubrimiento de la MTU de la ruta empieza por la MTU del primer enlace del emisor. Por IPv4, el emisor activa el bit Don't Fragment (DF, no fragmentar), y un router que no puede reenviar entero un paquete así lo descarta y devuelve un mensaje ICMP que significa que hace falta fragmentar y DF está activado ("fragmentation needed and DF set"; RFC 1191, sección 2, consultado en octubre de 2026). Por IPv6, un router que no puede reenviar un paquete porque es mayor que la MTU del siguiente enlace debe devolver un mensaje Packet Too Big (paquete demasiado grande; RFC 4443, sección 3.2, consultado en octubre de 2026). En ambos casos, el emisor baja su estimación (RFC 8201, sección 3). tracepath traza una ruta descubriendo la MTU a lo largo de ella ("discovering MTU along this path") y muestra la MTU de la ruta allí donde cambia (iputils 20250605, consultado en octubre de 2026). En todas las trazas de esta prueba se mantuvo en 1500 de principio a fin, y ningún ping provocó un mensaje de paquete demasiado grande ("too big"), así que ningún salto informó de una MTU menor.

Los pings comprueban lo mismo de extremo a extremo. Cada ping de 1500 bytes llegó a su host y su respuesta volvió. Eso cubre los saltos que no responden a tracepath, que solo los pings prueban. Y la ruta empieza en el router de casa, así que la configuración del propio router forma parte del resultado: nada en estas rutas, incluidos el router de casa y la red de Starlink, recortaba los paquetes por debajo de 1500 bytes en ese momento.

Por IPv4, las trazas empezaron con el mismo tipo de saltos que la traza de la guía sobre alojar un servidor sin una dirección IPv4 pública, que esta página no repite.

Un ping de 1472 bytes es un paquete IPv4 de 1500 bytes

La opción -s de ping fija el número de bytes de datos, y ICMP les añade una cabecera de 8 bytes (ping(8), iputils 20250605, consultado en octubre de 2026). Un mensaje de eco ICMPv6 también tiene 8 bytes antes de sus datos: tipo, código, suma de comprobación, identificador y número de secuencia (RFC 4443, sección 4.1, consultado en octubre de 2026). Una cabecera IPv4 mínima ocupa 20 bytes, y una cabecera IPv6, 20 bytes más: 40 (RFC 8200, sección 8.3, consultado en octubre de 2026).

Un ping con DF activado que recibe respuestas con 1472 bytes de datos por IPv4 significa que un paquete de 1500 bytes cruzó la ruta. 1472 es la carga útil del ping, y la MTU es el paquete entero.

Por IPv6, los routers nunca dividen un paquete: en IPv6, la fragmentación la hacen solo los nodos de origen, dice RFC 8200 ("fragmentation in IPv6 is performed only by source nodes"; sección 4.5). Así que un ping IPv6 de 1500 bytes o cruza entero o se encuentra con un router que debe responder con un mensaje Packet Too Big (RFC 4443, sección 3.2).

Para repetir la prueba en Linux con iputils, ejecuta estos comandos, que aquí se muestran con uno de los tres hosts:

tracepath -4 -n scanme.nmap.org
ping -4 -M do -n -c 3 -W 2 -s 1472 scanme.nmap.org
tracepath -6 -n scanme.nmap.org
ping -6 -M do -n -c 3 -W 2 -s 1452 scanme.nmap.org

-M do activa DF, -c 3 envía tres pings y -W 2 fija un tiempo de espera de respuesta de 2 segundos (ping(8)). La página de Nmap pide a los visitantes que no abusen de su host: unos pocos escaneos al día están bien ("A few scans in a day is fine"). Los comandos ping de otros sistemas usan otras opciones, y esta página no los cubre.

Los paquetes de 1501 bytes nunca salieron del equipo

En un equipo cuya propia MTU de enlace es de 1500 bytes, un ping con -M do y 1473 bytes de datos (IPv4) o 1453 (IPv6) que falla al instante, con un error local que dice que el mensaje es demasiado largo para una MTU de 1500, lo rechazó ese mismo equipo. El fallo no dice nada de tu proveedor.

Si el error nombra una MTU menor que 1500, esa interpretación no se aplica. El equipo está comparando el paquete con un límite más bajo que el de su enlace, y ese límite puede venir de la ruta: un emisor baja su estimación tras un mensaje de paquete demasiado grande ("too big") de un router (RFC 1191, sección 2; RFC 8201, sección 3).

Las herramientas de túnel cuentan las cabeceras de WireGuard como 80 bytes

En el kernel de Linux, una interfaz nueva de WireGuard recibe dev->mtu = ETH_DATA_LEN - overhead (device.c, Linux 6.18). ETH_DATA_LEN vale 1500, la carga útil máxima de Ethernet (if_ether.h). La sobrecarga es el mensaje de datos más pequeño de WireGuard, más una cabecera UDP de 8 bytes (RFC 768) y la mayor de las cabeceras IPv6 e IPv4, los 40 bytes de IPv6 (RFC 8200). Ese mensaje ocupa 32 bytes: un tipo de 4 bytes, un índice de clave de 4 bytes, un contador de 8 bytes y una etiqueta de autenticación de 16 bytes (messages.h, con el tamaño de la etiqueta en chacha20poly1305.h). Así que la sobrecarga es de 80 bytes, y la interfaz empieza en 1420. Todo consultado en octubre de 2026.

La etiqueta va después de los datos cifrados: en el AEAD (cifrado autenticado con datos asociados) de RFC 8439, la salida es el texto cifrado y después la etiqueta (sección 2.8, consultado en octubre de 2026).

wg-quick en Linux usa la línea MTU de la configuración de la interfaz cuando la hay. Sin ella, el script lee la MTU de las rutas hacia los endpoints de los pares, recurre después a la de la ruta por defecto y luego a 1500, y fija la interfaz 80 bytes por debajo (linux.bash, wireguard-tools v1.0.20250521, consultado en octubre de 2026). En una ruta de 1500 bytes, eso da 1420.

Tailscale cuenta los mismos 80 bytes para el peor caso, una cabecera exterior IPv6. Su lista es una cabecera IPv4 de 20 bytes o IPv6 de 40 bytes ("20-byte IPv4 header or 40-byte IPv6 header"), una cabecera UDP de 8 bytes, un tipo de 4 bytes, un índice de clave de 4 bytes, un nonce de 8 bytes y una etiqueta de autenticación de 16 bytes (mtu.go, Tailscale v1.90.0, consultado en octubre de 2026). En este archivo el tamaño no depende del enlace: DefaultTUNMTU(), que el archivo usa para fijar la MTU de la interfaz, devuelve 1280, su MTU segura ("safe") por defecto, salvo que el ajuste de depuración TS_DEBUG_MTU indique otro tamaño. Devuelve 1280 incluso con TS_DEBUG_ENABLE_PMTUD, el ajuste de depuración para sondear la MTU de la ruta, activado. Con los 80 bytes añadidos, 1280 son 1360 bytes en el cable. 1280 es también la MTU más pequeña que IPv6 permite en cualquier enlace (RFC 8200, sección 5).

Las rutas de esta prueba llevaron paquetes de 1500 bytes. Ningún túnel funcionó sobre ellas, así que esta página no muestra qué hicieron los paquetes de un túnel.

Cuando un paquete es demasiado grande para un enlace y el mensaje de paquete demasiado grande nunca llega al emisor, RFC 8201 describe conexiones que completan correctamente el saludo de tres vías de TCP, pero luego se cuelgan al transferir datos ("complete the TCP three-way handshake correctly but then hang when data is transferred"; sección 1). Esta prueba no buscó eso.

Sin probar aquí

• La MTU de un túnel sobre esta conexión, para WireGuard, Tailscale o una VPN del trabajo. Tampoco se ha probado si cambiar una MTU arregla un problema de VPN.
• Un máximo o un valor por defecto. Nada por encima de 1500 bytes pudo salir del equipo de prueba, así que esta página no muestra ningún máximo. Las páginas de Starlink sobre la MTU no se han leído para esta página, así que tampoco muestra ningún valor por defecto.
• Wi-Fi. Ambas lecturas se hicieron por un enlace cableado.
• Otras conexiones y otros momentos. Las dos lecturas estuvieron separadas por unos minutos, y la MTU de una ruta puede cambiar con el tiempo, debido a cambios en la topología de enrutamiento ("may change over time, due to changes in the routing topology"; RFC 8201, sección 3).

Consulta cómo encaja esto con las demás pruebas en casa, para un homelab.