VMware NSX 4.1.0 | 28 FEB 2023 | Build 21332672

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

Novità

NSX 4.1.0 offre una serie di nuove funzionalità per le reti virtualizzate e la sicurezza dei cloud privati e pubblici, nonché delle infrastrutture multi-cloud. Sono stati introdotti miglioramenti e nuove funzionalità nelle seguenti aree chiave:

  • Supporto IPv6 per la comunicazione dei piani di controllo e di gestione interni di NSX: questa versione include il supporto per la comunicazione del piano di controllo e del piano di gestione tra i nodi di trasporto e gli NSX Manager tramite IPv6. In questa versione il cluster di NSX Manager deve comunque essere distribuito in modalità dual stack (IPv4 e IPv6) e sarà in grado di comunicare con i nodi di trasporto (host ESXi e nodi Edge) tramite IPv4 o IPv6. Quando il nodo di trasporto è configurato con dual stack (IPv4 e IPv6), verrà sempre preferita la comunicazione IPv6.

  • Multi-tenancy disponibile nell'interfaccia utente, nell'API e nel framework degli allarmi: in questa versione è stato esteso il modello di consumo di NSX tramite la multi-tenancy che consente a più utenti in NSX di utilizzare i loro oggetti, visualizzare i loro allarmi e monitorare le loro macchine virtuali con Traceflow. Questo è possibile perché l'amministratore aziendale può segmentare la piattaforma in progetti assegnando spazi diversi a utenti diversi pur mantenendo visibilità e controllo.

  • Miglioramenti dell'integrazione di Antrea e NSX: in NSX 4.1 è possibile creare regole del firewall con oggetti K8s e NSX. È inoltre possibile creare gruppi dinamici in base ai tag NSX e alle etichette K8s. Questo migliora l'usabilità e la funzionalità dell'utilizzo di NSX per gestire i cluster Antrea.

  • Sistema di diagnostica online: fornisce runbook predefiniti che contengono passaggi di debug per risolvere un problema specifico. Questi runbook possono essere richiamati dall'API e attivano passaggi di debug tramite CLI, API e script. Dopo il debug vengono suggerite azioni consigliate per risolvere il problema ed è possibile scaricare gli artefatti generati relativi al debug per ulteriori analisi. Il sistema di diagnostica online consente di automatizzare il debug e semplifica la risoluzione dei problemi. 

Sono state inoltre aggiunte molte altre funzionalità in ogni area del prodotto. Di seguito è disponibile una descrizione dettagliata delle funzionalità aggiunte.

Rete di livello 2

  • Alta disponibilità di ESXi MultiTEP: quando più TEP sono configurati in un hypervisor, NSX monitora lo stato degli indirizzi IP TEP e delle sessioni BFD per eseguire il failover del traffico overlay in un altro uplink. Questa funzionalità offre alta disponibilità in caso di problemi del commutatore fisico, ad esempio quando una porta del commutatore fisico rimane attiva ma l'inoltro non funziona correttamente.

Rete di livello 3

  • Distanza amministrativa BGP: questa versione include il supporto per la modifica dei valori predefiniti della distanza amministrativa di BGP. La distanza amministrativa è un valore arbitrario assegnato a ciascun protocollo di routing e viene utilizzata per la selezione della route. La possibilità di modificare la distanza amministrativa delle route BGP consente di controllare ulteriormente la selezione della route.

  • ASN (Autonomous System Number) BGP per gateway VRF di livello 0 e router adiacente BGP: questa versione include il supporto per la configurazione di un ASN (Autonomous System Number) BGP diverso per ogni gateway VRF di livello 0 e anche per ogni router adiacente BGP. La definizione di un ASN separato per ogni VRF e peer BGP è una funzionalità importante per le topologie con provider di servizi e multi-tenant in cui i clienti finali utilizzano il proprio ASN BGP nelle topologie di rete.

  • Routing tra VRF: questa versione include un modello di perdita delle route e dell'interconnessione VRF più avanzato. Grazie a questa funzionalità, gli utenti possono configurare il routing tra VRF utilizzando workflow più semplici e controlli granulari importando ed esportando dinamicamente le route tra i VRF.

  • Identificatore BGP univoco a livello di sistema autonomo - RFC6286: questa versione include il supporto per ampliare la definizione dell'ID del router BGP, che ora può essere un numero intero diverso da zero, non firmato a 4 ottetti, nonché ridurre il requisito di "univocità" per i peer eBGP, in base alla RFC 6286.

  • Supporto IPv6 per la comunicazione dei piani di controllo e di gestione interni di NSX: questa versione include il supporto per la comunicazione del piano di controllo e del piano di gestione tra i nodi di trasporto e gli NSX Manager tramite IPv6. In questa versione il cluster di NSX Manager deve comunque essere distribuito in modalità dual stack (IPv4 e IPv6) e sarà in grado di comunicare con i nodi di trasporto (host ESXi e nodi Edge) tramite IPv4 o IPv6. Quando il nodo di trasporto è configurato con dual stack (IPv4 e IPv6), verrà sempre preferita la comunicazione IPv6.

DPU-based Acceleration (Accelerazione basata su DPU)

  • UPT V2 è pronto per la produzione per NVIDIA Bluefield-2.

  • Sicurezza

    • NSX Distributed Firewall (firewall L2 e L3 stateful) è disponibile per la distribuzione di produzione con accelerazione DPU.

    • NSX Distributed IDS/IPS (anteprima tecnica)

Piattaforma del nodo Edge

  • Supporto delle impostazioni del nodo Edge nell'API del nodo di trasporto

    • L'API del nodo Edge consente di impostare i seguenti parametri: priorità di riavvio (macchina virtuale del nodo Edge), coalescingScheme e coalescingParams. Grazie a questa funzionalità, i clienti possono ottimizzare le impostazioni relative alle prestazioni e la priorità di riavvio tramite NSX Manager. In questo modo è possibile garantire coerenza per l'esecuzione delle impostazioni degli oggetti NSX tramite NSX Manager.

  • Aggiornamento del sistema operativo del nodo Edge a Ubuntu 20.04

    • Il sistema operativo del nodo Edge è stato aggiornato a Ubuntu 20.04, che offre un supporto hardware migliore per l'Edge bare metal.

  • Piattaforma dell'Edge: aggiornamento della versione dell'hardware

    • Durante l'aggiornamento a NSX 4.1.0, il sistema aggiorna automaticamente le macchine virtuali dell'Edge alla versione hardware più recente supportata che offre prestazioni ottimali.

Network Detection and Response (NDR)

  • Supporto per gli eventi IDPS dal firewall del gateway: a partire da NSX 4.1.0, gli eventi IDPS del firewall del gateway o dell'Edge vengono utilizzati da NDR nelle campagne di correlazione/intrusione.

Rete e sicurezza del container

  • Miglioramenti dell'integrazione di Antrea e NSX: in NSX 4.1.0 è possibile creare regole del firewall con oggetti K8s e NSX. È inoltre possibile creare gruppi dinamici in base ai tag NSX e alle etichette K8s. Questo migliora l'usabilità e la funzionalità dell'utilizzo di NSX per gestire i cluster Antrea. È ora possibile creare criteri del firewall per consentire o bloccare il traffico tra le macchine virtuali e i pod K8s in un'unica regola. È stato inoltre introdotto un nuovo punto di applicazione che include tutti gli endpoint e il valore di "Applica a" corretto viene determinato in base alle destinazioni dei membri del gruppo di origine e di destinazione. I livelli e i criteri di rete K8s creati nel cluster Antrea possono ora essere visualizzati nel set di regole del criterio di NSX. NSX 4.1.0 include inoltre miglioramenti di Traceflow e dell'interfaccia utente che consentono di migliorare la risoluzione dei problemi e la gestione dei criteri di rete K8s fornendo una gestione centralizzata dei criteri di rete K8s tramite NSX.

Installazione e aggiornamento

  • Ripristino rapido in seguito agli errori di aggiornamento: uno dei modi per eseguire rapidamente il ripristino dopo un errore dell'aggiornamento di NSX consiste nell'utilizzare un backup. A volte però non è disponibile un backup utilizzabile ed è necessario un intervento manuale che richiede tempo. In NSX 4.1, viene creato automaticamente un backup di NSX che viene archiviato nell'appliance stessa. Ciò significa che, in caso di errore, il supporto di VMware può ripristinare rapidamente il funzionamento di NSX utilizzando questo backup integrato. 

Operazioni e monitoraggio

  • Sistema di diagnostica online: fornisce runbook predefiniti che contengono i passaggi di debug per risolvere un problema specifico. Questi runbook possono essere richiamati dall'API e attivano passaggi di debug tramite CLI, API e script. Dopo il debug vengono suggerite azioni consigliate per risolvere il problema ed è possibile scaricare gli artefatti generati relativi al debug per ulteriori analisi. Il sistema di diagnostica online consente di automatizzare il debug e semplifica la risoluzione dei problemi.

Per risolvere i problemi del nodo di trasporto dell'host ESXi, sono disponibili i seguenti runbook predefiniti che possono essere richiamati tramite NSX API.

  • Runbook per diagnosticare problemi del tunnel di overlay, problemi di connettività del controller, problemi di blocco delle porte e problemi di prestazioni della pNIC.

VPN

  • Supporto IPv6 per VPN IPSec: gli indirizzi IPv6 possono ora essere utilizzati per la terminazione della VPN IPSec offrendo un meccanismo di tunnel protetto nelle reti IPv6. Tramite la VPN IPv6, NSX può trasportare dati IPv4 e IPv6.

Guest Introspection

  • Supporto per i driver di GI in Windows 11: a partire da NSX 4.1.0, le macchine virtuali che eseguono sistemi operativi Windows 11 sono supportate per NSX Guest Introspection.

Sicurezza della piattaforma

  • Gestione del ciclo di vita degli utenti locali: questa versione consente ai clienti di aggiungere e rimuovere utenti locali dal sistema.

  • Modifica della porta sicura per l'installazione e l'aggiornamento: in questa versione la porta TCP predefinita 8080 per l'installazione e gli aggiornamenti è stata sostituita dalla porta TCP 443 per garantire una maggiore sicurezza della piattaforma.

  • Sostituzione dei certificati interni: questa versione consente ai clienti di sostituire i certificati interni autofirmati con certificati firmati dall'autorità di certificazione.

Multi-tenancy

  • Multi-tenancy nell'interfaccia utente di NSX: NSX 4.1.0 consente l'utilizzo multi-tenancy dall'interfaccia utente per l'amministratore aziendale (provider) e gli utenti del progetto (tenant). 

    • Visualizzazione diversa per utenti diversi: la visualizzazione di NSX disponibile all'accesso degli utenti del progetto (tenant) è diversa da quella degli amministratori aziendali (provider). Gli utenti del progetto non vedono infatti gli altri progetti e le configurazioni del provider.

    • Possibilità di cambiare progetto: nella parte superiore dell'interfaccia di questa versione è disponibile un elenco a discesa che consente di cambiare contesto passando da un progetto a quello successivo in base al controllo RBAC degli utenti. Le configurazioni eseguite all'esterno dei progetti si trovano nel contesto predefinito: questo è il comportamento predefinito per i ruoli configurati all'esterno dei progetti. Gli utenti configurati nel contesto predefinito ( / ) possono visualizzare e configurare tutti i progetti mappati al loro controllo RBAC mentre gli utenti associati a un progetto specifico possono accedere solo ai loro progetti.

  • Schermata che include tutti i progetti: oltre alla possibilità di passare da un progetto all'altro, l'amministratore aziendale può visualizzare una vista consolidata che include tutte le configurazioni nel sistema.

  • Gestione del ciclo di vita del progetto: i progetti sono costrutti facoltativi che hanno lo scopo di offrire una tenancy che può essere configurata dall'amministratore aziendale nell'istanza di NSX.

    • Progetto CRUD: possibilità di creare tali progetti dall'interfaccia utente e visualizzare una vista consolidata di tutti i progetti con i relativi stati/allarmi.

    • Allocazione degli utenti: gli utenti e i gruppi possono essere allocati ai progetti (ad esempio, l'utente "project_admin_1" è l'amministratore del progetto 1, del progetto 2 e del progetto 4).

    • Quote: le quote possono essere allocate ai diversi progetti per limitare in base al tipo il numero di configurazioni disponibili (ad esempio, il progetto 1 può creare 10 segmenti).

    • Condivisione degli oggetti: l'amministratore aziendale può condividere gli oggetti del contesto predefinito (/infra) con tutti i progetti o con progetti specifici (ad esempio, il gruppo "Servizi condivisi" è condiviso con tutti i progetti).

  • Multi-tenancy per operazioni e monitoraggio

    • Registrazione multi-tenant per i registri di sicurezza: è disponibile l'ID registro breve del progetto, che è un'etichetta inserita nei registri per collegarli a un progetto. In questa versione questo ID registro breve verrà applicato ai registri del firewall del gateway e ai registri di Distributed Firewall.

    • Allarmi multi-tenant: estensione del framework degli allarmi per supportare la multi-tenancy. L'amministratore del progetto può ora visualizzare gli allarmi relativi alle sue configurazioni.

    • Traceflow a livello di progetto: l'amministratore del progetto può utilizzare Traceflow per testare la connettività tra i carichi di lavoro. Le configurazioni applicate al suo oggetto dall'esterno del progetto dal provider saranno offuscate.

  • Piattaforma NSX Manager

    • Aggiornare il sistema operativo dell'appliance NSX Manager a Ubuntu 20.04.

      • Il sistema operativo dell'appliance NSX Manager è stato aggiornato a Ubuntu 20.04.

Deprecazioni di funzionalità e API e modifiche dei comportamenti

Annuncio di deprecazione per NSX Load Balancer

VMware intende deprecare il bilanciamento del carico di NSX integrato e consiglia ai clienti di eseguire la migrazione a NSX Advanced Load Balancer (AVI) non appena possibile. VMware NSX Advanced Load Balancer (AVI) fornisce un superset di funzionalità di bilanciamento del carico NSX e VMware consiglia di acquistare VMware NSX Advanced Load Balancer (AVI) Enterprise per sbloccare il bilanciamento del carico di livello aziendale, GSLB, analisi avanzata, servizi in ingresso container, sicurezza delle applicazioni e WAF.

Diffondiamo questa notizia in anticipo per consentire ai clienti esistenti che utilizzano il bilanciamento del carico di NSX integrato di eseguire la migrazione a NSX Advanced Load Balancer (Avi). Il supporto per il bilanciamento del carico di NSX integrato per i clienti che utilizzano NSX-T Data Center 3.x rimarrà disponibile per tutta la durata della serie di versioni NSX-T Data Center 3.x. Il supporto per il bilanciamento del carico di NSX integrato per i clienti che utilizzano NSX 4.x rimarrà disponibile per tutta la durata della serie di versioni NSX 4.x. I dettagli per entrambi i prodotti sono descritti nella matrice del ciclo di vita dei prodotti VMware. Non verrà fornito il supporto per il bilanciamento del carico di NSX integrato successivo all'ultima versione di NSX 4.x.

Ulteriori informazioni:

Annuncio di deprecazione per le API di NSX Manager e le interfacce utente avanzate di NSX

NSX include due metodi per la configurazione della rete logica e della sicurezza: modalità Manager e modalità Criterio. L'API di Manager contiene URI che iniziano con /api, e l'API di Criterio contiene URI che iniziano con /policy/api.

Si tenga presente che VMware intende rimuovere il supporto delle API di NSX Manager e delle interfacce utente avanzate di NSX in una prossima versione di NSX principale o secondaria, che sarà disponibile non prima di un anno dalla data dell'annnuncio originale, ovvero il 16/12/2021. Le API di NSX Manager di cui è pianificata la rimozione sono contrassegnate con "deprecate" nella Guida all'API di NSX Data Center che contiene indicazioni sulle API sostitutive.

Nelle nuove distribuzioni di NSX è consigliabile utilizzare le API di Criterio di NSX e le interfacce utente di Criterio di NSX. Per le distribuzioni che attualmente utilizzano le API di NSX Manager e le interfacce utente avanzate di NSX, fare riferimento a NSX Manager per la pagina di promozione degli oggetti da Manager a Criterio e alla Guida all'API di NSX Data Center per facilitare la transizione.

Deprecazioni delle API e modifiche dei comportamenti

  • Nella Guida di NSX API sono state aggiunte nuove pagine sulla deprecazione o la rimozione delle API per semplificarne l'utilizzo. Queste pagine includono un elenco delle API e dei tipi deprecati, nonché delle API e dei tipi rimossi.

  • API rimosse: Sono state rimosse le API seguenti. Per ulteriori dettagli, fare riferimento alla Guida di NSX API.

API rimossa

Sostituzione

POST /api/v1/intrusion-services/ids-events

 POST /policy/api/v1/infra/settings/firewall/security/intrusion-services/ids-events

POST /api/v1/intrusion-services/ids-summary

POST /policy/api/v1/infra/settings/firewall/security/intrusion-services/ids-summary

POST /api/v1/intrusion-services/affected-vms

POST /policy/api/v1/infra/settings/firewall/security/intrusion-services/affected-vms

POST /api/v1/intrusion-services/affected-users

POST /policy/api/v1/infra/settings/firewall/security/intrusion-services/affected-users

GET /api/v1/intrusion-services/profiles/<profile-id>

GET /policy/api/v1/infra/settings/firewall/security/intrusion-services/profiles/<profile-id>/effective-signatures

  • API deprecate: le seguenti API sono contrassegnate come deprecate. Per ulteriori dettagli, fare riferimento alla Guida di NSX API.

API deprecata

Sostituzione

DELETE /api/v1/aaa/registration-token/<token>

POST /api/v1/aaa/registration-token/delete

GET /api/v1/aaa/registration-token/<token>

POST /api/v1/aaa/registration-token/retrieve

GET /api/v1/node/services/dataplane/l3vpn-pmtu

nessuna

GET /api/v1/node/services/policy

GET /api/v1/node/services/manager

GET /api/v1/node/services/policy/status

GET /api/v1/node/services/manager/status

GET /api/v1/ns-groups/<ns-group-id>/effective-cloud-native-service-instance-members

GET /policy/api/v1/infra/domains/{domain-id}/groups/{group-id}/members/cloud-native-service-instances

GET /api/v1/ns-groups/<ns-group-id>/effective-directory-group-members

GET /policy/api/v1/infra/domains/{domain-id}/groups/{group-id}/members/identity-groups

GET /api/v1/ns-groups/<ns-group-id>/effective-ipset-members

GET /policy/api/v1/infra/domains/{domain-id}/groups/{group-id}/members/segment-ports

GET /policy/api/v1/infra/domains/{domain-id}/groups/{group-id}/members/logical-ports

GET /api/v1/ns-groups/<ns-group-id>/effective-physical-server-members

GET /policy/api/v1/infra/domains/{domain-id}/groups/{group-id}/members/physical-servers

GET /api/v1/ns-groups/<ns-group-id>/effective-transport-node-members

GET /policy/api/v1/infra/domains/{domain-id}/groups/{group-id}/members/transport-nodes

POST /api/v1/batch

nessuna

POST /api/v1/node/services/policy?action=reset-manager-logging-levels

POST /api/v1/node/services/manager?action=reset-manager-logging-levels

POST /api/v1/node/services/policy?action=restart

POST /api/v1/node/services/manager?action=restart

POST /api/v1/node/services/policy?action=start

POST /api/v1/node/services/manager?action=start

POST /api/v1/node/services/policy?action=stop

POST /api/v1/node/services/manager?action=stop

POST /policy/api/v1/infra/realized-state/enforcement-points/<enforcement-point-name>/virtual-machines?action=update_tags

POST /policy/api/v1/infra/realized-state/virtual-machines/{virtual-machine-id}/tags

PUT /api/v1/node/services/dataplane/l3vpn-pmtu

nessuna

PUT /api/v1/node/services/policy

PUT /api/v1/node/services/manager

Compatibilità e requisiti di sistema

Per informazioni sulla compatibilità e i requisiti di sistema, vedere le matrici di interoperabilità dei prodotti VMware e la Guida all'installazione di NSX.

Note sull'aggiornamento per questa versione

Per istruzioni sull'aggiornamento dei componenti di NSX, vedere la guida all'aggiornamento di NSX.

  • NSX 4.1.0 è una nuova versione che offre diverse nuove funzionalità. I clienti che desiderano utilizzare queste funzionalità devono eseguire l'aggiornamento. I clienti che al momento non desiderano utilizzare queste funzionalità devono eseguire l'aggiornamento alla versione più recente disponibile di NSX 3.2 (attualmente la 3.2.2), che continua a essere la versione consigliata da VMware.

  • NSX 4.1.0 non è supportato per i clienti di NSX Cloud distribuiti con carichi di lavoro di AWS/Azure. Non utilizzare NSX 4.1.0 per aggiornare l'ambiente in questo scenario.

È consigliabile che i clienti che eseguono l'aggiornamento a questa versione eseguano lo strumento di valutazione dell'aggiornamento di NSX prima di avviare il processo di aggiornamento. Lo strumento è progettato per garantire il successo dell'operazione verificando l'integrità e la disponibilità degli NSX Manager prima dell'aggiornamento. Lo strumento viene integrato nel workflow di aggiornamento prima di iniziare l'aggiornamento di NSX Manager.

Lingue disponibili

NSX è stato localizzato in più lingue: inglese, tedesco, francese, giapponese, cinese semplificato, coreano, cinese tradizionale, italiano e spagnolo. Tuttavia, poiché la localizzazione di NSX utilizza le impostazioni della lingua del browser, assicurarsi che le impostazioni corrispondano alla lingua desiderata.

Cronologia delle revisioni del documento

Data revisione

Edizione

Modifiche

28 febbraio 2023

1

Edizione iniziale

29 marzo 2023

2

Aggiunti problemi noti 3094405, 3106569, 3113067, 3113073, 3113076, 3113085, 3113093, 3113100, 3118868, 3121377, 3152174, 3152195.

12 maggio 2023

3

Aggiunto il problema noto 3210316.

19 maggio 2023

4

Aggiunto il problema noto 3116294.

1 giugno 2023

5

Aggiunti problemi noti 3186573, 3155845 e 3163020.

20 luglio 2023

6

Aggiunto il problema noto 3108693.

8 settembre 2023

7

Aggiunto l'aggiornamento di NSX Manager alla sezione Novità.

14 dicembre 2023

8

Aggiunto il problema noto 3296976.

10 gennaio 2024

9

Aggiunto il problema noto 3222376.

7 marzo 2024

10

Aggiunto il problema noto 3308657.

Problemi risolti

  • Problema 3053647 risolto: La migrazione completa dell'Edge non è riuscita perché uno degli ESG NSX-V era spento durante la migrazione da NSX for vSphere a NSX-T.

    Le operazioni eseguite in ESG durante la migrazione non riescono.

  • Problema 3048603 risolto: Il traffico DNS basato su UDP crea informazioni relative alla sessione quando arrivano nuove connessioni, causando l'esaurimento della memoria dopo un'esecuzione prolungata.

    L'utilizzo del pool di memoria del percorso dati raggiunge il 100%, superando il valore di soglia pari all'85%.

  • Problema 3106018 risolto: È possibile che si verifichi un arresto anomalo del piano dati del servizio in NSX 4.0.0.1 e 4.0.1.1 se l'Edge riceve un pacchetto di report IGMPv2.

    Il percorso dati verrà riavviato e causerà l'interruzione del traffico.

  • Problema 3073647 risolto: Il falso allarme di DNS "Timeout server upstream server di inoltro" si verifica quando sono configurati almeno due server upstream.

    Il falso allarme crea confusione. I server upstream funzionano correttamente.

  • Problema 3062615 risolto: L'eliminazione del nodo di trasporto Edge può lasciare voci obsolete nelle tabelle interne dell'Edge.

    NSX Manager viene bloccato dopo l'aggiornamento di NSX a causa delle voci obsolete.

  • Problema 3059517 risolto: Perdita di memoria nella programmazione dell'attributo di riepilogo DNS.

    In base alla quantità di traffico, può causare core continui.

  • Problema 3055437 risolto: La proprietà SPF viene abilitata anche quando la zona di trasporto overlay viene rimossa dal commutatore host.

    Le macchine virtuali possono perdere la connettività dopo vMotion.

  • Problema 3046491 risolto: La relazione tra il pool di IP e i segmenti dell'infrastruttura non viene verificata durante la convalida dell'eliminazione e vengono quindi eliminati pool di IP che sono in uso o a cui viene fatto riferimento dai segmenti dell'infrastruttura. In questo modo, gli indirizzi IP vengono deallocati mentre sono in uso.

    Il problema ha un impatto funzionale perché causa la perdita di indirizzi IP mentre sono utilizzati dai segmenti dell'infrastruttura.

  • Problema 3044226 risolto: La revisione della finalità realizzata in RealizationState di DhcpRelayConfig non è stata aggiornata.

    L'interfaccia utente indica lo stato consolidato di dhcp-relay come "IN_PROGRESS" anche se dhcp-relay funziona correttamente.

  • Problema 3056265 risolto: Si verifica un errore di distribuzione del nodo NSX Manager quando viene utilizzato lo stesso nome host usato in precedenza da un nodo NSX Manager scollegato.

    La distribuzione dei nodi NSX Manager viene bloccata se si utilizzano gli stessi nomi host che erano stati scollegati in precedenza.

  • Problema 3024587 risolto: I registri IDPS ricevuti nel server syslog esterno vengono troncati, nonostante l'aumento dell'impostazione remote-host-max-msg-len.

    Gli eventi IDPS possono essere suddivisi in più righe nel server syslog esterno.

  • Problema 3008229 risolto: La CLI del timeout impostato di CCP TN non dispone dell'opzione per utilizzare l'unità oraria.

    Non è possibile utilizzare l'unità oraria nella CLI del timeout impostato di CCP TN.

  • Problema 2863105 risolto: Un gruppo di traffico utilizzato da HCX non può essere eliminato da NSX finché non si eliminano le entità correlate da HCX.

    Non è chiaro come eliminare i gruppi di traffico o la mappa di associazione di HCX.

  • Problema 3091229 risolto: La REST API di appartenenza effettiva per le istanze di servizio native del cloud non funziona per i gruppi che hanno più di due membri CNS.

    La REST API di appartenenza effettiva per il membro CNS non funziona come previsto.

  • Problema 3056889 risolto: Le route statiche nei router distribuiti e/o nei router di servizio di livello 1 non vengono propagate nei nodi di trasporto.

    Il traffico destinato a tali route statiche viene interrotto. Le porte del router logico devono essere configurate prima di configurare le route statiche.

  • Problema 3046448 risolto: Una regola non viene eliminata dagli host ESX quando nell'interfaccia utente di MP viene eseguita l'eliminazione forzata del gruppo NG.

    La regola del firewall con NSgroup eliminato utilizzata nell'origine o nella destinazione continuerà ad applicare il comportamento di sicurezza negli host ESX per tutte le origini o le destinazioni rispettivamente.

  • Problema 3044281 risolto: Nella macchina virtuale dell'Edge è presente un errore di configurazione hardware obsoleto. Questo problema causa un errore di convalida quando si applicano le modifiche della configurazione di Manager.

    La configurazione dell'Edge non può essere modificata tramite l'API PUT o l'interfaccia utente del nodo di trasporto perché è presente un errore obsoleto.

  • Problema 3043150 risolto: I dati del nodo di trasporto obsoleto vengono tralasciati dalla replica LCP di CCP dopo la rimozione del nodo di trasporto da MP.

    Se MP aggiunge un nuovo nodo di trasporto che riutilizza l'IP VTEP precedente con un MAC VTEP diverso, CCP segnala dati errati perché i dati obsoleti del nodo di trasporto non sono stati cancellati.

  • Problema 3037403 risolto: Quando si eseguono query tramite RPC GetLportRealizedState, CCP sovrascrive l'ID VLAN del binding con l'ID VLAN del segmento.

    Quando l'utente esegue query relative ai binding degli indirizzi, può notare che l'ID VLAN è diverso da quello impostato nei binding manuali.

  • Problema 3013563 risolto: La modifica del nome del gruppo in AD influisce sul percorso dati. La regola DFW non viene applicata all'utente che fa parte del gruppo con il nome modificato [dopo la sincronizzazione completa/delta].

    Il percorso dati viene interrotto.

  • Problema 3008229 risolto: La CLI del timeout impostato di CCP TN non dispone dell'opzione per utilizzare l'unità oraria.

    Non è possibile utilizzare l'unità oraria nella CLI del timeout impostato di CCP TN.

  • Problema 2982055 risolto: I membri dei gruppi nidificati non vengono sincronizzati in Intelligence.

    L'API della topologia del flusso del gruppo non mostra i membri dei gruppi nidificati.

  • Problema 2930122 risolto: La migrazione dei dati di CCP da GC/HL a una versione successiva può lasciare record in conflitto che generano falsi allarmi.

    Verranno visualizzati falsi allarmi che segnalano nodi di trasporto disconnessi anche se sono connessi.

  • Problema 2863105 risolto: Un gruppo di traffico utilizzato da HCX non può essere eliminato da NSX finché non si eliminano le entità correlate da HCX.

    Non è chiaro come eliminare i gruppi di traffico o la mappa di associazione di HCX.

  • Problema 3062600 risolto: Quando il file controller-info.xml viene eliminato o è vuoto, il proxy NSX continua a riavviarsi.

    Il proxy NSX viene riavviato continuamente e il problema continua a essere registrato.

  • Problema 3063646 risolto: Nell'appliance unificata si verifica un errore di connessione del registro nestdb-ops-agent.

    I registri verranno compilati più rapidamente.

  • Problema 3065925 risolto: Il RIB VRF definito dall'utente non viene popolato con route ECMP IPv6.

    Mancano informazioni per le route ICMP IPv6.

  • Problema 3071393 risolto: La regola del gateway con profilo di accesso L7 non viene realizzata nell'Edge dopo l'abilitazione o la disabilitazione del gateway.

    La regola del gateway con profilo di accesso L7 non viene realizzata nell'Edge dopo l'abilitazione o la disabilitazione del gateway.

  • Problema 3072735 risolto: Il calcolo effettivo del profilo di rilevamento IP in CCP non ha la precedenza su profili LSP -> profili LS -> profili del gruppo come previsto.

    Nei gruppi DFW sono presenti IP errati.

  • Problema 3073055 risolto: Le regole ereditano accidentalmente lo span dalle definizioni DHCP e vengono inviate agli Edge.

    Le regole vengono realizzate negli Edge quando non dovrebbero trovarsi nell'interfaccia utente.

  • Problema 3073457 risolto: Lo stato dell'endpoint del tunnel remoto non è aggiornato.

    La connettività delle sessioni BGP nell'endpoint del tunnel remoto è intatta e il problema non influisce in alcun modo sul percorso dati, ma nell'interfaccia utente non viene visualizzato lo stato appropriato.

  • Problema 3078357 risolto: La compatibilità della versione LM-LM della federazione deve essere +/-2, ma CCP supporta solo +/-1.

    Due siti di federazione vengono disconnessi se un sito è in esecuzione nella versione V e l'altro è in esecuzione nella versione V+2 o V-2.

  • Problema 3081190 risolto: Il servizio di ricerca utilizza la partizione root in GM per archiviare i dati. Lo spazio del disco della partizione root è insufficiente e genera un allarme.

    GM non funziona correttamente quando lo spazio del disco della partizione root è utilizzato al 100%.

  • Problema 3081664 risolto: La regola DFW viene inviata per errore a EdgeNode. Se una delle regole inviate all'Edge ha parametri errati, è possibile che si verifichi un arresto anomalo perpetuo del piano dati.

    CCP calcola la porta downlink come parte dello span della regola DFW quando si utilizza il commutatore logico/LSP nel campo appliedTo della regola. Di conseguenza, la regola DFW viene inviata per errore a EdgeNode. Se una delle regole inviate all'Edge ha parametri errati, è possibile che si verifichi un arresto anomalo perpetuo del piano dati.

  • Problema 3057573 risolto: L'applicazione del profilo TN al cluster abilitato per vLCM non riesce.

    L'installazione di NSX non riesce nel cluster abilitato per LCM perché la password dell'account di servizio è scaduta.

  • Problema 3046985 risolto: Alcuni servizi firewall del gateway non sono supportati ("MS_RPC_TCP, MS_RPC_UDP, SUN_RPC_TCP, SUN_RPC_UDP, ORACLE_TNS"). Se i servizi sono selezionati, l'operazione di pubblicazione non riesce e viene visualizzato un messaggio di errore.

    I servizi possono essere selezionati nell'interfaccia utente, ma viene visualizzato un messaggio di errore durante la pubblicazione: "Tipo di gateway di livello di applicazione (ALG) non supportato: ORACLE_TNS."

  • Problema 3040934 risolto: Non è possibile pubblicare le modifiche nelle impostazioni del firewall distribuito (DFW) o del firewall del gateway (GWFW). Il pulsante di pubblicazione è disabilitato quando il firewall distribuito (DFW) o il firewall del gateway (GWFW) è disabilitato.

    Non è possibile pubblicare le modifiche della configurazione perché il firewall distribuito (DFW) o il firewall del gateway (GWFW) è disabilitato.

  • Problema 2888207 risolto: Non è possibile reimpostare le credenziali degli utenti locali quando vIDM è abilitato.

    Se vIDM è abilitato, non è possibile modificare le password degli utenti locali.

  • Problema 3068125 risolto: Quando BGP è configurato sull'interfaccia VTI in una distribuzione di Edge attivo-standby, è previsto che BGP sia inattivo nel nodo dell'Edge di standby, ma viene comunque generato un allarme "BGP inattivo" nel nodo dell'Edge di standby.

    Il problema non ha alcun impatto funzionale. Viene comunque generato un falso allarme "BGP inattivo" nel nodo dell'Edge di standby.

  • Problema 3057573 risolto: L'applicazione del profilo TN al cluster abilitato per vLCM non riesce.

    L'installazione di NSX non riesce nel cluster abilitato per LCM perché la password dell'account di servizio è scaduta.

  • Problema 3047608 risolto: Dopo la distribuzione dell'appliance CSM, l'interfaccia utente di CSM non sarà accessibile dopo l'accesso e il servizio nsx-cloud-service di Manager sarà inattivo.

    L'interfaccia utente di CSM Day0 sarà inattiva dopo l'accesso.

  • Problema 3045514 risolto: Non è possibile visualizzare i flussi delle macchine virtuali supportate da NSX in vRNI.

    L'utente non può visualizzare i flussi delle macchine virtuali supportate da NSX in vRNI.

  • Problema 3042523 risolto: I binding individuati in NSX (indirizzi IP) forniti da vm-tools per le porte dei segmenti delle macchine virtuali diventano vuoti mentre Storage vMotion è in corso.

    Tutte le regole DFW basate sugli indirizzi IP individuati da vm-tools come origine non vengono applicate all'IP durante l'esecuzione di Storage vMotion della macchina virtuale.

  • Problema 3038658 risolto: Quando viene eseguito un ripristino in una configurazione con scalabilità hypervisor 1000, si verifica l'arresto anomalo del servizio NSX (proton) a causa di problemi di oom.

    Il processo di ripristino può durare più a lungo perché il servizio NSX viene riavviato.

  • Problema 3027580 risolto: Se i DVPG vengono eliminati nel vCenter Server collegato agli host che fanno parte di un cluster preparato solo per la sicurezza mappato ai segmenti rilevati che fanno parte dei gruppi dell'inventario, i segmenti rilevati non verranno mai eliminati.

    Questo non ha alcun impatto sul funzionamento. Nell'interfaccia utente di NSX Manager vengono visualizzati oggetti obsoleti.

  • Problema 3027473 risolto: Il feedback dell'interfaccia utente non viene visualizzato quando si esegue la migrazione di più di 1.000 regole DFW da NSX for vSphere a NSX-T Data Center, ma le sezioni sono suddivise in sezioni di 1.000 regole al massimo.

    Il feedback dell'interfaccia utente non viene visualizzato.

  • Problema 3025367 risolto: Se il profilo uplink dispone di quattro uplink attivi e nella configurazione di TN vengono forniti solo due uplink per la mappatura di uplink di VDS, sul lato host verranno creati quattro vmk.

    Nessun impatto sulla funzionalità.

  • Problema 3024658 risolto: Quando si elaborano pacchetti con traffico SMB, il processo IDS/IPS di NSX genera un utilizzo della CPU e una latenza elevati.

    In alcuni casi, si verifica l'arresto anomalo del processo IDS/IPS di NSX a causa di un errore di memoria insufficiente durante l'elaborazione del traffico SMB.

  • Problema 3024136 risolto: Le modifiche della configurazione BGP VRF non vengono sempre applicate.

    Le modifiche apportate alla configurazione di BGP in un VRF non vengono sempre applicate.

  • Problema 3024129 risolto: Avvisi di Global Manager attivati di frequente.

    Gli allarmi vengono attivati non appena uno viene risolto.

  • Problema 3019893 risolto: Quando la persistenza del bilanciamento del carico viene disabilitata, si verifica l'arresto anomalo di NGINX.

    Non è possibile stabilire una nuova connessione a causa di un deadlock.

  • Problema 2963524 risolto: Le connessioni UDP non vengono eliminate in base al loro timeout di scadenza.

    Il feedback dell'interfaccia utente non viene visualizzato.

  • Problema 2947840 risolto: La vista della topologia di rete non mostra tutti i componenti di rete nell'interfaccia utente.

    Non è possibile visualizzare la topologia di rete completa.

  • Problema 2928725 risolto: I download della firma IDPS non funzionano con il proxy tramite una porta specifica.

    La chiamata di download della firma tramite proxy non è autorizzata a raggiungere il server NTICS.

  • Problema 3034373 risolto: Il profilo IPFIX DFW viene bloccato durante l'eliminazione dopo l'aggiornamento da una versione precedente alla 3.2.0 alla versione 3.2.x o 4.0.x.

    Non è possibile eliminare i profili IPFIX DFW.

  • Problema 3043151 risolto: La classificazione L7 dei flussi del firewall potrebbe non essere disponibile per un breve periodo quando nel sistema è presente un traffico elevato che deve determinare AppId

    È possibile che le regole L7 non vengano soddisfatte negli host con traffico elevato.

  • Problema 3039159 risolto: il vMotion delle macchine virtuali con interfaccia in modalità UPT (Uniform Passthrough) e con un numero elevato di flussi potrebbe causare il PSOD dell'host.

    Il PSOD dell'host influisce sul traffico durante il vMotion delle macchine virtuali basate su UPT con un numero elevato di flussi.

  • Problema 3047608 risolto: Dopo la distribuzione dell'appliance CSM, l'interfaccia utente di CSM non sarà accessibile dopo l'accesso e il servizio nsx-cloud-service di Manager sarà inattivo.

    L'interfaccia utente di CSM Day0 sarà inattiva dopo l'accesso.

  • Problema 3027580 risolto: Se i DVPG vengono eliminati nel vCenter Server collegato agli host che fanno parte di un cluster preparato solo per la sicurezza mappato ai segmenti rilevati che fanno parte dei gruppi dell'inventario, i segmenti rilevati non verranno mai eliminati.

    Questo non ha alcun impatto sul funzionamento. Nell'interfaccia utente di NSX Manager vengono visualizzati oggetti obsoleti.

  • Problema 3042382 risolto: La sessione deve essere nuovamente cercata quando il pacchetto corrisponde alla regola non SNAT.

    Il traffico corrispondente alla regola non SNAT è bloccato.

  • Problema 3044704 risolto: NSX Manager supporta solo il proxy HTTP senza SSL-BUMP anche se la pagina di configurazione accetta lo schema e il certificato HTTPS.

    Quando si configura il proxy in Sistema-> Impostazioni generali -> Server proxy Internet, è necessario fornire dettagli per lo schema (HTTP o HTTPS), l'host, la porta e così via.

    Il termine schema indica qui il tipo di connessione che si desidera stabilire tra NSX Manager e il server proxy. Non indica il tipo di proxy. In genere il proxy HTTPS utilizza lo schema HTTPS. Ma un proxy come Squid, configurato con http_port + SSL, stabilisce anche la connessione HTTPS tra NSX Manger e il server proxy. Tuttavia, i servizi in NSX Manager presuppongono sempre che il proxy sia esposto con la porta http. Il certificato fornito non verrà quindi mai utilizzato in NSX Manager.

    Quando si sceglie lo schema HTTPS e si fornisce il certificato, nel sistema viene visualizzato il messaggio di errore "Il certificato xx non è un certificato valido per xx" per un proxy HTTPS nella pagina di configurazione.

    Se si tenta di utilizzare un proxy Squid con http_port + bump SSL, non verrà visualizzato alcun messaggio di errore ma i servizi di NSX Manager non riusciranno a inviare la richiesta ai server esterni. Nel registro potrebbe essere presente un messaggio di errore che indica che non è possibile trovare la catena di certificati.

  • Problema 3025104 risolto: L'host passa allo stato "Non riuscito" quando si esegue il ripristino utilizzando un IP diverso ma lo stesso nome di dominio completo.

    Quando il ripristino viene eseguito utilizzando un IP diverso dei nodi di NSX Manager ma lo stesso nome di dominio completo, gli host non sono in grado di connettersi ai nodi di NSX Manager.

  • Problema 2888207 risolto: Non è possibile reimpostare le credenziali degli utenti locali quando vIDM è abilitato.

    Se vIDM è abilitato, non è possibile modificare le password degli utenti locali.

Problemi noti

  • Problema 3308657: Quando si creano sezioni di firewall con un numero molto elevato di regole, la risposta dell'API di creazione/eliminazione delle regole richiede più di 30 minuti.

    Questa lentezza causa 409/500 errori o rallenta l'attivazione delle esecuzioni dell'API per i POD.

    Soluzione: ridurre il numero di regole in una sezione.

  • Problema 3222376: La funzionalità "Controlla stato" di NSX nell'interfaccia utente di configurazione di LDAP segnala un errore durante la connessione a Windows Server 2012/Active Directory. Il problema si verifica perché Windows 2012 supporta solo i pacchetti di crittografia TLS più deboli che non sono più supportati da NSX per motivi di sicurezza.

    Anche se viene visualizzato un messaggio di errore, l'autenticazione LDAP su SSL funziona perché il set di pacchetti di crittografia utilizzati dal codice di autenticazione LDAP è diverso dal set utilizzato dal collegamento "Controlla stato".

    Soluzione: Per informazioni dettagliate, vedere l'articolo 92869 della Knowledge Base.

  • Problema 3296976: Il firewall del gateway può consentire l'utilizzo di ID app di livello 7 non supportati come parte dei profili di accesso di contesto o L7.

    Fare riferimento alla pagina seguente, in cui sono elencati gli ID app supportati per la versione di NSX - https://docs.vmware.com/it/NSX-Application-IDs/index.html.

    Soluzione: nessuna.

  • Problema 3108693: L'amministratore del progetto non sarà in grado di configurare la funzionalità dns-forwarder dall'interfaccia utente.

    Se si è connessi come "project-admin", le T1 nell'ambito del progetto non vengono elencate nel menu a discesa nella pagina dns-forwarder. Di conseguenza, l'amministratore del progetto non è in grado di configurare la funzionalità dns-forwarder dall'interfaccia utente.

    Soluzione:

    1. L'amministratore del progetto può eseguire la stessa funzionalità dall'API.

    2. L'amministratore aziendale può creare servizi DNS nell'ambito del progetto.

  • Problema 3186573: Perdita di dati in CorfuDB.

    Perdita improvvisa di alcune configurazioni. Non è possibile creare/aggiornare alcune configurazioni.

    Soluzione: per informazioni dettagliate, vedere l'articolo 92039 della Knowledge Base.

  • Problema 3163020: Quando le maiuscole e le minuscole del nome di dominio completo nei pacchetti DNS sono diverse da quelle presenti nei nomi di dominio configurati nei profili L7 delle regole dei nomi di dominio completi, le azioni delle regole dei nomi di dominio completi non vengono applicate correttamente.

    Le azioni delle regole dei nomi di dominio completi non vengono applicate correttamente. Il filtro dei nomi di dominio completi di DFW non funziona correttamente.

    Soluzione: configurare il nome di dominio completo nel profilo del contesto L7 in modo che corrisponda al nome di dominio nel pacchetto DNS.

  • Problema 3155845: PSOD durante vMotion quando è configurato il filtro del nome di dominio completo.

    L'host ESXi verrà riavviato.

    Soluzione: rimuovere la configurazione del nome di dominio completo.

  • Problema 3116294: La regola con gruppo nidificato non funziona come previsto negli host.

    Traffico non consentito o ignorato correttamente.

    Soluzione: vedere l'articolo 91421 della Knowledge Base.

  • Problema 3210316: la configurazione di vIDM viene cancellata se (1) Manager è IPv4/IPv6 dual stack e (2) non è configurato alcun indirizzo VIP e (3) si immette un indirizzo IP anziché un nome di dominio completo per il campo "NSX Appliance" nella configurazione di vIDM.

    Non sarà possibile accedere tramite vIDM finché la configurazione di vIDM non verrà riconfigurata.

    Soluzione: utilizzare il nome di dominio completo per il campo "NSX Appliance".

  • Problema 3152195: Le regole DFW con profili di contesto con nome di dominio completo di tipo .*XYZ.com non vengono applicate.

    L'applicazione della regola DFW non funziona come previsto in questo scenario specifico.

    Soluzione: nessuna.

  • Problema 3152174: La preparazione dell'host con VDS non riesce e viene visualizzato il messaggio di errore: L'host {UUID} non viene aggiunto a VDS.

    In vCenter, se le reti sono nidificate all'interno di cartelle, le migrazioni da NVDS a CVDS o da NSX-V a NSX-T potrebbero non riuscire se la migrazione viene eseguita verso CVDS in NSX-T.

    Soluzione: La prima rete dell'host è la prima rete visibile nel campo della rete nella pagina MOB vCenter https://<VC-IP>/mob?moid=host-moref

    • Prima della versione 3.2.1: La prima rete dell'host, come indicato sopra, e il VDS interessato devono trovarsi direttamente nella stessa cartella. La cartella può essere DataCenter o una cartella di rete all'interno di DataCenter.

    • Dalla versione 3.2.1 e 4.0.0 in poi: La prima rete dell'host, come indicato sopra, deve trovarsi direttamente all'interno di una cartella e il VDS desiderato può trovarsi direttamente all'interno della stessa cartella o può essere annidato all'interno della stessa cartella. La cartella può essere DataCenter o una cartella di rete all'interno di DataCenter.

  • Problema 3118868: Filtri vNIC errati o obsoleti programmati nella pNIC quando i filtri di overlay vengono programmati circa nello stesso momento in cui una pNIC viene abilitata.

    I filtri vNIC programmati nella pNIC possono essere obsoleti, errati o mancanti quando i filtri di overlay vengono programmati circa nello stesso momento in cui una pNIC viene abilitata causando un possibile peggioramento delle prestazioni.

    Soluzione: nessuna.

  • Problema 3113100: L'indirizzo IP non viene realizzato per alcune macchine virtuali nei gruppi di sicurezza dinamici a causa di una voce VIF obsoleta.

    Se un cluster è stato inizialmente configurato per Rete e sicurezza utilizzando Avvio rapido ed è stato quindi disinstallato e reinstallato esclusivamente per motivi di sicurezza, è possibile che le regole DFW non funzionino come previsto. Ciò è dovuto al fatto che la TZ automatica generata per Rete e sicurezza è ancora presente e deve essere rimossa affinché le regole DFW funzionino correttamente.

    Soluzione: Eliminare la TZ generata automaticamente dall’avvio rapido di Rete e sicurezza che fa riferimento allo stesso DVS utilizzato da Solo sicurezza.

  • Problema 3113093: I nuovi host aggiunti non sono configurati per la sicurezza.

    Dopo l'installazione della sicurezza, quando un nuovo host viene aggiunto a un cluster e connesso al commutatore virtuale distribuito, non attiva automaticamente l'installazione di NSX in tale host.

    Soluzione: Apportare eventuali aggiornamenti al VDS esistente in VC (o) aggiungere un nuovo VDS in VC e aggiungere tutti gli host nel cluster al VDS. Questa operazione aggiornerà automaticamente il TNP e il TNP verrà riapplicato in TNC. Quando il TNC viene aggiornato, il nuovo host aggiunto avrà la configurazione più recente del TNP.

  • Problema 3113085: Le regole DFW non vengono applicate alla macchina virtuale durante vMotion.

    Quando una macchina virtuale protetta da DFW viene spostata tramite vMotion da un host a un altro in una distribuzione dell'installazione di sola sicurezza, è possibile che le regole DFW non vengano applicate all'host ESX causando una classificazione non corretta della regola.

    Soluzione: Connettere la macchina virtuale a un'altra rete, quindi riconnetterla al DVPortgroup di destinazione.

  • Problema 3113076: I core dump non vengono generati quando si verificano arresti anomali del daemon FRR.

    Quando si verificano arresti anomali del daemon FRR, i core dump non vengono generati dal sistema nella directory /var/dump. Questo può causare il flap di BGP.

    Soluzione: Abilitare il dump principale per i daemon FRR, attivare il crash e ottenere il dump principale da /var/dump.

    Per abilitare il dump principale, utilizzare il comando seguente nel nodo Edge, che deve essere eseguito come utente root nel nodo Edge.

    prlimit --pid <pid del daemon FRR> --core=500000000:500000000

    Per verificare se il dump principale è abilitato per il daemon FRR, utilizzare il comando seguente e controllare i limiti SOFT e HARD per la risorsa CORE. Questi limiti devono essere 500000000 byte o 500 MB.

    prlimit --pid <pid del daemon FRR>

  • Problema 3113073: Le regole DFW non vengono applicate per un po' di tempo dopo l'abilitazione della modalità di blocco.

    L'abilitazione della modalità di blocco in un nodo di trasporto può causare un ritardo nell'applicazione delle regole DFW. Questo è dovuto al fatto che quando la modalità di blocco è abilitata in un nodo di trasporto, la macchina virtuale associata può essere rimossa dall'inventario di NSX e quindi ricreata. Durante questo intervallo di tempo, è possibile che le regole DFW non vengano applicate alle macchine virtuali associate a tale host ESXi.

    Soluzione: Aggiungere manualmente 'da-user' nell'elenco di eccezioni prima di passare ESX in modalità di blocco.

  • Problema 3113067: Non è possibile connettersi a NSX-T Manager dopo vMotion.

    Quando si aggiorna NSX da una versione precedente a NSX 3.2.1, le macchine virtuali di NSX Manager non vengono aggiunte automaticamente all'elenco di esclusione del firewall. Di conseguenza, tutte le regole DFW vengono applicate alle macchine virtuali di Manager e questo può causare problemi di connettività di rete.

    Questo problema non si verifica nelle nuove distribuzioni di NSX 3.2.2 o versioni successive. Tuttavia, se si esegue l'aggiornamento dalla versione NSX 3.2.1 o precedenti a qualsiasi versione di destinazione fino alla NSX 4.1.0 inclusa, è possibile che si verifichi questo problema.

    Soluzione: Contattare l'assistenza VMware.

  • Problema 3106569: Le prestazioni non raggiungono i livelli previsti con la modalità server route EVPN.

    I filtri vNIC programmati nella pNIC possono essere obsoleti, errati o mancanti quando i filtri di overlay vengono programmati per la pNIC in una situazione di raggruppamento causando un possibile peggioramento delle prestazioni.

    Soluzione: nessuna.

  • Problema 3094405: Filtri vNIC errati o obsoleti programmati per la pNIC quando sono configurate reti di overlay.

    I filtri di overlay della vNIC vengono aggiornati in un ordine specifico. Quando gli aggiornamenti si verificano in rapida successione, viene mantenuto solo il primo aggiornamento mentre gli aggiornamenti successivi vengono eliminati. Questo causa la programmazione non corretta del filtro e un possibile peggiormento delle prestazioni.

    Soluzione: nessuna.

  • Problema 3121377: PSOD in ESX.

    Impatto sul traffico del nodo di trasporto inattivo.

    Soluzione:

    1. Modificare la configurazione del carico di lavoro per evitare l'invio di traffico al router first hop per i peer sullo stesso segmento.

    2. Accettare i reindirizzamenti ICMP6 in modo normale dal router first hop.

  • Problema 3098639: L'aggiornamento di NSX Manager non riesce perché il servizio di autenticazione/proxy inverso non passa alla modalità di manutenzione durante l'aggiornamento.

    Errore di aggiornamento di nsx-manager.

    Soluzione: per informazioni dettagliate, vedere l'articolo 91120 della Knowledge Base.

  • Problema 3114329: Intel QAT non è disponibile dopo l'installazione bare-metal NSX Edge.

    La tecnologia Intel QuickAssist (QAT) è una tecnologia di accelerazione hardware progettata per scaricare gli algoritmi crittografici e di compressione/decompressione ad alta intensità di calcolo dalla CPU all'hardware dedicato. A causa di questo problema, non è possibile utilizzare Intel QAT per migliorare le prestazioni della velocità effettiva del servizio VPN con bare-metal NSX Edge.

    Soluzione: nessuna.

  • Problema 3106950: Dopo aver raggiunto la quota DFW, la creazione di un nuovo VPC nell'ambito del progetto non riesce.

    Non è possibile creare un VPC in un progetto in cui è stata raggiunta la quota DFW.

    Soluzione: nessuna.

  • Problema 3094463: È possibile creare una regola del firewall stateless con FTP del servizio ALG tramite l'API MP obsoleta. Questa operazione non è supportata tramite l'API del criterio.

    Se sono presenti regole del firewall problematiche in MP, non è possibile eseguire la migrazione da MP a criterio.

    Soluzione: la regola del firewall problematica deve essere aggiornata in modo che sia stateful o non deve disporre di FTP del servizio ALG.

  • Problema 3083358: Al riavvio il controller impiega molto tempo per collegarsi al cluster.

    Dopo il riavvio del controller, per le nuove configurazioni create in NSX Manager potrebbe verificarsi un ritardo di realizzazione perché l'avvio del controller può richiedere tempo.

    Soluzione: eliminare i gruppi di IP dannosi ridondanti ed eseguire il riavvio.

  • Problema 3106317: Quando si modifica l'indirizzo MAC di una vNIC nel guest, è possibile che le modifiche non vengano riportate nei filtri programmati per la pNIC.

    È possibile che si verifichi un peggioramento delle prestazioni.

    Soluzione: disabilitare e quindi riabilitare l'interfaccia nel guest.

  • Problema 3047727: CCP non ha pubblicato RouteMapMsg aggiornato.

    Le route non destinate alla pubblicazione vengono pubblicate.

    Soluzione: nessuna.

  • Problema 2792485: Viene visualizzato l'IP di NSX Manager anziché il nome di dominio completo per il Manager installato in vCenter.

    L'interfaccia utente di NSX-T integrata in vCenter mostra l'IP di NSX Manager anziché il nome di dominio completo per il Manager installato.

    Soluzione: nessuna.

  • Problema 3092154: La NIC corrente non supporta l'intestazione dell'estensione di routing IPv6.

    Qualsiasi traffico IPv6 con intestazioni dell'estensione di routing verrà eliminato da SmartNIC.

    Soluzione: nessuna.

  • Problema 3079932: È possibile che la modifica della MTU non riesca per i flussi TCP con offload su larga scala nelle interfacce UPT.

    Nei flussi TCP con offload su larga scala nelle interfacce UPT, a volte la modifica della MTU può non riuscire.

    Soluzione:

    1. non modificare la MTU durante il traffico.

    2. Oppure disabilitare l'offload dell'hardware e quindi eseguire la modifica della MTU.

  • Problema 3077422: Le macchine virtuali, nonché le porte e le interfacce supportate da SmartNIC non vengono elencate in LTA perché LTA non è supportato nelle macchine virtuali e nelle porte supportate da SmartNIC.

    In determinate macchine virtuali non è possibile creare LTA.

    Soluzione: nessuna.

  • Problema 3076771: Il comando "get physical-ports <physical-port-name> stats verbose" visualizza il valore 0 per le statistiche per coda.

    Quando nel debug vengono utilizzate le statistiche della porta dettagliate, vengono visualizzati valori zero imprevisti.

    Soluzione: se disponibile, "get physical-ports <physical-port-name> xstats" visualizza le statistiche per coda per le porte fisiche.

  • Problema 3069003: È presente un numero eccessivo di operazioni LDAP nel servizio di directory LDAP del cliente quando si utilizzano gruppi LDAP nidificati.

    Nei casi in cui vengono utilizzati gruppi LDAP nidificati, si verifica un carico elevato nel servizio di directory LDAP.

    Soluzione: per vROPS precedente alla versione 8.6, utilizzare l'utente locale "admin" anziché un utente LDAP.

  • Problema 3068100: La perdita di route è supportata solo in caso di routing simmetrico. La perdita di route asimmetrica tra i VRF può causare un blackhole del traffico.

    Se le route VRF sono asimmetriche tra i nodi Edge nel cluster, tali route asimmetriche non vengono sincronizzate nel cluster Edge, anche se è abilitato il routing tra SR. Questa condizione può creare un blackhole per il traffico da sud a nord.

    Soluzione: assicurarsi che le route vengano propagate simmetricamente a tutti i nodi Edge nel cluster. In questo esempio, i prefissi 2.1.4.0/24 e 2.1.5.0/24 devono essere propagati a entrambi gli Edge e1 ed e2.

  • Problema 2855860: Quando il file system di un Edge passa alla modalità di sola lettura, viene interrotto indefinitamente l'inoltro del percorso dati dell'Edge.

    Si verifica la perdita di traffico. È possibile che nella console della macchina virtuale dell'Edge venga segnalato che il file system è passato alla modalità di sola lettura.

    Soluzione: nessuna.

  • Problemi 3046183 e 3047028: Dopo l'attivazione o la disattivazione di una delle funzionalità di NSX ospitate in NSX Application Platform, lo stato della distribuzione delle altre funzionalità ospitate in NSX diventa In Progress. Le funzionalità di NSX interessate sono NSX Network Detection and Response, NSX Malware Prevention e NSX Intelligence.

    Dopo aver distribuito NSX Application Platform, l'attivazione o la disattivazione della funzionalità NSX Network Detection and Response causa l'impostazione dello stato della distribuzione delle funzionalità Prevenzione malware NSX e NSX Intelligence su In Progress. Analogamente, l'attivazione e la disattivazione della funzionalità NSX Malware Prevention causa l'impostazione dello stato della funzionalità NSX Network Detection and Response su In Progress. Se la funzionalità NSX Intelligence è attivata e si attiva NSX Malware Prevention, lo stato della funzionalità NSX Intelligence viene impostato su Down e Partially up.

    Soluzione: nessuna. Il sistema esegue il ripristino autonomamente.

  • Problema 3041672: Per le modalità di migrazione di sola configurazione e DFW, una volta completate tutte le fasi della migrazione, è possibile richiamare le API di pre-migrazione e post-migrazione per spostare i carichi di lavoro. Se si modificano le credenziali di NSX for vSphere, vCenter Server o NSX dopo che le fasi della migrazione sono state completate correttamente, la chiamata delle API di pre-migrazione e post-migrazione non riesce.

    Non sarà possibile spostare i carichi di lavoro perché le chiamate delle API dell'infrastruttura di pre-migrazione, post-migrazione e finalizzazione non riusciranno.

    Soluzione: eseguire i passaggi seguenti.

    1. Riavviare il coordinatore della migrazione.

    2. Nell'interfaccia utente della migrazione, utilizzando la stessa modalità di migrazione utilizzata prima del riavvio, fornire tutti i dettagli di autenticazione. Questa operazione dovrebbe sincronizzare nuovamente lo stato di avanzamento della migrazione.

    3. Eseguire le API dell'infrastruttura pre-migrazione, post-migrazione e finalizzazione.

  • Problema 3043600: La distribuzione di NSX Application Platform non riesce quando si utilizza un repository Harbor privato (non predefinito) con un certificato autofirmato da un'autorità di certificazione (CA) meno nota.

    Se si tenta di distribuire NSX Application Platform utilizzando un repository Harbor privato (non predefinito) con un certificato autofirmato da un'autorità di certificazione meno nota, la distribuzione non riesce perché il processo di distribuzione non è in grado di ottenere i grafici Helm e le immagini Docker di NSX Application Platform. Poiché la piattaforma NSX Application Platform non viene distribuita correttamente, non è possibile attivare alcuna funzionalità di NSX, ad esempio NSX Intelligence, ospitata dalla piattaforma.

    Soluzione: utilizzare un'autorità di certificazione attendibile nota per firmare il certificato utilizzato per il server Harbor privato.

  • Problema 2491800: Gli attributi del certificato della porta del canale di replica asincrona non vengono controllati periodicamente per verificare la scadenza o la revoca.

    È quindi possibile che venga utilizzato un certificato scaduto o revocato per una connessione esistente.

    Soluzione: Qualsiasi riconnessione utilizzerà i nuovi certificati (se presenti) o genererà un errore perché il vecchio certificato è scaduto o revocato. Per attivare la riconnessione, è sufficiente riavviare Appliance Proxy Hub (APH) nel nodo di gestione.

  • Problema 2994066: Non è possibile creare vmknic di mirroring in ESXi 8.0.0.0 e NSX 4.0.1 e versioni successive.

    Non è possibile abilitare L3SPAN con stack di mirroring perché non è stato possibile creare vmknic di mirroring.

    Soluzione:

    1. Dal prompt della CLI di ESXi, creare uno stack di mirroring in ESXi.

    2. Da vSphere Web Client, creare un'istanza di vmknic.

    3. Eseguire il comando seguente:

    esxcli network ip netstack add -N mirror

  • Problema 3007396: Se per il nodo remoto è impostata la modalità di timeout LACP SLOW, è possibile che si verifichi un rallentamento del traffico di circa 60-90 secondi dopo la disattivazione di uno dei link LAG tramite il comando della CLI "esxcli network nic down -n vmnicX"

    Rallentamento del traffico di circa 60-90 secondi dopo la disattivazione di uno dei link LAG tramite il comando della CLI "esxcli network nic down -n vmnicX".

    Il problema si verifica solo se il timeout LACP del nodo remoto è impostato sulla modalità SLOW.

    Soluzione: impostare il timeout LACP del commutatore esterno su FAST.

  • Problema 3013751: L'avanzamento dell'installazione o della disinstallazione di NSX non viene visualizzato automaticamente nella pagina Infrastruttura.

    L'avanzamento è visibile dopo l'aggiornamento manuale della pagina Infrastruttura.

    Soluzione: aggiornare manualmente la pagina Infrastruttura.

  • Problema 3018596: La funzione virtuale (VF) viene rilasciata se si imposta la MTU della NIC virtuale (vNIC) della macchina virtuale nella macchina virtuale guest in modo che sia maggiore della MTU della NIC fisica.

    Quando la MTU della vNIC viene modificata in modo che sia maggiore della MTU della pNIC, la macchina virtuale non sarà in grado di acquisire una VF. Pertanto, la macchina virtuale non sarà in modalità UPT. Sarà in modalità "emu vmnic".

    Soluzione:

    1. Modificare le dimensioni della MTU in DVS da 1600 a 9100.

    2. La VF viene assegnata di nuovo alla vNIC della macchina virtuale.

  • Problema 3003762: La disinstallazione del servizio Prevenzione malware NSX non riesce se non si eliminano le regole del servizio Prevenzione malware dal criterio e non viene visualizzato alcun messaggio di errore che indica la mancata riuscita della disinstallazione perché le regole sono ancora presenti nel criterio.

    In questo scenario la disinstallazione del servizio Prevenzione malware NSX non riesce.

    Soluzione: eliminare le regole e riprovare la disinstallazione.

  • Problema 3003919: Le regole DFW che corrispondono a CNAME con azioni diverse rispetto alla regola DFW che corrisponde al nome di dominio originale causeranno l'imposizione della regola in modo incoerente.

    Se un'applicazione o un utente accedono a CNAME anziché al nome di DOMINIO originale, vengono ignorati o eliminati erroneamente dalle regole DFW.

    Soluzione: eseguire uno dei passaggi seguenti.

    • Configurare le regole DFW solo per il nome di dominio originale, non per il CNAME.

    • Configurare le regole con il nome di dominio e CNAME con la stessa azione.

  • Problema 3014499: Se si spegne l'Edge che gestisce il traffico tra siti, alcuni flussi vengono interrotti.

    Alcuni flussi del traffico tra siti smettono di funzionare.

    Soluzione: accendere l'Edge spento.

  • Problema 3014978: Se si passa il puntatore del mouse sul flag Rete e sicurezza nella pagina Infrastruttura, vengono visualizzate informazioni errate indipendentemente dalla rete selezionata.

    Nessun impatto.

    Soluzione: nessuna.

  • Problema 3014979: L'avanzamento dell'installazione o della disinstallazione di NSX non viene visualizzato automaticamente nella pagina Infrastruttura.

    Nessun impatto. Aggiornare manualmente la pagina per visualizzare lo stato di avanzamento.

    Soluzione: aggiornare manualmente la pagina Infrastruttura.

  • Problema 3017885: L'analisi del nome di dominio completo può supportare solo un cluster secondario in modalità Attivo/Attivo stateful.

    Non abilitare la funzionalità se la modalità Attivo/Attivo stateful ha più di un cluster secondario.

    Soluzione: distribuire un solo cluster secondario.

  • Problema 3010038: In un LAG a due porte che supporta le macchine virtuali UPT (Uniform Passthrough) dell'Edge, se la connessione fisica a una delle porte LAG viene disconnessa, l'uplink sarà inattivo, ma le funzioni virtuali (VF) utilizzate da tali macchine virtuali UPT continueranno a essere attive perché ottengono la connettività tramite l'altra interfaccia del LAG.

    Nessun impatto.

    Soluzione: nessuna.

  • Problema 3009907: I VIB di NSX non vengono eliminati dall'host SmartNIC se l'host era disconnesso durante l'operazione "Rimuovi NSX" nel cluster.

    Il problema non ha alcun impatto funzionale.

    Soluzione: in vCenter Server, passare all'interfaccia utente di vLCM e correggere il cluster.

  • Problema 2490064: Il tentativo di disabilitare VMware Identity Manager con "LB esterno" attivato non funziona.

    Dopo aver abilitato l'integrazione di VMware Identity Manager in NSX con "LB esterno", se si tenta di disabilitare l'integrazione disattivando "LB esterno", dopo circa un minuto viene visualizzata di nuovo la configurazione iniziale che sovrascrive le modifiche locali.

    Soluzione: quando si tenta di disabilitare vIDM, non disattivare il flag LB esterno. Disattivare solo l'integrazione di vIDM. In questo modo, la configurazione verrà salvata nel database e sincronizzata con gli altri nodi.

  • Problema 2558576: Le versioni di Global Manager e Local Manager di una definizione di profilo globale possono essere diverse e avere un comportamento sconosciuto in Local Manager.

    I profili DNS, di sessione o flood globali creati in Global Manager non possono essere applicati a un gruppo locale dall'interfaccia utente, ma possono essere applicati dall'API. Di conseguenza, un utente dell'API può accidentalmente creare mappe di binding del profilo e modificare entità globali in Local Manager.

    Soluzione: utilizzare l'interfaccia utente per configurare il sistema.

  • Problema 2355113: Le macchine virtuali del carico di lavoro che eseguono RedHat e CentOS in istanze di rete accelerata di Azure non sono supportate.

    In Azure, quando la rete accelerata è abilitata in sistemi operativi basati su RedHat o CentOS e con NSX Agent installato, l'interfaccia Ethernet non ottiene un indirizzo IP.

    Soluzione: disabilitare la rete accelerata per i sistemi operativi basati su RedHat e CentOS.

  • Problema 2574281: Il criterio consentirà al massimo 500 sessioni VPN.

    NSX richiede il supporto di 512 sessioni VPN per Edge nel fattore di forma di grandi dimensioni. Poiché il criterio esegue il plumbing automatico dei criteri di sicurezza, consente tuttavia un massimo di 500 sessioni VPN.

    Durante la configurazione della 501esima sessione VPN nel livello 0, viene visualizzato il messaggio di errore seguente:

    {'httpStatus': 'BAD_REQUEST', 'error_code': 500230, 'module_name': 'Policy', 'error_message': 'GatewayPolicy, percorso=[/infra/domains/default/gateway-policies/VPN_SYSTEM_GATEWAY_POLICY] presente più di 1.000 regole consentite per percorso Gateway=[/infra/tier-0s/inc_1_tier_0_1].'}

    Soluzione: utilizzare le API del piano di gestione per creare sessioni VPN aggiuntive.

  • Problema 2684574: Se l'Edge include più di 6.000 route per Database e Route, si verifica il timeout dell'API del criterio.

    Queste API dei criteri per il database OSPF e le route OSPF restituiscono un errore se l'Edge include più di 6.000 route: /tier-0s/<tier-0s-id>/locale-services/<locale-service-id>/ospf/routes /tier-0s/<tier-0s-id>/locale-services/<locale-service-id>/ospf/routes?format=csv /tier-0s/<tier-0s-id>/locale-services/<locale-service-id>/ospf/database /tier-0s/<tier-0s-id>/locale-services/<locale-service-id>/ospf/database?format=csv Se l'Edge include più di 6.000 route per Database e Route, si verifica il timeout dell'API del criterio. Si tratta di un'API di sola lettura e ha un impatto solo se l'API o l'interfaccia utente viene utilizzata per scaricare le oltre 6.000 route per le route e il database OSPF.

    Soluzione: utilizzare i comandi della CLI per recuperare le informazioni dall'Edge.

  • Problema 2663483: Un NSX Manager a nodo singolo si disconnetterà dal resto dell'ambiente di federazione di NSX se si sostituisce il certificato APH-AR in tale NSX Manager.

    Questo problema si verifica solo con la federazione di NSX e con il cluster NSX Manager a nodo singolo. Un NSX Manager a nodo singolo si disconnetterà dal resto dell'ambiente di federazione di NSX se si sostituisce il certificato APH-AR in tale NSX Manager.

    Soluzione: la distribuzione di un cluster NSX Manager a nodo singolo non è un'opzione di distribuzione supportata. È necessario disporre di un cluster NSX Manager a tre nodi.

  • Problema 2690457: Quando si aggiunge un MP a un cluster MP in cui publish_fqdns è impostato sul cluster MP e il server DNS esterno non è configurato correttamente, è possibile che il servizio proton non venga riavviato correttamente nel nodo che viene aggiunto.

    Il Manager che viene aggiunto non funzionerà e l'interfaccia utente non sarà disponibile.

    Soluzione: configurare il server DNS esterno con voci DNS dirette e inverse per tutti i nodi di Manager.

  • Problema 2719682: I campi elaborati dal controller Avi non vengono sincronizzati con l'intento nel criterio, causando discrepanze nei dati visualizzati nell'interfaccia utente di Avi e nell'interfaccia utente di NSX-T.

    I campi elaborati dal controller Avi vengono visualizzati vuoti nell'interfaccia utente di NSX-T.

    Soluzione: usare il commutatore di app per controllare i dati dall'interfaccia utente di Avi.

  • Problema 2792485: Viene visualizzato l'IP di NSX Manager anziché il nome di dominio completo per il Manager installato in vCenter.

    L'interfaccia utente di NSX-T integrata in vCenter mostra l'IP di NSX Manager anziché il nome di dominio completo per il Manager installato.

    Soluzione: nessuna.

  • Problema 2799371: Gli allarmi IPSec per VPN L2 non vengono cancellati anche se le sessioni di IPSec e VPN L2 sono attive.

    Questo problema non ha alcun impatto funzionale ad eccezione del fatto che vengono visualizzati allarmi aperti non necessari.

    Soluzione: risolvere manualmente gli allarmi.

  • Problema 2838613: Nelle versioni di ESX precedenti alla 7.0.3, la funzionalità di sicurezza di NSX non è abilitata nel VDS aggiornato dalla versione 6.5 a una versione successiva dopo l'installazione della sicurezza nel cluster.

    Le funzionalità di sicurezza di NSX non sono abilitate nelle macchine virtuali connesse al VDS aggiornato dalla versione 6.5 a una versione successiva (6.6+) in cui è supportata la funzionalità di sicurezza di NSX negli oggetti DVPortgroup di vSphere.

    Soluzione: dopo l'aggiornamento del VDS, riavviare l'host e attivare le macchine virtuali per abilitare la sicurezza nelle macchine virtuali.

  • Problema 2848614: Quando si aggiunge un MP a un cluster MP in cui publish_fqdns è impostato sul cluster MP e in cui la voce di ricerca diretta o inversa manca nel server DNS esterno o la voce DNS manca per il nodo che viene aggiunto, gli allarmi diretti o inversi non vengono generati per il nodo che viene aggiunto.

    Gli allarmi diretti o inversi non vengono generati per il nodo che viene aggiunto anche se la voce di ricerca diretta/inversa non è presente nel server DNS o la voce DNS non è presente per il nodo che viene aggiunto.

    Soluzione: configurare il server DNS esterno per tutti i nodi di Manager con voci DNS dirette e inverse.

  • Problema 2853889: Quando si crea la configurazione del tenant EVPN (con mappatura vlan-vni), i segmenti secondari vengono creati, ma lo stato della realizzazione dei segmenti secondari indica un errore per circa 5 minuti per poi essere ripristinato automaticamente.

    Sono necessari 5 minuti per realizzare la configurazione del tenant EVPN.

    Soluzione: nessuna. Attendere 5 minuti.

  • Problema 2866682: In Microsoft Azure, quando la rete accelerata è abilitata nelle macchine virtuali del carico di lavoro SUSE Linux Enterprise Server (SLES) 12 SP4 e NSX Agent è installato, l'interfaccia Ethernet non ottiene un indirizzo IP.

    L'agente della macchina virtuale non viene avviato e la macchina virtuale diventa non gestita.

    Soluzione: disabilitare la rete accelerata.

  • Problema 2868944: Il feedback dell'interfaccia utente non viene visualizzato quando si esegue la migrazione di più di 1.000 regole DFW da NSX for vSphere a NSX-T Data Center, ma le sezioni sono suddivise in sezioni di 1.000 regole al massimo.

    Il feedback dell'interfaccia utente non viene visualizzato.

    Soluzione: controllare i registri.

  • Problema 2870085: La registrazione a livello di criterio di sicurezza per abilitare/disabilitare la registrazione per tutte le regole non funziona.

    Non sarà possibile modificare la registrazione di tutte le regole modificando "logging_enabled" del criterio di sicurezza.

    Soluzione: modificare ogni regola per abilitare/disabilitare la registrazione.

  • Problema 2871440: I carichi di lavoro protetti con NSX Security in dvPortGroups di vSphere perdono le impostazioni di sicurezza quando vengono spostati tramite vMotion in un host connesso a un NSX Manager inattivo.

    Per i cluster installati con NSX Security nella funzionalità dvPortGroups di vSphere, alle macchine virtuali spostate tramite vMotion in host connessi a un NSX Manager inattivo non vengono applicate le regole DFW e di sicurezza. Queste impostazioni di sicurezza vengono applicate nuovamente quando viene ristabilita la connettività a NSX Manager.

    Soluzione: evitare lo spostamento tramite vMotion negli host interessati quando NSX Manager è inattivo. Se altri nodi di NSX Manager funzionano, spostare la macchina virtuale tramite vMotion in un altro host connesso a un NSX Manager integro.

  • Problema 2871585: La rimozione dell'host da DVS e l'eliminazione di DVS sono consentite per le versioni di DVS precedenti alla 7.0.3 dopo l'abilitazione della sicurezza di NSX nella funzionalità DVPortgroups di vSphere nei cluster mediante DVS.

    Potrebbe essere necessario risolvere eventuali problemi relativi alla configurazione del nodo di trasporto o del cluster che derivano dalla rimozione di un host da DVS o dall'eliminazione di DVS.

    Soluzione: nessuna.

  • Problema 2877776: È possibile che l'output "get controllers" includa informazioni obsolete sui controller diversi dal master rispetto al file controller-info.xml.

    Questo output della CLI crea confusione.

    Soluzione: riavviare nsx-proxy in tale TN.

  • Problema 2879133: La funzionalità Prevenzione malware può impiegare fino a 15 minuti per iniziare a funzionare.

    Quando la funzionalità Prevenzione malware viene configurata per la prima volta, l'inizializzazione della funzionalità può richiedere fino a 15 minuti. Durante l'inizializzazione, non viene eseguita alcuna analisi per l'individuazione dei malware, ma non viene visualizzato alcun messaggio che indica che l'inizializzazione è in corso.

    Soluzione: attendere 15 minuti.

  • Problema 2889482: Quando si aggiornano i profili dei segmenti per le porte rilevate, viene visualizzata una conferma di salvataggio errata.

    L'interfaccia utente del criterio consente di modificare le porte rilevate ma non invia la mappa di associazione aggiornata per le richieste di aggiornamento delle porte quando i profili dei segmenti vengono aggiornati. Dopo aver fatto clic su Salva, viene visualizzato un messaggio che indica un falso positivo. I segmenti risultano aggiornati per le porte rilevate, ma non lo sono.

    Soluzione: utilizzare l'API o l'interfaccia utente di MP per aggiornare i profili dei segmenti per le porte rilevate.

  • Problema 2898020: Nello stato dei nodi di trasporto viene visualizzato il messaggio di errore "Configurazione di FRR non riuscita: ROUTING_CONFIG_ERROR (-1)".

    Il nodo dell'Edge rifiuta una sequenza della mappa di routing configurata con un'azione Nega che ha più di un elenco di community collegato ai propri criteri di corrispondenza. Se i nodi dell'Edge non hanno la configurazione prevista dall'amministratore, si verifica un comportamento imprevisto.

    Soluzione: nessuna.

  • Problema 2910529: L'Edge perde l'indirizzo IPv4 dopo l'allocazione di DHCP.

    Dopo che la macchina virtuale Edge è stata installata e ha ricevuto un IP dal server DHCP, entro un breve periodo di tempo perde l'indirizzo IP e diventa inaccessibile. Questo problema si verifica perché il server DHCP non fornisce un gateway, quindi il nodo dell'Edge perde l'IP.

    Soluzione: assicurarsi che il server DHCP fornisca l'indirizzo del gateway corretto. In caso contrario, eseguire i passaggi seguenti:

    1. Accedere alla console della macchina virtuale Edge come utente admin.

    2. Arrestare il piano dati del servizio.

    3. Impostare interfaccia <mgmt intf> dhcp plane mgmt.

    4. Avviare il piano dati del servizio.

  • Problema 2919218: Per le selezioni eseguite per la migrazione dell'host vengono reimpostati i valori predefiniti dopo il riavvio del servizio MC.

    Dopo il riavvio del servizio MC, vengono reimpostati i valori predefiniti di tutte le selezioni pertinenti alla migrazione dell'host eseguite in precedenza, ad esempio l'abilitazione o la disabilitazione dei cluster, la modalità di migrazione, l'ordinamento della migrazione dei cluster e così via.

    Soluzione: assicurarsi che tutte le selezioni pertinenti alla migrazione dell'host vengano eseguite di nuovo dopo il riavvio del servizio MC.

  • Problema 2942900: Il firewall di identità non funziona per lo scraping del registro eventi quando si verifica il timeout delle query di Active Directory.

    Il firewall di identità genera una query ricorsiva di Active Directory per ottenere le informazioni sul gruppo dell'utente. È possibile che si verifichi il timeout delle query di Active Directory con un'eccezione di denominazione "Timeout di lettura della risposta LDAP, timeout utilizzato: 60000 ms". Pertanto, le regole del firewall non vengono popolate con gli indirizzi IP dello scraper del registro eventi.

    Soluzione: per migliorare i tempi delle query ricorsive, gli amministratori di Active Directory possono organizzare e indicizzare gli oggetti di Active Directory.

  • Problema 2954520: Quando il segmento viene creato dal criterio e il bridge è configurato da MP, l'opzione di scollegamento del bridging non è disponibile in tale segmento dall'interfaccia utente.

    Se il segmento viene creato dal criterio e il bridge è configurato da MP, non è possibile scollegare o aggiornare il bridging dall'interfaccia utente.

    Se viene creato un segmento dal lato del criterio, è consigliabile configurare il bridging solo dal lato del criterio. Analogamente, se viene creato un commutatore logico dal lato MP, è consigliabile configurare il bridging solo dal lato MP.

    Soluzione: utilizzare le API per rimuovere il bridging.

    1. Aggiornare l'elemento LogicalPort interessato e rimuovere l'allegato.

    PUT :: https://<mgr-ip>/api/v1/logical-ports/<logical-port-id>

    Nel campo delle intestazioni del payload PUT aggiungere -> X-Allow-Overwrite : true

    2. Eliminare BridgeEndpoint

    DELETE :: https://<mgr-ip>/api/v1/bridge-endpoints/<bridge-endpoint-id>

    3. Eliminare LogicalPort

    DELETE :: https://<mgr-ip>/api/v1/logical-ports/<logical-port-id>

  • Problema 3030847: Le modifiche della configurazione BGP VRF non vengono sempre applicate.

    Le modifiche apportate alla configurazione di BGP in un VRF non vengono sempre applicate.

    Soluzione: è possibile creare una route statica fittizia e rimuoverla. Ciò causerà un push della configurazione che realizzerà la configurazione BGP VRF nell'Edge.

  • Problema 3005685: Quando i clienti configurano una connessione di Open ID Connect come provider di autenticazione di NSX LM, è possibile che si verifichino errori.

    La configurazione di OpenID Connect genera errori.

    Soluzione: nessuna.

  • Problema 2949575: Se si rimuove un nodo worker di Kubernetes dal cluster senza eliminare innanzitutto i pod che si trovano in tale nodo, i pod rimangono bloccati per sempre nello stato Terminazione in corso.

    NSX Application Platform e le applicazioni che include funzionano parzialmente o non funzionano come previsto.

    Soluzione: eliminare manualmente tutti i pod per cui viene visualizzato lo stato Terminazione in corso utilizzando le informazioni seguenti.

    1. Da NSX Manager o dall'host IP dello strumento di esecuzione (jump host Linux da cui è possibile accedere al cluster Kubernetes) eseguire il comando seguente per elencare tutti i pod con stato Terminating.

      kubectl get pod -A | grep Terminating

    2. Eliminare tutti i pod elencati utilizzando il comando seguente.

      kubectl delete pod <pod-name> -n <pod-namespace> --force --grace-period=0

  • Problema 3017840: Il cambio dell'Edge non si verifica quando l'indirizzo IP dell'uplink viene modificato.

    Uno stato errato di HA potrebbe causare il blackhole del traffico.

    Soluzione: cambiare lo stato di BFD. Prima di modificare l'IP dell'uplink di una modifica dell'Edge, attivare la modalità di manutenzione dell'Edge.

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