24 febbraio 2021

VMware SD-WAN Orchestrator versione R402-20210219-GA
VMware SD-WAN Gateway versione R402-20210218-GA
VMware SD-WAN Edge versione R402-20210218-GA

Controllare periodicamente le aggiunte e gli aggiornamenti delle presenti note di rilascio.

Contenuto delle note di rilascio

Le note di rilascio riguardano i seguenti argomenti:

Uso consigliato

Questa versione è consigliata per tutti i clienti che richiedono le caratteristiche e le funzionalità rese disponibili per la prima volta nella versione 4.0.0, nonché per i clienti interessati dai problemi elencati di seguito, che sono stati risolti nella versione 4.0.1.

Compatibilità

Le istanze di Orchestrator, Gateway ed Edge hub con versione 4.0.2 supportano tutte le istanze di VMware SD-WAN Edge 3.0.0 o versioni successive 
Nota: ciò significa che le versioni precedenti alla 3.0.0 non sono supportate.

Le seguenti combinazioni di interoperabilità sono state testate in modo esplicito:

Orchestrator

 

Gateway

 

Edge

Hub

Filiale

4.0.2 

3.4.2

3.4.2

3.4.2

4.0.2 

4.0.2 

3.4.2

3.4.2

4.0.2 

4.0.2 

4.0.2 

3.4.2

4.0.2 

4.0.2 

3.4.2

4.0.2 

4.0.2 

4.0.2 

3.4.5

3.4.5

4.0.2 

4.0.2 

4.0.2

3.4.3, 3.4.4, 3.4.5

4.0.2 

3.3.2 P3 

3.3.2 P3

3.3.2 P3 

4.0.2 

4.0.2 

3.3.2 P3 

3.3.2 P3 

4.0.2 

4.0.2 

4.0.2 

3.3.2 P2, 3.3.2 P3

4.0.2 

4.0.2 

3.3.2 P2 

4.0.2 

4.0.2 

3.2.2 

3.2.2 

3.2.2 

4.0.2 

4.0.2 

3.2.2 

3.2.2 

4.0.2 

4.0.2 

4.0.2 

3.2.2 

4.0.2 

4.0.2 

3.2.2 

4.0.2 

4.0.2

4.0.0

4.0.0

4.0.0

4.0.2

4.0.0

4.0.1

4.0.2

4.0.2

4.0.2

4.0.0

4.0.1

4.0.1

4.0.1

4.0.2

4.0.0

4.0.0

4.0.0

4.0.2

4.0.2

Nota: l'interoperabilità con la versione 3.x è stata testata esplicitamente come parte del test della versione 4.0.0 e non sono state apportate modifiche al protocollo tra la versione 4.0.0 e la versione 4.0.2, che avrebbero richiesto di ripetere esplicitamente il test di più combinazioni rispetto a quelle mostrate nella tabella precedente.

Nota di compatibilità

La versione 3.x non supporta correttamente AES-256-GCM. Ciò significa che i clienti che utilizzano AES-256 usano sempre i propri Edge con GCM disabilitato (AES-256-CBC). Se un cliente utilizza AES-256, deve disabilitare esplicitamente GCM da Orchestrator prima di aggiornare gli Edge alla versione 4.x. Quando in tutti gli Edge è in esecuzione la versione 4.x, il cliente può scegliere tra AES-256-GCM e AES-256-CBC.

Se si esegue questa operazione, si eviteranno i problemi di interoperabilità tra gli Edge 3.x e 4.x.

Cronologia delle versioni del documento

24 febbraio 2021. Prima edizione.

Problemi risolti

I problemi risolti sono raggruppati come segue.

Problemi risolti dell'Edge o del gateway

Risolti nella versione R402-20210218-GA

Nella versione R401-20201110 di Edge e R401-20201124-GA-53090 di Gateway sono stati risolti i seguenti problemi.

  • Problema 32917 risolto: L'output non è preciso per la pagina di monitoraggio dei router adiacenti PIM multicast in VMware SD-WAN Orchestrator.

    L'output per i router adiacenti PIM multicast nella pagina di monitoraggio dell'Edge non è preciso, ad esempio nell'interfaccia PIM per alcuni degli Edge viene visualizzato un valore garbage anziché un'interfaccia effettiva e l'adiacenza PIM viene visualizzata nel monitoraggio anche dopo che è stata eliminata dall'Edge. 

  • Problema 36956 risolto: Quando viene eseguita la diagnostica remota "Svuota sessioni del firewall" (Flush Firewall Sessions) o viene generato un bundle di diagnostica per un VMware SD-WAN Edge in cui è abilitato un firewall e sono presenti almeno 22000 flussi di firewall, è possibile che nell'Edge si verifichi un errore del servizio piano dati e che il servizio venga riavviato per il ripristino.

    Questo problema si verifica molto raramente sul campo e il team VMware Engineering non è in grado di ricrearlo in modo coerente. Quando viene ricreato dal team Engineering, il problema ha le caratteristiche indicate nella sezione Sintomi. Il motivo per cui la generazione di un bundle di diagnostica può causare questo problema per un Edge che utilizza un firewall è che il bundle di diagnostica include il registro di debug user_firewall_dump e la generazione di questo registro è collegata al problema 36956. 

  • Problema 48612 risolto: I gateway e gli Edge virtuali VMware SD-WAN che utilizzano una scheda di rete X710/XL710 rimuovono tutti i tag VLAN del pacchetto RX.

    Questo problema ha un impatto significativo per i clienti che utilizzano un gateway configurato nel modo indicato in cui è abilitato anche DPDK perché non sono in grado di elaborare il traffico con tag VLAN nell'interfaccia di handoff. Questo problema è stato analizzato per il driver i40evf DPDK che ha inviato il codice operativo VIRTCHNL_OP_ADD_VLAN alla funzione fisica (PF) per aggiungere tag filtrati VLAN. Tuttavia, il driver PF ha abilitato la rimozione dei tag VLAN come parte del comando per abilitare il filtro dei tag VLAN e di conseguenza tutti i tag VLAN sono stati rimossi.

  • Problema 49139 risolto: Se un Edge virtuale VMware SD-WAN viene distribuito e attivato senza eseguire un aggiornamento del software iniziale, è possibile che lo spazio su disco (inode) venga esaurito.

    Quando si distribuisce un Edge virtuale, se l'attivazione dell'Edge non aggiorna immediatamente l'Edge a una versione del software GA, è possibile che nell'Edge vengano esauriti gli inode durante il funzionamento dopo la creazione di alcuni file aggiuntivi.

  • Problema 49598 risolto: Quando in un VMware SD-WAN Gateway è presente una grande quantità di traffico sottoposto a backhaul e diversi tunnel verso il gateway sono instabili, le prestazioni delle istanze di VMware SD-WAN Edge connesse al gateway peggiorano e si verifica la perdita intermittente di pacchetti.

    Quando si parla di una grande quantità di traffico sottoposto a backhaul si intendono ~700000 flussi sottoposti a backhaul verso un gateway con ~6000 tunnel. In questo caso, se ~100 Edge hanno connessioni instabili che causano la ripetuta eliminazione e ricreazione di tunnel verso il gateway, il risultato sarà una collisione di tabelle hash che determina un utilizzo elevato della CPU per un thread specifico e la perdita di pacchetti intermittente per gli Edge connessi. Se si esaminano i registri del gateway o si utilizza debug.py --handoff, è possibile notare un numero significativamente elevato di interruzioni di code di handoff per gli handoff vc_queue_vcmp_ctrl e vc_queue_vcmp_bottom.

  • Problema 51108 risolto: VMware SD-WAN Edge continua a inviare traffico al VMware SD-WAN Gateway di una destinazione non SD-WAN (NSD) anche quando i tunnel NSD nel gateway sono inattivi.

    Il gateway non invia l'evento di raggiungibilità NSD agli Edge quando l'indirizzo IP pubblico NSD viene modificato in VMware SD-WAN Orchestrator. In questo modo, l'Edge continua a inoltrare il traffico a NSD tramite il gateway. Senza la correzione, l'unica azione correttiva consiste nel rimbalzare il tunnel NSD nel Gateway.  

  • Problema 51116 risolto: I flussi remoti non vengono classificati correttamente utilizzando le subnet IP della mappa delle applicazioni.

    Ciò influisce sul traffico per due Edge che utilizzano il flusso da Edge a Edge tramite Gateway.  Nell'Edge remoto, la tabella dei flussi inverte l'indirizzo IP e la porta di origine con l'indirizzo IP e la porta di destinazione e, poiché la ricerca della mappa delle applicazioni utilizza solo l'indirizzo IP e la porta di destinazione, i flussi vengono classificati in modo non corretto.

  • Problema 51166 risolto: In un'istanza di VMware SD-WAN Edge 610, se GE2 è configurato come interfaccia instradata e su tale interfaccia è configurata una VLAN, il traffico su tale VLAN viene interrotto. 

    A causa di una programmazione errata dello switch di Edge 610, le tabelle VLAN non vengono configurate correttamente quando GE1 o GE2 vengono convertiti in interfacce instradate. Se non viene applicata questa correzione, Edge 610 dovrebbe utilizzare solo da GE3 a GE6 come interfacce instradate con VLAN.

  • Problema 51881 risolto: Quando si elimina una destinazione non SD-WAN tramite Edge diretta, la memoria non viene liberata correttamente in VMware SD-WAN Edge.

    Per le destinazioni non SD-WAN (NSD) tramite Edge dirette, i riferimenti in una struttura di dati interna venivano conteggiati in modo errato e quindi non liberavano la memoria dopo l'eliminazione di un provider NSD. L'aumento della memoria dovrebbe verificarsi solo se vengono eliminati più provider NSD tramite Edge e vengono aggiunti nuovi provider.  La perdita di memoria avrebbe un impatto negativo sui modelli di Edge con footprint di memoria inferiori (ad esempio, Edge 510, 520, 610 e così via) e, nel peggiore dei casi, causerebbe un unico riavvio del servizio Edge per eliminare la perdita di memoria.  Questo problema non riguarda i clienti che eliminano una destinazione non SD-WAN tramite gateway, ma è specifico per il tipo NSD tramite Edge.

  • Problema 51915 risolto: Per un sito in cui gli SD-WAN Edge sono distribuiti in una topologia ad alta disponibilità, se nel sito si verifica un failover di HA, il traffico Cloud tramite gateway diventa traffico Diretto al cloud.

    Dopo il failover di HA, se il percorso verso VMware SD-WAN Gateway non è attivo quando il traffico raggiunge l'Edge, il traffico diventa "Diretto al cloud" anziché "Cloud tramite gateway". Il traffico Diretto al cloud non utilizza l'ottimizzazione dinamica percorso multiplo di VMware SD-WAN e il traffico sensibile alla perdita o al jitter non beneficia di questi miglioramenti quando viene inviato direttamente.

  • Problema 52102 risolto: Sintomo: per un'azienda che utilizza una topologia hub/spoke, i flussi esistenti vengono rilasciati in un Edge spoke VMware SD-WAN durante il ripristino da un failover di Edge hub per una data tupla. 

    Descrizione: la sequenza di eventi causa questo problema quando un Edge hub primario viene recuperato dal failover: 

    1. Quando l'Edge hub primario viene disattivato, la route viene rimossa dalla FIB di tale Edge hub primario mantenendo le route nella RIB. 

    2. I flussi esistenti saranno a questo punto commutati nell'Edge hub secondario. 

    3. Quando l'hub primario viene riattivato, viene immediatamente stabilito un tunnel tra l'hub primario e l'Edge spoke. 

    4. Le route nella RIB acquisite in precedenza dall'hub primario tramite il gateway vengono analizzate e le route vengono installate nella FIB che punta a questo hub primario. 

    5. Il traffico passerà di nuovo all'hub primario, mentre l'hub primario non avrebbe acquisito le route dal proprio router adiacente BGP. 

    6. In questo modo, la ricerca della route corrisponde alla route predefinita e il traffico di ritorno viene contrassegnato con un flag di backhaul. 

    7. L'Edge spoke non prevede il traffico di ritorno con un flag di backhaul impostato e ciò comporta l'interruzione del traffico. 

    Se non si apporta questa correzione, l'unico modo per risolvere il problema è eseguire la diagnostica remota "Svuota flussi" nell'Edge hub per la tupla specificata. 

  • Problema 52141 risolto: Se il socket TCP che connette il processo OSPF di un VMware SD-WAN Edge e il processo SD-WAN diventa inattivo e deve essere ripristinato, è possibile che la route predefinita OSPF dell'Edge non venga aggiornata e che si verifichi un errore del traffico per tale sito. 

    Si verifica un flap nel canale Zebra (il socket TCP) tra il processo OSPF (ospfd) e il processo SD-WAN (con Edge). Circa nello stesso momento, viene eseguito un aggiornamento LSA (Link-State Advertisement) pianificato per la route predefinita in OSPF. A causa dei tempi, ospfd rileva che il canale Zebra non è configurato e quindi ignora la rigenerazione di LSA quando il suo timer scade circa alla stessa ora. LSA viene quindi rimosso (perché non è stato aggiornato) con il risultato che non è possibile passare alcun traffico nella rete che utilizza questo Edge. La correzione forza il processo OSPF ad aggiornare l'intera configurazione e fa in modo che la route predefinita sia sempre presente.

  • Problema 52342 risolto: il caricamento della pagina Diagnostica remota nell'interfaccia utente di VMware SD-WAN Orchestrator potrebbe non riuscire.

    Per la versione 4.x, VMware ha introdotto WebSocket per sostituire il live-heartbeat precedentemente utilizzato nella diagnostica remota. Tuttavia, VMware SD-WAN Edge ha originato la connessione WebSocket sull'IP WAN predefinito, causando un calo del traffico casuale nel middleware o nell'Edge stesso. Il binding del WebSocket con un IP specificato da VMware risolve il problema.

  • Problema 52628 risolto: I pacchetti con origine sconosciuta sono consentiti dall'interfaccia LAN di un VMware SD-WAN Edge.

    A causa di questo problema, i pacchetti originati da una subnet diversa dalla subnet della LAN possono passare attraverso l'Edge. Ciò è causato dalle interfacce LAN dell'Edge che non hanno attivato il Reverse-Path Forwarding (RPF). La correzione abilita RPF in tutte le interfacce LAN dell'Edge e i pacchetti provenienti dalle interfacce LAN saranno consentiti solo se sono originati dalla subnet LAN configurata. 

  • Problema 52659 risolto: Quando un VMware SD-WAN Edge viene configurato come agente di inoltro DHCP, l'Edge non inoltra i pacchetti NAK DHCP a un client.

    Se il server DHCP invia pacchetti NAK DHCP, l'Edge configurato come inoltro DHCP elimina i pacchetti senza inoltrarli. 

  • Problema 52954 risolto: Per l'azienda di un cliente in cui viene utilizzato il multicast, i router adiacenti PIM (Protocol-Independent Multicast) non vengono scalati al limite supportato di ~1600.

    Questo problema si verifica nello scenario specifico in cui 4000 Edge spoke sono separati da due profili spoke, uno con multicast disabilitato e l'altro con multicast abilitato. Se pimd (il processo che gestisce PIM) diventa inattivo e quindi di nuovo attivo, l'Edge hub non ristabilirà i 1600 router adiacenti PIM previsti.

  • Problema 53019 risolto: È possibile che in un VMware SD-WAN Edge si verifichi un errore del servizio piano dati quando viene ricevuto un pacchetto danneggiato. 

    L'Edge può interpretare il pacchetto danneggiato (ad esempio un messaggio non valido inviato da un peer) come un pacchetto VeloCloud Management Control (NACK) che l'Edge non è in grado di elaborare correttamente. Si verifica quindi un errore del servizio piano dati e l'Edge riavvia il servizio per il ripristino. Il pacchetto del caso verificatosi sul campo era stato inviato da un dispositivo peer.

  • Problema 53176 risolto: Quando in un VMware SD-WAN Edge 610 si verifica una transizione dello stato di VRRP da Backup ad Attivo, il traffico da LAN a WAN viene perso per ~4 minuti.

    Edge 610 non acquisisce l'indirizzo MAC VRRP dopo che diventa attivo, quindi il traffico viene interrotto finché l'Edge 610 non acquisisce l'indirizzo MAC. Questa operazione richiede ~4 minuti. 

  • Problema 53243 risolto: È possibile che il traffico indirizzato a una destinazione non SD-WAN (NSD) che utilizza un tipo Check Point venga interrotto perché il gateway non elimina l'associazione di sicurezza della fase 2. 

    I peer risulteranno non sincronizzati in termini di associazione di sicurezza e il link rimarrà inattivo finché l'associazione di sicurezza non scadrà. In una NSD che utilizza un tipo di firewall Check Point, quando il collegamento non è stabile è possibile che si verifichi una situazione in cui il peer invia una notifica di eliminazione, ma il gateway non può eliminare l'associazione di sicurezza della fase 2 perché l'associazione di sicurezza della fase 1 corrispondente è già stata eliminata. 

  • Problema 53426 risolto: La route BGP underlay locale non viene ordinata correttamente nella Forwarding Information Base (FIB) di VMware SD-WAN Edge rispetto alle route BGP dagli Edge hub e la route overlay preferita in un Edge non viene ridistribuita correttamente nel BGP underlay. 

    Quando il flag DCC è abilitato, la preferenza e i valori di annuncio della route vengono modificati, ma la route underlay non viene riordinata correttamente nel FIB dell'Edge.  Inoltre, quando la route BGP underlay viene inizialmente preferita nella FIB dell'Edge e successivamente una route BGP overlay viene preferita rispetto alla route acquisita localmente, a causa di un problema della logica di ridistribuzione, la route overlay non viene ridistribuita correttamente nel BGP underlay. Senza la correzione, è necessario forzare l'Edge ad acquisire nuovamente la route BGP underlay o overlay, nel modo appropriato. 

  • Problema 53439 risolto: Un VMware SD-WAN Gateway interrompe i tentativi di ridefinire la chiave IKE di una VPN dopo diversi tentativi non riusciti.

    Questo problema può influire sui clienti che utilizzano destinazioni non SD-WAN tramite gateway basate su criteri (le VPN basate su route non vengono coinvolte). Per una VPN basata su criteri (ad esempio, Cisco ASA o firewall generico), il traffico degli utenti inviato tramite VPN deve avviare una nuova associazione di sicurezza se, per qualsiasi motivo, l'associazione di sicurezza precedente è stata eliminata. In questo caso, la ridefinizione della chiave IKE utilizza selettori del traffico non corretti, che causano la mancata creazione della nuova associazione di sicurezza. Il traffico verso la destinazione non SD-WAN sarà quindi inattivo finché non viene eseguito il push di una nuova modifica della configurazione da VMware SD-WAN Orchestrator. Se l'associazione di sicurezza precedente non è stata eliminata quando viene eseguita la ridefinizione della chiave, non si verifica alcun problema. Ciò significa che il problema non coinvolge tutti i clienti e tutte le ridefinizioni delle chiavi.

  • Problema 53477 risolto: Quando i VMware SD-WAN Edge configurati in una topologia ad alta disponibilità vengono spostati in un profilo di configurazione diverso, si verificano ripetuti riavvii del servizio Edge.  

    Per questo problema, uno degli Edge HA è configurato in modo da avere più interfacce LAN o WAN rispetto all'altro Edge HA (ad esempio, una porta WAN è disabilitata in uno degli Edge). Se tali Edge vengono spostati in un altro profilo, si verificheranno quindi continui riavvii del servizio Edge.

  • Problema 53546 risolto: Se la CoS (Class of Service) MPLS è abilitata e in una delle CoS nel link privato si verifica una perdita, è possibile che i pacchetti nell'altra CoS vengano eliminati a causa dell'oversubscription. 


    Se uno o più sottopercorsi del link privato diventano instabili a causa della perdita, l'intera larghezza di banda del link privato verrà esclusa dal calcolo del limite massimo della larghezza di banda del dispositivo. Di conseguenza, è possibile che alcuni pacchetti negli altri sottopercorsi vengano eliminati se l'attuale utilizzo della larghezza di banda supera il limite massimo della larghezza di banda del dispositivo. Il limite massimo della larghezza di banda del dispositivo viene calcolato sommando la larghezza di banda dei link stabili. 

  • Problema 53656 risolto: L'utente non può accedere a una macchina virtuale VMware vSphere distribuita da un VMware SD-WAN Orchestrator o un pacchetto OVA di VMware SD-WAN Gateway.

    Dopo aver distribuito un Orchestrator o un pacchetto OVA del Gateway in vSphere, il sistema non è in grado di analizzare i metadati della vApp, nonché applicare la password e la configurazione di rete fornite.

  • Problema 53676 risolto: Nella piattaforma VMware SD-WAN Edge 3x00, periodi molto brevi di instabilità della tensione di input, ad esempio di 4 millisecondi, possono causare il riavvio dell'Edge.

    Questo problema si verifica in genere quando si utilizza un gruppo di continuità UPS in cui si verifica una leggera instabilità della tensione di output durante il passaggio dalla linea alla batteria. La correzione di questo problema aggiorna il firmware dell'Edge in modo che tolleri 20-30 ms di instabilità della tensione prima di riavviare l'Edge. In un modello di Edge 3x00 senza questa correzione, l'unica possibilità del cliente è utilizzare un gruppo di continuità UPS più sofisticato in grado di cambiare input senza alcuna instabilità della tensione di output. 

  • Problema 53809 risolto: Per un cliente che distribuisce VMware SD-WAN Edge in una topologia ad alta disponibilità avanzata, se si verifica un failover, l'evento di failover di HA specifica sempre il motivo del failover come errore dell'heartbeat del peer (con il messaggio "Attivazione Standby in corso. Errore dell'heartbeat del peer" (Standby going active, peer heartbeat failure)) indipendentemente dal motivo effettivo.

    Nel caso dell'alta disponibilità avanzata, se l'interfaccia LAN o WAN diventa inattiva e si verifica un failover dell'alta disponibilità, gli eventi descriveranno il motivo con il messaggio "Attivazione Standby in corso. Errore dell'heartbeat del peer" (Standby going active, peer heartbeat failure) anziché "Attivazione Standby in corso. Interfacce WAN peer inattive" (Standby going active, Peer WAN interface(s) down) o "Attivazione Standby in corso. Interfacce LAN peer inattive" (Standby going active, Peer LAN interface(s) down).

  • Problema 53837 risolto: La pagina Diagnostica remota non viene caricata nell'interfaccia utente di VMware SD-WAN Orchestrator e la pagina Web visualizzata rimane "Passaggio alla modalità live" (Entering into live mode).

    Questo problema è collegato al problema 52342 di Orchestrator (descritto in queste note di rilascio) e la correzione in questo caso consente di risolvere un problema relativo a VMware SD-WAN Edge. Insieme, entrambi i problemi assicurano che la pagina Diagnostica remota venga sempre caricata.

  • Problema 53864 risolto: La route OSPF underlay locale non viene ordinata correttamente nella Forwarding Information Base (FIB) di VMware SD-WAN Edge rispetto alle route OSPF dagli Edge hub e la route overlay preferita in un Edge non viene correttamente ridistribuita nell'OSPF underlay. 

    Quando il flag DCC è abilitato, la preferenza e i valori di annuncio della route vengono modificati, ma la route underlay non viene riordinata correttamente nel FIB dell'Edge.  Inoltre, quando la route OSPF underlay viene inizialmente preferita nella FIB dell'Edge e successivamente una route OSPF overlay viene preferita rispetto alla route acquisita localmente, a causa di un problema della logica di ridistribuzione, la route overlay non viene correttamente ridistribuita nell'OSPF underlay. Senza la correzione, è necessario forzare l'Edge ad acquisire nuovamente la route OSPF underlay o overlay, nel modo appropriato. 

  • Problema 53977 risolto: È possibile che una macchina virtuale Azure creata da un'immagine di VMware SD-WAN Orchestrator o VMware SD-WAN Gateway non venga avviata correttamente.

    Dopo aver creato una macchina virtuale da un'immagine di Orchestrator o del gateway, è possibile che la macchina virtuale non venga avviata correttamente e che venga visualizzato il messaggio di errore "Impossibile aprire il dispositivo root" (Cannot open root device) nella console seriale.

  • Problema 54001 risolto: Un VMware Edge non è in grado di inviare il traffico dopo il blocco della coda TX nelle interfacce SFP.

    In rari casi, quando l'Edge invia a DPDK un pacchetto di dimensioni non valide (inferiori a 17 byte o superiori a 1526 byte), la coda di trasmissione si blocca e impedisce l'inoltro di ulteriore traffico dall'Edge. Il riavvio dell'Edge consente di correggere temporaneamente il problema, che però può verificarsi nuovamente quando un pacchetto di dimensioni non valide viene inviato dal servizio Edge a DPDK. Solo l'aggiornamento a un livello con la correzione consente di evitare il problema. 

  • Problema 54493 risolto: VMware SD-WAN Edge elimina i pacchetti in esecuzione durante l'handoff tra thread diversi nel percorso dei dati.

    Nel caso di un evento del piano di controllo, come l'abbandono della route, l'Edge inizia a eliminare i pacchetti durante l'handoff a thread diversi nella pipeline. Questa correzione consente di ridurre il problema aumentando le dimensioni della coda per il buffering dei pacchetti.

  • Problema 54519 risolto: Nel caso in cui una destinazione non SD-WAN con un firewall generico non sia configurata correttamente, è possibile che si verifichi un errore relativo alla perdita dell'associazione di sicurezza (SA).

    Questo non è un problema di sicurezza perché la perdita è interna e non comporta la perdita delle informazioni di SA all'esterno. La perdita di SA è causata da una configurazione non corretta del selettore del traffico per un criterio del firewall generico. Alcuni peer non controllano l'intervallo del selettore del traffico e rispondono alla negoziazione SA IPSec. VMware SD-WAN Gateway riceve quindi la risposta, la controlla e, se è presente un errore, torna indietro senza azzerare il contenuto di SA. Il contatore di SA continua ad aumentare a causa della rinegoziazione in corso.

  • Problema 54800 risolto: Durante una ridefinizione della chiave IKE con VMware SD-WAN Gateway, in una destinazione non SD-WAN tramite gateway potrebbe verificarsi un'interruzione del tunnel che non viene ripristinata.

    Quando un'istanza di VMware SD-WAN Gateway attiva una ridefinizione della chiave IKE con una destinazione non SD-WAN (NSD) e durante la ridefinizione della chiave il link IKE diventa inattivo o la creazione del tunnel non riesce per un motivo qualsiasi, il gateway non sarà in grado di riattivare un nuovo tunnel IPsec perché la logica di attivazione presuppone che sia disponibile un ID del criterio di sicurezza. Di conseguenza, il tunnel non verrà ristabilito anche quando viene inviato il traffico dati. Senza la correzione, l'unico modo per ripristinare il tunnel consiste nel rimbalzarlo modificando la configurazione di NSD in VMware SD-WAN Orchestrator.

  • Problema 54947 risolto: Per le destinazioni non SD-WAN (NSD) tramite Edge, l'utente non è in grado di eseguire il ping dall'IP NSD al self_ip di VMware SD-WAN Edge a scopo di monitoraggio.

    Per NSD diretto tramite Edge, il supporto per il ping verso o da qualsiasi interfaccia dell'Edge tramite IP NSD non era supportato in precedenza. Il supporto di questo metodo di monitoraggio fa parte di questo ticket. Con questa correzione, il cliente sarà in grado di eseguire il ping dall'Edge all'IP NSD o viceversa.

  • Problema 55181 risolto: Nell'azienda di un cliente che utilizza una topologia di rete hub/spoke in cui l'Edge spoke VMware SD-WAN esegue il backhaul del traffico verso l'Edge hub, se il tunnel dell'Edge spoke verso l'Edge hub diventa inattivo, il traffico continua a essere contrassegnato come "backhaul" e viene instradato all'hub anziché essere instradato direttamente da filiale a filiale. 

    Immediatamente dopo un failover del traffico dallo spoke all'hub o dopo il ripristino da una perdita di connettività WAN in tutti i link overlay, è possibile che le route non vengano acquisite e i flussi vengano considerati come flussi Internet e soddisfino un criterio di business di backhaul. Tuttavia, dopo che vengono acquisite le route corrette, i criteri di business non vengono a volte valutati nuovamente per questi flussi e non vengono ripristinati da questo stato. 

  • Problema 55196 risolto: Per una destinazione non SD-WAN (NSD) tramite gateway, in alcuni scenari quando la chiave di un peer viene costantemente ridefinita, è possibile che venga rilevato un accumulo di associazioni di sicurezza (SA) IPSec in entrata.

    L'impatto sul cliente è minimo perché le SA vengono mantenute fino alla loro scadenza e vengono quindi eliminate. Ciò non comporta alcun rischio per la sicurezza. Quando si verifica una ridefinizione della chiave IKE, una SA IPSec in uscita viene scollegata dal descrittore IKE e ne viene collegata una nuova. Questo forza l'eliminazione della SA in uscita. Quando il peer invia una "notifica di eliminazione", VMware SD-WAN Gateway non trova la SA in uscita da eliminare. La SA in entrata persiste quindi fino alla sua scadenza. Se la chiave del peer viene spesso ridefinita, è possibile che il gateway continui a creare e mantenere la nuova SA in entrata fino a ogni scadenza.

  • Problema 55788 risolto: I tunnel verso un servizio di sicurezza cloud o una destinazione non SD-WAN possono diventare inattivi e tornare attivi in rapida successione (ovvero un "flap") e quindi diventare completamente inattivi senza venire ripristinati. In VMware SD-WAN Gateway viene trovata una grande quantità di voci di associazione di sicurezza (SA) obsolete in uscita.

    Quando un burst di pacchetti di controllo deve essere inviato da un gateway, i pacchetti vengono inseriti in una coda crittografica e un contatore di riferimenti viene incrementato di un'unità per pacchetto. Se nella coda crittografica non c'è spazio, i pacchetti vengono eliminati ma il numero del contatore di riferimenti collegato a questi pacchetti non diminuisce. Quindi, anche se i pacchetti vengono eliminati perché il conteggio dei riferimenti è diverso da zero, la SA associata non viene eliminata e diventa obsoleta nel sistema. Se in un determinato periodo di tempo si verifica un numero sufficiente di questi tipi di evento, il gateway raggiunge la capacità massima di SA e non avvia le connessioni IKE della fase 2 in uscita. In questo modo, i tunnel non vengono ricreati e rimangono inattivi.  Senza la correzione nel gateway, l'unico modo per risolvere temporaneamente questo problema è riavviare il gateway per cancellare tutte le SA.

  • Problema 55853 risolto: Nell'azienda di un cliente che utilizza destinazioni non SD-WAN (NSD) tramite Edge, in un VMware SD-WAN Edge può verificarsi un errore del servizio piano dati che determina un riavvio del servizio.

    Quando nell'Edge è presente traffico verso NSD tramite Edge e questo traffico passa dal percorso verso NSD tramite Edge a un altro percorso (ad esempio, il percorso verso NSD diventa temporaneamente inattivo) e quindi torna di nuovo al percorso verso NSD tramite Edge, alcuni flussi possono passare allo stato danneggiato. Quando si verifica il timeout di questi flussi, viene attivato un errore del servizio piano dati nell'Edge coinvolto.

  • Problema 55929 risolto: Quando un cliente disabilita e quindi abilita i tunnel in una destinazione non SD-WAN tramite gateway basata su criteri utilizzando l'interfaccia utente di VMware SD-WAN Orchestrator e la negoziazione IKE è bloccata sulla porta 4500, è possibile che si verifichi un accumulo di associazioni di sicurezza (SA) in entrata in VMware SD-WAN Gateway.

    Questo problema richiede che l'amministratore disabiliti e abiliti una destinazione non SD-WAN basata su criteri (ad esempio Zscaler) in cui la negoziazione IKE possa creare una SA, ma non esista alcun traffico in entrata dal peer. In questo caso è possibile che si verifichi l'accumulo di SA in entrata in VMware SD-WAN Gateway. Le SA verranno eliminate quando è presente il traffico in entrata. Tuttavia, se non è presente alcun traffico in entrata e l'amministratore continua ad abilitare/disabilitare l'NSD basato su criteri, ogni volta che viene eseguita questa operazione nel gateway rimarrà una SA in entrata. Tali SA rimangono fino alla loro scadenza. L'impatto per il cliente è minimo.

  • Problema 55949 risolto: In alcuni scenari, una destinazione non SD-WAN (NSD) tramite tunnel gateway diventa inattiva e non viene ripristinata per un determinato periodo di tempo.

    In una situazione in cui un VMware SD-WAN Gateway attiva la ridefinizione della chiave IKE con qualsiasi altra destinazione NSD e il tentativo di ridefinire la chiave non riesce a causa di un problema di rete durante la negoziazione, continuano a essere eseguiti nuovi tentativi di ridefinizione. Quando viene ristabilito un link, è possibile che l'evento Dead Peer Detection (DPD) elimini un'associazione di sicurezza (SA) della fase 1 appena creata. Ciò comporta anche l'eliminazione della SA IPSec con alcuni peer, in particolare con Zscaler. Quando un peer elimina la SA IPSec, il gateway non sarà in grado di rilevarla e un tunnel rimarrà inattivo fino alla successiva ridefinizione della chiave.  Senza la correzione, l'unico modo per forzare questa ridefinizione della chiave è quello di rimbalzare il tunnel disabilitando e riabilitando la NSD coinvolta tramite VMware SD-WAN Orchestrator.

  • Problema 56276 risolto: Se una mappa delle applicazioni viene modificata e salvata e quindi viene eseguito un push della mappa delle applicazioni, è possibile che un router adiacente BGP venga eliminato nell'azienda di un cliente.

    Quando una mappa delle applicazioni viene modificata e poi sottoposta a push, tutti i flussi per le aziende coinvolte vengono svuotati. Ciò comporta la creazione di nuovi flussi per BGP. Quando viene creato un nuovo flusso, il suo stato TCP viene reinizializzato su LISTEN.  Con questo stato, non è possibile ricevere e inviare pacchetti BGP. Solo i pacchetti SYN TCP possono essere ricevuti e inviati.  Tutti i pacchetti keep-live di BGP vengono eliminati e si verifica quindi un flap di BGP.

  • Problema 56436 risolto: La destinazione non SD-WAN (NSD) tramite tunnel gateway diventa inattiva e quindi di nuovo attiva (ovvero si verifica un "flap") ogni 30 secondi.

    A causa di un errore imprevisto relativo al riconoscimento del cambiamento in una configurazione NSD nell'heartbeat, la configurazione NSD viene inviata a VMware SD-WAN Gateway a ogni heartbeat (l'intervallo di heartbeat è ogni 30 secondi). Quando la configurazione viene ricevuta nel gateway, la connessione viene riavviata e ciò comporta il flap dei tunnel NSD ogni 30 secondi.

Problemi risolti di Orchestrator

Risolti nella versione R402-20210219-GA

Nella versione di Orchestrator R401-20201215-GA sono stati risolti i seguenti problemi.

  • Problema 48706 risolto: È possibile che gli utenti non siano in grado di salvare le modifiche nella scheda Configura (Configure) > Edge > Dispositivo (Device) con l'interfaccia di origine selezionata nella configurazione di syslog.

    Il messaggio di errore visualizzato in VMware SD-WAN Orchestrator è "L'interfaccia di origine fornita non è presente nel segmento: <Nome segmento>" (Provided source interface is not present in the segment on segment <Segment Name>). Questo errore è causato dall'utente che crea ed elimina diversi segmenti in modo tale che l'ordine dei segmenti non è più sequenziale.

  • Problema 50590 risolto: VMware SD-WAN Orchestrator invia avvisi del tunnel del servizio di sicurezza cloud (CSS) con data e ora UTC anziché con il fuso orario locale di VMware SD-WAN Edge. 

    Il problema si verifica quando gli avvisi del tunnel CSS vengono attivati e inviati tramite e-mail, webhook e così via. Questo problema non ha alcun impatto funzionale, ma coinvolge i clienti non interessati alla conversione di data e ora UTC in diversi fusi orari in base alla posizione dell'Edge.

  • Problema 50719 risolto: Quando una coppia di VMware SD-WAN Edge configurati in una topologia ad alta disponibilità viene aggiornata alla versione 3.4.1, 3.4.2 o 3.4.3, l'Edge di standby non viene più rilevato.

    Quando gli Edge vengono aggiornati, l'interfaccia di HA (ovvero LAN1 o GE1) viene programmata come porta di trunk anche se dovrebbe essere configurata come porta di accesso e ciò comporta la mancata visualizzazione dell'interfaccia HA.  La correzione aggiunge una convalida per assicurarsi che l'interfaccia HA sia configurata come porta di accesso.  Senza la correzione, l'unica soluzione consiste nel riconfigurare la porta HA su "Accesso" utilizzando VMware SD-WAN Orchestrator. 

  • Problema 53333 risolto: I parametri della durata IPSec/IKE del servizio della rete WAN virtuale di Azure della destinazione non SD-WAN (NSD) tramite gateway non corrispondono ai valori predefiniti di Azure.

    Il problema si verifica quando l'utente crea una NSD tramite il servizio della rete WAN virtuale di Azure del gateway utilizzando l'interfaccia utente di VMware SD-WAN Orchestrator. Questo problema non si verifica quando la NSD viene creata o aggiornata tramite l'API di Orchestrator.

  • Problema 54586 risolto: In un VMware SD-WAN Edge con route statiche configurate, quando viene creato un nuovo criterio di business in VMware SD-WAN Orchestrator, è possibile che vengano rimosse varie route statiche. 

    Il problema è causato da una funzionalità dell'Edge che utilizza segmentId come indice causando un problema quando manca uno dei segmentId. 

  • Problema 52033 risolto: Per i partner che hanno distribuito gateway del partner di VMware SD-WAN si verifica quanto segue: a) nella pagina Gateway (Gateways) di VMware SD-WAN Orchestrator viene visualizzato un messaggio di errore e b) una richiesta all'API pubblica "enterpriseProxy/getEnterpriseProxyGateways" restituisce un errore.

    Il problema impedisce il recupero dei dati relativi ai gateway dei partner. La pagina Gateway (Gateways) nell'interfaccia utente non viene caricata. L'API pubblica "getEnterpriseProxyGateways" non recupera alcun dato. Questo problema può riguardare qualsiasi workflow correlato ai gateway dei partner.

  • Problema 52241 risolto: Quando una destinazione non SD-WAN (NSD) tramite un tunnel Edge viene disabilitata mediante VMware SD-WAN Orchestrator utilizzando Configura (Configure) > Edge > Impostazioni dispositivo (Device Settings), nella pagina Monitoraggio Edge (Edge Monitoring) lo stato del tunnel NSD tramite Edge continua a essere visualizzato come attivo.

    Il problema si verifica dopo aver deselezionato la casella di controllo "Abilita" (Enable) di una NSD tramite servizio Edge o tunnel.  Mentre il tunnel viene di fatto eliminato, nella colonna "Tunnel Edge" (Edge Tunnels) della pagina Monitoraggio Edge (Edge Monitoring) per l'Edge in questione, il tunnel viene visualizzato come attivo e connesso.

  • Problema 52306 risolto: Quando si utilizza la nuova interfaccia utente in un VMware SD-WAN Orchestrator, nella pagina Panoramica della rete (Network Overview) > Link (Links) se un VMware SD-WAN Edge utilizza più di un link WAN, solo per il primo link WAN viene visualizzato lo stato del link corretto.

    Per gli altri link WAN viene visualizzato un punto grigio come stato del link anziché uno stato effettivo, come Verde per lo stato attivo o Rosso per lo stato inattivo.

  • Problema 52721 risolto: Quando l'azienda di un cliente distribuisce una destinazione non SD-WAN (NSD) tramite Edge o un servizio di sicurezza cloud (CSS), l'utente non può modificare il provider di servizi di rete in Edge > Impostazioni dispositivo (Device Settings) quando in un altro Edge dell'azienda del cliente è presente un criterio di business che utilizza lo stesso provider di servizi di rete.

    Si tratta di un problema di convalida di Orchestrator causato dal codice che non tiene conto dell'ID Edge durante la convalida di una modifica della configurazione per una NSD tramite Edge o un CSS.

  • Problema 53104 risolto: Quando un operatore tenta di eseguire la migrazione di un'azienda da un VMware Orchestrator a un altro Orchestrator utilizzando lo strumento di migrazione e nell'azienda sono configurati alcuni tipi di dati BLOB, la migrazione non riesce nella fase di importazione.

    Poiché i dati BLOB non devono essere presenti nell'Orchestrator di destinazione, lo strumento di migrazione deve eliminare i dati BLOB e non importarli nell'Orchestrator di destinazione.

  • Problema 53524 risolto: Se la scheda SIM viene rimossa da un VMware SD-WAN Edge 510-LTE, quando si visualizza la pagina Monitora (Monitor) > Edge nella nuova interfaccia utente di VMware SD-WAN Orchestrator, il link corrispondente viene visualizzato come standby e non come inattivo/offline.

    Il problema è connesso allo stato del link quando il link smette di inviare dati e l'API non ha alcun dato da inviare al front-end. In questo caso il link viene visualizzato come link di standby.  Nell'interfaccia utente precedente viene utilizzato un metodo diverso per monitorare lo stato del link e questo problema non si verifica.

  • Problema 55244 risolto: Quando si esegue la migrazione di un VMware SD-WAN Orchestrator distribuito in una topologia di ripristino di emergenza da una versione 3.4.x a una versione 4.x.x, è possibile che la migrazione rallenti significativamente e non venga completata.

    Durante la migrazione di un Orchestrator del ripristino di emergenza, nel MySQL di Orchestrator potrebbe verificarsi un aumento imprevisto del numero di connessioni che gestiscono le query per recuperare un numero elevato di flussi, determinando un carico elevato su MySQL. Il sovraccarico di MySQL influisce negativamente sul resto dei sistemi causando risposte API lente e compromettendo l'esperienza utente complessiva. Il processo di migrazione non tiene conto di tale lentezza e si verifica un timeout aggressivo per l'attività. A causa del timeout aggressivo, il processo registra un errore ma la query continua a essere eseguita in MySQL. Di conseguenza, quando viene attivato il processo successivo, iniziano ad accumularsi sempre più query MySQL e ciò influisce negativamente sulle prestazioni del sistema.

  • Problema 56485 risolto: Se un VMware SD-WAN Orchestrator viene aggiornato a una versione 4.x qualsiasi e utilizza la nuova interfaccia utente, quando si consulta la pagina Monitoraggio Edge (Edge Monitoring), la scheda delle statistiche del percorso non è visibile per un utente che ha effettuato l'accesso come amministratore partner con ruolo di superuser.

    In un Orchestrator con questa correzione, non si verifica più il problema di visibilità delle statistiche del percorso per i superuser partner.

  • Problema 57001 risolto: In un VMware SD-WAN Orchestrator che utilizza la versione 4.x.x o successiva e la nuova interfaccia utente, nella pagina Monitora (Monitor) > Edge (Edges), in Velocità effettiva media (Average Throughput) sono visualizzati gli stessi dati di Byte ricevuti/inviati (Bytes Received/Sent).

    Questo problema si verifica solo quando si utilizza la nuova interfaccia utente Angular.  In tale interfaccia un utente passa a Monitora (Monitor) > Edges (Edge), sceglie un Edge, seleziona la scheda Percorsi (Paths) e quindi sceglie "Velocità effettiva media" (Average Throughput) nel menu a discesa.

  • Problema 57063 risolto: Se l'ora di inizio e di fine di una chiamata API si sovrappongono esattamente all'ora in cui un VMware SD-WAN Edge esporta i dati in VMware SD-WAN Orchestrator, si verificano i due comportamenti seguenti: a) nella risposta alle chiamate API delle metriche del link emesse dall'interfaccia utente di Orchestrator o dai client SDK viene restituito un valore più elevato del normale. b) nelle chiamate API delle serie di link emesse dall'interfaccia utente di Orchestrator o dai client SDK il valore dell'ultima serie temporale è più elevato del solito.

    Un utente può vedere questa discrepanza quando consulta la scheda Monitora (Monitor) > Trasporto (Transport) nell'interfaccia utente di Orchestrator o quando un client SDK richiama le chiamate API getEdgeLinkMetrics, getEdgeLinkSeries e getAggregateLinkMetrics.  In entrambi i casi, questo problema si verifica raramente dati i requisiti indicati nella descrizione dei sintomi.

Problemi noti

Problemi ancora irrisolti nella versione 4.0.2

I problemi noti sono raggruppati come segue.

Problemi noti di Edge/Gateway
  • Problema 14655:

    Se si collega o si scollega un adattatore SFP, il dispositivo può bloccarsi nell'Edge 540, Edge 840 e Edge 1000 e richiedere un riavvio fisico.

    Soluzione alternativa: l'Edge deve essere riavviato fisicamente.  Tale operazione può essere effettuata sia su Orchestrator tramite Azioni remote (Remote Actions) > Riavvia Edge (Reboot Edge) oppure tramite il ciclo di alimentazione dell'Edge.

  • Problema 25504:

    I costi di routing statici superiori a 255 potrebbero comportare un ordinamento delle route imprevedibile.  

    Soluzione alternativa: utilizzare un costo della route compreso tra 0 e 255

  • Problema 25595:

    Potrebbe essere necessario riavviare il servizio affinché le modifiche apportate a una SLA statica su un overlay WAN funzionino correttamente.  

    Soluzione alternativa: riavviare l'Edge dopo aver aggiunto e rimosso una SLA statica dall'overlay WAN

  • Problema 25742:

    Il traffico conteggiato come underlay è limitato al massimo della capacità verso il VMware SD-WAN Gateway, anche se è inferiore alla capacità di un link WAN privato che non è connesso al gateway.  

  • Problema 25758:

    I link WAN USB potrebbero non essere aggiornati correttamente quando si passa da una porta USB a un'altra fino a quando non viene riavviato il VMware SD-WAN Edge.  

    Soluzione alternativa: riavviare l'Edge dopo aver spostato i link WAN USB da una porta all'altra.

  • Problema 25855:

    Un grande aggiornamento della configurazione nel gateway partner (ad esempio, 200 VRF abilitati per BGP) può causare un aumento della latenza di circa 2-3 secondi per il traffico tramite il VMware SD-WAN Gateway.

    Soluzione alternativa: nessuna soluzione alternativa disponibile.

  • Problema 25921:

    Quando sono presenti tremila Edge di filiale connessi all'hub, il failover ad alta disponibilità dell'hub VMware SD-WAN richiede più tempo del previsto (fino a 15 secondi).  

  • Problema 25997:

    Il VMware SD-WAN Edge potrebbe richiedere un riavvio per passare correttamente il traffico su un'interfaccia instradata che è stata convertita in una porta commutata.  

    Soluzione alternativa: riavviare l'Edge dopo aver apportato la modifica della configurazione.

  • Problema 26421:

    Per creare i tunnel al cluster, a un cluster di hub VMware SD-WAN si deve assegnare anche il gateway partner primario per qualsiasi sito di filiale.  

  • Problema 28175:

    Il NAT dei criteri di business non riesce quando l'IP NAT si sovrappone con l'indirizzo IP dell'interfaccia del VMware SD-WAN Gateway.  

  • Problema 31210:

    VRRP: ARP non viene risolto nel client LAN per l'indirizzo IP virtuale VRRP quando il VMware SD-WAN Edge è master con un segmento CDE non globale in esecuzione nell'interfaccia LAN. 

  • Problema 32731:

    Le route predefinite condizionali annunciate tramite OSPF potrebbero non essere ritirate correttamente quando la route è disattivata. La riabilitazione e la disabilitazione della route verranno ritirate correttamente. 

  • Problema 32960:

    L'interfaccia "Negoziazione automatica" e "Velocità" potrebbe essere visualizzata erroneamente nell'interfaccia utente Web locale per gli VMware SD-WAN Edge attivati.

  • Problema 32981:

    L'impostazione di velocità e duplex come hardcoded su una porta abilitata per DPDK potrebbe richiedere il riavvio di un VMware SD-WAN Edge affinché le configurazioni abbiano effetto in quanto richiede la disabilitazione di DPDK.

  • Problema 34254:

    Quando viene creato un CSS di Zscaler e per il segmento globale sono configurate le impostazioni FQDN/PSK, queste impostazioni vengono copiate in segmenti non globali per formare tunnel IPSec a un CSS di Zscaler.

  • Problema 35778:

    Quando in un'interfaccia singola sono presenti più link WAN definiti dall'utente, solo uno di questi link WAN può disporre di un tunnel GRE a Zscaler. 

    Soluzione alternativa: utilizzare un'interfaccia diversa per ogni link WAN che deve creare tunnel GRE a Zscaler.

  • Problema 35807:

    Un'interfaccia instradata DPDK verrà completamente disabilitata se l'interfaccia viene disabilitata e riabilitata da VMware SD-WAN Orchestrator. 

  • Problema 36923:

    Il nome del cluster potrebbe non essere aggiornato correttamente nella descrizione dell'interfaccia NetFlow per un VMware SD-WAN Edge collegato a tale cluster come hub.

  • Problema 38682:

    Un VMware SD-WAN Edge che funge da server DHCP in un'interfaccia abilitata per DPDK potrebbe non generare correttamente gli eventi "Nuovo dispositivo client" per tutti i client connessi.

  • Problema 38767:

    Quando un overlay WAN per il quale sono già stati configurati tunnel GRE a Zscaler passa da essere rilevato automaticamente a definito dall'utente, fino al riavvio successivo potrebbero rimanere tunnel obsoleti.

    Soluzione alternativa: riavviare l'Edge per cancellare il tunnel obsoleto.

  • Problema 39134:

    La statistica di stato del sistema "Percentuale CPU" non può essere segnalata correttamente in Monitora > Edge > Sistema per l'VMware SD-WAN Edge e in Monitora > Gateway per il VMware SD-WAN Gateway.

    Soluzione alternativa: gli utenti devono utilizzare le eliminazioni della coda di handoff per monitorare la capacità dell'Edge non la percentuale di CPU.

  • Problema 39374:

    La modifica dell'ordine dei VMware SD-WAN Gateway partner assegnati a un VMware SD-WAN Edge potrebbe non impostare correttamente il gateway 1 come gateway locale da utilizzare per il test della larghezza di banda.

  • Problema 39608:

    L'output del della diagnostica remota "Test ping" potrebbe mostrare per pochi istanti i contenuti non validi prima di mostrare i risultati corretti.

  • Problema 39624:

    Il ping tramite un'interfaccia secondaria potrebbe non riuscire quando l'interfaccia principale è configurata con PPPoE.

  • Problema 39659:

    In un sito configurato per l'alta disponibilità ottimizzata, con un solo link WAN su ogni VMware SD-WAN Edge, quando l'Edge di standby ha solo PPPoE connesso e quello attivo ha solo non-PPPoE connesso, è possibile uno stato split brain (attivo/attivo) se il cavo HA non riesce.

  • Problema 39753:

    La disabilitazione della VPN Da filiale a filiale dinamico può causare il blocco dei flussi esistenti in quel momento in fase di invio tramite Da filiale a filiale dinamico.

  • Problema 40096:

    Se viene riavviato un VMware SD-WAN Edge 840, è possibile che un modulo SFP collegato all'Edge interromperà il passaggio del traffico anche se il link si illumina e VMware SD-WAN Orchestrator mostrerà la porta come "ATTIVA". 

    Soluzione alternativa: scollegare il modulo SFP e ricollegarlo nuovamente alla porta.

  • Problema 40421:

    Traceroute non mostra il percorso quando attraversa un VMware SD-WAN Edge con un'interfaccia configurata come porta commutata.

  • Problema 42278:

    Per un tipo specifico di configurazione errata del peer, il VMware SD-WAN Gateway può inviare continuamente messaggi di inizializzazione IKE a un peer non SD-WAN. Questo problema non interrompe il traffico degli utenti al gateway. Tuttavia, i registri del gateway saranno compilati con errori IKE e ciò potrebbe oscurare voci di registro utili.

  • Problema 42388:

    In un VMware SD-WAN Edge 540, una porta SFP non viene rilevata dopo la disabilitazione e riabilitazione dell'interfaccia da VMware SD-WAN Orchestrator.

  • Problema 42488:

    In un VMware SD-WAN Edge che ha una porta commutata con VRRP abilitato, se il cavo è scollegato e viene riavviato il servizio Edge, vengono annunciate le route connesse alla LAN.

    Soluzione alternativa: non esistono soluzioni alternative a questo problema.

  • Problema 42872:

    L'abilitazione dell'isolamento del profilo in un profilo Hub in cui è associato un cluster di hub non revoca le route dell'hub dalla Routing Information Base (RIB).

  • Problema 43373:

    Quando si acquisisce la stessa route BGP da più VMware Edge di SD-WAN, se questa route viene spostata da uscita preferita a idonea nel controllo del flusso di overlay, l'Edge non viene rimosso dall'elenco degli annunci e continua a essere annunciato.

    Soluzione alternativa: abilitare il calcolo dei costi distribuiti in VMware SD-WAN Orchestrator.

  • Problema 44832:

    Il traffico proveniente da una destinazione non SD-WAN tramite Edge a un'altra destinazione non SD-WAN tramite Edge (ovvero, "Hairpinning" o "Loopback NAT" (NAT loopback)) viene rimosso in VMware SD-WAN Edge.

  • Problema 44995:

    Le route OSPF non vengono revocate dagli VMware SD-WAN Gateway e VMware SD-WAN Edge spoke quando le route vengono ritirate dal cluster di hub.

  • Problema 45189:

    Con il NAT lato LAN di origine configurato, il traffico proveniente da un VMware SD-WAN Edge spoke a un Edge hub è consentito anche senza la configurazione della route statica per la subnet NAT.

  • Problema 45302:

    In un cluster di hub VMware SD-WAN, se un hub perde la connettività per più di 5 minuti a tutti i VMware SD-WAN Gateway comuni tra di loro e i relativi Edge spoke assegnati, in rare condizioni gli spoke possono perdere le route dell'hub dopo 5 minuti. Il problema si risolve quando l'hub recupera il contatto con i gateway.

  • Problema 46053:

    Le preferenze di BGP non vengono corrette automaticamente per le route di overlay quando il relativo router adiacente viene modificato in un router adiacente di uplink.

    Soluzione alternativa: un riavvio del servizio Edge correggerà il problema.

  • Problema 46137:

    Un VMware SD-WAN Edge sul quale è in esecuzione il software 3.4.x non avvia un tunnel con crittografia AES-GCM anche se l'Edge è configurato per GCM.

  • Problema 46216:

    In una destinazione non SD-WAN tramite gateway o Edge in cui il peer è un'istanza di AWS, quando il peer avvia la ridefinizione della chiave di fase 2, anche l'IKE di fase 1 viene eliminata e applica una ridefinizione della chiave.  Ciò significa che il tunnel è stato eliminato e ricreato, causando la perdita di pacchetti durante la ricostruzione del tunnel.

    Soluzione alternativa: per evitare la distruzione del tunnel, configurare il timer delle destinazioni non SD-WAN tramite gateway/Edge o di ridefinizione della chiave IPSec di CSS su un valore inferiore a 60 minuti.  Ciò impedisce ad AWS di avviare la ridefinizione della chiave.

  • Problema 46391:

    Per un VMware SD-WAN Edge 3800, le interfacce SFP1 e SFP2 hanno entrambe problemi con SFP multi-rate (ovvero 1/10G) e non devono essere utilizzate in tali porte.

    Soluzione alternativa: utilizzare gli SFP single-rate per l'articolo della Knowledge Base VMware SD-WAN Supported SFP Module List (79270).  Gli SFP multi-rate possono essere utilizzati con SFP3 e SFP4.

  • Problema 46628:

    Le porte GE5 e GE6 in un VMware SD-WAN Edge 620/640/680 non rilevano un link se le porte sono configurate con 100 Mbps e duplex.

  • Problema 46918:

    Un VMware SD-WAN Edge spoke che utilizza la versione 3.4.2 non aggiorna correttamente l'ID di rete privata di un nodo Cluster di hub.

  • Problema 47084:

    Un VMware SD-WAN Edge hub non può stabilire più di 750 PIM (Protocol-Independent Multicast) adiacenti quando sono presenti 4000 Edge spoke collegati.

  • Problema 47244:

    In un VMware SD-WAN Edge 6x0 attivato con DPDK abilitato e alcuni SFP di rame, l'Edge mostrerà il link come "ATTIVO" anche quando non è stato inserito alcun cavo nell'interfaccia utente di VMware SD-WAN Orchestrator.

    Soluzione alternativa: collegare e scollegare un cavo per rimuovere la condizione di falso.

  • Problema 47355:

    Quando viene acquisita la stessa route tramite BGP dell'underlay locale, il BGP dell'hub e/o statisticamente configurato nel gateway partner, l'ordinamento delle route è errato e il BGP dell'hub è preferibile rispetto al BGP dell'underlay.

  • Problema 47664:

    In una configurazione di hub e spoke dove la VPN da filiale a filiale tramite hub è disabilitata, il tentativo di invertire il traffico da filiale a filiale tramite una route di riepilogo in uno switch/router L3 causerà loop di routing.

    Soluzione alternativa: configurare VPN cloud per abilitare la VPN da filiale a filiale e selezionare “Usa hub per VPN”.

  • Problema 47681:

    Quando un host lato LAN di un VMware SD-WAN Edge utilizza lo stesso indirizzo IP dell'interfaccia WAN di quell'Edge, la connessione dall'host LAN alla WAN non funziona.

  • Problema 47787:

    Un VMware SD-WAN Edge spoke configurato con un criterio di business di backhaul invia erroneamente il traffico tramite il percorso del VMware SD-WAN Gateway se tale flusso viene avviato dall'Edge hub all'Edge spoke.

  • Problema 48166:

    Un VMware SD-WAN Edge virtuale su KVM non è supportato quando si utilizza un sistema operativo di virtualizzazione Ciena e l'Edge subirà errori del servizio piano dati ricorrenti.

  • Problema 48175:

    Un VMware SD-WAN Edge che esegue la versione 3.4.2 formerà un'adiacenza OSPF su un segmento non globale se il segmento non globale ha un'interfaccia configurata nello stesso intervallo di indirizzi IP di un'interfaccia configurata nel segmento globale.

  • Problema 48179:

    Un VMware SD-WAN Edge potrebbe subire un errore del servizio piano dati durante la generazione di un bundle di diagnostica.

    Soluzione alternativa: non esistono soluzioni alternative a questo problema.

  • Problema 48488:

    La regola del criterio di business non viene sovrascritta se la casella del traffico in uscita non è selezionata (per il traffico avviato dal peer remoto e consentito dalla regola NAT 1:1).

    Soluzione alternativa: selezionare "Traffico in uscita" in NAT 1:1.

  • Problema 48502:

    In alcuni scenari, un VMware SD-WAN Edge hub utilizzato per il backhaul del traffico Internet potrebbe subire un errore del servizio piano dati a causa della manipolazione non corretta dei pacchetti di ritorno del backhaul.

  • Problema 48530:

    Gli VMware SD-WAN Edge 6x0 non eseguono la negoziazione automatica per gli SFP di rame a tripla velocità (10/100/1000 Mbps).

    Soluzione alternativa: l'Edge 520/540 supporta gli SFP di rame a tripla velocità, ma questo modello è stato contrassegnato per la cessata vendita entro il primo trimestre del 2021.

  • Problema 48666:

    Il calcolo dell'MTU del percorso del gateway di fronte a un IPSec non tiene conto del sovraccarico dell'IPSec di 61 byte, determinando un annuncio dell'MTU più elevato al client LAN e la successiva frammentazione dei pacchetti IPSec.

    Soluzione alternativa: non esistono soluzioni alternative a questo problema.

  • Problema 49055 risolto: VMware SD-WAN Edge può eliminare pacchetti in esecuzione durante l'handoff tra thread diversi nel percorso dei dati e in fase di invio di DPDK.

    Se in uno dei link WAN dell'Edge si verifica l'oversubscription, l'Edge inizia a eliminare i pacchetti in fase di invio di DPDK e durante l'handoff a thread diversi nella pipeline. La correzione consente di ridurre il problema aumentando le dimensioni della coda per il buffering dei pacchetti e le dimensioni del buffer di riordinamento modificabile.

  • Problema 49172:

    Una regola NAT basata su criteri configurata con la stessa subnet NAT per due diversi VMware SD-WAN Edge non funziona.

  • Problema 49738:

    In alcuni casi, quando un VMware SD-WAN Edge spoke è configurato per l'utilizzo di più Edge hub, l'Edge spoke potrebbe non formare tunnel a uno degli hub configurati nell'elenco di hub.

  • Problema 50518:

    In un VMware SD-WAN Gateway in cui è abilitata l'infrastruttura PKI, se > 6000 tunnel PKI tentano di connettersi al gateway, i tunnel potrebbero non diventare tutti attivi perché le SA in entrata non vengono eliminate.

    Nota: I tunnel che utilizzano l'autenticazione con chiave precondivisa (PSK) non hanno questo problema.

  • Problema 53219: Dopo il ribilanciamento di un cluster di hub VMware SD-WAN, è possibile che l'interfaccia RPF o IIF non siano impostati correttamente.

    Questo problema influisce sul traffico multicast degli Edge spoke in cui si verifica. Ciò che accade è dovuto al fatto che dopo un ribilanciamento del cluster, alcuni degli Edge spoke non riescono a inviare un join PIM.

    Soluzione: il problema persiste finché negli Edge spoke interessati non viene riavviato il servizio Edge.

Problemi noti di Orchestrator
  • Problema 19566:

    Dopo il failover ad alta disponibilità, il numero di serie del VMware SD-WAN Edge di standby può essere visualizzato come il numero di serie attivo nell'Orchestrator.

  • Problema 20900:

    Se il servizio di geolocalizzazione MaxMind è abilitato e non è in grado di raggiungere il server MaxMind, le nuove attivazioni del VMware SD-WAN Edge non funzioneranno.

  • Problema 21342:

    Quando si assegnano i gateway partner per segmento, l'elenco corretto delle assegnazioni del gateway potrebbe non essere visualizzato sotto l'opzione operatore "Visualizza gateway" nell'elenco di monitoraggio del VMware SD-WAN Edge.

  • Problema 24269:

    La rappresentazione grafica di Monitora > Trasporto > Perdita non riporta la perdita di link WAN mentre i grafici QoE riflettono questa perdita. 

  • Problema 25932:

    VMware SD-WAN Orchestrator consente di rimuovere VMware SD-WAN Gateway dal pool di gateway anche quando sono in uso.

  • Problema 32335:

    La pagina "Contratto di licenza con l'utente finale" (EUSA) genera un errore quando un utente tenta di accettare il contratto.

    Soluzione alternativa: assicurarsi che nel nome dell'azienda non siano presenti spazi iniziali o finali.

  • Problema 32435:

    È consentita una sostituzione del VMware SD-WAN Edge per una configurazione del NAT basata su criteri per le tuple che sono già configurate a livello di profilo e viceversa.

  • Problema 32856:

    Sebbene un criterio di business sia configurato per utilizzare il cluster di hub per il backhaul del traffico Internet, l'utente può deselezionare il cluster di hub da un profilo in un VMware SD-WAN Orchestrator che è stato aggiornato dalla versione 3.2.1 alla versione 3.3.x.

  • Problema 32913:

    Dopo l'abilitazione dell'alta disponibilità, i dettagli multicast per il VMware SD-WAN Edge non vengono visualizzati nella pagina di monitoraggio. Un failover risolve il problema.

  • Problema 33026:

    La pagina "Contratto di licenza con l'utente finale" (EUSA) non viene ricaricata correttamente dopo l'eliminazione del contratto.

  • Problema 34828:

    Il traffico non può passare tra un VMware SD-WAN Edge spoke versione 2.x e un Edge hub che usa la versione 3.3.1.

  • Problema 35658:

    Quando un VMware SD-WAN Edge viene spostato da un profilo a un altro con impostazione del CSS diversa (ad esempio, da IPSec in profilo1 a GRE in profilo2), le impostazioni del CSS a livello di Edge continueranno a utilizzare le impostazioni del CSS precedenti (ad esempio, IPSec versus GRE). 

    Soluzione alternativa: per risolvere il problema, disabilitare e quindi riabilitare GRE a livello di Edge.

  • Problema 35667:

    Quando un VMware SD-WAN Edge viene spostato da un profilo a un altro profilo che ha la stessa impostazione del CSS ma un nome CSS GRE diverso (gli stessi endpoint), alcuni tunnel GRE non verranno visualizzati nel monitoraggio.

    Soluzione alternativa: per risolvere il problema, disabilitare e quindi riabilitare GRE a livello di Edge.

  • Problema 36665:

    Se VMware SD-WAN Orchestrator non riesce a raggiungere Internet, le pagine dell'interfaccia utente che richiedono l'accesso all'API di Google Maps potrebbero non caricarsi completamente.

  • Problema 38056:

    Il file export.csv delle licenze Edge non mostra i dati della regione.

  • Problema 38843:

    Quando si invia in push una mappa delle applicazioni, non è presente alcun evento operatore e l'evento Edge è di utilità limitata.

  • Problema 39633:

    Il link ipertestuale del super gateway non funziona dopo che un utente ha assegnato il gateway alternativo come super gateway.

  • Problema 39790:

    VMware SD-WAN Orchestrator consente a un utente di configurare un'interfaccia instradata di VMware SD-WAN Edge in modo che abbia un numero di interfacce secondarie supportate superiore a 32, creando il rischio che un utente possa configurare 33 o più interfacce secondarie su un'interfaccia e ciò potrebbe causare un errore del servizio piano dati per l'Edge.

  • Problema 40341:

    Sebbene l'applicazione Skype sia correttamente classificata nel backend come traffico in tempo reale, quando si modifica il criterio di business di Skype in VMware SD-WAN Orchestrator, la classe di servizio potrebbe visualizzare erroneamente "Transazionale".

  • Problema 41691:

    L'utente non può modificare il campo "Numero di indirizzi" (Number of addresses) anche se il pool DHCP non è esaurito nella pagina Configura (Configure) > Edge > dispositivo (Device).

  • Problema 43276:

    L'utente non può modificare il tipo di segmento quando un VMware SD-WAN Edge o un profilo ha un gateway partner configurato.

  • Problema 44153:

    VMware SD-WAN Orchestrator non invia costantemente e-mail di avviso agli indirizzi e-mail configurati nella sezione "Avvisi e notifiche".

  • Problema 46254:

    Durante un'attivazione del VMware SD-WAN Edge, VMware SD-WAN Orchestrator non rileva una MTU del link WAN modificato o la presenza di un ID VLAN per le interfacce configurate da DHCP.

  • Problema 47269:

    L'interfaccia VMware SD-WAN 510-LTE può essere visualizzata per i modelli Edge che non supportano un'interfaccia LTE.

  • Problema 47713:

    Se una regola del criterio di business viene configurata con la VPN cloud disabilitata, è necessario ripetere la configurazione del NAT al momento dell'abilitazione della VPN cloud.

  • Problema 47820:

    Se una VLAN viene configurata con DHCP disabilitato a livello di profilo, al contempo è presente una sostituzione dell'Edge per questa VLAN in tale Edge con DHCP abilitato, ed è presente una voce per il campo del server DNS impostato su Nessuno (nessun indirizzo IP configurato), l'utente non sarà in grado di apportare modifiche alla pagina Configura > Edge > Dispositivo e riceverà un messaggio di errore di "Indirizzo IP non valido []" che non spiega o punta al problema effettivo.

  • Problema 48085:

    VMware SD-WAN Orchestrator consente a un'utente di eliminare una VLAN associata a un'interfaccia.

  • Problema 48737:

    In un VMware SD-WAN Orchestrator che utilizza la nuova interfaccia utente versione 4.0.0, se un utente si trova in una pagina di monitoraggio e modifica l'intervallo di tempo iniziale e finale e poi naviga tra le schede, Orchestrator non aggiorna l'intervallo di tempo iniziale e finale sui nuovi valori.

  • Problema 49225:

    VMware SD-WAN Orchestrator non applica un limite di 32 VLAN totali.

  • Problema 49790:

    Quando un VMware SD-WAN Edge viene attivato alla versione 4.0.0, l'attivazione viene pubblicata due volte negli eventi.

    Soluzione alternativa: ignorare l'evento duplicato.

  • Problema 50531:

    Quando due operatori con privilegi diversi utilizzano la stessa finestra del browser nel momento in cui accedono alla nuova interfaccia utente in una versione 4.0.0 di VMware SD-WAN Orchestrator e l'operatore con privilegi minori tenta di effettuare l'accesso dopo l'operatore con privilegi superiori, l'operatore con privilegi minori osserverà più errori affermando che "l'utente non ha privilegi" (user does not have privilege).

    Nota: Non vi è alcuna escalation dei privilegi per l'operatore con privilegi inferiori, bensì solo la visualizzazione dei messaggi di errore.

    Soluzione alternativa: l'operatore successivo può aggiornare la pagina prima di accedere per evitare di vedere gli errori, oppure ogni operatore può utilizzare finestre del browser diverse per evitare questo problema di visualizzazione.

  • Problema 51722: Nella versione 4.0.0 di VMware SD-WAN Orchestrator, il selettore dell'intervallo di tempo non è superiore a due settimane per qualsiasi statistica nelle schede Monitora (Monitor) > Edge.

    Il selettore dell'intervallo di tempo non include opzioni superiori a "Ultime 2 settimane (Past 2 Weeks)" nelle schede Monitora (Monitor) > Edge anche se il periodo di conservazione per un set di statistiche è molto più lungo di 2 settimane.  Ad esempio, le statistiche del flusso e del link vengono conservate per 365 giorni per impostazione predefinita (questa opzione è configurabile), mentre le statistiche del percorso vengono conservate solo per 2 settimane per impostazione predefinita (anche questa opzione è configurabile).  Il problema sta nel fare in modo che tutte le schede di monitoraggio siano conformi al periodo minimo di conservazione delle statistiche oppure consentire all'utente di selezionare un intervallo di tempo coerente con il periodo di conservazione per una determinata statistica.

    Soluzione: per visualizzare i dati per più di 2 settimane, l'utente può utilizzare l'opzione "Personalizzato (Custom)" nel selettore dell'intervallo di tempo.

  • Problema 53652: Nel visualizzatore delle applicazioni dell'interfaccia utente Web di VMware SD-WAN Orchestrator viene visualizzato un nome casuale per un'applicazione personalizzata creata prima dell'aggiornamento di Orchestrator alla versione 4.0.1.

    Ogni volta che un'applicazione personalizzata viene configurata con un appId già esistente come parte della mappa delle applicazioni iniziale predefinita, il nome visualizzato per l'applicazione personalizzata è sempre quello della mappa delle applicazioni iniziale predefinita, che sostituisce il nome definito dal cliente. Anche quando Orchestrator viene aggiornato da una versione precedente a una versione successiva e il valore di appIds della mappa delle applicazioni iniziale predefinita della versione successiva è in conflitto con il valore di appIds di un'applicazione personalizzata creata in una versione precedente, dopo l'aggiornamento il nome visualizzato per tale applicazione personalizzata non è corretto. È infatti il nome visualizzato della mappa delle applicazioni iniziale predefinita della versione successiva di Orchestrator anziché il nome visualizzato dell'applicazione personalizzata della versione precedente.

    Soluzione: scaricare la mappa delle applicazioni, correggere manualmente il valore di appIds dell'applicazione personalizzata (ovvero modificare il valore di appIds dell'applicazione personalizzata a partire da 7000, 7001 e così via). Caricare la mappa delle applicazioni appena modificata. Duplicare il profilo operatore corrente, sostituire la mappa delle applicazioni con la mappa delle applicazioni appena modificata e quindi assegnare questo profilo operatore duplicato agli Edge dell'azienda del cliente.

check-circle-line exclamation-circle-line close-line
Scroll to top icon