This site will be decommissioned on January 30th 2025. After that date content will be available at techdocs.broadcom.com.

 

VMware SASE 5.1.0 | 18 dicembre 2023

  • VMware SASE™ Orchestrator versione R51010-20231215-GA

  • VMware SD-WAN™ Gateway versione R5103-20230621-GA

  • VMware SD-WAN™ Edge versione R5102-20230310-GA

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

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

Compatibilità

Le istanze di Orchestrator, Gateway ed Edge hub con versione 5.1.0 supportano tutte le istanze di VMware SD-WAN Edge 3.4.0 o versioni successive.

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

Orchestrator

Gateway

Edge

Hub

Filiale/spoke

5.1.0 

5.1.0 

3.4.5 

3.4.5 

5.1.0 

5.1.0 

3.4.6 

3.4.6 

5.1.0 

5.1.0 

5.1.0 

3.4.5 

5.1.0 

5.1.0 

3.4.6 

5.1.0 

5.1.0 

4.2.2 

4.2.2 

4.2.2 

5.1.0 

5.1.0 

4.2.2 

4.2.2 

5.1.0 

5.1.0 

5.1.0 

4.2.2 

5.1.0 

5.1.0 

4.2.2 

5.1.0 

5.1.0 

4.3.0 

4.3.0 

4.3.0 

5.1.0 

5.1.0 

4.3.0 

4.3.0 

5.1.0 

5.1.0 

5.1.0 

4.3.0 

5.1.0 

5.1.0 

4.3.0 

5.1.0 

5.1.0 

4.3.1 

4.3.1 

4.3.1 

5.1.0 

5.1.0 

4.3.1 

4.3.1 

5.1.0 

5.1.0 

5.1.0 

4.3.1 

5.1.0 

5.1.0 

4.3.1 

5.1.0 

5.1.0 

4.5.0 

4.5.0 

4.5.0 

5.1.0 

5.1.0 

4.5.0 

4.5.0 

5.1.0 

5.1.0 

5.1.0 

4.5.0 

5.1.0 

5.1.0 

4.5.0 

5.1.0 

5.1.0 

4.5.1 

4.5.1 

4.5.1 

5.1.0 

5.1.0 

4.5.1 

4.5.1 

5.1.0 

5.1.0 

5.1.0 

4.5.1 

5.1.0 

5.1.0 

4.5.1 

5.1.0 

5.1.0 

5.0.1 

5.0.1 

5.0.1 

5.1.0 

5.1.0 

5.0.1 

5.0.1 

5.1.0 

5.1.0 

5.1.0 

5.0.1 

5.1.0 

5.1.0 

5.0.1 

5.1.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.

Attenzione:

Le versioni 3.2.x, 3.3.x e 3.4.x di VMware SD-WAN hanno raggiunto la fine del supporto.

  • Le versioni 3.2.x e 3.3.x hanno raggiunto la fine del supporto generale (EOGS, End of General Support) il 15 dicembre 2021 e la fine delle linee guida tecniche (EOTG, End of Technical Guidance) il 15 marzo 2022.

  • Le versioni 3.4.x per Orchestrator e Gateway hanno raggiunto la fine del supporto generale (EOGS) il 30 marzo 2022 e la fine delle linee guida tecniche (EOTG) il 30 settembre 2022.

  • Le versioni 3.4.x per l'Edge hanno raggiunto la fine del supporto generale (EOGS) il 31 dicembre 2022 e la fine delle linee guida tecniche (EOTG) il 31 marzo 2023.

  • Per ulteriori informazioni, consultare l'articolo della Knowledge Base: Announcement: End of Support Life for VMware SD-WAN Release 3.x (84151)

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).

Nota:

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

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.1.0.

Orchestrator

Le istanze di Orchestrator che utilizzano la versione 4.0.0 o successiva possono essere aggiornate alla versione 5.1.0. 

Gateway

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

Importante:

quando si distribuisce un nuovo Gateway che utilizza la versione 5.1.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.1.0 o successiva.

Importante:

prima di aggiornare un Gateway alla versione 5.1.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.1.0 o successiva.

Edge

Un Edge può essere aggiornato direttamente alla versione 5.1.0 da qualsiasi versione 3.x o successiva.

Nuove funzionalità di SD-WAN

Hub o Cluster Interconnect

Per la prima volta è possibile interconnettere più Edge hub o cluster hub tramite l'overlay anziché l'underlay e aumentare l'intervallo degli Edge spoke che possono comunicare tra loro. Gli hub possono ora condividere route tra loro consentendo agli Edge spoke connessi a un Edge hub o a un cluster hub di comunicare tramite l'overlay con gli Edge spoke connessi a un altro Edge hub o cluster hub. Gli Edge spoke in una distribuzione multi-hub possono ora sfruttare l'ottimizzazione dinamica del percorso multiplo (DMPO) per migliorare la qualità del traffico garantendo la visibilità completa end-to-end di tutto il traffico nella rete. Hub o Cluster Interconnect offre ai clienti maggiore scalabilità, affidabilità e disponibilità nella propria rete di Edge multi-hub o cluster hub.

Importante:

L'abilitazione di Hub o Cluster Interconnect introduce una modifica fondamentale del protocollo di routing di VMware SD-WAN perché consente ai pacchetti di attraversare più hop nella rete. Anche se questa modifica è stata testata nelle topologie rappresentative, non è possibile testarla per tutti gli scenari di routing che possono verificarsi quando si apporta tale modifica consentendo la distribuzione di route distanti. Di conseguenza, VMware rilascia questa funzionalità come Early Access e monitorerà attentamente le distribuzioni in cui è abilitata per rilevare eventuali comportamenti di routing imprevisti.

Nuova interfaccia utente di Orchestrator

La versione 5.1.0 di Orchestrator include l'implementazione completa della nuova interfaccia utente che è stata introdotta per la prima volta nella versione 4.0.0. La nuova interfaccia utente semplifica l'utilizzo e offre un aspetto coerente in tutti i servizi VMware SASE. La nuova interfaccia utente include inoltre la Guida del prodotto integrata per indirizzare gli utenti alla documentazione pertinente e ad altro materiale utile per l'utilizzo del servizio SD-WAN.

La nuova interfaccia utente è l'interfaccia predefinita nella versione 5.1.0 di Orchestrator anche se l'utente ha comunque la possibilità di passare all'interfaccia utente di Orchestrator classica quando utilizza SD-WAN.

Nota:

L'interfaccia utente classica verrà deprecata nella prossima versione secondaria di VMware SASE Orchestrator. È quindi consigliabile che i clienti acquisiscano familiarità con la nuova interfaccia utente di Orchestrator utilizzandola.

Visibilità flusso

Nelle versioni precedenti, l'interfaccia utente di Orchestrator visualizza solo singolarmente le informazioni e le statistiche dei flussi aggregati in Applicazione (Application), Origine (Source) o Destinazione (Destination) e non combina tutte queste informazioni in un'unica schermata per fornire una singola visualizzazione end-to-end. Di conseguenza, il monitoraggio, la risoluzione dei problemi e la creazione di report sono ostacolati dalla mancanza di visibilità dettagliata di ogni flusso.

Nella versione 5.1.0, la nuova interfaccia utente di Orchestrator include una scheda "Flussi" (Flows) in cui vengono visualizzati i dati consolidati per ogni flusso di traffico. L'interfaccia utente di Orchestrator visualizza i parametri chiave di ogni flusso in una singola visualizzazione. La funzionalità Visibilità flusso (Flow Visibility) consente inoltre ai clienti di visualizzare i dati cronologici del flusso, filtrare i dati in base a determinati parametri e scaricare statistiche del flusso end-to-end.

Voci DNS locali

La versione 5.1.0 supporta le voci DNS locali nell'Edge per fare in modo che il traffico punti a domini specifici. Quando è configurato il DNS locale, l'Edge esegue una ricerca nel file host locale prima di tentare di risolvere un dominio con un server DNS.

Test automatico dell'accensione (POST) per Orchestrator, Gateway ed Edge

La versione 5.1.0 include miglioramenti della protezione e della visibilità del dispositivo grazie a un test automatico dell'accensione (POST). Il POST è un processo eseguito da una routine software richiamata automaticamente subito dopo l'accensione o il riavvio di un dispositivo. Il processo POST include:

  • Verifica dell'integrità del software.

  • Verifica del test della risposta nota degli algoritmi del modulo crittografico.

  • Test dell'origine dell'entropia (noise).

  • Visualizzazione dei risultati del processo POST: Riuscito/Non riuscito. Il sistema continuerà ad attivare le altre applicazioni solo se il processo POST viene eseguito correttamente. Se il processo POST non viene eseguito correttamente, vengono visualizzati messaggi di errore nei punti in cui il test non è riuscito e la sequenza di avvio del sistema viene interrotta.

Per gli Orchestrator e i Gateway questa funzionalità è disponibile solo in una distribuzione greenfield. Negli Edge questa funzionalità non è attivata per impostazione predefinita e un utente deve attivarla tramite l'interfaccia utente di Orchestrator.

Nuovi miglioramenti di SD-WAN

Sincronizzazione delle route locali ad alta disponibilità (HA) e riavvio normale di BGP

Per un sito distribuito in una topologia ad alta disponibilità in cui viene utilizzato anche BGP oppure OSPF, un failover HA può essere lento e comportare l'interruzione del traffico del cliente a causa di un'elevata perdita di pacchetti quando l'Edge di standby sincronizza le route. Per garantire failover HA più rapidi e che comportino meno interruzioni, VMware ha introdotto due miglioramenti: sincronizzazione delle route locali HA e riavvio normale di BGP.

La sincronizzazione delle route locali HA consente di sincronizzare automaticamente le route tra l'Edge attivo e l'Edge di standby e utilizza queste route per l'inoltro nell'Edge attivo, assicurando inoltre che la tabella di route sia immediatamente disponibile dopo un failover di HA.

Il riavvio normale di BGP consente riavvii dell'Edge e failover HA più rapidi facendo in modo che i dispositivi BGP adiacenti partecipino al riavvio per garantire che non si verifichino modifiche delle route nella rete per tutta la durata del riavvio. Senza il riavvio normale di BGP, l'Edge peer elimina tutte le route quando la sessione TCP tra i peer BGP termina e queste route devono essere rigenerate dopo il riavvio dell'Edge o il failover di HA. Il riavvio normale di BGP modifica questo comportamento facendo in modo che gli Edge peer non eliminino le route se viene stabilita una nuova sessione entro un determinato tempo di riavvio configurabile.

Importante:

Per ottenere prestazioni migliori, è necessario attivare anche il calcolo dei costi dinamico (DCC) nell'azienda del cliente. Quando DCC è attivato, le decisioni relative alle preferenze e agli annunci sono locali per l'Edge e l'Edge viene sincronizzato da attivo a standby non appena acquisisce le route dal processo di routing. Per ulteriori informazioni su DCC, vedere Panoramica di VMware SD-WAN routing e Configurazione del calcolo dei costi distribuito.

Nota:

La sincronizzazione delle route locali HA è disponibile solo per le aziende che utilizzano BGP. La sincronizzazione delle route locali HA nelle aziende in cui viene utilizzato OSPF sarà disponibile in una versione futura.

Autenticazione RADIUS in un'interfaccia commutata

I clienti possono utilizzare l'autenticazione RADIUS tramite il protocollo 802.1x nelle porte commutate mentre prima potevano utilizzarla solo nelle porte instradate. L'autenticazione RADIUS della porta commutata viene configurata tramite una VLAN associata a tale porta. Questo miglioramento è utile per i siti dei clienti in cui non sono disponibili altri router per espandere l'accesso locale, ma che richiedono l'autenticazione sicura dei dispositivi tramite il protocollo 802.1x.

Bypass dell'indirizzo MAC

Nelle interfacce instradate i clienti possono ora controllare gli indirizzi MAC in base a un elenco in un server RADIUS per ignorare l'autenticazione 802.1x per i dispositivi LAN che non la supportano. Il bypass dell'indirizzo MAC semplifica le operazioni IT, consente di risparmiare tempo e migliora la scalabilità perché i clienti non devono più configurare manualmente ogni indirizzo MAC che può richiedere l'autenticazione.

Importante:

La funzionalità MAB basata su RADIUS non è supportata per le VLAN e non può quindi essere utilizzata per le porte commutate. La funzionalità MAB basata su RADIUS è supportata solo per le interfacce instradate.

Modifiche della configurazione che causano il riavvio dell'Edge

Diverse modifiche della configurazione dell'Edge che in precedenza attivavano un riavvio del servizio Edge non lo attivano più nella versione 5.1.0. In particolare, le modifiche della configurazione dell'interfaccia dell'Edge utilizzate di frequente come la modifica di un indirizzo IP della LAN dell'Edge in un'interfaccia commutata o la modifica di un IP CIDR, di un prefisso CIDR o di un IP fisso non causano più un riavvio dell'Edge. Per un elenco completo, consultare l'articolo della Knowledge Base Modifiche della configurazione di VMware SD-WAN Edge che possono attivare un riavvio del servizio Edge (60247).

SNMP

La versione 5.1.0 include i seguenti miglioramenti di SNMP:

  • SNMPv2: supporto per stringhe della community aggiuntive e contatori a 64 bit.

  • SNMPv3: supporto per SHA2, nome utente e password aggiuntivi, autenticazione separata e chiavi private.

  • In MIB è stata aggiunta la seguente telemetria:

    • UUID del link alla mappatura dei nomi dell'interfaccia.

    • Larghezza di banda/capacità del link.

    • Velocità effettiva del link.

Aumento della capacità del flusso degli Edge 2000, 3800 e 3810

Nei modelli di Edge 2000, 3800 e 3810 è stata aumentata la capacità massima del flusso da 1,9 M di flussi a 3,8 M di flussi quando si utilizza il software della versione 5.1.0 dell'Edge.

Nota:

Questa modifica non influisce sul modello 3400 dell'Edge e la capacità massima del flusso di questo modello rimane 1,9 M.

Acquisizione di pacchetti (PCAP) nei Gateway

Un utente può avviare un PCAP in un Gateway tramite l'interfaccia utente di Orchestrator. È possibile acquisire fino a 120 secondi del traffico del Gateway con la possibilità di definire filtri semplici o complessi per garantire che l'utente acquisisca solo ciò di cui ha bisogno. Questa funzionalità è accessibile per gli utenti come segue:

  • Gli amministratori partner possono avviare un PCAP solo nei propri Gateway partner.

  • Gli operatori possono avviare un PCAP nei Gateway partner e nei Gateway ospitati.

Autorità di certificazione (CA) esterna

Alla funzionalità CA esterna sono state aggiunte due nuove modalità pronte per l'API:

  • Modalità manuale (Manual Mode): fornisce supporto per qualsiasi autorità di certificazione e offre flessibilità e controllo consentendo all'utente di eseguire manualmente ogni passaggio del processo di certificazione.

  • Modalità asincrona (Asynchronous Mode): offre supporto per qualsiasi autorità di certificazione con la possibilità di eseguire lo script dei passaggi manuali e automatizzare le attività ricorrenti.

Tunnel di destinazione non SD-WAN (NSD) e servizio di sicurezza cloud (CSS)

Nelle versioni precedenti di SD-WAN, i tunnel per NSD o CSS vengono creati solo quando il traffico passa attraverso una NSD o un CSS e persistono finché il traffico continua a passare. Quando il traffico manca per un determinato periodo di tempo, il tunnel viene eliminato e deve essere rigenerato al successivo passaggio del traffico in una delle due direzioni causando la latenza per tale traffico mentre il tunnel viene ristabilito. A partire dalla versione 5.1.0, tutti i tunnel NSD e CSS vengono attivati e stabiliti nel momento in cui uno dei servizi viene inizialmente configurato e persistono, indipendentemente dal fatto che il traffico passi o meno, per un periodo di tempo qualsiasi, migliorando l'esperienza utente per entrambi i servizi.

Note importanti

Stringa community estesa BGP aggiunta ai prefissi BGP

Le route BGP interne al cluster vengono contrassegnate automaticamente con una community BGP interna che viene aggiunta alle community BGP esistenti da ogni Edge. Questa stringa della community aggiuntiva combina 1 byte per il numero di hop e 3 byte derivati dall'ID logico dell'Edge. Di conseguenza, i clienti che utilizzano il peering BGP sul lato LAN spoke/hub non devono filtrare i prefissi BGP annunciati dagli Edge con la nuova stringa delle community di BGP.

Timeout di Dead Peer Detection (DPD) per le destinazioni non SD-WAN

Nella versione 5.1.0 sono state apportate modifiche importanti al timeout di Dead Peer Detection (DPD) per le destinazioni non SD-WAN. Nelle versioni precedenti, il valore predefinito del timeout di DPD era 20 secondi e un utente poteva disattivare DPD configurando il timer del timeout di DPD su 0 secondi. Quando VMware SD-WAN è passato al toolkit IPSec QuickSec, il timeout di DPD è stato modificato nel modo seguente:

  • Intervallo probe: esponenziale (0,5 secondi, 1 secondo, 2 secondi, 4 secondi, 8 secondi, 16 secondi).

  • Intervallo DPD minimo predefinito: 47,5 secondi (QuickSec attende 16 secondi dopo l'ultimo tentativo. Quindi 0,5+1+2+4+8+16+16 = 47,5).

  • Intervallo DPD minimo predefinito + Timeout DPD (secondi): 67,5 secondi.

In seguito alle modifiche indicate in precedenza, un utente non può disattivare DPD configurando il timer del timeout di DPD su 0 secondi. Il valore del timeout di DPD in secondi verrà aggiunto al valore minimo predefinito di 47,5 secondi. Pertanto, anche se un utente configura DPD su 0 secondi, in realtà il DPD è 47,5.

Funzionalità che devono essere configurate in Orchestrator classico

Per la versione 5.1.0, VMware rende la nuova interfaccia utente l'interfaccia predefinita per Orchestrator riconoscendo che un utente può eseguire tutte le attività di monitoraggio e configurazione in tale interfaccia. Alcune funzionalità non sono tuttavia completamente integrate nella nuova interfaccia utente:

  • Secure Access: impostazioni di Edge e profilo

  • Zscaler: impostazioni di Edge e profilo

  • TACACS: impostazioni dell'Edge e pagina Servizi di rete (Network Services)

  • Impostazioni partner (Partner Settings): pagina Partner

Per configurare le funzionalità precedenti, un cliente può selezionare l'opzione Apri Orchestrator classico (Open Classic Orchestrator) nella parte superiore della schermata di Orchestrator. Verrà aperta una nuova scheda del browser con l'interfaccia utente classica.


Queste funzionalità saranno completamente integrate nella nuova interfaccia utente in una versione successiva del software di Orchestrator.

La combinazione di Edge con e senza supporto Wi-Fi in modalità ad alta disponibilità non è supportata 

A partire dal 2021, VMware SD-WAN ha introdotto modelli di Edge che non includono un modulo Wi-Fi, ovvero i modelli di Edge 510N, 610N, 620N, 640N e 680N. Anche se questi modelli sembrano identici alle controparti con supporto Wi-Fi, ad eccezione del Wi-Fi, la distribuzione di un Edge con supporto Wi-Fi e di un Edge senza supporto Wi-Fi dello stesso modello (ad esempio, un Edge 640 e un Edge 640N) come coppia ad alta disponibilità non è supportata. I clienti devono assicurarsi che gli Edge distribuiti come coppia in alta disponibilità siano dello stesso tipo: entrambi con o senza supporto Wi-Fi.

Modifica del carattere di delimitazione della configurazione del filtro BGPv4 per anteporre AS-PATH

Nelle versioni 3.x, la configurazione del filtro BGPv4 di VMware SD-WAN per l'anteposizione di AS-PATH supportava sia le virgole che gli spazi come caratteri di delimitazione. Tuttavia, a partire dalla versione 4.0.0, VMware SD-WAN supporterà solo gli spazi come carattere di delimitazione in una configurazione per l'anteposizione di AS-Path. I clienti che effettuano l'aggiornamento dalla versione 3.x alla versione 4.x o 5.x devono modificare le configurazioni dell'anteposizione di AS-PATH per sostituire le virgole con spazi prima di eseguire l'aggiornamento per evitare una selezione errata della route migliore di BGP.

Tempo di aggiornamento esteso per i modelli Edge 3x00

Gli aggiornamenti a questa versione richiederanno più tempo del normale (3-5 minuti) nei modelli di Edge 3x00 (ovvero 3400, 3800 e 3810) se l'aggiornamento dell'Edge viene eseguito direttamente dalla versione 4.0.0, 4.0.1 o 4.2.0. Ciò è dovuto a un aggiornamento del firmware che risolve il problema 53676. Se un Edge 3400 o 3800 viene aggiornato alla versione 5.1.0 da qualsiasi altra versione dell'Edge, l'aggiornamento dell'Edge verrà eseguito come previsto. Per ulteriori informazioni, consultare il Problema 53676 risolto nelle rispettive note di rilascio.

Limitazione con BGP su IPSec nell'Edge e nel Gateway e automazione della rete WAN virtuale di Azure

La funzionalità BGP su IPSec nell'Edge e nel Gateway non è compatibile con l'automazione della rete WAN virtuale di Azure dall'Edge o dal Gateway. Quando si automatizza la connettività da un Edge o un Gateway a una vWAN di Azure, sono supportate solo le route statiche.

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.1.0 è localizzato nelle seguenti lingue: 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.0.0

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

Il registro delle modifiche completo dell'API è disponibile per il download all'indirizzo developer.vmware.com (vedere "VMware SD-WAN Orchestrator API v1").

Le seguenti modifiche potrebbero richiedere un'azione da parte degli sviluppatori:

  • Problema 66795: questa correzione introduce un meccanismo per cui un token API sarà valido e accettato da Orchestrator per gli utenti non nativi solo se hanno stato abilitato e se l'utente SSO è attivo nel rispettivo provider di identità. Se un utente non nativo diventa inattivo (in altre parole, viene eliminato nel provider di identità o non dispone di un token di aggiornamento valido), tutti i token API per questo utente vengono revocati tramite un processo back-end.

Nota:

  • I token emessi per conto di un utente abilitato per SSO prima di questa correzione sono soggetti al comportamento precedente per cui Orchestrator continuerà a utilizzarli finché non scadono.

  • Gli utenti SSO dei provider di identità che non supportano token di aggiornamento o endpoint di introspezione non potranno utilizzare la funzionalità di autenticazione basata su token. 

  • Problema 87878: modifica del payload della risposta vcoInventory/getPendingInventory. Sono stati rimossi i campi token, vcoInstanceLogicalId, vcoUrl, edgeMappingId, enterpriseId, enterpriseProxyId, uuid, mac, imei e owner. Non vengono utilizzati nel front-end e questa modifica non influisce sull'interfaccia utente perché questi campi non erano utilizzati nell'interfaccia utente. Questa API è pensata per essere utilizzata per ottenere un elenco di Edge disponibili per ZTP e questi campi non sono obbligatori per l'assegnazione dell'Edge (solo serialNumber è obbligatorio). Pertanto, se un cliente utilizza questa API per ZTP e dispone di una convalida del payload rigida che può influire negativamente (in base all'implementazione in uso), in generale, le informazioni restituite sono sufficienti per il flusso ZTP corretto.

  • Problema 84303: è stata aggiunta una convalida per l'attributo maxHop del router adiacente BGP per impedire la configurazione di un valore maxHop minore di 2 quando è presente un localIP del router adiacente. In precedenza, la configurazione di un valore maxHop pari a 1 era consentita indipendentemente dalla presenza o meno di un localIP del router adiacente. Ora, in base alla modifica apportata, ogni volta che è presente un localIP del router adiacente, il valore minimo di maxHop consentito è 2 e se un utente tenta di configurare un valore di maxHop minore di 2, viene visualizzato il messaggio di errore Invalid MaxHop for Neighbor. MaxHop value ranges from 2 to 255 when localIp is present. Per gestire la configurazione esistente, verrà scritta una patch.

  • Problema 84114: la migrazione dei dispositivi client da MySQL a ClickHouse elimina il campo clientDeviceId. Poiché non è stato identificato un client esterno utilizzando il campo clientDeviceId, l'impatto dovrebbe essere minimo. L'unico client che utilizza l'endpoint dei dispositivi client con clientDeviceId è l'interfaccia utente classica di Orchestrator. L'interfaccia utente è stata migliorata per aggiornare o recuperare i record in ClickHouse utilizzando logicalId o la combinazione di ipAddress e macAddress. I client esterni devono fare la stessa cosa quando utilizzano l'endpoint del dispositivo client per aggiornare il nome host o quando recuperano dispositivi specifici in base all'ID.

Modifiche di VMware SASE Orchestrator API v2

  • Problema 98750: il campo lastContact nel record dell'Edge restituito dalle API correlate all'Edge è obsoleto e non deve più essere utilizzato. Per determinare lo stato effettivo dell'Edge, deve invece essere utilizzato solo il campo edgeState della risposta. Se un codice del client utilizza lastContact e non può sostituirlo con edgeState, l'API v1 fornisce comunque un campo lastContact nella risposta che può essere utilizzato come compromesso, anche se non è consigliato.

  • Problema 30901: in seguito all'introduzione della funzionalità Visibilità flusso nella versione 5.1.0, la clausola groupBy obbligatoria non è più necessaria per flowstats. Se la clausola groupBy non viene menzionata, per impostazione predefinita l'endpoint dell'API sta eseguendo query o chiamate per l'endpoint dell'API Visibilità flusso che a sua volta viene risolto per tutti i resolver come applicazione, dispositivi client e così via. Tuttavia, questo è applicabile solo per la chiamata dell'API delle metriche delle statistiche del flusso e l'API della serie delle statistiche del flusso rimane invariata senza alcuna modifica.

  • Problema 95089: il modulo di limitazione della velocità dell'APIv2 non applicava lo stesso criterio predefinito applicato dalla funzionalità di limitazione della velocità dell'API del portale, a differenza di quanto previsto. Una modifica di questa versione rende effettivo tale criterio per l'APIv2. Gli utenti devono consultare le procedure consigliate per evitare di attivare la funzionalità di limitazione della velocità e di dover gestire le risposte quando viene attivata la limitazione della velocità.

Nota sulla documentazione per gli sviluppatori

La documentazione dell'API di VMware SASE/SD-WAN è sempre stata disponibile in VMware {code} all'indirizzo code.vmware.com. VMware {code} è stato recentemente migrato in un nuovo dominio, developer.vmware.com. In seguito alla migrazione, alcuni link permanenti a pagine specifiche precedentemente ospitate in code.vmware.com potrebbero non funzionare più come previsto.

Oltre alla documentazione migrata, VMware continuerà a utilizzare il portale della documentazione per gli sviluppatori disponibile all'indirizzo https://developer.vmware.com/apis, in cui ora si trova tutta la documentazione dell'API di VMware SASE/SD-WAN.

Cronologia delle versioni del documento

18 dicembre 2023. Ventiquattresima edizione.

  • Aggiunta una nuova build di rollup di Orchestrator R51010-20231215-GA alla sezione Problemi risolti di Orchestrator. Questa è la decima build di rollup di Orchestrator ed è la nuova build GA di Orchestrator predefinita per la versione 5.1.0.

  • La build di Orchestrator R51010-20231215-GA include le correzioni per i problemi 117941, 125006, 128310, 129239 e 131789, che sono tutti documentati in questa sezione.

9 ottobre 2023. Ventitreesima edizione.

  • Aggiunta una nuova build di rollup di Orchestrator R5109-20231003-GA alla sezione Problemi risolti di Orchestrator. Questa è la nona build di rollup di Orchestrator ed è la nuova build GA di Orchestrator predefinita per la versione 5.1.0.

  • La build R5109-20231003-GA di Orchestrator include le correzioni per i problemi 119938 e 128310, ciascuno dei quali è documentato in questa sezione.

  • Aggiunto il problema non risolto 105933 alla sezione Problemi noti di Edge/Gateway.

20 settembre 2023. Ventiduesima edizione.

  • Aggiunta una nuova build di rollup di Orchestrator R5108-20230916-GA alla sezione Problemi risolti di Orchestrator. Questa è l'ottava build di rollup di Orchestrator ed è la nuova build GA di Orchestrator predefinita per la versione 5.1.0.

  • La build R5108-20230916-GA di Orchestrator include le correzioni per i problemi 94610, 104775, 105580, 106191, 115981, 116531, 117822, 118728, 121085, 121441, 121469 e 124778, ciascuno dei quali è documentato in questa sezione.

  • Spostato il problema non risolto 62701 da Problemi noti di Edge/Gateway alla sezione Problemi risolti di Edge/Gateway relativa alla build GA originale R5100-20221204-GA. Questa azione avrebbe dovuto essere eseguita nella prima edizione di queste Note di rilascio.

  • Aggiunti i problemi non risolti 115136 e 117037 alla sezione Problemi noti di Edge/Gateway.

  • Cronologia delle versioni del documento riorganizzata per la lettura dalle voci più recenti alle voci meno recenti per migliorare l'esperienza utente.

22 agosto 2023. Ventunesima edizione.

3 agosto 2023. Ventesima edizione.

26 luglio 2023. Diciannovesima edizione.

  • Aggiunto il problema risolto 103708 alla sezione Problemi risolti di Edge/Gateway per la seconda build di rollup dell'Edge R5102-20230310-GA. Questo problema è stato omesso per errore nella decima edizione delle Note di rilascio della versione 5.0.1.

23 luglio 2023. Diciottesima edizione.

  • Aggiunta una nuova build di rollup di Orchestrator R5107-20230722-GA alla sezione Problemi risolti di Orchestrator. Questa è la settima build di rollup di Orchestrator ed è la nuova build GA di Orchestrator predefinita per la versione 5.1.0.

  • La build di Orchestrator R5107-20230722-GA include la correzione del problema 122271, documentata in questa sezione.

  • Il problema irrisolto 53359 è stato rimosso dalla sezione Problemi noti di Edge/Gateway poiché è stato risolto nella versione 4.3.0.

  • Aggiunti i problemi non risolti 103708 e 117775 alla sezione Problemi noti di Edge/Gateway.

15 luglio 2023. Diciassettesima edizione.

6 luglio 2023. Sedicesima edizione.

  • Aggiunta una nuova build di rollup di Orchestrator R5106-20230705-GA alla sezione Problemi risolti di Orchestrator. Questa è la sesta build di rollup di Orchestrator ed è la nuova build GA di Orchestrator predefinita per la versione 5.1.0.

  • La build di Orchestrator R5106-20230705-GA include le correzioni per i problemi 84772, 115411, 115433, 116633, 117772, 117988, 117993, 118074, 118544, 118733, 119733 e 120606, tutti documentati in questa sezione.

  • Aggiunto il problema 95565 alla sezione Problemi risolti di Edge/Gateway per la build originale R5100-20221204-GA. Questo problema è stato omesso per errore nelle note di rilascio della versione 5.1.0.

  • Aggiunto il problema non risolto 107994 alla sezione Problemi noti di Edge/Gateway.

  • Aggiunto il problema non risolto 112826 alla sezione Problemi noti di Orchestrator.

23 giugno 2023. Quindicesima edizione.

  • Aggiunta una nuova build di rollup R5103-20230621-GA del Gateway alla sezione Problemi risolti di Edge/Gateway. Questa è la terza build di rollup del Gateway e della nuova build GA di Orchestrator per la versione 5.1.0.

  • La build del gateway R5103-20230621-GA include le correzioni per i problemi 82808, 100172, 101536, 104619, 107309, 108473, 111646, 111888, 111924, 112016, 112017, 112019, 112020, 112800, 114052, 114084, 114282, 114932, 115604, 115692 e #116182, documentati tutti in questa sezione.

  • Aggiunti i problemi non risolti 115148 e 119033 alla sezione Problemi noti di Edge/Gateway.

13 giugno 2023. Quattordicesima edizione.

  • Aggiunta una nuova build di rollup di Orchestrator R5105-20230611-GA alla sezione Problemi risolti di Orchestrator. Questa è la quinta build di rollup di Orchestrator ed è la nuova build GA di Orchestrator per la versione 5.1.0.

  • La build di Orchestrator R5105-20230611-GA include le correzioni per i problemi 87089, 105861, 106295, 107180, 107766, 110826, 111957, 112044, 112333, 112451, 112500, 112605, 112809, 112906, 112912, 112992, 113209, 113254, 113366, 113375, 113963, 114240, 114291, 114564, 114602, 114912, 115307, 115439, 115624, 115653, 115719, 116141, 116523, 116770, 116790, 116976, 117527, 117800 e 118071.

  • Aggiunti i problemi non risolti seguenti alla sezione Problemi noti di Edge/Gateway: 82808, 107309, 111924, 112016, 112017, 112019, 114084, 114282, 115692 e 116182. Tutti questi problemi influiscono sul VMware SD-WAN Gateway.

11 maggio 2023. Tredicesima edizione.

  • Aggiunti i problemi non risolti seguenti alla sezione Problemi noti di Edge/Gateway: 108473, 111646, 111888, 112020, 112800, 114052 e 114932. Tutti questi problemi influiscono sul VMware SD-WAN Gateway.

27 aprile 2023. Dodicesima edizione.

  • Aggiunta una nuova build di rollup di Orchestrator R5104-20230426-GA alla sezione Problemi risolti di Orchestrator. Si tratta della quarta build di rollup di Orchestrator per la versione 5.1.0.

  • La build di Orchestrator R5104-20230426-GA include le correzioni per i problemi 95631, 104785, 106327, 106929, 107071, 107349, 107980, 108072, 108363, 109284, 109300, 109532, 109533, 109715, 109788, 109836, 109911, 110094, 110330, 110946, 111104, 111407, 111444, 111665, 111934, 111944, 111946, 112094, 112201, 112224, 112437, 112458, 112885 e 114475. Ogni problema è documentato in questa sezione.

  • Due dei ticket risolti, 106907 e 106929 erano originariamente contrassegnati come corretti nella versione 5.1.0.2 di Orchestrator. Tuttavia, le correzioni non erano complete nella versione 5.1.0.2 e i problemi sono stati risolti completamente solo nella versione 5.1.0.4 di Orchestrator. Di conseguenza, questi ticket sono stati rimossi dalla sezione Problemi risolti di Orchestrator versione 5.1.0.2 e sono stati spostati nella sezione relativa alla versione 5.1.0.4.

  • Aggiunto il problema 94612 alla sezione Problemi risolti di Edge/Gateway per la build originale R5100-20221204-GA. Questo problema è stato omesso per errore nelle note di rilascio della versione 5.1.0.

  • Aggiornata la sezione Compatibilità per indicare che tutte le versioni 3.x hanno raggiunto la fine del ciclo di vita del servizio (EOSL). Aggiornata inoltre la sezione relativa alla versione 4.x per indicare che le versioni 4.2.x di Orchestrator e Gateway hanno raggiunto la fine del ciclo di vita del servizio (EOSL).

  • Aggiunta una nota in Note importanti intitolata Stringa community estesa BGP aggiunta ai prefissi BGP. Per ulteriori dettagli, vedere la nota.

15 marzo 2023. Undicesima edizione.

  • Aggiunta una nuova build di rollup di Orchestrator R5103-20230315-GA nella sezione Problemi risolti di Orchestrator. Si tratta della terza build di rollup di Orchestrator per la versione 5.1.0.

  • La build di Orchestrator R5103-20230315-GA include le correzioni per i problemi 107587, 107725, 108533, 108833 e 109064. Ogni problema è documentato in questa sezione. R5104-202304xx-GA

14 marzo 2023. Decima edizione.

  • Aggiunta una nuova build di rollup R5102-20230310-GA di Edge e Gateway alla sezione Problemi risolti di Edge/Gateway. Questa è la seconda build di rollup di Edge/Gateway ed è la nuova build GA di Edge e Gateway per la versione 5.1.0.

  • La build R5102-20230310-GA di Edge e Gateway include le correzioni per i problemi 98782, 104141, 105744 e 106587 che sono tutti documentati in questa sezione.

6 marzo 2023. Nona edizione.

  • Nella sezione Nuovi miglioramenti di SD-WAN la voce Aumento della capacità del flusso di Edge 3x00 è stata modificata. La voce originale escludeva l'Edge 2000 e includeva erroneamente l'Edge 3400. La voce modificata ora è:

    • Aumento della capacità del flusso degli Edge 2000, 3800 e 3810

    • Nei modelli di Edge 2000, 3800 e 3810 è stata aumentata la capacità massima del flusso da 1,9 M di flussi a 3,8 M di flussi quando si utilizza il software della versione 5.1.0 dell'Edge.

    • È stata aggiunta una nota per chiarire che il modello 3400 dell'Edge non è interessato da questa modifica e che quindi la capacità massima del flusso di questo modello rimane 1,9 M.

28 febbraio 2023. Ottava edizione.

  • Build di rollup di Orchestrator R5102-20230216-GA sostituita da R5102-20230222-GA. La nuova build di Orchestrator risolve un problema di aggiornamento rilevato dal team di VMware Operations durante l'aggiornamento di un Orchestrator alla build R5102-20230216-GA. Il problema di aggiornamento era causato dalla mancata corrispondenza della versione nel manifesto del pacchetto di aggiornamento.

  • La nuova build include anche le correzioni per i problemi seguenti: 106907, 108074 e 108309.

17 febbraio 2023. Settima edizione.

  • Aggiunta una nuova build di rollup di Orchestrator R5102-20230216-GA nella sezione Problemi risolti di Orchestrator. Si tratta della seconda build di rollup di Orchestrator per la versione 5.1.0.

  • La build di Orchestrator R5102-20230216-GA include le correzioni per i problemi 40584, 105610, 106159, 106242, 106592, 106806, 106929, 107410, 107637 e 107885. Ogni problema è documentato in questa sezione.

  • Aggiunto il problema 89725 alla sezione Problemi risolti di Edge/Gateway per la build originale R5100-20221204-GA. Questo problema è stato omesso per errore nelle note di rilascio della versione 5.1.0.

  • Rimosso il problema 39659 dalla sezione Problemi noti di Edge/Gateway perché si tratta di un duplicato di un altro ticket, 39501, che è stato risolto nella versione 4.3.0.

29 gennaio 2023. Sesta edizione.

  • Nella sezione Compatibilità è stata rivista la nota importante relativa alla fine del supporto per la versione 4.2.x ed è stata aggiunta la versione 4.3.x per includere le date appena riviste per il software SD-WAN Edge.

  • Nella sezione Nuovi miglioramenti di SD-WAN è stato aggiunto il miglioramento Tunnel della destinazione non SD-WAN (NSD) e del servizio di sicurezza cloud (CSS), che per errore era stato omesso nella prima edizione delle note di rilascio.

  • Nella sezione Note importanti è stata aggiunta una nota relativa al timeout di Dead Peer Detection (DPD) per le destinazioni non SD-WAN. Questa nota illustra le modifiche nel comportamento di DPD in seguito al passaggio del software VMware SD-WAN al toolkit IPSec QuickSec. La nota era stata omessa per errore nella prima edizione delle note di rilascio.

20 gennaio 2023. Quinta edizione.

  • Aggiunta una nuova build di rollup R5101-20230112-GA del Gateway alla sezione Problemi risolti di Edge/Gateway. Si tratta della prima build di rollup del Gateway e della nuova build GA di Orchestrator per la versione 5.1.0.

  • La build R5101-20230112-GA del Gateway include le correzioni per i problemi 97272 e 104487 che sono entrambi documentati in questa sezione.

  • Modificato il testo della funzionalità avanzata MAC Address Bypass (MAB) per chiarire che questa funzionalità non è supportata per le VLAN e pertanto non può essere utilizzata per le porte commutate che dipendono da una VLAN per l'autenticazione 802.1x. Pertanto, la funzionalità MAB è supportata solo nelle interfacce instradate a partire dalla versione 5.1.0.

12 gennaio 2023. Quarta edizione.

  • Aggiunta la descrizione di due miglioramenti della versione 5.1.0: Sincronizzazione delle route locali HA e riavvio normale di BGP.

5 gennaio 2023. Terza edizione.

  • Aggiunta una nuova build di rollup di Orchestrator R5101-20221220-GA nella sezione Problemi risolti di Orchestrator. Questa è la prima build di rollup di Orchestrator per la versione 5.1.0.

  • La build di Orchestrator R5101-20221220-GA include le correzioni per i problemi 100133, 101835, 102806 e 103622 che sono tutti documentati in questa sezione.

15 dicembre 2022. Seconda edizione.

  • Rimosso il problema non risolto 39134 dalla sezione Problemi noti di Edge/Gateway perché gli ingegneri hanno rilevato che è stato risolto. Questo ticket era già stato aggiunto erroneamente nella sezione Problemi risolti di Edge/Gateway nella prima edizione delle note di rilascio della versione 5.1.0.

8 dicembre 2022. Prima edizione.

Problemi risolti di Edge/Gateway

Risolto nella versione R5103-20230621-GA del Gateway

La build R5103-20230621-GA del Gateway è stata rilasciata il 23-06-2023 ed è il terzo rollup del Gateway per la versione 5.1.0.

Questa build di rollup del Gateway risolve i seguenti problemi critici presenti a partire dalla seconda build di rollup del Gateway, ovvero dalla versione R5102-20230310-GA.

  • Problema 82808 risolto: In un VMware SD-WAN Edge che utilizza un servizio di sicurezza cloud (CSS) e in cui è attivato Controllo integrità L7 (L7 Health Check), è possibile che il cliente noti che il traffico non riesce a utilizzare questi tunnel CSS anche se VMware SASE Orchestrator continua a contrassegnare i tunnel come ATTIVI.

    Anche se il probe L7 non riesce con un errore HTTP 4XX, VMware SD-WAN Gateway non riconosce l'errore e non informa Orchestrator di contrassegnare i tunnel CSS come INATTIVI.

  • Problema 100172 risolto: se un utente tenta di accedere tramite SSH a un Edge tramite un VMware SD-WAN Gateway, è possibile che nel Gateway si verifichi un errore del servizio piano dati, venga generato un core e venga eseguito un riavvio per il ripristino.

    È possibile che nel Gateway si verifichi questo problema quando un utente tenta di accedere tramite SSH a un Edge tramite il Gateway e tale sessione SSH generi un messaggio d'errore FRAG_NEEDED ICMP.

  • Problema 101536 risolto: È possibile che in un VMware SD-WAN Gateway si verifichi un errore del servizio piano dati, che venga generato un core e che venga eseguito un riavvio per il ripristino.

    Quando esamina il file core, l'utente osserva la registrazione relativa al monitoraggio del mutex del gateway e questo può verificarsi quando l'azienda di un cliente connessa a tale gateway utilizza Hub e Cluster Interconnect.

  • Problema 104619 risolto: Quando due o più aziende condividono lo stesso gateway partner e tutte dispongono di una configurazione di handoff partner in cui utilizzano IPv4, se un handoff partner in un'azienda viene rimosso, la creazione di un'associazione di sicurezza (SA) non riesce per le altre aziende connesse a tale gateway partner.

    Ad esempio, se sono presenti due aziende denominate Enterprise-1 ed Enterprise-2 che utilizzano un gateway partner e in entrambe le aziende è configurato un handoff partner, il servizio SD-WAN imposta un singolo indirizzo IP nell'interfaccia di rete virtuale del gateway. Se un utente disabilita l'handoff partner in Enterprise-2, il servizio SD-WAN passa al flusso successivo ed elimina questo indirizzo IP dall'interfaccia della rete virtuale anche se lo stesso indirizzo IP viene utilizzato per l'handoff di Enterprise-1. Di conseguenza, Enterprise-1 non sarà in grado di stabilire tunnel IPSec con i rispettivi Edge.

    Se in un gateway si verifica questo problema senza una correzione, il riavvio del gateway risolverà il problema.

  • Problema 107309 risolto: Quando un cliente configura il controllo integrità L7 per una destinazione non SD-WAN tramite Edge in Orchestrator 4.x e Orchestrator viene aggiornato alla versione 5.x, se il cliente tenta di modificare il valore del nuovo tentativo probe L7, l'Edge non applica il nuovo valore.

    Ad esempio, se il valore del nuovo tentativo del probe del controllo integrità L7 è 3 (il tunnel viene contrassegnato come inattivo in 3 probe non riusciti) e il cliente modifica questo valore impostandolo su 1, il controllo integrità L7 continua a utilizzare il valore originale di 3 tentativi prima che il tunnel venga contrassegnato come inattivo.

  • Problema 108473 risolto: È possibile che in un VMware SD-WAN Gateway si verifichi un errore del servizio piano dati, che venga generato un core e che venga eseguito un riavvio per ripristinare il servizio.

    Nel Gateway può verificarsi una situazione in cui è presente un overflow del numero di sequenza. Questo attiva l'eliminazione di tutte le SA (associazioni di sicurezza IPSec). Quando si tenta di eliminare tutte le SA, il processo del gateway tenta di trovare un tunnel in base all'ID tunnel, ma il tunnel non esiste e questo causa un errore del servizio gateway.

  • Problema 111646 risolto: In un VMware SD-WAN Gateway con un carico di CPU elevato è possibile che si verifichi un errore del servizio piano dati e che il Gateway venga riavviato per il ripristino.

    Un utente che esegue una ricerca nel core generato dal Gateway noterà un'eccezione del monitoraggio mutex e il messaggio Program terminated with signal SIGXCPU, CPU time limit exceeded message. Il problema è correlato a un processo del Gateway che rilascia un blocco del thread con priorità inferiore.

  • Problema 111888 risolto: In un VMware SD-WAN Gateway distribuito con 4 core e più di 2000 tunnel connessi, è possibile che si verifichi un utilizzo elevato della CPU e che i tunnel connessi al Gateway non siano stabili.

    Uno dei thread del Gateway utilizza una capacità CPU eccessiva in un Gateway a 4 core. Ciò impedisce al Gateway di mantenere tunnel stabili.

  • Problema 111924 risolto: Un cliente può notare che in tutti i siti il traffico con percorso multiplo (ovvero il traffico che attraversa VMware SD-WAN Gateway) viene eliminato anche se i tunnel di VMware SD-WAN Edge verso il gateway sono attivi e stabili.

    Non esiste alcun limite al numero di volte per cui un gateway può ritrasmettere un pacchetto VCMP (protocollo di gestione di SD-WAN) e tali ritrasmissioni possono sovraccaricare i link con larghezza di banda bassa. Queste ritrasmissioni causano anche la creazione di pacchetti nello scheduler quando l'Edge ha un link con larghezza di banda bassa perché le ritrasmissioni non possono essere svuotate abbastanza rapidamente. Le code dello scheduler diventano quindi piene e lo scheduler elimina i pacchetti da tutti gli Edge. Questo problema non influisce sul traffico diretto che non utilizza il gateway.

    Quando il problema si verifica ed è presente un gateway senza una correzione, l'unico modo in cui un utente operatore può correggerlo consiste nell'identificare gli Edge che causano la creazione di pacchetti nello scheduler utilizzando il comando debug.py --qos_dump_net e bloccarli nel gateway interessato.

  • Problema 112016 risolto: È possibile che in un VMware SD-WAN Gateway si verifichino più errori del servizio piano dati con core generati dopo l'avvio del gateway.

    Esaminando i core, un operatore nota che ogni errore viene attivato da un problema del monitoraggio mutex. Si verifica un aumento del tempo di elaborazione di VCMP (protocollo di gestione di SD-WAN) eseguito per il thread che lo gestisce. Durante un avvio del gateway, questo comportamento causa la continua esecuzione del thread di VCMP al 100% per lunghi periodi di tempo (più di 60 secondi) che causano più errori del servizio gateway relativi al monitoraggio mutex.

  • Problema 112017 risolto: Un operatore può notare che in un VMware SD-WAN Gateway distribuito con 4 core si verifica un carico elevato che causa uno o più errori del servizio piano dati.

    I registri principali del gateway puntano al monitoraggio mutex che attiva l'errore del servizio. Esistono diversi ticket relativi al sintomo descritto in precedenza. In questo caso il problema è dovuto al fatto che i thread VCMP (protocollo di gestione) raggiungono il limite dei processi della CPU di un gateway a 4 core e questo attiva il monitoraggio mutex. Questo ticket consente a un utente operatore di configurare un limite di connessione semiaperta di VCMP di 20. Questa operazione può essere eseguita tramite l'interfaccia della riga di comando (CLI) del gateway utilizzando debug.py o tramite un file di configurazione statico.

  • Problema 112019 risolto: È possibile che in un VMware SD-WAN Gateway si verifichi un errore del servizio piano dati e che il servizio venga quindi riavviato per il ripristino quando il carico della CPU è elevato.

    Come per gli altri ticket relativi a errori del servizio gateway nella build di rollup 5.1.0.3, l'operatore o il partner notano un trigger del monitoraggio mutex nel file core. Con questo ticket, la correzione consiste nello spostare i registri di debug NAT all'esterno dell'ambito di blocco della tabella NAT per evitare una delle cause di questo problema.

  • Problema 112020 risolto: È possibile che in un VMware SD-WAN Gateway distribuito con 4 core con un carico di CPU elevato si verifichi un errore del servizio piano dati e un conseguente riavvio.

    Se esamina il file core del Gateway, un utente noterà un errore del monitoraggio mutex causato da un processo del Gateway che non può essere eseguito perché la CPU è in esecuzione alla capacità massima a causa di un numero elevato di tunnel.

  • Problema 112800 risolto: I clienti che utilizzano un VMware SD-WAN Gateway possono notare prestazioni scarse che riguardano ad esempio la convergenza di tunnel e route.

    Se esamina il monitoraggio del gateway, un utente nota che i core del piano dati (dp-core) sono in esecuzione al 100% perché il gateway non svuota i flussi obsoleti del dispatcher.

  • Problema 114052 risolto: È possibile che in un VMware SD-WAN Gateway si verifichi un errore del servizio piano dati, che venga generato un core e che il servizio venga quindi riavviato.

    Il problema è causato dal timeout di un thread nel processo IPSec del gateway che attiva un errore del servizio gateway.

  • Problema 114084 risolto: Quando un cliente che ha configurato un servizio di sicurezza cloud (CSS) di tipo Zscaler con Controllo integrità L7 (L7 Health Check) per un VMware SD-WAN Edge, aggiorna il server cloud Zscaler in VMware SASE Orchestrator, i dettagli aggiornati non vengono applicati all'Edge.

    Anche se in Orchestrator viene visualizzata la nuova configurazione del server cloud Zscaler, l'Edge e il gateway non inviano il traffico o i probe L7 tramite questo nuovo server, ma tramite il server Zscaler precedente.

  • Problema 114282 risolto: Quando viene riavviato un VMware SD-WAN Gateway distribuito con 4 core, è possibile che siano necessari fino a venti minuti per la convergenza di circa 3000 tunnel per le aziende dei clienti connessi.

    Le prestazioni standard prevedono che il gateway esegua la convergenza di circa 3000 tunnel in 5 minuti circa rispetto ai venti minuti necessari quando questo problema si verifica. La velocità inferiore può causare un'interruzione del traffico del cliente finché i tunnel non vengono completamente ripristinati. La causa della convergenza più lenta è riconducibile a una configurazione nel processo IPSec del gateway che gestisce le associazioni di sicurezza e le chiavi e che viene corretta con questo ticket.

  • Problema 114932 risolto: Gli utenti del client VMware SD-WAN Edge possono notare prestazioni scarse del traffico che attraversa il VMware SD-WAN Gateway primario dell'Edge.

    Gli utenti operatori possono notare un utilizzo elevato della CPU per il Gateway anche se il numero di tunnel è inferiore al limite massimo supportato. L'utilizzo elevato della CPU deriva dal fatto che una SA (associazione di sicurezza) IKE obsoleta rimane più a lungo nella tabella IKE aumentando il tempo necessario per la convergenza dei tunnel. Questo causa un aumento delle eliminazioni del traffico e l'instabilità del percorso per il traffico del cliente che attraversa il Gateway.

  • 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 115692 risolto: In un VMware SD-WAN Gateway è possibile che un operatore noti un aumento dell'utilizzo della memoria che può causare l'esaurimento della memoria e un riavvio preventivo del servizio per cancellare la memoria.

    In questo caso, nel gateway si verifica una perdita di memoria IKE durante il rinnovo dei certificati con i siti peer.

    Senza una correzione per questo problema, l'operatore può solo monitorare l'utilizzo della memoria nel gateway e riavviare proattivamente il gateway in una finestra di manutenzione che riduca al minimo l'interruzione dei siti dei clienti che utilizzano il gateway.

  • Problema 116182 risolto: È possibile che in un VMware SD-WAN Gateway si verifichi un errore del servizio piano dati, che venga generato un core e che il servizio venga quindi riavviato.

    Questo problema si verifica nei gateway in cui gli SD-WAN Edge connessi sono configurati con un criterio di backhaul Internet che utilizza la modalità IPv6 o la modalità mista IPv4/IPv6 in una destinazione non SD-WAN (NSD) tramite gateway. In questo scenario, quando il gateway riceve pacchetti IPv6 destinati a un NSD che utilizza IPv4, il servizio gateway non viene eseguito correttamente.

Risolti nelle versioni R5102-20230310-GA dell'Edge e del Gateway

La build R5102-20230310-GA di Edge e Gateway è stata rilasciata il 14-03-2023 ed è il secondo rollup di Edge e Gateway per la versione 5.1.0.

Questa build di rollup del Gateway risolve i seguenti problemi critici presenti dalla prima build di rollup R5101-20230112-GA di Edge e Gateway.

  • Problema 98782 risolto: È possibile che in VMware SD-WAN Gateway si verifichi un errore del servizio piano dati durante la creazione del tunnel IPSec, che causa la generazione di un core e il riavvio del servizio.

    Quando in un gateway si verifica questo problema, il riavvio può causare una breve interruzione del traffico del cliente per gli Edge connessi a tale Gateway e le destinazioni non SD-WAN che utilizzano il Gateway per i tunnel IPSec. Il problema è causato da una race condition per cui quando il Gateway stabilisce un tunnel IPSec attiva l'errore del servizio piano dati.

  • Problema 103708 risolto: Quando vengono aggiunte nuove regole in una configurazione del filtro BGP, è possibile che route BGP impreviste vengano ricevute e inviate da VMware SD-WAN Edge.

    Quando vengono aggiunte nuove regole ai filtri BGP da Orchestrator, gli elenchi di prefissi vengono aggiunti nella configurazione di routing dell'Edge senza rimuovere le voci precedenti. Questo comporta la presenza di elenchi di prefissi di route obsoleti che causano un comportamento imprevisto del filtro.

  • Problema 104141 risolto: È possibile che per gli utenti dietro un VMware SD-WAN Edge o i clienti connessi a un VMware SD-WAN Gateway si verifichino notevoli problemi relativi al traffico che utilizza l'Edge o che attraversa il Gateway e che non venga inoltrato alcun traffico.

    Quando il problema si verifica, nell'Edge o nel Gateway è presente un numero illimitato di buffer di memoria (mbuf) che vengono utilizzati dalla coda del buffer jitter a causa dell'aumento di timestamp del tunnel di gestione ricevuti da un peer. Ciò attiva l'underflow di un intero nel calcolo del jitter causando il buffering indefinito dei pacchetti. All'inizio questo comportamento influisce solo sui flussi con buffering, ma in un periodo di tempo sufficientemente lungo il numero di mbuf utilizzati per la coda del buffer jitter si avvicina al numero totale di mbuf disponibili impedendo al dispositivo SD-WAN (Edge o Gateway) di inoltrare tutto il traffico. Se il problema si verifica in un Gateway, influisce solo sul traffico con percorso multiplo che attraversa il Gateway e non sul traffico diretto del cliente.

    Anche il ticket 105744 si riferisce ai sintomi evidenziati qui ma causati da un motivo diverso. Differenza tra i due ticket: la correzione inclusa nel ticket 104141 si riferisce ai buffer di memoria utilizzati dalla coda del buffer jitter a causa dell'aumento dei timestamp di gestione ricevuti dal peer. La correzione inclusa nel ticket 105744 limita il numero di buffer jitter al 25% dei buffer di memoria totali indipendentemente da ciò che succede, per fare in modo che il problema non si ripeta.

    Senza una correzione per questo problema per l'Edge o il Gateway, un utente può monitorare l'utilizzo del buffer di memoria (mbuf) in Orchestrator e individuare l'aumento dell'utilizzo di mbuf dovuto al fatto che i pacchetti vengono inseriti nella coda del buffer jitter. Se l'utente rileva il problema, può svuotare i flussi per l'Edge (tramite diagnostica remota) o il Gateway per ovviare temporaneamente al problema, che tuttavia si verificherà ancora finché non verrà applicata la correzione.

  • Problema 105744 risolto: È possibile che per gli utenti dietro un VMware SD-WAN Edge o i clienti connessi a un VMware SD-WAN Gateway si verifichino notevoli problemi relativi al traffico che utilizza l'Edge o che attraversa il Gateway e che non venga inoltrato alcun traffico.

    Questo ticket e il problema n. 104141 sono direttamente correlati e hanno gli stessi sintomi e la stessa causa, ovvero quando si verifica il problema, nell'Edge o nel Gateway viene utilizzato un numero illimitato di buffer di memoria (mbuf) dalla coda del buffer jitter a causa dell'aumento dei timestamp del tunnel di gestione ricevuti da un peer. Ciò attiva l'underflow di un intero nel calcolo del jitter causando il buffering indefinito dei pacchetti. All'inizio questo comportamento influisce solo sui flussi con buffering, ma in un periodo di tempo sufficientemente lungo il numero di mbuf utilizzati per la coda del buffer jitter si avvicina al numero totale di mbuf disponibili impedendo al dispositivo SD-WAN (Edge o Gateway) di inoltrare tutto il traffico. Se il problema si verifica in un Gateway, influisce solo sul traffico con percorso multiplo che attraversa il Gateway e non sul traffico diretto del cliente.

    Differenza tra i due ticket: la correzione inclusa nel ticket 104141 si riferisce ai buffer di memoria utilizzati dalla coda del buffer jitter a causa dell'aumento dei timestamp di gestione ricevuti dal peer. La correzione inclusa nel ticket 105744 limita il numero di buffer jitter al 25% dei buffer di memoria totali per assicurarsi che il problema non si ripeta.

    Senza una correzione per questo problema per l'Edge o il Gateway, un utente può monitorare l'utilizzo del buffer di memoria mbuf in Orchestrator e individuare l'aumento dell'utilizzo di mbuf dovuto al fatto che i pacchetti vengono inseriti nella coda del buffer jitter. L'utente può svuotare i flussi per l'Edge o il Gateway per ovviare temporaneamente al problema, che tuttavia si verificherà ancora finché non verrà applicata la correzione.

  • Problema 106587 risolto: Un cliente può notare che tutto il traffico viene eliminato in modo casuale e questo stato persiste.

    Il problema è correlato all'installazione di IPSec Security Association (SA) sul lato del risponditore. Quando l'Edge avvia una nuova SA o esegue una ridefinizione delle chiavi, è possibile che il vecchio pacchetto SPI (Security Parameter Index) di SA arrivi prima del nuovo SPI di SA. In questo caso, VMware SD-WAN Gateway elimina lo SPI di SA appena creato. La correzione aggiunta impedirà l'eliminazione del nuovo SPI di SA creato.

    Senza una correzione per questo problema, un utente operatore o partner deve riavviare il Gateway per riavviare tutti i tunnel IPSec interessati.

Risolto nella versione R5101-20230112-GA del Gateway

La build R5101-20230112-GA del Gateway è stata rilasciata il 19-01-2023 ed è il primo rollup del Gateway per la versione 5.1.0.

Questa build di rollup del Gateway risolve i seguenti problemi critici presenti dalla build R5100-20221204-GA del Gateway originale.

  • Problema 97272 risolto: In un sito con una topologia ad alta disponibilità in cui viene utilizzato OSPF, quando nel sito si verifica una condizione di split brain (entrambi gli SD-WAN Edge sono attivi), la route predefinita verso il router principale viene rimossa e il sito HA non può raggiungere i siti peer nella rete.

    L'età dell'annuncio dello stato del link (LSA) del router principale viene sincronizzata con l'Edge attivo. Quando si verifica una condizione di split brain di HA, l'Edge di standby diventa attivo e invia una nuova età di LSA al router principale. Poiché sia l'Edge attivo sia l'Edge di standby hanno lo stesso ID router, il nuovo Edge attivo invia un'età di LSA diversa. Questa mancata corrispondenza causa l'impostazione dell'età di LSA su un valore massimo di 3600 nel router principale, che rimuove anche la route principale verso il sito HA, causando un'interruzione completa nel sito.

  • Problema 104487 risolto: A causa della lentezza del servizio di database, è possibile che per gli utenti di VMware SASE Orchestrator si verifichi un rallentamento generale e alcuni errori dell'API. Altri effetti negativi includono i seguenti: gli SD-WAN Gateway o gli SD-WAN Edge vengono visualizzati offline nell'interfaccia utente, le modifiche della configurazione apportate tramite l'interfaccia utente di Orchestrator non vengono inviate agli SD-WAN Edge di destinazione e le funzionalità di creazione report vengono perse.

    I problemi sono tutti causati dal fatto che il servizio di database di Orchestrator non viene eseguito correttamente e viene visualizzato il messaggio di errore: troppi file aperti. Questo errore viene notato dall'operatore di VMware SASE Orchestrator tramite i registri. Per un utente finale che accede a VMware SASE Orchestrator tramite l'interfaccia utente potrebbero verificarsi un rallentamento ed errori intermittenti dell'API che causano la visualizzazione di messaggi di errore nell'interfaccia utente.

Risolti nelle versioni R5100-20221204-GA dell'Edge e del Gateway

Nella build R5100-20221204-GA dell'Edge e del Gateway, rilasciata il 08-12-2022, sono stati risolti i seguenti problemi presenti dalla versione R5012-20221107-GA dell'Edge e R5011-20221007-GA del Gateway.

Nota:

La versione 5.1.0 contiene tutte le correzioni di Edge e Gateway elencate nelle note di rilascio della versione 5.0.0 e tutte le correzioni di Edge e Gateway elencate nelle note di rilascio della versione 5.0.1 fino alle build indicate in precedenza.

  • Problema 26085 risolto: Un cliente che utilizza una topologia hub/spoke e gateway partner può notare che il traffico viene eliminato in un VMware SD-WAN Edge spoke se la configurazione di uno dei gateway viene annullata da un Edge hub.

    Il traffico eliminato utilizza una route obsoleta per un gateway che non è più assegnato. Quando la configurazione di un gateway viene annullata da un Edge hub, il gateway stesso non è a conoscenza di questo e gestisce l'evento come un semplice evento di inattività del tunnel. Di conseguenza, il gateway continua a fornire all'Edge spoke la sua route e l'Edge spoke non rimuove la route remota (raggiungibile tramite l'Edge hub) perché l'Edge hub è ancora raggiungibile per l'Edge spoke.

    Quando questo problema si verifica perché si utilizza una build senza la correzione, l'unico modo per risolverlo è quello di eseguire lo slap dell'Edge spoke al link del gateway.

  • Problema 29929 risolto: Per un sito distribuito con una topologia ad alta disponibiliyà (HA), quando si verifica un failover di HA, un utente potrebbe non essere in grado di accedere all'interfaccia utente locale per gli Edge HA.

    Quando le credenziali locali vengono modificate per gli Edge HA in Orchestrator, l'Edge attivo corretto applica la modifica, ma le nuove credenziali non vengono sincronizzate con l'Edge di standby. Di conseguenza, quando si verifica un failover di HA e l'Edge di standby viene promosso ad attivo, l'Edge utilizza le credenziali utente/password predefinite e un utente che tenta di accedere all'interfaccia utente locale non riesce se utilizza le credenziali più recenti.

  • Problema 32413 risolto: La temperatura non è inclusa nelle statistiche di integrità o nel MIB.

    La correzione aggiunge la temperatura della CPU al MIB utilizzato per SNMP e alle metriche misurate in Monitor (Monitora) > Edge > Sistema (System), note anche come "statistiche di integrità dell'Edge".

  • Problema 32654 risolto: È possibile che gli utenti di un sito VMware SD-WAN Edge in cui un'interfaccia WAN è inattiva notino l'eliminazione del traffico.

    Il traffico viene eliminato perché le route connesse rimangono annunciate a un VMware SD-WAN Gateway anche se la raggiungibilità è False in VMware SD-WAN Edge quando l'interfaccia connessa è inattiva.

  • Problema 39134 risolto: Quando si controlla la pagina Monitora (Monitor) > Edge > Sistema (System), la percentuale di CPU non è corretta.

    Noto anche come "statistiche di integrità dell'Edge", VMware SASE Orchestrator non riceve informazioni accurate sull'utilizzo della CPU dell'Edge e le invia come output ai grafici della pagina Sistema (System) che risultano quindi imprecisi e fuorvianti per i clienti che tentano di risolvere un problema dell'Edge.

  • Problema 45453 risolto: Un cliente non può configurare un VMware SD-WAN Edge in modo che abbia 2 interfacce WAN che utilizzano la stessa VLAN.

    Il problema si verifica in uno scenario in cui un sito connette più porte WAN Edge allo stesso commutatore L2 nella stessa VLAN. Il problema di questa configurazione consiste nel fatto che l'Edge può a volte utilizzare l'indirizzo MAC di origine errato quando invia traffico di gestione.

  • Problema 50920 risolto: VMware SD-WAN Edge non invia un avviso quando il numero di tunnel connessi raggiunge il 60% del limite hardware definito per quel modello di Edge.

    L'Edge invia un avviso quando il numero di tunnel connessi raggiunge il limite hardware con cui comunica che il numero dei tunnel stabilito ha superato la capacità del dispositivo. Una volta raggiunto questo limite, l'Edge non consentirà ulteriori tunnel dinamici finché non verranno eliminati tunnel esistenti. Tuttavia, non viene inviato alcun avviso intermedio precedente per avvertire il cliente che vi è la possibilità del raggiungimento del limite di tunnel, impedendo così al cliente di gestire la propria rete per tempo.

  • Problema 53337 risolto: si possono verificare mancate elaborazioni di pacchetti con un'istanza di AWS di un VMware SD-WAN Gateway quando la velocità effettiva è superiore a 3200 Mbps.

    Quando il traffico supera una velocità effettiva superiore a 3200 Mbps e una dimensione di pacchetto di 1300 byte, si verificano mancate elaborazioni di pacchetti in RX e all'handoff BH IPv4.

  • Problema 54846 risolto: I MIB SNMP di VMware SD-WAN utilizzano contatori per jitter, latenza e perdita di pacchetti.

    Nei MIB SNMP di VMware, latenza, jitter e perdita di pacchetti sono definiti come Counter64, che non è appropriato per questi tipi. I contatori devono essere utilizzati per i tipi di dati con valori sempre crescenti e che non vengono mai reimpostati in SNMP come byte Tx/Rx. Al contrario, latenza, jitter e perdita di pacchetti non hanno valori sempre crescenti, ma valori regolati dinamicamente, e non devono utilizzare contatori.

  • Problema 55327 risolto: La connessione SSH da un VMware SD-WAN Gateway a un VMware SD-WAN Edge potrebbe non funzionare se si verifica continuamente il flap del tunnel dall'Edge al gateway.

    Se si verifica continuamente il flap del tunnel dall'Edge al gateway, è possibile che la voce della route installata nell'Edge per consentire la connessione SSH dal gateway venga eliminata e causi la mancata riuscita della connessione SSH.

  • Problema 56153 risolto: Per l'azienda di un cliente in cui viene distribuita una destinazione non SD-WAN tramite gateway e in cui viene utilizzato BGP su IPSec, se il cliente annulla l'assegnazione di un filtro BGP in entrata, il filtro non viene rimosso in VMware SD-WAN Gateway e con il filtro viene applicata la mappa di routing.

    Questo problema può causare un routing imprevisto per il cliente perché prevede che il filtro BGP in entrata sia inattivo mentre invece è ancora utilizzato dal gateway e dall'Edge.

  • Problema 60844 risolto: Un criterio di business progettato per eliminare tutto il traffico corrispondente al criterio configurando un limite di velocità pari a 0% non funziona.

    Anche se la configurazione di un limite di velocità pari a 0% è consentita, l'Edge non lo considera 0%, ma 100%, vanificando completamente lo scopo del criterio di business.

    In un Edge senza la correzione, la soluzione consiste nell'utilizzare una regola del firewall che stabilisca se il traffico corrisponde a un criterio di business e lo elimini.

  • Problema 61804 risolto: L'azienda di un cliente che utilizza BGP può notare che quando un VMware SD-WAN Edge acquisisce route da un peer, tali route vengono annunciate nuovamente al peer stesso.

    L'Edge non deve annunciare le route acquisite dal peer al peer stesso e questo causa un comportamento di routing negativo e l'eliminazione del traffico.

  • Problema 62701 risolto: Per un VMware SD-WAN Edge distribuito come parte di un cluster dell'Edge hub, se la VPN cloud non è attivata nel segmento globale ma è attivata in un segmento non globale, un aggiornamento del piano di controllo inviato da Orchestrator può causare il flap di tutti i link WAN nell'Edge hub.

    I link WAN dell'Edge hub che diventano inattivi e quindi attivi in rapida successione (flap) influiranno sul traffico in tempo reale come le chiamate vocali. Questo problema si verifica in una distribuzione del cliente in cui la VPN cloud non è stata attivata nel segmento globale dell'Edge hub, ma è stata eseguita la configurazione del cluster. Ciò significa che questo Edge hub fa parte di un cluster (e la configurazione di un cluster è applicabile a tutti i segmenti). Quando si esegue il push di una modifica della configurazione nell'Edge hub, il piano dati dell'Edge hub inizierà ad analizzare i dati partendo dal segmento globale in cui la VPN cloud non è attivata e l'Edge hub penserà erroneamente che il clustering sia stato disattivato in questo segmento globale. Di conseguenza l'Edge hub rimuoverà tutti i tunnel dai link WAN dell'hub causando il flap di tutti i link WAN di tale Edge. Per qualsiasi evento imprevisto di questo tipo, i link WAN diventano inattivi e vengono ripristinati una sola volta per ogni aggiornamento del piano di controllo.

    In un'azienda in cui gli Edge non utilizzano una versione con una correzione per questo problema, la soluzione consiste nell'attivare la VPN cloud in tutti i segmenti, ovvero il segmento globale e tutti i segmenti non globali.

  • Problema 64526 risolto: Quando un utente modifica l'interfaccia GE2 in un VMware SD-WAN Edge da commutata a instradata e quindi configura un'interfaccia secondaria in questa interfaccia e tenta di salvare le modifiche, Orchestrator genera un errore.

    Questo errore viene attivato solo quando la configurazione dell'interfaccia dell'Edge viene modificata a livello del profilo (anziché a livello dell'Edge). Il messaggio di errore è simile a "Tipo di indirizzamento sconosciuto DHCP_STATELESS per l'interfaccia secondaria GE2 - ignorato" e viene visualizzato nella pagina Eventi (Events) di Orchestrator per tale cliente.

  • Problema 65530 risolto: Un cliente che distribuisce SFP Metanoia in un VMware SD-WAN Edge può notare un problema relativo al modulo.

    È possibile che il problema si verifichi perché non ci si trova in un livello più recente del firmware che viene aggiornato con la versione 5.1.0. Le modifiche apportate alla versione di CSP e alla versione del firmware SFP UPG sono illustrate nella tabella seguente:

    Versione dell'Edge

    Versione di CSP

    Versione del firmware SFP UPG

    5.1.0

    3.2.9.13

    1_62_8559

    4.0.0 - 5.0.x

    3.2.8.11

    1_62_8431

    Questi aggiornamenti garantiscono una maggiore stabilità per gli SFP Metanoia nell'Edge.

  • Problema 65919 risolto: Per un cliente che ha configurato un servizio di sicurezza cloud (CSS) Zscaler, se il servizio Edge viene riavviato o il DNS viene eliminato, è possibile che il tunnel Zscaler non riesca.

    Anche se le query DNS vengono eseguite correttamente, DNS non mostra il nome di dominio completo di Zscaler e di conseguenza il tunnel non viene attivato. Quando si cerca DNS nei registri dell'Edge, non vi saranno voci Zscaler nella cache di DNS.

    Per risolvere il problema, è necessario che un utente esegua il comando nslookup o un ping in seguito al quale viene creata la voce DNS e viene attivato il tunnel Zscaler. 

  • Problema 67900 risolto: Se un link WAN viene configurato come rilevato automaticamente in VMware SASE Orchestrator, Orchestrator può contrassegnarlo come link privato anche se deve essere impostato come link pubblico.

    Orchestrator richiede che il link venga impostato come privato anche se il cliente ha impostato la configurazione per tale link come pubblica. Ciò può causare notevoli problemi di connettività relativi a un gateway perché il link tenterà di connettersi a un IP privato e il processo non riuscirà.

  • Problema 68335 risolto: Per l'azienda di un cliente che utilizza una topologia hub/spoke in cui gli hub sono cluster, i VMware SD-WAN Edge spoke che non sono in grado di connettersi a un cluster di hub possono consumare quantità elevate di larghezza di banda classificata come traffico di controllo di SD-WAN.

    Quando un Edge spoke non riesce a stabilire overlay con i cluster di hub del proprio data center, l'Edge chiede ai controller di riassegnare un membro del cluster diverso. Di conseguenza, i controller inviano continuamente eventi di controllo e consumano la larghezza di banda del link.

    In un Edge senza la correzione, la soluzione per questo problema consiste nel creare e assegnare un profilo temporaneo senza assegnare il cluster di hub non raggiungibile nel profilo.

  • Problema 70248 risolto: Quando viene emesso un CRL sul lato Edge, il tunnel diventa inattivo e viene nuovamente ristabilito.

    Quando Orchestrator revoca un certificato qualsiasi, ad esempio un certificato del gateway, l'Edge disattiva il tunnel ma lo ristabilisce nuovamente.

    Il problema riguarda il tempo di validità del CRL. Se l'ora di aggiornamento del CRL è precedente all'ora dell'Edge, il tunnel verrà nuovamente ristabilito.

    Se la correzione non è presente, l'unica soluzione consiste nel fare in modo che la data e l'ora dell'Edge e di Orchestrator corrispondano.

  • Problema 70311 risolto: È possibile che in un VMware SD-WAN Edge si verifichi un errore del servizio piano dati e che il servizio venga quindi riavviato.

    Durante il riavvio del servizio Edge, il traffico del cliente verrà interrotto per circa 15-30 secondi. Questo problema si verifica in modo non coerente. Tuttavia, quando si verifica, l'Edge sta rimuovendo un'associazione di sicurezza IKE. Questo problema si verifica in genere solo quando il timer SA (configurato in VMware SD-WAN Orchestrator) scade oppure l'utente modifica la configurazione di IPSec in Orchestrator.

  • Problema 71302 risolto: Per l'azienda di un cliente che utilizza una destinazione non SD-WAN tramite Edge, la porta utilizzata è la 500 anziché la 4500.

    Questo non è il comportamento previsto e può causare problemi relativi al traffico che utilizza tale destinazione non SD-WAN tramite Edge se sono presenti altri dispositivi che bloccano la porta 500.

  • Problema 71719 risolto: La connessione PPTP non viene stabilita nel percorso da Edge a cloud.

    La connessione al server PPTP dietro VMware SD-WAN Edge non viene stabilita.

  • Problema 75553 risolto: Un cliente che distribuisce una destinazione non SD-WAN (NSD) tramite gateway che utilizza un tipo basato su criterio non può configurare VMware SD-WAN Gateway ridondanti.

    Nelle build precedenti VMware contrassegna sempre una route NSD basata su criterio come "Raggiungibile (Reachable)" indipendentemente dallo stato. In questo modo la route del gateway primario della destinazione non SD-WAN (NSD) non viene mai contrassegnata come non raggiungibile e viene attivato un failover in un gateway ridondante.

    Nelle versioni 5.1.0 e successive, il percorso del gateway viene contrassegnato come raggiungibile a meno che la negoziazione IKE/IPSec non riesca. In questo caso viene contrassegnato come "Non raggiungibile (Unreachable)" e il traffico della NSD passa attraverso il gateway ridondante come avviene con una NSD basata su route.

  • Problema 75668 risolto: Il tag DSCP viene reimpostato per il traffico lato LAN quando viene instradato verso una destinazione LAN interna.

    Per il traffico degli utenti instradato/diretto, l'Edge reimposta il tag DSCP su 0 e per il traffico in ingresso e in uscita nello stesso Edge (in altre parole, il traffico che rimane locale nell'Edge) il tag DSCP viene modificato con il contrassegno CSP=0DSCP e viene reimpostato su CS0 per il traffico underlay quando attraversa l'Edge.

  • Problema 76881 risolto: Quando in un VMware SD-WAN Edge vengono utilizzati più di 10.000 lease DHCPv6, è possibile che vengano raggiunti livelli critici di utilizzo della memoria e che venga attivato un riavvio del servizio Edge.

    Quando un numero elevato di client DHCPv6 è connesso al server DHCPv6, a ogni client viene fornito un lease e la memoria del server DHCPv6 continua ad aumentare. L'Edge non limita il numero di lease DHCPv6 che possono essere allocati mentre limita a 5.000 il numero di indirizzi IPv4. Di conseguenza, è possibile che l'Edge assegni lease sufficienti per raggiungere un livello critico dello stato della memoria dell'Edge e attivare un riavvio del servizio.

    La correzione del problema limita il numero massimo di client a 10.000.

  • Problema 77066 risolto: È possibile che in un VMware SD-WAN Gateway si verifichi un errore del servizio piano dati, che venga attivato un core e che venga riavviato il servizio da ripristinare.

    Il problema viene attivato da un danneggiamento della memoria del Gateway che si verifica perché due processi del Gateway che gestiscono rispettivamente i pacchetti di trasmissione e ricezione tentano contemporaneamente di accedere allo stesso nodo di una struttura di ricerca.

  • Problema 77457 risolto: Se un utente tenta di generare un'acquisizione di pacchetti (PCAP) per un'interfaccia in un VMware SD-WAN Edge di standby, VMware SASE Orchestrator segnala che il PCAP non è riuscito.

    Quando un utente tenta di generare un PCAP per l'Edge di standby in una distribuzione ad alta disponibilità avanzata, l'interfaccia utente di Orchestrator registra lo Stato richiesta (Request Status) come Non riuscito (Failed) con la spiegazione "Impossibile caricare il bundle di diagnostica: 'unicode' non dispone dell'interfaccia del buffer" (Failed to upload diagnostic bundle: 'unicode' does not have the buffer interface).


  • Problema 77611 risolto: Per il sito di un cliente che utilizza una topologia ad alta disponibilità, quando l'Edge HA viene migrato in un profilo di configurazione diverso, è possibile che venga attivato lo stato Attivo-Attivo (Active-Active) (split brain) per entrambi gli Edge e che vengano riavviati contemporaneamente per il ripristino.

    Mentre è attivo lo stato Attivo-Attivo (Active-Active), gli utenti del client rilevano notevoli problemi di qualità del traffico per la perdita di pacchetti.

    Il problema si verifica perché gli Edge HA non riescono a seguire un determinato processo quando passano a un nuovo profilo per cui l'Edge di standby deve essere innanzitutto riavviato per applicare le modifiche e rimanere come Edge di standby. A questo punto l'Edge attivo applica le modifiche di configurazione e viene riavviato, promuovendo l'Edge di standby a Edge attivo mentre abbassa di livello se stesso a Edge di standby. Anziché seguire questo processo, l'Edge di standby promuove immediatamente se stesso a Edge attivo dopo il riavvio causando lo stato Attivo-Attivo (Active-Active).

  • Problema 78037 risolto: Un VMware SD-WAN Edge potrebbe subire un picco nell'utilizzo della memoria seguito da un guasto del servizio di piano dati se un server DHCPv6 è configurato con più di 1.000 indirizzi.

    Il problema si verifica sia per le interfacce di route che per quelle commutate. Il problema può verificarsi quando vengono configurati più di 1.000 indirizzi per i client su un server DHCPv6. Quando oltre 1.000 client ottengono indirizzi, la quantità di pacchetti di richiesta DHCPv6 generati può portare all'esaurimento della memoria dell'Edge e all'errore del servizio Edge.

  • Problema 78050 risolto: È possibile che in un VMware SD-WAN Edge si verifichi un errore del servizio piano dati quando è presente un server PPTP sul lato LAN.

    Quando un server PPTP è presente sul lato LAN e un client PPTP da Internet si connette a tale server tramite una regola del firewall in entrata, è possibile che il servizio Edge non venga eseguito correttamente a causa di un errore di ricerca del canale di controllo PPTP. Questa ricerca del canale di controllo è necessaria per garantire che il canale dati GRE venga inviato tramite lo stesso link a un client PPTP.

    In un Edge che utilizza una build senza una correzione per questo problema, l'unica alternativa del cliente è non utilizzare le sessioni PPTP.

  • Problema 78435 risolto: Un VMware SD-WAN Edge attivato con un URL tramite l'interfaccia utente locale può generare un errore che indica che l'attivazione dell'Edge non è riuscita anche se è stata eseguita correttamente.

    L'attivazione dell'Edge tramite URL con l'interfaccia utente locale genera un messaggio di errore simile a "impossibile completare l'attivazione dell'Edge" (edge activation could not be completed).


    Il problema si verifica perché l'Edge fa riferimento a una richiesta di attivazione precedente con parametri non corretti quando risponde alla richiesta dello stato di attivazione. Nel frattempo, viene effettivamente elaborata l'attuale richiesta di attivazione con i parametri corretti. Di conseguenza l'interfaccia utente locale genera un errore anche se l'attivazione dell'Edge viene elaborata correttamente.

  • Problema 79437 risolto: Un VMware SD-WAN Gateway distribuito in un server che utilizza una scheda NIC Intel X710 con SR-IOV abilitato per le interfacce potrebbe non essere distribuito correttamente.

    Se si verifica questo errore, l'operatore nota che le interfacce SR-IOV della NIC X710 vengono rimosse da DPDK e non vengono visualizzate quando si esegue debug.py --dpdk_ports_d. Le interfacce SR-IOV non vengono viualizzate nemmeno in /opt/vc/etc/dpdk.json. La distribuzione di un gateway nella versione 5.1.0 assicura che questo problema non si verifichi.

  • Problema 79338 risolto: Quando un numero elevato di client DHCPv6 tenta di recuperare un nuovo indirizzo IPv6, è possibile che alcuni client non siano in grado di recuperarlo.

    Quando più di 1024 client tentano di acquisire contemporaneamente un indirizzo IPv6, è possibile che alcuni dei client non ottengano un indirizzo IPv6 valido. Questo problema si verifica perché la cache dei router adiacenti è stata corretta e le voci dei router adiacenti di alcuni client non vengono create. Poiché le voci del router adiacente non sono presenti, i messaggi di rinnovo non riescono.

    Un cliente che non utilizza una build con la correzione, può riprovare ad acquisire l'indirizzo IPv6 dai client dopo alcuni minuti.

  • Problema 79550 risolto: è possibile che in un VMware SD-WAN Gateway o SD-WAN Edge si verifichi un errore del servizio piano dati e che il servizio venga quindi riavviato.

    Questo problema può verificarsi se viene ricevuto un frammento di traffico di gestione ripetuto (VCMP), causando la scrittura del processo oltre il buffer allocato per tale pacchetto e generando l'errore.

  • Problema 81881 risolto: È possibile che una modifica della configurazione in Configura (Configure) > Dispositivo (Device) apportata in VMware SASE Orchestrator non venga applicata nel VMware SD-WAN Edge di destinazione anche se l'Edge è connesso a Orchestrator.

    Questo problema può verificarsi in un Edge con un carico elevato in cui le modifiche della configurazione vengono apportate in modo rapido e frequente. In questo scenario, il thread di gestione dell'Edge responsabile dell'applicazione della configurazione si blocca e non applica ulteriori modifiche.

  • Problema 81353 risolto: È possibile che in un VMware SD-WAN Gateway distribuito utilizzando una piattaforma Azure vengano eliminati pacchetti sul lato Rx delle interfacce.

    I pacchetti vengono eliminati a causa di un buffer basso. L'impostazione del buffer ring non fa parte delle interfacce gestite non DPDK utilizzate dalle piattaforme Azure e le code di buffer ring Rx della NIC vengono impostate su numeri bassi.

  • Problema 81355 risolto: Nei VMware SD-WAN Gateway distribuiti utilizzando la piattaforma Azure possono verificarsi problemi relativi ai pacchetti di dimensioni superiori a 1500 byte.

    I pacchetti di dimensioni superiori a 1500 byte vengono eliminati e viene visualizzato il messaggio di errore: pkt_too_big_drop. I pacchetti di dimensioni molto superiori a 1500 byte vengono eliminati e viene visualizzato il messaggio di errore: sock_too_big_dropp.

    Il problema si verifica perché la piattaforma Azure non utilizza interfacce associate a DPDK. L'elenco DPDK.json del Gateway rimane quindi vuoto e le configurazioni di rete DPDK non inizializzano le impostazioni TSO/GSO dell'interfaccia Linux.

  • Problema 81377 risolto: Quando le subnet di Secure Access vengono aggiornate, le subnet precedenti non vengono revocate da BGP.

    Quando viene modificata la configurazione di una subnet di Secure Access, SD-WAN elimina le subnet precedenti solo da FIB (Forwarding Information Base) e dalle altre tabelle di route locali. Il problema si verifica perché SD-WAN non revoca la route dalla tabella BGP utilizzata per la ridistribuzione e queste route obsolete rimangono in BGP.

  • Problema 81483 risolto: Per un cliente con una topologia hub spoke, se un utente aumenta la durata di IKE e/o IPSec tramite VMware SASE Orchestrator, il cliente può notare che alcuni tunnel mantengono le durate precedenti. Alcuni tunnel eseguono la ridefinizione delle chiavi con una frequenza maggiore del previsto perché mantengono le durate precedenti.

    Se il cliente riduce la durata, questo bug si verifica comunque (un'estremità della topologia hub spoke può mantenere la durata maggiore precedente), ma non influisce sulla funzionalità perché l'Edge che ha ricevuto correttamente la durata inferiore eseguirà per primo la ridefinizione delle chiavi, mascherando il problema.

    L'unica soluzione per questo problema consiste nel modificare i valori della durata finché tutti i tunnel non riflettono lo stato corretto e quindi riavviare l'Edge.

  • Problema 82104 risolto: In rari casi, i VMware SD-WAN Edge attivati in una topologia ad alta disponibilità (HA) potrebbero non essere in grado di comunicare con un'istanza di VMware SASE Orchestrator, che contrassegnerà il sito come inattivo e impedirà qualsiasi intervento nel sito tramite Orchestrator.

    Questo problema si verifica solo quando agli Edge HA viene applicata una configurazione insolita e non valida. La configurazione specifica che la porta HA è configurata come "trunk" (configurazione che non dovrebbe essere consentita), con zero VLAN (altra configurazione che non dovrebbe essere consentita) ma sono impostate "tutte le VLAN". Anziché generare un errore in questa configurazione e impedire a un utente di attivare HA per gli Edge, Orchestrator lo consente. Questa configurazione consentita attiva un errore del piano di gestione negli Edge HA che non inviano più un heartbeat a Orchestrator. La correzione in questo caso consente a questa configurazione non valida di funzionare in una coppia di Edge HA senza interrompere il traffico di gestione verso Orchestrator.

  • Problema 82188 risolto: per modelli VMware SD-WAN LTE (Edge 510-LTE, 610-LTE), quando l'impostazione IPv6 è disattivata, i tunnel tramite l'interfaccia CELL potrebbero non riuscire.

    Quando la casella di controllo IPv6 in Impostazioni dispositivo (Device Settings) è disattivata, lo stato interno dell'interfaccia CELL diventa SCONOSCIUTO. Questo stato non viene aggiornato anche quando l'impostazione IPv6 è attivata per l'interfaccia CELL. A causa di questo problema, i tunnel tramite l'interfaccia CELL non riescono. Se l'Edge LTE utilizza solo le interfacce CELL per il traffico, l'Edge passa offline e tutto il traffico dell'Edge viene eliminato causando un'interruzione notevole per il cliente.

    Senza la correzione, l'utente deve riavviare il servizio Edge dopo aver disattivato l'impostazione IPv6. Se l'Edge è offline poiché utilizza solo l'interfaccia CELL per la larghezza di banda, un utente locale deve spegnere e riaccendere l'Edge per ripristinarlo.

  • Problema 83040 risolto: Nell'azienda di un cliente con una topologia hub/spoke che utilizza sia i Gateway partner sia la destinazione non SD-WAN (NSD), è possibile che il traffico utilizzi un hub anziché NSD.

    L'Edge spoke dispone di un criterio di business che esegue il backhaul del traffico in NSD e se è configurato anche un handoff del Gateway partner, lo spoke invia all'Edge hub il traffico che dovrebbe utilizzare un NSD. L'hub a sua volta invia il traffico direttamente a Internet. Se l'handoff del gateway partner è disabilitato, il traffico NSD viene instradato correttamente.

  • Problema 83227 risolto: Per un VMware SD-WAN Edge che esegue la versione 5.0.0 configurata con 128 segmenti, il processo dnsmasq dell'Edge viene interrotto e si chiude.

    Quando IPv6 viene attivato su 128 segmenti e i server DCPv6 sono configurati nella LAN di ogni segmento, il processo dnsmasq si arresta quando vengono superati i descrittori di file aperti totali. Il processo dnsmasq continua per circa 30 minuti prima chiudersi; a quel punto, l'assegnazione DHCP degli indirizzi IP dell'Edge va in errore.

    il riavvio dell'Edge ripristina per circa 30 minuti il processo dnsmasq, che tuttavia va ancora in errore. L'unica reale soluzione consiste nel ridurre il numero di segmenti a meno di 128.

  • Problema 83821 risolto: Per i clienti che utilizzano NetFlow, i pacchetti/byte Tx e Rx per il traffico di controllo di SD-WAN non vengono aggiornati correttamente nei record di NetFlow.

    I dati di controllo di SD-WAN (pacchetti/byte Tx/Rx) che vengono esportati in un agente di raccolta di NetFlow sono sempre pari a zero. Poiché le voci non vengono popolate in chat_stats del container del flusso, NetFlow non esporta nemmeno i dati.

  • Problema 84000 risolto: In un VMware SD-WAN Gateway connesso a Edge distribuiti in una configurazione dual stack (IPv4/IPv6), in cui è presente un'alta frequenza di eliminazioni e creazioni di tunnel con gli Edge, è possibile che si verifichi una perdita di memoria che quando è sufficientemente elevata attiva un riavvio del servizio.

    Quando un tunnel VCMP (gestione crittografata) viene creato ed eliminato più volte per un Edge con una configurazione dual stack, nel Gateway per tale Edge può verificarsi una perdita di pi se il Gateway funziona su larga scala. Non è presente una reale perdita di pi, ma l'eliminazione di pi viene eseguita lentamente e questa lenta eliminazione può causare problemi di memoria condivisa che possono diventare critici.

    In un gateway che non include la correzione, un riavvio del servizio cancella temporaneamente la memoria.

  • Problema 84136 risolto: Il cliente può notare un utilizzo elevato della CPU e prestazioni del traffico scarse in un VMware SD-WAN Edge aggiornato ad alcune versioni dell'Edge.

    Questo problema si verifica in un Edge in cui sono configurate più di 400 regole IP nella sezione Configura (Configure) > Firewall > Accesso all'Edge (Edge Access) (indirizzi IP consentiti da Accesso assistenza (Support Access) o Accesso SNMP (SNMP Access)). Quando l'Edge tenta di inviare la configurazione del firewall in questo scenario, il processo di gestione esaurisce la CPU e si verifica il timeout, quindi il processo si ripete.

    Nei siti dei clienti che utilizzano anche una topologia ad alta disponibilità, i sintomi potrebbero includere gli eventi sconosciuti dell'HA poiché l'Edge attivo non invia heartbeat all'interno della finestra temporale prevista.

  • Problema 84225 risolto: Quando l'interfaccia di un VMware SD-WAN Edge connesso diventa inattiva, la subnet configurata viene comunque ridistribuita in OSPF o BGP.

    L'Edge attira il traffico dal peer per la subnet quando è inattivo e può causare interruzioni del traffico perché il peer preferisce questo percorso rispetto agli altri alternativi per la subnet.

    In un Edge che non include la correzione per questo problema, l'utente deve riavviare l'Edge in una finestra di servizio pianificata per eliminare il problema.

  • Problema 84313 risolto: Nell'azienda di un cliente con una topologia hub/spoke è possibile che un link overlay IPv6 venga annunciato ai peer underlay dei VMware SD-WAN Edge spoke.

    Quando si configura un indirizzo IPv6 nell'overlay e si abilita l'annuncio, anche l'indirizzo stesso viene annunciato tramite l'underlay.

  • Problema 84741 risolto: Un utente nota statistiche della velocità effettiva non precise nelle schermate Monitora (Monitor) > Trasporto (Transport).

    I pacchetti RX (in entrata) e le statistiche del link non vengono incrementati in Orchestrator per il traffico inviato direttamente in un'interfaccia in cui l'opzione Inoltro percorso inverso (Reverse Path Forwarding) è disattivata nell'overlay WAN.

  • Problema 84790 risolto: Quando un VMware SD-WAN Edge con un tipo di modello qualsiasi diverso da 510/510-LTE viene riavviato, può segnalare erroneamente l'evento critico Unable to launch service wifihang a VMware SASE Orchestrator.

    Il messaggio di evento wifihang è progettato per essere utilizzato solo con i modelli Edge 510/510-LTE e avvisa il cliente quando si verifica un problema relativo al processo Wi-Fi di tale Edge. Quando questo messaggio di evento viene visualizzato in qualsiasi altro modello di Edge, indipendentemente dal fatto che utilizzi o meno il Wi-Fi (ad esempio, nell'Edge 3400), il messaggio di evento è falso e può essere ignorato.

  • Problema 85154 risolto: Quando un VMware SD-WAN Edge virtuale in AWS con tipo di istanza C4.xlarge viene aggiornato da una versione precedente dell'Edge a una versione più recente (inclusa la 4.3.1) e ne viene quindi eseguito il downgrade a una versione precedente l'Edge passa a uno stato disattivato in cui non crea tunnel di gestione con il Gateway e Orchestrator.

    La causa del problema è che Orchestrator disattiva erroneamente l'Edge e, per tale motivo, Orchestrator rileva una mancata corrispondenza del numero di serie.

    Non esistono soluzioni per questo problema oltre a NON eseguire il downgrade dalla versione più recente dell'Edge una volta che AWS Edge è stato aggiornato a questa versione.

  • Problema 85156 risolto: per un sito distribuito con una topologia in alta disponibilità, il cliente può notare più riavvii del VMware SD-WAN Edge di standby, con possibile interruzione del traffico.

    La logica di elaborazione della sincronizzazione dei dati di controllo HA nell'Edge di standby per i dati ricevuti tramite TCP può determinare una lettura parziale dei dati. Questo può causare l'elaborazione di più messaggi brevi nel nodo di standby, con conseguente rallentamento del nodo stesso. Nelle piattaforme Edge di fascia inferiore (ad esempio, i modelli Edge 510, 520, 610 e 620), il rallentamento può influire in modo significativo sull'elaborazione dell'heartbeat tra nodo attivo e di standby e questo comporta l'errata promozione dell'Edge di standby ad Edge attivo. In uno stato attivo/attivo, il tie-break passa all'Edge attivo e l'Edge di standby viene riavviato per riportarne il livello allo stato di standby corretto.

    Quando questo problema si verifica in una topologia HA convenzionale, l'impatto per il cliente è minimo perché l'Edge di standby non trasmette il traffico del cliente. In una distribuzione in alta disponibilità avanzata, in cui anche l'Edge di standby trasmette il traffico, i riavvii possono interrompere il traffico del cliente. 

    La correzione per questo errore aggiunge miglioramenti alla logica di elaborazione del messaggio TCP dell'Edge per migliorare le prestazioni nell'Edge di standby e impedire il rallentamento del sistema.

  • Problema 85269 risolto: Per le aziende dei clienti che utilizzano una topologia hub/spoke in cui è configurato il multicast, un ricevitore multicast potrebbe non ricevere l'origine del traffico dietro un Edge hub in cui l'indirizzo IP di origine viene impostato manualmente nell'Edge hub o nell'Edge spoke, ma non in entrambi.

    I registri pimd e i comandi di debug forniscono agli utenti la conferma se l'invio dell'unione PIM non riesce a causa di una mancata corrispondenza tra l'indirizzo IP di un router adiacente PIM e l'indirizzo IP dell'hop successivo, impedendo a LHR di raggiungere RP ed eseguire la registrazione (*,G).

  • Problema 86098 risolto: Per un sito che utilizza una topologia ad alta disponibilità (HA) avanzata in cui viene utilizzato un link WAN PPPoE nell'Edge di standby, è possibile che l'utente noti che la route del proxy predefinita non è installata nell'Edge attivo e il traffico che utilizza tale link non riesce.

    Quando viene attivata una coppia di Edge in una topologia ad alta disponibilità (HA) avanzata, il link PPPoE viene sincronizzato con l'Edge di standby e fornisce una route predefinita con un hop successivo 0.0.0.0. Di conseguenza, questa route non viene installata nell'Edge attivo e il traffico che utilizza questo link viene eliminato.

  • Problema 86994 risolto: Nell'azienda di un cliente in cui è attivata l'opzione Da filiale a filiale dinamico (Dynamic Branch-to-Branch) quando si tenta di risolvere i problemi di un VMware SD-WAN Edge il comando di debug dispcnt non funziona.

    Il comando di debug dispcnt non fornisce tutti i valori dei contatori e non viene eseguito correttamente visualizzando il messaggio di errore Domain (null) does not exist. Questa operazione non riesce anche quando si fa riferimento ai registri pertinenti in un bundle di diagnostica dell'Edge. Questo ostacola notevolmente la risoluzione dei problemi di rete di un cliente.

    Questo problema si verifica nelle aziende in cui è attivata l'opzione Da filiale a filiale dinamico (Dynamic Branch-to-Branch) a causa della grande quantità di tunnel che vengono creati e rimossi verso ogni peer. I contatori che includono varie metriche dei peer vengono archiviati in una memoria condivisa e, nel tempo, lo stato di questi segmenti di memoria condivisa diventa non valido a causa di una collisione e i contatori non vengono recuperati dal comando dispcnt.

    Questo problema può essere risolto solo eseguendo un riavvio del servizio dell'Edge.

  • Problema 87205 risolto: Per un cliente che distribuisce un VMware SD-WAN Edge con un gateway partner, quando un Edge acquisisce nuove route dal gateway partner, il traffico del cliente potrebbe essere interrotto.

    Questo problema è causato dal traffico che corrisponde al criterio di business errato. Ad esempio, il traffico DHCP destinato al gateway partner potrebbe corrispondere alla regola di backhaul Internet con una conseguente interruzione del traffico del cliente.

    Senza la correzione, il problema viene risolto svuotando i flussi dell'Edge tramite Diagnostica remota (Remote Diagnostics) > Svuota flussi (Flush Flows). Questa correzione non impedisce che si verifichino potenziali eventi futuri quando l'Edge acquisisce nuovi percorsi verso il gateway partner.

  • Problema 87552 risolto: Quando un VMware SD-WAN Edge è configurato per utilizzare una destinazione non SD-WAN (NSD) tramite Edge o un servizio di sicurezza cloud (CSS), è possibile che in tale VMware SD-WAN Edge si verifichi periodicamente un errore del servizio piano dati che causa un riavvio quando i tunnel NSD o CSS sono instabili.

    Quando l'Edge elimina un tunnel verso un NSD o un CSS (IPSec o GRE), viene eseguita la versione errata di un tunnel scelto in precedenza che attiva un'eccezione nel servizio piano dati dell'Edge e un riavvio del servizio Edge per ripristinare il servizio. Il riavvio del servizio Edge comporterà l'interruzione del traffico del cliente per 10-15 secondi.

    In un Edge senza una correzione per questo problema, associando un NSD tramite Edge o CSS a un link WAN è possibile ridurre le probabilità che il problema si verifichi. In altre parole, anziché configurare un NSD o un CSS in più link WAN, scegliere un solo link WAN. Questa operazione comporterà la perdita di ridondanza, ma ridurrà l'impatto del problema.

  • Problema 88055 risolto: Nei modelli di VMware SD-WAN Edge 3x00, un cliente può notare che quando la velocità effettiva viene mantenuta almeno a 10 Gbps, la latenza del percorso WAN può bloccarsi e influire sulla stabilità e la velocità effettiva dell'Edge.

    Negli ambienti 10 G con una rapida deviazione clock tra gli endpoint VCMP, le misure della latenza del percorso WAN possono bloccarsi influendo sull'efficacia di DMPO (Dynamic Mutlipath Omptization) e ciò comporta una selezione del percorso non corretta e un peggioramento della velocità effettiva.

  • Problema 88152 risolto: Le richieste SNMP a un'interfaccia secondaria di VMware SD-WAN Edge non funzionano.

    Questo è un comportamento del giorno uno per cui si verifica il timeout di tutte le richieste SNMP a un'interfaccia secondaria dell'Edge. La correzione di questo problema aggiunge il supporto per queste richieste SNMP a un'interfaccia secondaria dell'Edge.

  • Problema 88317 risolto: In un VMware SD-WAN Edge che utilizza link pubblici e privati e in cui è configurata l'opzione SD-WAN raggiungibile (SD-WAN Reachable), quando un link pubblico diventa inattivo, il traffico diretto non utilizza il link privato come previsto.

    Quando un criterio di business è impostato in modo da preferire il link pubblico, il flusso non utilizza il link privato raggiungibile di SD-WAN mentre il link pubblico preferito è inattivo. La correzione aggiunge la logica per consentire anche i link raggiungibili di SD-WAN quando la selezione del link diretto tenta di individuare i link privati come ultima risorsa.

  • Problema 88550 risolto: Per i clienti che utilizzano Edge Network Intelligence, un VMware SD-WAN Edge non è in grado di comunicare con il servizio Edge Network Intelligence quando non è configurato esplicitamente un DNS.

    Quando non è configurato in modo esplicito un DNS, il servizio Edge Network Intelligence utilizza il DNS di Google per impostazione predefinita. Se DNS sceglie un'interfaccia di loopback come interfaccia di origine, la raggiungibilità del servizio viene interrotta a causa di un errore di ricerca DNS.

    Per l'azienda di un cliente che non utilizza una build dell'Edge con la correzione, la soluzione consiste nel configurare DNS in modo esplicito in Orchestrator e scegliere come interfaccia di origine un'interfaccia reale anziché un'interfaccia di loopback virtuale.

  • Problema 89364 risolto: Per un sito che utilizza una topologia ad alta disponibilità (HA) avanzata, se un utente esegue Diagnostica remota (Remote Diagnostics) > Stato interfaccia (Interface Status), la velocità del link dell'interfaccia dell'Edge di standby è 0 Mbps/half duplex.

    I dettagli relativi alla velocità e alla negoziazione automatica non vengono recuperati dall'Edge di standby in cui l'interfaccia è attiva e i dettagli non vengono visualizzati correttamente.

  • Problema 89596 risolto: È possibile che in un VMware SD-WAN Edge si verifichi un errore del servizio piano dati e che venga eseguito un riavvio che causa l'interruzione del traffico del cliente.

    Questo problema può verificarsi quando un cliente configura NAT. Quando viene stabilito un nuovo flusso che utilizza NAT, esiste una race condition molto rara che può causare un'eccezione nel servizio Edge che causa un errore e un riavvio.

    Senza la correzione per questo problema, l'unico modo per evitarlo è disabilitare NAT.

  • Problema 89725 risolto: Per i VMware SD-WAN Edge che utilizzano versioni del software dell'Edge precedenti alla 5.1.0, è possibile che il test della larghezza di banda del link WAN delle utilità di diagnostica remota e Traceroute non funzionino.

    Il test della larghezza di banda del link WAN e Traceroute richiedono un input aggiuntivo per l'interfaccia (per il test della larghezza di banda) o l'indirizzo IP (per Traceroute). Quando si verifica questo problema, l'utente non può configurare tali input perché non viene visualizzata l'opzione del menu a discesa, quindi il test in entrambe le istanze genera un errore.

  • Problema 90044 risolto: Quando un VMware SD-WAN Gateway è configurato con un probe ICMP e il Gateway viene riavviato, il probe ICMP non viene ripristinato e rimane inattivo.

    Lo stato del probe ICMP in debug.py --icmp è indicato come INATTIVO dopo il riavvio del Gateway.

    In un Gateway che non include la correzione per questo problema, la soluzione consiste nel disattivare il probe ICMP e quindi riattivarlo.

  • Problema 90098 risolto: Per l'azienda di un cliente in cui è configurata la VPN da filiale a filiale in alcuni scenari è possibile che l'esecuzione di un tunnel venga provata all'infinito anche se non può mai diventare attivo a causa di una modifica della configurazione.

    Lo scenario coinvolge un Edge che tenta di creare un tunnel con un Edge peer che è offline o in cui è stato modificato l'indirizzo IP. L'Edge non comprende che il peer è irraggiungibile e tenta continuamente di creare un tunnel verso la destinazione inesistente compromettendo le prestazioni complessive. L'Edge non può essere arrestato dal cliente.

    Il problema è causato dalla mancanza di limite per la scadenza dei tunnel da filiale a filiale che non funzionano. È inoltre difficile risolvere il problema perché non viene generato alcun messaggio che indica dove l'Edge riceve il messaggio di risposta da filiale a filiale e non è presente alcun comando di debug nel Gateway connesso che consenta di visualizzare le informazioni da filiale a filiale valide per un peer.

  • Problema 90216 risolto: Traceroute potrebbe non visualizzare l'indirizzo IP corretto di un VMware SD-WAN Edge hub quando il flusso di traffico proviene da Client > Edge spoke (Spoke Edge) > Hub > Server.

    Se in un Edge spoke è configurato un Criterio di business (Business Policy) per eseguire il backhaul del traffico verso un Edge hub con Gruppo di trasporto (Transport Group) configurato per utilizzare Cablato privato (Private Wired) e Obbligatorio (Mandatory), quando il pacchetto traceroute raggiunge l'Edge hub, l'Edge hub risponde con l'indirizzo IP errato (in questo caso, l'indirizzo IP pubblico anziché l'indirizzo IP privato) al traceroute.

  • Problema 90884 risolto: Per un'azienda cliente che utilizza una topologia cluster hub/spoke, quando un hub edge del cluster viene riassegnato a uno o più Edge spoke, gli utenti di tali posizioni Edge spoke possono subire un'interruzione del traffico.

    Gli Edge in un cluster possono essere riassegnati come parte di un ribilanciamento del cluster quando un'azienda aggiorna il proprio software Edge. Questo problema potrebbe verificarsi dopo l'aggiornamento. Quando si verifica questo problema, il VMware SD-WAN Gateway non invia le nuove route dell'Edge spoke all'Edge hub perché il gateway prevede che tutti gli Edge hub abbiano tutte le route dell'Edge spoke e quindi queste route non sono nella tabella di routing dell'Edge hub. Di conseguenza, il traffico tra gli Edge spoke e l'Edge hub nel cluster ne risente perché il percorso di inoltro è inattivo.

    Se il problema viene riscontrato in un'azienda che non utilizza gateway con una correzione a questo problema, è possibile risolverlo temporaneamente eseguendo un reintegro della route sull'Edge hub. Tuttavia, il problema potrebbe ripresentarsi con una nuova riassegnazione di un Edge hub.

  • Problema 91164 risolto: Nell'azienda di un cliente distribuita con una topologia hub/spoke in cui il VMware SD-WAN Edge hub è configurato per l'alta disponibilità, è possibile che l'Edge hub HA non inoltri il traffico di backhaul Internet dopo un failover HA.

    Il problema si verifica solo in uno scenario in cui 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 di overlay non WAN. Quando l'Edge di standby viene quindi promosso ad Edge attivo in un failover HA, questi fattori causano un errore del traffico di backhaul Internet.

  • Problema 91188 risolto: Il ping IPv6 a un host connesso a una VLAN in un'interfaccia commutata non riesce se viene eseguito quando si utilizza Diagnostica remota (Remote Diagnostics) > Ping e si seleziona l'interfaccia VLAN come interfaccia di origine.

    Il nome dell'interfaccia di origine "VLAN-x" è noto solo al VMware SD-WAN Edge e il sistema operativo dell'Edge richiede l'interfaccia di origine nel formato "br-networkx" perché l'interfaccia della VLAN viene creata con tale nome nel sistema operativo dell'Edge.

  • Problema 91203 risolto: Nell'azienda di un cliente configurata con una topologia hub/spoke in cui il VMware SD-WAN Edge spoke è configurato per il backhaul del traffico tramite un Edge hub, un utente può notare prestazioni del traffico scarse per i flussi di backhaul.

    Il leg del backhaul nell'Edge hub è determinato dai tipi di route di origine e destinazione (in altre parole, l'origine è l'azienda e la destinazione è il cloud), ma questo approccio può causare un comportamento incoerente perché dipende da eventi imprevisti basati sulle modifiche della route e può causare l'eliminazione dei pacchetti per i flussi sottoposti a backhaul. La correzione di questo problema consiste nel fare in modo che il leg del backhaul venga determinato in base alla messaggistica dell'Edge spoke.

  • Problema 92454 risolto: Diagnostica remota (Remote Diagnostics) > Traceroute non funziona quando nel campo Destinazione (Destination) viene immesso un nome di dominio che viene risolto solo in un indirizzo IPv4.

    Se un nome di dominio viene risolto solo in un indirizzo IPv4, il comando Traceroute eseguito tramite Diagnostica remota (Remote Diagnostics) non funziona. Il problema si verifica perché VMware SD-WAN Edge tenta sempre di risolvere il nome di dominio per il record IPv6 e non riesce a trovare l'indirizzo IPv4.

    In un Edge senza questa correzione, la soluzione consiste nell'utilizzare l'indirizzo IPv4 corrispondente al nome di dominio direttamente nel comando Traceroute. L'indirizzo IPv4 può essere ottenuto specificando il nome di dominio in Diagnostica remota (Remote Diagnostics) > Test DNS (DNS Test).

  • Problema 92758 risolto: In un sito con una topologia ad alta disponibilità (HA), è possibile che si verifichino diversi problemi nei VMware SD-WAN Edge HA, tra cui uno stato del LED non corretto o un errore di HA.

    Lo stato del LED non corretto nell'Edge attivo viene visualizzato come giallo anziché verde anche se l'Edge è attivo e i link WAN sono attivi e stabili.

    Questo problema è dovuto al danneggiamento della memoria condivisa nell'Edge che si manifesta in diversi modi. Può essere confermato recuperando i contatori con lo strumento getcntr per un dominio specifico come vcedge.com. L'output dello strumento indica che il dominio non esiste e il nome del contatore non è stato trovato.

    VMware SD-WAN utilizza la chiamata di sistema ftok () per recuperare le chiavi della memoria condivisa SYSV. ftok() utilizza gli ultimi 16 bit di inode per calcolare la chiave. Ciò può causare una collisione di chiavi quando i numeri di inode sono diversi in base ad almeno 64K. Quando si verifica una collisione di questo tipo, i contatori della memoria condivisa del tunnel dinamico possono danneggiare le variabili della memoria condivisa globali causando diversi possibili problemi dell'Edge, tra cui uno stato del LED non corretto, l'incapacità dei contatori o un errore di HA.

  • Problema 93062 risolto: Quando un utente esegue la diagnostica remota "Stato interfaccia" (Interface Status) in VMware Orchestrator, Orchestrator restituisce un errore per tale test e il test non viene completato oppure non restituisce risultati per le interfacce instradate.

    Il messaggio di errore visualizzato è "errore durante la lettura dei dati per il test" (error reading data for test). Se il test non viene completato, i risultati per le interfacce instradate sono vuoti e non contengono informazioni sulla velocità o sul duplex. In entrambi i casi lo stato dell'interfaccia viene interrotto. Il problema è correlato al comando di debug sottostante a Stato interfaccia (Interface Status) che omette le porte attivate da DPKD.

    In un Edge senza questa correzione, l'utente deve generare un bundle di diagnostica per l'Edge per visualizzare lo stato dell'interfaccia instradata

  • Problema 93853 risolto: In un VMware SD-WAN Gateway con un carico elevato è possibile che si verifichi un errore del servizio piano dati con un codice SIGXCPU e che il servizio venga riavviato per il ripristino.

    Quando il carico è elevato, in diversi thread del Gateway che eseguono varie attività, come il routing e la registrazione, le risorse CPU sono insufficienti e non è possibile completare l'attività entro il periodo di tempo stabilito. Il servizio Gateway interpreta questi thread in ritardo come completamente bloccati e attiva il segnale SIGXCPU che causa l'interruzione del processo del piano dati del Gateway.

  • Problema 94204 risolto: Un utente può notare che i tentativi di generare un bundle di diagnostica per un VMware SD-WAN Edge compatibile con VNF non riescono.

    Il completamento di un bundle di diagnostica in un Edge compatibile con VNF non riesce perché nell'Edge lo spazio su disco è insufficiente. Questo problema può verificarsi se l'Edge ha generato uno o più core e li invia alla cartella /vnf/tmp. Il pacchetto di ogni core viene decompresso nella cartella /vnf/tmp che viene quindi riempita rapidamente causando la mancata riuscita del bundle di diagnostica. 

    Gli Edge compatibili con VNF (Virtual Network Function) includono i seguenti modelli: 520v, 620, 640, 680 e 840.

  • Problema 94401 risolto: In un VMware SD-WAN Edge in cui è abilitato il firewall stateful, è possibile che il timeout di un flusso TCP stabilito si verifichi troppo rapidamente e che il flusso venga cancellato.

    Il flusso TCP stabilito viene considerato come un flusso TCP non stabilito ed è soggetto a un timeout più breve. Quando in un flusso TCP si verifica una reimpostazione di TCP, seguita da un handshake a 3 vie TCP, anche se lo stato di TCP è Stabilito, il flusso viene cancellato dopo essere stato sottoposto a un timeout del flusso TCP non stabilito.

  • Problema 94612 risolto: È possibile che il traffico verso il prefisso di rete BGP non sia raggiungibile.

    Quando si verifica questo problema, il prefisso di rete BGP non è configurato in BGP e non viene annunciato ai nodi peer.

    In un Edge che non contiene alcuna correzione per questo problema, l'unica soluzione consiste nell'eliminare le reti BGP e riconfigurarle.

  • Problema 94775 risolto: Nell'azienda di un cliente che utilizza una topologia hub/spoke in cui il VMware SD-WAN Edge spoke esegue il backhaul del traffico tramite un Edge hub, gli utenti del client possono notare problemi di prestazioni del traffico.

    Il problema si verifica perché per il traffico sottoposto a backhaul viene impostato un flag errato e i pacchetti sottoposti a backhaul vengono gestiti nell'Edge spoke come se si trovassero nell'Edge hub. Ciò comporta problemi di ricerca della route nell'hub e i pacchetti di backhaul vengono eliminati.

  • Problema 94980 risolto: Per un sito distribuito con una topologia ad alta disponibilità, è possibile che nel VMware SD-WAN Edge di standby si verifichi un errore del servizio piano dati e un riavvio dopo la configurazione di un link WAN PPPoE per gli Edge HA.

    Quando si esamina il core generato dall'Edge di standby, viene visualizzato il messaggio vc_is_use_cloud_gateway_set dopo la configurazione del link PPPoE.

    In un sito HA senza una correzione per questo problema, il cliente deve assicurarsi che il link PPPoE venga configurato solo in una finestra di manutenzione per gestire il rischio di questo problema.

  • Problema 95047 risolto: Quando un'utilità di scansione della porta di sicurezza esegue la scansione di un VMware SD-WAN Edge in cui Edge Network Intelligence (Analisi) non è attivato, la scansione segnala che la porta syslog 514 è chiusa, il che significa che potrebbe essere accessibile.

    Edge Network Intelligence è in ascolto nella porta 514 (syslog). Se la funzionalità Analisi (Analytics) non è attivata, la porta 514 è comunque accessibile, ma non risponde alle richieste. Uno strumento di analisi delle porte segnala quindi la porta come "chiusa" (in altre parole, la porta è accessibile ma non c'è alcuna applicazione in ascolto in tale porta).

  • Problema 95121 risolto: Quando in un VMware SD-WAN Edge modello 510-LTE o 610-LTE viene utilizzata una "SIM bloccata" (ovvero una SIM bloccata tramite password), il cliente non riesce a stabilire la connessione nella rete perché si verificano errori.

    Quando gli utenti utilizzano schede SIM LTE bloccate con slot SIM dei modelli di Edge 510-LTE e 610-LTE, si verificano errori durante il tentativo di stabilire il percorso perché lo sblocco della SIM non funziona da Orchestrator e ciò è dovuto alla mancanza di supporto delle SIM bloccate negli script ModemManager dell'Edge.

  • Problema 95501 risolto: Nell'azienda di un cliente che utilizza una topologia hub/spoke e BGP per il routing, gli utenti del client nei VMware SD-WAN Edge spoke possono notare prestazioni del traffico scarse.

    Un amministratore può notare che l'Edge spoke preferisce le route contrassegnate con community uplink da un hub non incluso nel proprio profilo rispetto all'Edge hub configurato per essere utilizzato per tale Edge spoke. Ciò è dovuto al fatto che il traffico dell'Edge spoke utilizza un percorso dinamico da filiale a filiale per i prefissi di uplink.

    Il problema è causato dal fatto che SD-WAN reimposta il flag di uplink per i messaggi di routing ricevuti da un Edge hub. Di conseguenza, quando viene creato un tunnel dinamico da filiale a filiale, per questi prefissi di uplink vengono installate route dirette che causano un routing non ottimale e prestazioni del traffico scarse.

  • Problema 95565 risolto: 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.

    In una coppia di Edge HA in cui si verifica il problema e non è disponibile la correzione, la soluzione consiste nel disabilitare SNMP poiché si tratta di un problema di temporizzazione e questa operazione riduce, ma non elimina, il rischio che si verifichi.

  • Problema 96626 risolto: Quando a un'interfaccia di VMware SD-WAN Edge è assegnato un indirizzo IP secondario, le connessioni tramite l'indirizzo IP secondario non riescono.

    Qualsiasi richiesta proveniente da un'altra filiale a un IP nella rete secondaria genererà un ARP dall'indirizzo IP primario anziché dall'indirizzo IP secondario. Di conseguenza, l'ARP rimarrà non risolto causando un errore nel traffico che passa attraverso l'indirizzo IP secondario.

  • Problema 96739 risolto: Quando un utente esamina la scheda Monitora (Monitor) > Applicazione (Application) per un VMware SD-WAN Edge in un VMware SASE Orchestrator, è possibile che nella schermata vengano visualizzati i nomi di dominio completi di destinazione con nomi di dominio errati.

    Questo problema può verificarsi quando le statistiche dell'Edge raggiungono il limite (noto come condizione di overflow) e anziché visualizzare queste statistiche come overflow, Orchestrator visualizza nomi di dominio casuali in Nome di dominio completo destinazione (Destination FQDN) nella scheda Applicazione (Application).

  • Problema 96994 risolto: Quando si esegue un snmpwalk in un VMware SD-WAN Edge, è possibile che alcune delle interfacce non siano visibili.

    Le interfacce mancanti possono essere interfacce valide che avrebbero dovuto essere visibili in snmpwalk. Ma poiché nell'elenco di hardware dell'Edge viene visualizzata un'interfaccia non valida, le interfacce valide visualizzate dopo quella non valida nell'elenco non saranno visibili e non verranno restituite da snmpwalk. Un'interfaccia in questo caso non è valida se viene visualizzata nell'elenco di hardware ma non viene visualizzata quando si esegue il comando ifconfig nell'Edge.

    Anche se questo problema può verificarsi in qualsiasi Edge, è più probabile che si verifichi in un Edge virtuale distribuito tramite Azure. Ciò è dovuto al fatto che l'Edge di Azure tende a inserire nell'elenco di hardware un numero di interfacce maggiore di quello che si ottiene nell'Edge stesso utilizzando ifconfig.

  • Problema 97152 risolto: Quando l'azienda di un cliente ha un criterio di business configurato con un gruppo di servizi come qualsiasi elemento cablato e la modalità collegamento è impostata su "Disponibile" (Available), il traffico non viene reindirizzato a un link wireless quando i collegamenti cablati diventano inattivi e gli utenti client nel sito notano che il traffico corrispondente a tale regola non riesce.

    Quando una regola del criterio di business include un gruppo di servizi esplicito di link WAN cablati con la modalità collegamento impostata su Disponibile (Available) e nel sito sono disponibili link wireless, si verificherà il failover del traffico che utilizza tale regola ai collegamenti WAN cablati se i link cablati nel gruppo di servizi sono diventati inattivi (in altre parole, non sono più disponibili) per garantire il flusso continuo del traffico corrispondente a tale regola. In questo problema, il reindirizzamento del traffico ai link wireless non si verifica.

  • Problema 97321 risolto: Dal momento in cui un utente attiva le funzionalità di analisi di Edge Network Intelligence in un VMware SD-WAN Edge, l'Edge può potenzialmente attivare un riavvio del servizio Edge, ogni istanza del quale causa 10-15 secondi di interruzione del traffico del cliente.

    Quando l'analisi è abilitata nell'Edge, è possibile che nell'Edge si verifichi una condizione di memoria insufficiente seguita da uno stato di memoria "double free". L'Edge riavvia il servizio per ripristinare la memoria.

    I sintomi di questo problema possono verificarsi più volte mentre l'analisi è attivata.

  • Problema 99718 risolto: Il router adiacente BGP non viene stabilito quando viene utilizzato l'indirizzo IP secondario nell'interfaccia virtuale di uno switch.

    Quando l'Edge elabora i pacchetti in ingresso, verifica se l'indirizzo di destinazione del pacchetto in ingresso corrisponde all'indirizzo IP dell'interfaccia in ingresso. Poiché vengono confrontati solo gli indirizzi IP primari, i pacchetti con un indirizzo IP di destinazione come indirizzo IP secondario vengono eliminati. Di conseguenza, la sessione BGP non viene creata in questo IP secondario.

  • Problema 100363 risolto: È possibile che in un VMware SD-WAN Gateway si verifichi un errore del servizio piano dati e che venga attivato un riavvio del servizio che causa un'interruzione del traffico di 1-5 secondi.

    Questo problema si è verificato durante il test di stress con l'errore in futex_abstimed_wait causando un thread con deadlock che attiva l'errore e il riavvio del servizio.

Problemi risolti di Orchestrator

Risolto nella versione R51010-20231215-GA di Orchestrator

La build R51010-20231215-GA di Orchestrator è stata rilasciata il 18-12-2023 ed è il decimo rollup di Orchestrator per la versione 5.1.0.

Questa build di rollup di Orchestrator risolve il seguente problema critico presente a partire dalla nona build di rollup di Orchestrator, ovvero R5109-20231003-GA.

  • Problema 117941 risolto: La casella di controllo Annuncio VLAN (VLAN Advertise) viene sempre visualizzata come deselezionata nell'interfaccia utente di Orchestrator.

    Anche quando un utente seleziona la casella di controllo Annuncio VLAN (VLAN Advertise) e Salva modifiche (Save Changes), la casella di controllo Annuncio VLAN (VLAN Advertise) nell'interfaccia utente di Orchestrator viene deselezionata.

  • Problema 125006 risolto: 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.

    In un Orchestrator senza una correzione, il modo per evitare questo problema consiste nell'aumentare il valore della 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 128310 risolto: A causa di alcuni problemi del servizio di database di Orchestrator, è possibile che per gli utenti di VMware SASE Orchestrator si verifichi un rallentamento generale e alcuni errori dell'API. Altri effetti negativi includono i seguenti: gli SD-WAN Gateway o gli SD-WAN Edge vengono visualizzati offline nell'interfaccia utente, le modifiche della configurazione apportate tramite l'interfaccia utente di Orchestrator non vengono inviate agli SD-WAN Edge di destinazione e le funzionalità di creazione report vengono perse.

    Questi problemi sono tutti causati dal fatto che il servizio di database di Orchestrator non viene eseguito correttamente e viene visualizzato il messaggio di errore: troppi file aperti (too many open files). Questo errore può essere notato da un utente operatore in VMware SASE Orchestrator tramite i registri. Per un utente aziendale o partner che accede a VMware SASE Orchestrator tramite l'interfaccia utente potrebbero verificarsi un rallentamento ed errori intermittenti dell'API che causano la visualizzazione di messaggi di errore nell'interfaccia utente.

  • Problema 129239 risolto: Nella pagina Configura (Configure) > Profilo (Profile) dell'interfaccia utente di Orchestrator, quando un utente modifica un'impostazione a livello di profilo e tenta di eseguire il salvataggio, è possibile che si verifichi il timeout della chiamata API che non riesce.

    Quando si verifica questo problema, nella pagina del browser dell'interfaccia utente di Orchestrator viene visualizzato un banner di errore rosso che indica "timeout di configuration/updateConfigurationModule" (configuration/updateConfigurationModule time out). Il problema si verifica perché il completamento di altre query del database di Orchestrator impiega troppo tempo causando il timeout del tentativo di salvataggio delle nuove impostazioni del profilo.

  • Problema 131789 risolto: Quando si configura Single Sign-On (SSO) per un'organizzazione, anche se le informazioni sul ruolo sono presenti nella risposta del provider di identità, gli utenti non possono accedere a Orchestrator.

    In Orchestrator non è possibile stabilire la corrispondenza con il ruolo di un utente che accede tramite Single Sign-On (SSO), se il provider di identità invia informazioni sul ruolo in una struttura JSON nidificata. A partire dalla versione 5.0.1.7, Orchestrator può fare riferimento e stabilire una corrispondenza con il ruolo di un utente SSO, anche se è presente in una struttura JSON nidificata. Se il problema si verifica in un Orchestrator che non dispone di una correzione, la soluzione consiste nel configurare il provider di identità in modo che invii i dettagli del ruolo nel livello immediato e non nella struttura nidificata.

Problemi risolti nella versione R5109-20231003-GA di Orchestrator

La build R5109-20231003-GA di Orchestrator è stata rilasciata il 05/10/2023 ed è il nono rollup di Orchestrator per la versione 5.1.0.

Questa build di rollup di Orchestrator risolve il seguente problema critico presente a partire dall'ottava build di rollup di Orchestrator, ovvero R5108-20230916-GA.

  • Problema 119938 risolto: Per un cliente che utilizza l'automazione per i tunnel Zscaler, la creazione di un tunnel IPSec automatizzato da un VMware SD-WAN Edge a Zscaler può richiedere molto tempo.

    Quando i clienti configurano le posizioni secondarie di Zscaler in Edge > Impostazioni dispositivo (Device Settings), la sincronizzazione di queste configurazioni con il cloud Zscaler può richiedere molto tempo. Questo problema si verifica perché il cloud Zscaler deve aggiornare i record per ogni posizione secondaria e questo processo può richiedere molto tempo.

    Il problema è causato dal fatto che il framework di automazione in Orchestrator inserisce nella coda di automazione le azioni di creazione del tunnel IPSec e della posizione secondaria. Nella coda di automazione inserisce anche le azioni di aggiornamento quando l'IP della WAN dell'Edge viene modificato. Tuttavia, il tempo di attesa per gli elementi nella coda aumenta a causa del numero elevato di azioni di aggiornamento. In alcuni ambienti di distribuzione dei clienti, l'IP della WAN dell'Edge può cambiare fino a 4.000 volte in un giorno (ad esempio, nel caso dei link WAN mobili).

  • Problema 128310 risolto: A causa di alcuni problemi del servizio di database di Orchestrator, è possibile che per gli utenti di VMware SASE Orchestrator si verifichi un rallentamento generale e alcuni errori dell'API. Altri effetti negativi includono i seguenti: gli SD-WAN Gateway o gli SD-WAN Edge vengono visualizzati offline nell'interfaccia utente, le modifiche della configurazione apportate tramite l'interfaccia utente di Orchestrator non vengono inviate agli SD-WAN Edge di destinazione e le funzionalità di creazione report vengono perse.

    I problemi sono tutti causati dal fatto che il servizio di database di Orchestrator non viene eseguito correttamente e viene visualizzato il messaggio di errore: troppi file aperti. Questo errore può essere notato da un utente in VMware SASE Orchestrator tramite i registri. Per un utente aziendale o partner che accede a VMware SASE Orchestrator tramite l'interfaccia utente potrebbero verificarsi un rallentamento ed errori intermittenti dell'API che causano la visualizzazione di messaggi di errore nell'interfaccia utente.

Problemi risolti nella versione R5108-20230916-GA di Orchestrator

La build R5108-20230916-GA di Orchestrator è stata rilasciata il 20/09/2023 ed è l'ottavo rollup di Orchestrator per la versione 5.1.0.

Questa build di rollup di Orchestrator risolve il seguente problema critico presente a partire dalla settima build di rollup di Orchestrator, ovvero R5107-20230722-GA.

  • Problema 94610 risolto: Quando un utente avvia un failover HA forzato tramite Azioni remote (Remote Actions) > Forza failover HA (Force HA Failover), è possibile che VMware SASE Orchestrator non generi e non invii alcun avviso per il failover HA.

    Dato che il failover HA è forzato da Orchestrator, sia l'Edge attivo che quello in standby anticipano il failover e questo può causare l'invio di entrambi i messaggi HA_GOING_ACTIVE e HA_READY nello stesso heartbeat da parte dell'Edge HA. Se lo "Stato HA (HA State)" inviato nell'heartbeat è "Pronto (Ready)", Orchestrator non genera un avviso per il failover perché vede solo il messaggio "Pronto (Ready)" e non quello "In attivazione (Going Active)".

  • Problema 104775 risolto: Quando un utente configura un link WAN precedentemente attivo in un VMware SD-WAN Edge come backup, lo stato non viene visualizzato correttamente in Monitora (Monitor) > Edge > Panoramica (Overview) nell'interfaccia utente di VMware SASE Orchestrator.

    Lo stato dovrebbe essere Standby o Inattivo (Idle) con un punto di colore grigio, ma il tipo di link o lo stato del backup non viene invece visualizzato. Si tratta solo di un problema di visualizzazione perché il link WAN esegue il proprio ruolo come backup.

  • Problema 105580 risolto: In un VMware SASE Orchestrator in cui è configurata la modalità FIPS, è possibile che il tentativo di configurare Disaster Recovery (DR) per Orchestrator non riesca.

    SSL_CTX_new non riuscito durante il tentativo di connessione. La configurazione di DR quando è configurata la modalità FIPS include una build di Orchestrator con MySQL versione 8.0.28 o successiva e non riesce durante la fase COPYING_DP di DR con il messaggio di errore: SSL_CTX_new failed when trying to connect.

  • Problema 106191 risolto: Un utente non può apportare modifiche a una configurazione di VMware SD-WAN Edge se l'Edge utilizza un profilo in cui un'interfaccia è configurata con un indirizzo IP statico.

    Se si tenta di modificare la configurazione dell'Edge, nell'interfaccia utente di VMware SASE Orchestrator viene visualizzato il messaggio di errore: "intervallo probe non valido per l'interfaccia" (invalid probe interval for interface) e non è possibile salvare le modifiche.

    In un Orchestrator senza una correzione per questo problema, l'unica soluzione consiste nel creare un nuovo profilo senza assegnazioni di interfaccia statica e applicarlo all'Edge.

  • Problema 115981 risolto: Nell'azienda di un cliente che utilizza l'APIv2 di VMware SASE Orchestrator, quando si esegue l'API per ottenere gli eventi aziendali, Orchestrator restituisce solo un set limitato.

    La chiamata specifica è https://\{api_host}//api/sdwan/v2/enterprises/{enterpriseLogicalId}/events. Quando viene richiamata, restituisce solo la gerarchia di livello superiore e include dettagli come enterpriseName, EdgeName, segmentName o edgeID. APIv2 non supporta inoltre l'attraversamento del grafico.

    In un Orchestrator senza una correzione per questo problema, l'unica soluzione consiste nell'utilizzare APIv1, che impone a un cliente di mantenere due set di famiglie di API. APIv1 non supporta inoltre Cloud Web Security.

  • Problema 116531 risolto: Se un utente tenta di generare un report in un VMware SASE Orchestrator in cui almeno una descrizione dell'Edge include una virgola (,), è possibile che il report non venga formattato correttamente.

    Quando una descrizione dell'Edge include una virgola (come illustrato nella schermata seguente), il servizio di creazione report di Orchestrator confonde la virgola e sposta il testo dopo ogni virgola nella colonna successiva del report, anziché includere l'intera stringa di testo nella colonna Descrizione Edge (Edge Description) come previsto.

    Pertanto, anziché un valore in Byte trasmessi (Bytes Transmitted) è incluso il testo dopo la prima virgola, in Byte ricevuti (Bytes Received) è incluso il testo dopo la seconda virgola (se è presente) e così via. Il report include comunque i dati relativi a Byte trasmessi (Bytes Transmitted) e Byte ricevuti (Bytes Received) ma risultano spostati verso destra e non allineati alle colonne corrette.

    In un Orchestrator senza una correzione per questo problema, l'utente deve assicurarsi che la descrizione dell'Edge non contenga virgole.

  • Problema 117822 risolto: Quando un cliente consulta Monitora (Monitor) > Edge > QoE, potrebbe riscontrare delle lacune nei grafici QoE che non sono riconducibili a problemi con i link WAN dell'Edge.

    Le lacune sono il risultato di un problema con il database di Orchestrator in cui la coda di lavoro interna per i dati di collegamento viene persa e i dati di collegamento non vengono riempiti.

  • Problema 118728 risolto: Nel portale di un partner o nell'azienda di un cliente, è possibile che alcuni utenti non siano autorizzati ad accedere a VMware SASE Orchestrator.

    È possibile che venga visualizzato il messaggio di errore "L'utente non dispone del privilegio [READ:PROXY] necessario per accedere a [enterpriseProxy/getEnterpriseProxy]" anche se l'utente dispone dei privilegi corretti per accedere. Questo problema si verifica per l'autenticazione nativa e l'autenticazione a due fattori. L'errore è dovuto a una password scaduta anche se Orchestrator non informa l'utente che questo è il vero motivo per cui non può accedere e l'utente non può reimpostare la propria password perché non può accedere.

    In un Orchestrator senza una correzione per questo problema, un amministratore del partner o del cliente con un ruolo appropriato può inviare l'e-mail di reimpostazione della password all'utente in modo che possa reimpostare la password.

  • Problema 121085 risolto: Se un amministratore del partner si trova nella pagina Impostazioni globali (Global Settings) > Gestione utenti (User Management) > Autorizzazioni servizio (Service Permissions), l'opzione "Ripristina valori predefiniti del sistema" (Reset to System Default) non funziona come previsto.

    Il comportamento previsto quando si seleziona Ripristina valori predefiniti del sistema (Reset to System Default) prevede il ripristino dello stato Non pubblicato (Unpublished) per tutti i pacchetti di autorizzazioni dei ruoli personalizzati quando vengono ripristinate le impostazioni predefinite per le autorizzazioni del ruolo utente. Tuttavia, l'utente partner nota che lo stato di uno o più pacchetti personalizzati rimane Pubblicato (Published) e ogni pacchetto che rimane Pubblicato (Published) non può essere modificato o eliminato.

  • Problema 121441 risolto: Quando un cliente attiva l'inserimento di VNF su una VLAN di un VMware SD-WAN Edge, quest'ultimo elimina e poi reimpiega la VNF, rendendola inutilizzabile per quell'Edge.

    Dopo l'attivazione dell'inserimento di VNF sulla VLAN, il cliente osserva gli eventi di cancellazione e ridistribuzione di VNF nella pagina Monitora (Monitor) > Eventi (Events) e riceve anche un'e-mail con il messaggio "(VNF_VM_DELETED) / La VNF di un fornitore sconosciuto è stata eliminata sull'edge <Nome dell'edge>". Il problema è riconducibile all'invio da parte di Orchestrator di un nuovo UUID (identificativo univoco universale) dopo l'attivazione dell'inserimento di VNF su una VLAN. L'Edge interpreta questa modifica dell'UUID come un'attivazione per eliminare la VNF e riallocarla, rendendola inutilizzabile per quell'Edge.

    Questo problema si verifica solo nella nuova interfaccia utente. Se il problema si verifica in Orchestrator 5.1.x che non include la correzione, passare all'interfaccia utente classica per configurare VNF.

  • Problema 121469 risolto: Effettuando l'accesso alla pagina Impostazioni globali (Global Settings) > Gestione utenti (User Management), sebbene tutti o la maggior parte degli account non siano effettivamente bloccati, tutti gli account utente vengono visualizzati come bloccati a causa di un banner nell'interfaccia utente.

    Il banner del messaggio di errore per qualsiasi account utente è "Questo account è stato bloccato a causa di un numero eccessivo di tentativi di accesso non riusciti (This account has been locked due to too many failed login attempts)", anche nel caso in cui lo stato della pagina dell'elenco di utenti sia visualizzato come Sbloccato (Unlocked) e sia comunque possibile accedere alla pagina di accesso dell'interfaccia utente locale.

  • Problema 124778 risolto: Quando si utilizza la nuova interfaccia in VMware SASE Orchestrator, se un cliente passa a Impostazioni globali (Global Settings) > Configurazione cliente (Customer Configuration), non vede l'opzione per configurare il proprio criterio di protezione.

    Nella sezione Criterio di protezione (Security Policy) un cliente può configurare l'opzione Proposta IPSec Edge (Edge IPsec Proposal) che include crittografia, gruppo DH e così via. Questa opzione è presente nell'interfaccia utente classica ma non nella nuova interfaccia utente.

Risolti nella versione R5107-20230722-GA di Orchestrator

La build R5107-20230722-GA di Orchestrator è stata rilasciata il 22-07-2023 ed è la settima rollup di Orchestrator per la versione 5.1.0.

Questa build di rollup di Orchestrator risolve il seguente problema critico presente a partire dalla sesta build di rollup di Orchestrator, ovvero R5106-20230705-GA.

  • Problema 122271 risolto: Quando un cliente aggiunge ulteriori regole NAT lato LAN a un profilo utilizzando la nuova interfaccia utente di VMware SASE Orchestrator, è possibile che tutto il traffico che corrisponde a tali regole non riesca.

    La nuova interfaccia utente calcola erroneamente la maschera esterna del NAT lato LAN dal prefisso dell'indirizzo interno. Quando le regole non sono scritte in modo tale che il prefisso interno ed esterno sia lo stesso (in altre parole: 1:1), il comportamento delle regole cambia e può non funzionare se un utente modifica una qualsiasi regola NAT lato LAN dalla nuova interfaccia utente.

    In un Orchestrator senza una correzione per questo problema, il cliente deve utilizzare l'interfaccia utente classica di Orchestrator solo per configurare le regole NAT lato LAN.

Problemi risolti nella versione R5106-20230705-GA di Orchestrator

La build R5106-20230705-GA di Orchestrator è stata rilasciata il 06-07-2023 ed è la sesta rollup di Orchestrator per la versione 5.1.0.

Questa build di rollup di Orchestrator risolve i seguenti problemi critici presenti a partire dalla quinta build di rollup di Orchestrator, ovvero dalla versione R5105-20230611-GA.

  • Problema 84772 risolto: Quando il server DHCP IPv6 di una VLAN viene configurato come tipo Inoltro (Relay) a livello di profilo, se un utente modifica il tipo in Attivato (Activated) a livello di Edge utilizzando l'override dell'Edge e successivamente disattiva l'override dell'Edge, l'Edge continuerà a utilizzare il tipo Attivato (Activated) anziché ripristinare il tipo Inoltro (Relay) specificato dal profilo.

    VMware SASE Orchestrator non riesce a imporre la configurazione del profilo dopo la disattivazione dell'override dell'Edge, causando le impostazioni errate del server IPv6 per l'Edge interessato.

  • Problema 115411 risolto: Per un VMware SASE Orchestrator che utilizza la versione 5.1.0 o successiva e viene distribuito con una topologia di ripristino di emergenza, la sincronizzazione potrebbe non riuscire a causa di un problema del database.

    Il processo specifico che non riesce è dr_utils.js e dipende dal fatto che questo processo è stato deprecato nella versione più recente del software del database di Orchestrator trovata nella versione 5.1.0 e successive.

  • Problema 115433 risolto: Un utente con il ruolo "Supporto aziendale" (Enterprise Support) non può visualizzare i dettagli della configurazione DHCP quando esamina la nuova interfaccia utente di VMware SASE Orchestrator.

    Lo stesso utente con il ruolo "Supporto aziendale" (Enterprise Support) può visualizzare i dettagli della configurazione DHCP se utilizza l'interfaccia utente classica.

  • Problema 116633 risolto: Quando accede a VMware SASE Orchestrator utilizzando Safari o Firefox, se un utente configura una VLAN non valida a livello di profilo (ad esempio, "") e quindi configura un valore di VLAN valido in VMware SD-WAN Edge, la chiamata continua ma mostra un errore.

    Il valore dell'interfaccia in cui non è impostato alcun valore deve essere null ma è vlanID = "". Se un utente accede a Orchestrator con un browser basato su Chromium, questo problema non si verifica.

  • Problema 117772 risolto: Quando si esamina la schermata Monitoraggio (Monitor) > Panoramica della rete (Network Overview) per un VMware SASE Orchestrator per un cliente aziendale, i link WAN con stato Degradato (Degraded) o Inattivo (Down) potrebbero non essere inclusi nella schermata di stato Link se vengono monitorati più di 10 link WAN.

    Questo problema si verifica esclusivamente nella nuova interfaccia utente di Orchestrator a causa di un problema front-end che non tiene conto dei link WAN degradati o inattivi. Il monitoraggio funziona come previsto nell'interfaccia utente classica.

  • Problema 117988 risolto: La casella di controllo "Acquisizione route in entrata" (Inbound Route Learning) con l'opzione "Corrispondenza esatta" (Exact Match) configurata per OSPF in un'interfaccia VMware SD-WAN non corrisponde a quella configurata nell'Edge quando si confrontano i valori nell'interfaccia utente classica e nella nuova interfaccia utente di VMware SASE Orchestrator.

    In un'opzione Corrispondenza esatta (Exact Match), il valore corretto non viene visualizzato anche se è archiviato correttamente nel database dell'Edge quando si esamina la nuova interfaccia utente. I valori corretti sono rappresentati nell'interfaccia utente classica.

  • Problema 117993 risolto: Quando un utente partner che gestisce le aziende dei clienti che utilizzano l'autenticazione nativa (in altre parole, nome utente/password) o un utente aziendale tenta di reimpostare una password per un utente aziendale, il tentativo non riesce.

    L'utente nota l'errore: l'utente non dispone dei privilegi necessari per accedere a [enterpriseUser/sendEnterpriseUserPasswordResetEMail] (user does not have privileges required to access [enterpriseUser/sendEnterpriseUserPasswordResetEMail]). Questo problema si verifica solo nella nuova interfaccia utente ed è il risultato di parametri di richiesta mancanti. Se si verifica questo problema, l'utente può passare all'interfaccia utente classica e la reimpostazione della password funziona come previsto.

  • Problema 118074 risolto: È possibile che un utente non riesca ad aprire alcune impostazioni del dispositivo nella pagina Configura (Configure) > Edge > Dispositivo (Device) della nuova interfaccia utente di VMware SASE Orchestrator.

    Le impostazioni che potrebbero non essere accessibili includono Interfacce (Interfaces), IPv6, VPN cloud (Cloud VPN), Destinazione non SD-WAN (NSD) (Non SD-WAN Destination) e servizio di sicurezza cloud (CSS) (Cloud Security Service). Il problema è riconducibile alle impostazioni WAN che richiedono un indirizzo IP pubblico e se questo indirizzo non è presente, nella nuova interfaccia utente viene generato un errore che blocca l'accesso a tali impostazioni. Le impostazioni del dispositivo funzionano come previsto nell'interfaccia utente classica.

  • Problema 118544 risolto: Un utente può osservare che un profilo operatore non viene caricato ed è inaccessibile e quindi non può essere assegnato a un'azienda del cliente.

    Si è verificato un problema con il database di Orchestrator in cui è presente il profilo operatore ma a un modulo di configurazione viene aggiunto un ID logico errato se viene eliminata l'azienda di un cliente e questo ne impedisce il caricamento.

  • Problema 118733 risolto: Quando si utilizza la nuova interfaccia utente di VMware SASE Orchestrator e a livello di profilo viene configurato un criterio di business o una regola del firewall che viene quindi sostituita a livello di Edge, quando si esamina la schermata Configura (Configure) > Edge (Edges) > Elenca Edge (List Edges) le icone per l'Edge sostituito non sono rappresentate correttamente per Dispositivo (Device), Business e Firewall (Firewall).

    Le icone in cui è selezionato Override dell'Edge (Edge Override) devono essere visualizzate con un colore pieno ma vengono invece visualizzate come vuote. L'Orchestrator classico visualizza correttamente le icone come piene quando un override dell'Edge è stato configurato per una determinata categoria.

  • Problema 119733 risolto: È possibile che nel database di VMware SASE Orchestrator si verifichi un errore e che smetta di funzionare.

    Il problema dipende dal fatto che il database non esegue la versione stabile più recente di MySQL e la versione 5.1.0.6 di Orchestrator corregge tale mancanza con una versione aggiornata di MySQL.

  • Problema 120606 risolto: Quando si tenta di creare un nuovo ruolo in Cliente (Customer) > Impostazioni globali (Global Settings) > Gestione utenti (User Management) > Nuovo ruolo (New Role), si verifica un errore e i privilegi non vengono caricati.

    Quando si verifica questo problema, l'utente visualizza "errore del metodo" (method error) nella pagina dell'interfaccia utente quando crea un nuovo ruolo e che impedisce inoltre il caricamento dei privilegi.

     

Problemi risolti nella versione R5105-20230611-GA di Orchestrator

La build R5105-20230611-GA di Orchestrator è stata rilasciata il 13-06-2023 ed è il quinto rollup di Orchestrator per la versione 5.1.0.

Questa build di rollup di Orchestrator risolve i seguenti problemi critici presenti a partire dalla quarta build di rollup di Orchestrator, ovvero dalla versione R5104-20230426-GA.

  • Problemi che si verificano solo nella nuova interfaccia utente di Orchestrator e non nell'interfaccia utente classica di Orchestrator

    La versione 5.1.0.5 di Orchestrator include un numero notevole di correzioni relative ai problemi che possono verificarsi solo quando si utilizza la nuova interfaccia utente e non quando si utilizza l'interfaccia utente classica. Nella tabella seguente sono elencate tutte queste correzioni con le descrizioni dei sintomi per ogni problema.

    Problemi della nuova interfaccia utente risolti

    Ticket

    Sintomo/Descrizione

    Problema 87089 risolto

    L'utente non può modificare l'indirizzo del client nella pagina Monitor (Monitora) > Edge > Origini (Sources). La correzione aggiunge un'icona a forma di matita blu su cui è possibile fare clic per modificare una voce.

    Problema 112044 risolto

    Per un sito in cui viene distribuita una destinazione non SD-WAN tramite Edge di tipo Zscaler, quando si passa a Monitora (Monitor) > Servizi di rete (Network Services), nella nuova interfaccia utente non viene visualizzata la colonna Sottoscrizioni IaaS (IaaS Subscriptions) nella pagina Stato distribuzione (Deployment Status).

    Problema 112451 risolto

    Quando un utente modifica un profilo di configurazione e in Dispositivo (Device) > Interfacce (Interfaces) > Modelli di Edge personalizzati (Your Edge Models) seleziona l'Edge 3810, la pagina del browser Web smette di rispondere e non può essere salvata e l'utente deve aggiornare la pagina per ripristinarla. Il cliente non può utilizzare l'Edge 3810 per tale profilo.

    Problema 112500 risolto

    Per un sito in cui viene distribuito un servizio di sicurezza cloud (CSS) di tipo Zscaler, quando si visualizza Monitora (Monitor) > Edge (Edges) e si passa il puntatore del mouse sui tunnel Edge per un Edge, nell'interfaccia utente non vengono visualizzati i campi Città (City) e Stato (State) del CSS Zscaler.

    Problema 112809 risolto

    Un amministratore del cliente con ruolo Sola lettura aziendale (Enterprise Read Only) può visualizzare la pagina Monitoraggio (Monitoring) > Routing nell'interfaccia utente.

    Problema 112906 risolto

    Un utente può notare che le pagine dell'interfaccia utente vengono caricate con una strana formattazione per cui la pagina contiene ampie sezioni di spazi vuoti.

    Problema 112912 risolto

    Un amministratore del cliente con ruolo Supporto aziendale (Enterprise Support) non ha la possibilità di selezionare Azioni remote (Remote Actions) > Riavvia (Reboot) per un Edge.

    Problema 113254 risolto

    Un amministratore partner con ruolo superuser o standard non può modificare il profilo operatore predefinito per un cliente che gestisce.

    Problema 113366 risolto

    Un utente non può configurare una route statica in cui un IP secondario VLAN è l'hop successivo.

    Problema 113963 risolto

    Se un utente crea una regola del firewall e imposta un'applicazione per tale regola e successivamente modifica la stessa regola e cambia l'applicazione, la modifica non viene applicata e la regola conserva l'applicazione precedente.

    Problema 114291 risolto

    Se un servizio di sicurezza cloud (CSS) è configurato in un profilo, l'utente non può passare da un segmento all'altro senza possibilità di salvare Impostazioni dispositivo (Device Settings) dopo la modifica di un CSS in diversi segmenti.

    Problema 114564 risolto

    L'utente non può configurare Impostazione 802.1P (802.1P Setting) nella configurazione facoltativa per l'interfaccia di un Edge.

    Problema 114602 risolto

    L'utente non ha alcuna opzione per configurare gli avvisi operatore o gli avvisi aziendali in Impostazioni servizio (Service Settings) > Avvisi e notifiche (Alerts & Notifications).

    Problema 114912 risolto

    La pagina Panoramica partner (Partner Overview) non include le impostazioni per Contratto di licenza (User Agreement).

    Problema 115307 risolto

    Quando una sessione utente rimane inattiva abbastanza a lungo da attivare un timeout, nell'interfaccia utente non viene visualizzato un messaggio di disconnessione, ma viene attivata la modalità di sospensione. Quando l'utente accede all'interfaccia utente, Orchestrator viene riattivato e consente all'utente di accedere a Orchestrator anziché reindirizzarlo alla pagina di accesso.

    Problema 115439 risolto

    Quando un utente passa a Configura (Configure) > Profilo (Profile) > Impostazioni dispositivo (Device Settings) > BGP nota che BGP è presente, ma se applica l'ordinamento in base a Sensibile al segmento (Segment Aware), l'opzione per configurare BGP è ora mancante.

    Problema 115653 risolto

    Quando un amministratore partner visualizza la pagina Gestisci clienti (Manage Customers), l'interfaccia utente non comunica se il cliente sta utilizzando gateway con stato di servizio Inattivo (Quiesced). Ciò impedisce al partner di intervenire tempestivamente per assicurarsi che il cliente utilizzi solo gateway attivi.

    Problema 115719 risolto

    Una regola di backhaul scompare dalla pagina Configura (Configure) > Criterio di business (Business Policy) se viene apportata una modifica in Impostazioni dispositivo (Device Settings) a livello di profilo.

    Problema 116523 risolto

    Quando un utente imposta una configurazione di inserimento VNF e tenta di configurare l'alta disponibilità della VNF nell'Edge, Orchestrator non salva la modifica della VNF dopo la configurazione dell'alta disponibilità.

    Problema 117527 risolto

    Quando un utente configura BGP a livello di profilo, è possibile che il browser non risponda se è configurato un numero elevato di regole.

  • Problema 105861 risolto: Quando un link WAN rimane inattivo per diversi minuti e quindi torna attivo, il grafico Monitora (Monitor) > QoE non indica lo stato effettivo del link.

     Il grafico QoE deve essere rosso mentre il link è inattivo e quindi riprendere il colore verde (se la qualità è buona) quando il link viene ripristinato. Questo comportamento non si verifica causando confusione per gli utenti. Il problema è causato dal fatto che il database di VMware SASE Orchestrator non registra correttamente l'evento link inattivo.

  • Problema 106295 risolto: Per una destinazione non SD-WAN con tipo AWS, quando vengono configurati i gateway primario e secondario con BGP configurato in ognuno, è possibile che in VMware SASE Orchestrator i tunnel secondari ridondanti vengano visualizzati come inattivi anche se sono attivi.

    Il lato AWS segnala che i tunnel primario e secondario sono attivi, ma nella pagina Monitora (Monitor) > Servizi di rete (Network Services) il tunnel secondario viene segnalato come inattivo. Si tratta di un problema strettamente cosmetico.

  • Problema 107180 risolto: Quando un utente configura una VNF con tipo Fortinet, non può visualizzare la versione 6.49 o 7.2.0 dell'immagine Fortinet nel menu a discesa.

    Queste immagini sono supportate nella versione 5.1.0 ma non sono accessibili da un cliente.

  • Problema 107766 risolto: Quando un cliente configura una destinazione non SD-WAN tramite Edge o un servizio di sicurezza cloud (CSS) e configura anche l'opzione di controllo integrità di livello 7 (L7), il cliente può notare che i tunnel vengono contrassegnati in modo imprevisto come inattivi o attivi rispetto a ciò che dovrebbe verificarsi in base al valore della configurazione del controllo integrità L7.

    Il problema è causato dal fatto che Orchestrator invia a VMware SD-WAN Edge i parametri predefiniti del controllo integrità L7, indipendentemente da ciò che il cliente ha configurato. Di conseguenza, anche se le condizioni del tunnel corrispondono a ciò che il cliente ha configurato, lo stato del tunnel può rimanere invariato perché soddisfa il valore predefinito del controllo integrità L7.

  • Problema 110826 risolto: Quando un VMware SD-WAN Edge viene assegnato all'azienda di un cliente, VMware SASE Orchestrator non sposta automaticamente l'Edge nella scheda "Inventario assegnato" (Assigned Inventory) nell'applicazione di gestione dell'inventario Maestro.

    Quando Maestro richiede Edge non assegnati e Orchestrator cerca numeri di serie già assegnati, il numero di modello dell'Edge non viene confrontato causando problemi con gli Edge che vengono assegnati due volte.

  • Problema 111957 risolto: Dopo che un operatore aggiorna un VMware SASE Orchestrator, è possibile che gli utenti notino errori perché gli aggiornamenti dello schema con esecuzione prolungata non riescono. Ad esempio, le route appena acquisite (BGP o OSPF) possono non essere presenti nella pagina OFC. Nei registri di caricamento dell'Orchestrator sono segnalati anche errori relativi alle route acquisite.

    Una chiave esterna in VELOCLOUD_LEARNED_PARTNER_ROUTE_ASSOC viene eliminata e aggiunta nuovamente durante un aggiornamento di Orchestrator dalla versione 4.2.x alla versione 4.3.x o successiva come aggiornamento dello schema con esecuzione prolungata. Questa chiave esterna però non esiste negli Orchestrator in cui il percorso di aggiornamento è stato eseguito tramite alcune build con versione 2.1.x con un difetto di aggiornamento e un gateway che acquisiva le route BGP è stato eliminato da Orchestrator. In tali Orchestrator, l'aggiunta della chiave esterna durante l'aggiornamento dalla versione 4.2.x alla versione 4.3.x o successiva non riesce se nella tabella è già presente una chiave esterna che viola i record.

    La correzione di questo problema risolve la causa principale eliminando la chiave esterna che viola i record e quindi aggiungendo nuovamente la chiave esterna.

    Se si esegue l'aggiornamento a un Orchestrator che non include una correzione per questo problema, la soluzione consiste nell'eseguire la query seguente nello schema di VeloCloud MySQL: DELETE FROM VELOCLOUD_LEARNED_PARTNER_ROUTE_ASSOC WHERE gatewayId not in (selezionare l'ID da VELOCLOUD_GATEWAY) e quindi riattivare gli aggiornamenti dello schema con esecuzione prolungata.

  • Problema 112333 risolto: In un VMware SASE Orchestrator che gestisce circa 4.000 VMware SD-WAN Edge con circa 6.000 tunnel, il flusso di traffico continuo può diventare instabile in un periodo di circa 4 giorni e iniziare a disconnettere gli utenti in modo casuale.

    La sollecitazione causa la mancata riuscita del database di Orchestrator e l'errore "connect ECONNREFUSED" seguito dall'indirizzo IP di Orchestrator. Questo problema si verifica solo in un ambiente di test di scalabilità e non in una distribuzione sul campo.

  • Problema 112605 risolto: Un cliente può notare che quando tenta di assegnare un cluster hub tramite Configura (Configure) > Dispositivo (Device) > VPN cloud (Cloud VPN) > Da Edge ai siti SD-WAN (Edge to SD-WAN Sites), il profilo non risponde e la configurazione non può essere salvata.

    Orchestrator crea associazioni di configurazione duplicate in cui sono presenti più criteri di business di backhaul e i riferimenti duplicati causano l'errore di configurazione e assegnazione dei cluster hub.

  • Problema 112992 risolto: Quando si esegue la migrazione dell'azienda di un cliente da un VMware SASE Orchestrator a un altro, Orchestrator aggiunge un record UUID.

    Il record UUID viene aggiunto ai record VELOCLOUD_ENTERPRISE_OBJECT anche se non dovrebbe.

  • Problema 113209 risolto: Un utente non può eliminare un VMware SD-WAN Edge da SASE Orchestrator se lo stato dell'Edge è "Degradato" (Degraded).

    Orchestrator genera il messaggio di errore "Gli Edge degradati e gli Edge connessi non possono essere eliminati" (Degraded edges and connected edges cannot be deleted). Anche se un utente non può eliminare un Edge connesso, deve poter eliminare un Edge degradato. 

  • Problema 113375 risolto: Per un VMware SASE Orchestrator distribuito con una topologia di ripristino di emergenza, quando Orchestrator viene aggiornato dalla versione 4.5.x alla versione 5.1.x, è possibile che l'aggiornamento non riesca.

    Lo script di aggiornamento e iptables non riescono con codice restituito 1. Il problema può verificarsi durante il periodo in cui l'Orchestrator attivo e quello di standby eseguono versioni del software diverse e le iptables non vengono caricate correttamente quando l'Orchestrator di standby tenta di eseguire l'aggiornamento (operazione prevista e temporanea). L'errore fa fallire l'intero aggiornamento. La correzione trasforma semplicemente l'errore iptables in un avviso e consente il proseguimento dell'aggiornamento.

  • Problema 114240 risolto: In Proposta IPSec Edge (Edge IPSec Proposal) quando un utente modifica la crittografia impostandola su AES-128-GCM o AES-256-GCM e salva la configurazione, l'interfaccia utente di Orchestrator genera un errore.

    Il testo del messaggio di errore è: "instance.ipsec.encryption is not one of enum values: AES_128_CBC, AES_256_CBC, DES_CBC. Il problema è dovuto al fatto che le due crittografie di tipo GCM vengono aggiunte erroneamente al menu Crittografia (Encryption) anche se non sono opzioni valide. Queste opzioni vengono rimosse nell'Orchestrator aggiornato.

  • Problema 115624 risolto: In un VMware SASE Orchestrator può verificarsi un utilizzo elevato della CPU e instabilità ed è possibile che il caricamento delle pagine dell'interfaccia utente Impostazioni dispositivo (Device Settings) e Impostazioni di rete (Network Settings) sia lento quando il servizio del portale viene riavviato.

    Il problema è stato rilevato in un Orchestrator con circa 2.000 Edge connessi che utilizza anche servizi di sicurezza cloud (CSS) e può verificarsi con questo numero di Edge connessi o superiore. Il problema è causato dal fatto che diversi processi di Orchestrator correlati alle configurazioni di Edge, profilo e rete vengono caricati dagli Edge a Orchestrator e il completamento richiede molto più tempo del previsto (circa 60 secondi o di più).

  • Problema 116141 risolto: Quando un utente apporta modifiche alle Impostazioni dispositivo (Device Settings) in un profilo di configurazione, VMware SASE Orchestrator impiega una quantità di tempo eccessiva per convalidare le modifiche.

    La convalida e l'applicazione di ogni modifica possono richiedere fino a un minuto, mentre dovrebbero richiedere solo alcuni secondi. Il problema si verifica in un processo di Orchestrator che non solo recupera tutti i record di configurazione dell'Edge associati a tale profilo, ma esegue anche la decodifica e l'analisi di ogni record. Questa operazione non è necessaria e influisce sulla CPU di Orchestrator. La correzione assicura che il processo recuperi solo il numero di record.

  • Problema 116770 risolto: Quando un utente operatore crea un'autorità di certificazione (CA) esterna con una lunghezza della catena pari almeno a 2 nella root di attendibilità, VMware SASE Orchestrator non consente di utilizzare il valore 0 per pathLengthConstraint in una subordinata.

    Una subordinata che non può firmare una sua subordinata è una configurazione valida e deve essere consentita da Orchestrator, ma un processo impedisce il salvataggio della configurazione.

  • Problema 116790 risolto: Quando un VMware SASE Orchestrator viene aggiornato alla versione 5.1.x o successiva, è possibile che venga accidentalmente eseguito il downgrade dei VMware SD-WAN Edge del cliente a una versione precedente a quella che l'Edge è configurato per utilizzare.

    Il problema si verifica quando l'azienda di un cliente viene eliminata dall'Orchestrator in cui l'azienda eliminata era associata a un profilo operatore in base al suo ID logico nel database di Orchestrator. Quando l'azienda viene eliminata, viene eliminato anche il profilo operatore. Ai clienti che hanno configurato Gestione immagine Edge (Edge Image Management), dispongono di più profili operatore e hanno questo profilo operatore eliminato assegnato come predefinito, viene quindi assegnato un profilo operatore che rimane disponibile nel menu Gestione immagine Edge (Edge Image Management). Di conseguenza, al cliente può essere assegnato un profilo operatore contenente una versione dell'Edge precedente. È possibile che negli Edge assegnati a questo profilo operatore venga eseguita la modifica e il potenziale downgrade del software con possibili effetti negativi, tra cui un errore di rete se l'Edge esegue una versione precedente che non supporta le funzionalità che il cliente sta utilizzando.

  • Problema 116976 risolto: Quando un amministratore partner accede a VMware SASE Orchestrator, può notare che in Orchestrator non viene visualizzato lo stato corretto dei link WAN che sono inattivi da più di 24 ore nei VMware SD-WAN Edge che gestiscono.

    L'API di Orchestrator restituisce solo i link recenti per i partner/MSP, mentre gli utenti abituali dell'azienda del cliente ricevono le informazioni corrette sullo stato dei link. Questo influisce sulla capacità di un partner di supportare correttamente i propri clienti in caso di problemi dei link.

  • Problema 117800 risolto: Quando un VMware SASE Orchestrator viene aggiornato dalla versione 4.x alla versione 5.1.x o successiva, l'operatore può notare che dopo il riavvio del processo di back-end viene creato lo stesso file upgradeSchema.sql anche se è stato eseguito correttamente.

    Questo problema si verifica con l'aggiornamento dello schema successivo all'aggiornamento e dopo l'esecuzione dello script post-schema. Il file upgradeSchema.sql non deve essere generato nuovamente.

  • Problema 118071 risolto: È possibile che il tentativo dell'utente di modificare le impostazioni della VPN in Configura (Configure) > Profilo (Profile) > Dispositivo (Device) non riesca e che venga visualizzato un messaggio di errore se al cliente sono assegnati più VMware SD-WAN Gateway, ciascuno con circa 2.000 Edge assegnati.

    L'errore di Orchestrator è "Errore durante la convalida delle modifiche". VMware SASE Orchestrator non riesce ad aggiornare le impostazioni della VPN perché l'API è in attesa di una query del database che restituisce un eccesso di 10.000 righe, cosa che può verificarsi in un Orchestrator che opera su larga scala. Il problema è causato dal fatto che Orchestrator ottiene tutti i gateway indipendentemente dal tipo (primario o secondario) mentre invece l'Edge dovrebbe segnalare solo il suo gateway primario. Ciò aumenta notevolmente il numero di record restituiti e può causare l'overflow di una query su larga scala.

Risolti nella versione R5104-20230426-GA di Orchestrator

La build di Orchestrator R5104-20230426-GA è stata rilasciata il 27-04-2023 ed è il quarto rollup di Orchestrator per la versione 5.1.0.

Questa build di rollup di Orchestrator risolve i seguenti problemi critici presenti a partire dalla terza build di rollup di Orchestrator, ovvero dalla versione R5103-20230315-GA.

  • Problemi che si verificano solo nella nuova interfaccia utente di Orchestrator e non nell'interfaccia utente classica di Orchestrator

    La versione 5.1.0.4 di Orchestrator include un numero notevole di correzioni relative ai problemi che possono verificarsi solo quando si utilizza la nuova interfaccia utente e non quando si utilizza l'interfaccia utente classica. Nella tabella seguente sono elencate tutte queste correzioni con le descrizioni dei sintomi per ogni problema.

    Problemi della nuova interfaccia utente risolti

    Ticket

    Sintomo/Descrizione

    Problema 104785 risolto

    Quando un utente si trova nella pagina Monitora (Monitor) > Eventi (Events) e fa clic sul pulsante di aggiornamento degli eventi, la data e l'ora della tabella Eventi (Events) non vengono aggiornate e gli eventi più recenti non vengono visualizzati nella tabella a meno che la pagina del browser Web non venga ricaricata.

    Problema 106327 risolto

    Quando un utente si trova nella pagina Monitora (Monitor) > Eventi (Events) e sta configurando un filtro per Eventi (Events), alcune opzioni del filtro mancano e limitano il modo in cui gli eventi dell'Edge possono essere filtrati.

    Problema 107071 risolto

    Quando un utente si trova nella pagina Monitora (Monitor) > Eventi (Events) e seleziona una finestra temporale sufficientemente ampia da restituire > 5 milioni di eventi, si verifica il timeout della pagina che non viene caricata correttamente.

    Problema 107980 risolto

    Quando un utente si trova nella pagina Configura (Configure) > Edge > Panoramica (Overview), non può modificare il nome di un Edge a meno che non compili anche i dati di Contatto e posizione (Contact & Location) se i dati del contatto locale sono vuoti.

    Problema 108072 risolto

    Quando un utente tenta di configurare un'interfaccia di loopback con lo stesso indirizzo IP in vari segmenti, Orchestrator impedisce questa operazione e visualizza il messaggio di avviso "Deve essere univoco" (Must be unique).

    Problema 109284 risolto

    Quando un utente aggiunge un tunnel per una destinazione non SD-WAN (NSD) tramite Edge di tipo Azure o Zscaler, è possibile modificare i campi Tipo di identificazione locale (Local Identification Type), Identificazione locale (Local Identifaction) e PSK.

    Problema 109300 risolto

    Quando un utente esamina un'area di Orchestrator in cui deve essere configurata una licenza, può vedere solo la licenza selezionata e nessun'altra licenza. Quando viene selezionata una licenza, Orchestrator elimina tutte le altre opzioni di licenza. La correzione di questo problema include un nuovo pulsante Cancella (Clear) a destra del menu a discesa della licenza per consentire la selezione di un'opzione di licenza diversa.

    Problema 109532 risolto

    Quando si esamina la pagina Configura (Configure) > Servizi di rete (Network Services), gli indirizzi IP DNS sono diversi nella nuova interfaccia utente rispetto all'interfaccia utente classica perché nella nuova interfaccia utente sono visualizzati campi diversi.

    Problema 109533 risolto

    Nella pagina Configura (Configure) > Edge > Dispositivo (Device) > Connettività (Connectivity) > VLAN, il server DHCP viene visualizzato come Abilitato (Enabled) quando dovrebbe essere visualizzato uno stato più preciso di Inoltro (Relay).

    Problema 109715 risolto

    Un link WAN inattivo scompare dalla pagina Monitora (Monitor) > Panoramica della rete (Network Overview) dopo 24 ore anche se Limite link Edge inattivo (Edge Down Link Limit) è impostato su un valore > 24 ore.

    Problema 109788 risolto

    Quando si configura una destinazione non SD-WAN, un utente non può configurare una Subnet del sito (Site Subnet) con un valore 0.0.0.0/0 e Orchestrator la dichiara come "Prefisso CIDR non valido" (Invalid CIDR Prefix).

    Problema 109836 risolto

    Le route statiche del gateway partner non vengono distribuite negli Edge quando vengono configurate nella nuova interfaccia utente. Queste route devono essere distribuite agli Edge connessi come route cloud (Tipo = Cloud) e visualizzate in un dump della tabella di route, ma non lo sono.

    Problema 109911 risolto

    Quando si configura un criterio di business, nella sezione Reindirizzamento link (Link Steering) > Interfacce (Interfaces) se il tipo di overlay WAN è "Disabilitato" (Disabled), tale interfaccia non può essere selezionata. La nuova interfaccia utente consente le interfacce correlate all'overlay WAN rilevate automaticamente o definite solo dall'utente.

    Problema 110094 risolto

    Quando si modifica un'interfaccia dell'Edge e si aggiungono molti filtri contemporaneamente in OSPF, la griglia dei filtri scompare. Quando viene aggiunto un numero sufficiente di filtri OSPF in modo che nella griglia dei filtri OSPF venga visualizzata l'impaginazione, l'altezza della griglia viene impostata su 0 e un utente non può più modificare o visualizzare la griglia dei filtri.

    Problema 110330 risolto

    Gli amministratori del partner e del cliente potrebbero non essere in grado di visualizzare la scheda Impostazioni globali (Global Settings) > Autorizzazioni servizio (Service Permissions) anche se il loro ruolo lo consente. Autorizzazioni servizio (Service Permissions) è il campo in cui è documentata la personalizzazione dei ruoli utente.

    Problema 111104 risolto

    Quando esamina la pagina Impostazioni servizio (Service Settings) > Gestione Edge (Edge Management) > Immagini software e firmware (Software & Firmware Images), se un utente espande una riga nella parte inferiore della tabella, non potrà visualizzare tutti i dettagli.

    Problema 111407 risolto

    Quando un utente si trova nella pagina Configura (Configure) > Edge > Dispositivo (Device) > Connettività (Connectivity) > Interfacce (Interfaces), non può configurare un'interfaccia definita dall'utente senza aggiungere anche un link WAN.

    Problema 111444 risolto

    Quando configura un servizio di sicurezza cloud (CSS) con tipo Zscaler, l'utente non è autorizzato a configurare l'URL di accesso a Zscaler (Zscaler Login URL) con un URL e viene visualizzato il messaggio L'FQDN non è valido (FQDN is invalid) e il valore dell'URL di accesso non viene inviato a un server, né salvato.

    Problema 111934 risolto

    Quando si aggiorna un campo qualsiasi di una destinazione non SD-WAN tramite Edge di tipo Zscaler, Orchestrator rimuove il campo Gruppo DH (DH Group).

    Problema 111944 risolto

    Un superuser operatore non può modificare o eliminare una Proprietà di sistema (System Property).

    Problema 112094 risolto

    Quando un utente modifica le credenziali per un servizio di sicurezza cloud (CSS) in un segmento non globale e nella stessa sessione passa a un segmento globale, le credenziali CSS vengono rimosse.

    Problema 112201 risolto

    Se un utente configura un servizio di sicurezza cloud (CSS) tramite un'API e imposta CSS su Nessuno (None) (vuoto), nella configurazione di CSS in VMware Edge, Orchestrator non mostra alcuna configurazione, ma nelle risposte dell'API e del database dell'Edge il CSS viene segnalato come attivo e funzionante. Un CSS con questo stato non può essere utilizzato come parte di un criterio di business.

    Problema 112224 risolto

    Quando un amministratore del cliente con ruolo Superuser, Standard o Supporto (Support) passa a Diagnostica (Diagnostics), il link della pagina Bundle di diagnostica (Diagnostic Bundles) non è presente anche se il suo ruolo consente l'accesso a questa sezione. Di conseguenza, un amministratore del cliente non può generare (ma può scaricare) un bundle di diagnostica e non può generare né scaricare una acquisizione di pacchetti.

    Problema 112437 risolto

    Se un utente apre più sessioni di Diagnostica remota (Remote Diagnostics) per lo stesso Edge, è possibile che la pagina non venga caricata correttamente dopo che è stato aperto un determinato numero di sessioni.

  • Problema 95631 risolto: Quando un utente passa a Monitora (Monitor) > Servizi di rete (Network Services) > Siti dei servizi di sicurezza cloud (Cloud Security Service Sites) e tenta di ordinare gli eventi in base a Ora modifica stato (State Change Time), la sequenza di ordinamento non è corretta.

    Quando un utente tenta di ordinare in base alla colonna Ora modifica stato (State Change Time) della tabella CSS, l'ordinamento è errato perché le date non vengono ordinate in base a data e ora ma in base alla data analizzata. Questo problema si verifica sia nell'interfaccia utente classica sia nella nuova interfaccia utente.

  • Problema 106907 risolto: Se dopo che un cliente ha configurato una destinazione non SD-WAN (NSD) tramite Edge associata a un criterio di business, un utente usa la override dell’Edge per disattivare NSD tramite Edge, il criterio di business non viene rimosso in un VMware SASE Orchestrator che utilizza la versione 5.1.0.

    Orchestrator deve rimuovere il criterio di business dopo la disattivazione di NSD tramite Edge perché se la regola persiste, il traffico che soddisfa tale criterio di business verrà reindirizzato a una destinazione inesistente e verrà quindi eliminato.

  • Problema 106929 risolto: Un operatore potrebbe non essere in grado di assegnare una versione del software a un profilo operatore in un VMware SASE Orchestrator che utilizza la versione 5.1.0.

    Orchestrator genera un errore simile al seguente:

    Messaggio di errore.

    Il problema è dovuto al fatto che in Orchestrator si verifica il timeout del tentativo di aggiungere l'immagine software perché sono presenti query API del database concorrenti. È più probabile che questo problema si verifichi in un Orchestrator che ospita un numero elevato di Edge, come nel caso di Orchestrator ospitati in VMware, e può verificarsi quando si utilizza la nuova interfaccia utente o l'interfaccia utente classica.

    In un Orchestrator che non contiene alcuna correzione per questo problema, l'unica soluzione consiste nell'aumentare il valore del timeout per le connessioni al database.

  • Problema 107349 risolto: Quando si esamina Monitora (Monitor) > Edge > Origini (Sources) in VMware SASE Orchestrator, è possibile che alcune o persino tutte le origini non vengano risolte e che venga visualizzato il messaggio "Impossibile risolvere" (Unable to resolve).

    Questo problema non si verifica in modo coerente ed è possibile che in alcuni siti dell'azienda di un cliente vengano visualizzati gli indirizzi IP e MAC per le origini come previsto. Il problema è causato dal mancato aggiornamento della tabella del database di Orchestrator per i nomi degli Edge.

    Se un cliente nota questo problema in un Orchestrator senza una correzione per il problema, può disattivare la VPN cloud in una finestra di manutenzione e quindi attivarla di nuovo per forzare Orchestrator a recuperare i nomi degli Edge corretti.

  • Problema 108363 risolto: Dopo l'aggiornamento di VMware SASE Orchestrator a una versione 5.x, nei VMware SD-WAN Edge che distribuiscono i servizi di sicurezza cloud (CSS) come Zscaler e hanno il controllo integrità di livello 7 (L7) configurato, è possibile che si verifichi una perdita di traffico che utilizza tale CSS per circa 30 secondi.

    Dopo l'aggiornamento, Orchestrator attiva un aggiornamento della configurazione per tutti gli Edge. Questo può causare l'inattività di alcuni siti CSS con Controllo integrità L7 (L7 Health Check) configurato finché la configurazione non viene corretta. Questo problema è collegato al problema 107302 risolto che riguarda il problema nell'Edge. La correzione in questo caso impedisce a Orchestrator di attivare gli aggiornamenti della configurazione degli Edge durante un aggiornamento e quindi protegge gli Edge che non includono la correzione per il problema 107302.

  • Problema 110946 risolto: È possibile che un VMware SD-WAN Orchestrator che utilizza la versione 4.2.x o precedente non venga eseguito correttamente quando viene aggiornato per diventare un SASE Orchestrator che utilizza la versione 4.3.x o successiva.

    Orchestrator 4.2.x o precedente non pulisce la cache apt prima di eseguire la routine apt update service quando Orchestrator viene aggiornato alla versione 4.3.x o successiva e, di conseguenza, il database MySQL viene riavviato durante l'aggiornamento, che quindi non riesce.

    Quando esegue l'aggiornamento a una versione di Orchestrator senza una correzione per questo problema, l'operatore può eseguire il comando rm -rf /var/lib/apt/lists/ prima dell'aggiornamento.

  • Problema 111665 risolto: Quando si aggiorna un VMware SASE Orchestrator da una versione di Orchestrator precedente alla versione 5.1.0, è possibile che la migrazione del dispositivo client non venga completata.

    Il problema influisce sulla migrazione dei dati del dispositivo client da un'istanza di Orchestrator che utilizza MySQL a un'istanza che utilizza ClickHouse. Dopo la migrazione di un determinato numero di record, il processo di migrazione termina prematuramente.

  • Problema 111946 risolto: Un utente non può visualizzare i percorsi nella scheda Edge > Monitora (Monitor) > Percorsi (Paths) in un VMware SASE Orchestrator quando l'elenco di peer è maggiore di 100.

    Quando un utente passa alla scheda Edge > Monitora (Monitor) > Percorsi (Paths), il back-end di Orchestrator restituisce tutti i record anche se sono più di 100. Ciò è dovuto al fatto che il back-end omette il vincolo del limite, ovvero il numero massimo di record che può essere restituito. I record restituiti oltre il limite massimo non sono normalizzati, ovvero non hanno una formattazione compatibile con l'interfaccia utente. Ciò causa un errore nell'interfaccia utente. Orchestrator deve restituire solo i record che rientrano nel limite impostato.

  • Problema 112458 risolto: Quando un nuovo VMware SD-WAN Gateway viene aggiunto a un pool di gateway e viene avviato un ribilanciamento del gateway, il nuovo gateway non viene ridistribuito nei VMware SD-WAN Edge anche se i gateway esistenti sono sovraccarichi.

    Quando viene eseguito un ribilanciamento del gateway, VMware SASE Orchestrator deve riassegnare più Edge al gateway meno carico nella stessa area geografica. A seguito di questo problema, gli Edge mantengono la propria assegnazione del gateway esistente nonostante tale gateway sia sovraccarico.

  • Problema 112885 risolto: È possibile che venga attivato un ribilanciamento del gateway per i workflow non direttamente correlati all'attivazione di un ribilanciamento tramite l'interfaccia utente di VMware SASE Orchestrator.

    La correzione in questo caso risolve il problema per cui i ribilanciamenti del gateway possono verificarsi per i workflow che si trovano all'esterno di un'azienda dedicata. Un ribilanciamento del gateway può essere attivato solo tramite l'interfaccia utente di Orchestrator a livello di operatore e con nessun'altro mezzo.

  • 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.

Risolti nella versione R5103-20230315-GA di Orchestrator

La build R5103-20230315-GA di Orchestrator è stata rilasciata il 15-03-2023 ed è il terzo rollup di Orchestrator per la versione 5.1.0.

Questa build di rollup di Orchestrator risolve i seguenti problemi critici presenti a partire dalla seconda build di rollup di Orchestrator, ovvero dalla versione R5102-20230315-GA.

  • Problema 107587 risolto: Un operatore non può modificare i dettagli dell'utente di altri operatori o degli amministratori del cliente in VMware SASE Orchestrator.

    Gli operatori devono poter modificare i dettagli dell'utente in Amministrazione (Administration) > Gestione utenti (User Management) per un altro operatore se il loro ruolo lo consente, nonché modificare un amministratore del cliente se è attivata la delega della gestione. Quando si verifica questo problema, l'operatore vede i dettagli dell'utente in sola lettura e non può modificarli.

  • Problema 107725 risolto: Quando un utente che utilizza la nuova interfaccia utente di VMware SASE Orchestrator passa a Monitora (Monitor) > Edge (Edges) > Distribuzione mappa (Map Distribution), nella mappa vengono visualizzati al massimo 20 VMware SD-WAN Edge alla volta e non tutti gli Edge distribuiti dal cliente.

    Questo problema influisce sui clienti che distribuiscono più di 20 Edge perché in Distribuzione mappa (Map Distribution) per la nuova interfaccia utente vengono visualizzati solo 20 Edge alla volta nell'elenco di Edge del cliente. Quando l'utente fa clic sulla pagina successiva dell'elenco, nella mappa vengono visualizzati solo gli Edge in tale pagina. Non è possibile visualizzare l'elenco di tutti gli Edge per l'azienda del cliente.

  • Problema 108533 risolto: Quando un utente passa a Impostazioni servizio (Service Settings) > Gestione Edge (Edge Management) > Configura aggiornamenti (Configure Updates), il testo esplicativo delle impostazioni non è chiaro nella nuova interfaccia utente di VMware SASE Orchestrator.

    Il nome dell'impostazione Disabilita aggiornamenti configurazione Edge (Disable Edge Configuration Updates) contraddice la funzione effettiva dell'impostazione e con questa correzione viene sostituito da Abilita aggiornamenti configurazione Edge (Enable Edge Configuration Updates) in modo che corrisponda alla funzione e al testo esplicativo.

  • Problema 108833 risolto: Se un utente modifica un filtro BGP in un segmento non globale nella nuova interfaccia utente di VMware SASE Orchestrator, Orchestrator sovrascrive questa modifica del filtro BGP nel segmento globale.

     Per un cliente che utilizza BGP in più segmenti con impostazioni univoche in ogni segmento, è possibile che si verifichi un'interruzione della rete per gli utenti che utilizzano il segmento globale in cui le impostazioni BGP vengono sovrascritte. Il problema non si verifica quando si utilizza l'interfaccia utente classica.

  • Problema 109064 risolto: Un utente può configurare lo stesso SSID (Service Set Identifier) in due interfacce Wi-Fi diverse per un VMware SD-WAN Edge se l'utente configura il filtro MAC in un'interfaccia Wi-Fi e non nell'altra.

    La configurazione dello stesso SSID in WLAN1 e WLAN2, una con il filtro MAC attivato e l'altra con il filtro MAC disattivato (o con un elenco di MAC consentiti diverso in ogni interfaccia), non deve essere consentita da VMware SASE Orchestrator perché permette la connessione di indirizzi MAC non approvati.

Risolti nella versione R5102-20230222-GA di Orchestrator

La build R5102-20230222-GA di Orchestrator è stata rilasciata il 24-02-2023 ed è il secondo rollup di Orchestrator per la versione 5.1.0.

La build di rollup di Orchestrator risolve i seguenti problemi critici presenti a partire dalla prima build di rollup di Orchestrator, ovvero dalla versione R5101-20221220-GA.

  • Problema 40584 risolto: Quando un utente controlla Monitora (Monitor) > Edge > Origini (Sources) in VMware SASE Orchestrator, può notare che, anche se sono stati aggiunti nuovi dispositivi client a un VMware SD-WAN Edge, in Orchestrator non viene visualizzato il dispositivo client più recente quando viene utilizzata la modalità di visibilità IP.

    Questo problema può verificarsi quando la modalità di visibilità dell'Edge è configurata come Visibilità per indirizzo IP (Visibility by IP Address). Il problema è causato dal fatto che Orchestrator non elabora le informazioni più recenti del client per l'Edge quando utilizza la modalità Indirizzo IP correttamente e quindi mostra solo il client precedente e il relativo indirizzo IP.

  • Problema 105610 risolto: Quando un utente tenta di creare un nuovo gruppo di oggetti IPv4 o tenta di aggiornare un gruppo di oggetti IPv4 esistente che include una maschera con caratteri jolly che inizia con "255" e termina con "0" (ad esempio 255.0.1.0), VMware SASE Orchestrator non consente questa maschera con caratteri jolly e genera un errore anche se si tratta di un'espressione con caratteri jolly valida che dovrebbe essere consentita.

    A partire dalla versione 5.0.x, le macchine di Orchestrator non dispongono della convalida per le maschere con caratteri jolly nei gruppi di oggetti e di conseguenza generano un errore quando un utente configura una maschera con caratteri jolly per tale maschera.

  • Problema 106159 risolto: Un VMware SASE Orchestrator che esegue le versioni 5.1.0.0 e 5.1.0.1 non consente agli utenti nativi di creare token API quando l'autenticazione è configurata come Single Sign-On (SSO) e il provider di identità (IdP) corrispondente non supporta l'endpoint di introspezione.

    La versione 5.1.0.0 include il controllo dell'endpoint di introspezione IdP durante la convalida della creazione del token API. Questo controllo non distingue gli utenti nativi dagli utenti non nativi e, finché per l'autenticazione è configurato SSO, Orchestrator verificherà se il provider di identità supporta l'endpoint di introspezione. Di conseguenza, se il provider di identità non supporta l'endpoint di introspezione, la convalida impedirà agli utenti nativi e non nativi di creare token API. Questa condizione si verifica sia per gli utenti operatore sia per gli amministratori partner.

  • Problema 106242 risolto: È possibile che un utente che accede alla pagina Diagnostica (Diagnostics>) > Diagnostica remota (Remote Diagnostics) in VMware SASE Orchestrator venga disconnesso in modo imprevisto dalla pagina Diagnostica remota (Remote Diagnostics) durante l'esecuzione di una diagnostica qualsiasi dell'Edge.

    Quando un utente rileva questo problema, è dovuto al fatto che Orchestrator ha raggiunto il limite del numero di connessioni possibili e Orchestrator disconnette gli utenti di diagnostica remota per garantire il normale funzionamento. Il problema è causato dal fatto che Orchestrator erroneamente non rilascia le connessioni al database quando non sono più necessarie, causando l'attivazione dei comportamenti previsti al raggiungimento del limite.

  • Problema 106592 risolto: In un VMware SASE Orchestrator che esegue le versioni 5.1.0.0 e 5.1.0.1, un cliente che utilizza le API può notare i seguenti sintomi: a) i token API attivi vengono revocati da Orchestrator e b) i servizi come APIv2 non funzionano più.

    La versione 5.1.0.0 include un nuovo processo back-end denominato batchRevokeApiTokenForInactiveSsoUsers che verrà eseguito ogni 6 ore per revocare i token API emessi in precedenza per gli utenti Single-Sign-On (SSO) inattivi. Alcuni difetti nel processo back-end causano la revoca erronea di tutti i token API in Orchestrator indipendentemente dall'utente per cui i token sono stati creati.

    Con la correzione, un amministratore del cliente con un superuser o un amministratore partner deve eliminare manualmente gli utenti del provider di identità (IdP) inattivi da Orchestrator per impedire l'accesso non autorizzato tramite token API.

  • Problema 106806 risolto: Quando un VMware SASE Orchestrator viene aggiornato alla versione 5.1.0, è possibile che per i clienti connessi a Orchestrator si verifichino interruzioni del traffico.

    Orchestrator crea una nuova versione del modulo delle impostazioni del dispositivo durante l'aggiornamento alla versione 5.1.0. Orchestrator esegue quindi il push di questa nuova versione delle impostazioni del dispositivo in tutti gli Edge connessi. Questa operazione può causare interruzioni perché alcune modifiche delle impostazioni del dispositivo possono attivare un riavvio del servizio Edge che comporta 10-15 secondi di interruzione del traffico del cliente. La correzione di questo problema assicura che Orchestrator non esegua il push di una versione aggiornata delle impostazioni del dispositivo in tutti gli Edge connessi quando viene aggiornato alla versione 5.1.0.

  • Problema 107410 risolto: Quando un amministratore partner, che utilizza la nuova interfaccia utente in VMware SASE Orchestrator, tenta di assegnare un'immagine software a uno dei clienti del partner, nota che non può scorrere il menu a discesa che elenca le immagini software.

    Di conseguenza, a meno che il partner non veda l'immagine software desiderata nella visualizzazione iniziale delle immagini quando viene aperto il menu a discesa, non sarà in grado di scorrere verso il basso per trovare l'immagine che desidera se è più in basso. Gli utenti operatore non hanno problemi a eseguire questa operazione e l'amministratore partner può comunque scorrere l'elenco nell'interfaccia utente classica quando assegna un'immagine software a un cliente.

  • Problema 107637 risolto: Se un cliente utilizza un numero elevato di VMware Edge e seleziona Configura (Configure) > Edge (Edge) nell'interfaccia utente classica di VMware SASE Orchestrator, è possibile che l'interfaccia non venga caricata.

    Questo problema si verifica nell'interfaccia utente classica e causa il timeout della pagina, nonché la visualizzazione del messaggio "Si è verificato un errore imprevisto". Questo problema non si verifica quando si utilizza la nuova interfaccia utente.

    Schermata dell'errore.

    Quando si risolve il problema, un operatore che esamina i registri di Orchestrator nota che il metodo enterprise/getEnterpriseEdgeList non riesce e viene visualizzato il seguente messaggio di errore:

    2023-02-06T17:21:05.412Z - error: [[email protected]] [24775] API Invocation error for enterprise/getEnterpriseEdgeList: { code: undefined, message: 'Internal error' }

    Questo problema è causato da un'API di Orchestrator che recupera l'elenco di Edge per un cliente in scenari come Configura (Configure) > Edge (Edges). Nell'interfaccia utente classica questa API viene utilizzata in un modo che può causarne il timeout, specialmente quando è necessario recuperare un numero elevato di Edge (ad esempio, almeno cinquecento Edge).

  • Problema 107885 risolto: Per tutti gli utenti che usano la nuova interfaccia utente di VMware SASE Orchestrator, è possibile che la pagina Configura (Configure) > Panoramica (Overview) non venga caricata per alcuni VMware SD-WAN Edge.

    Questo problema è incoerente ed è possibile che la pagina Configura (Configure) > Panoramica (Overview) venga caricata per alcuni Edge. Il problema si verifica quando il modulo QoS dell'Edge non viene popolato con le informazioni relative al segmento.

    In un Orchestrator che non include la correzione per questo problema, un utente può configurare un criterio di business di prova che non influisca sul traffico degli utenti e salvarlo. La pagina Panoramica (Overview) verrà quindi caricata correttamente.

  • Problema 108074 risolto: Nella nuova interfaccia utente di VMware SASE Orchestrator, quando un utente visualizza la casella a discesa delle informazioni dell'Edge nella schermata Monitora (Monitor) > Edge, la descrizione non è presente.

    Nell'interfaccia utente classica, la schermata della casella a discesa delle informazioni dell'Edge Monitora (Monitor) > Edge include la descrizione configurata:


    Nella schermata Monitora (Monitor) > Edge della nuova interfaccia utente, la casella a discesa delle informazioni dell'Edge non include la descrizione configurata:


    Un utente può configurare la Descrizione (Description) dell'Edge nella pagina Configura (Configure) > Edge > Panoramica (Overview).

  • Problema 108309 risolto: Nella nuova interfaccia utente di VMware SASE Orchestrator che utilizza la versione 5.1.0, quando un utente tenta di associare un VMware SD-WAN Edge a una destinazione non SD-WAN (NSD) utilizzando la override dell’Edge, l'opzione di configurazione del tunnel non viene visualizzata.

    L'opzione di configurazione del tunnel deve essere visualizzata nell'ultima colonna della schermata come Azione (Action) con un simbolo +. Quando si verifica questo problema, il simbolo + manca.


    Questo problema si verifica solo per le azioni specifiche dell'Edge e se un cliente aggiunge un NSD tramite un profilo utilizzato dall'Edge (anziché usare la override dell’Edge), l'opzione Azione + (Action +) viene visualizzata correttamente.


Risolti nella versione R5101-20221220-GA di Orchestrator

La build R5101-20221220-GA di Orchestrator è stata rilasciata il 20-12-2022 ed è il primo rollup di Orchestrator per la versione 5.1.0.

Questa build di rollup di Orchestrator risolve i seguenti problemi critici presenti dalla build R5100-20221202-GA di Orchestrator.

  • Problema 100133 risolto: È possibile che in un VMware SASE Orchestrator si verifichino problemi di prestazioni.

    Quando un cliente configura un numero elevato di regole dei criteri di business associandole a un cluster hub dell'Edge, in Orchestrator si verificano problemi di prestazioni ogni volta che deve eseguire il push di queste configurazioni negli Edge di tale azienda.

  • Problema 101835 risolto: La sezione VPN cloud (Cloud VPN) non è disponibile nella nuova interfaccia utente di Orchestrator se l'utente seleziona un segmento non globale in cui è configurata la VPN cloud.

    Nella pagina delle impostazioni Configura (Configure) > EdgeDispositivo (Device) della nuova interfaccia utente di Orchestrator, la sezione VPN cloud (Cloud VPN) non è disponibile se l'utente seleziona un segmento non globale in cui è configurata la VPN cloud.

  • Problema 102806 risolto: Il cliente non può modificare la configurazione dell'handoff del gateway partner a livello di gateway.

    Questo problema si verifica quando un cliente configura l'handoff del gateway partner durante un aggiornamento.

  • Problema 103622 risolto: È possibile che per l'utente operatore venga visualizzato il messaggio di errore: "Non si dispone delle autorizzazioni necessarie per accedere a questi dati" (You don’t have permission to access this data) quando tenta di accedere ad alcune pagine in VMware SASE Orchestrator.

    Questo problema si verifica nella nuova interfaccia utente di Orchestrator quando un utente operatore tenta di accedere alla pagina Gestione utenti operatore (Operator User Management) o Gestione utenti partner (Partner User Management) dopo aver visitato le pagine Impostazioni globali (Global Settings), Cloud Web Security o Secure Access di un cliente.

Risolti nella versione R5100-20221202-GA di Orchestrator

Nella versione R5100-20221202-GA di Orchestrator, rilasciata il 08-12-2022, sono stati risolti i problemi seguenti presenti dalla versione R5011-20221129-GA di Orchestrator.

Nota:

La versione 5.1.0 contiene tutte le correzioni di Orchestrator elencate nelle note di rilascio della versione 5.0.0 o 5.0.1.

  • Problema 91407 risolto: Quando un overlay WAN definito dall'utente è configurato come link di backup, in VMware SASE Orchestrator che esegue la versione 5.0.x, il link viene visualizzato come attivo in Monitora (Monitor) > Edge mentre il link è effettivamente in modalità di backup.

    Questo è solo un problema di visualizzazione e il link WAN di backup funziona correttamente. Il problema è causato dal fatto che Orchestrator non archivia i valori della modalità link per l'Edge in modo appropriato e viene visualizzato uno stato errato.

  • Problema 91393 risolto: Per un cliente che utilizza la raccolta dati dall'Edge tramite syslong o telnet, l'utente può notare due nomi per la stessa applicazione nei dati di NetFlow da VMware SD-WAN Edge.

    Questo problema si verifica quando sono presenti applicazioni per cui il valore di displayName nel file della lingua (appids_en_us.json) è diverso dal valore di displayName nel file delle applicazioni (applications.json). Poiché il valore di displayName del file applications.json viene utilizzato sul lato Edge, non deve essere modificato.

    Il problema si verifica perché il valore di displayName del file applications.json è stato sostituito con il valore di displayName del file appids_en_us.json come parte di una risposta API e ogni volta che vengono aggiornati i dati della mappa applicazioni, viene aggiornato ogni valore di displayName della mappa applicazioni anche quando l'utente non lo ha modificato e viene eseguito il push di tale valore nell'Edge.

  • Problema 12132 risolto: Quando si configura una route statica in VMware SASE Orchestrator, l'interfaccia utente avvisa di un riavvio del servizio Edge che in realtà non viene eseguito.

    Quando si modifica la configurazione in una route statica qualsiasi e si salvano le modifiche, l'interfaccia utente di Orchestrator avvisa che verrà eseguito un riavvio dell'Edge e si verificherà un'interruzione del servizio. Questo messaggio non è valido e non viene eseguito alcun riavvio del servizio Edge associato alla modifica della configurazione di una route statica. La correzione elimina il falso avviso.

  • Problema 36058 risolto: Un link WAN configurato come link di backup può essere grigio nella pagina Monitora (Monitor) > Panoramica (Overview) dell'interfaccia utente di VMware SASE Orchestrator quando il link è effettivamente inattivo.

    La schermata sarà simile alla seguente:


    Quando si controlla la pagina Monitora (Monitor) > Edge > Panoramica (Overview), lo stato del link di backup è corretto.

  • Problema 52952 risolto: L'interfaccia utente di VMware SASE Orchestrator consente a un utente di configurare input non validi per Anteponi AS Path (AS Path Prepend).

    L'interfaccia utente di Orchestrator non analizza un valore di Anteponi AS Path (AS Path Prepend) non valido. Un utente può immettere Anteponi AS Path (AS Path Prepend) con valori che includono una virgola e l'interfaccia utente li accetta anche se si tratta di una configurazione non valida per il processo di routing dell'Edge. La configurazione non valida non viene applicata e all'utente non viene fornito alcun feedback, ad esempio un avviso, un messaggio di errore o un suggerimento relativo alla configurazione non valida.

  • Problema 53740 risolto: Quando si configura una regola del firewall nell'interfaccia utente di VMware SASE Orchestrator, un utente non può configurare un valore del protocollo per un protocollo che desidera soddisfare.

    Orchestrator consente solo TCP/UDP/ICMP/GRE nei criteri di corrispondenza del protocollo e non consente valori del protocollo compresi tra 0 e 255. La modifica consente a un utente di configurare una regola del firewall corrispondente e in Destinazione (Destination) l'utente seleziona Altro (Other) dal menu Protocollo (Protocol) e quindi immette un valore compreso tra 0 e 255.

    Nota:

    Mentre un utente può immettere un valore compreso tra 0 e 255, i valori del protocollo che vanno da 144 a 255 sono considerati riservati o non assegnati in base alla documentazione Numeri di protocollo Internet assegnati IANA.

  • Problema 68347 risolto: In VMware SASE Orchestrator un evento IPSec Zscaler per il tunnel GRE viene visualizzato erroneamente come evento del tunnel IPSec Edge nella pagina Avvisi (Alerts).

    Non è previsto che per gli eventi del tunnel GRE vengano generati avvisi.

  • Problema 70987 risolto: È possibile che un utente non riesca ad eliminare un VMware SD-WAN Edge da VMware SASE Orchestrator.

    Gli Edge sono offline ma poiché non vengono segnalati come disconnessi, rimangono in uno stato danneggiato e quindi non sono idonei per l'eliminazione.

  • Problema 72444 risolto: Quando un utente configura i router adiacenti BGP IPv4 e IPv6 per un VMware SD-WAN Edge e tenta quindi di disattivare le impostazioni BGP utilizzando il pulsante di scorrimento di attivazione/disattivazione, la configurazione non viene salvata e nell'interfaccia utente di VMware SASE Orchestrator viene visualizzato il messaggio "Nessuna modifica (No changes)".

    In questo raro caso in cui un utente configura l'impostazione BGP ma disattiva BGP, le azioni dell'utente non vengono salvate per le impostazioni BGP come dovrebbero.

  • Problema 73481 risolto: Quando due o più VMware SD-WAN Gateway vengono distribuiti nella stessa posizione, un operatore può notare che un gateway viene utilizzato dalla maggior parte dei VMware SD-WAN Edge mentre gli altri gateway non vengono utilizzati come dovrebbero. Questo può causare problemi di prestazioni nel gateway che viene utilizzato completamente.

    A causa di questo problema, un gateway verrà utilizzato al 90%, mentre un altro che si trova nella stessa posizione rimarrà al 10% di utilizzo con risorse di riserva. Le assegnazioni dei gateway primario e secondario per gli Edge devono tenere conto del carico esistente nei gateway. Se questo non avviene, un singolo gateway viene sovraccaricato come gateway primario mentre è presente molta capacità lasciata inutilizzata in un gateway secondario.

  • Problema 75175 risolto: Quando un amministratore del cliente tenta di accedere alla pagina Informazioni gateway (Gateway Information) in VMware SASE Orchestrator, la pagina non viene aperta e viene visualizzato un messaggio di errore.

    Dopo aver eseguito la migrazione del gateway, in Monitora (Monitor) > Edge > Visualizza (View) nel gateway, viene visualizzato il messaggio di errore: Errore durante il caricamento delle informazioni del gateway (Error Loading Gateway info)


    Non è previsto che gli amministratori dei clienti siano in grado di accedere alla pagina Informazioni gateway (Gateway Information), tuttavia quando tentano di accedervi in base al loro livello di privilegio, si verifica un errore.

  • Problema 76091 risolto: Un utente può notare che mentre modifica una subnet nella schermata Configura (Configure) > Dispositivo (Device), lo schermo si blocca.

    Se si fa clic sul pulsante Reimposta (Reset) o si sposta l'Edge in Uscite VPN idonee (Eligible VPN Exits) e quindi si fa clic su Salva (Save) per una subnet che non ha route acquisite, l'interfaccia utente si blocca con l'icona di caricamento sempre in esecuzione.


     

    Il problema è causato dal fatto che in tali subnet manca l'array learnedRoute e questo attiva un errore dell'interfaccia utente.

  • Problema 76182 risolto: Quando si selezionano determinati intervalli di tempo nella pagina Monitora (Monitor) > Edge dell'interfaccia utente di VMware SASE Orchestrator, è possibile che Orchestrator restituisca dati incompleti.

    Quando la query di un utente con intervalli multipli di 5, ad esempio 12:00:00 - 13:00:00, invia solo 11 campioni di 5 minuti, anziché i 12 campioni corretti a causa di un problema relativo all'API delle statistiche del link dell'Edge.

  • Problema 77538 risolto: Quando l'azienda di un cliente viene migrata da un VMware SASE Orchestrator a un altro Orchestrator, il cliente può notare immagini software dell'Edge e profili operatore duplicati.

    Non solo i profili operatore duplicati creano confusione per il cliente, ma puntano ancora al vecchio Orchestrator. Per questo motivo, un Edge che utilizza un'istanza di Orchestrator può creare un heartbeat per l'Orchestrator errato. In questo modo, l'Edge viene contrassegnato come inattivo e non riceve gli aggiornamenti della configurazione.

  • Problema 79383 risolto: Quando si effettua una modifica della configurazione in Configura (Configure) > Dispositivo (Device), è possibile che venga visualizzato un messaggio di errore ma che non venga segnalato il nome del segmento in cui si è verificato l'errore.

    Ad esempio durante il passaggio dell'interfaccia dell'Edge da route a commutata a livello di profilo, l'utente visualizza una stringa 'object.segment.name' anziché il nome del segmento quando si verifica un errore nelle impostazioni del dispositivo.


    Se l'azienda del cliente utilizza più segmenti, la risoluzione del problema diventa molto difficile quando non è chiaro in quale segmento si verifica l'errore.

  • Problema 80445 risolto: Quando configura OSPF in VMware SASE Orchestrator, un utente può notare che l'ID area OSPF consente voci duplicate tra IP e numero e il valore dell'ID area OSPF "0" è consentito come ID valido.

    Orchestrator non verifica la presenza di voci duplicate nell'IP e nel numero per gli ID area. Consente inoltre il valore "0" come ID area OSPF valido. Di conseguenza, l'utente può configurare e pubblicare per errore una configurazione OSPF non valida che causa effetti negativi.

  • Problema 81364 risolto: Quando si utilizza la nuova interfaccia utente di Orchestrator per configurare le interfacce di VMware SD-WAN Edge, le impostazioni di velocità e duplex non vengono aggiornate per le interfacce instradate.

    In un Orchestrator che non include la correzione per questo problema, l'utente deve utilizzare Orchestrator classico per configurare le impostazioni di velocità e duplex per l'interfaccia instradata di un Edge.

  • Problema 81366 risolto: Quando si utilizza la nuova interfaccia utente di Orchestrator per configurare il sito di un cliente utilizzando l'alta disponibilità, le modifiche non vengono salvate per l'intervallo di probe APR nei valori LOS.

    L'intervallo di probe APR rivisto in Rilevamento LOS (LOS Detection) non include i valori configurati per l'Edge HA. In un Orchestrator che non include la correzione per questo problema è necessario configurare i valori del probe APR in Orchestrator classico.

  • Problema 83342 risolto: Quando si tenta di creare un report con un numero eccessivo di Edge, in VMware SASE Orchestrator viene visualizzato un messaggio di errore vago che non spiega il motivo per cui il report non è stato creato correttamente.

    In seguito alla generazione di un report che causa un errore non vengono visualizzati i dettagli dell'errore nell'interfaccia utente e l'utente non può quindi correggere ciò che causa l'errore.


    In un Orchestrator che non include la soluzione per questo problema, i dettagli mancanti sono disponibili nei dati del registro del servizio.

    N/D

  • Problema 83345 risolto: Se il tentativo di creare un report non riesce in VMware SASE Orchestrator perché si verifica il timeout, nell'interfaccia utente non viene visualizzato un errore di convalida.

    Questo ticket è correlato al problema 83342 e in entrambi i casi i registri non includono dettagli sufficienti per eseguire il debug del problema. La differenza in questo caso è la causa del problema. La generazione di un report senza Edge può causare anche il timeout di un report senza che venga visualizzata alcuna spiegazione dell'errore.

  • Problema 83694 risolto: Quando un utente accede all'interfaccia utente locale di un VMware SD-WAN Edge, VMware SASE Orchestrator non registra e non visualizza questa azione in Monitora (Monitor) > Eventi (Events).

    Gli amministratori del cliente non saranno quindi a conoscenza degli accessi degli utenti all'interfaccia utente locale di un Edge.

  • Problema 84064 risolto: Un cliente che distribuisce Microsoft Azure Virtual Hub può configurare BGP in VMware SASE Orchestrator.

    BGP non è ufficialmente supportato in "Microsoft Azure Virtual Hub", che è automatizzato. Gli utenti sono tuttavia autorizzati a configurare BGP in Orchestrator e se un utente configura l'automazione di Azure con BGP, i tunnel diventano inattivi per il Gateway e il sito di Azure non passa il traffico.


  • Problema 88811 risolto: In un VMware SASE Orchestrator che utilizza la versione 5.0.x, un superuser operatore non può creare token API per gli utenti dei clienti, anche se dispongono di privilegi delegati.

    Questo problema si verifica perché il superuser operatore non dispone del privilegio CREATE ENTERPRISE_API_TOKEN. Di conseguenza, l'operatore non può creare, leggere o revocare token API per gli altri utenti.

  • Problema 88845 risolto: Quando un utente tenta di rimuovere interfacce da un elenco di VLAN aziendali e salva le modifiche in un VMware SASE Orchestrator tramite l'interfaccia utente classica, Orchestrator non rimuove le interfacce.

    Durante il salvataggio delle modifiche di questa azione, Orchestrator ignora la modifica della configurazione perché il formato dei dati json non corrisponde al formato dei dati dell'interfaccia utente classica.

  • Problema 88910 risolto: In un VMware SASE Orchestrator che esegue la versione 4.5.1 o 5.0.x, l'utente non riesce a eseguire un test della velocità del link WAN per un VMware SD-WAN Edge utilizzando Diagnostica remota (Remote Diagnostics) > Test velocità link WAN (WAN Link Speed Test).

    Quando si tenta di utilizzare la diagnostica del test della velocità del link WAN, l'utente non potrà scegliere un'interfaccia per il test della velocità poiché non è presente alcun menu a discesa per le interfacce.

    In un Orchestrator che non include la correzione per questo problema, se un utente desidera forzare un test della larghezza di banda per un link WAN, può modificare il metodo di misurazione della larghezza di banda per tale link WAN attivando automaticamente un nuovo test. Questa operazione può essere eseguita nel modo seguente:

    1. Nell'interfaccia utente di Orchestrator per un Edge specifico, passare a Configura (Configure) > Dispositivo (Device) e scorrere verso il basso fino a Impostazioni WAN (WAN Settings).

    2. Per il link WAN da sottoporre a nuovo test, selezionare Modifica (Edit)per rimisurarlo e quindi selezionare Avanzato (Advanced) per visualizzare le impostazioni aggiuntive.

    3. Nel menu Misurazione della larghezza di banda (Bandwidth Measurement) modificare il metodo di misurazione della larghezza di banda da quello corrente a un metodo diverso (ad esempio se il link utilizza la modalità burst, impostarlo su Avvio lento (Slow Start) o viceversa) e fare clic su Aggiorna link (Update Link) e quindi su Salva modifiche (Save Changes) nella parte superiore della pagina Dispositivo (Device).

    4. Dopo aver eseguito una misurazione nel link WAN, sostituire il metodo di misurazione con il metodo originale per garantire la misurazione più accurata per il rispettivo link WAN. In questo modo si attiva un test della larghezza di banda aggiuntivo.

  • Problema 88998 risolto: Un utente non può clonare un criterio di business o una regola del firewall in un VMware SASE Orchestrator che esegue la versione 5.0.x utilizzando l'interfaccia utente classica.

    Nella versione 5.0.x per l'interfaccia utente classica di Orchestrator, le opzioni IPv6 e Misto (Mixed) (IPv4 e IPv6) sono state disabilitate per la regola del criterio di business dell'Edge. Gli utenti possono tuttavia utilizzarle per clonare regole già esistenti, ma il risultato è un messaggio di errore.

    Questo problema non si verifica nella nuova interfaccia utente di Orchestrator e un utente può risolvere il problema usando la nuova interfaccia utente.

  • Problema 91231 risolto: Per un VMware SASE Orchestrator distribuito con una topologia di Disaster Recovery, è possibile che la configurazione iniziale della replica di DR non riesca se viene attivato un processo di troncamento di una tabella di grandi dimensioni durante la fase di importazione della tabella di grandi dimensioni del processo DR.

    Se l'importazione in background delle statistiche dura più di 24 ore, entra in collisione con i processi di troncamento automatico che vengono eseguiti quotidianamente. Il processo tronca le partizioni precedenti delle tabelle di grandi dimensioni che vengono replicate anche nel server MySQL di standby.

    Tra un processo e l'altro, è tuttavia possibile che in MySQL sia in corso l'importazione di dati per la stessa tabella. Questo causa la mancata riuscita della replica e del processo DR complessivo.

    Se questo problema si verifica in un Orchestrator senza la correzione, il processo DR può essere avviato dopo l'ora di modifica del giorno UTC. Questo non garantisce tuttavia che il problema non si verifichi quando Orchestrator ha grandi dimensioni e il completamento di DR richiede più di 24 ore.

  • Problema 93846 risolto: Per i partner e gli operatori che gestiscono l'inventario dell'Edge utilizzando ZTP, quando un utente tenta di riassegnare a un altro cliente un VMware SD-WAN Edge precedentemente assegnato a un cliente e quindi eliminato, VMware SASE Orchestrator restituisce il messaggio di errore "Edge non trovato" (Edge is not found).

    Orchestrator stabilisce che l'Edge non esiste perché non vede l'Edge logico dopo che è stato eliminato dall'azienda di un cliente e un utente non è in grado di riassegnarlo a un altro cliente.

Problemi noti

Problemi noti di Edge/Gateway

Problemi ancora irrisolti nella versione 5.1.0.

  • Problema 105933: Un utente non può accedere tramite SSH a VMware SD-WAN Edge modello 610/610-LTE o 520/540 tramite un'interfaccia instradata.

    Non è presente alcuna regola di eliminazione per i pacchetti SSH duplicati originati tramite un driver af-pkt utilizzato dal sistema operativo dell'Edge interessato. Per questo motivo, il kernel dell'Edge riceve 2 pacchetti SSH: uno tramite l'interfaccia vce1 e un altro pacchetto SSH diretto a causa della natura del driver. Di conseguenza, il kernel Edge risponde a 2 richieste SSH, confondendo il client SSH e causando un errore di SSH.

    Soluzione: in un Edge senza una correzione per questo problema, l'utente può aggiungere una regola della tabella IP per eliminare i pacchetti SSH ricevuti da interfacce diverse da vce1.

  • Problema 115136: un cliente può osservare un aumento rapido dell'utilizzo della memoria in un VMware SD-WAN Edge nell'azienda di un cliente che utilizza BGP per il routing.

    Il daemon BGP dell'Edge causa una perdita di memoria rapida nell'Edge nel corso di diversi giorni e può farlo anche quando BGP non è configurato per tale Edge. Se la perdita di memoria continua per un periodo di tempo sufficiente a superare la soglia critica del 60% della RAM disponibile per più di 90 secondi, l'Edge riavvierà il servizio in modo difensivo per eliminare la perdita, e questo può causare un'interruzione delle attività del traffico del cliente per 10-15 secondi.

    Soluzione: L'unica correzione senza una correzione dell'Edge consiste nel riavviare il processo BGP terminato o eseguire preventivamente un failover HA/riavvio del servizio Edge in una finestra del servizio idonea.

  • Problema 117037: 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.

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

Problemi noti di Orchestrator

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