VMware, come qualsiasi overlay, impone un sovraccarico aggiuntivo sul traffico che attraversa la rete. Questa sezione descrive innanzitutto il sovraccarico aggiunto in una rete IPsec tradizionale operando un confronto con VMware, seguito da una spiegazione sul rapporto tra il sovraccarico aggiunto e il comportamento dell'MTU e della frammentazione dei pacchetti nella rete.
Sovraccarico del tunnel IPsec
- Riempimento (Padding)
- AES crittografa i dati in blocchi di 16 byte, denominati dimensioni del "blocco".
- Se il corpo di un pacchetto è più piccolo delle dimensioni del blocco o non è un suo multiplo, viene riempito in modo da farlo coincidere con le dimensioni del blocco.
- Esempi:
- Un pacchetto di 1 byte diventerà 16 byte con 15 byte di riempimento.
- Un pacchetto di 1400 byte diventerà 1408 byte con 8 byte di riempimento.
- Un pacchetto di 64 byte non richiede alcun riempimento.
- Intestazioni e pagine di riepilogo dell'IPsec:
- Intestazione UDP per l'attraversamento NAT (NAT-T).
- Intestazione IP per la modalità tunnel IPsec.
- Intestazione e pagina di riepilogo dell'ESP.
| Elemento | Dimensioni in byte |
|---|---|
| Intestazione IP | 20 |
| Intestazione UDP | 8 |
| Numero di sequenza dell'IPsec | 4 |
| SPI IPsec | 4 |
| Vettore di inizializzazione | 16 |
| Riempimento | 0 – 15 |
| Lunghezza di riempimento | 1 |
| Intestazione successiva | 1 |
| Dati di autenticazione | 12 |
| Totale (Total) | 66-81 |
Sovraccarico del tunnel di VMware
Per supportare Dynamic Multipath Optimization™ (DMPO), VMware incapsula i pacchetti in un protocollo denominato VeloCloud Multipath Protocol (VCMP). VCMP aggiunge 31 byte di sovraccarico per i pacchetti utente per supportare il risequenziamento, la correzione degli errori, l'analisi della rete e la segmentazione della rete all'interno di un singolo tunnel. VCMP opera su una porta registrata presso IANA di UDP 2426. Per garantire un comportamento coerente in tutti i potenziali scenari (non crittografato, crittografato e dietro un NAT, crittografato ma non dietro un NAT), VCMP viene crittografato utilizzando la modalità di trasporto IPsec e forza NAT-T ad assumere il valore true con una porta NAT-T speciale di 2426.
I pacchetti inviati a Internet tramite il gateway SD-WAN non sono crittografati per impostazione predefinita, poiché verranno inviati a Internet all'uscita dal gateway. Di conseguenza, il sovraccarico per il traffico Internet Multipath è inferiore al traffico VPN.
Traffico VPN
| Elemento | Dimensioni in byte |
|---|---|
| Intestazione IP | 20 |
| Intestazione UDP | 8 |
| Numero di sequenza dell'IPsec | 4 |
| SPI IPsec | 4 |
| Intestazione VCMP | 23 |
| Intestazione dati VCMP | 8 |
| Vettore di inizializzazione | 16 |
| Riempimento | 0 – 15 |
| Lunghezza di riempimento | 1 |
| Intestazione successiva | 1 |
| Dati di autenticazione | 12 |
| Totale (Total) | 97 - 112 |
Traffico Internet Multipath (Internet Multipath Traffic)
| Elemento | Dimensioni in byte |
|---|---|
| Intestazione IP | 20 |
| Intestazione UDP | 8 |
| Intestazione VCMP | 23 |
| Intestazione dati VCMP | 8 |
| Totale (Total) | 59 |
Impatto del tunnel IPv6 su MTU
VMware SD-WAN supporta gli indirizzi IPv6 per configurare le impostazioni delle interfacce dell'Edge e dell'overlay WAN dell'Edge.
Il tunnel VCMP può essere configurato negli ambienti seguenti: solo IPv4, solo IPv6 e dual stack. Per ulteriori informazioni, vedere Impostazioni IPv6.
Quando una filiale include almeno un tunnel IPv6, DMPO utilizza facilmente questo tunnel insieme agli altri tunnel IPv4. I pacchetti per un flusso specifico possono richiedere qualsiasi tunnel, IPv4 o IPv6, in base all'integrità in tempo reale del tunnel. Un esempio di flusso specifico è il punteggio di selezione del percorso per il traffico con bilanciamento del carico. In questi casi, è necessario tenere in considerazione l'aumento delle dimensioni dell'intestazione IPv6 (20 byte aggiuntivi). Di conseguenza, l'MTU del percorso effettivo sarà inferiore a 20 byte. Inoltre, questo valore MTU effettivo ridotto verrà propagato alle altre filiali remote tramite Gateway, in modo che le route in entrata in questa filiale locale da altre filiali remote riflettano il valore di MTU ridotto.
Rilevamento MTU percorso
Dopo aver determinato la quantità di sovraccarico che verrà applicata, l'Edge SD-WAN deve individuare l'MTU massima consentita per calcolare l'MTU effettiva per i pacchetti dei clienti. Per trovare il valore dell'MTU massima consentita, l'Edge esegue il rilevamento dell'MTU del percorso:
- Per i link WAN che utilizzano Internet pubblico:
- Il rilevamento dell'MTU del percorso viene eseguito in tutti i gateway.
- L'MTU per tutti i tunnel verrà impostata sull'MTU minima rilevata.
- Per i link WAN privati:
- Il rilevamento dell'MTU del percorso viene eseguita su tutti gli altri Edge nella rete del cliente.
- La MTU per ciascun tunnel è impostata in base ai risultati del rilevamento dell'MTU del percorso.
L'Edge tenterà innanzitutto di rilevare la MTU del percorso RFC 1191; durante questa procedura, un pacchetto dell'MTU del link nota corrente (valore predefinito: 1500 byte) viene inviato al peer con il bit DF (Don’t Fragment) impostato nell'intestazione IP. Se questo pacchetto viene ricevuto nell'Edge o nel gateway remoto, all'Edge viene restituito un pacchetto di conferma delle stesse dimensioni. Se il pacchetto non riesce a raggiungere l'Edge o il gateway remoto a causa dei vincoli dell'MTU, è previsto l'invio da parte del dispositivo intermedio di un messaggio di destinazione ICMP non raggiungibile (frammentazione necessaria). Quando l'Edge riceve il messaggio di ICMP non raggiungibile, convalida il messaggio (per garantire che il valore dell'MTU indicato sia corretto) e, una volta convalidato, regolerà la MTU. Il processo si ripeterà fino a quando non viene rilevata la MTU.
In alcuni casi (ad esempio i dongle USB LTE), il dispositivo intermedio non invierà un messaggio ICMP non raggiungibile, neanche se il pacchetto è troppo grande. Se RFC 1191 non funziona (l'Edge non ha ricevuto una conferma o l'ICMP non è raggiungibile), si tornerà al rilevamento dell'MTU del percorso per il livello di pacchettizzazione RFC 4821. L'Edge tenterà di eseguire una ricerca binaria per individuare la MTU.
Quando viene individuata una MTU per un peer, tutti i tunnel a questo peer vengono impostati sulla stessa MTU. Ciò significa che se un Edge dispone di un solo link con una MTU di 1400 byte e un solo link con una MTU di 1500 byte, tutti i tunnel avranno una MTU di 1400 byte. Questo garantisce che i pacchetti possano essere inviati in qualsiasi tunnel in qualsiasi momento utilizzando la stessa MTU. Tale MTU viene detta MTU effettiva dell'Edge (Effective Edge MTU). In base alla destinazione (VPN o Internet Multipath), il sovraccarico descritto in precedenza viene sottratto per calcolare la MTU effettiva dell'Edge (Effective Edge MTU). Per Internet diretto o per l'altro traffico underlay, il sovraccarico è 0 byte e poiché il failover del link non è necessario, la MTU effettiva del pacchetto è identica alla MTU rilevata per il link WAN.
Traffico VPN e MTU
Ora che l'Edge SD-WAN ha rilevato la MTU e ha calcolato i sovraccarichi, è possibile calcolare una MTU effettiva per il traffico del client. L'Edge tenterà di applicare questa MTU nel modo più efficiente possibile per i diversi potenziali tipi di traffico ricevuti.
Traffico TCP (TCP Traffic)
L'Edge esegue automaticamente la regolazione degli MSS (Maximum Segment Size) TCP per i pacchetti TCP ricevuti. Mentre i pacchetti SYN e SYN|ACK attraversano l'Edge, la MSS viene riscritta in base alla MTU efficace del pacchetto.
Traffico non TCP senza set di bit DF (Non-TCP Traffic without DF bit set)
Se il pacchetto è più grande dell'MTU effettiva del pacchetto, l'Edge esegue automaticamente la frammentazione dell'IP secondo RFC 791.
Traffico non TCP con set di bit DF (Non-TCP Traffic with DF bit set)
Se il pacchetto è più grande dell'MTU effettiva del pacchetto:
- La prima volta che viene ricevuto un pacchetto per questo flusso (IP 5 tuple), l'Edge elimina il pacchetto e invia un messaggio di destinazione ICMP non raggiungibile (frammentazione necessaria) secondo RFC 791.
- Se vengono ricevuti pacchetti successivi per lo stesso flusso che sono ancora troppo grandi, questi pacchetti vengono frammentati in più pacchetti VCMP e riassemblati in modo trasparente prima dell'handoff all'estremità remota.
