MTU: el paquete que funciona en casa y desaparece dentro del tunel

Hay fallos de red especialmente crueles porque imitan la normalidad. El ping responde. La conexion TCP abre. Incluso una peticion pequena devuelve un 200. Pero al descargar una imagen, negociar ciertos certificados o mover una respuesta mas grande, todo se congela. No parece una caida: parece una aplicacion caprichosa.

Una causa clasica es la MTU. Ethernet suele permitir una trama de 1500 bytes, pero un paquete que cruza un tunel necesita cargar cabeceras adicionales. VXLAN, Geneve, WireGuard o una capa de nube consumen parte de ese espacio. Si dentro del tunel intentas transportar el mismo paquete que cabia antes, ya no cabe igual.

La escena en Kubernetes

Un pod en un nodo habla con un pod en otro. Desde la aplicacion todo parece una IP contra otra IP. Por debajo, el CNI puede encapsular el trafico para llevarlo entre nodos. Ese envoltorio cuesta bytes. Si la interfaz del pod, del nodo y de la red inferior no estan de acuerdo, llegan los sintomas raros: solicitudes pequenas funcionan y respuestas grandes se pierden o se fragmentan donde no deberian.

Antes de tocar el cluster, miro los tamaños que cada capa anuncia:

ip link show
ip -d link show
ip route get 10.244.2.17

Despues hago una prueba deliberada, impidiendo fragmentacion y variando el tamaño:

ping -M do -s 1472 10.244.2.17
ping -M do -s 1372 10.244.2.17

En IPv4, los 1472 bytes sumados a la cabecera ICMP e IP se acercan a una MTU de 1500. Si el paquete grande muere y uno menor cruza, ya no estas persiguiendo una sensacion: tienes una hipotesis concreta sobre el camino.

El error de arreglarlo a ciegas

Bajar la MTU hasta que “funcione” puede ocultar el incidente, pero no explica que capa estaba mintiendo. En una plataforma vale la pena escribir el mapa: MTU de la red fisica, overhead del tunel, MTU que el CNI entrega a los pods y cualquier salto adicional hacia VPN, balanceador o servicio externo. Esa tabla pequeña evita semanas de fallos intermitentes.

Tambien conviene recordar Path MTU Discovery. Para que el origen ajuste el tamaño, ciertos mensajes ICMP deben poder volver. Una regla de firewall que bloquea todo ICMP puede convertir un paquete demasiado grande en un agujero negro: nadie avisa, simplemente deja de llegar.

Lo que parece un bug de aplicacion puede ser una cuestion muy fisica: cuantos bytes caben en el camino real. Entenderlo es una de esas habilidades de networking que cambia para siempre como miras un timeout.

Referencia: el comportamiento de Path MTU Discovery esta definido en RFC 1191; la configuracion concreta del encapsulado depende del CNI y de la red donde corre el cluster.