Optimización Jumbo Frames en ESXi y NAS: MTU 9000 para Estabilidad en Producción
Tabla de contenido
En entornos de misión crítica en México, donde el cumplimiento normativo exige una disponibilidad impecable, la red no puede ser el eslabón débil. Configurar Jumbo Frames en ESXi no es un lujo decorativo; es una decisión de ingeniería de infraestructura diseñada para obtener esa paz mental que solo da un almacenamiento estable y veloz.
¿Qué son los Jumbo Frames y por qué importan?
Toda información en la red viaja en paquetes llamados frames. El tamaño estándar (MTU) es de 1500 bytes. Cualquier valor superior es un Jumbo Frame.
En arquitecturas modernas de 10 Gbps o superiores, usar un MTU de 9000 reduce drásticamente la fragmentación de datos y el consumo de CPU. Es la diferencia entre transportar arena en cubetas o hacerlo en un camión de volteo: menos viajes, más eficiencia.

Si quieren obtener más detalles sobre esta función, les recomiendo hacer una búsqueda rápida y leer hasta que su sed de conocimiento sea saciada.
Escenarios Críticos: ¿Cuándo implementarlos?
Para un SysAdmin en la trinchera, los Jumbo Frames son obligatorios en:
- Almacenamiento iSCSI/NFS: Para evitar latencia en la data de tus VMs.
- vMotion: Para que las migraciones en vivo no tarden una eternidad.
- Bases de Datos en RAC: Donde la interconectividad es el corazón del servicio.
- Respaldos Masivos: Crucial para cumplir con los tiempos de recuperación (RTO) locales.
Jumbo Frames en ESXi y NAS
Para este artículo usaremos de ejemplo un ambiente de virtualización incorporado por lo siguiente:
| Dispositivo | S.O. | Puertos | Hostname | IP |
| Switch Capa 2 | — | 10 Gbps | SWMC2 | — |
| Servidor | VMware ESXi | Uno a 10 Gbps | Nodo1 | 192.168.0.2 |
| Servidor | VMware ESXi | Uno a 10 Gbps | Nodo2 | 192.168.0.3 |
| Storage NAS | — | Dos a 10 Gbps | SNAS10 | 192.168.0.4
192.168.0.5 |
Nuestro objetivo será mejorar la comunicación entre los servidores ESXi y el Storage NAS debido a que en esa comunicación viajan paquetes de gran tamaño (La data de los discos virtuales de cada VM)
[PASO] Configuración de punta a punta (End-to-End)
La configuración debe ser simétrica. Si un solo punto en el camino (Switch, NIC, Storage) no soporta MTU 9000, los paquetes se fragmentarán o se perderán.
| Dispositivo | S.O. | Interfaz | MTU Sugerido |
| Switch Capa 2 | OS Propietario | 10 Gbps Trunk/Access | 9216 |
| Servidor Nodo 1 | VMware ESXi | vmk (VMkernel) | 9000 |
| Storage NAS | Storage OS | Bond/LACP | 9000 |
En el switch siempre configuramos un poco más (9216) para dar margen a los encabezados de capa 2 y evitar el descarte de paquetes.
Para configurar en ESXi puedes consultar este artículo Enable Jumbo Frames for a VMkernel Adapter
[SOLUCIÓN] Cómo validar la comunicación real
La prueba es tan sencilla como hacer uso del comando ping, sólo se tiene que agregar algunos parámetros para especificar que se usa paquetes de mayor tamaño.
Hablando técnicamente: lo que se hace es definir el tamaño de la carga ICMP; tomando en cuenta que ICMP usa 8 bytes para su encabezado y 20 bytes para su encabezado IP.

En base a lo anterior (y suponiendo que ingresas a los servidores ESXi mediante SSH) hacemos la prueba con el comando vmkping (El equivalente de ping para los ESXi)
Respuesta satisfactoria
# vmkping -s 8972 -d 192.168.0.2 PING 192.168.0.2 (192.168.0.2): 8972 data bytes 8980 bytes from 192.168.0.2: icmp_seq=0 ttl=64 time=0.446 ms 8980 bytes from 192.168.0.2: icmp_seq=0 ttl=64 time=0.479 ms 8980 bytes from 192.168.0.2: icmp_seq=0 ttl=64 time=0.477 ms
# vmkping -s 8972 -d 192.168.0.4 PING 192.168.0.4 (192.168.0.2): 8972 data bytes 8980 bytes from 192.168.0.4: icmp_seq=0 ttl=64 time=0.446 ms 8980 bytes from 192.168.0.4: icmp_seq=0 ttl=64 time=0.479 ms 8980 bytes from 192.168.0.4: icmp_seq=0 ttl=64 time=0.477 ms
Error de comunicación
La siguiente respuesta se puede dar si algún puerto no está conectado correctamente o hace falta alguna otra configuración que impide la comunicación.
PING xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx): 8184 data bytes Request timeout for icmp_seq 0
Prueba en Linux, MacOS y Windows (PowerShell)
La siguiente respuesta se puede dar si el MTU no está configurado en alguno de los puntos de comunicación
PING xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx): 8184 data bytes ping: sendto: Message too long
Como extra, en otros sistemas operativos la sintaxis del comando ping es la siguiente:
MacOS
# ping -D -s 8184 [IP]
Windows
# ping -f -l 9000 [IP]
Linux
# ping -M do -s 8972 [IP]
Conclusiones
Optimizar con Jumbo Frames es como abrir la llave de una tubería al máximo. Sin esto, en cargas de trabajo pesadas, enfrentarás desconexiones de storage, lentitud general y, en el peor de los casos, caídas del servicio en horas pico.
Referencias



Deja una respuesta