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.

Ambiente misto nella rete da Edge a Edge

Se l'iniziatore è dual stack e il risponditore è uno single stack, la preferenza del tunnel dell'iniziatore viene ignorata e il tunnel viene creato in base al tipo di IP del risponditore. In altri casi, la preferenza del tunnel dell'iniziatore ha la precedenza. Non è possibile stabilire l'overlay tra un'interfaccia solo IPv4 e un'interfaccia solo IPv6.

Nell'esempio precedente, l'Edge B1 ha un'interfaccia dual stack. L'Edge B1 può creare VCMP IPv4 per l'interfaccia solo IPv4 nell'Edge B2 (tunnel non preferito) e VCMP IPv6 per l'interfaccia solo IPv6 nell'Edge B3 (tunnel preferito).

Ambiente misto nella rete da Edge a Gateway

Quando un Edge dual stack (attivato sia IPv4 che IPv6) si connette a un Gateway single stack (solo IPv4), viene stabilito un tunnel IPv4.

Nell'illustrazione precedente, il Gateway solo IPv4 è connesso agli Edge E1 ed E2 che hanno interfacce dual stack con preferenza IPv6. Viene stabilito un tunnel IPv4 tra il Gateway e gli Edge.

In questo scenario, gli Edge non acquisiscono gli endpoint IPv6 pubblici degli altri Edge/Hub dal Gateway, perché il Gateway non supporta IPv6. Acquisiscono solo gli endpoint IPv4, insieme all'informazioni che la preferenza di overlay dell'altro Edge o Hub è IPv6. Anche se entrambi i dispositivi negoziano e comprendono che la loro preferenza di overlay corrisponde (IPv6), non saranno in grado di creare tunnel IPv6 tra loro a causa della mancanza di informazioni sull'endpoint IPv6. Inoltre, la corrispondenza della negoziazione della preferenza di overlay (per entrambi IPv6) impedisce ai dispositivi di creare tunnel IPv4 tra loro.

Nei casi in cui un Edge è connesso a un Gateway solo IPv4, è consigliabile impostare la preferenza di overlay su IPv4 in modo che gli Edge possano stabilire tunnel IPv4 tra loro.

Nota: È consigliabile non includere il Gateway solo IPv4 in un pool di Gateway con Gateway dual stack.

Ambiente dual stack

Quando tutti gli Edge e i Gateway sono in un ambiente dual stack, la preferenza del tunnel viene selezionata come segue:

  • Dall'Edge al gateway (Edge to Gateway): l'iniziatore, ovvero l'Edge, sceglie sempre il tipo di tunnel in base alla preferenza del tunnel.
  • Dall'Edge all'hub (Edge to Hub): l'iniziatore, ovvero l'Edge spoke, sceglie sempre il tipo di tunnel in base alla preferenza del tunnel.
  • Da filiale a filale dinamica (Dynamic Branch to Branch): quando si verifica una mancata corrispondenza nella preferenza del tunnel, la connessione utilizza indirizzi IPv4 per garantire un comportamento coerente e prevedibile.

Per le connessioni da Edge a Edge, la preferenza viene scelta come segue:

  • Quando per le interfacce dei peer Edge è impostata la stessa preferenza, viene utilizzato il tipo di indirizzo preferito.
  • Quando per le interfacce dei peer Edge sono impostate preferenze diverse, viene utilizzata la preferenza dell'iniziatore.
Nota: Quando entrambe le estremità si trovano in un ambiente dual stack, con IPv4 come preferenza e l'overlay stabilito con IPv4, l'overlay IPv6 non viene stabilito.

Nell'illustrazione precedente, tutti gli Edge sono in un ambiente dual stack con le seguenti preferenze:

  • Edge B1: IPv6
  • Edge B2: IPv6
  • Edge B3: IPv4

Nell'esempio precedente, un tunnel da Edge a Edge dinamico viene creato su IPv4 tra gli Edge B2 e B3, indipendentemente dal sito che avvia la connessione.

Impatto del tunnel IPv6 su MTU

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.

Quando è disponibile una singola oppure più interfacce secondarie, il valore MTU dell'annuncio della route non viene aggiornato correttamente nell'interfaccia secondaria. Le interfacce secondarie ereditano il valore di MTU dall'interfaccia principale. I valori MTU ricevuti nelle interfacce secondarie vengono ignorati e viene rispettato solo il valore di MTU dell'interfaccia principale. Quando un Edge ha una singola o più interfacce secondarie, è necessario disattivare l'opzione MTU nell'annuncio della route del router peer. In alternativa, è possibile modificare il valore MTU di un'interfaccia secondaria in un overlay WAN definito dall'utente. Per ulteriori informazioni, vedere Configurazione delle impostazioni di overlay WAN dell'Edge.

Funzionalità IPv6 dell'Edge

La funzionalità IPv6 di un Edge viene decisa in base allo stato amministrativo di IPv6 di ogni interfaccia. L'Edge deve avere una delle seguenti opzioni attivate con IPv6: VLAN commutata (Switched-VLAN), Interfaccia instradata (Routed-Interface), Interfaccia secondaria (Sub-Interface) e Interfaccia di loopback (Loopback-Interface). Ciò consente di categorizzare l'Edge come nodo compatibile con IPv6 per ricevere le route remote IPv6 dal Gateway.

Nota:

Gli hub ricevono sempre route remote IPv6, indipendentemente dalla propria funzionalità IPv6.

Limitazioni della configurazione degli indirizzi IPv6
  • SD-WAN Edge non supporta la configurazione dell'overlay privato in una famiglia di indirizzi e dell'overlay pubblico nell'altra famiglia di indirizzi nella stessa interfaccia instradata. Se configurato, SD-WAN Edge avvierà il tunnel utilizzando la famiglia di indirizzi preferita configurata nell'interfaccia instradata.
  • La modifica della preferenza del tunnel può causare l'interruzione dell'overhead di PMTU. Quando viene apportata una modifica alla configurazione per impostare la preferenza del tunnel IPv4 in tutte le interfacce, i tunnel da Edge a Edge o da hub a spoke possono essere eliminati e ripristinati in modo da utilizzare l'overhead IPv4 per garantire che la larghezza di banda del tunnel venga utilizzata in modo ottimale.
  • In un'interfaccia con link IP diversi, la larghezza di banda misurata dal tunnel o dal link preferito viene ereditata dagli altri link. Ogni volta che la preferenza del tunnel viene modificata per un link da IPv6 a IPv4 o viceversa, la larghezza di banda del link non viene misurata di nuovo.
  • Quando l'indirizzo del tunnel o la preferenza del tunnel vengono modificati da IPv6 a IPv4 o viceversa, i flussi esistenti vengono eliminati in un hub o uno spoke. È consigliabile svuotare i flussi nell'hub o nello spoke per recuperare il traffico bidirezionale.
  • Durante il monitoraggio degli eventi per un gateway nella pagina Eventi operatore (Operator Events) o per un Edge nella pagina Monitora (Monitor) > Eventi (Events), quando il gateway o l'Edge non è in grado di inviare l'heartbeat, nel messaggio dell'evento corrispondente viene visualizzato l'indirizzo IPv6 con trattini anziché due punti, nel formato seguente: x-x-x-x-x-x-x-x. Questa circostanza non ha alcun impatto sulla funzionalità.
  • La versione dell'Edge che esegue l'interfaccia commutata 4.x non supporta l'indirizzo IPv6.
  • SD-WAN Edge non utilizza nuovi prefissi IPv6 se ha più prefissi IPv6 perché potrebbe causare flap del tunnel. In questo caso, l'Edge dà la priorità al prefisso IPv6 precedente. Se è necessario utilizzare il nuovo prefisso IPv6, è consigliabile rimbalzare l'interfaccia WAN lato Internet o riavviare l'Edge per eseguire un ripristino immediato. In alternativa, è possibile attendere la scadenza della voce dell'indirizzo precedente.

Traffico di gestione e indirizzi IP

Quando l'Edge passa offline con una combinazione multipla di famiglie di indirizzi IP in uso, l'Edge non sarà in grado di comunicare con Orchestrator. Ciò si verifica quando si invia traffico diretto e la selezione del link ha esito negativo.

Nell'Orchestrator dual stack e nell'Edge, il daemon del piano di gestione (MGD) preferisce sempre l'indirizzo IPv6 per la comunicazione MGD a Orchestrator. IPv6 ha esito negativo e viene eseguito il fallback a IPv4. La matrice seguente mostra la famiglia di IP scelta da MGD per la comunicazione con Orchestrator.

Orchestrator
Edge IPv4 IPv6 Doppio
IPv4 Il traffico MGD è IPv4 Famiglia non corrispondente Il traffico MGD è IPv4
IPv6 Famiglia non corrispondente Il traffico MGD è IPv6 Il traffico MGD è IPv6
Doppio Il traffico MGD è IPv4 Il traffico MGD è IPv6 Il traffico MGD è IPv6

Il traffico MGD viene sempre inviato mediante overlay tramite gateway cloud a meno che tutti i percorsi al gateway non siano inattivi. In questo caso, il traffico MGD a Orchestrator viene inviato direttamente. Di seguito è riportata la logica per lo svuotamento diretto dei pacchetti.

  1. Loop su tutta l'interfaccia. Nei casi seguenti, l'Edge viene lasciato con interfacce composte solo da link WAN attivati.
    1. L'interfaccia su cui l'overlay WAN è disattivato non viene considerata.
    2. Quando l'interfaccia è single stack con IPv6 e il traffico è IPv4, non viene considerata.
    3. Quando l'interfaccia è single stack con IPv4 e il traffico è IPv6, non viene considerata.
  2. Loop su link WAN nell'interfaccia. Nei casi seguenti, l'Edge rimane con un link WAN che può essere utilizzato anche se i percorsi sono inattivi verso il gateway cloud.
    1. Se il link WAN è in standby, non viene considerato.
    2. Se il link WAN è privato, non viene considerato.

È possibile configurare gli indirizzi IPv6 per quanto segue: