O VMware, como qualquer sobreposição, impõe um overhead adicional no tráfego que atravessa a rede. Esta secção descreve primeiro o overhead adicionado numa rede IPsec tradicional e como este se compara ao VMware, seguida de uma explicação de como este overhead adicionado diz respeito aos comportamentos de fragmentação de MTU e pacotes na rede.
Overhead do túnel IPsec
- Padding
- O AES encripta dados em blocos de 16 bytes, referidos como tamanho de “bloco”.
- Se o corpo de um pacote for menor ou indivisível pelo tamanho do bloco, este será preenchido para corresponder ao tamanho do bloco.
- Exemplos:
- Um pacote de 1 byte tornar-se-á num de 16 bytes com 15 bytes de preenchimento.
- Um pacote de 1400 byte tornar-se-á num de 1408 bytes com 8 bytes de preenchimento.
- Um pacote de 64 bytes não requer nenhum preenchimento.
- Cabeçalhos e trailers IPsec:
- Cabeçalho UDP para NAT Traversal (NAT-T).
- Cabeçalho IP para o modo de túnel IPsec.
- Cabeçalho e trailer ESP.
| Elemento | Tamanho em bytes |
|---|---|
| Cabeçalho IP | 20 |
| Cabeçalho UDP | 8 |
| Número da sequência do IPsec | 4 |
| SPI do IPsec | 4 |
| Vetor de inicialização | 16 |
| Padding | 0–15 |
| Comprimento do padding | 1 |
| Próximo cabeçalho | 1 |
| Dados de autenticação | 12 |
| Total | 66-81 |
Overhead do túnel do VMware
Para suportar o Dynamic Multipath Optimization™ (DMPO), o VMware encapsula pacotes num protocolo denominado VeloCloud Multipath Protocol (VCMP). O VCMP adiciona 31 bytes de overhead para os pacotes de utilizador para suportar a nova sequenciação, correção de erros, análise de rede e segmentação de rede dentro de um único túnel. O VCMP opera numa porta registada na IANA de UDP 2426. Para garantir um comportamento consistente em todos os cenários potenciais (não encriptados, encriptados e atrás de um NAT, encriptado mas não atrás de um NAT), o VCMP é encriptado utilizando o modo de transporte IPsec e obriga o NAT-T a ser verdadeiro com uma porta NAT-T especial de 2426.
Os pacotes enviados para a Internet através do SD-WAN Gateway não são encriptados por predefinição, uma vez que irão sair para a Internet aberta ao sair do gateway. Como resultado, o overhead para o tráfego multicaminho da Internet é inferior ao tráfego VPN.
Tráfego de VPN
| Elemento | Tamanho em bytes |
|---|---|
| Cabeçalho IP | 20 |
| Cabeçalho UDP | 8 |
| Número da sequência do IPsec | 4 |
| SPI do IPsec | 4 |
| Cabeçalho VCMP | 23 |
| Cabeçalho de dados VCMP | 8 |
| Vetor de inicialização | 16 |
| Padding | 0–15 |
| Comprimento do padding | 1 |
| Próximo cabeçalho | 1 |
| Dados de autenticação | 12 |
| Total | 97 – 112 |
Tráfego multicaminho da Internet
| Elemento | Tamanho em bytes |
|---|---|
| Cabeçalho IP | 20 |
| Cabeçalho UDP | 8 |
| Cabeçalho VCMP | 23 |
| Cabeçalho de dados VCMP | 8 |
| Total | 59 |
Impacto do túnel IPv6 no MTU
O VMware SD-WAN suporta endereços IPv6 para configurar as definições de interfaces Edge e Overlay WAN Edge.
O túnel VCMP pode ser configurado nos seguintes ambientes: apenas IPv4, apenas IPv6 e pilha dupla. Para obter mais informações, consulte Definições de IPv6.
Quando um ramo tem, pelo menos, um túnel IPv6, o DMPO utiliza este túnel sem problemas juntamente com outros túneis IPv4. Os pacotes para qualquer fluxo específico podem escolher qualquer túnel, IPv4 ou IPv6, com base na condição em tempo real do túnel. Um exemplo para o fluxo específico é a pontuação da seleção do caminho para o tráfego com equilíbrio de carga. Nesses casos, o aumento da dimensão do cabeçalho IPv6 (20 bytes adicionais) deve ser tomado em consideração e, consequentemente, o MTU do caminho efetivo terá menos 20 bytes. Além disso, este MTU efetivo reduzido será propagado aos outros ramos remotos através do Gateway, de modo que os caminhos de entrada para este ramo local a partir de outros ramos remotos reflitam o MTU reduzido.
Path MTU Discovery
Depois de ser determinado quanto overhead será aplicado, o SD-WAN Edge deve descobrir o MTU máximo admissível para calcular o MTU eficaz para os pacotes de clientes. Para encontrar o MTU máximo admissível, o Edge executa o Path MTU Discovery:
- Para ligações WAN públicas à Internet:
- O Path MTU Discovery é realizado a todos os gateways.
- O MTU para todos os túneis será definido para o MTU mínimo descoberto.
- Para ligações WAN privadas:
- O Path MTU Discovery é realizado para todos os outros Edges na rede de clientes.
- O MTU para cada túnel é definido com base nos resultados do Path MTU Discovery.
O Edge tentará pela primeira vez o Path MTU Discovery definido na RFC 1191, onde um pacote MTU da ligação atual conhecida (predefinição: 1500 bytes) é enviado para o par com o bit DF (Don't Fragment – Não fragmentar) definido no cabeçalho IP. Se este pacote for recebido no Edge ou gateway remoto, um pacote de reconhecimento do mesmo tamanho será devolvido ao Edge. Se o pacote não conseguir aceder ao Edge ou ao gateway remoto devido a restrições de MTU, espera-se que o dispositivo intermédio envie uma mensagem de destino ICMP inacessível (fragmentação necessária). Quando o Edge receber a mensagem de ICMP inacessível, este validará a mensagem (para garantir que o valor MTU reportado é válido) e, uma vez validado, ajuste o MTU. O processo repete-se até que o MTU seja descoberto.
Nalguns casos (por ex., dongles USB LTE), o dispositivo intermédio não enviará uma mensagem de ICMP inacessível mesmo que o pacote seja demasiado grande. Se a RFC 1191 falhar (o Edge não recebeu um reconhecimento ou ICMP inacessível), este voltará para a RFC 4821 Packetization Layer Path MTU Discovery. O Edge tentará realizar uma pesquisa de binário para descobrir o MTU.
Quando um MTU é descoberto para um par, todos os túneis para este par são definidos para o mesmo MTU. Isto significa que se um Edge tiver uma ligação com um MTU de 1400 bytes e uma ligação com um MTU de 1500 bytes, todos os túneis terão um MTU de 1400 bytes. Isto garante que os pacotes podem ser enviados em qualquer túnel a qualquer momento utilizando o mesmo MTU. Referimo-nos a isto como o MTU Edge eficaz (Effective Edge MTU). Com base no destino (VPN ou multicaminho de Internet) o overhead acima descrito é subtraído para calcular o MTU de pacote eficaz (Effective Packet MTU). Para a Internet direta ou outro tráfego de underlay, o overhead é de 0 bytes e, como não é necessária a recuperação automática da ligação, o MTU de pacote eficaz é idêntico ao MTU da ligação WAN eficaz.
Tráfego VPN e MTU
Agora que o SD-WAN Edge descobriu o MTU e calculou os overheads gerais, um MTU eficaz poderá ser calculado para o tráfego de clientes. O Edge tentará impor este MTU da forma mais eficiente possível para os vários tipos potenciais de tráfego recebidos.
Tráfego de TCP
O Edge executa automaticamente o ajuste do MSS (Tamanho máximo do segmento) do TCP para os pacotes TCP recebidos. Como os pacotes SYN e SYN|ACK atravessam o Edge, o MSS é reescrito com base no MTU de pacote eficaz.
Tráfego não-TCP sem bit DF definido
Se o pacote for maior do que o MTU de pacote eficaz, o Edge executará automaticamente a fragmentação IP de acordo com a RFC 791.
Tráfego não-TCP com bit DF definido
Se o pacote for maior do que o MTU de pacote eficaz:
- A primeira vez que um pacote for recebido para este fluxo (IP 5-tuple), o Edge descartará o pacote e enviará um destino ICMP inacessível (fragmentação necessária) de acordo com a RFC 791.
- Se os pacotes subsequentes forem recebidos para o mesmo fluxo que ainda são demasiado grandes, estes pacotes serão fragmentados em vários pacotes VCMP e remontados de forma transparente antes do handoff na extremidade remota.
Limitação de pacotes jumbo
O VMware SD-WAN não oferece suporte para pacotes jumbo a partir da versão 5.0. O máximo de MTU de IP suportado para pacotes enviados através do overlay sem fragmentação é 1500.
