Note di rilascio di VMware SASE 5.4.0

VMware SASE 5.4.0 \| 16 novembre 2023 VMware SASE™ Orchestrator versione R5401-20231115-GA VMware SD-WAN™ Gateway versione R5400-20231009-GA VMware SD-WAN™ Edge versione R5400-20231108-GA-125647 Verificare la disponibilità di informazioni aggiuntive e aggiornamenti relativi a queste note di rilascio.

VMware SASE 5.4.0 | 16 novembre 2023

VMware SASE™ Orchestrator versione R5401-20231115-GA
VMware SD-WAN™ Gateway versione R5400-20231009-GA
VMware SD-WAN™ Edge versione R5400-20231108-GA-125647

Verificare la disponibilità di informazioni aggiuntive e aggiornamenti relativi a queste note di rilascio.

Contenuto delle note di rilascio

Le note di rilascio riguardano i seguenti argomenti:

Uso consigliato
Compatibilità
Percorsi di aggiornamento per Orchestrator, Gateway ed Edge
Nuove funzionalità e miglioramenti di SASE
Nuove funzionalità e miglioramenti di SD-WAN
Note importanti
Lingue disponibili
Modifiche dell'API di Orchestrator
Cronologia delle versioni del documento

Uso consigliato

Questa versione è consigliata per tutti i clienti che richiedono le funzionalità e le caratteristiche rese disponibili per la prima volta nella versione 5.4.0.

Importante:

La versione 5.4.0 contiene tutte le correzioni di Edge e Gateway elencate nelle Note di rilascio dalla versione 5.2.0 fino alla versione 5.2.0.2, nonché tutte le correzioni di Orchestrator elencate nelle Note di rilascio dalla versione 5.2.0 fino alla versione 5.2.0.3 e nelle Note di rilascio dalla versione 5.3.0 fino alla versione 5.3.0.2.

Compatibilità

La versione 5.4.0 di Orchestrator, Gateway ed Edge hub supporta tutte le versioni di VMware SD-WAN Edge precedenti con versione 4.2.0 o successiva.

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

Orchestrator	Gateway	Edge
Orchestrator	Gateway	Hub	Filiale/spoke
5.4.0	4.2.2	4.2.2	4.2.2
5.4.0	5.4.0	4.2.2	4.2.2
5.4.0	5.4.0	5.4.0	4.2.2
5.4.0	5.4.0	4.2.2	5.4.0
5.4.0	4.3.2	4.3.2	4.3.2
5.4.0	5.4.0	4.3.2	4.3.2
5.4.0	5.4.0	5.4.0	4.3.2
5.4.0	5.4.0	4.3.2	5.4.0
5.4.0	4.5.2	4.5.2	4.5.2
5.4.0	5.4.0	4.5.2	4.5.2
5.4.0	5.4.0	5.4.0	4.5.2
5.4.0	5.4.0	4.5.2	5.4.0
5.4.0	5.0.1.3	5.0.1.3	5.0.1.3
5.4.0	5.4.0	5.0.1.3	5.0.1.3
5.4.0	5.4.0	5.4.0	5.0.1.3
5.4.0	5.4.0	5.0.1.3	5.4.0
5.4.0	5.1.0.3	5.1.0.2	5.1.0.2
5.4.0	5.4.0	5.1.0.2	5.1.0.2
5.4.0	5.4.0	5.4.0	5.1.0.2
5.4.0	5.4.0	5.1.0.2	5.4.0
5.4.0	5.2.0.1	5.2.0.1	5.2.0.1
5.4.0	5.4.0	5.2.0.1	5.2.0.1
5.4.0	5.4.0	5.4.0	5.2.0.1
5.4.0	5.4.0	5.2.0.1	5.4.0
5.4.0	5.4.0	5.4.0	5.4.0

Nota:

la tabella precedente è valida solo per i clienti che utilizzano servizi SD-WAN. I clienti che devono accedere a VMware Cloud Web Security o VMware Secure Access, devono aggiornare gli Edge alla versione 4.5.0 o successiva.

Importante:

Le versioni 4.0.x di VMware SD-WAN hanno raggiunto la fine del supporto. Le versioni 4.2.x e 4.3.x hanno raggiunto la fine del supporto per Gateway e Orchestrator e le versioni 4.5.x stanno per raggiungere la fine del supporto per Gateway e Orchestrator.

Le versioni 4.0.x hanno raggiunto la fine del supporto generale (EOGS, End of General Support) il 30 settembre 2022 e la fine delle linee guida tecniche (EOTG, End of Technical Guidance) il 31 dicembre 2022.
Le versioni 4.2.x per Orchestrator e Gateway hanno raggiunto la fine del supporto generale (EOGS) il 30 dicembre 2022 e la fine delle linee guida tecniche (EOTG) il 30 marzo 2023.
Le versioni 4.2.x dell'Edge ha raggiunto la fine del supporto generale (EOGS, End of General Support) il 30 giugno 2023 e raggiungeranno la fine delle linee guida tecniche (EOTG, End of Technical Guidance) il 30 settembre 2025.
Le versioni 4.3.x di Orchestrator e Gateway hanno raggiunto la fine del supporto generale (EOGS, End of General Support) il 30 giugno 2023 e la fine delle linee guida tecniche (EOTG, End of Technical Guidance) il 30 settembre 2023.
Le versioni 4.3.x dell'Edge hanno raggiunto la fine del supporto generale (EOGS, End of General Support) il 30 giugno 2023 e raggiungeranno la fine delle linee guida tecniche (EOTG, End of Technical Guidance) il 30 settembre 2025.
Le versioni 4.5.x di Orchestrator e Gateway hanno raggiunto la fine del supporto generale (EOGS, End of General Support) il 30 settembre 2023 e raggiungeranno la fine delle linee guida tecniche (EOTG, End of Technical Guidance) il 31 dicembre 2023.
Per ulteriori informazioni, consultare l'articolo della Knowledge Base: Announcement: End of Support Life for VMware SD-WAN Release 4.x (88319).

Percorsi di aggiornamento per Orchestrator, Gateway ed Edge

Di seguito sono elencati i percorsi per i clienti che desiderano aggiornare Orchestrator, Gateway o Edge da una versione precedente alla versione 5.4.0.

Orchestrator

Le istanze di Orchestrator che utilizzano la versione 4.3.0 o successiva possono essere aggiornate alla versione 5.4.0.

Gateway

L'aggiornamento di un Gateway che utilizza la versione 4.3.0 o successiva alla versione 5.4.0 è completamente supportato per tutti i tipi di Gateway.

Importante:

Quando si distribuisce un nuovo Gateway che utilizza la versione 5.4.0, nell'istanza di VMware ESXi deve essere installata almeno la versione 6.7, Update 3 o successiva fino alla versione 7.0. Se si utilizza un'istanza di ESXi precedente, il servizio piano dati del Gateway non funziona quando si tenta di eseguire la versione 5.4.0 o successiva.

Importante:

Prima di aggiornare un Gateway alla versione 5.4.0, aggiornare l'istanza di ESXi almeno alla versione 6.7, Update 3 o successiva fino alla versione 7.0. Se si utilizza un'istanza di ESXi precedente, il servizio piano dati del Gateway non funziona quando si tenta di eseguire la versione 5.4.0 o successiva.

Edge

Un Edge può essere aggiornato direttamente alla versione 5.4.0 da qualsiasi versione 4.x o successiva.

Nuove funzionalità e miglioramenti di SASE

Orchestrator Bastion, fase 2

Introdotto per la prima volta nella versione 4.3.0, VMware SASE offre miglioramenti significativi dell'Orchestrator Bastion nella versione 5.4.0. I miglioramenti della fase 2 includono:

Aggiornamento del software SD-WAN Edge quando lo stato dell'Edge è Attivato (Activated).
Ripristino all'ultima configurazione corretta nota in caso di errore di promozione dell'Edge.
Gli eventi di un Edge che non viene promosso vengono inviati a un VMware SASE Orchestrator privato.
Generazione di un bundle di diagnostica per un Edge che non viene promosso.
Aggiornamenti del firmware aziendale in VMware SASE Orchestrator Bastion.

SD-WAN Client integrato con VMware SASE Orchestrator

VMware SD-WAN Client può ora essere gestito tramite VMware SASE Orchestrator offrendo una console di gestione unificata per la gestione di soluzioni di rete, sicurezza e accesso remoto.

Nuove funzionalità e miglioramenti di SD-WAN

Supporto del firewall Edge per FTPv6

La versione 5.4.0 include l'identificazione dell'applicazione avanzata per le modalità Attiva e Passiva FTPv4/FTPv6 quando si utilizza VMware SD-WAN DPI (Deep Packet Inspection). Questo DPI migliorato è particolarmente utile per i clienti che utilizzano la modalità FTPv6 passiva, che assegna numeri di porta casuali per il trasferimento dei dati e rende difficile l'identificazione del traffico FTP perché non utilizza le porte standard 20 e 21.

Miglioramenti della visualizzazione e della ricerca del servizio firewall avanzato

Il servizio firewall avanzato ora include una visualizzazione della tabella del firewall con un campo dei commenti e una nuova funzionalità di ricerca per le regole e gli oggetti del firewall che offre un'esperienza utente ottimale.

Visualizzazione della firma del servizio firewall avanzato (IDS/IPS)

Il servizio firewall avanzato include una visualizzazione della firma (IDS/IPS) migliorata, che fornisce una visualizzazione semplificata con la visibilità delle firme dei sistemi di rilevamento delle intrusioni (IDS) e dei sistemi di prevenzione delle intrusioni (IPS) installate in un VMware SD-WAN Edge insieme alla versione, ai dati e all'ora dell'installazione.

Miglioramenti dell'alta disponibilità, fase 2

La versione 5.4.0 include miglioramenti aggiuntivi per un sito distribuito utilizzando una topologia ad alta disponibilità con una coppia di Edge. Tali miglioramenti includono:

Avvisi: nell'elenco della pagina Impostazioni servizio (Service Settings) > Avvisi e notifiche (Alerts & Notifications) è stato aggiunto il nuovo avviso Edge HA non riuscito (Edge HA Failed). L'avviso Edge HA non riuscito (Edge HA Failed) viene attivato quando l'Edge di standby non riesce a inviare l'heartbeat all'Edge attivo e viene contrassegnato dall'Edge attivo come inattivo. Questo avviso è particolarmente utile nelle distribuzioni HA avanzate in cui anche l'Edge di standby passa il traffico del cliente.
Compatibilità tra gli Edge con supporto Wi-Fi e gli Edge senza supporto Wi-Fi: prima della versione 5.4.0 dell'Edge, i modelli di Edge che non includevano un modulo Wi-Fi (510N, 610N, 620N, 640N e 680N) non potevano essere utilizzati con una controparte con supporto Wi-Fi in una distribuzione HA. Ad esempio, un Edge 640 e un Edge 640N non erano supportati come coppia ad alta disponibilità. Nelle versioni 5.4.0 e successive, questa associazione è supportata.

Nota:

In uno scenario con Edge Wi-Fi e non Wi-Fi non corrispondenti, Orchestrator rileva la mancata corrispondenza degli Edge e disattiva automaticamente la funzionalità Wi-Fi nell'Edge che supporta il Wi-Fi. Il registro della mancata corrispondenza viene visualizzato in Eventi (Events) del cliente:

HA Wi-Fi capability mismatch identified, disabled Wi-Fi (viene identificata una mancata corrispondenza del Wi-Fi dell'Edge e il Wi-Fi viene disattivato nell'Edge con supporto Wi-Fi).
Wi-Fi capability mismatch no longer seen, reverted Wi-Fi (entrambi gli Edge hanno lo stesso tipo di Wi-Fi e la funzionalità Wi-Fi viene ripristinata in un Edge Wi-Fi in cui era stata disattivata in precedenza).

Hub o Cluster Interconnect è GA

Introdotta per la prima volta come Early Access Feature in SD-WAN versione 5.1.0, Hub o Cluster Interconnect è completamente GA nella versione 5.4.0. Questa soluzione consente ai clienti di creare un'architettura gerarchica e scalabile con connettività di overlay SD-WAN completa tra hub cloud, regionali e data center, fornendo protezione DMPO completa (Dynamic Multipath Optimization), visibilità end-to-end e affidabilità.

Oltre al supporto completo per questa funzionalità, la limitazione del numero di hop precedente a due è stata aumentata a un numero qualificato di quattro hop.

Delega del prefisso DHCPv6 IPv6

Nella versione 5.4.0 è stato aggiunto il supporto della delega del prefisso DHCPv6 per i clienti in cui il router delegante fa parte dell'hosting cloud o si trova in una posizione remota oppure negli scenari in cui l'ISP del cliente alloca gli indirizzi IP. La delega del prefisso DHCPv6 include nuovi tipi di indirizzo per IPv6 e supporta due server di delega del prefisso ISP per consentire una topologia primaria e di backup.

Importante:

Per utilizzare la funzionalità di delega del prefisso, Orchestrator, Gateway ed Edge devono tutti utilizzare una versione del software 5.4.0 o successiva. L'utilizzo della delega del prefisso non è supportato in un Edge che usa la versione 5.2.0 o precedente. Se per la delega del prefisso è configurato un Edge che utilizza la versione 5.2.0 o precedente, il comportamento della funzionalità non è quello previsto.

Un Edge che utilizza la versione 5.2.0 o precedente configurato con la delega del prefisso non può essere aggiornato alla versione 5.4.0. Pertanto, se si esegue l'aggiornamento di un Edge 5.2.0 o versione precedente alla versione 5.4.0 o successiva, assicurarsi che la delega del prefisso non venga utilizzata in tale Edge.

Supporto del driver Mellanox Bifurcated per Microsoft Azure Virtual Edge

VMware SD-WAN fornisce il supporto della rete accelerata (SR-IOV) per Microsoft Azure Virtual Edge e include il supporto per le NIC Mellanox ConnectX-4 e ConnectX-5. Quando si attiva SR-IOV nell'interfaccia di un Azure Virtual Edge, il miglioramento viene attivato automaticamente nell'Edge.

La rete accelerata può essere attivata o disattivata tramite il portale di Azure, la CLI di Azure o Azure PowerShell.

Nota:

Questo miglioramento non include il supporto per le NIC Mellanox ConnectX-3

FastPath Run-To-Completion nell'Edge, fase 3

Run-To-Completion è un'ottimizzazione del software che aumenta le prestazioni negli Edge e nei Gateway migliorando l'efficienza complessiva della soluzione SD-WAN.

Note importanti

Modifica del comportamento della NAT lato LAN

A partire dalla versione 4.5, quando una NAT lato LAN è configurata per le conversioni da molti a uno che utilizzano PAT (Port Address Translation), il traffico avviato dalla direzione opposta può consentire l'accesso imprevisto agli indirizzi fissi in base alla maschera esterna e all'indirizzo IP originale. Questo nuovo comportamento si applica alle regole NAT di destinazione (DNAT) e NAT di origine (SNAT), nonché alle regole NAT di origine e destinazione (S+D NAT).

Ad esempio, una regola SNAT con una rete interna 192.168.1.0/24 e un indirizzo esterno 10.1.1.100/32 consente la conversione dall'esterno all'interno in 192.168.1.100.

A causa di questo nuovo comportamento, SD-WAN ora blocca il traffico quando viene avviata una connessione nella direzione PAT inversa.

Per ripristinare il comportamento originale, l'utente deve configurare due regole dello stesso tipo della regola originale (SNAT, DNAT, S+D NAT) in un ordine specifico. Ad esempio utilizzando lo scenario SNAT precedente, è necessario configurare quanto segue:

Regola SNAT con una rete interna 192.168.1.100/32 e un indirizzo esterno 10.1.1.100/32
Regola SNAT con una rete interna 192.168.1.0/24 e un indirizzo esterno 10.1.1.100/32

Se la regola originale è DNAT o S+D NAT, l'utente necessita di due regole DNAT o S+D NAT con la stessa struttura e lo stesso ordine.

A partire dalla versione 4.5.0 e fino alla versione 5.2.0, l'utente può stabilire se i flussi per questo tipo di traffico sono stati eliminati cercando nei registri dispcnt di un bundle di diagnostica il contatore lan_side_nat_reverse_pat_drop.

A partire dalla versione 5.4.0, l'utente può trovare sei contatori separati nei registri:

lan_side_nat_rev_pat_drop_snat1
lan_side_nat_rev_pat_drop_snat2
lan_side_nat_rev_pat_drop_dnat1
lan_side_nat_rev_pat_drop_dnat2
lan_side_nat_rev_pat_drop_sdnat1
lan_side_nat_rev_pat_drop_sdnat2

Limitazione quando si disattiva la negoziazione automatica nei modelli 520, 540, 620, 640, 680, 3400, 3800 e 3810 di VMware SD-WAN Edge

Se un utente disabilita la negoziazione automatica per forzare la velocità e il duplex nelle porte GE1 - GE4 in un modello 620, 640 o 680 di VMware SD-WAN Edge, nella porta GE3 o GE4 in un Edge 3400, 3800 o 3810 o in un Edge 520/540, quando viene utilizzato un SFP con un'interfaccia in rame nella porta SFP1 o SFP2, è possibile che anche dopo un riavvio il link non sia disponibile.

Il problema è causato da ciascuno dei modelli di Edge elencati che utilizzano Intel Ethernet Controller i350, che ha una limitazione per cui quando la negoziazione automatica non viene utilizzata in entrambi i lati del link, non è in grado di rilevare dinamicamente i cavi appropriati per la trasmissione e la ricezione (auto-MDIX). Se entrambi i lati della connessione trasmettono e ricevono tramite gli stessi cavi, il link non verrà rilevato. Se anche il lato peer non supporta auto-MDIX senza la negoziazione automatica e il link non è disponibile con un cavo diretto, sarà necessario un cavo Ethernet incrociato per attivare il link.

Per ulteriori informazioni, vedere l'articolo della Knowledge Base relativo alla limitazione quando si disattiva la negoziazione automatica nei modelli 520, 540, 620, 640, 680, 3400, 3800 e 3810 (87208) di VMware SD-WAN Edge.

Lingue disponibili

VMware SASE Orchestrator che utilizza la versione 5.4.0 è localizzato nelle lingue seguenti: ceco, inglese, portoghese europeo, francese, tedesco, greco, italiano, spagnolo, giapponese, coreano, cinese semplificato e cinese tradizionale.

Modifiche dell'API di Orchestrator

Modifiche dell'API di Orchestrator dalla versione 5.3.0

Modifiche dell'API del portale di VMware SASE Orchestrator ("API v1")

Di seguito sono segnalati i problemi che influiscono sugli utenti dell'API v1:

Ticket	Sintomo/Descrizione
Problema noto 118684	APIv1 non include gli ID incrementali nel payload per il riferimento dell'utente. Nell'ambito della migrazione in corso a un nuovo sistema di gestione del database, VMware SD-WAN ha sostituito alcuni ID incrementali come edgeId con ID logici. Questa modifica è necessaria perché la maggior parte delle interfacce ora utilizza ID logici. Si tratta di un problema puramente cosmetico ed è possibile mappare l'edgeId chiamante all'edgeLogicalId restituito.
Problema noto 123867	Le API delle serie e delle metriche dei link restituiscono un errore quando vengono chiamate senza un elenco di metriche. Si tratta di un problema che verrà risolto in una versione futura. Per risolvere questo problema, è possibile inviare la richiesta API con un elenco dei campi delle metriche che si desidera vengano restituite. In questo modo è possibile ricevere i dati necessari, anche se l'API restituisce un messaggio di errore. Questo problema non influisce sulla funzionalità delle API che possono quindi essere utilizzate per recuperare i dati.
Problema noto 127994	La specifica Swagger segnala un errore dello schema a causa di un additionalProperty: title nello schema di risposta. Si tratta di un problema cosmetico che non influisce sulla funzionalità dell'API. Questo problema verrà risolto in una versione futura e l'API può comunque essere utilizzata per recuperare i dati, anche se in Orchestrator viene segnalato questo errore dello schema.
Problema 127995 risolto	La specifica Swagger segnala un errore dello schema a causa di un tipo errato nel campo degli elementi dello schema di risposta. Si tratta di un problema cosmetico che non influisce sulla capacità dell'API di recuperare i dati. L'errore può quindi essere ignorato. Questo problema è stato risolto nella versione 5.4.0.

Per informazioni di riferimento, il registro delle modifiche completo dell'API può essere scaricato all'indirizzo developer.vmware.com (vedere "VMware SD-WAN Orchestrator API v1").

Modifiche di VMware SASE Orchestrator API v2

Non sono presenti nuove APIv2 dalla versione 5.3.0.

Di seguito vengono descritte le modifiche di APIv2 dalla versione 5.3.0 alla versione 5.4.0.

Ticket	Sintomo/Descrizione
Problema 116610 risolto	Gli utenti non possono aggiungere una nuova interfaccia di loopback tramite APIv2. La struttura dello schema per l'interfaccia di loopback in APIv2 non consente le interfacce denominate tramite l'ID interfaccia. Pertanto, l'aggiornamento dell'interfaccia di loopback non riesce.
Problema 129679 risolto	I clienti non potranno aggiornare il modulo delle impostazioni del dispositivo dell'Edge utilizzando le impostazioni del dispositivo dell'Edge APIv2 PATCH quando nel modulo delle impostazioni del dispositivo dell'Edge sono configurate interfacce secondarie. Quando nel modulo delle impostazioni del dispositivo dell'Edge sono configurate interfacce secondarie, se si chiama l'API delle impostazioni del dispositivo dell'Edge PATCH v2, la richiesta rimane sospesa con stato "Accettato" (Accepted) e alla fine si verifica il timeout della richiesta. Di conseguenza, i clienti non vedranno alcuna modifica riportata nel modulo delle impostazioni del dispositivo dell'Edge in Orchestrator.

Ticket

Sintomo/Descrizione

Problema 116610 risolto

Gli utenti non possono aggiungere una nuova interfaccia di loopback tramite APIv2. La struttura dello schema per l'interfaccia di loopback in APIv2 non consente le interfacce denominate tramite l'ID interfaccia. Pertanto, l'aggiornamento dell'interfaccia di loopback non riesce.

Problema 129679 risolto

I clienti non potranno aggiornare il modulo delle impostazioni del dispositivo dell'Edge utilizzando le impostazioni del dispositivo dell'Edge APIv2 PATCH quando nel modulo delle impostazioni del dispositivo dell'Edge sono configurate interfacce secondarie. Quando nel modulo delle impostazioni del dispositivo dell'Edge sono configurate interfacce secondarie, se si chiama l'API delle impostazioni del dispositivo dell'Edge PATCH v2, la richiesta rimane sospesa con stato "Accettato" (Accepted) e alla fine si verifica il timeout della richiesta. Di conseguenza, i clienti non vedranno alcuna modifica riportata nel modulo delle impostazioni del dispositivo dell'Edge in Orchestrator.

Documentazione per gli sviluppatori

Tutta la documentazione dell'API di VMware SASE/SD-WAN si trova nel portale della documentazione per gli sviluppatori all'indirizzo https://developer.vmware.com/apis.

Cronologia delle versioni del documento

16 novembre 2023. Seconda edizione.

Aggiunta una nuova build di rollup di Orchestrator R5401-20231115-GA nella sezione Problemi risolti di Orchestrator. Questa è la prima build di rollup di Orchestrator ed è la nuova build GA di Orchestrator predefinita per la versione 5.4.0.
La build di Orchestrator R5401-20231115-GA include le correzioni per i problemi 117138, 123078, 123387, 125309, 125964, 126602, 127727, 127774, 127843, 127904, 128017, 128277, 128279, 128357, 128765, 129061, 129494, 129584, 129756, 129765, 129894, 130153, 130877 e 131846 che sono tutti documentati in questa sezione.
Aggiunta la build aggiornata dell'Edge R5400-20231108-GA-125647 alla sezione Problemi risolti di Edge/Gateway. Questo è un aggiornamento della build GA dell'Edge originale R5400-20231009-GA ed è la nuova build GA di Edge/Gateway predefinita per la versione 5.4.0.

La build dell'Edge R5400-20231108-GA-125647 include la correzione del problema 125647 che è documentato in questa sezione.
Importante:
- La build dell'Edge della versione precedente 5.4.0 è stata deprecata e sostituita da R5400-20231108-GA-125647.
- I clienti che eseguono l'aggiornamento alla versione 5.4.0, possono eseguire l'aggiornamento solo alla versione R5202-20231107-GA-125647.
- I clienti che utilizzano già correttamente la build dell'Edge 5.4.0 originale non devono aggiornare i loro Edge alla versione R5400-20231108-GA-125647.

19 ottobre 2023. Prima edizione.

Problemi risolti di Edge/Gateway

Risolto nella versione R5400-20231108-GA-125647 dell'Edge
Risolti nella versione R5400-20231009-GA dell'Edge e del Gateway

Risolto nella versione R5400-20231108-GA-125647 dell'Edge

La build R5400-20231108-GA-125647 dell'Edge è stata rilasciata il 14/11/2023 ed è un aggiornamento della build GA dell'Edge per la versione 5.4.0.

Questa build dell'Edge aggiornata risolve il seguente problema critico presente dalla build GA originale, R5400-20231009-GA.

Importante:

Tutte le build dell'Edge della versione 5.2.0 precedenti sono state deprecate e sostituite da R5202-20231107-GA-125647.
I clienti che eseguono l'aggiornamento alla versione 5.2.0 possono eseguire l'aggiornamento solo a R5202-20231107-GA-125647.
I clienti che utilizzano già una build dell'Edge 5.2.0.x non devono aggiornare gli Edge alla versione R5202-20231107-GA-125647.

Problema 125647 risolto: Per un sito distribuito con un modello Edge 520 o 540, quando un Edge viene aggiornato alla versione 5.2.0, è possibile che per gli utenti del client connessi all'Edge tramite una porta LAN si verifichi una perdita totale di connettività.

Il riavvio dell'Edge 520/540 non consente di risolvere il problema e nemmeno il downgrade dell'Edge a una versione software precedente dopo l'aggiornamento a una versione 5.2.0. Quando la console dell'Edge è disattivata nelle impostazioni di Sicurezza Edge (Edge Security) > Accesso alla console (Console Access) nella pagina di configurazione Firewall di Orchestrator (che è la configurazione predefinita per qualsiasi Edge), il driver che gestisce le porte da LAN1 a LAN8 dell'Edge 520 o 540 non si configura correttamente, impedendo la creazione di tali porte.

In un Edge senza una correzione per questo problema, un cliente può impedire che si verifichi e/o ripristinare la connettività nelle porte LAN di un Edge interessato eseguendo le operazioni seguenti: passare a Configura (Configure) > Edge/Profilo (Profile) > Firewall > Sicurezza Edge (Edge Security) e in Accesso alla console (Console Access) fare clic su Abilita (Enable) e su Salva modifiche (Save Changes).

Nota:
La modifica di questa configurazione richiede un riavvio dell'Edge che viene completato in 2-3 minuti circa. Se possibile, eseguire questa modifica in una finestra di manutenzione.

Risolti nella versione R5400-20231009-GA dell'Edge e del Gateway

Nella build R5400-20231009-GA dell'Edge e del Gateway, rilasciata il 23/10/2023, sono stati risolti i seguenti problemi presenti dalla build R5202-20230725-GA dell'Edge e del Gateway.

Nota:

La versione 5.4.0 contiene tutte le correzioni di Edge e Gateway documentate nelle Note di rilascio dalla versione 5.2.0 fino alla versione 5.2.0.2 (R5202-20230725-GA).

Problema 69641 risolto: Nell'azienda di un cliente che utilizza uno o più criteri di business che includono limiti di velocità, il cliente può notare eliminazioni di pacchetti in tutti i flussi, anche quelli che non sono correlati ai flussi dei criteri di business con velocità limitata, nonché negli altri segmenti e peer.

L'impostazione di un criterio di business con velocità limitata e l'invio di traffico di richiesta più elevato (superiore al limite) con un numero elevato di flussi comportano l'eliminazione di pacchetti di altri flussi (anche da altri segmenti e peer) perché viene raggiunto il limite del buffer dell'utilità di pianificazione di rete.

In un'azienda i cui Edge non dispongono di una correzione per questo problema, la soluzione consiste nel rimuovere la configurazione del limite di velocità e riclassificare invece il traffico che soddisfa la regola con il valore più basso possibile (Basso (Low), Di massa (Bulk)).
Problema 74422 risolto: Se l'alta disponibilità è attivata, l'Edge può passare offline se solo l'Edge di standby dispone di un link WAN attivo e di un indirizzo IP valido.

Questo problema si verifica quando in un link WAN è abilitato DHCP in cui solo l'Edge di standby dispone di un link WAN. Quando il link WAN di standby riceve un indirizzo IP dal server DHCP, invia i dettagli dell'interfaccia all'Edge attivo. L'Edge attivo effettua una chiamata per aggiungere l'indirizzo IP come route, tuttavia questa funzione non aggiunge la route al kernel Linux. La funzione dell'Edge aggiunge solo la route alla FIB (Forwarding Information Base). Di conseguenza, il processo di gestione dell'Edge genera un errore perché non è presente alcuna route nella tabella di route del kernel Linux per l'uscita del pacchetto e il sito è di fatto offline.
Problema 79598 risolto: Nell'azienda di un cliente che utilizza Zscaler con tunnel ridondanti, se si verifica un failover del tunnel primario nel tunnel secondario, il traffico torna al tunnel primario prima del previsto.

Il comportamento previsto è che il tunnel Zscaler primario diventi attivo e il traffico continui a utilizzare il tunnel secondario per altri 30 minuti prima che il traffico venga reindirizzato al tunnel primario. Questo garantisce che il tunnel primario sia stabile e diminuisce le probabilità che diventi di nuovo inattivo forzando un altro failover del traffico. Quando si verifica questo problema, il traffico viene reindirizzato al tunnel primario entro meno di 30 minuti.
Problema 91164 risolto: È possibile che un hub Edge in cui è configurata l'alta disponibilità non inoltri il traffico di backhaul Internet dopo un failover di HA.

L'Edge di standby non imposta la route di destinazione per i flussi di backhaul Internet quando il flusso di backhaul è configurato per essere instradato tramite una route statica utilizzando un'interfaccia instradata in cui l'overlay WAN è disattivato.
Problema 92421 risolto: Quando nella stessa interfaccia dell'Edge sono configurati overlay pubblico e overlay privato con tag VLAN personalizzati diversi, è possibile che il traffico instradato underlay venga eliminato.

Quando un overlay pubblico e un overlay privato sono configurati nella stessa interfaccia con tag VLAN personalizzati diversi, l'Edge può acquisire le voci ARP con tag VLAN errati causando l'eliminazione del traffico.
Problema 96334 risolto: In un VMware SASE Orchestrator in cui l'indirizzo IP viene modificato di frequente, i VMware SD-WAN Edge possono perdere il contatto con Orchestrator ed essere segnalati come offline.

In questo scenario in cui l'indirizzo IP di Orchestrator viene modificato di frequente, gli Edge rispondono a ogni modifica dell'indirizzo IP di Orchestrator modificando l'origine del traffico di gestione da un'interfaccia di loopback all'indirizzo IP della porta GE1, anche quando Orchestrator è configurato per utilizzare esclusivamente l'interfaccia di loopback come origine. Gli Edge perdono quindi il contatto con Orchestrator e anche se non influisce sul traffico del cliente, questo problema impedisce che il monitoraggio e gli aggiornamenti della configurazione funzionino come previsto.
Problema 99162 risolto: Se in un VMware SD-WAN Edge si verificano frequenti flap del tunnel, è possibile che si verifichi un aumento del consumo di memoria e che l'Edge venga riavviato in modo difensivo per ripristinare la memoria.

La memoria dell'Edge interessata è l'oggetto vc_edge_route, che il servizio Edge non cancella dopo che ogni istanza di un tunnel viene eliminata e quindi ricreata. Come per qualsiasi perdita di memoria, se questa perdita della memoria dell'Edge è sufficiente, l'Edge attiverà un riavvio del servizio per cancellare la memoria e questo può interrompere il traffico dell'utente per 10-15 secondi.
Problema 104776 risolto: Per un cliente che configura un'interfaccia di VMware SD-WAN Edge per PPPoE, quando le impostazioni dell'overlay WAN per tale interfaccia includono l'impostazione 802.1P, l'Edge include i bit PRI 802.1P nel traffico in uscita.

L'Edge non include l'opzione configurabile per netifd per impostare le "mappature delle priorità EGRESS" per le interfacce PPPoE e non contrassegna quindi tali pacchetti con PRI.
Problema 104786 risolto: Nell'azienda di un cliente distribuita utilizzando una topologia di Hub o Cluster Interconnect, il ribilanciamento automatico dei tunnel tra due cluster interconnessi non funziona.

Il ribilanciamento dei cluster interconnessi non si verifica se il punteggio del cluster o il flap di BGP è in aumento. Possono quindi verificarsi problemi di traffico a causa dello squilibrio nell'utilizzo del tunnel.
Problema 105034 risolto: Il polling SNMP per CPU e memoria di un VMware SD-WAN Edge ottiene sempre zero come valore di risposta.

Il polling SNMP per la CPU e la memoria come parte delle statistiche di integrità dell'Edge ottiene sempre il valore di risposta zero. Il problema è stato risolto rinominando l'opzione Utilizzo CPU (CPU utilization) con Carico CPU medio (CPU load average) e popolando l'utilizzo della memoria come risposta.
Problema 106160 risolto: Con un server DNS configurato per l'Edge e un gateway dell'hop successivo definito per un'interfaccia dell'Edge per cui i client interrogano il server DNS, non è disponibile alcuna risposta.

Il pacchetto di richieste di DNS viene ricevuto dal server DNS dell'Edge come previsto. Tuttavia, il pacchetto di risposte esegue una ricerca nella tabella di route in base al monitoraggio della connessione di IPtables, trova l'indirizzo IP del gateway dell'hop successivo e risolve l'indirizzo MAC. Il pacchetto di risposte di DNS utilizzerà quindi l'indirizzo MAC del gateway, non quello del mittente.
Problema 106992 risolto: Nell'azienda di un cliente distribuita utilizzando una topologia di Hub o Cluster Interconnect, il cliente può notare che i cluster Hub non possono creare overlay tra di loro.

È possibile che i membri dei cluster Hub con interconnessione abilitata non siano in grado di stabilire overlay perché la mappatura dei cluster Hub è obsoleta. L'unico modo per risolvere questo problema consiste nel disattivare e quindi riattivare l'interconnessione nei cluster Hub.
Problema 107550 risolto: Nelle aziende dei clienti in cui vengono distribuite destinazioni non SD-WAN tramite gateway, un utente può notare l'eliminazione di alcuni pacchetti crittografati IPSsec nel percorso.

L'implementazione corrente utilizza un valore TTL (Time-to-Live) dell'intestazione IP interna e questo non corrisponde al requisito della RFC. Di conseguenza, è necessario creare il valore TTL e se l'autore del pacchetto utilizza un valore TTL basso, è possibile che questo pacchetto non raggiunga la sua destinazione.
Problema 108111 risolto: Quando un utente operatore o partner tenta di eseguire il debug di un VMware SD-WAN Gateway utilizzando il comando debug.py --bgp_agg_dump, il comando non dispone di una stringa della guida corretta.

La stringa della guida spiega quali argomenti vengono utilizzati (ad esempio: [[v4 | v6 | all] ...]]) e quando si verifica questo problema tale stringa manca per il comando di debug.
Problema 109830 risolto: È possibile che le combinazioni di determinati client e server VPN PPTP (Point-to-Point Tunneling Protocol) non siano in grado di ristabilire immediatamente una connessione dopo che è stata interrotta quando si utilizza la NAT 1:1 con il server PPTP dietro l'Edge e il client in Internet.

È stato confermato che questo problema si verifica con Windows Server 2016 e Windows client 10, ma può verificarsi anche con altre versioni. Il problema è causato dal fatto che il server riutilizza lo stesso call-id PPTP per la nuova connessione mentre il client utilizza un nuovo call-id. Quando il call-id del server viene riutilizzato per la nuova connessione, il firewall non lo identifica come tale.

Senza una correzione per questo problema, un utente può eliminare la connessione PPTP obsoleta dalla tabella NAT per ripristinare la connettività.
Problema 112115 risolto: In un VMware SD-WAN Edge con un carico di CPU elevato è possibile che si verifichi un errore del servizio piano dati e che l'Edge venga riavviato per il ripristino.

In condizioni di CPU elevata, è possibile che si verifichino più errori del servizio attivati da un monitor mutex perché un thread con priorità più bassa acquisisce il blocco del ring di debug. La soluzione di questo problema consiste in un miglioramento del piano dati che rende tale thread senza blocco e senza attesa.
Problema 112509 risolto: In un VMware SD-WAN Edge configurato per l'utilizzo di una VNF può verificarsi un errore del servizio piano dati e un riavvio per il ripristino.

Il problema è riconducibile alla gestione di SKB (buffer di rete). In alcuni casi, il controllo dell'allocazione di SKB non è presente e questo può causare un errore del servizio Edge.
Problema 113877 risolto: Per i clienti che configurano la LAN BGP/GRE e che utilizzano TGW GRE, si verifica il flap di BGP e l'interruzione del traffico nel tunnel secondario TGW in tutti i segmenti quando la configurazione di BGP per TGW GRE viene modificata nel segmento globale.

Quando un cliente modifica una configurazione BGP di TGW GRE nel segmento globale, si verifica il flap del tunnel secondario nel segmento globale e negli altri segmenti che causa la reimpostazione e la riconvergenza della connessione BGP e l'interruzione del traffico. La connessione BGP verrà nuovamente stabilita e il traffico verrà ripristinato.
Problema 114529 risolto: Nei modelli di Edge LTE (510-LTE, 610-LTE), quando un utente non imposta le configurazioni CELL in Orchestrator anche dopo l'attivazione di CELL1/CELL2 e non sono selezionati gestori e configurazioni predefiniti, l'Edge genera un errore di configurazione.

Se un utente attiva l'interfaccia CELL1/CELL2 di un Edge LTE dalla pagina Configura (Configure) > Edge > Dispositivo (Device) > Interfaccia (Interface) e non seleziona alcun gestore o rete nell'elenco, questo campo passa all'Edge come vuoto e quando viene letto, l'Edge genera un errore che indica che non proviene da uno degli SPN disponibili. Questo errore è visibile nella sezione Eventi (Events) in Orchestrator.
Problema 114659 risolto: Il comando di debug tcpdump.sh non funziona per un VMware SD-WAN Gateway.

Il processo di sicurezza AppArmor del gateway blocca l'accesso ai terminali /dev/pts/*. Il processo vctcpdump viene quindi terminato e tcpdump.sh non acquisisce alcuna informazione in stdout.

In un gateway senza una correzione per questo problema, la soluzione consiste nell'eseguire il comando tcpdump.sh-w per salvare l'output in un file, perché questo comando comunque funziona.
Problema 114854 risolto: Se un utente, che risolve un problema relativo a un VMware SD-WAN Edge modello 610 con DPDK attivato, esegue un'acquisizione di pacchetti da Orchestrator oppure utilizza tcpdump.sh o vctcpdump, nota che il tag VLAN non è presente per il traffico di ritorno.

Quando manca il tag VLAN nel traffico di ritorno, l'utente non può risolvere correttamente un problema di rete relativo a una versione qualsiasi di Edge 610.
Problema 114938 risolto: Quando si consulta Monitora (Monitor) > Edge > Destinazioni (Destinations) per un'azienda cliente, l'utente potrebbe notare un nome di dominio errato per una destinazione.

Questi nomi host non validi possono riempire completamente la cache DNS dell'Edge e possono portare a eventi di Numero massimo di DNS raggiunto (Max DNS reached) e i nomi host validi non possono essere aggiunti dopo questo evento. Il problema è causato dal motore Deep Packet Inspection (DPI) dell'Edge che aggiunge nomi di host non validi (ad esempio Indirizzo IP o Indirizzo IP:Porta) nella cache DNS dell'Edge.
Problema 114988 risolto: Il messaggio di ICMPv6 "Pacchetto troppo grande" (Packet Too Big) non viene ricevuto da o tramite un VMware SD-WAN Gateway.

Il percorso dati del gateway utilizza tutti i messaggi "Pacchetto troppo grande" (Packet Too Big) di ICMPv6 in locale. La correzione assicura che il gateway invii la destinazione appropriata.
Problema 115148 risolto: quando un cliente distribuisce un servizio di sicurezza cloud (CSS) con tunnel ridondanti (in altre parole, attivo e di standby) e il Controllo dello stato L7 (L7 Health Check) è attivato, se il tunnel CSS primario si disattiva e quindi torna attivo, è possibile che il tunnel CSS di standby rimanga attivo.

Se il tunnel di standby è attivo quando è attivato Controllo dello stato L7 (L7 Health Check) e questa funzionalità viene quindi disattivata prima che il tunnel CSS primario torni attivo, il tunnel di standby può rimanere in stato attivo per un periodo di tempo indeterminato. La causa del problema è che anche se il Controllo dello stato L7 (L7 Health Check) è disattivato, il gateway controllerà lo stato di L7 per il tunnel primario, che verrà letto come inattivo; di conseguenza, il Gateway determinerà che il tunnel primario è inattivo e manterrà attivo il tunnel di standby.

In un Edge senza una correzione per questo problema se un utente esegue Azioni remote > Riavvia servizio Edge (Remote Actions > Edge Service Restart), il problema per tale posizione viene risolto.
Problema 115225 risolto: Quando in un VMware SD-WAN Edge si verifica un numero notevole di flap del tunnel, è possibile che si verifichi un aumento dell'utilizzo della memoria a causa di una perdita di memoria.

Quando si esaminano i registri, si nota un aumento dell'oggetto della memoria vc_edge_route quando si verificano numerosi flap del tunnel a causa di perdite di memoria correlate alla route dell'Edge.
Problema 115262 risolto: Se l'azienda di un cliente utilizza BGP per il routing, è possibile che l'adiacenza di BGP con un indirizzo IP secondario non venga attivata in un VMware SD-WAN Edge.

Quando un utente configura innanzitutto il router adiacente BGP e quindi configura l'indirizzo IP secondario corrispondente in un'interfaccia VLAN, la sessione di BGP non viene attivata perché l'interfaccia di BGP non viene aggiornata con la rimozione o l'aggiunta dell'indirizzo IP secondario in un'interfaccia VLAN.
Problema 115604 risolto: è possibile che in VMware SD-WAN Edge o Gateway si verifichi un errore del servizio piano dati e che venga generato un core con un'asserzione nella registrazione.

Quando un Edge o un Gateway elabora un pacchetto danneggiato, il software può raggiungere un'asserzione in cui la lunghezza effettiva del pacchetto dell'utente è superiore al buffer del pacchetto interno. È previsto che il gateway elimini questo tipo di pacchetto e ne impedisca l'invio all'Edge, ma invece lo elabora, e questo determina un errore e riavvio del servizio.
Problema 115869 risolto: I tunnel vengono ristabiliti in un VMware SD-WAN Gateway durante il processo di aggiornamento.

In un ambiente scalato in cui sono presenti migliaia di tunnel e peer che si connettono a un gateway, quando il gateway viene aggiornato, il traffico passa al gateway secondario per impostazione predefinita per fare in modo che il tempo di inattività sia breve e il flusso del traffico venga ripreso rapidamente. Durante l'esecuzione dello script di aggiornamento nel gateway in fase di aggiornamento (dalla versione 4.5.1 alla versione 5.2.0, dalla versione 5.0.1 alla versione 5.2.0 o dalla versione 5.1.0 alla versione 5.2.0), i tunnel iniziano a tornare attivi in tale gateway e il traffico passa nuovamente dal gateway secondario al gateway in fase di aggiornamento. Quando lo script termina, il gateway richiede un riavvio e ancora una volta il traffico passa a un gateway secondario. Questo può causare interruzioni critiche del traffico del cliente di tipo Multipath che utilizza il gateway.

In un gateway senza una correzione per questo problema, la soluzione consiste nello spostare vc_proc_mon restart dallo script successivo all'installazione a dopo il completamento dell'aggiornamento.
Problema 115904 risolto: Quando un utente attiva un bundle di diagnostica per un VMware SD-WAN Edge utilizzando VMware SASE Orchestrator, è possibile che nell'Edge si verifichi un errore del servizio piano dati, che venga generato un core e che venga eseguito un riavvio per il ripristino.

Un utente può generare un bundle di diagnostica dell'Edge nella pagina SD-WAN > Diagnostica (Diagnostics) > Bundle di diagnostica (Diagnostic Bundle). Quando viene eseguita questa azione, è possibile che si verifichi una race condition tra dns_name_cache (aggiunta e/o eliminazione) e la cache dei nomi DNS che fa sì che il servizio Edge tenti di accedere a un elemento in uso o eliminato. Questo causa un errore del servizio con il motivo SIGSEGV o SIGBUS.
Problema 116049 risolto: Lo stato della VPN di un link WAN configurato come backup può diventare INATTIVO (DEAD) anziché STANDBY come previsto.

L'impatto per il cliente è minimo perché la funzionalità del link WAN di backup (il link che diventa ATTIVO (ACTIVE) quando gli altri percorsi diventano inattivi) rimane inalterata. Tuttavia, lo stato del link WAN visualizzato come INATTIVO (DEAD) nell'interfaccia utente può causare confusione per il cliente. Quando si verifica questo problema, il cliente non può infatti verificare se il link WAN è davvero inattivo tramite la pagina Edge > Monitora (Monitor).

Questo problema può verificarsi quando l'azienda è connessa a un gateway partner e l'indirizzo IP di handoff BGP configurato non è l'indirizzo IP di alcuna interfaccia Edge in tale segmento. In questo scenario, è possibile che i messaggi di controllo del link di backup dell'Edge vengano eliminati. Di conseguenza, un link WAN configurato come backup per gli Edge può essere contrassegnato come INATTIVO (DEAD) anziché STANDBY anche se il link è attivo.
Problema 116059 risolto: Nel sito aziendale di un cliente distribuito con una topologia ad alta disponibilità in cui vengono utilizzate VNF, la connettività alla VNF di un Edge di standby non riesce dal VNF Manager presente nella VLAN di gestione della VNF.

Quando un VNF Manager viene distribuito nella VLAN di gestione della VNF, è possibile che venga acquisita una voce di indirizzo MAC errata nel database di inoltro del bridge di gestione della VNF di standby e questa voce persiste anche dopo che le porte del bridge di standby sono state impostate sullo stato disabilitato. Di conseguenza, la connettività della VNF dell'Edge di standby non riesce da VNF Manager.
Problema 116199 risolto: Nell'azienda di un cliente in cui sono configurati Hub e Cluster Interconnect, quando il tunnel tra un Edge spoke e un hub o un cluster diventa inattivo, è possibile che le route non vengano revocate dagli Edge spoke remoti.

Il problema può influire sul traffico del cliente che utilizza queste route obsolete e può essere risolto solo temporaneamente avviando nuovamente le route.
Problema 116257 risolto: In un VMware SD-WAN Edge connesso tramite un gateway partner in cui è configurato un handoff NAT per un server remoto, è possibile che il traffico di ritorno verso l'Edge venga eliminato da tale server.

Se il traffico non viene inizialmente crittografato dall'Edge al server remoto e quindi viene aggiornato con un flag crittografato, dopo l'aggiornamento della route, il traffico inverso viene eliminato nell'Edge a causa di un errore di ricerca della route.

Il problema può essere risolto temporaneamente eliminando i flussi nell'Edge interessato.
Problema 116368 risolto: I registri di routing in un VMware SD-WAN Gateway possono raggiungere la capacità massima e non raccogliere voci aggiuntive.

Questo problema è causato dal fatto che il software di routing del gateway non dispone della configurazione di rotazione dei registri il cui scopo è ruotare i registri di routing prima che raggiungano la capacità massima per consentire l'aggiunta di nuove voci di registro. Senza questa configurazione, i registri di routing non vengono ruotati ed è possibile che in Operatori (Operators) e Partner (Partners) manchino voci di registro critiche per un gateway.
Problema 116428 risolto: Nella distribuzione di un cliente in cui sono configurati più segmenti e ogni segmento non globale ha un nome personalizzato, quando si esegue Diagnostica remota (Remote Diagnostics) > Test ping (Ping Test), nel menu a discesa per scegliere un'interfaccia non viene visualizzato il nome personalizzato per ciascun segmento.

Anziché il nome personalizzato per ogni segmento non globale, l'utente vede un nome generico con un numero: Segmento 1, Segmento 2 e così via. Questo problema si verifica perché l'Edge esegue l'hardcoding del nome del segmento per ogni segmento non globale.
Problema 116827 risolto: È possibile che in un VMware SD-WAN Edge si verifichi un errore del servizio piano dati e che venga eseguito un riavvio per il ripristino.

È possibile che nell'Edge si verifichi questo problema a causa di una race condition durante l'avvio dell'Edge che causa la mancata riuscita del servizio Edge perché i dati non sono inizializzati.
Problema 116894 risolto: NAT 1:1 non funziona correttamente quando l'indirizzo IP esterno e l'indirizzo IP di origine si trovano nella stessa subnet.

Con questa configurazione NAT 1:1, l'Edge modifica la porta di origine durante la conversione di NAT e il risultato è l'eliminazione del traffico che soddisfa questa regola per il traffico in entrata.
Problema 116916 risolto: I percorsi dell'Edge verso i gateway e gli Edge peer possono diventare inattivi dopo l'aggiunta o l'eliminazione di una route predefinita del kernel IPv6 verso qualsiasi destinazione tramite un'interfaccia dell'Edge utilizzata dal processo di gestione dell'Edge.

I percorsi dell'Edge possono diventare inattivi dopo l'aggiunta o l'eliminazione di una route predefinita del kernel IPv6 che coinvolge qualsiasi interfaccia utilizzata dal processo di gestione dell'Edge per creare percorsi con altri nodi (ovvero, Edge o gateway).

Se si verifica questo problema senza una correzione, l'utente deve rimuovere la route IPv6 e riavviare il servizio.
Problema 116925 risolto: Il traffico FTP può essere classificato erroneamente come TCP generico dal motore DPI (Deep Packet Inspection) di VMware SD-WAN Edge.

Quando si verifica, questo problema ha un impatto significativo per un cliente che utilizza un criterio di business o una regola del firewall che implica la corrispondenza del traffico FTP, perché la regola non funziona.

Il traffico dati FTP viene classificato come APP_TCP anziché come APP_FTP_DATA. Questo perché i flussi di controllo FTP vengono rimossi dal contesto del motore DPI una volta eseguita la classificazione. Affinché il traffico dati FTP venga classificato correttamente, il flusso deve persistere nel motore DPI.
Problema 117037 risolto: Per un cliente che utilizza una topologia Hub/Spoke in cui vengono utilizzati più link WAN per inviare e ricevere il traffico dall'Edge Spoke all'Edge Hub, è possibile che i clienti rilevino prestazioni inferiori a quelle previste per il traffico indirizzato da Criteri aziendali, poiché i link WAN non aggregano la larghezza di banda del link WAN.

SD-WAN utilizza un contatore per il conteggio del numero di pacchetti inseriti nel buffer in una coda di risequenziamento. Questo contatore viene gestito per ogni peer e utilizzato per assicurarsi che vengano bufferizzati solo pacchetti da 4K per peer. In alcune condizioni, questo contatore può diventare negativo. Prima della versione 4.2.x, quando questo contatore diventava negativo, il relativo contatore veniva immediatamente reimpostato su 0 dopo aver scaricato i pacchetti nella coda di risequenziamento. Tuttavia, a partire dalla versione 4.3.x, questo contatore viene aggiornato automaticamente per garantire che rimanga entro i limiti previsti.

Il risultato di questo cambiamento di comportamento può causare casi in cui il conteggio dei contatori non è corretto e la coda di risequenziamento può rimanere a un numero molto alto a cui SD-WAN reagisce scaricando ogni singolo pacchetto. Questa azione non solo impedisce l'aggregazione della larghezza di banda, ma può ridurre l'efficacia dei flussi che altrimenti sarebbero su un unico collegamento.

Sugli Edge che non dispongono di una soluzione alternativa per questo problema, la soluzione alternativa consiste nel configurare politiche aziendali che indirizzino il traffico corrispondente verso un singolo link obbligatorio.
Problema 117314 risolto: Quando esiste già un flusso ICMP tra una coppia di indirizzi IP di origine e di destinazione, una regola del firewall che utilizza un gruppo di oggetti/gruppo di servizi (tipo e codice) per filtrare i pacchetti ICMP potrebbe non funzionare.

Nell'ambito di una revisione della funzionalità del firewall, le modifiche introdotte per la memorizzazione nella cache del tipo e del codice ICMP sono state annullate e questo ha influito sulle regole del firewall che utilizzavano un gruppo di servizi con un tipo e un codice ICMP (ad esempio, reindirizzamento ICMP con tipo 5 e codice 0). Se un flusso è già presente tra un indirizzo IP di origine e uno di destinazione, il traffico ICMP che dovrebbe corrispondere alle regole di questo flusso non sarà rispettato e solo i primi pacchetti di una sessione corrisponderanno alle regole del Firewall. Il problema riguarda i flussi ICMP IPv4 o IPv6.

Lo svuotamento dei flussi per creare nuovi flussi ICMP risolverà temporaneamente il problema.
Problema 117320 risolto: Nel sito di un cliente in cui sono attivati il firewall stateful e syslog, i messaggi syslog per il traffico che soddisfa una regola NAT lato LAN non includono l'indirizzo IP di origine.

Un messaggio syslog completo per qualsiasi traffico deve includere l'indirizzo IP di origine, specialmente per il traffico sottoposto a NAT.
Problema 117831 risolto: Le regole predefinite del firewall di VMware SD-WAN Gateway impediscono all'agente Linux Azure di comunicare con l'infrastruttura di Azure dopo l'avvio del servizio SD-WAN.

Questo problema non influisce sulla funzionalità di SD-WAN, ma è possibile che nel portale di Azure manchino alcune metriche per la macchina virtuale del gateway.

L'agente Linux Azure richiede la comunicazione in uscita sulle porte 80/TCP e 32526/TCP con WireServer (168.63.129.16). Dopo l'avvio del servizio gateway, la porta 32526 è bloccata.
Problema 117838 risolto: È possibile che in un VMware SD-WAN Edge si verifichi un errore del servizio piano dati, venga generato un core e venga eseguito un riavvio per il ripristino.

Il problema può verificarsi quando l'Edge riceve un pacchetto ike con una versione non corrispondente a quella di ike_ds. Il problema si verifica quando il servizio Edge elabora pacchetti con versioni non corrispondenti ed esegue un blocco mutex per modificare il valore di un cookie in ike_ds, ma se le versioni non corrispondono, l'Edge attiva un'eliminazione dell'associazione di sicurezza (SA) che tenta nuovamente di eseguire il mutex nello stesso ike_ds. Il risultato è un deadlock dell'Edge e un errore del servizio con conseguente riavvio.
Problema 117943 risolto: in un VMware SD-WAN Edge con funzionalità Wi-Fi, la selezione automatica del canale per alcuni pesi può determinare da parte dell'Edge la scelta di canali che determinano prestazioni scarse del Wi-Fi o persino una mancata attivazione del Wi-Fi.

In alcuni paesi come la Gran Bretagna il Wi-Fi richiede molto tempo per attivarsi, ad esempio per la banda 5 GHz (o può persino non attivarsi). La selezione automatica del canale per la banda a 5 GHz può finire per selezionare canali non adeguati in alcuni paesi, come ad esempio canali a bassissima potenza o canali che richiedono un rilevamento radar (il che può rallentare o impedire l'avvio).

In un Edge senza una correzione per questo problema, quando si seleziona la banda a 5 GHz in un paese europeo, configurare esplicitamente il canale radio su 36, 40, 44 o 48 (invece di lasciarlo su "Auto").
Problema 118097 risolto: Quando un utente operatore o partner esegue il debug di un VMware SD-WAN Gateway può notare che il comando debug.py --path non restituisce alcun risultato.

Il problema è causato da una chiave non gestita quando è presente un tunnel temporaneo e interrompe il comando debug.py --path mentre il gateway elabora percorsi temporanei.
Problema 118348 risolto: Nel sito aziendale di un cliente distribuito con una topologia ad alta disponibilità avanzata, se un utente attiva DHCP nell'interfaccia secondaria di VMware SD-WAN Edge, è possibile che nell'Edge HA si verifichi un errore del servizio piano dati, che venga generato un core e che venga eseguito un riavvio per il ripristino.

Se questo problema si verifica nell'Edge attivo, viene attivato un failover di HA e viene promosso l'Edge di standby. Se il problema si verifica nell'Edge di standby, non si verifica alcun failover ma il traffico che utilizza i link WAN dell'Edge di standby viene brevemente interrotto.
Problema 118436 risolto: È possibile che il traffico DNS verso un server DNS underlay non funzioni.

Il problema può verificarsi quando l'interfaccia instradata di un VMware SD-WAN Edge è configurata senza un gateway e DHCPv6 con interfaccia IPv6 come indirizzo IP del server DNS ma senza una route predefinita IPv6 in un gateway partner. In questa configurazione, la risposta DNS dell'underlay viene eliminata dall'Edge.
Problema 118591 risolto: Nel sito aziendale di un cliente che utilizza una topologia ad alta disponibilità avanzata, è possibile che nell'Edge HA di standby si verifichino frequenti flap dell'interfaccia.

In una distribuzione ad alta disponibilità avanzata, quando viene inviato un numero elevato di flussi o quando è installato un numero elevato di route, lo stato dell'interfaccia dell'Edge di standby passa da ATTIVO (UP) a INATTIVO (DOWN) e quindi di nuovo ad ATTIVO (UP).
Problema 119010 risolto: Nei modelli 520 e 540 di VMware SD-WAN Edge, è possibile che l'Edge non inoltri il traffico da una VLAN che si trova nelle porte LAN 1-4 a una VLAN che si trova nelle porte LAN 5-8 e viceversa.

I modelli di Edge 520 e 540 hanno due schede NIC LAN, ciascuna con una serie di quattro porte per un totale di 8 porte LAN. Quando una LAN è configurata per una porta LAN della prima serie di porte e una VLAN diversa è configurata per una porta LAN della seconda serie di porte, l'Edge non gestisce correttamente questo traffico, che viene eliminato.
Problema 119033 risolto: Durante un avvio, è possibile che nel VMware SD-WAN Gateway si verifichi un errore del servizio piano dati e che sia necessario un riavvio per il ripristino.

I dettagli delle allocazioni delle porte NAT vengono archiviati in un segmento di memoria condivisa esterno al processo del servizio gateway (gestito dal processo NAD) per impostazione predefinita. Questa operazione viene eseguita per garantire che il servizio gateway possa reinizializzare rapidamente la tabella NAT al riavvio del processo. Tuttavia, è possibile che questo stato persistente venga danneggiato, causando un errore del servizio gateway subito dopo il riavvio.

In un gateway senza una correzione per questo problema, l'eliminazione della tabella NAT o il riavvio del sistema operativo può impedire che si verifichi.
Problema 119466 risolto: Nel sito aziendale di un cliente distribuito con una topologia ad alta disponibilità, è possibile che il traffico che soddisfa una regola NAT Molti:1 non riesca dopo un failover di HA.

Quando si verifica questo problema, le voci NAT lato LAN non vengono sincronizzate con l'Edge di standby. Poiché la regola NAT Molti:1 coinvolge anche PAT (Port Address Translation), le voci NAT lato LAN non possono essere create in base alla configurazione e devono essere sincronizzate per evitare l'interruzione del traffico in un failover di HA.
Problema 119544 risolto: Quando la risposta echo ICMP è disattivata nell'interfaccia di loopback di un VMware SD-WAN Edge, il controllo dell'integrità L7 non riesce e l'Edge attiva la disinstallazione di un tunnel CSS in cui è configurato il controllo dell'integrità L7.

Inoltre, quando il traffico di gestione diventa diretto, viene persa anche la comunicazione tra Edge e Orchestrator.

Quando l'Edge tenta di inviare una richiesta di controllo dell'integrità L7 (pacchetto SYN HTTP), questa raggiunge l'interfaccia di loopback e poiché l'opzione Risposta echo ICMP (ICMP Echo Response) è disattivata, i pacchetti HTTP vengono eliminati. Quando il controllo dell'integrità L7 non ottiene un ACK per il pacchetto SYN inviato, il controllo dell'integrità L7 non riesce e si verifica la disinstallazione del tunnel CSS.

Analogamente, quando l'Edge tenta di inviare pacchetti HTTPS verso Orchestrator, raggiunge l'interfaccia di loopback e poiché l'opzione Risposta echo ICMP (ICMP Echo Response) è disattivata, i pacchetti ACK HTTPS vengono eliminati.
Problema 119811 risolto: Un cliente può notare che nel proprio elenco Eventi (Events) sono presenti più eventi dell'Edge MGD_WEBSOCKET_INIT e MGD_WEBSOCKET_CLOSE al giorno.

Nell'elenco Eventi (Events) di Orchestrator possono essere visualizzati più eventi MGD_WEBSOCKET_INIT e MGD_WEBSOCKET_CLOSE senza alcuna azione del cliente.

Questi messaggi di evento sono falsi e possono essere ignorati perché il loro livello di gravità è "Informazioni" (Info).
Problema 120940 risolto: Se in BGP sono presenti più route per lo stesso prefisso da router adiacenti diversi nello stesso VRF interno (come un VRF creato per le destinazioni non SD-WAN tramite sessioni BGP del gateway), lo stesso IP del router adiacente viene aggiornato per tutte le route.

Il problema può verificarsi nell'SD-WAN Gateway se si utilizzano i comandi debug.py --routes e debug.py --bgp_view outputs ed è causato dal fatto che il processo di routing di un gateway non aggiorna correttamente l'IP del router adiacente (origine).
Problema 121024 risolto: Il traffico del servizio di accesso remoto (RAS) non riesce quando in un VMware SD-WAN Edge è configurato un criterio di business corrispondente al traffico Internet.

Quando in un Edge è configurato un criterio di business corrispondente al traffico Internet e l'azione consiste nel reindirizzare il traffico direttamente, per qualsiasi traffico del servizio di accesso remoto che raggiunge questo Edge, il traffico di ritorno soddisfa questo criterio di business e viene eliminato nell'Edge.

L'unica soluzione consiste nel configurare un criterio di business più specifico corrispondente alle subnet di RAS e impostare l'azione per l'invio Multipath (tramite il gateway).
Problema 121338 risolto: In un sito in cui un link WAN è configurato come hot standby, VMware SD-WAN Edge include tale link come parte della larghezza di banda disponibile.

Un link WAN hot standby è inattivo per impostazione predefinita e non deve essere incluso nella larghezza di banda disponibile di un Edge. Poiché l'hot standby viene incluso, l'Edge calcola la larghezza di banda totale disponibile in modo non corretto e questo può causare la perdita di pacchetti.
Problema 121513 risolto: Nell'azienda di un cliente che utilizza un gateway partner in cui è attivata l'opzione "Route BGP sicure" (Secure BGP Routes), gli utenti client possono notare problemi relativi alla qualità del traffico.

Quando il traffico viene avviato con un indirizzo IP del peer BGP come origine dietro un gateway partner in cui è configurata l'opzione Route BGP sicure (Secure BGP Routes), è possibile che il traffico venga eliminato negli Edge. Questo problema si verifica perché quando il traffico viene avviato da un endpoint BGP come origine, crea un flusso non protetto nel gateway perché la route di origine è di tipo BGP-Peer per il quale non viene eseguita la gestione dell'impostazione sicura. Tuttavia, se la ricerca della route di origine negli Edge restituisce una route sicura, si verifica una mancata corrispondenza dell'impostazione sicura del traffico in entrata e della ricerca della route. Questo causa un errore di ricerca della route di origine negli Edge.
Problema 121606 risolto: I clienti connessi a un gateway partner possono notare che i tunnel VPN IPSec sono inattivi nel gateway partner.

Il processo IPSec dei gateway supporta al massimo 64 indirizzi IP in un'interfaccia. Quando si verifica questo problema in un gateway partner, gli indirizzi IP di handoff vengono aggiunti incondizionatamente all'interfaccia del processo IPSec del gateway. Se il numero di indirizzi IP di handoff supera il limite di 64, gli indirizzi IP precedenti vengono sovrascritti nel processo IPSec e i tunnel che utilizzano tali indirizzi IP sovrascritti diventano inattivi.

Quando questo problema si verifica in un gateway senza una correzione, non esiste una soluzione reale supponendo che tutti gli indirizzi IP di handoff del gateway partner vengano configurati come previsto. In caso contrario, la rimozione degli IP di handoff del gateway partner non necessari può essere utile se riduce gli IP nel processo IPSec del gateway a un numero inferiore a 64. Dopo questa modifica della configurazione, sarà necessario riavviare il servizio gateway.

Oltre a questo, la vera alternativa consiste nello spostare in un secondo gateway partner un numero di tunnel IPSec sufficiente a ridurre il numero totale di handoff al di sotto di 64 nel gateway partner interessato.
Problema 121815 risolto: Nel sito aziendale di un cliente distribuito con una topologia ad alta disponibilità e che utilizza VNF, quando un Edge di standby ha un'interfaccia LAN attiva e una VNF inattiva e l'Edge attivo ha un'interfaccia LAN inattiva e una VNF attiva, non si verifica alcun failover dell'alta disponibilità anche se nell'Edge di standby è presente una porta LAN attiva.

Questo problema deriva dal fatto che l'Edge include lo stato della VNF nel conteggio di LAN nell'heartbeat HA. Una VNF attiva viene conteggiata come LAN aggiuntiva e genera i sintomi elencati.

È possibile risolvere il problema separando gli stati delle VNF dal numero di LAN in modo che le decisioni di failover di HA vengano prese correttamente. Con questa modifica, l'Edge assegna una priorità più alta a una VNF che ha la connettività WAN e LAN di base attiva. In altre parole, se l'Edge attivo ha una VNF inattiva e l'Edge di standby ha una VNF attiva, l'Edge di standby viene promosso ad attivo se ha almeno 1 WAN e 1 LAN e questo indipendentemente dal numero di LAN/WAN nell'Edge attivo.
Problema 121998 risolto: Per un cliente che utilizza il firewall di tipo stateful in una topologia Hub/Spoke, il traffico che corrisponde a una regola del firewall configurata per il traffico da Spoke ad Hub in cui la regola include una VLAN di origine può essere eliminato.

In caso di modifica della classificazione delle applicazioni, della tabella dei criteri di business o della versione della tabella dei criteri del firewall, SD-WAN esegue una ricerca del firewall per i flussi nel suo prossimo pacchetto. A causa di un problema di temporizzazione, il pacchetto potrebbe essere uno di quelli provenienti dal lato del traffico di gestione (VCMP). Di conseguenza, durante la creazione di una chiave di ricerca dei criteri del firewall, SD-WAN scambia la VLAN dell'Edge Spoke con la VLAN dell'Edge Hub. La regola non viene quindi soddisfatta e il traffico viene eliminato.

Per un Edge senza una correzione per questo problema, un cliente può modificare l'origine da VLAN Edge (Edge VLAN) a "Qualsiasi" (Any).
Problema 122029 risolto: Un servizio di sicurezza cloud (in genere Zscaler) distribuito con l'automazione GRE in cui VMware SD-WAN Edge utilizza una versione 5.2.x non funziona.

Questo problema è causato dal fatto che l'indirizzo IP locale e gli indirizzi IP pubblici non vengono inviati e queste informazioni sono necessarie per consentire a Orchestrator di inviare uno stato di configurazione del tunnel inattivo all'Edge. Affinché Orchestrator invii la configurazione GRE automatizzata, lo stato del tunnel deve essere In sospeso (Pending).

Questo problema riguarda solo gli Edge 5.2.x e un utente può risolverlo solo effettuando il downgrade dell'Edge a una versione 5.1.x o precedente e attivando il tunnel, quindi eseguendo l'aggiornamento alla versione 5.2 o successiva.
Problema 122528 risolto: Per un'azienda cliente che utilizza route statiche WAN con probe ICMP configurate, è possibile che le probe ICMP smettano di funzionare su più VMware SD-WAN Edge contemporaneamente, con conseguente interruzione di tutto il traffico che utilizza tali route.

Ogni Edge ha un contatore di sequenze di probe ICMP con un numero massimo di 65535 iterazioni. Quando questo contatore scade dopo 65535 iterazioni, le sonde falliscono.

Su un Edge senza una soluzione a questo problema, la soluzione alternativa consiste nel rimuovere la probe ICMP, riavviare il servizio Edge e quindi ripristinare la sonda.
Problema 123144 risolto: Nella pagina dell'interfaccia utente di Orchestrator Monitora (Monitor) > Edge > Destinazioni (Destinations) sono visualizzati nomi di dominio di destinazione non validi.

L'Edge invia nomi di destinazione non validi come IP:porta che vengono visualizzati nell'interfaccia utente di Orchestrator a causa della mancata convalida dei nomi host DNS.
Problema 123237 risolto: In un VMware SD-WAN Edge che esegue la versione 5.2.x e in cui le interfacce sono configurate solo con IPv6, la pagina Diagnostica (Diagnostics) > Diagnostica remota (Remote Diagnostics) non viene caricata.

Quando le interfacce dell'Edge solo IPv6 sono configurate con le impostazioni IPv4 disattivate, viene generata un'eccezione nello script di una chiave che causa il mancato caricamento della pagina Diagnostica (Diagnostics) > Diagnostica remota (Remote Diagnostics).

La soluzione consiste nell'attivare le impostazioni IPv4 con una configurazione fittizia.
Problema 123956 risolto: Un utente non può accedere all'interfaccia utente locale in un VMware SD-WAN Edge che utilizza una versione 5.2.x.

La pagina del browser non viene caricata e si verifica un errore 404. Il problema è il risultato delle eccezioni generate negli script della diagnostica remota e dell'interfaccia utente locale.
Problema 124106 risolto: Quando una NAT lato LAN è configurata per le conversioni Molti:1 che utilizzano PAT (Port Address Translation), il traffico avviato dalla direzione opposta consente l'accesso imprevisto agli indirizzi fissi in base alla maschera esterna e all'indirizzo IP originale.

Le regole NAT lato LAN consentono di avviare le connessioni in entrambe le direzioni per le regole Molti:1 senza un modo chiaro per impedire il traffico nella direzione 1:Molti. Le conversioni 1:Molti sono ora bloccate e gli utenti devono creare regole NAT 1:1 esplicite per abilitare il traffico.

Questo problema è descritto dettagliatamente in Note importanti: Modifica del comportamento della NAT lato LAN.
Problema 124162 risolto: Quando un utente acquisisce un pacchetto nell'interfaccia di un VMware SD-WAN Edge, è possibile che il pacchetto sembri danneggiato.

Il pacchetto non è effettivamente danneggiato ma sembra danneggiato solo nel file PCAP. Questo problema è dovuto a un difetto nel modo in cui l'Edge scrive i pacchetti nell'interfaccia di acquisizione dei pacchetti. È possibile che i pacchetti contrassegnati con VLAN siano scritti in modo errato e vengano visualizzati come pacchetti danneggiati (tipo ether non valido) nel file PCAP.
Problema 124263 risolto: Un cliente può notare un utilizzo elevato della CPU in un VMware SD-WAN Edge durante la gestione del rilevamento del router adiacente IPv6 e dei pacchetti di incapsulamento L2.

La risoluzione dei problemi dell'Edge punta a api - vc_ip6_host_addr_to_network_addr che utilizza una CPU elevata.
Problema 124357 risolto: È possibile che in un VMware SD-WAN Edge si verifichi un errore del servizio piano dati e che l'Edge venga quindi riavviato.

Quando un criterio di business è configurato con backhaul Internet e un pacchetto di 3000 byte o più viene inviato dal lato LAN, il processo dell'Edge genera asserzioni per pacchetti di grandi dimensioni che attivano un errore del servizio.
Problema 125035 risolto: Quando un cliente distribuisce una VNF Fortinet 6.4.x, l'indirizzo IP di gestione dell'Edge non è accessibile.

Nella versione 6.4.x Fortinet ha apportato modifiche che impediscono a FortiLink e alla modalità trasparente di funzionare insieme. Poiché SD-WAN non utilizza FortiLink, la soluzione di questo problema consiste nel disabilitare FortiLink prima di impostare la modalità trasparente durante la distribuzione della VNF.
Problema 125421 risolto: Un cliente può notare che i link WAN in un VMware SD-WAN Edge vengono visualizzati in modo intermittente come inattivi e quindi come attivi nella pagina Monitoraggio ed eventi (Monitoring and Events) dell'interfaccia utente di VMware SASE Orchestrator. È possibile che l'Edge non risponda e non riesca a passare il traffico finché non viene riavviato manualmente oppure che nell'Edge si verifichi un errore del servizio piano dati e un riavvio.
Si tratta di un problema di perdita di memoria dell'Edge che si verifica quando il servizio piano dati dell'Edge non può aprire la memoria condivisa, causando PI obsolete. Questo, a sua volta, causa l'esaurimento del descrittore di file aperto che influisce inizialmente sui link WAN. Tuttavia, se questo problema è sufficientemente avanzato e comporta l'esaurimento della memoria dell'Edge, l'Edge può:
1. Non rispondere e non essere raggiungibile tramite Orchestrator. In questo caso è necessario un riavvio/ciclo di alimentazione in loco.
2. Attivare un errore del servizio Edge con un file core generato. L'Edge viene quindi riavviato per il ripristino.
Problema 125487 risolto: È possibile che il flusso del traffico da Edge a Edge venga interrotto da un problema di risoluzione di ARP.

Quando si verifica questo problema, l'Edge inoltra la richiesta ARP all'indirizzo IP dell'hop successivo utilizzando l'indirizzo IP dell'interfaccia primaria anziché l'indirizzo IP dell'interfaccia secondaria. Il problema si verifica durante la creazione del flusso quando una route non connessa viene utilizzata per raggiungere la destinazione e se per tale connettività viene utilizzata l'interfaccia secondaria dell'Edge, l'Edge non compila correttamente l'indirizzo IP di origine nel caso dell'interfaccia secondaria.
Problema 126304 risolto: Le regole NAT 1:1 la cui conversione dell'origine si sovrappone alle regole NAT Molti:1 o ad altre regole NAT 1:1 possono causare collisioni di porte o conversioni non riuscite.

Per correggere questo comportamento, quando la conversione dell'origine di una regola NAT 1:1 si sovrappone a un'altra regola, la PAT (Port Address Translation) viene attivata anche per la regola NAT 1:1.
Problema 126458 risolto: Nel sito di un cliente distribuito con una topologia ad alta disponibilità (HA) in cui gli Edge HA sono modelli di Edge 520 o 540, il cliente può notare più failover di HA che sono il risultato di uno stato Attivo/Attivo.

La condizione viene attivata negli Edge 520 o 540 configurati per l'alta disponibilità quando i flussi simultanei sono più di 300.000.

Negli Edge 520 o 540 configurati per l'alta disponibilità senza una correzione per questo problema, la soluzione consiste nell'aumentare il tempo di failover di HA da 700 ms a 7000 ms nella pagina Configura (Configure) > Edge > Dispositivo (Device) perché questo riduce la modifica di uno stato Attivo/Attivo.
Problema 127127 risolto: Un VMware SD-WAN Edge non acquisisce le route dagli Edge hub quando i VMware SD-WAN Gateway vengono aggiornati alla versione 5.1.x o successiva.

Quando un Edge è configurato con l'opzione Da filiale a filiale tramite hub (Branch to Branch via Hubs) con solo lo stesso Edge nell'elenco e il gateway esegue le versioni 5.1.x e successive, le route non vengono annunciate dal gateway all'Edge.

L'unica soluzione consiste nel rimuovere l'Edge dalla configurazione Da filiale a filiale tramite hub (Branch to Branch via Hubs).
Problema 127403 risolto: Nella pagina Test e risoluzione dei problemi (Test & Troubleshoot) > Diagnostica remota (Remote Diagnostics) dell'interfaccia utente di Orchestrator, quando si esegue la diagnostica remota Risoluzione dei problemi di OSPF - Elenca route ridistribuite OSPF (Troubleshoot OSPF - List OSPF Redistributed Routes) o Risoluzione dei problemi di BGP - Elenca route ridistribuite BGP (Troubleshoot BGP - List BGP Redistributed Routes), il test restituisce un errore senza dati.

Dopo aver eseguito una delle due diagnostiche, l'utente rileva un errore: Errore durante la lettura dei dati per il test (Error reading data for test).
Problema 128377 risolto: Nell'azienda di un cliente che utilizza BGP per il routing, il cliente può notare che il traffico dell'utente viene interrotto a causa di un errore di BGP.

È possibile che si verifichi l'arresto anomalo del processo BGP durante la pulizia a causa di un accesso alla memoria non valido di self_mac_hash.

Nell'ambito della pulizia di bgp_master, self_mac_hash è già stato pulito. Tuttavia, durante l'elaborazione del messaggio dopo che la pulizia è già stata eseguita, BGP accede all'hash eliminato causando l'errore.
Problema 128741 risolto: È possibile che in un VMware SD-WAN Gateway si verifichi un errore del servizio piano dati, venga generato un file core e venga eseguito un riavvio per il ripristino.

Quando un pacchetto di gestione valido arriva inaspettatamente nel tunnel IPSec di una destinazione non SD-WAN o in un'interfaccia GENEVE, è possibile che nel gateway si verifichi un errore durante l'elaborazione di tale pacchetto e che il processo del servizio gateway non riesca.

Problemi risolti di Orchestrator

Risolti nella versione R5401-20231115-GA di Orchestrator
Risolti nella versione R5400-20231020-GA di Orchestrator

Risolti nella versione R5401-20231115-GA di Orchestrator

La build R5401-20231115-GA di Orchestrator è stata rilasciata il 15/11/2023 ed è il primo rollup di Orchestrator per la versione 5.4.0.

Questa build di rollup di Orchestrator risolve i seguenti problemi critici presenti dalla build GA originale R5400-20231020-GA.

Problema 117138 risolto: Quando si utilizza Zscaler Automation per creare un servizio di sicurezza cloud (CSS) Zscaler, è possibile che non vengano creati tunnel IPSec da Edge a CSS Zscaler.

Orchestrator garantisce l'accodamento di una sola azione per Edge. Tuttavia, se un'azione è bloccata nello stato NOTIFICATA (NOTIFIED), tutte le azioni successive non vengono eseguite e i tunnel IPSec non vengono creati.

In un Orchestrator senza una correzione per questo problema, un utente operatore deve eliminare manualmente l'azione dell'Edge obsoleta dal database di Orchestrator.
Problema 123078 risolto: Quando si utilizza l'interfaccia utente di VMware SASE Orchestrator e si passa alla pagina Monitora (Monitor) > Edge > Panoramica (Overview), le colonne non sono allineate correttamente ed è difficile leggerle.

L'interfaccia utente non include alcuna informazione per la colonna Numero di serie dispositivo (Device Serial Number). Questo significa che sono presenti 11 colonne ma solo 10 intestazioni, per cui si verifica il problema di leggibilità.
Problema 123387 risolto: Un utente non può aggiungere una destinazione non SD-WAN (NSD) Zscaler tramite gateway con un indirizzo IP esistente.

La convalida di Orchestrator impedisce agli utenti di aggiungere un Zscaler con un indirizzo IP primario o secondario già utilizzato in un'altra NSD tramite gateway.
Problema 125309 risolto: Quando un utente disattiva IPv6 a livello di Edge in Configura (Configure) > Dispositivo (Device) > Impostazioni IPv6 (IPv6 Settings), è comunque possibile modificare, attivare e salvare l'opzione OSPF per IPv6.

Questo causa confusione per gli utenti del cliente che configurano queste impostazioni senza sapere che non dovrebbero perché la versione IPv6 di OSPF non è attiva.
Problema 125964 risolto: Se un cliente che distribuisce destinazioni non SD-WAN (NSD) tramite gateway passa alla pagina Configura (Configure) > Servizi di rete (Network Services) > NSD tramite gateway (NSD via Gateway) > IKEv2 generico (Generic IKEv2) e fa clic su Salva (Save) dopo aver aggiunto subnet del sito personalizzate, le modifiche della configurazione NSD non vengono salvate.

Questo problema è causato dai campi non validi Durata SA IKE (min) (IKE SA Lifetime (min)) e Durata SA IPSec (min) (IPsec SA Lifetime (min)) nella sezione Gateway VPN primario (Primary VPN Gateway).

Il cliente utilizza la vecchia interfaccia utente per completare l'attività.
Problema 126602 risolto: Un cliente non può aggiungere un pool di gateway al pool di gateway della configurazione partner esistente.

Il tentativo di eseguire questa operazione restituisce un errore se il pool di gateway nella configurazione partner include un pool gestito perché gli ID del pool gestito esistenti non vengono rimossi dall'interfaccia utente.
Problema 127727 risolto: Quando crea un nuovo servizio di sicurezza cloud (CSS), l'utente non può configurare l'opzione Preferenza nazionale (Domestic Preference).

Se un utente attiva la casella di controllo Preferenza nazionale (Domestic Preference) e salva la configurazione, Orchestrator verifica le credenziali e visualizza il messaggio "Modifiche salvate correttamente (Changes saved successfully)". Ma dopo il salvataggio, quando il profilo CSS viene aperto di nuovo, l'utente nota che la casella di controllo Preferenza nazionale (Domestic Preference) non è selezionata.
Problema 127774 risolto: In Configura (Configure) > Edge > Dispositivo (Device) > Connettività (Connectivity) > Interfacce di loopback (Loopback Interfaces), è possibile che un utente che tenta di configurare un'interfaccia di loopback non riesca.

Quando questo problema si verifica, se un utente configura un'interfaccia di loopback per un Edge e salva le modifiche, l'interfaccia utente non genera un errore, ma la configurazione non viene applicata e non viene visualizzata nella pagina dell'interfaccia utente.
Problema 127843 risolto: L'interfaccia utente non viene visualizzata correttamente quando è localizzata in italiano.

Questo problema riguarda gli utenti perché alcune schede di navigazione sono sovrapposte.
Problema 128017 risolto: Un cliente può notare che quando passa alla pagina Configura (Configure) > Edge > Dispositivo (Device), la pagina non viene mai caricata.

Quando si verifica questo problema, Orchestrator elimina erroneamente i riferimenti alla configurazione dell'Edge dal suo database. Una volta rimossi, questi riferimenti non possono essere ripristinati.

In un Orchestrator senza una correzione per questo problema, l'unica soluzione consiste nel forzare l'Edge a utilizzare tutte le configurazioni del profilo associato a tale Edge. Se l'Edge dispone di molte configurazioni di override dell'Edge personalizzate, ciò significa che è necessario creare un profilo specifico solo per tale Edge.
Problema 128277 risolto: Quando un utente nativo partner o aziendale (ovvero un utente che accede a Orchestrator con nome utente e password) tenta di accedere con una password scaduta, l'interfaccia utente entra in un loop e viene visualizzata una schermata vuota.

La schermata Password scaduta (Expired Password) viene continuamente aggiornata. Questo problema può essere risolto solo da un operatore o un partner con il ruolo corretto per reimpostare la password dell'utente.
Problema 127904 risolto: Quando un utente crea una route statica e aggiunge un probe ICMP a questa route, nell'Edge non viene installato il probe ICMP e si verifica un errore di analisi.

Questo problema si verifica perché i valori dell'IP dell'hop successivo e dell'IP di origine vengono inviati come null anziché come stringa vuota da Orchestrator all'Edge.
Problema 128279 risolto: Nella pagina Configura (Configure) > Controllo flusso overlay (Overlay Flow Control) > Elenco route (Routes List), è possibile visualizzare al massimo 256 route e non è possibile fare clic su una pagina di route aggiuntiva.

Il limite di 256 route e la mancanza di impaginazione influiscono sui clienti con aziende di grandi dimensioni in cui il numero di route è molto superiore al limite di 256.
Problema 128357 risolto: Nell'azienda di un cliente che utilizza OSPFv2 o OSPFv3 per il routing se si seleziona OE1 nell'elenco Route predefinita (Default Route), nell'elenco Annuncia (Advertise) viene visualizzata l'opzione non valida "Nessuna" (None).

Le opzioni valide per Annuncia (Advertise) sono "Sempre" (Always) e "Condizionale" (Conditional). Nessuna (None) non è un'opzione valida e non deve essere visualizzata nell'interfaccia utente.
Problema 128765 risolto: Nella pagina Filtri BGP (BGP Filters), è possibile che il pulsante Invia (Submit) rimanga inaccessibile quando l'utente cambia pagina.

Quando un utente modifica la tabella Filtri BGP (BGP Filters) e passa a un'altra pagina mentre lo stato di quella corrente non è valido, se torna alla pagina corrente e immette le informazioni corrette, i controlli non saranno validi.

In un Orchestrator senza una correzione per questo problema, l'utente deve rimanere nella pagina della tabella in cui il controllo non è valido. In alternativa, l'utente può rimuovere questa riga e aggiungerla di nuovo.
Problema 129061 risolto: Un cliente con l'opzione Handoff partner (Partner Hand off) attivata dalla schermata Cliente (Customer) > Impostazioni globali (Global Settings) > Configurazione cliente (Customer Configuration) > Configurazione aggiuntiva (Additional Configuration) > Pool di gateway (Gateway Pool), non può fare clic sulle caselle di controllo "Utilizza per tunnel privati (Use for Private Tunnels)" e "Annuncia indirizzo IP locale tramite BGP (Advertise Local IP Address via BGP)" nella sezione IPv6 di Interfaccia handoff (Hand Off Interface) del gateway.

Non può quindi disattivare il tunnel privato IPv6 per l'interfaccia di handoff.
Problema 129494 risolto: Nella pagina Cliente (Customer) > Impostazioni globali (Global Settings) > Configurazione cliente (Customer Configuration) > Configurazione servizio (Service Configuration) > SD-WAN, ogni volta che un utente modifica la configurazione del servizio, deve aggiungere il nome del dominio.

L'utente deve eseguire questa operazione anche se l'autenticazione Single Sign-On (SSO) o Edge Network Intelligence (ENI) non sono configurati per il cliente. Il nome del dominio non è obbligatorio se un cliente non utilizza ENI o SSO.
Problema 129584 risolto: Nella pagina Configura (Configure) > Edge (Edges) > Criterio di business (Business Policy), quando un utente modifica una regola del criterio di business esistente, l'interfaccia utente di Orchestrator non aggiorna il valore riconfigurato per il campo Destinazione (Destination) anche dopo il salvataggio delle modifiche.

Ad esempio, per una regola del criterio di business esistente con Destinazione (Destination) impostata su "Indirizzo IP (IP Address)" se l'utente modifica il valore di Destinazione (Destination) impostandolo su "Qualsiasi (Any)" e salva la modifica, le modifiche apportate al campo Destinazione (Destination) per la regola non vengono riportate nell'interfaccia utente. Nella regola l'utente continua a vedere il campo Destinazione (Destination) impostato su "Indirizzo IP (IP Address)" anziché su "Qualsiasi (Any)".
Problema 129756 risolto: Quando un operatore esegue lo schema di aggiornamento per un VMware SASE Orchestrator basato su cloud, è possibile che Orchestrator non sia in grado di connettersi al database remoto.

Questo problema non influisce sugli Orchestrator basati su macchine virtuali.
Problema 129765 risolto: Quando si modifica un'interfaccia instradata per un VMware SD-WAN Edge, nell'interfaccia utente di Orchestrator viene inserito un valore predefinito errato per dhcpServer.options.

Ad esempio, quando un utente modifica l'interfaccia instradata "GE3" e salva i dati di configurazione delle impostazioni del dispositivo, il valore del campo "options" in "dhcpServer" viene inviato come null anziché come array vuoto.
Problema 129894 risolto: È possibile che nella schermata Gestione gateway (Gateway Management) > Gateway (Gateways) > Panoramica (Overview) > Utilizzo cliente (Customer Usage) del portale dell'operatore dell'interfaccia utente di Orchestrator manchino alcuni dettagli del tunnel client dell'Edge.

Questo problema può verificarsi se il nome dell'Edge, il nome del pool di gateway e il tipo di gateway sono uguali.
Problema 130153 risolto: Per gli utenti aziendali con ruolo Supporto (Support), l'opzione Riavvia servizio (Restart Service) non è disponibile nel menu Monitora (Monitor) > Edge (Edges) > Seleziona Edge (Select Edge) > Collegamenti (Shortcuts) > Azioni remote (Remote Actions).

Gli utenti con ruolo Supporto (Support) non possono quindi eseguire un riavvio del servizio Edge dal menu Collegamenti (Shortcuts) nella pagina Monitora (Monitor) > Edge.
Problema 130877 risolto: Quando un utente aggiunge una route statica a un Edge utilizzando l'interfaccia utente di Orchestrator, gli utenti del client per tale Edge possono notare che il traffico non riesce per alcune route locali.

Nell'interfaccia utente in Configura (Configure) > Edge > Dispositivo (Device) > Routing e NAT (Routing & NAT) > Impostazioni route statiche (Static Route Settings) le opzioni dell'interfaccia per le Route locali (Local Routes) vengono impostate su N/D (N/A) e non possono essere modificate. Nei registri local_routes di tale Edge viene visualizzato il valore "reachable": "False" per le route locali coinvolte.

Questo problema può verificarsi quando l'IP dell'hop successivo di una route statica si trova nella stessa subnet della rete VLAN. In questo scenario, l'interfaccia utente di Orchestrator rimuove l'interfaccia della route statica e per tali route locali viene quindi visualizzata la raggiungibilità false.
Problema 131846 risolto: Nella pagina Impostazioni globali (Global Settings) > Configurazione cliente (Customer Configuration) > Handoff partner (Partner Hand off) > Interfaccia handoff (Hand Off Interface) dell'interfaccia utente di Orchestrator, quando un utente fa clic sul pulsante Aggiungi (Add) per aggiungere una route statica, l'interfaccia utente restituisce un messaggio di errore.
Quando l'utente fa clic sul pulsante Aggiungi (Add) nella sezione delle route statiche, nella tabella viene aggiunta una nuova riga vuota, ma viene visualizzato il messaggio di errore "Impossibile salvare le modifiche. Nella configurazione sono presenti uno o più errori" (Cannot save changes. There is one or more errors within your configuration). Il problema si verifica perché manca la convalida per la configurazione della route statica vuota nella sezione Handoff partner (Partner Handoff) della schermata Impostazioni globali (Global Settings) e riguarda solo le righe in cui non è configurata alcuna informazione.

Esistono due soluzioni per questo problema:
- Compilare tutti i campi obbligatori. In questo modo, il messaggio di errore ("Impossibile salvare le modifiche..." (Cannot save changes...)) verrà risolto automaticamente.
- Rimuovere dalla sezione tutte le righe vuote appena aggiunte. Dopo aver rimosso queste righe vuote, il messaggio di errore verrà risolto automaticamente.

Risolti nella versione R5400-20231020-GA di Orchestrator

Nella versione R5400-20231020-GA di Orchestrator, rilasciata il 23/10/2023, sono stati risolti i problemi seguenti presenti dalla versione R5302-20231011-GA di Orchestrator.

Nota:

La versione 5.4.0 contiene tutte le correzioni di Orchestrator elencate nelle Note di rilascio dalla versione 5.2.0 fino alla versione 5.2.0.3 (R5203-20230809-GA) e tutte le correzioni di Orchestrator elencate nelle Note di rilascio dalla versione 5.3.0 fino alla versione 5.3.0.2 (R5302-20231011-GA).

Problema 48230 risolto: Nella pagina Monitora (Monitor) > Edge (Edges), la ricerca degli Edge tramite "Modello" (Model) non è completamente accurata.

Quando un utente applica il filtro in base al numero di modello, Orchestrator restituisce Edge aggiuntivi.
Problema 48609 risolto: Nella pagina Monitora (Monitor) > Routing, un utente non può ordinare il nome del segmento in una tabella di route multicast.

Nella versione 5.4.0, l'API è stata migliorata in modo da accettare il nome del segmento come parametro di ordinamento e consente di ordinare il nome del segmento.
Problema 78581 risolto: Un utente può annunciare una VLAN quando le route connesse sono disattivate nell'interfaccia utente di Orchestrator.

Questa azione deve essere rifiutata da Orchestrator e deve essere generato un errore. Nella versione che include la correzione del problema, l'interfaccia utente di Orchestrator ascolta le route connesse e disattiva il flag di annuncio in base alle route connesse e viceversa.
Problema 82095 risolto: L'utente può configurare impostazioni del dispositivo non valide per le VLAN dell'Edge che causeranno problemi di connettività significativi per l'Edge.

Orchestrator non tenta di convalidare le configurazioni del dispositivo. In particolare la configurazione di una VLAN per una porta commutata con una tabella vuota. Alcune configurazioni possono includere un numero talmente elevato di errori che il processo di gestione dell'Edge non riesce.

In un Orchestrator senza una correzione per questo problema, il cliente deve rivedere tutte le impostazioni del dispositivo VLAN e assicurarsi che siano valide perché Orchestrator non le controlla.
Problema 91869 risolto: Quando un utente operatore passa a Gestisci partner (Manage Partners) e fa clic sul pulsante "Aggiungi profilo operatore" (Add Operator Profile), la descrizione del profilo operatore viene troncata quando il testo supera una determinata lunghezza.

Orchestrator non deve troncare la descrizione del profilo operatore indipendentemente dalla lunghezza del testo.
Problema 92766 risolto: Nella pagina Monitora (Monitor) > Routing, le informazioni sull'impaginazione non sono corrette.

Se un utente fa clic sul pulsante Avanti (Next), il passaggio alla pagina dell'interfaccia utente successiva non viene interrotto anche dopo che è stata raggiunta l'ultima pagina perché la logica del filtro non viene applicata correttamente e il numero di pagina visualizzato non è corretto.
Problema 102121 risolto: Quando la configurazione di Secure Access di un Edge viene aggiornata più volte senza che venga eseguito alcun aggiornamento della configurazione del firewall dell'Edge durante l'utilizzo dell'interfaccia utente di Orchestrator, è possibile che venga interrotto l'invio degli aggiornamenti della configurazione di Secure Access agli Edge.

Il problema si verifica più spesso durante i test in cui gli ingegneri forzano deliberatamente un numero elevato di aggiornamenti di Secure Access senza alcun aggiornamento del firewall. Tuttavia, in rari casi, può essere attivato da un cliente sul campo.

Se il problema si verifica in un Orchestrator senza una correzione, un utente può aggiornare manualmente la configurazione del firewall dell'Edge dall'interfaccia utente una sola volta. Dopo l'aggiornamento manuale del firewall, l'utente può ripetere la modifica della configurazione di Secure Access dell'Edge dall'interfaccia utente e Orchestrator eseguirà il push della modifica della configurazione di Secure Access dell'Edge dall'interfaccia utente agli Edge.
Problema 103828 risolto: Il filtro di ricerca dell'applicazione dell'editor Mappa applicazioni (Application Map) non è molto chiaro.

È quindi molto difficile controllare o modificare la configurazione per un'applicazione perché è necessario passare manualmente da una pagina di applicazione all'altra per trovare l'applicazione desiderata.
Problema 104395 risolto: Nella sezione "Link inattivi" (Links Down) della pagina Monitora (Monitor) > Rete (Network) > Panoramica (Overview) sono visualizzati solo i primi 10 siti con link inattivi. Quando un utente fa clic sul pulsante "Visualizza tutto" (View All), l'interfaccia utente di Orchestrator lo indirizza alla sezione Edge (Edges) in cui sono elencati tutti gli Edge indipendentemente dallo stato del link, anche se l'utente desidera visualizzare solo i siti con uno o più link inattivi.

Quando un utente fa clic sull'icona "Link inattivi" (Links down), l'elenco deve includere tutti i link inattivi, non solo 10, e non è possibile filtrare gli Edge in base allo stato del link o dell'Edge dopo aver fatto clic sul pulsante "Mostra tutto" (Show All).
Problema 108285 risolto: Quando si configura un profilo nell'interfaccia utente di Orchestrator, se un utente modifica un'interfaccia dell'Edge da commutata a instradata, Orchestrator aggiunge la nuova interfaccia instradata alla fine anziché inserirla nell'indice appropriato.

L'ordine errato delle interfacce instradate nella configurazione di un profilo causa problemi di convalida quando un utente aggiunge una route statica utilizzando tali riferimenti per l'interfaccia instradata.
Problema 108687 risolto: Un utente può configurare una destinazione non SD-WAN tramite gateway in modo da avere più gateway con lo stesso indirizzo IP.

Orchestrator deve rifiutare questa configurazione e generare un errore.
Problema 109125 risolto: Nella pagina Amministrazione (Administration) > Gestione utenti (User Management) dell'interfaccia utente di Orchestrator, un utente non può ordinare le chiavi SSH in base alla colonna Durata (Duration).

Questo limita la possibilità di un utente di trovare una determinata chiave SSH se tenta di individuarla in base alla sua durata.
Problema 109715 risolto: Un link WAN inattivo scompare dalla pagina Monitora (Monitor) > Panoramica della rete (Network Overview) dopo 24 ore anche se Limite inattivo link Edge (Edge Link Down Limit) è impostato su un valore > 24 ore.

Un utente può passare a Clienti e partner (Customers & Partners) > Monitora clienti (Monitor Customers) > Impostazioni servizio (Service Settings) > Gestione Edge (Edge Management) e nella sezione Impostazioni Edge generale (General Edge Settings) impostare Limite inattivo link Edge (Edge Link Down Limit) su un valore maggiore di 24 ore e salvarlo. Tuttavia, nonostante questa nuova impostazione, un link WAN inattivo non è più presente nella pagina Monitora (Monitor) dopo 24 ore.
Problema 110285 risolto: Un utente dell'azienda di un cliente con più di 5000 servizi di rete può notare che l'interfaccia utente di Orchestrator viene caricata lentamente per Panoramica della rete (Network Overview), Monitora (Monitor) > Edge (Edges), Configura (Configure) > Edge (Edges) e Configura (Configure) > Edge (Edges) > Dispositivo (Device).

Questo problema si verifica perché la chiamata API getEnterpriseServices impiega molto tempo per recuperare i risultati quando è presente un numero elevato di servizi di rete.
Problema 111407 risolto: VMware SASE Orchestrator non consente a un utente di disattivare l'interfaccia instradata di un Edge se è definita dall'utente e non ha alcun link WAN associato.

La convalida di Orchestrator non consente a un utente di salvare i dati senza un link WAN aggiunto e l'unica soluzione consiste nell'aggiungere un link WAN.
Problema 111497 risolto: Nella pagina Configura (Configure) > Controllo flusso overlay (Overlay Flow Control) dell'interfaccia utente di Orchestrator, i valori di VPN uscita preferita (Preferred Exit VPN) vengono visualizzati come "non definiti" per le subnet del sito.

Se per una destinazione non SD-WAN tramite gateway è specificata la configurazione dell'hop successivo, le subnet del sito in Configura (Configure) > Controllo flusso overlay (Overlay Flow Control) indicano VPN uscita preferita (Preferred Exit VPN) come "non definita" per le VPN il cui tipo di tunnel è "ACTIVE_ACTIVE".
Problema 111778 risolto: Quando un utente modifica una destinazione non SD-WAN tramite gateway con tipo Check Point (CheckPoint), Orchestrator imposta il tipo di VPN su Router IKEv1 generico (Generic IKEv1 Router).

Questo problema riguarda qualsiasi cliente con NSD di tipo Check Point (CheckPoint) e può causare un'interruzione se l'utente non rileva le operazioni che l'interfaccia utente di Orchestrator sta eseguendo.
Problema 112123 risolto: Quando viene aggiunto un VMware SD-WAN Edge 640-N, il nome del modello non viene visualizzato correttamente nell'interfaccia utente di VMware SASE Orchestrator.

Nell'interfaccia utente di Orchestrator il nome viene visualizzato come "EdgeModel.edge640-n" e non come "Edge 640-N".
Problema 112188 risolto: Nell'azienda di un cliente che distribuisce una destinazione non SD-WAN utilizzando GRE, quando il tunnel NSD diventa inattivo, in Orchestrator viene visualizzato un messaggio non corretto.

In Orchestrator viene visualizzato il messaggio: "Tunnel IPSec diretto Edge inattivo" (Edge Direct IPsec tunnel down), mentre il tunnel NSD è GRE.
Problema 112535 risolto: Quando si configura una regola del firewall in Configura (Configure) > Firewall, l'opzione Porta di trasporto (Transport Port) viene visualizzata erroneamente nella schermata Origine (Source) > Definisci (Define) > Trasporto (Transport).

In Orchestrator l'opzione Porta di trasporto (Transport Port) viene visualizzata semplicemente come "Trasporto" (Transport), che è vago e può causare confusione durante la configurazione di una regola del firewall.
Problema 112826 risolto: Quando un cliente esporta un elenco di avvisi in un file CSV tramite l'interfaccia utente di Orchestrator, recupera solo 512 elementi.

Se si esegue la stessa esportazione utilizzando un'API, vengono recuperati fino a 2048 avvisi, ovvero la quantità prevista anche per l'esportazione dell'interfaccia utente di Orchestrator. La limitazione di 512 influisce sui clienti che esportano avvisi il cui numero supera il limite di 512 per l'intervallo di tempo specificato.
Problema 113474 risolto: L'utente non può configurare un indirizzo di interfaccia host parziale durante la configurazione della delega del prefisso DHCPv6 nelle interfacce o nelle interfacce secondarie LAN IPv6.
In Orchestrator manca la convalida corretta per consentire un indirizzo IPv6 parziale.

Cosa è previsto per questo comportamento: con la correzione, i seguenti tipi di indirizzi di interfaccia completi o parziali sono consentiti o bloccati per la delega del prefisso DHCPv6 nella LAN e nella VLAN:
- Indirizzi IPv6 consentiti:
  - 2001::20; 2222:db8:3333:4444:5555:6666:7777:8888
  - 2001:db8:3333:4444:CCCC:DDDD:EEEE:FFFF
  - ::1:0:0:0:1
  - ::f:1:0:f
  - ::f:1:e;
  - ::c:1
- UNIQUE_LOCAL_IPV6 - fc00::
- GLOBAL_UNICAST - 2000:: or 2001:0DB8:C21A:1::
- Indirizzi IPv6 bloccati:
  - indirizzo vuoto - ::
  - indirizzo multicast - FF01:0:0:0:0:0:0:18C, FF01:0:0:0:0:0:0:BAC0 oppure FF01:0:0:0:0:DB8::
  - loopback - 0:0:0:0:0:0:0:1 or ::1
  - locale del link - fe80::210:5aff:feaa:20a2 or fe80::260:97ff:fe02:6ea5
  - locale del sito - fec0::
- Poiché è possibile utilizzare una sola coppia di ::, i seguenti indirizzi IP sono bloccati: ::1:0:0::0:1 or ::f:1:0::f
Problema 113530 risolto: L'utente non può modificare il tipo di indirizzamento IPv6 da Delega prefisso DHCPv6 (DHCPv6 Prefix Delegation) a qualsiasi altro tipo in un'interfaccia o un'interfaccia secondaria LAN instradata.

Nella sezione Configura (Configure) > Edge > Dispositivo (Device) >Interfaccia (Interface) > IPv6 LAN (LAN IPv6) in cui è possibile configurare la delega del prefisso DHCPv6 in Orchestrator, se l'utente tenta di selezionare un altro tipo di indirizzamento, ovvero Statico (Static), DHCP stateful (DHCP Stateful) o DHCP stateless (DHCP Stateless), l'opzione Salva (Save) rimane inaccessibile e l'utente non può completare la modifica. Il problema è il risultato di un difetto del processo che verifica l'univocità della configurazione della delega del prefisso DHCPv6 in un Edge.
Problema 114151 risolto: Quando vengono visualizzati Edge e gateway nelle pagine dei rispettivi elenchi, il certificato loro assegnato è una colonna facoltativa.

Poiché l'utilizzo dei certificati è un comportamento predefinito, i set di colonne predefiniti per gli elenchi di Edge o gateway dovrebbero essere sempre visibili per l'utente senza che debba impostarli.
Problema 114444 risolto: Quando un VMware SASE Orchestrator viene aggiornato alla versione 5.1.x o successiva, un utente non può salvare le modifiche apportate a una configurazione per una destinazione non SD-WAN tramite gateway in cui sono già configurati tunnel ridondanti.

L'utente non potrà salvare la configurazione nella pagina NSD tramite gateway e potrebbe verificarsi la perdita di pacchetti nei gateway per gli NSD ridondanti.

La soluzione a questo problema consiste nell'aggiornare l'hop massimo a 2 nell'interfaccia utente di NSD tramite gateway per i router adiacenti BGP ridondanti e salvare le modifiche.
Problema 114475 risolto: Quando un operatore tenta di aggiornare un VMware SASE Orchestrator dalla versione 4.2.0 alla versione 5.1.0, è possibile che Orchestrator segnali che l'aggiornamento non è riuscito.

Nei registri l'operatore può notare questa voce: Error while initializing CWS Server service Error: Too many connections. Questo problema viene attivato dal riavvio di MySQL prima dell'installazione di vco-db-schema a causa della mancata impostazione del numero massimo di connessioni di MySQL. Inoltre, mentre Orchestrator segnala che l'installazione non è riuscita, l'installazione è stata completata. È possibile riavviare Orchestrator e tutti i servizi funzioneranno come previsto.
Problema 114897 risolto: Quando si accede all'interfaccia utente di VMware SASE Orchestrator come partner o quando un operatore esamina il livello Partner, la scheda "Clienti" (Customers) viene visualizzata come "Clienti e partner" (Customers & Partners).

Il nome corretto è Clienti (Customers) e viene visualizzato in questa versione di Orchestrator.
Problema 115441 risolto: Nella pagina Impostazioni globali (Global Settings) > Configurazione cliente (Customer Configuration), quando si configura il riquadro SD-WAN, le immagini del software e del firmware sono visibili solo quando sono attivate.

Le immagini del software e del firmware devono essere sempre visibili per l'utente indipendentemente dal loro stato.
Problema 115695 risolto: Nella pagina Monitora (Monitor) > Edge (Edges), un cliente non può cercare un Edge in base alla descrizione nella tabella Elenco Edge (Edge List).

Alcune parole della descrizione di un Edge (ad esempio, Attivato (Activated) o la posizione dell'Edge) sono utili per la ricerca di tutti gli Edge con una descrizione simile.
Problema 115837 risolto: Nella pagina Monitora (Monitor) > Edge (Edges) o Configura (Configure) > Edge (Edges) dell'interfaccia utente di Orchestrator, quando si tenta di cercare Edge nella tabella principale, non è possibile eseguire la ricerca finché non vengono caricati tutti gli Edge.

Quando si caricano gli Edge nella tabella principale, la rotellina dell'elenco blocca la barra di ricerca impedendone l'utilizzo fino al completamento della richiesta. Questa operazione può richiedere un po' di tempo, specialmente se l'azienda ha un grande numero di Edge.
Problema 116021 risolto: Nella pagina Configura (Configure) > Edge (Edges) > Dettagli certificato (Certificated Detail) dell'interfaccia utente di Orchestrator, l'usabilità della finestra di dialogo è scarsa.

Nella finestra di dialogo Dettagli certificato (Certificate Detail) sono incorporate 3 barre di scorrimento, che rendono complicato l'utilizzo.
Problema 116524 risolto: Per i clienti che sottoscrivono Edge Network Intelligence e hanno l'analisi attivata, quando un utente esamina l'elenco di link a sinistra nella pagina Monitora (Monitor), può notare due link per l'analisi che hanno nomi diversi ma sono esattamente uguali e quindi ridondanti.

Sono disponibili due link per Edge Network Intelligence: Analisi applicazione (Application Analytics) e Analisi filiale (Branch Analytics) ed entrambi indirizzano alla stessa posizione in ENI. Il problema è stato corretto con l'inserimento di un singolo link sul lato sinistro denominato Edge Network Intelligence.
Problema 116610 risolto: Gli utenti non possono aggiungere una nuova interfaccia di loopback dell'Edge tramite APIv2.

Non è possibile creare una nuova interfaccia di loopback utilizzando l'operazione PATCH ADD tramite APIv2. La struttura dello schema per l'interfaccia di loopback in APIv2 non consente le interfacce denominate dall'ID interfaccia e in questo scenario l'aggiornamento dell'interfaccia di loopback non riesce.
Problema 116999 risolto: Quando un utente operatore accede a VMware SASE Orchestrator, sul lato destro di Orchestrator il menu è "Menu partner" (Partner Menu).

Questo può causare confusione per l'operatore che pensa di accedere al menu errato perché dovrebbe essere "Menu operatore" (Operator Menu).
Problema 117001 risolto: Nella pagina Amministrazione (Administration) > Gestione utenti (User Management) > Ruoli (Roles) dell'interfaccia utente di Orchestrator, l'utente non può osservare tutti i tipi di ruolo o gli utenti in una pagina.

La pagina Ruoli (Roles) è dotata di impaginazione. Ciò significa che i ruoli non si trovano tutti in una sola pagina del browser, ma sono distribuiti in più pagine del browser. Il problema consiste nel fatto che i controlli della pagina dell'interfaccia utente non sono facilmente visibili. La correzione elimina l'impaginazione e posiziona tutti i ruoli e i tipi in un'unica pagina.
Problema 117020 risolto: Nella pagina Configura (Configure) > Servizi di rete (Network Services) dell'interfaccia utente di Orchestrator, se un utente seleziona la scheda Servizi TACACS (TACACS Services) e tenta di eliminare un servizio TACACS, nell'interfaccia utente viene visualizzata una stringa di testo errata per confermare l'eliminazione.

Quando si elimina un servizio TACACS, nell'interfaccia utente viene visualizzata la stringa di testo configuration.networkServices.deleteConfirm. Nell'interfaccia utente dovrebbe essere visualizzata la finestra di dialogo di eliminazione corretta "Eliminare questo elemento?" (Are you sure you wish to delete this item?).
Problema 117145 risolto: Nell'azienda di un cliente che distribuisce VNF, quando un utente modifica una configurazione in Configura (Configure) > Dispositivo (Device), Orchestrator disattiva VNF.

Orchestrator non ridistribuisce VNF dopo la disattivazione, causando un'interruzione significativa per il cliente.
Problema 117152 risolto: Se un utente crea un filtro BGP in cui la community include valori interi superiori a 65535 e lo assegna a un router adiacente, Orchestrator consente questa integrazione anche se l'Edge ignora il filtro.

L'Edge supporta solo valori della community nel formato AA:NN con valori (0-65535):(0-65535). Se vengono specificati come numeri interi valori superiori a 65535, l'Edge li ignora e Orchestrator non riesce a rifiutare un filtro con un valore maggiore di 65535.
Problema 117385 risolto: Un utente può notare che VMware SASE Orchestrator è lento quando tenta di apportare più modifiche della configurazione.

Il cliente non può eseguire più modifiche della configurazione in Orchestrator. Le operazioni possono impiegare fino a un minuto.
Problema 117537 risolto: Nella pagina Monitora (Monitor) > Edge (Edges) > Origini (Sources) dell'interfaccia utente di Orchestrator, l'elenco dei dispositivi client indica un numero errato di dispositivi, in genere un numero minore di quello effettivo.

Il problema si verifica quando la modalità "Visibilità per indirizzo IP" (Visibility by IP Address) o "Visibilità per indirizzo MAC" (Visibility by MAC Address) non è impostata nel modulo di configurazione specifico dell'Edge predefinito, ma è impostata in un modulo associato.
Problema 117573 risolto: Nella pagina Configura (Configure) > Dispositivo (Device) > VPN > VPN cloud (Cloud VPN), quando un utente tenta di configurare un sito da filiale ad hub, gli hub non possono essere filtrati utilizzando l'icona del filtro.

Se nell'azienda di un cliente sono configurati più hub, la mancanza di filtri rende difficoltosa la configurazione di una VPN da filiale ad hub.
Problema 117614 risolto: Nella casella Collegamenti (Shortcuts) della pagina Configura (Configure) > Profilo (Profile) dell'interfaccia utente di Orchestrator mancano diverse azioni.

I collegamenti mancanti includono: Migra profilo (Migrate Profile), Duplica profilo (Duplicate Profile), Modifica profilo (Modify Profile) ed Elimina profilo (Delete Profile). Queste azioni sono disponibili nella pagina elenco del profilo, ma il cliente dovrebbe poter accedere in modo più semplice a queste azioni.
Problema 118265 risolto: Nella pagina Gestione utenti (User Management) dell'interfaccia utente di Orchestrator, un utente amministratore con privilegi corretti non può eliminare un account utente se utilizza la ricerca per individuare tale account.

Quando l'utente utilizza la barra di ricerca per individuare l'account e usa 4 o più caratteri, quando trova l'account il pulsante Elimina (Delete) è disattivato e non funziona.
Problema 118302 risolto: Nella pagina Monitora (Monitor) > Edge dell'interfaccia utente di Orchestrator, l'utente non può filtrare lo stato del link per gli Edge.

L'API di Orchestrator è stata migliorata in modo da accettare lo stato del link come parametro di filtro e consente di filtrare lo stato del link nella schermata dell'elenco degli Edge.
Problema 118527 risolto: In un VMware SASE Orchestrator distribuito come Orchestrator Bastion utilizzando un'autorità di certificazione esterna, i clienti possono notare che un VMware SD-WAN passa offline quando viene promosso correttamente.

In un ambiente Bastion in cui l'Orchestrator privato è integrato con un'autorità di certificazione esterna, l'Edge passa allo stato offline subito dopo la promozione a Orchestrator privato.

In un Orchestrator senza una correzione per questo problema, la soluzione consiste nell'eliminare l'elenco di revoche di certificati (CRL) nel dispositivo Edge e riavviare il servizio Edge.
Problema 118670 risolto: Il caricamento della pagina Monitora (Monitor) > Servizi di rete (Network Services) > Cluster Edge (Edge Clusters) può richiedere più di 30 secondi.

Quando un'azienda dispone di più di 10.000 servizi di rete, il caricamento della pagina Monitora (Monitor) > Servizi di rete (Network Services) > Cluster Edge (Edge Clusters) richiede molto tempo.
Problema 118761 risolto: Nella pagina Elenco Edge (Edge Listing), quando utilizza il menu a discesa Assegna immagine software (Assign Software Image), l'utente non può filtrare le immagini software.

La mancanza di filtri rende più difficile il processo di selezione quando sono presenti molte immagini software tra cui scegliere.
Problema 118764 risolto: Nella pagina Elenchi Edge (Edge Listings), il menu a discesa Assegna profilo operatore (Assign Operator Profile) non consente agli utenti di filtrare gli elementi.

La mancanza di opzioni di filtro rende il processo di selezione del profilo operatore più difficile di quello che dovrebbe essere.
Problema 118767 risolto: Nella pagina Panoramica Edge (Edge Overview), gli utenti non possono filtrare gli elementi ed effettuare selezioni quando aggiornano la selezione della licenza dell'Edge.

La mancanza di filtri rende più difficile il processo di selezione quando sono presenti molte licenze dell'Edge tra cui scegliere.
Problema 121336 risolto: Quando in un Edge o un profilo è configurata l'opzione "Assegnazione gateway partner" (Partner Gateway Assignment) nella pagina Configura (Configure) > Dispositivo (Device) e le modifiche vengono apportate tramite una chiamata API, nell'evento "Aggiornamento profilo" (Profile Update) i gateway vengono sempre visualizzati come eliminati.

Questo comportamento è puramente cosmetico e non ha alcun effetto sul funzionamento. Il problema si verifica perché il campo Gateway (Gateways) è deprecato nella configurazione.
Problema 121995 risolto: Un cliente riceve avvisi di failover HA anche se ha disattivato tali avvisi nella pagina Configura (Configure) > Avvisi (Alerts) di Orchestrator.

Quando gli avvisi aziendali sono abilitati ma gli avvisi di failover HA non sono abilitati, agli utenti aziendali vengono inviati gli avvisi di failover HA.
Problema 122940 risolto: Quando un utente si trova nella pagina Gestione gateway (Gateway Management), in alcuni casi può essere reindirizzato alla schermata errata.

Quando un cliente desidera assegnare un Gateway VPN sicuro (Secure VPN Gateway), Orchestrator deve eseguire il reindirizzamento alla schermata Assegna gateway datacenter (Assign Datacenter Gateway), ma esegue erroneamente il reindirizzamento alla schermata Assegna super gateway (Assign Super Gateway).
Problema 123593 risolto: Nel sito aziendale di un cliente distribuito con una topologia ad alta disponibilità in cui è attivata l'analisi di Edge Network Intelligence, in rari casi è possibile che l'Edge HA non esegua il pull della configurazione dell'analisi dal back-end di Edge Network Intelligence.

È possibile che l'Edge attivo e l'Edge di standby ottengano lo stesso token dal back-end ENI. Se l'Edge di standby ottiene il token dopo l'Edge attivo, il token dell'Edge attivo diventa obsoleto causando questo scenario.
Problema 123619 risolto: Se un VMware SASE Orchestrator non può accedere a Internet (ad esempio, un'istanza locale), la pagina Monitora (Monitor) > Edge > Panoramica (Overview) è vuota e non include informazioni.

Quando Orchestrator non può accedere a Internet, la pagina Panoramica Edge (Edge Overview) non è accessibile a causa della mancanza di accesso ai servizi Google.
Problema 123867 risolto: Le API delle serie e delle metriche dei link restituiscono un errore.

Quando viene chiamata l'API delle serie o delle metriche dei link senza un elenco di metriche, l'API restituisce un errore anziché aggiungere tutte le metriche applicabili alla risposta.

In un Orchestrator senza una correzione per questo problema, l'utente deve inviare una richiesta API con un elenco di campi delle metriche da restituire.
Problema 124092 risolto: Nella schermata Controllo flusso overlay (Overlay Flow Control), l'utente non può vedere il nome del segmento.

Quando si tenta di filtrare in base al nome del segmento, il nome del segmento non è presente nei risultati.
Problema 124743 risolto: Nella schermata Monitora (Monitor) > Edge > Panoramica (Overview) di VMware SASE Orchestrator, il caricamento della griglia Stato link (Links Status) non viene mai completato.

Non è possibile caricare lo stato del link quando uno o più link WAN sono configurati come backup o hot standby. In questa istanza, manca uno stato di backup/hot standby in uno dei link e l'interfaccia utente non viene eseguita correttamente.

Un utente può risolvere questo problema impostando la modalità per "Trasporto di backup" (Backup Transport) del link da "Hot standby" (Hot Standby) ad "Attivo" (Active), salvare e quindi impostarla di nuovo su "Hot standby" (Hot Standby).
Problema 126257 risolto: Il valore più alto nella pagina Monitora (Monitor) > Edge > Link (Links) non è visibile per gli utenti quando sono presenti molti valori notevolmente elevati.

Il problema si verifica perché l'altezza del grafico è stata precedentemente calcolata utilizzando i valori più bassi. Questo ha reso impreciso il grafico che non può essere allineato con la scala.
Problema 127281 risolto: Nella pagina Configura (Configure) > Controllo flusso overlay (Overlay Flow Control) dell'interfaccia utente di Orchestrator, le configurazioni statiche nelle interfacce secondarie instradate non vengono visualizzate nella pagina OFC come route connesse.

Quando una configurazione statica viene eseguita in un'interfaccia o in un'interfaccia secondaria non WAN instradata, è previsto che venga visualizzata nella pagina OFC come route connessa. Tuttavia, questa operazione non funziona per le interfacce secondarie che utilizzano configurazioni IPv6 in cui IPv6 non è attivato anche nell'interfaccia principale dell'interfaccia secondaria.
Problema 127636 risolto: Nella pagina Monitora (Monitor) > Edge > Origini (Sources) dell'interfaccia utente di VMware SASE Orchestrator, se si cerca un'origine in base al nome di dominio completo (FQDN), tale operazione non funziona.

La funzionalità di ricerca in base al nome di dominio completo (FQDN) non funziona come previsto quando si utilizza la nuova interfaccia utente. Di conseguenza, l'utente non può individuare un'origine utilizzando un metodo standard. E non può nemmeno eseguire una ricerca in base a una stringa parziale.

È comunque possibile eseguire una ricerca in base all'indirizzo IP, ma è necessario utilizzare una stringa completa.
Problema 127849 risolto: Non è possibile fare clic sul pulsante Visualizza certificato (View Certificate) che è disattivato nella schermata Edge > Configurazione (Configuration) > Panoramica (Overview).

Questo problema impedisce agli utenti di visualizzare i certificati dell'Edge. Senza una correzione dell'interfaccia utente, un utente può visualizzare il certificato dell'Edge passando all'elenco di Edge nella scheda Configurazione (Configuration) e cercare l'Edge desiderato.

Problemi noti

Problemi ancora irrisolti nella versione 5.2.0.

Problemi noti di Edge/Gateway
Problemi noti di Orchestrator

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: 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: 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: 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: riavviare l'Edge dopo aver spostato i link WAN USB da una porta all'altra.
Problema 25885:

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

Soluzione: nessuna soluzione 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).

Soluzione: nessuna soluzione disponibile.
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: 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.

Soluzione: nessuna soluzione disponibile.
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.

Soluzione: nessuna soluzione disponibile.
Problema 31210:

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

Soluzione: nessuna soluzione disponibile.
Problema 32731:

Le route predefinite condizionali annunciate tramite OSPF potrebbero non essere ritirate correttamente quando la route è disattivata.

Soluzione: se si riattiva la route e quindi la si disattiva di nuovo, le 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.

Soluzione: Fare riferimento all'interfaccia utente di Orchestrator in Diagnostica remota (Remote Diagnostics) > Stato interfaccia (Interface Status).
Problema 32981:

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

Soluzione: non esistono soluzioni a questo problema.
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 verso 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: utilizzare un'interfaccia diversa per ogni link WAN che deve creare tunnel GRE a Zscaler.
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 configurata per DPDK potrebbe non generare correttamente gli eventi "Nuovo dispositivo client" (New Client Device) 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: riavviare l'Edge per cancellare il tunnel obsoleto.
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 della diagnostica remota "Test ping" potrebbe mostrare per pochi istanti i contenuti non validi prima di mostrare i risultati corretti.

Soluzione: non esiste alcuna soluzione per questo problema.
Problema 39624:

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

Soluzione: non esistono soluzioni a questo problema.
Problema 39753:

La disattivazione della VPN dinamica da filiale a filiale (Dynamic Branch-to-Branch VPN) può causare il blocco dei flussi esistenti in fase di invio tramite Da filiale a filiale dinamico (Dynamic Branch-to-Branch).

Soluzione: disattivare la VPN dinamica da filiale a filiale solo in una finestra di manutenzione.
Problema 40421:

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

Se un VMware SD-WAN Edge 840 attivato viene riavviato, è possibile che un modulo SFP collegato all'Edge interrompa il passaggio del traffico anche se il link si illumina e in VMware SD-WAN Orchestrator la porta viene visualizzata come "ATTIVA" (UP).

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

Per un tipo specifico di configurazione errata del peer, il VMware SD-WAN Gateway può inviare continuamente messaggi init 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 42872:

L'attivazione dell'isolamento del profilo in un profilo hub in cui è associato un cluster hub non revoca le route dell'hub dalla RIB (Routing Information Base).
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 flusso overlay, l'Edge non viene rimosso dall'elenco degli annunci e continua a essere annunciato.

Soluzione: attivare il calcolo dei costi distribuito (Dynamic Cost Calculation (DCC)) in VMware SD-WAN Orchestrator.
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: 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.

Soluzione: se un cliente utilizza AES-256, deve disattivare 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.
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 della fase 2, anche l'IKE della fase 1 viene eliminata e forza una ridefinizione della chiave. Ciò significa che il tunnel è stato eliminato e ricreato, causando la perdita di pacchetti durante la ricostruzione del tunnel.

Soluzione: 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:

Nelle interfacce SFP1 e SFP2 di un VMware SD-WAN Edge 3800 si verificano problemi relativi agli SFP multi-rate (ovvero 1/10 G) e non devono essere utilizzate in tali porte.

Soluzione: utilizzare SFP single-rate in base alle indicazioni dell'articolo della Knowledge Base Elenco di moduli SFP supportati da VMware SD-WAN (79270). Gli SFP multi-rate possono essere utilizzati con SFP3 e SFP4.
Problema 47664:

In una configurazione di hub e spoke dove la VPN da filiale a filiale tramite hub non è configurata, 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: configurare la VPN cloud per attivare la VPN da filiale a filiale e selezionare "Usa hub per VPN" (Use Hubs for 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 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: 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 48597: Il router adiacente BGP multihop non resta attivo se uno dei due percorsi per il peer diventa inattivo.

Se è presente un router adiacente BGP multihop con un peer verso cui sono disponibili più percorsi e uno di tali percorsi diventa inattivo, l'utente noterà che il router adiacente BGP diventa inattivo e non viene riattivato utilizzando gli altri percorsi disponibili. Questo include anche il caso dell'adiacenza di IP-loopback locale.

Soluzione: non esistono soluzioni a questo problema.
Problema 50518:

In un VMware SD-WAN Gateway in cui è configurata l'infrastruttura PKI, se più di 6.000 tunnel PKI tentano di connettersi al gateway, è possibile che i tunnel non diventino 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 51436: per un sito che utilizza una topologia ad alta disponibilità ottimizzata durante la distribuzione di un VMware SD-WAN Edge utilizzando un modem LTE, se il sito entra in uno stato "Split-Brain", il failover dell'alta disponibilità (HA) impiega circa 5-6 minuti.

Come parte del ripristino da uno stato Split-Brain, le porte LAN vengono disattivate nell'Edge attivo e questo influisce sul traffico LAN durante il tempo in cui le porte sono in stato inattivo e finché il sito non può essere recuperato.

Soluzione: non esistono soluzioni a questo problema.
Problema 52955: Il rifiuto di DHCP non viene inviato dall'Edge e il rebinding di DHCP non viene riavviato dopo l'errore DAD nel DHCP stateful.

Se il server DHCPv6 alloca un indirizzo rilevato come duplicato dal kernel durante un controllo DAD, il client DHCPv6 non invia un rifiuto. Questo comporta l'interruzione del traffico perché l'indirizzo dell'interfaccia verrà contrassegnato come controllo DAD non riuscito e non verrà utilizzato. Nella rete non si verificherà alcun loop del traffico, ma verrà eseguito il blackholing del traffico.

Soluzione: non esistono soluzioni a 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é nell'Edge spoke interessato non viene riavviato il servizio Edge.
Problema 53934: In un'azienda in cui è configurato un cluster hub di VMware SD-WAN, se l'hub primario ha router adiacenti BGP multihop sul lato LAN, il cliente può riscontrare un calo del traffico in un Edge spoke quando si verifica un errore sul lato LAN o quando BGP non è configurato in tutti i segmenti.

In un cluster hub, l'hub primario presenta un router adiacente BGP multihop con un dispositivo peer per apprendere le route. Se l'interfaccia fisica nell'hub con cui viene stabilita l'adiacenza BGP diventa inattiva, le route della LAN BGP potrebbero non diventare zero nonostante la vista BGP sia vuota. Questo potrebbe impedire il ribilanciamento del cluster di hub. Il problema può verificarsi anche quando BGP non è configurato per tutti i segmenti e quando sono presenti uno o più router adiacenti BGP multihop.

Soluzione: riavviare l'hub in cui si è verificato l'errore sul lato LAN (o in cui BGP non è attivato).
Problema 57210: Anche quando un VMware SD-WAN Edge funziona correttamente ed è in grado di raggiungere Internet, il LED nella pagina Panoramica (Overview) dell'interfaccia utente locale viene visualizzato come "Rosso".

L'interfaccia utente locale dell'Edge determina la connettività dell'Edge in base al fatto che sia in grado di risolvere un nome noto tramite il resolver DNS di Google (8.8.8.8). Se per un motivo qualsiasi l'operazione non riesce, ritiene che l'Edge sia offline e il LED diventa rosso.

Soluzione: Non esistono soluzioni a questo problema, ad eccezione di garantire che il traffico DNS a 8.8.8.8 possa raggiungere la destinazione e venga risolto correttamente.
Problema 61543: Se più regole NAT 1:1 sono configurate in interfacce diverse con lo stesso IP interno, il traffico in entrata può essere ricevuto in un'interfaccia e i pacchetti in uscita dello stesso flusso possono essere instradati tramite un'altra interfaccia.

Per i flussi NAT dall'esterno all'interno, le regole NAT 1:1 verranno confrontate con l'IP esterno e l'interfaccia in cui vengono ricevuti i pacchetti. Per i pacchetti in uscita dello stesso flusso, VMware SD-WAN Edge tenterà nuovamente di far corrispondere le regole NAT confrontando l'IP interno e il traffico in uscita può essere instradato tramite l'interfaccia configurata nella prima regola di corrispondenza con l'opzione "Traffico in uscita" (Outbound Traffic) configurata.

Soluzione: Non è disponibile alcuna soluzione per questo problema, ad eccezione di garantire che non sia configurata più di una regola NAT 1:1 con un particolare indirizzo IP interno.
Problema 65560: Il traffico da un cliente a un dispositivo PE (Provider Edge) non riesce.

La presenza di router adiacenti BGP tra un Gateway partner e l'Edge del provider non viene stabilita quando si seleziona "nessuno" (none) come tipo di tag nella configurazione dell'handoff. Ciò è dovuto al fatto che i valori ctag, stag vengono selezionati da /etc/config/gatewayd anziché dalla configurazione dell'handoff in Orchestrator quando il tipo di tag è "nessuno".

Soluzione: aggiornare i valori di ctag e stag impostandoli su 0 in vrf_vlan->tag_info in /etc/config/ gatewayd. Eseguire un riavvio vc_procmon.
Problema 67879: Un tunnel del Servizio di sicurezza cloud (CSS) viene eliminato dopo che un utente modifica un'impostazione dell'overlay WAN da rilevamento automatico a definito dall'utente in un'impostazione dell'interfaccia WAN.

Dopo aver salvato le modifiche, i tunnel CSS non vengono riattivati finché il cliente non disattiva e quindi riattiva il tunnel. Se si modifica la configurazione WAN, il tunnel CSS verrà disattivato e verrà eseguita nuovamente l'analisi della configurazione di CSS. Tuttavia, in alcuni rari casi, nvs_config>num_gre_links è 0 e il tunnel CSS non viene attivato.

Soluzione: disattivare la configurazione di CSS, quindi riattivarla per rendere attivo il tunnel CSS.
Problema 68057: Il pacchetto della versione DHCPv6 non viene inviato da VMware SD-WAN Edge quando si modifica la modalità dell'indirizzo dell'interfaccia WAN dall'indirizzo DHCP stateful all'indirizzo IPv6 statico e il lease rimane attivo finché la sua validità non scade.

Il client DHCPv6 possiede un lease che non viene rilasciato quando viene eseguita la modifica della configurazione. Il lease rimane valido finché la sua durata scade nel server DHCPv6 e viene eliminato.

Soluzione: non è possibile correggere questo problema perché il lease rimane attivo per tutta la durata della sua validità.
Problema 68851: Se un VMware SD-WAN Edge e un VMware SD-WAN Gateway hanno ciascuno lo stesso server syslog TCP configurato, la connessione TCP dall'Edge al server syslog non viene stabilita.

Se l'Edge e il Gateway hanno ciascuno lo stesso server TCP e i pacchetti syslog vengono instradati dall'Edge tramite il Gateway, il server syslog invia una reimpostazione TCP all'Edge.

Soluzione: inviare i pacchetti syslog direttamente dall'Edge anziché eseguire il routing tramite un Gateway o configurare un server syslog diverso per l'Edge e il Gateway.
Problema 69284: Per un sito che utilizza una topologia ad alta disponibilità in cui gli Edge distribuiscono la VNF in una configurazione di alta disponibilità e utilizzano la versione 4.x, se questi Edge HA vengono sottoposti a downgrade a una versione 3.4.x in cui non sono supportate le VNF HA e vengono quindi aggiornati alla versione 4.5.0, quando le VNF HA vengono riattivate, la VNF dell'Edge di standby non viene attivata.

Lo stato della VNF nell'Edge di standby viene comunicato come inattivo tramite SNMP. Se la coppia VNF HA viene sottoposta a downgrade da una versione che supporta VNF-HA (versione 4.0+) a una versione che non la supporta con VNF configurata in Orchestrator. Questo problema si verifica quando l'Edge viene riaggiornato a una versione che supporta VNF-HA e viene nuovamente configurato in Orchestrator.

Soluzione: la VNF deve essere innanzitutto disattivata nel caso di una configurazione ad alta disponibilità, se si sta eseguendo il downgrade dell'Edge a una versione che non la supporta.
Problema 72358: Se l'indirizzo IP di un nome DNS di VMware SD-WAN Orchestrator cambia, il processo del piano di gestione di VMware SD-WAN Gateway non riesce a risolverlo correttamente e il Gateway non riuscirà a connettersi a Orchestrator.

Il processo di gestione del Gateway verifica periodicamente la risoluzione DNS del nome DNS

di Orchestrator per verificare se è stata modificata di recente in modo che il Gateway possa connettersi all'host corretto. Nel codice di risoluzione DNS è presente un problema per cui tutti questi controlli di risoluzione non vengono eseguiti correttamente e il Gateway continua a utilizzare l'indirizzo precedente e quindi non riesce più a connettersi a Orchestrator.

Soluzione: finché il problema non viene risolto, l'utente operatore non deve modificare l'indirizzo IP di Orchestrator. Se è necessario modificare l'indirizzo IP dell'Orchestrator, tutti i Gateway che si connettono a tale Orchestrator dovranno essere riattivati.
Problema 75171: Un utente del client Edge non riceve un indirizzo IP se il server DHCP è configurato in un sito di destinazione non SD-WAN tramite gateway in cui l'Edge funge da agente di inoltro.

Il problema si verifica perché i messaggi di Offerta DHCP (DHCP Offer) vengono eliminati dall'Edge perché il codice dell'Edge non tiene conto di questa configurazione DHCP.

Soluzione: posizionare il server DHCP in una posizione qualsiasi diversa da una destinazione non SD-WAN.
Problema 77541: quando un modem USB che supporta IPv6 viene scollegato e poi di nuovo collegato all'interfaccia USB di un VMware SD-WAN Edge, è possibile che non sia stato eseguito il provisioning di un indirizzo IPv6 nell'interfaccia USB.

Questo problema interessa i modem USB basati su IP anziché sull'applicazione ModemManager. La maggior parte dei modem Inseego è basata su IP, un aspetto importante da tenere presente perché Inseego è il produttore di modem consigliato per VMware SASE . I modem USB che supportano IPv6 e utilizzano ModemManager anziché essere basati su IP non presenteranno problemi in caso di disconnessione e riconnessione.

Soluzione: dopo aver ricollegato il modem USB alla porta USB dell'Edge, riavviare l'Edge (o eseguire un reset). Dopo il riavvio, l'Edge recupera l'indirizzo IPv6 per il modem.
Problema 81852: In un VMware SD-WAN Edge che utilizza un servizio di sicurezza cloud (CSS) di tipo Zscaler in cui vengono usati tunnel GRE con Controllo integrità L7 (L7 Health Check) attivato, quando l'Edge viene aggiornato alla versione 5.0.0, in alcuni casi il cliente può notare errori del Controllo integrità L7 (L7 Health Check).

In genere, questa circostanza si manifesta durante l'aggiornamento del software o durante l'avvio. Quando il Controllo dello stato L7 (L7 Health Check) è attivato per un CSS che utilizza tunnel GRE, è possibile che vengano visualizzati messaggi relativi all'errore getaddress del socket. L'errore è stato osservato in modo intermittente e non è costante. A causa di questo problema, i messaggi del probe del Controllo dello stato L7 (L7 Health Check) non vengono inviati.

Soluzione: senza la correzione, per risolvere il problema è necessario disattivare e riattivare la configurazione del Controllo dello stato L7 (L7 Health Check); la funzionalità viene ripristinata come previsto.
Problema 82184: In un VMware SD-WAN Edge che esegue l'Edge in versione 5.0.0, quando si avvia un comando traceroute o traceroute6 all'indirizzo IPv4/IPv6 della br-network dell'Edge, il traceroute non viene terminato correttamente se si utilizza un probe UDP.

Un traceroute o traceroute6 all'indirizzo IPv4/IPv6 della br-network dell'Edge non viene terminato correttamente quando si utilizza la modalità predefinita (ovvero, il probe UDP).

Soluzione: utilizzare l'opzione -I in traceroute e traceroute6 per utilizzare il probe ICMP; il traceroute all'indirizzo IPv4/IPv6 della br-network funzionerà come previsto.
Problema 83166: in caso di recente distribuzione di un VMware SD-WAN Gateway con un tipo di istanza AWS c5.4xlarge dal portale AWS con opzione IPv6 selezionata, le route predefinite e IPv6 non sono configurate.

A seguito alla mancata configurazione delle route predefinite e IPv6, i tunnel di gestione IPv6 del Gateway AWS non vengono formati e il Gateway non funziona.

Soluzione: non esistono soluzioni a questo problema; evitare la distribuzione di un Gateway con le proprietà sopra menzionate.
Problema 85402: Per l'azienda di un cliente che utilizza BGP con i gateway partner configurati, un utente può notare che alcuni router adiacenti BGP sono inattivi e ciò causa problemi di traffico del cliente.

Se un cliente ha il prefisso massimo configurato in un router con peering BGP con l'Edge e il gateway, è possibile che la sessione BGP venga eliminata dal router.

Ad esempio, se nel router è configurato BGP in modo da ricevere solo il numero massimo di prefissi "n", ma l'Edge e il gateway hanno un numero di filtri maggiore di "n" da annunciare in assenza di filtri. Ora, se la configurazione del filtro BGP viene modificata in Orchestrator, anche se il numero totale di prefissi consentiti nella direzione in uscita è inferiore a "n", si verifica il problema per cui più di "n" prefissi vengono inviati al peer prima che venga applicato qualsiasi filtro. Di conseguenza, il router rimuove la sessione.

Soluzione: Se BGP diventa inattivo a causa di questo problema (ovvero il raggiungimento del numero massimo di prefissi), eseguire il flap di BGP nel peer utilizzando la CLI (per FRR/Cisco, "neighbor x shut" seguito da "no neighbor x shut") e BGP produrrà solo con il numero desiderato di prefissi annunciati al peer.
Problema 92481: Se un'interfaccia WAN in un VMware SD-WAN Edge è disattivata in VMware SASE Orchestrator, SNMP riporterà comunque l'interfaccia come "UP".

Il processo di debug della chiave per l'output delle interfacce non include i dettagli della porta fisica per le interfacce WAN Edge (ad esempio, GE3 o GE4 o su un modello Edge 6x0 o 3x00). Di conseguenza, quando SNMP esegue il polling di tali interfacce, restituisce sempre un risultato che indica che sono attive indipendentemente dal modo in cui tali interfacce sono configurate.

Soluzione: non esistono soluzioni a questo problema.
Problema 93141: In un sito distribuito con una topologia ad alta disponibilità, un cliente che utilizza uno switch L2 upstream della coppia di Edge HA può osservare nei registri dello switch la presenza di un loop di traffico L2, nonostante non sia presente alcun loop effettivo.

Il problema è causato dall'Edge HA che invia l'heartbeat dell'interfaccia HA con l'indirizzo MAC virtuale a Orchestrator anziché l'indirizzo MAC effettivo dell'interfaccia, questo accade perché l'Edge HA archivia l'indirizzo MAC virtuale nel proprio file MAC. Di conseguenza, lo switch L2 connesso rileva il traffico dello stesso indirizzo MAC di origine proveniente da due interfacce Edge diverse e lo registra come loop L2. Questo problema è cosmetico a livello di registro poiché non è presente alcun loop L2 effettivo e non vi è alcuna interruzione del traffico del cliente o perdita di contatto con Orchestrator derivante da questo problema.

Soluzione: il cliente può ignorare gli eventi di rilevamento del loop L2 dai commutatori upstream che derivano dall'interfaccia HA dell'Edge (in genere GE1).
Problema 95399: Quando un link Ethernet viene scollegato fisicamente da un'interfaccia di VMware SD-WAN Edge o collegato a tale interfaccia, VMware SASE Orchestrator non riceve alcuna notifica di questo evento dall'Edge e non lo indica negli eventi del cliente.

I clienti utilizzano Orchestrator per segnalare questi eventi nella pagina Eventi (Events) e quando non vengono registrati, il monitoraggio dei vari siti risulta più inaffidabile.

Soluzione: non esistono soluzioni a questo problema.
Problema 95565: In un sito che utilizza una topologia ad alta disponibilità (HA) è possibile che nel VMware SD-WAN Edge attivo si verifichi un errore del servizio piano dati con un core generato che attiva il failover di HA.

Il problema è causato dai link WAN dell'Edge attivo che eseguono il flap una o più volte (disattivandosi e quindi riattivandosi rapidamente) utilizzando anche SNMP in cui sono presenti query SNMP frequenti. Si verifica un problema di temporizzazione per cui l'interfaccia che diventa nuovamente attiva e la query SNMP insieme possono attivare un deadlock che causa la mancata riuscita del servizio piano dati e la generazione di un core. Nonostante il problema possa essere causato anche da un solo flap del link WAN, maggiore è la frequenza dei flap del link WAN, maggiori saranno le probabilità che si verifichi.

Soluzione: in una coppia di Edge HA in cui si verifica il problema e non è disponibile la correzione, la soluzione consiste nel disabilitare SNMP perché si tratta di un problema di temporizzazione e questa operazione riduce il rischio che si verifichi.
Problema 97559: Nel sito di un cliente distribuito con una topologia ad alta disponibilità (HA) avanzata, un link WAN connesso a VMware SD-WAN Edge in un ruolo di standby può essere segnalato come inattivo in VMware SASE Orchestrator e non far passare il traffico del cliente anche se l'interfaccia WAN dell'Edge a cui il link WAN è connesso è attiva.
Un utente che esamina un tcpdump o la registrazione del bundle di diagnostica nota che sono presenti richieste ARP in arrivo e l'Edge di standby non risponde perché la sua porta è bloccata. Nell'alta disponibilità (HA) avanzata, quando un Edge assume il ruolo di standby, devono verificarsi gli eventi seguenti in sequenza:
1. L'Edge di standby blocca tutte le porte.
2. L'Edge di standby rileva quindi che è distribuito in modalità di alta disponibilità (HA) avanzata e sblocca le porte WAN per far passare il traffico.
Quando si verifica questo problema, l'evento 1, ovvero il completamento del blocco delle porte iniziale, richiede molto tempo e l'evento di follow-up 2, ovvero lo sblocco di tutte le porte WAN, viene completato prima del completamento dell'evento 1. Quando anche l'evento 1 viene completato, il risultato finale è che tutte le porte WAN sono bloccate nell'Edge di standby.
Soluzione: in un Edge HA senza una correzione per questo problema la soluzione consiste nel forzare un failover di HA che promuova l'Edge di standby ad Edge attivo rendendo attivi i link WAN dell'Edge HA.
Problema 98136: Per le aziende dei clienti che utilizzano una topologia hub/spoke in cui è configurata la VPN dinamica da filiale a filiale, gli utenti del client dietro un SD-WAN Edge spoke possono notare una latenza imprevista del traffico dovuta al fatto che utilizza un percorso non ottimale.

Il traffico dell'Edge spoke in cui si verifica questo problema utilizza una route che era inizialmente una route non uplink per un Edge hub non incluso nel profilo usato dall'Edge spoke. È possibile creare un tunnel della VPN dinamica da filiale a filiale dall'Edge spoke all'Edge hub perché il traffico viene inviato verso qualche altro prefisso non correlato e in questo caso la route non uplink è installata nell'Edge spoke.

In seguito alla presenza di questa route non uplink, tutto il traffico verso questo prefisso inizia a passare attraverso

l'Edge hub e la route non uplink diventa uplink (la community diventa community uplink). La route non uplink installata in precedenza non viene tuttavia revocata e il traffico segue il percorso dell'Edge hub finché il tunnel della VPN dinamica da filiale a filiale rimane attivo.

Soluzione: attendere la rimozione del tunnel della VPN dinamica da filiale a filiale. Dopo la rimozione, la route uplink non verrà installata nell'Edge spoke quando verrà creato un nuovo tunnel della VPN dinamica da filiale a filiale verso l'Edge hub.
Problema 102583: Nel sito aziendale di un cliente distribuito con una topologia ad alta disponibilità con VNF installate, in cui la coppia di Edge HA ha il modello 520/540 o 610, è possibile che si verifichi un errore di raggiungibilità della VNF dell'Edge di standby da un client connesso alla LAN.

La scheda di commutazione Ethernet in questi modelli di Edge elimina i pacchetti di risposta ARP inviati a un client LAN dalla VNF di un Edge di standby causando la perdita della raggiungibilità.

Soluzione: non esistono soluzioni a questo problema.
Problema 106289: Un VMware SD-WAN Hub Edge può eliminare pacchetti nei flussi verso gli Edge spoke connessi o nei flussi di backhaul.

Il flag del flusso di backhaul viene impostato durante il processo di sincronizzazione QoS. Nel codice è presente una posizione in cui viene impostato durante la creazione del flusso. L'Edge deve impostare questo flag solo in seguito all'elaborazione dei messaggi di sincronizzazione QoS;

Soluzione: se questo problema si verifica in un Edge hub senza una correzione, svuotare i flussi nell'Edge hub per risolverlo temporaneamente.
Problema 109771: È possibile che un VMware SD-WAN Edge non sia in grado di stabilire un tunnel con una destinazione non SD-WAN tramite Edge di tipo Cisco CSR/ASE quando viene applicato NAT66.

Se tra due peer viene coinvolto un NAT di indirizzo IPv6 di origine con Cisco CSR/ASA, non viene stabilito alcun tunnel.

Soluzione: In un Edge senza una correzione per questo problema, l'unica cosa che un utente può fare è aggiornare Cisco CSR/ASA a una versione del software Cisco che supporti NAT66 su IPSec.
Problema 110561: È possibile che in uno stesso set di VMware SD-WAN Edge con traffico bidirezionale non vengano attivati determinati tunnel dinamici quando il traffico viene arrestato e quindi riavviato.

Il problema si verifica in un ambiente di test in cui sono presenti 6000 tunnel dinamici con traffico bidirezionale elevato inviato tra gli Edge. Anche nei test su scala inferiore con 1000 tunnel dinamici, non tutti i tunnel vengono attivati.

Soluzione: non esistono soluzioni a questo problema.
Problema 111085: Quando il link WAN di un VMware SD-WAN Edge è configurato con un indirizzo IP nella stessa rete dell'IP di loopback dell'Edge, l'Edge utilizza l'indirizzo MAC dell'interfaccia WAN per rispondere a una richiesta ARP dell'indirizzo IP di loopback dell'Edge.

Questo può causare lo spoofing di ARP, la deprecazione dell'IP di gestione e l'interruzione della rete.

Soluzione: non esistono soluzioni a questo problema.
Problema 111592: Nell'azienda di un cliente che utilizza una topologia Hub/Spoke in cui i criteri di business sono configurati per l'utilizzo del backhaul Internet, il traffico Internet che utilizza la regola di backhaul può essere lento o non funzionare affatto.

In alcuni casi durante la creazione del flusso, la corrispondenza dei criteri di business viene modificata a causa di informazioni DPI (Deep Packet Inspection) aggiornate. Questo può causare la perdita dell'ID logico dell'Edge Hub o della destinazione non SD-WAN, che dovrebbe eseguire il backhaul dei pacchetti.

Soluzione: svuotare i flussi per forzare la reispezione dei flussi da parte del motore DPI.
Problema 117876: Nel sito di un cliente che utilizza una topologia ad alta disponibilità, se un utente attiva o disattiva Enhanced Firewall Services, è possibile che in un VMware SD-WAN Edge HA si verifichino più riavvii.

Quando Enhanced Firewall Services è attivato o disattivato, solo la configurazione delle impostazioni del dispositivo dell'Edge attivo viene sincronizzata immediatamente con l'Edge di standby. Il resto della sincronizzazione della configurazione viene eseguita solo in risposta a un heartbeat dell'Edge di standby. Quando l'Edge attivo viene riavviato per applicare la configurazione più recente prima di ricevere un heartbeat dall'Edge di standby, si verifica una mancata corrispondenza della configurazione tra i due Edge HA in cui vengono quindi eseguiti più riavvii per completare la sincronizzazione della configurazione.

Soluzione: l'unica soluzione consiste nell'attivare o disattivare Enhanced Firewall Services durante una finestra di manutenzione per gli Edge HA.
Problema 111840: Nell'azienda di un cliente distribuita con una topologia Hub/Spoke che utilizza 9 o più Edge hub, è possibile che la qualità del traffico degli utenti del client sia scarsa a causa di un routing non ottimale.

Quando un Edge spoke è configurato con più Edge hub, viene preferita una route tramite l'Edge hub anziché la route diretta e questo causa un routing non ottimale.

Soluzione: configurare innanzitutto gli Edge hub, seguiti dagli hub VPN nell'elenco dei siti da filiale ad hub.
Problema 120309: Le combinazioni di determinati client e server VPN PPTP potrebbero non essere in grado di ristabilire immediatamente una connessione dopo che è stata interrotta quando si utilizza la NAT 1:1 con Internet PPTP e il dispositivo client dietro l'Edge. È stato confermato che questo problema si verifica con Windows Server 2016 e Windows client 10, ma può verificarsi anche con altre versioni.

Il problema è causato dal fatto che il server riutilizza lo stesso call-id PPTP per la nuova connessione mentre il client utilizza un nuovo call-id. Quando il call-id del server viene riutilizzato per la nuova connessione, il firewall non lo identifica come nuova connessione.

In un Edge senza una correzione per questo problema, la soluzione consiste nell'eliminare la connessione PPTP obsoleta dalla tabella NAT.

Nota:
Lo stesso problema può verificarsi se vengono scambiate le posizioni di rete del client e del server (in altre parole, se il server PPTP si trova nella LAN dietro l'Edge e il client si trova su Internet o nel cloud). Questa versione del problema è segnalata nel ticket 109830. La correzione in questo caso riguarda specificamente i client Windows Server 2016. Il problema continua a verificarsi nei client Windows 10 che non sono interessati da questa correzione.

Soluzione: eliminare la connessione PPTP obsoleta dalla tabella NAT.
Problema 121281: In rari casi, nel sito aziendale di un cliente distribuito con una topologia ad alta disponibilità, l'utente può notare che nell'Edge di standby si verifica un errore del servizio piano dati, viene generato un core e viene eseguito un riavvio per il ripristino.

Si verifica un evento relativo al riavvio dell'Edge di standby e se l'utente configura un avviso relativo alla HA non riuscita, viene avvisato di tale evento. Il problema si verifica in rari scenari quando una route viene sincronizzata tra l'Edge attivo e l'Edge di standby e il servizio Edge di standby non riesce a causa del danneggiamento della memoria durante l'elaborazione del messaggio di sincronizzazione della route.

Soluzione: non esistono soluzioni a questo problema.
Problema 121371: Nell'azienda di un cliente configurata per l'utilizzo di Hub o Cluster Interconnect in cui viene usato anche il firewall stateful o il firewall avanzato, gli utenti client possono notare che il traffico viene eliminato.

Tra i nodi dell'hub del cluster di origine e di destinazione può verificarsi il routing asimmetrico in modo che il traffico in uscita segua un tunnel overlay diretto mentre il traffico di ritorno segua una route underlay.

Soluzione: l'unica soluzione consiste nel disattivare i servizi firewall stateful o firewall avanzato.
Problema 121606: Le aziende dei clienti che usano gateway partner possono notare che il traffico che include destinazioni non SD-WAN che utilizzano tali gateway viene eliminato.

I gateway partner con versione 5.1.0 e successive supportano al massimo 64 indirizzi IP per ogni interfaccia IPSec. In un gateway partner, a questa interfaccia IPSec vengono aggiunti IP di handoff senza condizioni. Se il numero di indirizzi IP di handoff supera il limite di 64, gli indirizzi IP precedenti vengono sovrascritti nel processo IPSec e i tunnel che utilizzano tali indirizzi IP sovrascritti diventano inattivi.

Soluzione: se tutti gli indirizzi IP di handoff dei gateway partner sono configurati come previsto, non esiste alcuna soluzione oltre allo spostamento di tali indirizzi in un gateway partner diverso (ad esempio, lo spostamento di un NSD tramite gateway). Tuttavia, se sono presenti indirizzi IP di handoff dei gateway partner non necessari, la loro rimozione può essere utile se riduce il numero di indirizzi IP al di sotto di 64. Dopo una modifica della configurazione, è necessario riavviare il servizio gateway.
Problema 121805: Per un VMware SD-WAN Edge distribuito con VNF, quando viene eseguito il ping di una VNF locale, l'utente può notare risposte duplicate.

Il problema si verifica quando viene eseguito un ping all'IP di una VNF dall'Edge.

Soluzione: eseguire sempre il ping da un client LAN dietro l'Edge, non dall'Edge stesso.
Problema 121998: Per un cliente che utilizza il firewall di tipo stateful in una topologia Hub/Spoke, il traffico che corrisponde a una regola del firewall configurata per il traffico da Spoke ad Hub in cui la regola include una VLAN di origine può essere eliminato.

In caso di modifica della classificazione delle applicazioni, della tabella dei criteri di business o della versione della tabella dei criteri del firewall, SD-WAN esegue una ricerca del firewall per i flussi nel suo prossimo pacchetto. A causa di un problema di temporizzazione, il pacchetto potrebbe essere uno di quelli provenienti dal lato del traffico di gestione (VCMP). Di conseguenza, durante la creazione di una chiave di ricerca dei criteri del firewall, SD-WAN scambia la VLAN dell'Edge Spoke con la VLAN dell'Edge Hub, il che comporta la mancata corrispondenza con la regola e l'interruzione del traffico.

Soluzione: Un cliente può modificare l'Origine (Source) da una VLAN dell'Edge a "Qualsiasi (Any)".
Problema 123379: Nel sito aziendale di un cliente distribuito con una topologia ad alta disponibilità, in rari casi il cliente può notare un errore del servizio piano dati dell'Edge di standby che viene quindi riavviato per il ripristino.

Questo problema può verificarsi quando un utente tenta di configurare l'indirizzo IPv6 nelle interfacce secondarie in 128 segmenti contemporaneamente utilizzando uno script. In questo scenario, le configurazioni vengono inserite in una coda e questo causa un errore del servizio dell'Edge di standby.

Soluzione: è consigliabile impostare le configurazioni degli indirizzi IPv6 nelle interfacce secondarie in gruppi più piccoli, in modo che il sistema abbia il tempo necessario per elaborare e applicare le configurazioni.
Problema 125509: Nell'azienda di un cliente che utilizza modelli di VMware SD-WAN Edge di livello base, è possibile che si verifichino flap per BFD, BGP oppure OSPF in base al protocollo di routing utilizzato.

Nelle piattaforme Edge di livello base (510, 520, 540, 610 e 620) su larga scala e abbinate al routing dinamico e/o alla configurazione dell'alta disponibilità, è possibile che si verifichino flap del routing OSPF/BGP quando vengono configurati timer degli intervalli Hello e Dead aggressivi. Inoltre, se il cliente utilizza anche Edge Network Intelligence con l'analisi attivata, aumentano le possibilità che il problema si verifichi.

Soluzione: se si verifica questo problema, la soluzione consiste nel ripristinare i timer degli intervalli predefiniti per OSPF (10, 40) o BGP (60, 180) oppure disabilitare completamente BFD.
Problema 127920: Un probe ICMP collegato a una route statica con un IP secondario come hop successivo può diventare inattivo, anche se l'indirizzo IP secondario è attivo e raggiungibile.

Quando un probe ICMP è collegato a una route statica con un IP secondario come hop successivo, il probe utilizza come origine l'indirizzo IP dell'interfaccia principale anziché l'indirizzo IP secondario. Quando il peer non è in grado di raggiungere l'indirizzo IP primario, il probe ICMP diventa inattivo anche se l'IP secondario è attivo e raggiungibile.

Soluzione: in questo scenario non esiste alcuna soluzione oltre al fatto di non utilizzare un indirizzo IP secondario.
Problema 128379: Una route di riepilogo BGP che un Edge spoke annuncia a un Edge hub tramite un backbone MPLS può entrare in un ciclo di ritiro e annuncio.
La sequenza che causa questo problema è la seguente:
1. L'Edge spoke aggiunge il proprio numero ASN (Autonomous System Number) e annuncia il prefisso di riepilogo BGP al router dell'Edge del cliente (CE). CE aggiunge quindi il proprio ASN e lo annuncia all'Edge hub.
2. L'Edge hub ridistribuisce il prefisso di riepilogo nell'overlay (utilizzando il protocollo di gestione di SD-WAN VCRP) con tutti gli ASN ricevuti. Anche l'Edge hub ridistribuisce i prefissi ricevuti tramite l'uplink.
3. L'Edge spoke riceve lo stesso prefisso di riepilogo tramite VCRP oltre all'ASN di CE. L'Edge spoke ridistribuisce questo prefisso di overlay in BGP. Poiché as-set è abilitato nella configurazione aggregata, BGP raccoglie gli ASN dal prefisso di overlay e li aggiunge ad AS_PATH del prefisso di riepilogo.
4. CE riceve quindi il prefisso di riepilogo con AS_PATH aggiornato. Poiché l'ASN di CE fa parte di AS_PATH aggiornato, CE rifiuta il prefisso di riepilogo e lo ritira dall'Edge hub. L'Edge hub lo ritira quindi dall'Edge spoke su VCRP.
5. L'Edge spoke ripristina il valore normale di AS_PATH del prefisso di riepilogo BGP e lo annuncia di nuovo. Questo ciclo si ripete per sempre.
Soluzione: non esistono soluzioni a questo problema.

Problemi noti di Orchestrator

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 (Monitor) > Trasporto (Transport) > Perdita (Loss) 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: assicurarsi che nel nome dell'azienda non siano presenti spazi iniziali o finali.
Problema 32435:

È consentita una override 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 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: per risolvere il problema, disattivare GRE e quindi riattivarlo.
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: A livello dell'Edge, disattivare GRE e quindi riattivarlo per risolvere il problema.
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 32913:

Dopo l'attivazione 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 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 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.

Soluzione: rimuovere temporaneamente la configurazione del gateway partner dal profilo o dall'Edge in modo che il segmento possa essere modificato da privato a regolare. In alternativa, l'utente può rimuovere il segmento dal profilo e apportare la modifica da tale profilo.
Problema 47713:

Se una regola del criterio di business viene configurata con la VPN cloud disattivata, è necessario ripetere la configurazione del NAT al momento dell'attivazione della VPN cloud.
Problema 47820:

Se una VLAN è configurata con DHCP disattivato a livello del profilo, è presente una override dell’Edge per questa VLAN in tale Edge con DHCP attivato ed è anche disponibile una voce per il campo del server DNS impostata su Nessuno (None), (ovvero nessun indirizzo IP configurato), l'utente non potrà apportare modifiche nella pagina Configura (Configure) > Edge > Dispositivo (Device) e verrà visualizzato il messaggio di errore "Indirizzo IP non valido []" (Invalid IP address []) che non spiega il problema effettivo.
Problema 48085: VMware SD-WAN Orchestrator consente a un'utente di eliminare una VLAN associata a un'interfaccia.

Quando si verifica questo problema, viene visualizzato un messaggio di errore simile a "L'ID VLAN [xx] non può essere rimosso perché è utilizzato dall'Edge [b1-edge1 (GEx-disabled)]".
Problema 51722: In VMware SASE 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 rende tutte le schede di monitoraggio conformi al periodo minimo di conservazione delle statistiche anziché 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 60522: Nell'interfaccia utente di VMware SD-WAN Orchestrator l'utente nota molti messaggi di errore quando tenta di rimuovere un segmento.

Il problema può verificarsi quando si aggiunge un segmento a un profilo e si associa il segmento a più VMware SD-WAN Edge. Quando l'utente tenta di rimuovere il segmento aggiunto dal profilo, vengono visualizzati molti messaggi di errore.

Soluzione: non esistono soluzioni a questo problema.
Problema 82680: Per un cliente che utilizza l'automazione del tunnel MT-GRE, quando un utente disattiva il flag di interconnessione da cloud a cloud (CCI) in un VMware SD-WAN Gateway configurato per l'utilizzo di CCI, è possibile che le voci MT-GRE di Zscaler non vengano eliminate in modo coerente dal portale di Zscaler.

Dopo l'eliminazione di un sito CCI dal Gateway, anche le voci di questo sito dovrebbero essere rimosse. Questo problema è stato riscontrato solo durante l'automazione dei test e non è stato riprodotto manualmente, tuttavia è un possibile rischio.

Soluzione: eliminare manualmente la risorsa da Zscaler prima di riprovare.
Problema 82681: Per un cliente che utilizza l'automazione del tunnel MT-GRE, quando un utente disattiva il flag di interconnessione da cloud a cloud (CCI) in un VMware SD-WAN Gateway configurato per l'utilizzo di CCI e disattiva il flag CCI da un VMware SD-WAN Edge con CCI configurato che utilizza un servizio di sicurezza cloud Zscaler, è possibile che le voci MT-GRE di Zscaler non vengano eliminate dall'Edge o dal portale di Zscaler.

Dopo l'eliminazione di un sito CCI dal Gateway, anche le voci di questo sito dovrebbero essere rimosse. Questo problema è stato riscontrato solo durante l'automazione dei test e non è stato riprodotto manualmente, tuttavia è un possibile rischio.

Soluzione: eliminare manualmente la risorsa da Zscaler prima di riprovare.
Problema 103769: Un operatore può notare che in una distribuzione di VMware SASE Orchestrator su larga scala si verificano problemi di prestazioni, ad esempio il disco viene utilizzato al 100% e Orchestrator non raccoglie più i registri.

Questo problema genera una modifica del comportamento di registrazione per Orchestrator 5.1.0 per cui le cartelle in cui sono archiviati i registri diventano piene e la CPU di Orchestrator raggiunge il 100% di utilizzo. Questo problema genera una modifica del comportamento di registrazione per Orchestrator 5.1.0 per cui le cartelle in cui sono archiviati i registri diventano piene e la CPU di Orchestrator raggiunge il 100% di utilizzo.

Soluzione: un operatore superuser deve accedere a Orchestrator e pulire i registri in sospeso.
Problema 114475: Quando un operatore tenta di aggiornare un VMware SASE Orchestrator dalla versione 4.2.0 alla versione 5.1.0, è possibile che Orchestrator segnali che l'aggiornamento non è riuscito.

Nei registri l'operatore può notare questa voce: Error while initializing CWS Server service Error: Too many connections.

Questo problema viene attivato dal riavvio di MySQL prima dell'installazione di vco-db-schema a causa della mancata impostazione del numero massimo di connessioni di MySQL. Inoltre, mentre Orchestrator segnala che l'installazione non è riuscita, l'installazione è stata completata. È possibile riavviare Orchestrator e tutti i servizi funzioneranno come previsto.
Problema 117699: Un operatore che tenta di aggiornare un VMware SD-WAN Orchestrator 4.2.x alla versione 5.2.0 di SASE Orchestrator può notare che l'aggiornamento non riesce.

L'aggiornamento non riesce e rimane bloccato nella fase "In attesa dell'attività del servizio CWS..." (Waiting for the CWS service up). Questo problema è limitato alle versioni 4.2.x di Orchestrator.

Soluzione: la soluzione di questo problema consiste nell'aggiornare innanzitutto Orchestrator 4.2.x alla versione 4.5.1 e quindi alla versione 5.2.0.0.
Problema 124568: In un VMware SASE Orchestrator distribuito con una topologia di Disaster Recovery (DR), in rari casi l'utente operatore può notare che DR viene arrestato causando una temporanea mancanza di replica tra l'Orchestrator attivo e quello di standby.

Il problema non influisce sull'esperienza utente perché riguarda solo DR. Nella pagina di DR viene indicato uno stato di errore anziché STANDBY_RUNNING.

Soluzione: si tratta di un errore intermittente che verrà risolto automaticamente.
Problema 125006: In un VMware SASE Orchestrator configurato con una topologia di Disaster Recovery (DR), è possibile che si verifichi un problema del database di Orchestrator e che l'Orchestrator di standby passi a uno stato di errore. In rari casi, questo problema può causare la visualizzazione degli Edge e dei gateway come offline nell'interfaccia utente di Orchestrator e l'attivazione degli eventi e degli avvisi corrispondenti.

È previsto che lo stato del database venga ripristinato automaticamente entro alcuni minuti e che gli Orchestrator di DR vengano risincronizzati. Tuttavia, a volte questo stato può superare il periodo di tolleranza e sia gli Edge sia i Gateway iniziano a inviare i loro heartbeat all'Orchestrator di standby anziché all'Orchestrator attivo. Di conseguenza, l'Orchestrator attivo contrassegna gli Edge e i gateway da cui non riceve gli heartbeat come inattivi e attiva eventi e avvisi. Questo problema si verifica esclusivamente sul lato della gestione e non influisce sul traffico di rete.

Soluzione: il modo per evitare questo problema senza una correzione consiste nell'aumentare la proprietà di sistema di Orchestrator che regola la tolleranza per una sincronizzazione non riuscita, ovvero vco.disasterRecovery.transientErrorToleranceSecs, di una quantità adeguata per fornire una finestra di ripristino automatico più lunga.
Problema 125082: Se un utente configura un VMware SD-WAN Edge con un indirizzo IP del server DNS sostituito in una VLAN e quindi modifica un'impostazione dell'interfaccia per il profilo utilizzato dall'Edge, l'indirizzo IP del server DNS non è più presente per la VLAN dell'Edge.

La nuova interfaccia utente non invia il flag di sostituzione all'interno della sezione DHCP e questo fa in modo che eventuali modifiche al profilo attivino una sostituzione della sezione DHCP.

Soluzione: non esistono soluzioni a questo problema.
Problema 125504: Se una route statica viene configurata con un hop successivo come VLAN con indirizzo IPv4/IPv6 a livello di profilo e quindi sostituita a livello di Edge e viene aggiunto un indirizzo IPv4/IPv6 alla VLAN, la route statica non viene contrassegnata come N/D e VMware SASE Orchestrator chiede l'interfaccia in un menu a discesa.

Il comportamento corretto prevede che se una route statica viene configurata con un hop successivo come VLAN con indirizzo IPv4/IPv6, Orchestrator non chieda l'interfaccia e la route venga contrassegnata come N/D.

Soluzione: non esistono soluzioni a questo problema.
Problema 125663: Un utente può configurare lo stesso indirizzo IP IPv4/IPv6 per più interfacce Edge.

VMware SASE Orchestrator consente a un utente di configurare lo stesso IP in più interfacce WAN, LAN o secondarie.

Soluzione: non esistono soluzioni a questo problema oltre al fatto di assicurarsi di non configurare lo stesso indirizzo IP per più interfacce.
Problema 126421: Per i partner che utilizzano un gateway partner, quando si configurano i dettagli di handoff, l'opzione "Utilizza per tunnel privati" (Use for Private Tunnels) è sempre selezionata, indipendentemente dalle operazioni eseguite dall'utente.

Questo non è un problema di visualizzazione perché Orchestrator applica all'handoff del gateway partner la configurazione Utilizza per tunnel privati (Use for Private Tunnels) che può influire sul traffico del cliente che utilizza il gateway partner.

Soluzione: non esistono soluzioni a questo problema in un Orchestrator che include solo la nuova interfaccia utente.
Problema 126425: Quando si esamina la pagina Configura (Configure) > Dispositivo (Device) > Routing e NAT (Routing & NAT) a livello di profilo, l'interruttore On/Off di OSPF non è presente.

L'interruttore On/Off di OSPF non è stato migrato nella nuova interfaccia utente a livello di profilo ed è presente solo a livello di Edge.

Soluzione: non esistono soluzioni a questo problema in un Orchestrator che include solo la nuova interfaccia utente.
Problema 126465: L'interfaccia utente di VMware SASE Orchestrator non applica le modifiche apportate da un utente per creare un cluster Edge.

Se un utente passa alla sezione Configura (Configure) > Edge > Alta disponibilità (High Availability) dell'interfaccia utente, attiva l'alta disponibilità (HA) con tipo Cluster, crea un cluster hub con nome xxxx e salva le modifiche, può notare che dopo il salvataggio l'opzione Cluster non è selezionata nella sezione HA e il cluster hub creato con nome xxxx non è presente.

Soluzione: non esistono soluzioni a questo problema in un Orchestrator che include solo la nuova interfaccia utente.
Problema 126695: Se un utente configura webhook per gli avvisi, quando fa clic sul pulsante "Configura il modello payload" (Configure Payload Template) il menu non viene visualizzato.

Questo problema si verifica quando si configurano webhook nella pagina SD-WAN > Impostazioni (Settings) > Avvisi (Alerts) > Webhook (Webhooks) dell'interfaccia utente. Guardando la console del browser, un utente può notare anche il messaggio seguente: ERROR TypeError: Cannot read properties of undefined (reading 'invalid').

Soluzione: non esistono soluzioni a questo problema in un Orchestrator che include solo la nuova interfaccia utente.
Problema 127152: Gli utenti non possono salvare le interfacce modificate con configurazioni OSPF nell'interfaccia utente di VMware SASE Orchestrator.

A livello di profilo, quando si configura OSPFv2 oppure OSPFv3, la finestra di dialogo Modifica interfaccia (Edit Interface) diventa non valida dopo la modifica dei dati di OSPF.

Soluzione: in un Orchestrator senza una correzione per questo problema, l'utente deve attivare l'autenticazione MD5 e modificare l'ID chiave impostandolo su un numero qualsiasi compreso tra 1 e 255, quindi disattivare l'autenticazione MD5.
Problema 130115: In un VMware SASE Orchestrator configurato con una topologia di Disaster Recovery (DR) nella sezione Cronologia (History) delle pagine di DR dell'Orchestrator attivo e dell'Orchestrator di standby vengono visualizzati dettagli diversi.

A differenza della sezione Cronologia (History) dell'Orchestrator di standby, nella sezione Cronologia (History) dell'Orchestrator attivo l'utente vede righe aggiuntive per uno stato di DR non riuscito che non sono ordinate in base all'ora.