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
- 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 |
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.
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 |
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.
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.
