VMware, al igual que cualquier superposición, impone una sobrecarga adicional en el tráfico que atraviesa la red. En esta sección, primero se describe la sobrecarga que se agrega en una red IPSec tradicional y cómo se compara con VMware, seguido por una explicación de cómo esta sobrecarga adicional se relaciona con los comportamientos de fragmentación de paquetes y MTU en la red.

Sobrecarga de túnel de IPSec

En una red IPSec tradicional, el tráfico generalmente se transporta en un túnel de IPSec entre endpoints. Un escenario de túnel IPSec estándar (cifrado AES de 128 bits que utiliza ESP (Carga de seguridad encapsuladora)) al cifrar el tráfico, genera varios tipos de sobrecarga de la siguiente manera:
  • Relleno (Padding)
    • AES cifra los datos en bloques de 16 bytes, lo que se conoce como tamaño de "bloque".
    • Si el cuerpo de un paquete es menor o indivisible por el tamaño de bloque, se rellena para que coincida con el tamaño de bloque.
    • Ejemplos:
      • Un paquete de 1 byte se convertirá en 16 bytes con un relleno de 15 bytes.
      • Un paquete de 1400 bytes se convertirá en 1408 bytes con un relleno de 8 bytes.
      • Un paquete de 64 bytes no requiere ningún relleno.
  • Encabezados y finalizadores de IPSec (IPsec headers and trailers):
    • Encabezado de UDP para NAT transversal (NAT-T).
    • Encabezado de IP para el modo de túnel de IPSec.
    • Encabezado y finalizador de ESP.
Elemento Tamaño en bytes
Encabezado de IP 20
Encabezado de UDP 8
Número de secuencia de IPSec 4
SPI de IPSec 4
Vector de inicialización 16
Relleno 0 – 15
Longitud de relleno 1
Siguiente encabezado 1
Datos de autenticación 12
Total 66-81
Nota: Los ejemplos proporcionados asumen que al menos un dispositivo se encuentra detrás de un dispositivo NAT. Si no se utiliza ninguna NAT, la sobrecarga de IPSec es de 20 bytes menos, ya que no se requiere NAT-T. No se produce ningún cambio en el comportamiento de VMware, independientemente de si NAT está presente o no (NAT-T siempre está activado).

Sobrecarga de túnel de VMware

Para admitir Dynamic Multipath Optimization™ (DMPO), VMware encapsula paquetes en un protocolo denominado VeloCloud Multipath Protocol (VCMP). VCMP agrega 31 bytes de sobrecarga para los paquetes de usuarios a fin de admitir la resecuenciación, la corrección de errores, el análisis de red y la segmentación de redes dentro de un solo túnel. VCMP funciona en un puerto registrado por IANA de UDP 2426. Para garantizar un comportamiento coherente en todos los escenarios potenciales (sin cifrar, cifrado y detrás de una NAT, cifrado pero no detrás de una NAT), VCMP se cifra mediante IPSec de modo de transporte y fuerza a NAT-T a cumplir con un puerto NAT-T especial de 2426.

Los paquetes que se envían a Internet a través de SD-WAN Gateway no están cifrados de forma predeterminada, ya que entran en la red Internet abierta al salir de la puerta de enlace. Como resultado, la sobrecarga del tráfico Multipath de Internet es menor que el tráfico de VPN.

Nota: Los proveedores de servicios tienen la opción de cifrar el tráfico de Internet a través de la puerta de enlace y, si optan por utilizar esta opción, la sobrecarga de "VPN" se aplica también al tráfico de Internet.

Tráfico de VPN (VPN Traffic)

Elemento Tamaño en bytes
Encabezado de IP 20
Encabezado de UDP 8
Número de secuencia de IPSec 4
SPI de IPSec 4
Encabezado de VCMP 23
Encabezado de datos de VCMP 8
Vector de inicialización 16
Relleno 0 – 15
Longitud de relleno 1
Siguiente encabezado 1
Datos de autenticación 12
Total 97–112

Tráfico Multipath de Internet (Internet Multipath Traffic)

Elemento Tamaño en bytes
Encabezado de IP 20
Encabezado de UDP 8
Encabezado de VCMP 23
Encabezado de datos de VCMP 8
Total 59

Impacto del túnel IPv6 en la MTU

VMware SD-WAN admite direcciones IPv6 para configurar las interfaces de Edge y la superposición de WAN de Edge.

El túnel de VCMP se puede configurar en los siguientes entornos: solo IPv4, solo IPv6 y doble pila. Para obtener más información, consulte Configuración de IPv6.

Cuando una sucursal tiene al menos un túnel IPv6, DMPO utiliza este túnel perfectamente integrado junto con otros túneles IPv4. Los paquetes de cualquier flujo específico pueden utilizar cualquier túnel, IPv4 o IPv6, según el estado en tiempo real del túnel. Un ejemplo de flujo específico es la puntuación de selección de ruta de acceso para el tráfico con equilibrio de carga. En estos casos, se debe tener en cuenta el mayor tamaño del encabezado IPv6 (20 bytes adicionales) y, como resultado, la MTU efectiva de la ruta de acceso será inferior en 20 bytes. Además, esta MTU efectiva reducida se propagará a las otras sucursales remotas a través de Gateway para que las rutas entrantes en esta sucursal local desde otras sucursales remotas reflejen la MTU reducida.

Detección de MTU de ruta de acceso (Path MTU Discovery)

Una vez que se determina la cantidad de sobrecarga que se aplicará, SD-WAN Gateway debe detectar la MTU máxima permitida para calcular la MTU efectiva para los paquetes de clientes. Para encontrar la MTU máxima permitida, Edge realiza la detección de MTU de ruta:

  • Para los vínculos de WAN de Internet públicos:
    • La detección de MTU de ruta se lleva a cabo en todas las puertas de enlace.
    • La MTU de todos los túneles se establecerá en la MTU mínima detectada.
  • Para los vínculos de WAN privados:
    • La detección de MTU de ruta se lleva a cabo en todas las demás instancias de Edge de la red del cliente.
    • La MTU de cada túnel se establece en función de los resultados de la detección de MTU de la ruta de acceso.

La instancia de Edge intentará primero realizar la detección de MTU de ruta de RFC 1191, en la que un paquete de MTU del vínculo conocido actual (valor predeterminado: 1500 bytes) se envía al par con el bit "no fragmentar" (DF) establecido en el encabezado de IP. Si este paquete se recibe en la puerta de enlace o la instancia de Edge remota, se devuelve un paquete de confirmación del mismo tamaño a la instancia de Edge. Si el paquete no puede acceder a la puerta de enlace o la instancia de Edge remota debido a restricciones de MTU, se espera que el dispositivo intermedio envíe un mensaje que indica que el destino de ICMP es inaccesible y que se necesita llevar a cabo una fragmentación. Cuando Edge recibe el mensaje de ICMP inaccesible, valida el mensaje (para asegurarse de que el valor de MTU del que se informa es válido) y, una vez validado, ajuste el valor de MTU. A continuación, el proceso se repite hasta que se detecta la MTU.

En algunos casos (por ejemplo, llaves USB LTE), el dispositivo intermedio no enviará un mensaje de ICMP inaccesible, incluso aunque el paquete sea demasiado grande. Si se produce un error en RFC 1191 (la instancia de Edge no recibió una confirmación o no se puede acceder a ICMP), se revertirá a la detección de MTU de ruta de la capa de paquetes de RFC 4821. Edge intentará realizar una búsqueda binaria para detectar la MTU.

Cuando se detecta una MTU para un elemento del mismo nivel, todos los túneles a este elemento del mismo nivel se establecen en la misma MTU. Esto significa que si una instancia de Edge tiene un vínculo con una MTU de 1400 bytes y un vínculo con una MTU de 1500 bytes, todos los túneles tendrán una MTU de 1400 bytes. Esto garantiza que los paquetes se puedan enviar en cualquier túnel en cualquier momento mediante la misma MTU. Nos referimos a esto como MTU de Edge efectiva (Effective Edge MTU). En función del destino (VPN o Multipath de Internet), la sobrecarga que se describe anteriormente se resta para calcular la MTU de Edge efectiva (Effective Edge MTU). Para el tráfico directo de Internet u otro tipo de tráfico subyacente, la sobrecarga es de 0 bytes y, debido a que no se requiere la conmutación por error del vínculo, la MTU de paquete efectiva es idéntica a la MTU del vínculo WAN detectado.

Nota: La detección de MTU de ruta de la capa de paquetes de RFC 4821 medirá la MTU hasta un mínimo de 1300 bytes. Si la MTU es inferior a 1300 bytes, debe configurar manualmente la MTU.

Tráfico de VPN y MTU

Ahora que SD-WAN Gateway detectó el valor de MTU y calculó las sobrecargas, se puede calcular una MTU efectiva para el tráfico de cliente. La instancia de Edge intentará aplicar esta MTU de la manera más eficaz posible para los distintos tipos de tráfico recibidos.

Tráfico de TCP (TCP Traffic)

La instancia de Edge realiza automáticamente el ajuste de MSS de TCP (tamaño de segmento máximo) para los paquetes TCP recibidos. A medida que los paquetes SYN y SYN|ACK atraviesan la instancia de Edge, MSS se reescribe en función de la MTU de paquete efectiva.

Tráfico no TCP sin conjunto de bits de DF (Non-TCP Traffic without DF bit set)

Si el paquete es más grande que la MTU de paquete efectiva, la instancia de Edge realiza automáticamente la fragmentación de direcciones IP según RFC 791.

Tráfico no TCP con conjunto de bits de DF (Non-TCP Traffic with DF bit set)

Si el paquete es mayor que la MTU de paquete efectiva:

  • La primera vez que se recibe un paquete para este flujo (IP 5-tupla), la instancia de Edge coloca el paquete y envía un mensaje que indica que el destino de ICMP es inaccesible y que se necesita llevar a cabo una fragmentación, según RFC 791.
  • Si se reciben paquetes posteriores para el mismo flujo que siguen siendo demasiado grandes, estos paquetes se fragmentan en varios paquetes de VCMP y vuelven a montarse de forma transparente antes de la entrega en el extremo remoto.

Limitación de tramas gigantes

VMware SD-WAN no admite tramas gigantes a partir de la versión 5.0. La MTU de IP máxima admitida para los paquetes enviados a través de la superposición sin fragmentación es 1500.