Aggiornamento: 8 giugno 2022 VMware SD-WAN™ Orchestrator versione R421-20211216-GA VMware SD-WAN™ Gateway versione R421-20210407-GA VMware SD-WAN™ Edge versione R421-20210624-GA-57011-60130 Controllare periodicamente le aggiunte e gli aggiornamenti delle presenti note di rilascio.

Contenuto delle note di rilascio

Le note di rilascio riguardano i seguenti argomenti:

• Uso consigliato
• Compatibilità
• Note importanti
• Cronologia delle revisioni
• Problemi risolti
• Problemi noti

Uso consigliato

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

Compatibilità

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

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

Orchestrator	Gateway	Edge
		Hub	Filiale/spoke
4.2.0	4.2.0	4.2.0	4.2.1
4.2.0	4.2.0	4.2.1	4.2.1
4.2.1	3.4.2	3.4.2	3.4.2
4.2.1	4.2.1	3.4.2	3.4.2
4.2.1	4.2.1	4.2.1	3.4.2
4.2.1	4.2.1	3.4.2	4.2.1
4.2.1	4.2.1	3.4.5	3.4.5
4.2.1	4.2.1	4.2.1	3.4.3, 3.4.4, 3.4.5
4.2.1	4.2.1	3.4.3, 3.4.4, 3.4.5	4.2.1
4.2.1	3.3.2 P3	3.3.2 P3	3.3.2 P3
4.2.1	4.2.1	3.3.2 P3	3.3.2 P3
4.2.1	4.2.1	4.2.1	3.3.2 P2, 3.3.2 P3
4.2.1	4.2.1	3.3.2 P2	4.2.1
4.2.1	3.2.2	3.2.2	3.2.2
4.2.1	4.2.1	3.2.2	3.2.2
4.2.1	4.2.1	4.2.1	3.2.2
4.2.1	4.2.1	3.2.2	4.2.1
4.2.1	4.0.0	4.0.0	4.0.0
4.2.1	4.0.0	4.0.1	4.2.1
4.2.1	4.2.1	4.0.0	4.0.1

Attenzione: le versioni 4.0.x e 4.2.x di VMware SD-WAN stanno per raggiungere la fine del supporto. 

• Le versioni 4.0.x raggiungeranno 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 raggiungeranno la fine del supporto generale (EOGS, End of General Support) il 30 dicembre 2022 e la fine delle linee guida tecniche (EOTG, End of Technical Guidance) il 30 marzo 2023.   
• Le versioni 4.2.x per Edge raggiungeranno 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.
• 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 disabilitato (AES-256-CBC). Se un cliente utilizza AES-256, deve disabilitare esplicitamente GCM da Orchestrator prima di aggiornare gli Edge alla versione 4.x. Quando in tutti gli Edge è in esecuzione la versione 4.x, il cliente può scegliere tra AES-256-GCM e AES-256-CBC.

Note importanti

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 il carattere di delimitazione spazio in una configurazione per anteporre AS-Path.
I clienti che effettuano l'aggiornamento dalla versione 3.x alla versione 4.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 possono richiedere più tempo del normale (3-5 minuti) nei modelli Edge 3x00 (ovvero 3400, 3800 e 3810). Ciò è dovuto a un aggiornamento del firmware che risolve il problema 53676. Se il firmware di un Edge 3400 o 3800 viene aggiornato nella versione 3.4.5 o 4.0.2, l'aggiornamento dell'Edge verrà eseguito nel modo previsto. Per ulteriori informazioni, consultare il problema 53676 risolto.

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

Quando un utente disabilita la negoziazione automatica per la velocità hardcode e il duplex nelle porte GE1 - GE4 in un modello 620, 640 o 680 di VMware SD-WAN Edge, nelle porte 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 nelle porte 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 disabilita la negoziazione automatica nei modelli 520, 540, 620, 640, 680, 3400, 3800 e 3810 (87208) di VMware SD-WAN Edge.

Cronologia delle versioni del documento

9 aprile 2021. Prima edizione.

13 aprile 2021. Seconda edizione.

• Problema 53676 risolto aggiunto alla sezione dei problemi risolti di Edge/Gateway.  Questo problema era stato erroneamente omesso dalle note di rilascio originali.
• Aggiunta di una sezione Note importanti in cui viene spiegato il tempo di aggiornamento esteso di un Edge 3x00 se il firmware deve essere aggiornato come parte della correzione per il problema 53676.

21 aprile 2021. Terza edizione.

• Aggiunta di una nuova build di Orchestrator: R421-20210415-GA come build più recente.  Aggiunta di una nuova sezione per R421-20210415-GA in Problemi risolti di Orchestrator.
• Aggiunto il ticket 61312 nella sezione relativa alla versione R421-20210415-GA in Problemi risolti di Orchestrator.

7 maggio 2021. Quarta edizione.

• La tabella Compatibilità (Compatibility) è stata rivista per includere due nuove combinazioni testate:
  • La versione 4.2.0 di Orchestrator e Gateway è compatibile con un Edge hub che utilizza la versione 4.2.0 e un Edge spoke che utilizza la versione 4.2.1.
  • La versione 4.2.0 di Orchestrator e Gateway è compatibile con un Edge hub che utilizza la versione 4.2.1 e un Edge spoke che utilizza la versione 4.2.1.
• Problemi 55949 e 56149 risolti aggiunti alla sezione dei problemi risolti di Edge/Gateway. Questi ticket avrebbero dovuto essere inclusi nelle note di rilascio originali di GA.

15 giugno 2021. Quinta edizione.

• Modificato il problema risolto 56876 di Edge/Gateway, in modo da includere un secondo scenario che la correzione di questo problema prevede e che riguarda anche la gestione della memoria che causa un errore grave e un riavvio del kernel dell'Edge.
• Aggiunto il problema risolto 54001 di Edge/Gateway, erroneamente omesso dalle edizioni precedenti.

5 agosto 2021. Sesta edizione.

• Aggiunta di un nuovo ticket alla sezione dei problemi ancora irrisolti dell'Edge o del gateway: #60006, #60225, #61361, #62552, #63359 e #67790.

11 agosto 2021. Settima edizione.

• Aggiunta una nuova versione di Edge R421-20210624-GA-57011-60130 e spostati i ticket esistenti 57011 e 60130 nella nuova sezione creata per tale build dell'Edge.

16 settembre 2021. Ottava edizione. 

• Aggiunta alle Note importanti la nota: Modifica del delimitatore di configurazione del filtro BGPv4 per l'anteposizione di AS-PATH.

21 dicembre 2021. Nona edizione.

• Aggiunta una nuova build di Orchestrator R421-20211216-GA alla sezione Problemi risolti di Orchestrator. Questa build di Orchestrator corregge CVE-2021-44228, la vulnerabilità di Apache Log4j, eseguendo l'aggiornamento a Log4j versione 2.16.0. Per ulteriori informazioni sulla vulnerabilità di Apache Log4j, consultare l'avviso di sicurezza di VMware VMSA-2021-0028.5.
• Aggiunta alle Note importanti la nota: Limitazione quando si disabilita la negoziazione automatica nei modelli 520, 540, 620, 640, 680, 3400, 3800 e 3810 di VMware SD-WAN Edge. Questa nota illustra un problema che può verificarsi durante la configurazione di una velocità forzata in alcune porte Ethernet dei modelli di Edge elencati.

24 marzo 2022, decima edizione

• Aggiunto il problema 84825 alla sezione Problemi noti di Edge/Gateway.

7 giugno 2022, undicesima edizione

• Aggiunto il problema risolto 54493 alla sezione Problemi risolti di Edge/Gateway. Questo problema è stato omesso per errore nell'edizione originale delle Note di rilascio della versione 4.2.1.

Problemi risolti

I problemi risolti sono raggruppati come segue.

• Problemi risolti dell'Edge
• Problemi risolti di Edge/Gateway
• Problemi risolti di Orchestrator

Problemi risolti dell'Edge

Risolto nella versione R421-20210624-GA-57011-60130

I problemi seguenti sono stati risolti dalla versione di Edge R421-20210407-GA.

• Problema 57011 risolto: Ogni volta che in un sito configurato con una topologia ad alta disponibilità (HA) vengono aggiunti e quindi eliminati segmenti, è possibile che in uno degli Edge HA si verifichi un errore del servizio piano dati. Se l'errore del servizio si verifica nell'Edge attivo, nel sito si verifica anche un failover HA.

  Quando in un sito HA vengono aggiunti e quindi eliminati segmenti, è possibile che siano presenti segmenti obsoleti (ad esempio, i segmenti eliminati potrebbero ancora essere visibili in uno degli Edge nella coppia HA). A causa di questa mancata corrispondenza delle informazioni del segmento tra gli Edge HA, qualsiasi evento destinato al segmento obsoleto può essere inviato all'altro Edge causando un errore del servizio piano dati, un failover HA se l'errore del servizio si verifica nell'Edge attivo e la generazione di un dump core che verrà segnalato in un bundle di diagnostica eseguito dopo il failover. non esistono soluzioni a questo problema.

• Problema 60130 risolto: In un sito possono verificarsi periodi intermittenti di elevata perdita di pacchetti e problemi di connettività.

  Ciò è causato dall'API che verifica la risoluzione ARP comunicando all'Edge che è presente una risoluzione ARP corretta per un dispositivo ma consegna un indirizzo MAC 00:00:00:00.  Questo indirizzo viene mantenuto nella cache di ARP e tutti i pacchetti destinati al dispositivo in cui l'indirizzo MAC è zero vengono eliminati. Quando si verifica questo problema, vengono consegnate molte di queste istanze di ARP corretto con indirizzo MAC zero causando l'elevata perdita di pacchetti e problemi di connettività.

  Questa correzione risolve i problemi relativi al valore memorizzato nella cache degli indirizzi MAC in un flusso (la causa più comune del problema), tuttavia questa correzione non affronta uno scenario più raro in cui ARP si memorizza nella cache e quindi restituisce un MAC pari a zero. Questo problema verrà affrontato in 62552. Oltre a disporre di un'immagine di Edge con la correzione, non è disponibile alcuna soluzione per questo problema.

Problemi risolti di Edge/Gateway

Risolti nella versione R421-20210407-GA

Nella versione R420-20201218-GA di Edge e R420-20210208-GA-53243-54800 di Gateway sono stati risolti i seguenti problemi.

• Problema 51025 risolto: Se un link WAN passa rapidamente tra lo stato attivo e lo stato inattivo (ovvero si verifica un flap) in un VMware SD-WAN Edge, è possibile che la voce della tabella di routing per il gateway predefinito dell'interfaccia instradata venga rimossa e non riapplicata.

  In un Edge con questo problema, si verifica un flap del link e la voce di routing del gateway predefinito viene rimossa per l'interfaccia che utilizza tale link. La tabella di routing per l'interfaccia risulta quindi vuota. Tuttavia, se si lascia la tabella di routing vuota, per impostazione predefinita il rilevamento connessioni (conntrack) di Linux eseguirà l'instradamento alla tabella successiva causando l'uscita di tutti i pacchetti attraverso l'interfaccia instradata errata.

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

  La sequenza di eventi causa questo problema quando un Edge hub primario viene recuperato dal failover:
  1. Quando l'Edge hub primario viene disattivato, la route viene rimossa dalla FIB di quell'Edge hub primario, mantenendo le route nella RIB.
  2. I flussi esistenti saranno a questo punto commutati nell'Edge hub secondario.
  3. Alla riattivazione dell'hub primario, viene immediatamente stabilito un tunnel tra l'hub primario e l'Edge spoke.
  4. Le route nella RIB apprese precedentemente dall'hub primario tramite il gateway vengono scansionate e le route vengono installate nella FIB che punta a questo hub primario.
  5. Il traffico passerà di nuovo all'hub primario, mentre l'hub primario non avrebbe appreso le route dal proprio router adiacente BGP.
  6. In questo modo, la ricerca della route corrisponde alla route predefinita e il traffico di ritorno viene contrassegnato con un flag di backhaul.
  7. L'Edge spoke non prevede traffico di ritorno con un flag di backhaul impostato e ciò comporta il calo del traffico. 

  Senza questa correzione, la soluzione consiste nell'accedere all'Edge hub ed eseguire la diagnostica remota "Svuota flussi" per la tupla specificata. Il traffico verrà ripristinato.

• Problema 53415 risolto: Nell'azienda di un cliente in cui è abilitata la funzionalità Edge Network Intelligence (ENI), se nel VMware SD-WAN Edge dell'azienda è abilitata la rete Wi-Fi, è possibile che nella pagina ENI venga visualizzato un indirizzo MAC errato per il punto di accesso Wi-Fi e che venga indicato l'IP del punto di accesso 160.254.3.1.

  Il problema è il risultato di una configurazione errata dell'indirizzo MAC del punto di accesso Wi-Fi che viene impostato su un valore denominato "selfMacAddress" e dell'indirizzo IP del punto di accesso che viene sempre configurato per 160.254.3.1 nella pagina ENI. La correzione consente di derivare l'indirizzo MAC dall'interfaccia Wi-Fi wlan0 e l'indirizzo IP dell'interfaccia di analisi.

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

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

• Problema 53651 risolto: Nel sito di un cliente che utilizza una topologia ad alta disponibilità avanzata, quando si effettua una modifica della configurazione nell'impostazione di un dispositivo VMware SD-WAN Edge che richiede il riavvio del servizio Edge, possono verificarsi due failover dell'alta disponibilità in successione.

  Per una modifica della configurazione dell'impostazione del dispositivo che richiede il riavvio del servizio Edge, il modulo dell'alta disponibilità aggiorna in modo errato il conteggio di LAN/WAN in VMware SD-WAN Gateway prima che il servizio Edge venga riavviato durante l'elaborazione della configurazione. Di conseguenza, quando si verifica il failover dell'alta disponibilità iniziale e il servizio Edge attivo corrente viene riavviato come parte dell'abbassamento al livello di standby, il Gateway non comprende che il nuovo Edge di standby dispone di un conteggio LAN/WAN migliore e invia un comando di failover all'Edge attivo appena promosso, causando il secondo failover.

  Nota: per un elenco di modifiche della configurazione dell'Edge che possono attivare il riavvio di un servizio, consultare l'articolo della Knowledge Base relativo alle modifiche della configurazione di VMware SD-WAN Edge che possono attivare il riavvio del servizio (60247)

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

  Questo problema si verifica in genere quando si utilizza un gruppo di continuità UPS in cui si verifica una leggera instabilità della tensione di output durante il passaggio dalla linea alla batteria. La correzione di questo problema aggiorna il firmware dell'Edge in modo che tolleri 20-30 ms di instabilità della tensione prima di riavviare l'Edge.

  Nota: se si aggiorna il firmware dell'Edge 3x00, il tempo di aggiornamento dell'Edge verrà esteso a 3-5 minuti se il firmware dell'Edge non è stato in precedenza aggiornato durante l'utilizzo della versione 3.4.5 o 4.0.2.

  In un modello di Edge 3x00 senza questa correzione, l'unica possibilità del cliente è utilizzare un gruppo di continuità UPS più sofisticato in grado di cambiare input senza alcuna instabilità della tensione di output. 

• Problema 53789 risolto: Negli Edge virtuali VMware SD-WAN in esecuzione in ESXi, in /var/log/messages viene inserito ogni 30 secondi un messaggio di errore spurio.

  Il messaggio di errore spurio viene visualizzato come GuestInfoGetDiskDevice: Missing disk device name; VMDK mapping unavailable for "/", fsName: "/dev/root" e viene sempre inserito in /var/log/messages riempiendo /var/log/messages e la sua controparte salvata /velocloud/log/messages*. In questo modo, i messaggi più importanti vengono eliminati e persi quando si consultano i registri per l'Edge interessato.

• Problema 53929 risolto: Nel sito di un cliente che utilizza una topologia ad alta disponibilità avanzata, dopo un failover dell'alta disponibilità, i flussi "Cloud tramite gateway" (Cloud via Gateway) passano a un percorso "Diretto al cloud" (Direct to Cloud).

  Dopo un failover dell'alta disponibilità, se il percorso verso VMware SD-WAN Gateway non è attivo quando il traffico raggiunge VMware SD-WAN Edge, il traffico diventa "Diretto al cloud" (Direct to Cloud) anziché "Cloud tramite gateway" (Cloud via Gateway). Ciò può avere un impatto significativo per i flussi che si basano su Dynamic Multipath Optimization come il traffico in tempo reale (ad esempio voce e video) perché il traffico diretto non utilizza queste ottimizzazioni.

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

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

• Problema 54493 risolto: Un operatore o un amministratore partner può notare un numero crescente di eliminazioni della coda di handoff per il traffico dell'Edge in un VMware SD-WAN Gateway. 

  Per questo problema, nel Gateway non si verificheranno problemi di utilizzo della CPU o eliminazioni di DPDK. Il problema viene attivato da un evento del piano di controllo (ad esempio il ricalcolo della route) e il Gateway inizia a eliminare pacchetti dell'Edge durante l'handoff a thread diversi nella pipeline del Gateway. La causa del problema è una coda di dimensioni insufficienti per il buffering dei pacchetti.

• Problema 54694 risolto: Quando un cliente utilizza il polling SNMP, il monitoraggio SNMP fornisce misure imprecise per il traffico in uscita

  La chiamata SNMP per IF-MIB::ifHCOutOctets consegna pacchetti TX anziché byte TX, causando conteggi degli ottetti in uscita errati. Ciò influisce sulla capacità del cliente di monitorare la propria azienda. Questo problema è il risultato del processo snmpagent che monitora i pacchetti TX rispetto ai byte TX.

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

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

• Problema 56149 risolto: Dopo l'abilitazione di Dynamic Cost Calculation (DCC) nell'azienda di un cliente che utilizza BGP, è possibile che in VMware SD-WAN Edge venga visualizzato un valore di preferenza della route errato per le route corrette automaticamente se si verifica il flap della route BGP per la route underlay.

  L'impatto per il cliente è il routing asimmetrico dovuto alla preferenza della route remota errata, che causa una latenza più elevata e prestazioni scarse in tutte le applicazioni del cliente. Dopo l'abilitazione di DCC, il nuovo valore della preferenza RIB (Routing Information Base) deve essere aggiornato nella route e la route deve essere annunciata nuovamente al VMware SD-WAN Gateway con il nuovo valore della preferenza RIB che viene quindi comunicato a tutti gli Edge. La causa del problema consiste nel fatto che quando la route viene corretta automaticamente, questa preferenza RIB non viene aggiornata nella tabella FIB dell'Edge peer, che conserva il vecchio valore che era presente prima dell'abilitazione di DCC. 

• Problema 56346 risolto: Un cliente può notare eliminazioni coda di handoff quando visualizza la pagina Monitora (Monitor) > Sistema (System) di VMware SD-WAN Edge.

  Gli aggiornamenti degli eventi della route di VCRP (VeloCloud Route Protocol) causano eliminazioni coda di handoff nel thread di dati di VCMP (VeloCloud Management Plane).  Ciò si verifica perché quando viene ricevuto un aggiornamento della route, tutte le route nel rispettivo segmento vengono invalidate. Ciò comporta nuove ricerche di route nel percorso dei dati. Una funzione specifica che viene chiamata come parte della ricerca di route esegue una costosa operazione di enumerazione hash che porta al 40% di aumento dell'utilizzo del thread dei dati di VCMP.  Quando questo problema è stato rilevato sul campo, la quantità di eliminazioni coda di handoff non era tale da influire negativamente sulle prestazioni della rete.

• Problema 56483 risolto: I valori di perdita di pacchetti, jitter e latenza non vengono visualizzati nel monitoraggio in tempo reale del link WAN nella schermata Monitora (Monitor) > Trasporto (Transport) in un VMware SD-WAN Orchestrator.

  Un utente non è in grado di recuperare in tempo reale i dati relativi alla perdita di pacchetti, al jitter o alla latenza per un determinato link WAN in Monitora (Monitor) > Trasporto (Transport) e il grafico viene visualizzato come una linea piatta. Inoltre, quando esamina la schermata Monitora (Monitor) > Edge > Panoramica (Overview), tutti i valori per perdita, jitter e latenza vengono espressi come "0". Le statistiche cronologiche vengono visualizzate correttamente in Monitora (Monitor) > Trasporto (Transport). Questo problema riguarda infatti solo le statistiche della modalità live. 

• Problema 58535 risolto: Quando un cliente configura un firewall stateful e in Protezione rete e flooding configura anche un elenco di elementi non consentiti, per tale elenco vengono automaticamente definite le impostazioni più aggressive per le nuove connessioni e il firewall stateful blocca ogni nuova connessione.

  Il problema ha un impatto critico per i clienti che utilizzano un firewall stateful perché rende inutilizzabile l'elenco degli elementi non consentiti. Quando l'elenco degli elementi non consentiti è abilitato, gli eventi del firewall vengono compilati con i registri: "FLOOD_ATTACK_DETECTED" e "Blacklisting source: xxx.xxx.x.x exceeded CPS limit : 0 per source"  in cui l'indirizzo IP è l'indirizzo IP di gestione dell'Edge e CPS è il numero di connessioni al secondo. Il limite della soglia della nuova connessione viene impostato su 0% che di fatto significa che tutti i tentativi di connessione attivano l'elenco di elementi non consentiti che blocca tutte le connessioni.  Il valore predefinito della soglia della nuova connessione è 25%.

• Problema 56876 risolto: È possibile che in un VMware SD-WAN Edge si verifichi un problema relativo alla gestione della memoria che causa un errore grave del kernel con conseguente riavvio dell'Edge.

  Questo problema risolto include le correzioni per due diversi scenari relativi alla gestione della memoria in un Edge che causa un errore grave del kernel:

  1. Nel primo scenario in cui un Edge utilizza la configurazione dinamica da filiale a filiale, vengono creati i tunnel dinamici e viene riservata una piccola quantità di memoria per l'archiviazione dei contatori per ogni peer. Quando il tunnel dinamico viene eliminato, questa memoria non viene pulita in modo da ottimizzare il tempo di attivazione alla successiva connessione dello stesso peer. In un Edge di piccole dimensioni (ad esempio, Edge 500, 510, 520 e 610) che si connette a un numero elevato di destinazioni diverse nel tempo, questo può esaurire la memoria disponibile e generare un errore grave del kernel e un riavvio dell'Edge.  Senza questa correzione, l'utente deve riavviare proattivamente il servizio Edge se l'utilizzo della memoria indicato nelle statistiche dell'integrità della schermata Monitora (Monitor) > Sistema (System) in VMware SD-WAN Orchestrator è superiore al 90%.
  2. Durante il processo di correzione della perdita di memoria causata dalla configurazione dinamica da filiale a filiale, è stato notato che malloc_trim (un processo che cancella la memoria frammentata) non veniva richiamato correttamente e questo processo è stato modificato anche per questa correzione. Se il processo malloc_trim non viene richiamato correttamente, può causare un problema diverso che può riguardare qualsiasi Edge (non solo gli Edge di dimensioni più piccole) e non solo quelli che utilizzano la configurazione dinamica da filiale a filiale, nè quelli in cui in Monitora (Monitor) > Sistema (System) l'utilizzo della memoria risulta superiore al 90%. È molto più probabile che questo scenario si verifichi se l'Edge ha un numero elevato di flussi.
• Problema 56931 risolto: Nel sito di un cliente che ha configurato una destinazione NSD (Non SD-WAN) tramite Edge è possibile che vengano visualizzate statistiche di integrità dell'Edge errate nell'interfaccia utente di VMware SD-WAN Orchestrator.

  Quando un NSD viene configurato dall'Edge, il servizio SD-WAN invia statistiche di integrità dall'Edge a Orchestrator con un'ora di inizio 0 per la prima volta dopo il riavvio. In questo modo, in Orchestrator vengono visualizzati dati errati dopo il riavvio dell'Edge.

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

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

Problemi risolti di Orchestrator

Versione di Orchestrator R421-20211216-GA

La versione R421-20211216-GA di Orchestrator è stata rilasciata il 20-12-2021. Questa build di Orchestrator corregge CVE-2021-44228, la vulnerabilità di Apache Log4j, eseguendo l'aggiornamento a Log4j versione 2.16.0. Per ulteriori informazioni sulla vulnerabilità di Apache Log4j, consultare l'avviso di sicurezza di VMware VMSA-2021-0028.5.

___________________________________________________________________

Risolti nella versione R421-20210415-GA

Nella versione di Orchestrator R421-20210326-GA sono stati risolti i problemi seguenti.

• Problema 61312 risolto: È possibile che in un VMware SD-WAN Orchestrator si verifichi un problema per cui le route non vengono più aggiornate e l'utilizzo della CPU di Orchestrator è prossimo al 100%, specialmente dopo l'aggiornamento di Orchestrator.

  Questo problema si verifica quando un Edge invia ~2K+ di aggiornamenti della route all'API di routing di Orchestrator. Negli scenari in cui Orchestrator non è in grado di elaborare l'intero set di route inviate durante una chiamata API specifica entro 60 secondi, si verifica un timeout della chiamata che causa il rifiuto totale della chiamata API. L'Edge riceve questo rifiuto e tenta di eseguire nuovamente il push delle stesse 2K+ route in Orchestrator, causando di nuovo lo scenario precedente. Ciò crea un ciclo che sovraccarica le risorse vCPU di Orchestrator. Quando questo problema si verifica, può impedire l'elaborazione degli aggiornamenti della route. 

  Per risolverlo, sono state aggiunte due proprietà di sistema:

  edge.learnedRoute.maxRoutePerCall Questa proprietà assicura che solo un numero limitato di route vengano elaborate da un Edge. Se il valore della proprietà è "200", vengono elaborate 200 route per ogni richiesta dell'Edge. Ciò garantisce che all'Edge venga inviata tempestivamente una conferma.

  vco.learnedRoute.simultaneous.maxQueue Questa proprietà assicura che nella coda venga inserito solo il numero configurato di richieste di routing degli Edge. Se il valore della proprietà è "8", solo 8 Edge alla volta saranno autorizzati a inviare richieste di routing. Le richieste di routing degli Edge oltre tale numero verranno rifiutate immediatamente prima dell'elaborazione delle route.

______________________________________

Risolti nella versione R421-20210326-GA

Nella versione di Orchestrator R420-20210306-GA sono stati risolti i problemi seguenti.

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

  Edge crea una connessione HTTPS a VMware SD-WAN Orchestrator per l'attivazione. Il timeout predefinito per la richiesta è 120 secondi e per la connessione con proxy è 60 secondi. Mentre Orchestrator tenta di geolocalizzare i caricamenti dell'Edge (indirizzo remoto IPv4), attende la risposta del servizio MaxMind per procedere con l'attivazione. Di conseguenza, dopo 60 secondi, NGINX smette di attendere la risposta del servizio di caricamento e chiude la connessione. L'attivazione non riesce a causa di un errore di timeout 504 di NGINX. 

  Con la nuova proprietà di sistema service.maxmind.timeout.seconds, la chiamata all'API MaxMind viene effettuata con un timeout personalizzato. Se viene raggiunto il timeout, la chiamata procede con il workflow di attivazione e di conseguenza l'Edge viene attivato correttamente.

• Problema 49997 risolto: Se in un VMware SD-WAN Orchestrator è abilitata la modalità di analisi di VMware Edge Network Intelligence, quando viene creato un nuovo utente operatore, tale operatore non è in grado di connettersi alle sezioni di analisi dell'interfaccia utente di Orchestrator.

  Gli utenti operatore creati dopo l'attivazione della modalità di analisi devono poter accedere all'interfaccia utente di VMware Edge Network Intelligence di tutti i clienti aziendali che hanno abilitato l'accesso al supporto. Se si verifica questo problema, ciò non è possibile.

• Problema 52379 risolto: VMware SD-WAN Orchestrator invia un'e-mail che avvisa che l'Edge è inattivo se VMware SD-WAN Edge viene ripristinato entro l'intervallo di ritardo configurato.

  Gli amministratori possono essere erroneamente avvisati che un Edge della rete è inattivo anche se hanno configurato un ritardo per consentire l'inattività dell'Edge per un determinato periodo di tempo prima che venga attivato l'avviso.

• Problema 53525 risolto: Quando si utilizza la nuova interfaccia utente in un VMware SD-WAN Orchestrator e si visualizza la pagina della panoramica dell'Edge, nella colonna Link (Links) non viene visualizzato lo stato del link, ad esempio Backup o Standby.

  Queste informazioni sullo stato del link vengono visualizzate correttamente nell'interfaccia utente precedente e, grazie a questa correzione, verranno visualizzate nel modo previsto nella nuova interfaccia utente.

• Problema 53652 risolto: Quando nell'azienda di un cliente che utilizza una mappa delle applicazioni personalizzata viene eseguito l'aggiornamento dalla versione 3.x alla versione 4.x, è possibile che il cliente noti nomi casuali per le applicazioni personalizzate create prima dell'aggiornamento.

  Ogni volta che una mappa delle applicazioni personalizzata viene configurata con un ID applicazione (appId) già esistente come parte della mappa delle applicazioni iniziale predefinita, in VMware SD-WAN Orchestrator viene sempre visualizzato il nome della mappa delle applicazioni iniziale predefinita che sostituisce il nome definito dal cliente. Ciò si verifica anche quando Orchestrator viene aggiornato da una versione precedente a una versione successiva e un appId della mappa delle applicazioni iniziale predefinita della versione successiva è in conflitto con un appId delle applicazioni personalizzate create nella versione precedente.  Dopo l'aggiornamento di Orchestrator, in tali applicazioni personalizzate viene visualizzato un nome errato, ovvero il nome visualizzato dell'appId della mappa delle applicazioni iniziale predefinita della versione successiva.

• Problema 53752 risolto: La migrazione dell'azienda di un cliente non riesce quando si tenta di eseguirla da un VMware SD-WAN Orchestrator che utilizza una versione 3.4.x a un Orchestrator che utilizza la versione 4.2.0.

  Lo strumento di migrazione aziendale più recente non supporta la versione 4.2.x e questa è la causa degli errori di migrazione.

• Problema 53857 risolto: La distribuzione di un VMware SD-WAN Orchestrator che utilizza un'immagine KVM basata sulla versione 4.0.0 non riesce.

  L'errore si verifica perché le dimensioni del disco virtuale dell'immagine KVM non sono corrette e i volumi non vengono espansi alle dimensioni richieste.  In una distribuzione, gli script di Orchestrator espandono automaticamente i volumi di Orchestrator in modo che occupino l'80% delle dimensioni massime dei dischi sottostanti (volumi fisici).  In questo caso, le dimensioni virtuali non corrette causano un'espansione non adeguata per i requisiti del database di Orchestrator e la distribuzione non riesce.  È possibile distribuire un Orchestrator che utilizza una build precedente senza questa correzione, ma i volumi devono essere ridimensionati manualmente.

• Problema 53987 risolto: In un VMware SD-WAN Orchestrator non è possibile effettuare ricerche nell'interfaccia utente di Orchestrator per l'evento dell'Edge "Rilevata MTU link" (Link MTU Detected).

  Questo problema si verifica nelle istanze di Orchestrator che utilizzano la versione 4.0.x e successive.  Quando si esegue una ricerca degli eventi nella pagina Eventi (Events) dell'interfaccia utente di Orchestrator, l'evento "Rilevata MTU link" (Link MTU Detected) non è disponibile nell'elenco di eventi per il filtro. È quindi difficile isolare tale evento durante la risoluzione dei problemi.

• Problema 54035 risolto: Se è abilitata la modalità di analisi di VMware Edge Network Intelligence, i pacchetti destinati al daemon syslog, al daemon aruba e al daemon snmptrap vengono eliminati in VMware SD-WAN Edge e questi dati non vengono visualizzati nel visualizzatore di Edge Network Intelligence.

  I pacchetti destinati ai daemon di Edge Network Intelligence (syslogd, amond e snmptrapd) vengono eliminati nel processo del piano dati dell'Edge perché mancano regole della tabella di IP corrispondenti. Di conseguenza, le statistiche corrispondenti non vengono ricevute nel back-end di Edge Network Intelligence.

• Problema 55259 risolto: Quando un amministratore crea un nuovo VMware SD-WAN Edge nell'interfaccia utente di VMware SD-WAN Orchestrator, il campo "Imposta posizione" (Set Location) non è presente.

  A causa di questo problema, l'amministratore può creare l'Edge ma senza informazioni sulla posizione e l'Orchestrator non può eseguire la geolocalizzazione automatica per l'Edge e assegnare i Gateway corretti.  L'amministratore deve eseguire un passaggio aggiuntivo dopo la creazione dell'Edge per accedere e compilare le informazioni sulla posizione dell'Edge nella pagina Configura (Configure) > Edge > Panoramica Edge (Edge Overview).

• Problema 55871 risolto: Alcune chiamate API a REST APIv2 (/sdwan) HTTP causano errori HTTP 500 nel server.

  In alcuni casi in cui i dati del cliente non sono conformi allo schema previsto dall'API, l'API genera un errore HTTP 500 anziché restituire dati incoerenti con lo schema documentato dell'API. Questo comportamento è stato causato da una decisione di progettazione che nel frattempo è stata modificata. Questo problema coinvolge le chiamate a "GET /enterprises", "GET /enterprises/{enterpriseLogicalId}/edges" e "GET /enterprises/{enterpriseLogicalId}/clientDevices".

• Problema 56763 risolto: In un'istanza di VMware SD-WAN Orchestrator che utilizza la versione 4.x o successiva con i report abilitati, se non è possibile generare un report per un motivo qualsiasi, non riesce nemmeno la generazione di tutti i report successivi per tutti i clienti che utilizzano Orchestrator finché non viene eseguito un riavvio del servizio back-end di Orchestrator.

  Questo problema ha un impatto significativo nell'Orchestrator in cui si verifica perché tutti i clienti che utilizzano tale Orchestrator non potranno generare report finché non verrà eseguito un riavvio del servizio back-end di Orchestrator. Questo problema si verifica perché la mancata riuscita di un singolo report causa uno stato non valido del servizio di creazione report che può essere ripristinato solo con un riavvio del servizio back-end di Orchestrator.  Ciò è dovuto al fatto che la generazione di un nuovo report non viene eseguita indipendentemente dalla generazione del report precedente.  La correzione assicura che il servizio di report continui a generare nuovi report indipendentemente da eventuali errori di generazione dei report.

• Problema 56824 risolto: In un VMware SD-WAN Orchestrator che utilizza la versione 4.2.x, il recapito degli avvisi ai destinatari di webhook non riesce quando l'URL del destinatario include un numero di porta esplicito.

  Gli utenti che in precedenza avevano configurato URL di destinatari di webhook che includevano numeri di porta espliciti possono notare che il recapito degli avvisi a tali destinatari non riesce indefinitamente. Senza la correzione di questa build, un amministratore deve configurare un proxy inverso per passare richieste al destinatario di webhook originale e aggiornare l'URL del destinatario di webhook in modo che punti al proxy inverso.

• Problema 56896 risolto: È possibile che si verifichino errori API e timeout del Gateway.

  Questo problema si verifica perché lo storage del disco di VMware SD-WAN Orchestrator diventa pieno a causa dell'accumulo di file. Questo accumulo si verifica perché esiste un modo per disabilitare l'elaborazione delle statistiche dei flussi per un VMware SD-WAN Edge o un elenco di Edge, simile a una funzionalità di elenco di elementi bloccati/non consentiti. Anche se l'elaborazione del flusso viene ignorata per questi Edge, il problema è che i file rimangono nel disco di Orchestrator senza essere eliminati. Nell'ambito in cui è stato rilevato questo problema, il monitoraggio disponibile è stato sufficiente per rilevare il problema ed evitare eventuali problemi relativi all'esperienza utente, ma in un Orchestrator in cui il monitoraggio era inferiore, questo problema avrebbe potuto influire sul traffico del cliente. Se non viene applicata questa correzione, un operatore di Orchestrator deve eliminare manualmente i file presenti nello storage del disco di Orchestrator che hanno più di 24 ore.

• Problema 56909 risolto: In un VMware SD-WAN Orchestrator che utilizza la versione 4.x, è possibile che la generazione dei report non riesca quando è incluso un link di backup.

  Se un link non include record di statistiche sul link, la generazione del report causa un errore.  Un link impostato come backup non genererà statistiche sul link se rimane un link di backup durante il periodo selezionato per il report. Senza questa correzione, l'unico modo per generare un report consiste nel deselezionare il link di backup durante la generazione di un report, in modo che il link includa alcuni dati statistici per il suo record.

• Problema 57087 risolto: Quando l'utente tenta di cambiare il profilo di un VMware SD-WAN Edge dalla schermata Configura (Configure) > Edge, si verifica un errore di convalida che include una casella di notifica con un messaggio di errore generico anziché il motivo effettivo.

  L'errore generico visualizzato è "Errore durante l'elaborazione dell'elemento. Riprovare" (Error processing item. Please try again). Per conoscere il motivo effettivo dell'errore di convalida, l'utente deve controllare la console di debug di un browser Web. Dopo la correzione, viene visualizzato il motivo o l'errore di convalida appropriato.

• Problema 58627 risolto: Gli utenti configurati per ricevere gli avvisi possono ricevere un avviso di link attivo quando in realtà il link rimane inattivo.

  A volte, dopo che un link viene contrassegnato come "Inattivo" (Down), le statistiche per tale link generate prima che il link diventasse inattivo potrebbero non essere inviate a VMware SD-WAN Orchestrator per un periodo che può arrivare fino a un minuto dopo l'evento.  Quando Orchestrator riceve queste statistiche sul link in ritardo, pensa erroneamente che il link sia di backup e quindi attiva un avviso di link attivo se le impostazioni di avviso sono aggressive (ad esempio, un ritardo di 0 minuti).  La correzione assicura che Orchestrator non interpreti le statistiche del link in ritardo come se indicassero che il link è ora attivo.

• Problema 59094 risolto: Quando un operatore tenta di aggiornare un VMware SD-WAN Orchestrator, lo script di aggiornamento non fornisce un messaggio di avviso appropriato sui requisiti per l'aggiornamento dello schema.

  Se un operatore salta il passaggio per applicare le modifiche dello schema nelle tabelle più grandi, è possibile che si verifichi un errore nei servizi di Orchestrator.  Non esiste inoltre un modo semplice per individuare le modifiche mancanti. Questa correzione risolve il problema quando, a seguito del riavvio di un servizio di back-end, rigenera eventuali modifiche dello schema mancanti necessarie in una tabella di grandi dimensioni.

• Problema 59967 risolto: Dopo aver eseguito l'aggiornamento di VMware SD-WAN Orchestrator a una versione 4.2.x o successiva, quando un utente operatore tenta di accedere alle pagine Configura (Configure) > Criterio di business (Business Policy) o Configura (Configure) > Criterio firewall (Firewall policy), la pagina non viene caricata e viene visualizzato un messaggio di errore.

  Il messaggio di errore è "Si è verificato un errore imprevisto" (An unexpected error has occurred). Questo influisce sugli utenti operatore, non sugli amministratori del partner o del cliente. Le pagine non vengono caricate a causa di un privilegio READ: OBJECT_GROUP mancante per gli operatori. Ciò significa che Orchestrator ritiene che un operatore non disponga dei privilegi necessari per accedere alle pagine Criterio di business (Business Policy) e Criterio firewall (Firewall policy).

Problemi noti

Problemi ancora irrisolti nella versione 4.2.1

I problemi noti sono raggruppati come segue.

• Problemi noti di Edge/Gateway
• Problemi noti di Orchestrator

Problemi noti di Edge/Gateway

• Problema 14655:

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

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

• Problema 25504:

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

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

• Problema 25595:

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

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

• Problema 25742:

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

• Problema 25758:

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

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

• Problema 25855:

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

  Soluzione: nessuna soluzione disponibile.

• Problema 25921:

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

• Problema 25997:

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

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

• Problema 26421:

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

• Problema 28175:

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

• Problema 31210:

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

• Problema 32731:

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

• Problema 32960:

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

• Problema 32981:

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

• Problema 34254:

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

• Problema 35778:

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

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

• Problema 35807:

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

• Problema 36923:

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

• Problema 38682:

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

• Problema 38767:

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

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

• Problema 39134:

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

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

• Problema 39374:

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

• Problema 39608:

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

• Problema 39624:

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

• Problema 39659:

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

• Problema 39753:

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

• Problema 40096:

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

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

• Problema 40421:

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

• Problema 42278:

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

• Problema 42388:

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

• Problema 42488:

  In un VMware SD-WAN Edge in cui VRRP è abilitato per una porta commutata o instradata, se il cavo viene scollegato dalla porta e il servizio Edge viene riavviato, vengono annunciate le route connesse alla LAN.

  Soluzione: non esistono soluzioni a questo problema.

• Problema 42872:

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

• Problema 43373:

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

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

• Problema 44526: Per un'azienda in cui due siti diversi distribuiscono i loro VMware SD-WAN Edge come hub utilizzando anche una topologia ad alta disponibilità e ogni sito utilizza l'altro sito hub come hub nel proprio profilo.  Se uno dei siti hub attiva un failover HA, potrebbero essere necessari fino a 30 minuti per entrambi gli Edge hub per ristabilire i tunnel tra loro. 

  Quando si verifica un failover HA, entrambi gli Edge hub tentano di avviare un tunnel tra loro contemporaneamente e nessuno dei due risponde al peer. Lo scambio di pacchetti tra i due hub viene eseguito, ma IKE non riesce mai. Questo causa un deadlock che richiede fino a 30 minuti per risolversi autonomamente. Il problema è intermittente e non si verifica dopo ogni failover HA. 

  Soluzione: per evitare che il problema si verifichi, il cliente deve configurare solo uno dei due siti hub HA in modo che utilizzi l'altro sito hub come hub nel proprio profilo.  Ad esempio, se sono presenti due siti hub HA, Hub1 e Hub2, Hub1 può avere Hub2 come hub nel proprio profilo, ma Hub2 non deve utilizzare Hub1 come hub nel proprio profilo.

• Problema 44832:

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

• Problema 44995:

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

• Problema 45189:

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

• Problema 45302:

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

• Problema 46053:

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

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

• Problema 46137:

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

• Problema 46216:

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

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

• Problema 46391:

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

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

• Problema 46918:

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

• Problema 47084:

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

• Problema 47244:

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

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

• Problema 47355:

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

• Problema 47664:

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

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

• Problema 47681:

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

• Problema 47787:

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

• Problema 48166:

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

• Problema 48175:

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

• Problema 48530:

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

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

• Problema 48597: il router adiacente BGP multihop non resta attivo se uno dei due percorsi per il peer diventa inattivo

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

  Soluzione: non esistono soluzioni a questo problema.

• Problema 48666:

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

  Soluzione: non esistono soluzioni a questo problema.

• Problema 49172:

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

• Problema 49738:

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

• Problema 50518:

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

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

• Problema 51428: potrebbe evidenziarsi una perdita di traffico multicast in un sito in cui il VMware SD-WAN Edge ha una interfaccia secondaria configurata con PIM.

  Quando un'interfaccia secondaria configurata con PIM viene spostata al volo da un segmento all'altro, pimd (il processo che gestisce PIM) potrebbe riavviarsi e nel sito si potrebbe verificare una perdita di traffico multicast intermittente.

  Soluzione: disabilitare prima l'interfaccia secondaria e quindi spostarla in un altro segmento. Una volta spostata, riattivare l'interfaccia secondaria.

• Problema 51436: per un sito che utilizza una topologia ad alta disponibilità ottimizzata durante la distribuzione di un VMware SD-WAN Edge utilizzando un modem LTE, se il sito entra in uno stato "Split-Brain", il failover dell'alta disponibilità (HA) impiega circa 5-6 minuti.

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

  Soluzione: non esistono soluzioni a questo problema

• Problema 52483: se è abilitato l'accounting underlay per un'interfaccia, il VMware SD-WAN Edge reinoltra erroneamente il traffico alla stessa interfaccia anziché inoltrarlo all'overlay.

  Questo comportamento è causato da un problema con l'accounting underlay e da una risoluzione di routing ricorsiva.

  Soluzione: disabilitare l'accounting underlay per l'interfaccia interessata.

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

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

  Soluzione: il problema persiste finché nell'Edge spoke interessato non viene riavviato il servizio Edge.

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

  Soluzione: non esistono soluzioni a questo problema.

• Problema 53359: la sessione BGP/BFD potrebbe non riuscire durante alcuni scenari di attacco DDoS.

  Se il traffico viene inoltrato (flood) dal client connesso all'interfaccia instradata al client LAN, la sessione BGP/BFD può non riuscire. Anche quando il traffico con priorità elevata in tempo reale viene inoltrato (flood) dalla destinazione di overlay, la sessione BGP/BFD può non riuscire.

  Soluzione: non esistono soluzioni a questo problema.

• Problema 53830: in un VMware SD-WAN Edge, alcune delle route nella vista BGP potrebbero non presentare la preferenza corretta e annunciare valori quando il flag DCC è abilitato causando un ordine errato nella FIB dell'Edge.

  Quando il Calcolo dei costi distribuito (DCC) è abilitato in uno scenario di scalabilità con un gran numero di route in un Edge, quando si esamina un bundle di diagnostica Edge per la bgp_view del registro, alcune delle route potrebbero non essere aggiornate correttamente con la preferenza e i valori di annuncio.  Questo problema, se incontrato, sarà relativo a pochi Edge in un'azienda di grandi dimensioni (oltre 100 Edge Spoke connessi a Edge hub o cluster hub).  

  Soluzione: questo problema può essere risolto con il riapprendimento delle route BGP underlay o eseguendo un'opzione "Aggiorna" nella pagina OFC del VMware SD-WAN Orchestrator per le route interessate. Si tenga presente che l'esecuzione dell'aggiornamento di una route comporterà il riapprendimento delle route da parte di tutti gli Edge dell'azienda.

• Problema 53934: in un'azienda in cui è configurato un cluster hub di VMware SD-WAN, se l'hub primario ha un router adiacente BGP multihop sul lato LAN, il cliente può riscontrare un calo del traffico in un Edge spoke quando si verifica un errore del lato LAN o quando BGP è disabilitato in tutti i segmenti.

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

  Soluzione: riavviare l'hub in cui si è verificato l'errore sul lato LAN (o in cui BGP è stato disabilitato).

• Problema 56218: Per il sito di un cliente distribuito con una topologia ad alta disponibilità o in cui è appena stata abilitata l'alta disponibilità, quando gli Edge vengono aggiornati dalla versione 3.2.x alla versione 3.4.x, è possibile che l'Edge di standby diventi inattivo.

  Quando è abilitata l'alta disponibilità o gli Edge ad alta disponibilità vengono aggiornati dalla versione 3.2.2 alla versione 3.4.x dopo che un'impostazione WAN viene configurata mediante l'interfaccia utente locale, l'interfaccia ad alta disponibilità (ad esempio LAN1 o GE1, in base al modello dell'Edge) viene rimossa dall'Edge di standby e lo stato dell'alta disponibilità viene impostato su HA_FAILED in VMware SD-WAN Orchestrator.

  Soluzione: riavviare l'Edge di standby per ripristinarlo

• Problema 60006: Quando l'alta disponibilità (HA) è abilitata nei VMware SD-WAN Edge basati su hardware, come il 620 e il 640, è possibile che l'Edge di standby venga riavviato.

  Quando l'alta disponibilità (HA) è abilitata in un'istanza di 620 o 640 (questi sono i modelli in cui si è verificato questo problema), l'Edge di standby può rilevare un errore grave attivo/attivo e riavviarsi per correggere lo stato attivo/attivo. Questo problema è causato dai seguenti fattori: durante l'inizializzazione dell'Edge è possibile che si verifichi una race condition tra l'inizializzazione dell'interfaccia HA e l'inizializzazione della macchina con stato HA. In altre parole, la macchina con stato HA viene avviata molto prima del completamento dell'inizializzazione del driver dell'interfaccia HA e, di conseguenza, la macchina con stato HA non rileva heartbeat dall'Edge peer e passa allo stato Attivo.  Questo problema si verifica raramente e, se si verifica per un determinato sito, è improbabile che si verifichi due volte nella stessa sessione. In altre parole, non è previsto che il sito entri in un ciclo infinito di riavvii dell'Edge di standby.

  Soluzione: Non è disponibile alcuna soluzione per questo problema, ma in genere la modalità Standby viene ripristinata dopo il primo riavvio.

• Problema 60225: Quando si esegue la diagnostica remota "Stato interfaccia" (Interface Status) per un VMware SD-WAN Edge, l'output nelle interfacce di VMware SD-WAN Orchestrator per SFP include informazioni non corrette relative alla velocità e al duplex.

  I dati in Orchestrator non sono corretti per le interfacce SFP. Ad esempio, indicando 0 Mbps / half-duplex dove, se visualizzato direttamente nell'Edge, i dati dimostrano half-duplex a 1000 Mbps o un valore simile.

  Soluzione: Non è disponibile alcuna soluzione.

• Problema 60523: Il ping verso un indirizzo IP del client instradato non riesce se è abilitato un probe SLA.

  Il pacchetto di risposta ICMP non viene elaborato dal servizio piano dati dell'Edge se è abilitato un probe SLA per l'indirizzo IP del client instradato.  Senza la correzione, l'unico modo per risolvere il problema era disabilitare il probe ICMP.

  Soluzione: Disabilitare la sonda ICMP.

• Problema 61361: Quando si applica un aggiornamento software per aggiornare VMware SD-WAN Edge 3400, 3800 e 3810 all'Edge versione 3.4.5, 4.0.2 o 4.2.1, i modelli Edge potrebbero non riavviarsi immediatamente dopo l'aggiornamento.

  Le versioni 3.4.5, 4.0.2 e 4.2.1 includono un particolare aggiornamento del firmware per il dispositivo logico programmabile complesso (CPLD) e l'aggiornamento attiva un riavvio che a volte può bloccarsi, richiedendo un ciclo di alimentazione manuale per riavviare sistema.

  Soluzione: Spegnere e riaccendere manualmente l'Edge per completare l'aggiornamento.

• Problema 61543: Se più regole NAT 1:1 sono configurate in interfacce diverse con lo stesso IP interno, il traffico in entrata può essere ricevuto in un'interfaccia e i pacchetti in uscita dello stesso flusso possono essere instradati tramite un'altra interfaccia.

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

  Soluzione: Non è disponibile alcuna soluzione per questo problema, ad eccezione di garantire che non sia configurata più di una regola NAT 1:1 con un particolare indirizzo IP interno.

• Problema 62552: In un sito possono verificarsi periodi intermittenti di elevata perdita di pacchetti e problemi di connettività.

  Ciò è causato dall'API che verifica la risoluzione ARP comunicando all'Edge che è presente una risoluzione ARP corretta per un dispositivo ma consegna un indirizzo MAC 00:00:00:00.  Questo indirizzo viene mantenuto nella cache di ARP e tutti i pacchetti destinati al dispositivo in cui l'indirizzo MAC è zero vengono eliminati.  Quando si verifica questo problema, vengono consegnate molte di queste istanze di ARP corretto con indirizzo MAC zero causando l'elevata perdita di pacchetti e problemi di connettività.

  Nota: Sia questo problema che il problema 60130 hanno lo stesso comportamento sottostante e la stessa causa, ma le correzioni previste per ogni ticket sono diverse. 60130 avrà una soluzione difensiva mentre 62552 avrà una correzione completa che impedisce il ripetersi di questo problema.

  Soluzione: non esistono soluzioni a questo problema.

• Problema 63359: Per un sito configurato con una topologia ad alta disponibilità e OSPF e in cui i VMware SD-WAN Edge utilizzano una build Edge MGMT IP, quando questi Edge vengono aggiornati da una build MGMT-IP 3.4.x a una build 4.2.x, la connettività OSPF potrebbe non funzionare correttamente dopo l'aggiornamento. 

  Quando gli Edge HA vengono aggiornati a una build MGMT-IP 4.2.x, i sistemi HA possono definire il proprio ID router come 169.254.2.2. Questo non è il comportamento previsto perché la selezione dell'ID router dell'Edge non deve tenere conto dell'indirizzo IP dell'interfaccia HA. Questo ID router interrompe la connettività OSPF e si verifica una disconnessione completa perché lo scambio di route non avviene più.

  Soluzione: Riavviare il servizio Edge (attivando un failover HA) perché ciò imporrà una riselezione dell'ID del router, che dovrebbe essere corretta dopo il riavvio.

• Problema 67790: Per l'azienda di un cliente che utilizza BGP o OSPF e ha configurato un filtro in entrata per ignorare determinate route, quando il calcolo dei costi dinamico (DCC) è abilitato in questa azienda, i filtri in entrata non saranno più attivi e il traffico tenterà di utilizzare tali route.

  Prima di abilitare DCC, la base di informazioni di inoltro (FIB) non includerà le route impostate su IGNORE nel filtro in entrata BGP/OSPF.  Dopo l'abilitazione di DCC, FIB ora include queste route e il traffico tenterà di utilizzare queste route con la possibilità di interruzione significativa del traffico per l'azienda del cliente.  

  Soluzione: Affinché il filtro in entrata venga applicato correttamente, è necessario riavviare OSPF/BGP.

• Problema 84825: per un sito distribuito con una topologia ad alta disponibilità (HA) in cui è configurato BGP, se nel sito sono configurate più di 512 regole match e set BGPv4, il cliente può notare il failover continuo della coppia di Edge HA senza che venga mai eseguito il ripristino.

  Per più di 512 regole match e set BGPv4 si intende che un cliente configura più di 256 regole di questo tipo sul filtro in entrata e 256 regole sul filtro in uscita. Questo problema potrebbe causare l'interruzione delle attività del cliente, perché il failover ripetuto fa in modo che i flussi di traffico in tempo reale, come le chiamate vocali, vengano continuamente eliminati e quindi ricreati. Quando in un Edge HA si verifica questo problema, il processo che sincronizza i thread della CPU dell'Edge non riesce e causa il riavvio dell'Edge per il ripristino. Lo stesso problema si verifica tuttavia anche nell'Edge promosso, che a sua volta viene riavviato senza alcun ripristino nel sito.

  Soluzione: senza una correzione per questo problema, il cliente deve assicurarsi che per un sito HA non vengano configurate più di 512 regole match e set BGPv4.

  Se un sito manifesta il problema e sono state configurate più di 512 regole match e set BGP/v4, il cliente deve ridurre immediatamente il numero di regole a non più di 512 per consentire il ripristino del sito.

  In alternativa, se sono richieste più di 512 regole match e set BGPv4, il cliente può effettuare il downgrade degli Edge in HA alla versione 3.4.6 in cui questo problema non si verifica; tuttavia, non saranno utilizzabili le funzionalità Edge disponibili nelle versioni successive. L'operazione può essere eseguita solo se il modello dell'Edge è supportato nella versione 3.4.6. Il cliente deve verificare questo requisito prima del downgrade.

Problemi noti di Orchestrator

• Problema 19566:

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

• Problema 21342:

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

• Problema 24269:

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

• Problema 25932:

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

• Problema 32335:

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

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

• Problema 32435:

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

• Problema 32856:

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

• Problema 32913:

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

• Problema 33026:

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

• Problema 34828:

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

• Problema 35658:

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

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

• Problema 35667:

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

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

• Problema 36665:

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

• Problema 38056:

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

• Problema 38843:

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

• Problema 39633:

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

• Problema 39790:

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

• Problema 40341:

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

• Problema 41691:

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

• Problema 43276:

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

• Problema 44153:

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

• Problema 46254:

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

• Problema 47269:

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

• Problema 47713:

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

• Problema 47820:

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

• Problema 48085:

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

• Problema 48737:

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

• Problema 49225:

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

• Problema 49790:

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

  Soluzione: ignorare l'evento duplicato.

• Problema 50531:

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

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

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

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

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

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

• Problema 60039: La Riattivazione RMA non funziona quando il modello di VMware SD-WAN Edge viene modificato.

  Quando si esegue una riattivazione di RMA per un sito in cui viene modificato anche il modello di Edge, VMware SD-WAN Orchestrator non salva la modifica del modello rendendo inefficace il link di riattivazione. Questo influisce solo sulle riattivazioni di RMA in cui viene modificato il modello di Edge. Una riattivazione di RMA in cui il modello di Edge rimane invariato funzionerà come previsto.

  Soluzione: se utilizza un modello di Edge diverso per un sito, l'utente deve creare un nuovo Edge e applicare manualmente tutte le impostazioni specifiche dell'Edge.