Versionshinweise für VMware NSX-T Data Center 3.2

VMware NSX 3.2 | 16. DEZ 2021 | Build 19067070 Prüfen Sie, ob Ergänzungen und Updates für diese Versionshinweise zur Verfügung stehen.

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

• Wichtige Information über NSX-T Data Center 3.2.0

• Neuigkeiten

• Tech Preview-Funktionen

• Inklusive Terminologie

• Kompatibilität und Systemvoraussetzungen

• Veraltete Funktionen/APIs und Änderungen des Verhaltens

• Upgrade-Hinweise für diese Version

• API und CLI-Ressourcen

• Verfügbare Sprachen

• Revisionsverlauf der Dokumente

• Behobene Probleme

• Bekannte Probleme

Wichtige Information über NSX-T Data Center 3.2.0

Beachten Sie, dass das VMware NSX-Team ein Problem mit dem Upgrade von früheren Versionen auf NSX-T Data Center 3.2.0 identifiziert und entschieden hat, diese Version von den Download-Seiten zugunsten von NSX-T Data Center 3.2.0.1 zu entfernen.

Kunden, die NSX-T Data Center 3.2.0 heruntergeladen und bereitgestellt haben, werden weiterhin unterstützt, es wird jedoch empfohlen, ein Upgrade auf NSX-T Data Center 3.2.0.1 durchzuführen.

Neuigkeiten

NSX-T Data Center 3.2.0 ist eine Hauptversion, die viele neue Funktionen in allen vertikalen Bereichen von NSX-T bietet: Netzwerk, Sicherheit, Dienste und Onboarding. Hier finden Sie einige der wichtigsten Verbesserungen.

• Switch-unabhängige verteilte Sicherheit: Die Möglichkeit zur Ausweitung der Mikrosegmentierung auf Arbeitslasten, die in vSphere-Netzwerken bereitgestellt werden.

• Gateway-Sicherheit: Verbesserte L7-App-IDs, Malware-Erkennung und Sandboxing, URL-Filterung, Benutzer-ID-Firewall, TLS-Prüfung (Tech Preview) und Intrusion Detection and Prevention Service (IDS/IPS).

• Erweiterte verteilte Sicherheit: Malware-Erkennung und -Vorbeugung, verhaltensbasiertes IDS/IPS, erweiterte Anwendungsidentitäten für L7-Firewall.

• Verbesserte Integration mit NSX Advanced Load Balancer (vormals Avi): Installieren und Konfigurieren von NSX ALB (Avi) über die NSX-T-Benutzeroberfläche. Migrieren von NSX for vSphere LB zu NSX ALB (Avi).

• Migration von NSX for vSphere zu NSX-T: Wichtige Verbesserungen am Migrationskoordinator, die die Abdeckung der unterstützten NSX for vSphere-Topologien erweitern und Flexibilität für die Ziel-NSX-T-Topologien bieten.

• Verbesserter Schutz vor Log4j-Schwachstelle: Apache Log4j auf Version 2.16 aktualisiert, um CVE-2021-44228 und CVE-2021-45046 zu beheben. Weitere Informationen zu diesen Schwachstellen und deren Auswirkungen auf VMware-Produkte finden Sie unter VMSA-2021-0028.

Neben diesen Verbesserungen wurden zu allen Produktteilen viele weitere Funktionen hinzugefügt.

• Layer-2-Netzwerk
• Layer-3-Netzwerk
• Multicast
• Edge-Plattform
• Verteilte Firewall
• Distributed Intrusion Detection/Prevention-System (D-IDPS)
• Gateway-Firewall
• Neue NSX Application Platform
• Netzwerkerkennung und -antwort
• VPN
• Guest Introspection
• Verbund
• Containernetzwerk und Sicherheit
• Load Balancing
• NSX Cloud
• Betrieb und Überwachung
• Überwachung
• Benutzerfreundlichkeit und Benutzeroberfläche
• Richtlinie
• AAA und Plattformsicherheit
• Skalierung
• Lizenzierung
• Migration von NSX Data Center for vSphere zu NSX-T Data Center

Layer-2-Netzwerk

• Unterstützung für die Bindung von zwei NICs auf physischen Windows-Servern – Auf physischen Servern werden jetzt Verbindungen unterstützt, die Bindungen von zwei physischen NICs (pNICs) nutzen. Dies ermöglicht die Konfiguration von Aktiv/Aktiv- oder Aktiv/Standby-Bindungen. Diese Funktion wird in VLAN- und Overlay-Netzwerken unterstützt.

• NUMA-fähige Gruppierungsrichtlinie – NSX unterstützt jetzt die Verarbeitung des Datenverkehrs auf demselben NUMA-Knoten wie die pNICs, die zum Verlassen von ESXi verwendet wurden. Diese Funktion verbessert die Leistung bei der Bereitstellung mit Gruppierungsrichtlinien über mehrere NUMAs hinweg.

• Neue Funktionen für den erweiterten Datenpfad – Der erweiterte Datenpfad-Switch unterstützt jetzt die verteilte Firewall (DFW), den verteilten Lastausgleichsdienst (DLB) und Port-Mirroring-Funktionen.

Layer-3-Netzwerk

• Unterstützung für L3-EVPN-Routenserver-Modus – ESXi kann jetzt VXLAN-Datenverkehr direkt an die Datencenter-Fabric-Router senden, wobei der Edge-Knoten im Datenpfad umgangen wird. In diesem Bereitstellungsmodell ist der Tier-0-SR (Dienstrouter), der auf dem Edge-Knoten gehostet wird, weiterhin erforderlich, jedoch nur für die Behandlung der Control Plane, d. h. für die Ankündigung der verbundenen Präfixe über die EVPN L2-VPN-Adressfamilie bei der Fabric. ESXi unterstützt jetzt ECMP in Richtung mehrerer physischer Router in der Fabric und testet die Verfügbarkeit der Router mit BFD.

• 5-Tupel-ECMP auf ESXi und KVM – Der auf ESXi gehostete verteilte Router (DR) unterstützt jetzt den 5-Tupel-Hashing-Algorithmus, wenn ECMP aktiviert ist. Mit dieser Funktion basiert das Hashing auf IP-Adressquelle, IP-Adressziel, IP-Protokoll, Layer-4-Portquelle, Layer-4-Portziel. Dies ermöglicht eine bessere Verteilung des Datenverkehrs auf alle verfügbaren Dienstrouter (SRs).

• Proxy-ARP-Unterstützung auf Aktiv/Aktiv-Tier-0-Gateway – In einfachen Topologien, die kein dynamisches Routing erfordern, kann jetzt ein Tier-0-Gateway im Aktiv/Aktiv-HA-Modus eingesetzt werden, was einen höheren Durchsatz bietet.

Multicast

• Unterstützung von Aktiv/Aktiv auf Tier-0-SR für Multicast-Datenverkehr – NSX unterstützt jetzt ECMP für Multicast-Datenverkehr über mehrere Tier-0-SRs (Dienstrouter) hinweg und bietet so einen besseren Durchsatz für Multicast-Datenverkehr.

Edge-Plattform

• UEFI-Unterstützung auf Bare Metal-Edge – NSX unterstützt jetzt die Bereitstellung von Bare Metal-Edge-Knoten auf Servern, die im UEFI-Modus ausgeführt werden. Dadurch können Edge-Knoten auf mehr Servern bereitgestellt werden.

Verteilte Firewall

• Verteilte Firewall unterstützt VMs, die auf verteilten Portgruppen auf VDS-Switches bereitgestellt sind – In früheren Versionen konnte NSX nur verteilte Sicherheitsfunktionen für N-VDS-Switchports erzwingen. Jetzt können Sie die Funktionen der verteilten Firewall für VDS-basierte VLAN-Netzwerke nutzen, ohne den Switchport in N-VDS zu konvertieren.

• Unterstützung für dynamische Tag-Kriterien für Gruppen von IP-Adressen.

• Unterstützung der verteilten Firewall für physische Server – Betriebssystem RedHat Enterprise Linux 8.0.

• Hinzufügen von mehr Anwendungs-IDs für die L7-Firewall-Nutzung.

• Malware-Schutz für verteilte Firewall (vertikaler Anwendungsfall) – Die verteilte Firewall von NSX verfügt jetzt über Zero-Day-Funktionen zur Erkennung und Verhinderung von Malware mithilfe fortschrittlicher Techniken des maschinellen Lernens und Sandboxing-Funktionen.

• Konfiguration der selektiven AD-Synchronisierung für IDFW – Die AD-Konfiguration der identitätsbasierten Firewall unterstützt jetzt das selektive Hinzufügen von Organisationseinheiten und Benutzern.

• Statistiken der identitätsbasierten Firewall – Das Dashboard für die Sicherheitsübersicht wurde um Statistiken der identitätsbasierten Firewall für aktive Benutzer und aktive Benutzersitzungen erweitert.

• Unterstützung der identitätsbasierten Firewall für das SMB-Protokoll.

Distributed Intrusion Detection/Prevention-System (D-IDPS)

• Verteiltes IDS/IPS wird für VMs unterstützt, die in verteilten Portgruppen auf VDS bereitgestellt sind.

• Verteiltes IDS/IPS unterstützt jetzt verhaltensbasierte Erkennung und Prävention – Eine neue Klasse von IDS-Signaturen ist jetzt sowohl auf dem verteilten IDPS als auch auf dem Edge verfügbar. Statt zu versuchen, Malware-spezifisches Verhalten zu identifizieren, versuchen diese Signaturen, Netzwerkverhalten zu identifizieren, das Anzeichen einer erfolgreichen Infizierung aufweist. Dies umfasst beispielsweise die Identifizierung von TOR-Kommunikation im Netzwerk, das Vorhandensein selbstsignierter TLS-Zertifikate an hohen Portnummern oder ausgefeiltere statusbehaftete Erkennungen, wie z. B. die Erkennung von Beaconing-Verhaltensweisen. Diese Signaturklasse ist durch den Schweregrad „Zur Information“ gekennzeichnet. Wenn NSX NDR aktiviert ist, wird eine weitere ML-basierte Verarbeitung auf Warnungen angewendet, die von diesen Signaturen erzeugt werden, um Fälle zu priorisieren, die in der spezifischen überwachten Umgebung sehr wahrscheinlich anomal sind.

• Kuratierung und Kombination von Trustwave- und VMware-Signaturen – Der NSX IDS/IPS-Signatursatz ermöglicht jetzt den Zugriff auf einen neuen IDS-Regelsatz, der von VMware entwickelt und kuratiert wird, um eine hohe Sicherheitseffizienz zu gewährleisten und die Wahrscheinlichkeit falsch positiver Ergebnisse zu minimieren. Der Regelsatz kombiniert Erkennungen, die von Drittanbietern entwickelt wurden, z. B. von Trustwave, sowie neue Bedrohungen und einen Korpus von durch VMware entwickelten Signaturen, die für die NSX IDS-Engines optimiert wurden.

Gateway-Firewall

• Auf der Benutzeridentität basierte Zugriffssteuerung – Die Gateway-Firewall führt die folgenden zusätzlichen Funktionen für die auf der Benutzeridentität basierte Firewall ein:

  1. Für Bereitstellungen, in denen Active Directory als Benutzerauthentifizierungssystem verwendet wird, nutzt NSX Active Directory-Protokolle.

  2. Für alle anderen Authentifizierungssysteme kann NSX jetzt vRealize Log Insight-basierte Protokolle nutzen, um die Zuordnung der Benutzeridentität zu einer IP-Adresse zu identifizieren.

• Erweiterter Satz von L7-AppIDs – Die Gateway-Firewall-Funktionen wurden verbessert, um eine umfassendere Anzahl von Layer-7-Anwendungen zu identifizieren.

• TLS-Prüfung für ein- und ausgehenden Datenverkehr (🔎Tech Preview, nicht für Produktionsbereitstellungen) – Immer mehr Datenverkehr wird im Netzwerk verschlüsselt. Mit der TLS-Überprüfungsfunktion können Sie jetzt die NSX Gateway-Firewall nutzen, um Dienste für Deep Packet Inspection und die Erkennung und Verhinderung von Bedrohungen auch für verschlüsselten Datenverkehr zu nutzen.

• URL-Filterung (umfasst Kategorisierung und Reputation von URLs) – Sie können internetgebundenen Datenverkehr jetzt basierend auf der neuen URL-Filterungsfunktion kontrollieren. Mit dieser Funktion können Sie den Internetzugriff basierend auf URL-Kategorien sowie der Reputation der URLs kontrollieren. Das URL-Repository, einschließlich der Kategorisierungs- und Reputationsdaten, wird fortlaufend aktualisiert, um den Schutz zu gewährleisten.

• Malware-Analyse und Sandboxing-Unterstützung – Die NSX Gateway-Firewall bietet jetzt Malware-Erkennung für bekannte Malware und Zero-Day-Malware mithilfe fortschrittlicher Techniken des maschinellen Lernens und Sandboxing-Funktionen. Die Daten bekannter Malware werden fortlaufend aktualisiert. (Sehen Sie sich das bekannte Problem 2888658 vor der Bereitstellung in Live-Produktionsbereitstellungen an.)

• Erkennung und Verhinderung von Eindringversuchen (🔎Tech Preview, nicht für Produktionsbereitstellungen) – Für die NSX Gateway-Firewall werden Intrusion Detection and Prevention-Funktionen (IPS) im Tech Preview-Modus eingeführt. Sie können den Funktionssatz in Nicht-Produktionsbereitstellungen testen.

Neue NSX Application Platform

NSX Application Platform – VMware NSX Application Platform ist eine neue containerbasierte Lösung, die in NSX-T 3.2.0 eingeführt wurde. Sie bietet eine hochverfügbare, stabile, horizontal skalierbare Architektur, um eine Reihe von Kernplattformdiensten bereitzustellen, die verschiedene neue NSX Funktionen wie die folgenden ermöglichen:

NSX Intelligence
NSX Metrics
NSX Network Detection and Response
NSX Malware-Schutz

Der NSX Application Platform-Bereitstellungsvorgang wird vollständig über die NSX Manager-Benutzeroberfläche koordiniert und erfordert eine unterstützte Kubernetes-Umgebung. Weitere Informationen zu den Infrastrukturvoraussetzungen und den Anforderungen für die Installation finden Sie im Handbuch zur Bereitstellung und Verwaltung der VMware NSX Application Platform.

Netzwerkerkennung und -antwort

• VMware NSX Network Detection and Response korreliert IDPS-, Malware- und Anomalie-Ereignisse in Kampagnen, die die Identifikation von Bedrohungen und schädlichen Aktivitäten im Netzwerk ermöglichen.

• Korrelation in Bedrohungskampagnen statt in Ereignissen ermöglicht es SOC-Operatoren, sich auf die Sichtung einer kleinen Gruppe verfolgbarer Bedrohungen zu konzentrieren.

• NSX Network Detection and Response sammelt IDPS-Ereignisse vom verteilten IDPS, Malware-Ereignisse (nur schädliche Dateien) vom Gateway und Netzwerk-Anomalieereignisse von NSX Intelligence.

  • Gateway-IDPS-Ereignisse (Tech Preview) werden von NSX Network Detection and Response in NSX-T 3.2 nicht erfasst.

• Die NSX Network Detection and Response-Funktion wird in der Cloud ausgeführt und ist in zwei Cloud-Regionen verfügbar: USA und EU.

Weitere Informationen zum Aktivieren, Verwenden, Verwalten und Beheben von Fehlern der NSX Network Detection and Response-Funktion finden Sie im Abschnitt NSX Network Detection and Response des NSX-T Data Center­Administratorhandbuchs.

VPN

• Erweiterte Service-Level-Alarme für VPN – Details zum Status des IPSec-Dienstes.

• Zusätzliche Protokolldetails für die Paketverfolgung – Anzeige von SPI- und Exchange-Informationen für IPSec.

Guest Introspection

• Verbesserungen der Guest Introspection – Guest Introspection bietet einen Satz APIs auf der Datenebene, die im Gastkontext verbraucht werden können. Diese Verbesserung stellt sicher, dass nur Benutzer mit der entsprechenden Berechtigung diesen Zugriff erhalten.

• Unterstützung weiterer Betriebssysteme für GI – Guest Introspection unterstützt jetzt CentOS 8.2, RHEL 8.2, SLES15 SP1, Ubuntu 20.04.

Verbund

Hinweis:

Während NSX-Versionen vor 3.2.0 das Onboarding vorhandener lokaler Manager-Sites unterstützten, wird diese Onboarding-Unterstützung ab 3.2.0 verzögert und in einer späteren Version von 3.2 erneut eingeführt.

• Unterstützung der VM-Tag-Replizierung zwischen lokalen Managern – Während der Notfallwiederherstellung (DR) werden replizierte VMs am DR-Speicherort neu gestartet. Wenn die Sicherheitsrichtlinie auf NSX-VM-Tags basiert, müssen die replizierten VMs zum Wiederherstellungszeitpunkt am DR-Speicherort im lokalen Remote-Manager über diese NSX-Tags verfügen. NSX-Verbund 3.2 unterstützt jetzt die VM-Tag-Replizierung zwischen lokalen Managern. Die Tag-Replizierungsrichtlinie kann nur über die API konfiguriert werden.

• Überwachung der Verbundkommunikation – Die Seite „Standortmanager“ enthält jetzt eine Anzeige zu Latenz und Nutzung der Kanäle zwischen globalen Managern und lokalen Managern. Dies bietet mehr Transparenz im Hinblick auf die Integrität der verschiedenen Komponenten des Verbunds.

• Firewall-Entwürfe – Entwürfe der Sicherheitsrichtlinien sind jetzt im globalen Manager verfügbar. Dies umfasst die Unterstützung für automatische und manuelle Entwürfe.

• LDAP-Unterstützung im globalen Manager – Der globale Manager unterstützt jetzt die Konfiguration von LDAP-Quellen für die rollenbasierte Zugriffssteuerung (RBAC), die der Unterstützung für lokale Manager ähnelt.

Containernetzwerk und Sicherheit

• Integration von Antrea in NSX-T – Die Möglichkeit, Antrea-Netzwerkrichtlinien über die Benutzeroberfläche der verteilten NSX-T-Firewall zu definieren, wurde hinzugefügt. Richtlinien werden auf K8s-Clustern angewendet, auf denen Antrea 1.3.1 bis 1.2.2 mittels Interworking-Controller ausgeführt wird. Außerdem wurde eine Bestandserfassung hinzugefügt: K8s-Objekte, z. B. Pods, Namespaces und Dienste, werden in der NSX-T-Bestandsliste erfasst und mit Tags versehen, sodass sie in DFW-Richtlinien ausgewählt werden können. Antrea-Traceflow kann jetzt über die NSX-T Traceflow-Benutzeroberfläche gesteuert werden und Protokollpakete können mithilfe von Antrea von K8s-Clustern erfasst werden. Es ist nicht zwingend erforderlich, dass die NSX-T-Datenebene auf Ihren K8s-Antrea-Clusterknoten aktiviert ist.

• Verbesserungen der Gruppierung – Unterstützung für Antrea-Containerobjekte wurde hinzugefügt. Unterstützung für den Operator Nicht in für Segmentport-Tag-Kriterien wurde hinzugefügt. Fügt Unterstützung für den Operator UND zwischen Gruppenmitgliedschaftskriterien für Segmente und Segmentports hinzu.

Load Balancing

• VMware NSX Advanced Load Balancer (Avi) – Installation über NSX – Controller für VMware NSX Advanced Load Balancer (Avi) können jetzt über die NSX-T Manager-Benutzeroberfläche installiert werden, die einen Bereich für die Installation aller NSX-Komponenten bietet.

• Übergreifendes Starten der Benutzeroberfläche von VMware NSX Advanced Load Balancer (Avi) über die NSX-T Manager-Benutzeroberfläche – Starten Sie die Benutzeroberfläche von VMware NSX ALB (Avi) für erweiterte Funktionen über den NSX-T Manager.

• Benutzeroberflächen für Advanced Load Balancer (Avi) werden in NSX angezeigt – Konfigurieren Sie VMware NSX Advanced Load Balancer (Avi) in NSX Manager.

• Migration des Lastausgleichs von NSX for vSphere zu VMware NSX Advanced Load Balancer (Avi) – Migrieren Sie Load Balancer zu VMware NSX ALB (Avi), wenn Sie das Modell Bring Your Own Topology (BYOT) mit dem Migrationskoordinator anwenden.

• Distributed Load Balancer (DLB) für Anwendungsbeispiele mit vSphere with Kubernetes (K8s)

  • Unterstützung für das Distributed Intrusion Detection-System (DIDS) und DLB für die Zusammenarbeit.

  • vMotion-Unterstützung.

  • Zusätzlicher Auswahlalgorithmus für DLB-Poolmitglieder: Wenigste Verbindung und Quell-IP-Hash.

  • Zusätzliche Befehle zur Fehlerbehebung.

• Nativer NSX-T-Load Balancer – Load Balancing-Funktionen werden in Zukunft nicht mehr hinzugefügt oder verbessert. Verbesserungen der NSX-T-Plattform werden nicht auf den nativen NSX-T-Load Balancer ausgeweitet.

• Empfehlung zum Load Balancing

  • Wenn Sie Load Balancing in NSX-T verwenden, wird empfohlen, zum VMware NSX Advanced Load Balancer (Avi) zu migrieren, der eine Obermenge der NSX-T-Load Balancing-Funktionen bereitstellt.

  • Wenn Sie NSX Data Center Advanced, NSX Data Center Enterprise Plus, NSX Advanced oder NSX Enterprise erworben haben, haben Sie Anspruch auf die Basisedition von VMware NSX Advanced Load Balancer (Avi), die über dieselben Funktionen wie NSX-T LB verfügt.

  • Es wird empfohlen, VMware NSX Advanced Load Balancer (Avi) Enterprise zu erwerben, um Load Balancing auf Unternehmensniveau, GSLB, erweiterte Analysen, Container-Ingress, Anwendungssicherheit und WAF freizuschalten.

Hinweis:

Es wird empfohlen, für neue Bereitstellungen mit NSX-T Data Center die Vorteile von VMware NSX Advanced Load Balancer (Avi) in der Version v20.1.6 oder höher zu nutzen und nicht den nativen NSX-T Load Balancer.

Weitere Informationen:

• Seite zu VMware NSX Advanced Load Balancer (Avi): https://www.vmware.com/products/nsx-advanced-load-balancer.html

• Migration zu VMware NSX Advanced Load Balancer (Avi): https://www.vmware.com/products/nsx/migrate-to-advanced-load-balancing.html

• Bereitstellen von VMware NSX Advanced Load Balancer (Avi) auf VCF mit Advanced Load Balancing für VCF VMware Validated Solution

• Vorgehensweise zum Anwenden Ihrer NSX Data Center-Lizenz auf den VMware NSX Advanced Load Balancer (Avi): https://avinetworks.com/docs/

• Editionen von VMware NSX Advanced Load Balancer (Avi): https://avinetworks.com/docs/21.1/nsx-license-editions/

NSX Cloud

• Erweiterte Betriebssystemunterstützung in NSX Cloud – NSX Cloud unterstützt jetzt neben den bereits unterstützten Betriebssystemen auch folgendes Betriebssystem:

  • Ubuntu 20.04

  • RHEL 8.next

• NSX Cloud-Unterstützung von erweiterten Sicherheitsfunktionen (Layer 7) auf PCG (🔎Tech Preview, nicht für Produktionsbereitstellungen) – NSX Cloud bietet auf dem PCG für Azure und AWS einige erweiterte Sicherheitsfunktionen (Layer 7), mit denen Sie für Ihre Arbeitslasten von der Sicherheit auf Anwendungsebene in der Public Cloud profitieren können. Sie können den Funktionssatz in Nicht-Produktionsbereitstellungen testen.

• NSX Cloud-Unterstützung der IDFW für Einzelbenutzer-VDI (🔎Tech Preview, nicht für Produktionsbereitstellungen) – NSX Cloud bietet eine identitätsbasierte Firewall, die benutzerbasierte Sicherheit für die VDI-Bereitstellung bietet. Es wird möglich sein, einer VM ein dem Benutzer zugeordnetes Sicherheitsprofil zuzuordnen, was die Sicherheitsverwaltung vereinfacht und die Sicherheit verstärkt. Sie können den Funktionssatz in Nicht-Produktionsbereitstellungen testen.

Betrieb und Überwachung

• Befehl „del nsx“ zur Bereinigung von NSX auf einem physischen/Bare Metal-Server – Entsprechend der „del nsx“-Funktion auf ESX-Servern ist der CLI-Befehl del nsx verfügbar, mit dem NSX von einem physischen/Bare Metal-Server entfernt werden kann, auf dem ein Linux-Betriebssystem ausgeführt wird. Wenn Sie über einen physischen/Bare Metal-Server mit NSX-VIBs in einem veralteten Zustand verfügen und NSX von diesem Host nicht deinstallieren können, können Sie den CLI-Befehl del nsx nutzen, um NSX in einem schrittweisen Prozess von diesem Host zu entfernen und ihn in einen Zustand zu versetzen, in dem NSX neu installiert werden kann.

• Analyse des Live-Datenverkehrs über die NSX Manager-Benutzeroberfläche – Die Funktion für die Analyse des Live-Datenverkehrs ist jetzt auf der NSX Manager-Benutzeroberfläche verfügbar, sodass Sie Live-Datenverkehrsflüsse problemlos über Datencenter hinweg analysieren können. Diese Funktion bietet einen einheitlichen Diagnoseansatz, indem Traceflow und die Paketerfassung kombiniert werden. Sie können beide Aktionen in einem Schritt ausführen: Live-Pakete verfolgen und die Paketerfassung an der Quelle durchführen. Die Analyse des Live-Datenverkehrs unterstützt die genaue Ermittlung von Problemen im Netzwerkdatenverkehr und bietet die Möglichkeit, eine Analyse bestimmter Flows durchzuführen, um Störungen zu vermeiden.

• Selektives Port-Mirroring – Verbesserte Spiegelung mit Flow-basierter Filterungsfunktion und geringeren Ressourcenanforderungen. Für eine effektive Fehlerbehebung können Sie sich jetzt auf die passenden Flows konzentrieren.

• Prüfung der Fabric MTU-Konfiguration – Eine bedarfsgesteuerte und regelmäßige MTU-Prüfung ist über die NSX Manager-Benutzeroberfläche verfügbar, mit der die MTU-Konfiguration für das Overlay-Netzwerk überprüft werden kann. Für MTU-Nichtübereinstimmungen werden Warnungen ausgelöst.

• Traceflow-Unterstützung für VLAN-gestütztes logisches Netzwerk – Sie können Traceflow auf einem VLAN-gestützten logischen Netzwerk ausführen. Diese Funktion ist über die API verfügbar.

• Verbesserte Protokollierung – Verbesserte Protokollierung durch Erkennung und Unterdrückung von wiederholt auftretenden Protokollmeldungen, die zu häufig ausgegeben werden. Dies verhindert, dass wichtige Protokollmeldungen verloren gehen oder übersehen werden.

• Verbessertes CLI-Handbuch und zusätzliche Befehle – Ein Satz neuer CLI-Befehle wurde eingeführt, die den Konstrukten der Benutzeroberfläche (Richtlinie) zugeordnet sind, z. B. dem Instanzsegment. Dies ermöglicht Benutzern eine einfachere Nutzung der CLI. Zur Vereinfachung der Verwendung wurde auch ein vollständig überarbeitetes CLI-Handbuch eingeführt.

• Kapazitätsgrenzwerte: Das Dashboard „Kapazität“ kennt jetzt die Bereitstellungsgröße des NSX Manager für einige Kapazitätsgrenzwerte und generiert möglicherweise Alarme, wenn die empfohlene Kapazität überschritten wird, nachdem ein Upgrade auf NSX-T 3.2 durchgeführt wurde. Kunden, die zusätzliche Kapazität benötigen, wird empfohlen, ein Upgrade von einem mittelgroßen NSX Manager auf einen großen NSX Manager durchzuführen oder die Nutzung zu reduzieren, um weiterhin unterstützt zu werden.

Überwachung

• Zeitreihenüberwachung – Bietet die Möglichkeit, mit der NSX Application Platform Metriken für einen längeren Zeitraum von bis zu einem Jahr zu erfassen und zu speichern. Zeitreihenmetriken erleichtern die Überwachung von Trends der wichtigen Leistungsindikatoren, bieten Vorher-/Nachher-Analysen und den Verlaufskontext, der bei der Fehlerbehebung hilfreich ist. Zeitreihenmetriken sind für Edge-Knoten, Tier-0- und Tier-1-Gateways, NSX Manager, NSX Application Platform und Sicherheitsfunktionen verfügbar, einschließlich TLS-Prüfung, IDPS und Gateway-Firewall. Diese Zeitreihenmetriken sind über NSX-T-APIs verfügbar. Eine Teilmenge dieser Metriken ist auch auf der NSX Manager-Benutzeroberfläche verfügbar.

• Ereignisse und Alarme

  • Zertifikate – Aktualisierung des CA-Pakets empfohlen

  • Vorgang – Cluster inaktiv, Cluster nicht verfügbar, Verwaltungskanal zum Manager-Knoten inaktiv, Verwaltungskanal zum Manager-Knoten lange inaktiv

  • Verbund – GM-zu-GM-Latenzwarnung, GM-zu-GM-Synchronisierungswarnung, GM-zu-GM-Synchronisierungsfehler, GM-zu-LM-Latenzwarnung, GM-zu-LM-Synchronisierungsfehler, LM-Wiederherstellung während des Konfigurationsimports, Schwellenwert für Warteschlangenbelegung überschritten

  • Transportknotenintegrität – Uplink des Transportknotens inaktiv

  • Verteilte Firewall – Hohe Anzahl DFW-Sitzungen, DFW-vMotion-Fehler

  • Edge – Edge-Knoteneinstellungen und vSphere-Einstellungen wurden geändert, Edge-Knoteneinstellungen stimmen nicht überein, Edge-VM- und vSphere-Einstellungen stimmen nicht überein, Edge- und vSphere-Speicherort stimmen nicht überein

  • Edge-Integrität – Hoher NIC-Durchsatz des Edge-Datenpfads, sehr hoher NIC-Durchsatz des Edge-Datenpfads, Fehlerdomäne inaktiv

  • VPN – IPSec-Dienst inaktiv

  • NAT – SNAT-Portnutzung auf Gateway ist hoch

  • Load Balancing – Die Load Balancing-Konfiguration wurde wegen unzureichendem Arbeitsspeicher nicht realisiert

  • MTU-Prüfung – MTU-Nichtübereinstimmung innerhalb der Transportzone, MTU des globalen Routers zu groß

  • Kommunikation der NSX Application Platform – Verzögerung bei Messaging-Überlauf erkannt, Verzögerung im Messaging-Rawflow erkannt, TN-Flow-Exporter getrennt

  • Integrität der NSX Application Platform – Rund 55 Alarme zur Überwachung der Integrität der Plattform

Benutzerfreundlichkeit und Benutzeroberfläche

• Anpassen von Anmeldenachrichten und Bannern Sie können die Anmeldenachricht von NSX Manager konfigurieren und anpassen und die obligatorischen Felder festlegen, die ein Benutzer vor der Anmeldung akzeptieren muss.

• Verbesserungen bei der Suche und Filterung – Die in der NSX-Benutzeroberfläche vorhandene Such- und Filterfunktion wurde verbessert. Auf dem Startbildschirm werden mögliche Suchbegriffe und die zuletzt gesuchten Objekte angezeigt. Für die erweiterte Suche ist ein separater Bereich verfügbar, in dem Benutzer Suchvorgänge anpassen und konfigurieren können. Suchabfragen zeigen jetzt Informationen zu Tags und Alarmen an.

• VPAT – Fehlerbehebungen zur Überbrückung der Lücke bei der Barrierefreiheit des Produkts.

• NSX-Topologie – Visualisierung der zugrunde liegenden Fabric, die den Gateways zugeordnet ist. Diese Funktion bietet Ihnen die Möglichkeit, die Edge-Cluster und die Host-Switch-Konfiguration zu visualisieren und die Details der Host- und Edge-Konfiguration zu erfassen.

• Verbesserung der Benutzerfreundlichkeit bei der Objektauswahl auf der Benutzeroberfläche – Diese Funktion bietet die Möglichkeit, mehrere Objekte auszuwählen, die sich in derselben Kategorie befinden. Außerdem können alle Objekte ausgewählt werden.

• Überarbeitete Sicherheitsübersicht – Die Seite Sicherheitsübersicht wurde überarbeitet, um eine ganzheitliche Sicht auf die Sicherheitskonfigurationen bereitzustellen. Sie können Bedrohungen und Reaktionen über verschiedene Funktionen hinweg und die vorhandene Konfiguration und Kapazität des Systems anzeigen.

• In vCenter integrierte NSX-T-Benutzeroberfläche – NSX-T kann jetzt über die vCenter-Benutzeroberfläche mit dem vCenter-Plug-in für NSX-T installiert und konfiguriert werden. Diese Funktion wird ERST ab vCenter 7.0U3 unterstützt.

• Bereitstellungsassistent von NSX-T für häufige Anwendungsfälle – Nach der Installation über das vCenter-Plug-in kann NSX-T jetzt NSX-T-Funktionen basierend auf gängigen Anwendungsfällen aktivieren, sodass Benutzer NSX-T-Funktionen schnell mit dem Bereitstellungsassistenten aktivieren können. Diese Version unterstützt zwei Assistenten: Einen zum Aktivieren der Sicherheitsfunktionen von NSX und einen weiteren zum Aktivieren virtueller Netzwerkfunktionen von NSX.

Richtlinie

• Heraufstufungstool für NSX Manager zu NSX-Richtlinien – Bietet die Möglichkeit, eine vorhandene Konfiguration von NSX Manager zur NSX Richtlinie heraufzustufen, ohne dass der Datenpfad unterbrochen oder vorhandene Objekte gelöscht werden bzw. neu erstellt werden müssen. Sobald die NSX Manager-Objekte zur NSX-Richtlinie heraufgestuft wurden, werden die NSX Manager-Objekte über die Manager-Benutzeroberfläche/-API mit Schreibschutz versehen. Anschließend können Sie mit denselben Objekten über die NSX-Richtlinienbenutzeroberfläche/-API interagieren.

AAA und Plattformsicherheit

• Verbesserungen der Zertifikatsverwaltung für die TLS-Prüfung (🔎Tech Preview, nicht für Produktionsbereitstellungen) – Mit der Einführung der TLS-Überprüfungsfunktion unterstützt die Zertifikatsverwaltung jetzt das Hinzufügen und Ändern von Zertifizierungspaketen und die Möglichkeit, CA-Zertifikate zu generieren, die mit der TLS-Überprüfungsfunktion verwendet werden können. Darüber hinaus kann die allgemeine Benutzeroberfläche für die Zertifikatsverwaltung Änderungen übertragen, die den Import/Export von Zertifikaten vereinfachen.

• Verbesserungen der Hochverfügbarkeit und Skalierung für die LDAP-Integration – Die LDAP-Konfiguration unterstützt jetzt die Konfiguration mehrerer LDAP-Server pro Domäne. Außerdem unterstützt sie die Vertrauenswürdigkeit mehrerer Zertifikate, die verschiedenen LDAP-Servern pro Domäne zugeordnet sind.

Skalierung

• Erhöhte Skalierung – Für die größten Bereitstellungen gelten mehrere Erhöhungen der unterstützten Skalierung. Details zu den Skalierungsänderungen finden Sie im VMware-Tool für die Konfiguration von Maximalwerten.

Lizenzierung

• Lizenzerzwingung – NSX-T stellt nun sicher, dass Benutzer lizenzkonform sind, indem der Zugriff auf Funktionen basierend auf der Lizenzedition eingeschränkt wird. Neue Benutzer können nur auf die Funktionen zugreifen, die in der von ihnen erworbenen Edition verfügbar sind. Bestehende Benutzer, die Funktionen verwendet haben, die nicht in ihrer Lizenzedition enthalten sind, können Objekte jetzt nur noch anzeigen. Das Erstellen und Bearbeiten ist nicht mehr zulässig.

• Neue Lizenzen – Unterstützung für das neue VMware NSX Gateway-Firewall- und NSX-Verbund-Add-On wurde hinzugefügt, wodurch NSX Data Center-Lizenzen (Standard, Professional, Advanced, Enterprise Plus, Remote Office Branch Office) weiterhin unterstützt werden, die im Juni 2018 eingeführt wurden, sowie frühere VMware NSX for vSphere-Lizenzschlüssel. Weitere Informationen zu NSX-Lizenzen finden Sie im VMware-Knowledgebase-Artikel 52462.

Migration von NSX Data Center for vSphere zu NSX-T Data Center

• Migration für VMware Integrated OpenStack – Die Möglichkeit wurde hinzugefügt, eine Migration von NSX for vSphere zu NSX-T in VIO-Umgebungen durchzuführen, ohne die OpenStack-Darstellung der Objekte zu unterbrechen. Diese Funktion erfordert die Unterstützung von Migrationsfunktionen durch die verwendete VMware Integrated OpenStack-Version.

• Bring Your Own Topology – Das Modell des Migrationskoordinators wurde erweitert, um die Migration zwischen NSX for vSphere und einer benutzerdefinierten Topologie in NSX-T zu ermöglichen. Dies bietet Benutzern mehr Flexibilität beim Definieren ihrer NSX-T-Topologie und erweitert die Anzahl der Topologien, die von NSX for vSphere zu NSX-T migriert werden können.

  Diese Funktion kann nur für die Konfigurationsmigration verwendet werden, um eine Lift and Shift-Migration zu aktivieren oder als Teil des gesamten Workflows für eine direkte Migration.

• Unterstützung der OSPF-Migration für feste Topologien – Der Migrationskoordinator unterstützt feste Topologien mit OSPF (statt BGP und statisch). Dies bietet Benutzern die Möglichkeit, feste Topologien (statt BYOT) zu verwenden, wenn sie OSP für die horizontale Konnektivität zwischen ESG und Top-of-Rack konfiguriert haben (OSPF zwischen ESG und DLR wurde bereits unterstützt und durch internes NSX-T-Routing ersetzt).

• Größere Skalierung für den Migrationskoordinator – Die Skalierung des Migrationskoordinators wurde vergrößert, um größere Umgebungen abzudecken und näher an die maximale Skalierung von NSX for vSphere heranzukommen.

• Migration der Guest Introspection – Die Migration von GI von NSX for vSphere zu NSX-T wurde jetzt zum Migrationskoordinator hinzugefügt. Sie können diese Funktion nutzen, sofern auch der Partneranbieter den Migrationskoordinator unterstützt.

• IDFW/RDSH-Migration – Der Migrationskoordinator unterstützt jetzt identitätsbasierte Firewall-Konfigurationen.

Tech Preview-Funktionen

NSX-T Data Center 3.2 bietet diverse Tech Preview-Funktionen. Tech Preview-Funktionen werden von VMware nicht für Produktionszwecke unterstützt. Sie sind nicht vollständig getestet und einige Funktionen funktionieren möglicherweise nicht wie erwartet. Diese Tech Preview-Funktionen helfen VMware jedoch, die aktuelle NSX-T-Funktionalität zu verbessern und zukünftige Verbesserungen zu entwickeln.

Weitere Informationen zu diesen Tech Preview-Funktionen finden Sie in der verfügbaren Dokumentation im Administratorhandbuch zu NSX-T Data Center 3.2. Die folgende Liste enthält Links, die zu kurzen Beschreibungen dieser Tech Preview-Funktionen führen. Die betroffenen Themen werden im Titel als Tech Preview gekennzeichnet.

Inklusive Terminologie

VMware legt Wert auf Inklusion und Vielfalt. Um diese Prinzipien bei unseren Kunden, Partnern und in internen Communitys zu fördern, bemühen wir uns im gesamten Unternehmen, eine nicht inklusive Sprache in unseren Produkten zu ersetzen. Problematische Terminologie auf der Benutzeroberfläche, in der Dokumentation, den APIs, CLIs und Protokollen von NSX-T Data Center wird derzeit durch inklusivere Alternativen ersetzt. So haben wir beispielsweise den nicht inklusiven Begriff disabled (deaktiviert/behindert) durch die Alternative deactivated (deaktiviert) ersetzt.

Kompatibilität und Systemvoraussetzungen

Informationen zur Kompatibilität und zu den Systemvoraussetzungen finden Sie in den VMware-Produktinteroperabilitätsmatrizen und im Installationshandbuch für NSX-T Data Center.

Veraltete Funktionen/APIs und Änderungen des Verhaltens

• Ankündigung der Abkündigung für NSX Manager-APIs und erweiterte NSX-Benutzeroberflächen
• Ankündigung der Abkündigung des N-VDS NSX-T Host-Switches
• OpenStack und KVM
• Ankündigung der Abkündigung für NSX-T Load Balancing-APIs
• Alarme
• Abkündigung und Änderung der Live-Datenverkehrsanalyse-API
• Veraltete APIs und Änderungen des Verhaltens

Ankündigung der Abkündigung für NSX Manager-APIs und erweiterte NSX-Benutzeroberflächen

NSX-T bietet zwei Methoden für das Konfigurieren logischer Netzwerke und der Sicherheit: Manager-Modus und Richtlinienmodus. Die Manager-API enthält URIs, die mit /api beginnen, und die Richtlinien-API enthält URIs, die mit /policy/api beginnen.

Bitte beachten Sie, dass VMware beabsichtigt, die Unterstützung für die NSX-T Manager-APIs und die erweiterten NSX-Benutzeroberflächen in einer kommenden Haupt- oder Nebenversion von NSX-T zu entfernen. Diese Version wird frühestens ein Jahr nach dem Datum dieser Meldung, am 16.12.2021, allgemein verfügbar sein. NSX-T Manager-APIs, deren Entfernung geplant wurde, werden im NSX Data Center API-Handbuch als „veraltet“ gekennzeichnet und durch Anleitungen für Ersatz-APIs ergänzt.

Für neue NSX-T-Bereitstellungen wird empfohlen, die Vorteile der NSX-Richtlinien-APIs und NSX-Richtlinien-Benutzeroberflächen zu nutzen. Informationen zur Umstellung von Bereitstellungen, die derzeit NSX Manager-APIs und erweiterte NSX-Benutzeroberflächen nutzen, finden Sie in NSX Manager auf der Seite Hochstufung von Manager- zu Richtlinienobjekten und im NSX Data Center API-Handbuch.

Ankündigung der Abkündigung des N-VDS NSX-T Host-Switches

NSX-T 3.0.0 und höher kann auf dem vSphere VDS-Switch Version 7.0 und höher ausgeführt werden. Dies ermöglicht eine engere Integration mit vSphere und eine einfachere NSX-T-Adoption für Kunden, die NSX-T zu ihrer vSphere-Umgebung hinzufügen.

Bitte beachten Sie, dass VMware beabsichtigt, die Unterstützung für den virtuellen Switch NSX-T N-VDS auf ESXi-Hosts in einer kommenden NSX-T-Version zu entfernen. Diese wird frühestens ein Jahr nach dem Datum dieser Meldung (17. April 2021), allgemein verfügbar sein. N-VDS bleibt der unterstützte virtuelle Switch auf KVM, NSX-T Edge-Knoten, nativen NSX-Agenten der Public Cloud und Bare-Metal-Arbeitslasten.

Es wird empfohlen, dass neue Bereitstellungen von NSX-T und vSphere die Vorteile dieser engen Integration nutzen und mit VDS-Switch Version 7.0 und höher bereitgestellt werden. Darüber hinaus empfiehlt VMware für bestehende Bereitstellungen von NSX-T, die den N-VDS auf ESXi-Hosts verwenden, auf die Verwendung von NSX-T auf VDS umzustellen. Um diesen Vorgang zu vereinfachen, hat VMware sowohl ein CLI-basiertes Switch-Migrationstool, das erstmals in NSX-T 3.0.2 zur Verfügung gestellt wurde, als auch ein GUI-basiertes Upgrade Readiness Tool, das erstmals in NSX-T 3.1.1 zur Verfügung gestellt wurde, bereitgestellt (weitere Details zu diesen Tools finden Sie in der NSX-Dokumentation).

Hinweis:

In NSX-T 3.2.0 ist das Tool für die Migration von N-VDS zu VDS nicht verfügbar. Kunden, die ihre Arbeitslasten in dieser Version von N-VDS zu VDS migrieren möchten, können hierzu die Arbeitslasten manuell migrieren.

Folgende Überlegungen zu Bereitstellungen werden für die Umstellung von N-VDS auf VDS empfohlen:

• Die N-VDS- und VDS-APIs sind unterschiedlich, und die Sicherungstypen für VM- und vmKernel-Schnittstellen-APIs für die N-VDS- und VDS-Switches sind ebenfalls unterschiedlich. Wenn Sie auf die Verwendung von VDS in Ihrer Umgebung umstellen, müssen Sie statt der N-VDS-APIs die VDS-APIs aufrufen. Diese Änderung muss vor der Umstellung von N-VDS auf VDS durchgeführt werden. Weitere Details finden Sie im Knowledgebase-Artikel 79872. Hinweis: Es gibt keine Änderungen der APIs für N-VDS oder VDS.

• VDS wird über vCenter konfiguriert. N-VDS ist unabhängig von vCenter. Mit NSX-T-Unterstützung für VDS und der eventuellen Abkündigung von N-VDS wird NSX-T eng mit vCenter verbunden, und vCenter wird erforderlich sein, um NSX in vSphere-Umgebungen zu aktivieren.

OpenStack und KVM

Die Versionen der Serie 3.x sind die letzten, die KVM- und Nicht-VIO-OpenStack-Distributionen unterstützen. Dazu gehören, ohne darauf beschränkt zu sein: die RedHat OpenStack-Plattform, Canonical/Ubuntu OpenStack, SUSE OpenStack Cloud, Mirantis OpenStack und das Community-basierte OpenStack, das keinen spezifischen Anbieter hat. Kunden, die Nicht-VIO OpenStack mit NSX verwenden, sollten für ihre Bereitstellungen vRealize Automation oder VMware Cloud Director als Ersatz in Betracht ziehen.

Ankündigung der Abkündigung für NSX-T Load Balancing-APIs

NSX-T Load Balancer-APIs werden dann als veraltet markiert. Dies gilt für alle APIs, die URIs enthalten, die beginnen mit /policy/api/v1/infra/lb-

Bitte beachten Sie, dass VMware beabsichtigt, die Unterstützung für den NSX-T Load Balancer in einer kommenden NSX-T-Version zu entfernen. Diese wird frühestens ein Jahr nach dem Datum dieser Meldung (16. Dezember 2021), allgemein verfügbar sein. NSX-T Manager-APIs, deren Entfernung geplant wurde, werden im NSX Data Center API-Handbuch als „veraltet“ gekennzeichnet.

Es wird empfohlen, für neue Bereitstellungen mit NSX-T Data Center die Vorteile von VMware NSX Advanced Load Balancer (Avi) in der Version v20.1.6 oder höher zu nutzen.

Hinweis:

Die API-Abkündigung gilt nicht für den Distributed Load Balancer.

Alarme

• NSX Intelligence-Kommunikationsalarme wurden durch NSX Application Platform-Kommunikationsalarme ersetzt.

• NSX Intelligence-Integritätsalarme wurden durch NSX Application Platform-Integritätsalarme ersetzt.

• DNS – Alarm für Weiterleitung deaktiviert.

• Infrastrukturdienst – Der Alarm „Status des Edge-Diensts nicht verfügbar“ wird als Teil des Alarms zur Statusänderung des Edge-Diensts behandelt.

• Transportknotenintegrität – Der Alarm „NVDS-Uplink inaktiv“ wurde durch den Alarm „Transportknoten-Uplink inaktiv“ ersetzt.

Abkündigung und Änderung der Live-Datenverkehrsanalyse-API

• MP-APIs für die Live-Datenverkehrsanalyse wurden in NSX-T 3.2.0 als veraltet markiert.

• Die Option „Paketanzahl“ wurde in NSX-T 3.2.0 aus der Live-Datenverkehrsanalyse entfernt. Die Live-Datenverkehrsanalyse unterstützt weiterhin Nachverfolgung und Paketerfassung.

• Folgende Felder und Typen werden entfernt:

  • Richtlinien-API: Felder – count_config , Typen – PolicyCountObservation

  • MP-API: Felder – count_config, count_results, Typen – CountActionConfig, LiveTraceActionType (COUNT: Eine nicht unterstützte Aktion), CountActionArgument, CountResult, CountObservation, BaseCountObservation

Veraltete APIs und Änderungen des Verhaltens

• Entfernung veralteter NSX-APIs – Die folgenden APIs sind seit über einem Jahr veraltet und wurden aus NSX-T 3.2.0 entfernt.

  Entfernte API	Ersatz
  GET api/v1/hpm/alarms	Ersetzt durch /api/v1/alarms
  POST /fabric/nodes	POST /api/v1/transport-nodes
  POST /fabric/nodes/<node-id>?action=restart_inventory_sync	POST /api/v1/transport-nodes/<node-id>?action=restart_inventory_sync
  POST /api/v1/fabric/discovered-nodes/<node-ext-id>?action=hostprep	POST /api/v1/fabric/discovered-nodes/<node-ext-id>?action=create_transport_node
  GET /fabric/nodes	GET /api/v1/transport-nodes
  GET /fabric/nodes/<node-id>	GET /api/v1/transport-nodes/<node-id>
  POST /fabric/nodes/<node-id>	POST /api/v1/transport-nodes/<node-id>
  PUT /fabric/nodes/<node-id>	PUT /api/v1/transport-nodes/<node-id>
  DELETE /fabric/nodes/<node-id>	DELETE /api/v1/transport-nodes/<node-id>
  GET /fabric/nodes/<node-id>/status	GET /api/v1/transport-nodes/<node-id>/status
  GET /fabric/nodes/status	GET /api/v1/transport-nodes/<node-id>/status
  GET /fabric/nodes/<node-id>/capabilities	GET /api/v1/transport-nodes/<node-id>/capabilities
  POST /fabric/nodes/<node-id>?action=<enter/exit>_maintenance_mode	Kein Ersatz in der NSX-T-API.
  GET /fabric/nodes/<node-id>/state	GET /api/v1/transport-nodes/<node-id>/state
  GET /fabric/nodes/<node-id>/modules	GET /api/v1/transport-nodes/<node-id>/modules
  POST /fabric/nodes/<node-id>?action=upgrade_infra	Kein Ersatz in der NSX-T-API.
  GET /fabric/nodes/<node-id>/network/interfaces	GET /api/v1/transport-nodes/<node-id>/interfaces
  GET /fabric/nodes/<node-id>/network/interfaces/<interface-id>	GET /api/v1/transport-nodes/<node-id>/interfaces/<interface-id>
  GET /fabric/compute-collection-fabric-templates	Workflows werden mithilfe von Transportknotenprofil(TNP)-API und Transportknotensammlungs(TNC)-API unterschiedlich behandelt
  POST /fabric/compute-collection-fabric-templates	Workflows werden mithilfe von Transportknotenprofil(TNP)-API und Transportknotensammlungs(TNC)-API unterschiedlich behandelt
  DELETE /fabric/compute-collection-fabric-templates/<fabric-template-id>	Workflows werden mithilfe von Transportknotenprofil(TNP)-API und Transportknotensammlungs(TNC)-API unterschiedlich behandelt
  PUT /fabric/compute-collection-fabric-templates/<fabric-template-id>	Workflows werden mithilfe von Transportknotenprofil(TNP)-API und Transportknotensammlungs(TNC)-API unterschiedlich behandelt
  GET /fabric/compute-collection-fabric-templates/<fabric-template-id>	Workflows werden mithilfe von Transportknotenprofil(TNP)-API und Transportknotensammlungs(TNC)-API unterschiedlich behandelt
  GET /fabric/compute-collection-transport-node-templates	Workflows werden mithilfe von Transportknotenprofil(TNP)-API und Transportknotensammlungs(TNC)-API unterschiedlich behandelt
  POST /fabric/compute-collection-transport-node-templates	Workflows werden mithilfe von Transportknotenprofil(TNP)-API und Transportknotensammlungs(TNC)-API unterschiedlich behandelt
  DELETE /fabric/compute-collection-transport-node-templates/<transport-node-template-id>	Workflows werden mithilfe von Transportknotenprofil(TNP)-API und Transportknotensammlungs(TNC)-API unterschiedlich behandelt
  PUT /fabric/compute-collection-transport-node-templates/<transport-node-template-id>	Workflows werden mithilfe von Transportknotenprofil(TNP)-API und Transportknotensammlungs(TNC)-API unterschiedlich behandelt
  GET /fabric/compute-collection-transport-node-templates/<transport-node-template-id>	Workflows werden mithilfe von Transportknotenprofil(TNP)-API und Transportknotensammlungs(TNC)-API unterschiedlich behandelt
  GET /api/v1/ipfix-obs-points/switch-global	Verwenden Sie /api/v1/ipfix-profiles/<ipfix-profile-id> für das Switch-IPFIX-Profil und /api/v1/ipfix-collector-profiles/<ipfix-collector-profile-id> für das IPFIX-Collector-Profil.
  PUT /api/v1/ipfix-obs-points/switch-global	Verwenden Sie /api/v1/ipfix-profiles/<ipfix-profile-id> für das Switch-IPFIX-Profil und /api/v1/ipfix-collector-profiles/<ipfix-collector-profile-id> für das IPFIX-Collector-Profil.
  GET /api/v1/ipfix-obs-points	Verwenden Sie /api/v1/ipfix-profiles für das Switch-IPFIX-Profil und /api/v1/ipfix-collector-profiles für das IPFIX-Collector-Profil
  GET /infra/ipfix-collector-profiles	GET /policy/api/v1/infra/ipfix-l2-collector-profiles
  GET /infra/ipfix-collector-profiles/<ipfix-collector-profile-id>	GET /policy/api/v1/infra/ipfix-l2-collector-profiles/<ipfix-collector-profile-id>
  PUT /infra/ipfix-collector-profiles/<ipfix-collector-profile-id>	PUT /policy/api/v1/infra/ipfix-l2-collector-profiles/<ipfix-collector-profile-id>
  PATCH /infra/ipfix-collector-profiles/<ipfix-collector-profile-id>	PATCH /policy/api/v1/infra/ipfix-l2-collector-profiles/<ipfix-collector-profile-id>
  DELETE /infra/ipfix-collector-profiles/<ipfix-collector-profile-id>	DELETE /policy/api/v1/infra/ipfix-l2-collector-profiles/<ipfix-collector-profile-id>
  GET /infra/tier-1s/<tier-1-id>/ipfix-switch-collection-instances	GET /policy/api/v1/infra/ipfix-l2-profiles
  GET /infra/tier-1s/<tier-1-id>/ipfix-switch-collection-instances/<ipfix-switch-collection-instance-id>	GET /policy/api/v1/infra/ipfix-l2-profiles/<ipfix-switch-collection-instance-id>
  PUT /infra/tier-1s/<tier-1-id>/ipfix-switch-collection-instances/<ipfix-switch-collection-instance-id>	PUT /policy/api/v1/infra/ipfix-l2-profiles/<ipfix-switch-collection-instance-id>
  PATCH /infra/tier-1s/<tier-1-id>/ipfix-switch-collection-instances/<ipfix-switch-collection-instance-id>	PATCH /policy/api/v1/infra/ipfix-l2-profiles/<ipfix-switch-collection-instance-id>
  DELETE /infra/tier-1s/<tier-1-id>/ipfix-switch-collection-instances/<ipfix-switch-collection-instance-id>	DELETE /policy/api/v1/infra/ipfix-l2-profiles/<ipfix-switch-collection-instance-id>
  GET /api/v1/node/services/mgmt-plane-bus	Die API wurde nach Änderungen der internen Architektur aus NSX-T entfernt
  POST /api/v1/node/services/mgmt-plane-bus?action=restart|start|stop	Die API wurde nach Änderungen der internen Architektur aus NSX-T entfernt
  GET /api/v1/node/services/mgmt-plane-bus/status	Die API wurde nach Änderungen der internen Architektur aus NSX-T entfernt
  DELETE /api/v1/node/rabbitmq-management-port	Die API wurde nach Änderungen der internen Architektur aus NSX-T entfernt
  GET /api/v1/node/rabbitmq-management-port	Die API wurde nach Änderungen der internen Architektur aus NSX-T entfernt
  POST /api/v1/node/rabbitmq-management-port	Die API wurde nach Änderungen der internen Architektur aus NSX-T entfernt
  GET /api/v1/node/services/intelligence-upgrade-coordinator	Die API wurde aus NSX-T Manager entfernt, da NSX Intelligence jetzt auf der NSX Application Platform gehostet wird
  POST /api/v1/node/services/intelligence-upgrade-coordinator?action=start|stop|restart	Die API wurde aus NSX-T Manager entfernt, da NSX Intelligence jetzt auf der NSX Application Platform gehostet wird
  GET /api/v1/node/services/intelligence-upgrade-coordinator/status	Die API wurde aus NSX-T Manager entfernt, da NSX Intelligence jetzt auf der NSX Application Platform gehostet wird
  GET /api/v1/bridge-clusters	Diese APIs wurden zum Konfigurieren der Bridge auf ESXi verwendet, wobei es sich um eine veraltete und entfernte Funktion handelt. Bridging wird unterstützt und Edge-Cluster können auf dem Segment mit Edge-Bridge-Profilen konfiguriert werden. (Weitere Informationen finden Sie in der Edge-Bridge-Dokumentation.)
  POST /api/v1/bridge-clusters	Diese APIs wurden zum Konfigurieren der Bridge auf ESXi verwendet, wobei es sich um eine veraltete und entfernte Funktion handelt. Bridging wird unterstützt und Edge-Cluster können auf dem Segment mit Edge-Bridge-Profilen konfiguriert werden. (Weitere Informationen finden Sie in der Edge-Bridge-Dokumentation.)

• Veraltete NSX-API-Felder entfernt – Folgende API-Felder sind seit über einem Jahr veraltet und wurden in NSX-T 3.2.0 entfernt. (Die API selbst wurde nicht entfernt, nur das genannte Feld.)

  • Transportzonen-API-Feld entfernt:

    POST /api/v1/transport-zones
    {
         "display_name":"tz1",
         "host_switch_name":"test-host-switch-1", <<==== WILL BE REMOVED
         "host_switch_mode":  "STANDARD", <<==== WILL BE REMOVED
         "description":"Transport Zone 1",
         "transport_type":"OVERLAY"
    } 

  • Transportknoten-API-Feld für Edge-Knoten-VM entfernt:

    POST /api/v1/transport-nodes
    POST /api/v1/transport-node-profiles
    {
    "node_id": "92f893b0-1157-4926-9ce3-a1787100426c",
    "host_switch_spec": {
    "host_switches": [
    {
    ...
    ...
    "transport_zone_endpoints": [ <<<==== SHOULD BE USED INSTEAD
    {
    "transport_zone_id": "1b3a2f36-bfd1-443e-a0f6-4de01abc963e"
    }
    ],
    }
    ],
    "resource_type": "StandardHostSwitchSpec"
    },
    "transport_zone_endpoints": [], <<<<=== WILL BE REMOVED
    "node_deployment_info": {
    "deployment_type": "VIRTUAL_MACHINE",
    "deployment_config": {
    "vm_deployment_config": {
    "vc_id": "23eaf46e-d826-4ead-9aad-ed067574efb7",
    "compute_id": "domain-c7",
    "storage_id": "datastore-22",
    "management_network_id": "network-24",
    "hostname": "edge", <-- will be removed
    "data_network_ids": [
    "network-24"
    ],
    "search_domains": [ "vmware.com" ] <<<<=== WILL BE REMOVED (replacement in out block)
    "dns_servers": [ "10.172.40.1" ], <<<<=== WILL BE REMOVED
    "enable_ssh": true, <<<<=== WILL BE REMOVED
    "allow_ssh_root_login": true, <<<<=== WILL BE REMOVED
    "placement_type": "VsphereDeploymentConfig"
    },
    ...
    "node_settings": {
    "hostname": "edge", <<<<=== This should be used - REPLACEMENT
    "search_domains": ["eng.vmware.com" ], <<<<=== This should be used - REPLACEMENT
    "dns_servers": [ "10.195.12.31"], <<<<=== This should be used - REPLACEMENT
    "enable_ssh": true, <<<<=== This should be used - REPLACEMENT
    "allow_ssh_root_login": true <<<<=== This should be used - REPLACEMENT
    },
    "resource_type": "EdgeNode",
    "id": "90ec1776-f3e2-4bd0-ba1f-a1292cc58707",
    ...
    "display_name": "edge", <<<<=== WILL BE REMOVED (replacement in out block)
    "_create_user": "admin", <<<<=== WILL BE REMOVED
    "_create_time": 1594956232211, <<<<=== WILL BE REMOVED
    "_last_modified_user": "admin", <<<<=== WILL BE REMOVED
    "_last_modified_time": 1594956531314, <<<<=== WILL BE REMOVED
    "_system_owned": false, <<<<=== WILL BE REMOVED
    "_protection": "NOT_PROTECTED", <<<<=== WILL BE REMOVED
    "_revision": 2 <<<<=== WILL BE REMOVED
    },
    "failure_domain_id": "4fc1e3b0-1cd4-4339-86c8-f76baddbaafb",
    "resource_type": "TransportNode",
    "id": "90ec1776-f3e2-4bd0-ba1f-a1292cc58707",
    "display_name": "edge", <<<<=== This should be used - REPLACEMENT
    "_create_user": "admin", <<<<=== This should be used - REPLACEMENT
    "_create_time": 1594956232373, <<<<=== This should be used - REPLACEMENT
    "_last_modified_user": "admin", <<<<=== This should be used - REPLACEMENT
    "_last_modified_time": 1594956531551, <<<<=== This should be used - REPLACEMENT
    "_system_owned": false, <<<<=== This should be used - REPLACEMENT
    "_protection": "NOT_PROTECTED", <<<<=== This should be used - REPLACEMENT
    "_revision": 1 <<<<=== This should be used - REPLACEMENT
    }

Upgrade-Hinweise für diese Version

Anweisungen zum Upgrade der NSX-T Data Center-Komponenten finden Sie im Upgrade-Handbuch für NSX-T Data Center.

Kunden, die ein Upgrade auf NSX-T 3.2.0.1 durchführen, wird dringend empfohlen, das NSX Upgrade Evaluation Tool auszuführen, bevor Sie den Upgrade-Vorgang starten. Das Tool wurde entwickelt, um den Erfolg sicherzustellen, indem die Integrität und Bereitschaft Ihrer NSX Manager vor dem Upgrade überprüft werden.

API und CLI-Ressourcen

Informationen zur Verwendung der NSX-T Data Center-APIs oder -CLIs für die Automation finden Sie unter developer.vmware.com.

Die API-Dokumentation ist über die Registerkarte API-Referenz verfügbar. Die CLI-Dokumentation ist über die Registerkarte Dokumentation verfügbar.

Verfügbare Sprachen

NSX-T Data Center wurde in mehrere Sprachen lokalisiert: Englisch, Deutsch, Französisch, Italienisch, Japanisch, vereinfachtes Chinesisch, Koreanisch, traditionelles Chinesisch und Spanisch. Da die NSX-T Data Center-Lokalisierung die Browser-Spracheinstellungen verwendet, müssen Sie sicherstellen, dass Ihre Einstellungen mit der gewünschten Sprache übereinstimmen.

Revisionsverlauf der Dokumente

Revisionsdatum	Edition	Änderungen
16. Dezember 2021	1	Erstedition.
3. Januar 2022	2	Im Abschnitt „Verbund“ wurde unter „Neuigkeiten“ ein Hinweis hinzugefügt. Bekanntes Problem 2882574 wurde hinzugefügt.
5. Januar 2022	3	In den Upgrade-Hinweisen für diese Version und in den Abschnitten „Bekannte Probleme“ wurde das bekannte Problem hinzugefügt.
21. Januar 2022	4	Der Abschnitt Wichtige Information über NSX-T Data Center 3.2.0 wurde hinzugefügt. Informationen zum NSX-Upgrade Evaluation Tool wurden im Abschnitt Upgrade-Hinweise für diese Version hinzugefügt. Bekanntes Problem 2890348 wurde hinzugefügt.
4. Februar 2022	5	Unterstützung der identitätsbasierten Firewall für das SMB-Protokoll.
15. Februar 2022	6	Aufzählungspunkt zu Kapazitätsgrenzwerten in Neuheiten hinzugefügt.
22. Februar 2022	7	Anforderung für die Bereitstellung der NSX Application Platform hinzugefügt.
29. April 2022	8	Die bekannten Probleme 2885820, 2871440 und 2945515 wurden hinzugefügt. Doppelte Einträge für die bekannten Probleme 2685550, 2566121 und 2848614 wurden entfernt.
5. Mai 2022	9	Die bekannten Probleme 2875563, 2875667, 2883505, 2914934, 2921704 und 2933905 wurden hinzugefügt.
16. Mai 2022	10	Bekanntes Problem 2927442 wurde hinzugefügt.
6. Juni 2022	11	Bekanntes Problem 2937810 wurde hinzugefügt.
2. August 2022	12	Bekanntes Problem 2989696 wurde hinzugefügt.
24. August 2022	13	Bekanntes Problem 3015843 wurde hinzugefügt.
1. September 2022.	14	Die Informationen zum Speicherort für die VMware NSX Network Detection and Response-Dokumentation wurden aktualisiert.
7. September 2022.	15	Bekanntes Problem 3012313 wurde hinzugefügt.
14. September 2022.	16	Bekanntes Problem 3025104 wurde hinzugefügt.
6. Februar 2023	17	In Neuheiten wurde ein Aufzählungspunkt über zusätzliche Funktionen für Distributed Load Balancer für vSphere hinzugefügt.
23. Februar 2023	18	Redaktionelle Aktualisierung.

Behobene Probleme

• Behobenes Problem 2692344: Wenn Sie den Avi Enforcement Point löschen, löscht er alle realisierten Elemente aus der Richtlinie, wodurch alle realisierten Entitäten des standardmäßigen Objekts aus der Richtlinie gelöscht werden. Durch das Hinzufügen eines neuen Enforcement Point kann das Standardobjekt nicht erneut vom Avi-Controller synchronisiert werden.

  Sie sind nicht in der Lage, die Systemstandardobjekte nach dem Löschen und der Neuerstellung des Enforcement Point von AVIConnectionInfo zu verwenden.

• Behobenes Problem 2858893: Bereinigung der Dienstbereitstellung schlägt für clusterbasierte Bereitstellung fehl.

  Keine funktionalen Auswirkungen. Fehler beim Bereinigen des Diensts, wenn versucht wird, die Registrierung von ServiceDefinion mit nicht zugeordneter ServiceDeployment oder -Instanzen aufzuheben. Bereinigung von db muss manuell/erzwungen erfolgen.

• Behobenes Problem 2557287: Die nach der Sicherung durchgeführten TNP-Updates werden nicht wiederhergestellt.

  Nach der Sicherung auf einer wiederhergestellten Appliance werden keine TNP-Updates angezeigt.

• Behobenes Problem 2679614: Wenn das API-Zertifikat auf dem lokalen Manager ausgetauscht wird, wird in der Benutzeroberfläche des globalen Managers die Meldung „Es ist ein allgemeiner Fehler aufgetreten.“ angezeigt.

  Wenn das API-Zertifikat auf dem lokalen Manager ausgetauscht wird, wird in der Benutzeroberfläche des globalen Managers die Meldung „Es ist ein allgemeiner Fehler aufgetreten.“ angezeigt.

• Behobenes Problem 2658687: Die Switchover-API des globalen Managers meldet einen Fehler, wenn die Transaktion fehlschlägt, der Failover findet aber statt.

  Die API schlägt fehl, der Switchover des globalen Managers wird jedoch abgeschlossen.

• Behobenes Problem 2652418: Langsamer Löschvorgang, wenn eine große Anzahl von Entitäten gelöscht wird.

  Das Löschen verläuft langsamer.

• Behobenes Problem 2649499: Das Erstellen einer Firewallregel dauert lange, wenn nacheinander einzelne Regeln erstellt werden.

  Die langsame API benötigt mehr Zeit, um Regeln zu erstellen.

• Behobenes Problem 2649240: Das Löschen verläuft langsam, wenn eine große Anzahl von Entitäten mithilfe einzelner DELETE-APIs gelöscht wird.

  Es dauert ausgesprochen lange, bis der Löschvorgang abgeschlossen ist.

• Behobenes Problem 2606452: Das Onboarding über die API wird blockiert.

  Die Onboarding-API schlägt mit der Fehlermeldung „Standardtransportzone auf Site nicht gefunden“ fehl.

• Behobenes Problem 2587513: Richtlinie zeigt einen Fehler an, wenn mehrere VLAN-Bereiche in einer Bridge-Profilbindung konfiguriert sind.

  Sie sehen die Fehlermeldung „UNGÜLTIGE VLAN-IDs“.

• Behobenes Problem 2662225: Wenn der aktive Edge-Knoten während der Ausführung eines S-N-Datenverkehrsstroms deaktiviert wird, kommt es zum Datenverkehrsverlust.

  Der aktuelle S-N-Datenverkehrsstrom wird auf dem aktiven Multicast-Knoten ausgeführt. Die bevorzugte Route von TOR zur Quelle sollte nur über den aktiven Multicast-Edge-Knoten verlaufen. Durch Einführung eines weiteren Edge kann der aktive Multicast-Knoten übernommen werden (Edge mit niedriger Rangfolge ist der aktive Multicast-Knoten). Beim aktuellen S-N-Datenverkehr kommt es zu einem Datenverkehrsverlust von bis zu vier Minuten. Dies wirkt sich nicht auf den neuen Datenverkehrsstrom aus oder auf den aktuellen Datenverkehrsstrom, wenn dieser angehalten und neu gestartet wird.

• Behobenes Problem 2625009: Inter-SR iBGP-Sitzungen flattern weiter, wenn zwischengeschaltete Router oder physische NICs eine niedrigere oder gleiche MTU als der Inter-SR-Port haben.

  Dies kann sich auf die standortübergreifende Konnektivität in Verbundstopologien auswirken.

• Behobenes Problem 2521230: Der für „get bgp neighbor summary“ angezeigte BFD-Status zeigt den aktuellen Status der BFD-Sitzung möglicherweise nicht richtig an.

  BGP und BFD können ihre Sitzung unabhängig einrichten. Im Rahmen von „get bgp neighbor summary“ zeigt BGP auch den BFD-Status an. Wenn das BGP ausgefallen ist, werden keine BFD-Benachrichtigungen verarbeitet und somit weiterhin der letzte bekannte Zustand angezeigt. Dies kann dazu führen, dass für BFD der veraltete Status angezeigt wird.

• Behobenes Problem 2550492: Während eines Upgrades wird vorübergehend die Meldung „Die Anmeldedaten waren falsch oder das angegebene Konto wurde gesperrt“ angezeigt und das System wird automatisch wiederhergestellt.

  Vorübergehende Fehlermeldung während des Upgrades.

• Behobenes Problem 2682480: Möglicher Fehlalarm für den Systemzustand von NCP.

  Der Alarm für den Systemzustand von NCP kann in dem Sinne unzuverlässig sein, dass er ausgelöst wird, wenn das NCP-System fehlerfrei ist.

• Behobenes Problem 2655539: Hostnamen werden auf der Seite „Standort-Manager“ der Benutzeroberfläche des globalen Managers nicht aktualisiert, wenn die Hostnamen mithilfe der Befehlszeilenschnittstelle aktualisiert werden.

  Der alte Hostname wird angezeigt.

• Behobenes Problem 2631703: Beim Sichern/Wiederherstellen einer Appliance mit vIDM-Integration wird die vIDM-Konfiguration beschädigt.

  Wenn eine Umgebung aktualisiert und/oder wiederhergestellt wurde, führt der Versuch, eine Appliance wiederherzustellen, in der die vIDM-Integration ausgeführt wird, zur Beschädigung der Integration, die Sie anschließend neu konfigurieren müssen.

• Behobenes Problem 2730109: Wenn Edge eingeschaltet wird, versucht Edge, eine OSPF-Nachbarschaft mit dem Peer unter Verwendung seiner Routerlink-IP-Adresse als OSPF-RouterID zu erstellen, obwohl ein Loopback vorhanden ist.

  Nach dem erneuten Laden von Edge wählt OSPF die Downlink-IP-Adresse (die höhere IP-Adresse) als Router-ID aus, bis die OSPF-Router-ID-Konfiguration aufgrund der Reihenfolge der Konfigurationssequenzierung empfangen wird. Der Nachbareintrag mit älterer Router-ID wird schließlich zu einem veralteten Eintrag, wenn OSPF HELLO mit der neuen Router-ID empfangen wird, und läuft nach Ablauf des Dead-Timers auf dem Peer ab.

• Behobenes Problem 2610851: Beim Filtern von Namespaces, der Computing-Sammlung oder des L2VPN-Service-Rasters werden möglicherweise keine Daten zurückgegeben, wenn bestimmte Ressourcentypfilter kombiniert werden.

  Beim gleichzeitigen Anwenden mehrerer Filter werden für einige Ressourcentypen keine Ergebnisse zurückgegeben, auch wenn Daten mit übereinstimmenden Kriterien verfügbar sind. Dieses Szenario tritt nicht häufig auf und nur in diesen Rastern mit den folgenden Filterattribut-Kombinationen: Für „Namespaces-Raster ==> Filtern von Clustername und Seite „Netzwerktopologie“ ==> L2VPN-Service, wenn ein Remote-IP-Filter Computing-Sammlung == > Filtern von ComputeManager angewendet wird

• Behobenes Problem 2482580: Die IDFW/IDS-Konfiguration wird nicht aktualisiert, wenn ein IDFW/IDS-Cluster aus vCenter gelöscht wird.

  Wenn ein Cluster, auf dem IDFW/IDS aktiviert ist, aus vCenter gelöscht wird, wird die NSX-Verwaltungsebene nicht über die erforderlichen Updates informiert. Dadurch wird die Anzahl der Cluster, auf denen IDFW/IDS aktiviert ist, verfälscht. Es gibt keine funktionalen Auswirkungen. Lediglich die Anzahl der aktivierten Cluster ist falsch.

• Behobenes Problem 2587257: In einigen Fällen wird das PMTU-Paket, das von NSX-T Edge gesendet wird, beim Erhalt am Ziel ignoriert.

  Die PMTU-Ermittlung schlägt fehl, was zur Fragmentierung und zur erneuten Zusammenstellung sowie zu Paketverlust führt. Dies kann zu Leistungseinbußen oder Ausfall des Datenverkehrs führen.

• Behobenes Problem 2622576: Fehler aufgrund einer doppelten Konfiguration werden nicht ordnungsgemäß an den Benutzer weitergegeben.

  Während das Onboarding ausgeführt wird, wird eine Meldung zu einem Fehler beim Onboarding angezeigt.

• Behobenes Problem 2638673: SRIOV vNICs für VMs werden von der Bestandsliste nicht erkannt.

  SRIOV vNICs werden im Dialogfeld „Neue SPAN-Sitzung hinzufügen“ nicht aufgeführt. Es werden keine SRIOV vNICs angezeigt, wenn Sie eine neue SPAN-Sitzung hinzufügen.

• Behobenes Problem 2643749: Die Gruppe aus der benutzerdefinierten Region, die auf einer bestimmten Site erstellt wurde, kann nicht in eine Gruppe verschachtelt werden, die zu einer vom System erstellten sitespezifischen Region gehört.

  Die Gruppe wird nicht in der sitespezifischen benutzerdefinierten Region erstellt, wenn die untergeordnete Gruppe als Mitglied für die Gruppe in der vom System erstellten Region mit dem gleichen Standort auswählt wird.

• Behobenes Problem 2805986: NSX-T verwaltete Edge-VM kann nicht bereitgestellt werden.

  NSX-T Edge-Bereitstellung schlägt fehl, wenn ESX-Benutzeroberfläche verwendet wird.

• Behobenes Problem 2685550: Der Realisierungsstatus der FW-Regel wird bei der Anwendung auf überbrückte Segmente immer als „Wird durchgeführt“ angezeigt.

  Beim Anwenden von FW-Regeln auf eine NSGroup, zu deren Mitgliedern überbrückte Segmente gehören, wird der Realisierungsstatus immer als „Wird durchgeführt“ angezeigt. Sie können den Realisierungsstatus von FW-Regeln, die auf überbrückte Segmente angewendet werden, nicht überprüfen.

Bekannte Probleme

• Problem 3025104: Host zeigt den Status „Fehlgeschlagen“ an, wenn die Wiederherstellung für eine andere IP und denselben FQDN ausgeführt wurde.

  Wenn die Wiederherstellung unter Verwendung verschiedener IP-Adressen von MP-Knoten und mithilfe desselben FQDN ausgeführt wird, können Hosts keine Verbindung mit den MP-Knoten herstellen.

  Problemumgehung: Aktualisieren Sie den DNS-Cache für den Host. Verwenden Sie den Befehl „/etc/init.d/nscd restart“.

• Problem 3012313: Das Upgrade von NSX Malware-Schutz oder NSX Network Detection and Response von Version 3.2.0 auf NSX ATP 3.2.1 oder 3.2.1.1 schlägt fehl.

  Nachdem die NSX Application Platform erfolgreich von NSX 3.2.0 auf NSX ATP 3.2.1 oder 3.2.1.1 aktualisiert wurde, schlägt das Upgrade von NSX Malware-Schutz (Malware Protection, MP) oder NSX Network Detection and Response (NDR) mit einem oder mehreren der folgenden Symptome fehl.

  1. Im Fenster der Upgrade-Benutzeroberfläche wird ein Status FAILED für NSX NDR und die Cloud-Connector-Pods angezeigt.

  2. Bei einem NSX NDR-Upgrade befinden sich einige Pods mit dem Präfix nsx-ndr im Status ImagePullBackOff.

  3. Bei einem NSX MP-Upgrade befinden sich einige Pods mit dem Präfix cloud-connector im Status ImagePullBackOff.

  4. Das Upgrade schlägt fehl, nachdem Sie auf UPGRADE geklickt haben, aber die vorherigen NSX MP- und NSX NDR-Funktionen funktionieren immer noch genauso wie vor dem Start des Upgrades. Die NSX Application Platform kann jedoch instabil werden.

  Problemumgehung: Informationen hinzu finden Sie im VMware-Knowledgebase-Artikel 89418.

• Problem 2989696: Geplante Sicherungen können nach dem Wiederherstellungsvorgang von NSX Manager nicht gestartet werden.

  Geplante Sicherung generiert keine Sicherungen. Manuelle Sicherungen funktionieren weiterhin.

  Problemumgehung: Weitere Informationen hierzu finden Sie im Knowledgebase-Artikel 89059.

• Problem 3015843: Der Bezeichner des DFW-Paketprotokolls wurde in NSX-T 3.2.0 geändert und in den Versionshinweisen nicht erwähnt.

  Es können keine DFW-Paketprotokolle mit einem Protokollbezeichner aus früheren Versionen angezeigt werden.

  Die folgenden NSX-T Syslog-Felder wurden geändert, um der RFC-Konformität zu entsprechen:

  • FIREWALL_PKTLOG geändert in FIREWALL-PKTLOG

  • DLB_PKTLOG geändert in DLB-PKTLOG

  • IDPS_EVT geändert in IDPS-EVT

  • nsx_logger geändert in nsx-logger

  Da diese Änderungen zur Entsprechung der RFC-Konformität vorgenommen wurden, gibt es kein vorhersehbares Szenario zukünftiger NSX-Versionen, bei denen die Protokollstruktur zu einer aus früheren Versionen zurückgesetzt wird.

• Problem 2355113: Arbeitslast-VMs, auf denen RedHat und CentOS mit beschleunigten Netzwerkinstanzen in Azure ausgeführt werden, werden nicht unterstützt.

  Wenn in Azure das beschleunigte Netzwerk auf RedHat- oder auf CentOS-basierten Betriebssystemen mit installiertem NSX Agent aktiviert ist, erhält die Ethernet-Schnittstelle keine IP-Adresse.

  Problemumgehung: Deaktivieren Sie beschleunigte Netzwerke für RedHat- und CentOS-basierte Betriebssysteme.

• Problem 2283559: Die MP-APIs „/routing-table“ und „/forwarding-table“ geben einen Fehler zurück, wenn der Edge mehr als 65.000 Routen für RIB und mehr als 100.000 Routen für FIB aufweist.

  Wenn der Edge mehr als 65.000 Routen für RIB und mehr als 100.000 Routen für FIB aufweist, nimmt die Anforderung von MP an den Edge mehr als 10 Sekunden in Anspruch, und dies führt zu einer Zeitüberschreitung. Dies ist eine schreibgeschützte API und wirkt sich nur dann aus, wenn die mehr als 65.000 Routen für RIB und mehr als 100.000 Routen für FIB mithilfe der API/UI heruntergeladen werden müssen.

  Problemumgehung: Es gibt zwei Optionen zum Abrufen von RIB/FIB. Diese APIs unterstützen Filteroptionen, die auf Netzwerkpräfixen oder Routentypen beruhen. Verwenden Sie diese Optionen zum Herunterladen der gewünschten Routen. Wenn die gesamte RIB-/FIB-Tabelle erforderlich ist, ist eine CLI-Unterstützung erforderlich, und in diesem Fall tritt keine Zeitüberschreitung auf.

• Problem 2693576: Transportknoten zeigt „NSX-Installation fehlgeschlagen“ nach dem Upgrade von KVM RHEL 7.9 auf RHEL 8.2 an.

  Nach dem Upgrade von RHEL 7.9 auf 8.2 fehlen die Abhängigkeiten „nsx-opsagent“ und „nsx-cli“, und der Host wird mit „Installation fehlgeschlagen“ markiert. Das Beheben des Fehlers über die Benutzeroberfläche funktioniert nicht: Softwareinstallation auf Host fehlgeschlagen. Nicht aufgelöste Abhängigkeiten: [PyYAML, python-mako, python-netaddr, python3]

  Problemumgehung: Installieren Sie NSX RHEL 8.2-VIBs nach dem Upgrade des Host-Betriebssystems manuell und lösen Sie sie über die Benutzeroberfläche auf.

• Problem 2628503: DFW-Regel wird selbst nach dem erzwungenen Löschen der Manager-NSGroup weiterhin angewendet.

  Problemumgehung: Erzwingen Sie keinen Löschvorgang für eine NSGroup, die noch durch eine DFW-Regel verwendet wird. Leeren Sie stattdessen die NSGroup oder löschen Sie die DFW-Regel.

• Problem 2684574: Wenn das Edge über mehr als 6.000 Routen für Datenbank und Routen verfügt, tritt eine Zeitüberschreitung bei der Richtlinien-API auf.

  Diese Richtlinien-APIs für die OSPF-Datenbank und OSPF-Routen geben einen Fehler zurück, wenn das Edge über mehr als 6.000 Routen verfügt: /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 Wenn der Edge über 6.000 Routen für Datenbank und Roten besitzt, tritt bei der Richtlinien-API eine Zeitüberschreitung auf. Dies ist eine schreibgeschützte API, und sie wirkt sich nur dann aus, wenn die API/UI zum Herunterladen von mehr als 6.000 Routen für OSPF-Routen und die Datenbank verwendet wird.

  Problemumgehung: Verwenden Sie die CLI-Befehle, um die Informationen vom Edge abzurufen.

• Problem 2663483: Der Einzelknoten-NSX-Manager wird von der restlichen NSX-Verbundumgebung getrennt, wenn Sie das APH-AR-Zertifikat auf diesem NSX Manager ersetzen.

  Dieses Problem tritt nur mit dem NSX-Verbund und einem NSX Manager-Cluster mit einem einzelnen Knoten auf. Der Einzelknoten-NSX-Manager wird von der restlichen NSX-Verbundumgebung getrennt, wenn Sie das APH-AR-Zertifikat auf diesem NSX Manager ersetzen.

  Problemumgehung: Eine NSX Manager-Clusterbereitstellung mit einem einzelnen Knoten wird als Bereitstellungsoption nicht unterstützt, weshalb Sie NSX Manager-Cluster mit drei Knoten benötigen.

• Problem 2636771: Die Suche kann eine Ressource zurückgeben, wenn diese mit mehreren Tag-Paaren gekennzeichnet ist und Tag und Geltungsbereich mit einem beliebigen Wert für Tag und Geltungsbereich übereinstimmen.

  Dies wirkt sich auf die Suchabfrage mit einer Bedingung für Tag und Geltungsbereich aus. Der Filter gibt möglicherweise zusätzliche Daten zurück, wenn das Tag und der Geltungsbereich mit einem beliebigen Paar übereinstimmen.

  Problemumgehung: Keine.

• Problem 2668717: Beim Ost-West-Routing zwischen vRA-erstellten Netzwerken, die mit Segmenten verbunden sind, die Tier-1 gemeinsam nutzen, kann es zu zeitweiligen Verkehrsverlusten kommen.

  Wenn vRA mehrere Segmente erstellt und sich mit einem gemeinsam genutzten ESG verbindet, konvertiert V2T eine solche Topologie in eine gemeinsam genutzte Tier-1, die mit allen Segmenten auf der NSX-T-Seite verbunden ist. Während des Zeitfensters für die Hostmigration kann es beim Ost-West-Verkehr zwischen Arbeitslasten, die mit den Segmenten verbunden sind, die das Tier-1 gemeinsam nutzen, zu einem zeitweiligen Verkehrsverlust kommen.

  Problemumgehung: Keine.

• Problem 2490064: Das Deaktivieren von VMware Identity Manager schlägt fehl, wenn die Option für den externen Load Balancer aktiviert ist.

  Wenn Sie nach der Aktivierung der VMware Identity Manager-Integration auf NSX mit „Externer Load Balancer“ versuchen, die Integration zu deaktivieren, indem Sie „Externer Load Balancer“ ausschalten, wird nach rund einer Minute erneut die ursprüngliche Konfiguration angezeigt, die die lokalen Änderungen überschreibt.

  Problemumgehung: Wenn Sie versuchen, vIDM zu deaktivieren, dann schalten Sie das Flag „Externer Load Balancer“ nicht aus. Deaktivieren Sie nur die Integration von vIDM. Dadurch wird diese Konfiguration in der Datenbank gespeichert und mit den anderen Knoten synchronisiert.

• Problem 2526769: Bei der Wiederherstellung auf einem Cluster mit mehreren Knoten tritt ein Fehler auf.

  Wenn Sie in einem Cluster mit mehreren Knoten eine Wiederherstellung starten, schlägt die Wiederherstellung fehl und Sie müssen die Appliance erneut bereitstellen.

  Problemumgehung: Stellen Sie ein neues Setup bereit (Cluster mit einem Knoten) und starten Sie die Wiederherstellung.

• Problem 2534933: Zertifikate mit LDAP-basierten CDPs (CRL Distribution Point) können nicht als Tomcat-/Cluster-Zertifikate angewendet werden.

  CA-signierte Zertifikate mit LDAP-CDPs können nicht als Cluster-/Tomcat-Zertifikat verwendet werden.

  Problemumgehung: Es gibt zwei Optionen.

  1. Verwenden Sie ein Zertifikat mit HTTP-basiertem CDP.

  2. Deaktivieren Sie die CRL-Prüfung mit PUT https://<manager>/api/v1/global-configs/SecurityGlobalConfig API (Stellen Sie sicher, dass in der Nutzlast für PUT für „crl_checking_enabled“ „false“ festgelegt ist.)

• Problem 2566121: Die falsche Fehlermeldung „Einige Appliance-Komponenten funktionieren nicht ordnungsgemäß“ wird angezeigt, wenn der Server überlastet ist.

  Wenn zu viele API-Aufrufe an NSX erfolgen, zeigt die Benutzeroberfläche/API den Fehler „Einige Appliance-Komponenten funktionieren nicht ordnungsgemäß“ an, statt „Server ist überlastet“.

  Problemumgehung: Keine.

• Problem 2613113: Wenn ein Onboarding ausgeführt wird und der lokale Manager wiederhergestellt wird, ändert sich der Status auf dem globalen Manager nicht von IN_PROGRESS.

  Die Benutzeroberfläche zeigt beim globalen Manager IN_PROGRESS für das Onboarding des lokalen Managers an. Die Konfiguration der wiederhergestellten Site kann nicht importiert werden.

  Problemumgehung: Starten Sie den Cluster des globalen Managers neu, einen Knoten nach dem anderen.

• Problem 2690457: Wenn Sie eine MP mit einem MP-Cluster verbinden, auf dem publish_fqdns festgelegt ist und der externe DNS-Server nicht ordnungsgemäß konfiguriert ist, wird der Proton-Dienst auf dem Knoten, der hinzugefügt wird, möglicherweise nicht ordnungsgemäß neu gestartet.

  Der Manager, der hinzugefügt wird, funktioniert nicht, und die Benutzeroberfläche wird nicht verfügbar sein.

  Problemumgehung: Konfigurieren Sie den externen DNS-Server mit Forward- und Reverse-DNS-Eingaben für alle Manager-Knoten.

• Problem 2574281: Die Richtlinie lässt nur maximal 500 VPN-Sitzungen zu.

  NSX beansprucht im Formfaktor „Groß“ 512 VPN-Sitzungen pro Edge. Da die Richtlinie eine automatische Auslagerung von Sicherheitsrichtlinien durchführt, lässt die Richtlinie jedoch nur maximal 500 VPN-Sitzungen zu. Bei der Konfiguration der 501. VPN-Sitzung auf Tier0 wird folgende Fehlermeldung angezeigt: {'httpStatus': 'BAD_REQUEST', 'error_code': 500230, 'module_name': 'Policy', 'error_message': 'GatewayPolicy path=[/infra/domains/default/gateway-policies/VPN_SYSTEM_GATEWAY_POLICY] besitzt mehr als 1.000 zulässige Regeln pro Gateway path=[/infra/tier-0s/inc_1_tier_0_1].'}

  Problemumgehung: Verwenden Sie die APIs der Management Plane, um zusätzliche VPN-Sitzungen zu erstellen.

• Problem 2658092: Das Onboarding schlägt fehl, wenn NSX Intelligence auf dem lokalen Manager konfiguriert ist.

  Onboarding schlägt mit einem Prinzipalidentitätsfehler fehl und Sie können kein Onboarding für ein System mit dem Prinzipalidentitätsbenutzer durchführen.

  Problemumgehung: Erstellen Sie einen temporären Prinzipalidentitätsbenutzer mit dem Benutzernamen, der auch von NSX Intelligence verwendet wird.

• Problem 2639424: Die Wartung eines Hosts in einem vLCM-Cluster mit hostbasierter Bereitstellung schlägt fehl, nachdem die Wartung zu 95 % abgeschlossen ist.

  Der Wartungsfortschritt für einen Host bleibt bei 95 % stehen und der Vorgang schlägt nach 70 Minuten aufgrund einer Zeitüberschreitung fehl.

  Problemumgehung: Informationen hinzu finden Sie im VMware-Knowledgebase-Artikel 81447.

• Problem 2636420: Der Host wechselt in den Status „NSX-Installation übersprungen“ und der Cluster in den Status „Fehlgeschlagen“ nach der Wiederherstellung, wenn „NSX entfernen“ nach der Sicherung auf dem Cluster ausgeführt wird.

  „NSX-Installation übersprungen“ wird für den Host angezeigt.

  Problemumgehung: Nach der Wiederherstellung müssen Sie „NSX entfernen“ erneut auf dem Cluster ausführen, um den Status zu erreichen, der nach der Sicherung (Status „Nicht konfiguriert“) vorhanden war.

• Problem 2558576: Die Versionen einer globalen Profildefinition für den globalen Manager und den lokalen Manager können sich unterscheiden und ein unbekanntes Verhalten auf dem lokalen Manager aufweisen.

  Globale DNS-, Sitzungs- oder Flood-Profile, die im globalen Manager erstellt wurden, können nicht über die Benutzeroberfläche auf eine lokale Gruppe angewendet werden, wohl aber über die API. Daher kann ein API-Benutzer versehentlich Profilbindungs-Maps erstellen und die globale Entität auf dem lokalen Manager ändern.

  Problemumgehung: Verwenden Sie die Benutzeroberfläche, um das System zu konfigurieren.

• Problem 2491800: SSL-Zertifikate für den AR-Kanal werden nicht regelmäßig auf ihre Gültigkeit überprüft, was zur Verwendung eines abgelaufenen/widerrufenen Zertifikats für eine bestehende Verbindung führen kann.

  Die Verbindung würde ein abgelaufenes/widerrufenes SSL verwenden.

  Problemumgehung: Starten Sie den APH auf dem Manager-Knoten erneut, um eine erneute Verbindung auszulösen.

• Problem 2561988: Alle IKE/IPSEC-Sitzungen werden vorübergehend unterbrochen.

  Der Datenverkehrsausfall wird für einige Zeit angezeigt.

  Problemumgehung: Ändern Sie die lokalen Endpoints in Phasen statt alle gleichzeitig.

• Problem 2584648: Der Wechsel von Primär für T0/T1-Gateway wirkt sich auf die Northbound-Konnektivität aus.

  Die Standort-Failover-Zeit verursacht eine Unterbrechung für einige Sekunden und kann sich auf Standort-Failover oder Failback-Test auswirken.

  Problemumgehung: Keine.

• Problem 2636420: Das Transportknotenprofil wird auf einen Cluster angewendet, auf dem nach der Sicherung „NSX entfernen“ aufgerufen wird.

  Hosts befinden sich nicht im vorbereiteten Zustand, das Transportknotenprofil wird aber weiterhin auf den Cluster angewendet.

  Problemumgehung: Nach der Wiederherstellung müssen Sie „NSX entfernen“ erneut auf dem Cluster ausführen, um den Status zu erreichen, der nach der Sicherung (Status „Nicht konfiguriert“) vorhanden war.

• Problem 2687084: Nach dem Upgrade oder Neustart gibt die Such-API möglicherweise den Fehler 400 mit dem Fehlercode 60508 zurück: „Wenn Sie Indizes neu erstellen, kann dies einige Zeit in Anspruch nehmen.“

  Je nach Größe des Systems können die Such-API und die Benutzeroberfläche erst verwendet werden, nachdem die erneute Indizierung abgeschlossen wurde.

  Problemumgehung: Keine.

• Problem 2782010: Die Richtlinien-API lässt die Änderung von „vdr_mac/vdr_mac_nested“ zu, auch wenn für „allow_changed_vdr_mac_in_use“ „false“ festgelegt ist.

  VDR-MAC wird auf TN aktualisiert, auch wenn für „allow_changing“ „false“ festgelegt ist. Es wird kein Fehler ausgelöst.

  Problemumgehung: Ändern Sie VDR-MAC wieder in den alten Wert, falls Sie das Feld nicht ändern möchten.

• Problem 2791490: Verbund: Die Objekte können nach dem Ändern des Standby-GM-Kennworts nicht mit dem globaler Manager (GM) im Standby synchronisiert werden.

  Aktiver GM kann nicht auf dem Standort-Manager des Standby-GM beobachtet werden, ebenso Updates vom aktiven GM.

  Problemumgehung: Fordern Sie auf der Benutzeroberfläche des Standby-GM eine erzwungene Synchronisierung an.

• Problem 2799371: IPSec-Alarme für L2-VPN werden nicht gelöscht, obwohl L2-VPN- und IPSec-Sitzungen aktiv sind.

  Keine funktionalen Auswirkungen, außer dass unnötige offene Alarme angezeigt werden.

  Problemumgehung: Lösen Sie die Alarme manuell auf.

• Problem 2838613: Für ESX-Versionen vor 7.0.3 wird auf dem VDS, der von Version 6.5 auf eine höhere Version aktualisiert wurde, nach der Sicherheitsinstallation die NSX-Sicherheitsfunktionalität auf dem Cluster nicht aktiviert.

  NSX-Sicherheitsfunktionen werden auf den VMs, die mit dem VDS verbunden sind, der von 6.5 auf eine höhere Version (6.6+) aktualisiert wurde, nicht aktiviert, wenn die Funktion „NSX-Sicherheit auf vSphere DVPortgroups“ unterstützt wird.

  Problemumgehung: Starten Sie nach der Aktualisierung des VDS den Host neu und schalten Sie die VMs ein, um die Sicherheit auf den VMs zu aktivieren.

• Problem 2839782: Ein Upgrade von NSX-T 2.4.1 auf 2.5.1 ist nicht möglich, da die Zertifikatsperrlisteneinheit groß ist und Corfu eine Größenbeschränkung in 2.4.1 festlegt, was verhindert, dass die Zertifikatsperrlisteneinheit während des Upgrades in Corfu erstellt wird.

  Kein Upgrade möglich.

  Problemumgehung: Ersetzen Sie das Zertifikat durch ein Zertifikat, das von einer anderen Zertifizierungsstelle signiert wurde.

• Problem 2851991: IDFW schlägt fehl, wenn die Richtliniengruppe mit der AD-Gruppe auch eine verschachtelte leere Quellgruppe aufweist.

  IDFW schlägt fehl, wenn die Richtliniengruppe mit der AD-Gruppe eine verschachtelte leere Quellgruppe besitzt.

  Problemumgehung: Entfernen Sie die leere untergeordnete Gruppe.

• Problem 2852419: Es wird eine Fehlermeldung angezeigt, wenn die statische Route mit einem nicht verbindungslokalen nächsten IPv4/v6-Hop mit mehreren Geltungsbereichswerten konfiguriert ist.

  Statische Routen-API mit nicht verbindungslokaler IP des nächsten Hops mit einer Konfiguration mehrerer Geltungsbereichswerte wird abgelehnt.

  Problemumgehung: Erstellen Sie mehrere nächste Hops, statt mehrerer Geltungsbereichswerte und stellen Sie sicher, dass jeder nächste Hop eine andere IP-Adresse besitzt.

• Problem 2853889: Beim Erstellen der EVPN-Mandantenkonfiguration (mit VLAN-VNI-Zuordnung) werden untergeordnete Segmente erstellt, der Realisierungsstatus des untergeordneten Segments wird aber etwa 5 Minuten als fehlerhaft angezeigt versetzt und dann automatisch wiederhergestellt.

  Es dauert 5 Minuten, bis die EVPN-Mandantenkonfiguration realisiert wurde.

  Problemumgehung: Keine. Warten Sie 5 Minuten.

• Problem 2854139: Kontinuierliches Hinzufügen/Entfernen von BGP-Routen in RIB für eine Topologie, in der Tier0-SR auf dem Edge über mehrere BGP-Nachbarn verfügt und diese BGP-Nachbarn ECMP-Präfixe an den Tier0-SR senden.

  Der Datenverkehr wird verworfen für die Präfixe, die kontinuierlich hinzugefügt/gelöscht werden.

  Problemumgehung: Fügen Sie eine eingehende RouteMap hinzu, die das BGP-Präfix filtert, das sich im Subnetz des nächsten Hops der statischen Route befindet.

• Problem 2864250: Bei der Transportknotenrealisierung tritt ein Fehler auf, wenn beim Erstellen eines Transportknotens ein benutzerdefiniertes NIOC-Profil verwendet wird.

  Der Transportknoten ist nicht einsatzbereit.

  Problemumgehung: Erstellen Sie den Transportknoten mit dem Standard-NIOC-Profil und aktualisieren Sie ihn dann, indem Sie das benutzerdefinierte NIOC-Profil anwenden.

• Problem 2866682: Wenn in Microsoft Azure das beschleunigte Netzwerk auf Arbeitslast-VMs mit SUSE oder Linux Enterprise Server (SLES) 12 SP4 und mit installiertem NSX Agent aktiviert ist, erhält die Ethernet-Schnittstelle keine IP-Adresse.

  Der VM-Agent wird nicht gestartet und die VM wird nicht verwaltet.

  Problemumgehung: Deaktivieren Sie das beschleunigte Netzwerk.

• Problem 2867243: Effektive Mitgliedschafts-APIs für eine Richtliniengruppe oder NSGroup ohne effektive Mitglieder geben in der API-Antwort die Felder „results“ und „result_count“ nicht zurück.

  Es gibt keine funktionalen Auswirkungen.

  Problemumgehung: Keine.

• Problem 2868235: Im Dialogfeld „Schnellstart – Netzwerk und Sicherheit“ zeigt die Visualisierung einen doppelten VDS an, wenn mehrere pNICs an denselben VDS angehängt sind.

  Visualisierung zeigt doppelten VDS an. Es kann schwierig sein, den Abschnitt zum Anpassen des Host-Switches zu finden oder dorthin zu scrollen, wenn der Fokus auf dem Visualisierungsdiagramm liegt.

  Problemumgehung: Für das Bildlaufproblem drücken Sie die Tabulatortaste oder bewegen Sie den Mauszeiger außerhalb des Visualisierungsbereichs und scrollen Sie zum Abschnitt „Switch-Konfiguration anpassen“.

• Problem 2870085: Die Protokollierung auf der Sicherheitsrichtlinienebene zum Aktivieren/Deaktivieren der Protokollierung für alle Regeln funktioniert nicht.

  Sie können die Protokollierung aller Regeln nicht ändern, indem Sie „logging_enabled“ der Sicherheitsrichtlinie ändern.

  Problemumgehung: Ändern Sie jede Regel, um die Protokollierung zu aktivieren/deaktivieren.

• Problem 2870529: Laufzeitinformationen für die identitätsbasierte Firewall (IDFW) sind nicht verfügbar, wenn beim Hinzufügen der AD-Domäne der NetBIOS-Name nicht in der exakten Schreibweise angegeben wird.

  Sie können die aktuellen Laufzeitinformationen/den Status der IDFW nicht einfach und problemlos abrufen. Aktuell aktive Anmeldungen können nicht ermittelt werden.

  Problemumgehung: Bearbeiten Sie die betreffende Domäne und korrigieren Sie den NetBIOS-Namen. Sobald die Änderungen angewendet wurden, werden alle zukünftigen IDFW-Ereignisse korrekt gemeldet.

• Problem 2870645: Als Reaktion auf die /policy/api/v1/infra/realized-state/realized-entities-API werden in „publish_status_error_details“ Fehlerdetails angezeigt, selbst wenn „publish_status“ „ERFOLGREICH“ ist, was bedeutet, dass die Realisierung erfolgreich war.

  Es gibt keine funktionalen Auswirkungen.

  Problemumgehung: Keine.

• Problem 2871585: Das Entfernen des Hosts aus DVS und das Löschen von DVS ist für DVS-Versionen vor 7.0.3 zulässig, nachdem die NSX-Sicherheit der vSphere DVPortgroups-Funktion auf den Clustern aktiviert wurde, die DVS verwenden.

  Möglicherweise müssen Sie alle Probleme in der Transportknoten- oder der Clusterkonfiguration beheben, die dadurch verursacht werden, dass ein Host aus dem DVS entfernt oder gelöscht wurde.

  Problemumgehung: Keine.

• Problem 2874236: Wenn Sie nach dem Upgrade nur ein Public Cloud-Gateway (PCG) in einem HA-Paar erneut bereitstellen, wird erneut der ältere HA-AMI-/VHD-Build verwendet.

  Dies geschieht nur nach einem Upgrade bei der ersten erneuten Bereitstellung von PCGs.

  Problemumgehung: Stellen Sie das richtige AMI oder VHD nach dem Upgrade über die API bereit.

• Problem 2875385: Wenn ein neuer Knoten dem Cluster beitritt und lokale Benutzer (admin, audit, guestuser1, guestuser2) umbenannt wurden, können sich diese lokalen Benutzer möglicherweise nicht anmelden.

  Der lokale Benutzer kann sich nicht anmelden.

  Problemumgehung: Es gibt zwei mögliche Problemumgehungen.

  • Problemumgehung 1: Benennen Sie den Benutzer in einen beliebigen anderen Namen und dann wieder in den gewünschten Namen um.

  • Problemumgehung 2: Wenn Sie die Benutzer nicht umbenennen können, starten Sie NSX Manager neu.

• Problem 2848614: Beim Hinzufügen einer MP zu einem MP-Cluster, während „publish_fqdns“ auf dem MP-Cluster festgelegt ist und der Forward- oder Reverse-Lookup-Eintrag im externen DNS-Server fehlt oder der DNS-Eintrag für den Beitrittsknoten fehlt, werden für den beitretenden Knoten keine Forward- oder Reverse-Alarme generiert.

  Forward/Reverse-Alarme werden für den beitretenden Knoten nicht generiert, obwohl der Forward/Reverse-Lookup-Eintrag im DNS-Server fehlt oder der DNS-Eintrag für den beitretenden Knoten fehlt.

  Problemumgehung: Konfigurieren Sie den externen DNS-Server für alle Manager-Knoten mit Forward- und Reverse-DNS-Einträgen.

• Problem 2719682: Berechnete Felder vom Avi-Controller werden nicht mit dem Intent der Richtlinie synchronisiert, was zu Diskrepanzen bei den auf der Avi-und der NSX-T-Benutzeroberfläche angezeigten Daten führt.

  Berechnete Felder vom Avi-Controller werden auf der NSX-T-Benutzeroberfläche leer angezeigt.

  Problemumgehung: Prüfen Sie mit dem App-Switcher die Daten der Avi-Benutzeroberfläche.

• Problem 2747735: Nach der Wiederherstellung ist die VIP-Konnektivität aufgrund von Netzwerkkompatibilitätsproblemen unterbrochen.

  Während der Wiederherstellung der Sicherung können Kunden VIP vor dem Schritt "AddNodeToCluster" aktualisieren.

  [Geben Sie ggf. die Problemumgehung ein, andernfalls geben Sie „Keine“ ein] Die Wiederherstellung wird in der Regel im Schritt "AddNodeToCluster" angehalten, in dem der Benutzer aufgefordert wird, zusätzliche Manager-Knoten hinzuzufügen. In diesem Schritt entfernen/aktualisieren Sie zuerst die VIP, um eine neue IP-Adresse auf der Seite „Benutzeroberfläche für Systeme/Appliances“ zu verwenden, und fügen dann zusätzliche Knoten zu einem wiederhergestellten Cluster mit einem Knoten hinzu, sobald die VIP korrigiert wurde.

• Problem 2816781: Physische Server können nicht mit einer auf Lastausgleich basierenden Gruppierungsrichtlinie konfiguriert werden, da sie einen einzelnen VTEP unterstützen.

  Sie können keine physischen Server mit einer auf Lastausgleich basierten Gruppierungsrichtlinie konfigurieren.

  Problemumgehung: Ändern Sie die Gruppierungsrichtlinie in eine auf Failover basierte Gruppierungsrichtlinie oder eine beliebige Richtlinie mit einem einzelnen VTEP.

• Problem 2856109: Das Hinzufügen des 2000. Poolmitglieds führt mit der Avi-Controller-Version 21.1.2 zu einem Grenzwertfehler.

  Avi Controller 21.1.2 lässt nur 1.999 Poolmitglieder und nicht 2.000 Poolmitglieder zu.

  Problemumgehung: Verwenden Sie den Avi-Controller in der Version 20.1.7 oder 21.1.3.

• Problem 2862418: Das erste Paket geht in der Live-Datenverkehrsanalyse (LTA) möglicherweise verloren, wenn LTA zum Verfolgen der genauen Anzahl der Pakete konfiguriert wird.

  Sie können die erste Paket-Nachverfolgung nicht sehen.

  Problemumgehung: Keine.

• Problem 2864929: Die Anzahl der Poolmitglieder ist höher, wenn eine Migration von NSX for vSphere zum Avi-Load Balancer auf NSX-T Data Center erfolgt.

  Eine höhere Anzahl Poolmitglieder wird angezeigt. Die Integritätsüberwachung markiert diese Poolmitglieder als inaktiv. An nicht erreichbare Poolmitglieder wird aber kein Datenverkehr gesendet.

  Problemumgehung: Keine.

• Problem 2865273: Die Suchmaschine für Advanced Load Balancer (Avi) stellt keine Verbindung zum Avi-Controller her, wenn vor der Migration von NSX for vSphere zu NSX-T Data Center eine DFW-Regel zum Blockieren der Ports 22, 443, 8443 und 123 vorhanden ist.

  Die Avi-Suchmaschine kann keine Verbindung zum Avi-Controller herstellen.

  Problemumgehung: Fügen Sie explizite DFW-Regeln hinzu, um die Ports 22, 443, 8443 und 123 für SE-VMs zuzulassen oder um SE-VMs aus DFW-Regeln auszuschließen.

• Problem 2866885: ELS erfordert, dass der in der AD-Domäne konfigurierte NetBIOS-Name mit dem im AD-Server übereinstimmt.

  Benutzeranmeldung wird von ELS nicht erkannt.

  Problemumgehung: Ändern Sie den NetBIOS-Namen, damit er mit dem im AD-Server übereinstimmt.

• Problem 2868944: Auf der Benutzeroberfläche wird kein Feedback angezeigt, wenn mehr als 1.000 DFW-Regeln von NSX for vSphere zu NSX-T Data Center migriert werden, die Abschnitte werden jedoch in Abschnitte mit maximal 1.000 Regeln unterteilt.

  Auf der Benutzeroberfläche wird kein Feedback angezeigt.

  Problemumgehung: Prüfen Sie die Protokolle.

• Problem 2878030: Der Upgrade-Orchestrator-Knoten für die Änderung der lokalen Manager-Site zeigt keine Benachrichtigung an.

  Wenn der Orchestrator-Knoten nach dem UC-Upgrade geändert wird und Sie mit dem Workflow auf der Benutzeroberfläche fortfahren, indem Sie auf eine beliebige Aktionsschaltfläche klicken (Vorabprüfung, Start usw.), wird auf der Upgrade-Benutzeroberfläche kein Fortschritt angezeigt. Dies gilt nur, wenn der Zugriff auf die Upgrade-Benutzeroberfläche des lokalen Managers über den Site-Switcher auf der Benutzeroberfläche des globalen Manager erfolgt.

  Problemumgehung: Wechseln Sie zum lokalen Manager für diese Site und setzen Sie das Upgrade fort, damit die erwartete Benachrichtigung angezeigt wird.

• Problem 2878325: In der Anzeige des Dashboards für die Bestandskapazität für Manager enthält die für das Attribut „Gruppen basierend auf IP Sets“ angezeigte Anzahl keine Gruppen, die IP-Adressen enthalten, die über die Richtlinien-Benutzeroberfläche erstellt wurden.

  In der Anzeige des Dashboards für die Bestandskapazität für Manager wird die für das Attribut „Gruppen basierend auf IP Sets“ angezeigte Anzahl nicht korrekt dargestellt, wenn Richtliniengruppen mit IP-Adressen vorhanden sind.

  Problemumgehung: Keine.

• Problem 2879133: Der Start der Malware-Schutzfunktion kann bis zu 15 Minuten in Anspruch nehmen.

  Wenn die Malware-Schutzfunktion zum ersten Mal konfiguriert wird, kann es bis zu 15 Minuten dauern, bis die Funktion initialisiert wurde. Während dieser Initialisierung erfolgt keine Malware-Analyse, es wird jedoch kein Hinweis angezeigt, dass die Initialisierung läuft.

  Problemumgehung: Warten Sie 15 Minuten.

• Problem 2879734: Die Konfiguration schlägt fehl, wenn dasselbe selbstsignierte Zertifikat in zwei verschiedenen lokalen IPsec-Endpoints verwendet wird.

  Die fehlgeschlagene IPsec-Sitzung wird erst eingerichtet, nachdem der Fehler behoben wurde.

  Problemumgehung: Verwenden Sie für jeden lokalen Endpoint ein eindeutiges selbstsigniertes Zertifikat.

• Problem 2879979: Der IKE-Dienst initiiert möglicherweise keine neue IPsec-routenbasierte Sitzung, nachdem eine Erkennung inaktiver Peers stattgefunden hat, weil der IPsec-Peer nicht erreichbar war.

  Es kann zu einem Ausfall einer bestimmten routenbasierten IPsec-Sitzung kommen.

  Problemumgehung: Ein Aktivieren/Deaktivieren der IPsec-Sitzung kann das Problem beheben.

• Problem 2881281: Die gleichzeitige Konfiguration mehrerer virtueller Server schlägt möglicherweise für einige fehl.

  Bei Clientverbindungen zu virtuellen Servern kann es zu einer Zeitüberschreitung kommen.

  Problemumgehung: Führen Sie die folgende API aus, um den Workflow des logischen Routers erneut auszulösen.

  https://{ip}/api/v1/logical-routers/<id>? action=reprocess

• Problem 2881471: Der Dienstbereitstellungsstatus wird nicht aktualisiert, wenn der Bereitstellungsstatus von „Fehlgeschlagen“ zu „Erfolgreich“ wechselt.

  Möglicherweise sehen Sie, dass der Dienstbereitstellungsstatus dauerhaft „Inaktiv“ bleibt und der ausgelöste Alarm weiterhin besteht.

  Problemumgehung: Verwenden Sie die Dienstbereitstellungsstatus-API, um den Status zu prüfen.

  API: https://{{nsx-mgr-ip}}/api/v1/serviceinsertion/services/{{service-id}}/service-deployments/{{service-deployment-id}}/status

• Problem 2882070: Für globale Gruppen werden NSGroup-Mitglieder und -Kriterien nicht in der Manager-API-Auflistung angezeigt.

  Keine funktionalen Auswirkungen.

  Problemumgehung: Zeigen Sie die globalen Gruppendefinitionen über die Richtlinien-API auf dem lokalen Manager an.

• Problem 2882769: Tags für NSService- und NSServiceGroup-Objekte werden beim Upgrade auf NSX-T 3.2 nicht übernommen.

  Dies hat keine funktionalen Auswirkungen auf NSX, da Tags für NSService und NSServiceGroup von keinem Workflow genutzt werden. Dies kann Auswirkungen auf externe Skripts haben, die Workflows enthalten, die auf Tags für diese Objekte angewiesen sind.

  Problemumgehung: Nach dem Upgrade auf NSX-T 3.2 können fehlende Tags zu NSService und NSServiceGroup hinzugefügt werden, indem die Entitäten aktualisiert werden.

• Problem 2884939: Die NSX-Ratenbegrenzung von 100 Anforderungen pro Sekunde wird erreicht, wenn eine große Anzahl virtueller Dienste von NSX for vSphere zu NSX-T ALB migriert wird und alle APIs für einige Zeit blockiert sind.

  NSX-T-Richtlinien-API zeigt folgenden Fehler: Client „admin“ hat die Anforderungsrate von 100 pro Sekunde überschritten (Fehlercode: 102) einige Zeit nach dem Erreichen der Migration der Konfiguration.

  Problemumgehung: Ändern Sie den Client-API-Ratengrenzwert auf 200 Anforderungen pro Sekunde.

• Problem 2792485: Für den in vCenter installierten Manager wird anstelle des FQDN die NSX Manager-IP angezeigt.

  Die in vCenter integrierte NSX-T-Benutzeroberfläche zeigt für den installierten Manager anstelle des FQDN die NSX Manager-IP an.

  Problemumgehung: Keine.

• Problem 2884518: Fehlerhafte Anzahl der mit dem Segment verbundenen VMs auf der Benutzeroberfläche der Netzwerktopologie nach dem Upgrade einer NSX-Appliance auf NSX-T 3.2.

  Sie sehen eine fehlerhafte Anzahl der VMs, die mit dem Segment in der Netzwerktopologie verbunden sind. Die tatsächliche Anzahl der mit dem Segment verknüpften VMs wird allerdings angezeigt, wenn Sie den Knoten der VM erweitern.

  Problemumgehung:

  1. Melden Sie sich im Engineering-Modus bei der NSX-Appliance an.

  2. Führen Sie folgenden Befehl aus: curl -XDELETE http://localhost:9200/topology_manager

• Problem 2874995: Die Priorität von LCores kann auch dann hoch bleiben, wenn sie nicht verwendet werden, weshalb sie von einigen VMs nicht verwendet werden können.

  Leistungsbeeinträchtigungen für VMs mit normaler Latenz.

  Problemumgehung: Es gibt zwei Optionen.

  • Starten Sie das System neu.

  • Entfernen Sie die LCores mit hoher Priorität und erstellen Sie sie neu. Sie werden dann standardmäßig wieder zu LCores mit normaler Priorität.

• Problem 2772500: Das Aktivieren von verschachteltem Overlay auf ENS kann zu PSOD führen.

  Kann zu PSOD führen.

  Problemumgehung: Deaktivieren Sie ENS.

• Problem 2832622: IPv6-ND-Profil wird nach der Bearbeitung oder Änderung nicht wirksam.

  Das Netzwerk verweist weiterhin auf das alte NDRA-Profil.

  Problemumgehung: Starten Sie CCP neu, um das IPv6-ND-Profil zu aktualisieren.

• Problem 2840599: Die MP-Normalisierungs-API gibt den Fehler INVALID_ARGUMENT aus.

  Schlechte Benutzerfreundlichkeit der Benutzeroberfläche.

  Problemumgehung: Keine.

• Problem 2844756: Löschen des Segments schlägt mit einem Fehler fehl.

  Sie können das Segment nicht löschen.

  Problemumgehung: Erzwingen Sie das Löschen der mit dem Segment verbundenen Ports.

  1. Rufen Sie mithilfe der folgenden API alle mit diesem Segment verbundenen logischen Ports ab. Z. B. für PolicySegment01.

     GET : https://<NSX MANAGER IP>/policy/api/v1/infra/segments/PolicySegment01/ports

  2. Führen Sie für jeden mit dem obigen Abruf aufgeführten logischen Port folgenden Aufruf durch.

     DELETE : https://<NSX MANAGER IP>/api/v1/logical-ports/<LOGICAL PORT UUID>?detach=true

  Sobald alle verbundenen Ports gelöscht wurden, kann das Segment gelöscht werden.

• Problem 2866751: Die konsolidierte effektive Mitgliedschafts-API listet keine statischen IPs in der Antwort für eine Shadow Group auf.

  Keine Auswirkungen auf die Funktion oder den Datenpfad. Statische IP-Adressen werden beim Abrufen der konsolidierten effektiven Mitgliedschaft über die API für eine Shadow Group nicht angezeigt. Dies gilt nur für eine Shadow Group (auch als Referenzgruppe bezeichnet).

  Problemumgehung: Überprüfen Sie die konsolidierte effektive Mitgliedschaft einer Shadow Group auf ihrer ursprünglichen Site.

• Problem 2869356: Auf der Management Plane wird ein Fehler angezeigt, wenn Sie für eine NSGroup mit IPSet-Mitgliedern auf die Registerkarte „Übersicht“ klicken.

  Schlechte Benutzerfreundlichkeit der Benutzeroberfläche.

  Problemumgehung: Keine.

• Problem 2872658: Nach der Site-Registrierung wird auf der Benutzeroberfläche die Fehlermeldung angezeigt, dass das Importieren aufgrund nicht unterstützter Funktionen unmöglich ist: IDS.

  Es gibt keine funktionalen Auswirkungen. Der Konfigurationsimport wird in NSX-T 3.2 nicht unterstützt.

  Problemumgehung: Entfernen Sie die IDS-Konfiguration aus dem lokalen Manager und wiederholen Sie die Registrierung.

• Problem 2877628: Beim Versuch, die Sicherheitsfunktion auf einem ESX-Host-Switch mit einer VDS-Version vor 6.6 zu installieren, wird eine unklare Fehlermeldung angezeigt.

  Die Fehlermeldung wird über die Benutzeroberfläche und die API angezeigt.

  Problemumgehung: Verwenden Sie eine VDS-Version ab 6.6 auf ESX, um die NSX-Sicherheit zu installieren.

• Problem 2877776: Die Ausgabe „get controller“ zeigt möglicherweise veraltete Informationen zu Controllern an, die beim Abgleich mit der Datei „controller-info.xml“ keine Master sind.

  Diese CLI-Ausgabe ist verwirrend.

  Problemumgehung: Starten Sie nsx-proxy auf dem TN neu.

• Problem 2879119: Wenn ein virtueller Router hinzugefügt wird, wird die entsprechende Kernel-Netzwerkschnittstelle nicht angezeigt.

  Das Routing auf dem VRF schlägt fehl. Für VMs, die über das VRF verbunden sind, wird keine Konnektivität hergestellt.

  Problemumgehung: Starten Sie den Dataplane-Dienst neu.

• Problem 2881168: Die Ausgabe von LogicalPort GET API erfolgt im erweiterten Format „fc00:0:0:0:0:0:0:1“, statt im vorherigen Format „fc00::1“.

  Die Ausgabe von LogicalPort GET API in NSX-T 3.2 erfolgt im erweiterten Format „fc00:0:0:0:0:0:0:1“, statt im NSX-T 3.0 Format „fc00::1“.

  Problemumgehung: Keine.

• Problem 2882822: Temporäre IPSets werden während der Migration der Konfiguration von NSX for vSphere zu NSX-T nicht zu SecurityGroups hinzugefügt, die in EDGE-Firewallregeln/LB-Poolmitgliedern verwendet werden.

  Während der Migration kann eine Lücke auftreten, bis die VMs/VIFs auf NSX-T erkannt und Teil der SGs werden, auf die sie über statische/dynamische Mitgliedschaften anwendbar sind. Dies kann dazu führen, dass in der Zeit zwischen der vertikalen Übernahme (vertikaler Datenverkehr, der über das NSX-T-Gateway läuft) bis zum Ende der Migration Datenverkehr entgegen den Edge-Firewall-Regeln verworfen oder zugelassen wird.

  Problemumgehung: Fügen Sie eine Fake-DFW-Regel hinzu, in der die Quelle/das Ziel alle Sicherheitsgruppen enthält, die in der Edge-FW verbraucht werden. Eine weitere Option besteht darin, die Quelle und das Ziel der Edge-Firewallregeln vor der Migration in IPSets zu verschieben.

• Problem 2884070: Wenn die MTU-Einstellung für den NSX-T Edge-Uplink und den Peering-Router nicht übereinstimmt, bleibt die OSPF-Nachbarschaft im Exstart-Status stecken. Während der Migration von NSX for vSphere zu NSX-T wird die MTU nicht automatisch migriert, weshalb sich eine Nichtübereinstimmung während der vertikalen Edge-Übernahme auf die Datenebene auswirken kann.

  Die OSPF-Nachbarschaft bleibt im Exstart-Status stecken.

  Problemumgehung: Konfigurieren Sie die MTU auf OSPF-Nachbarschnittstellen manuell übereinstimmend, bevor Sie die Edge-Übernahme durchführen.

• Problem 2884416: Der Load Balancer-Status kann nicht rechtzeitig aktualisiert werden.

  Falscher Load Balancer-Status.

  Problemumgehung: Beenden Sie die Statistikerfassung des Load Balancers.

• Problem 2885009: Der globale Manager besitzt nach dem Upgrade zusätzliche Standard-Switching-Profile.

  Keine funktionalen Auswirkungen.

  Problemumgehung: Es wird nicht erwartet, dass Sie die Standard-Switching-Profile verwenden, die mit dem Präfix „nsx-default“ beginnen.

• Problem 2885248: Wenn EdgeVnics in einem InterVtep-Szenario mit NSX-Portgruppen verbunden sind (unabhängig vom VLAN auf der Edge-VM und dem ESX-Host), funktioniert der vertikale Datenverkehr zwischen Arbeitslast-VMs auf dem ESX und dem Edge nicht mehr, da ESX Pakete verwirft, die für den Edge-VTEP bestimmt sind.

  Problemumgehung: Aktualisieren Sie den Edge-Transportknoten, indem Sie die Segmente von ihren Schnittstellen trennen und erneut verbinden.

• Problem 2885330: Effektives Mitglied wird für AD-Gruppe nicht angezeigt.

  Effektive Mitglieder der AD-Gruppe werden nicht angezeigt. Keine Auswirkung auf Datenpfad.

  Problemumgehung: Keine.

• Problem 2885552: Wenn Sie eine LDAP-Identitätsquelle erstellt haben, die OpenLDAP verwendet, und mehr als ein LDAP-Server definiert wird, wird nur der erste Server verwendet.

  Wenn der erste LDAP-Server nicht mehr verfügbar ist, schlägt die Authentifizierung fehl, statt die weiteren konfigurierten OpenLDAP-Server zu nutzen.

  Problemumgehung: Wenn es möglich ist, einen Load Balancer vor den OpenLDAP-Servern zu platzieren und NSX mit der virtuellen IP des Load Balancers zu konfigurieren, ist Hochverfügbarkeit möglich.

• Problem 2886210: Wenn der VC während der Wiederherstellung inaktiv ist, wird ein Sichern/Wiederherstellen-Dialogfeld angezeigt, das den Benutzer auffordert, sicherzustellen, dass VC aktiv ist und ausgeführt wird. Die IP-Adresse des VC wird jedoch nicht angezeigt.

  Für die VC-Konnektivität wird während der Wiederherstellung die IP-Adresse des VCs nicht angezeigt.

  Problemumgehung: Überprüfen Sie, ob alle registrierten VCs ausgeführt werden, bevor Sie mit dem nächsten Wiederherstellungsschritt fortfahren.

• Problem 2886971: Gruppen, die auf dem globalen Manager erstellt wurden, werden nach dem Löschen nicht bereinigt. Dies geschieht nur, wenn es sich bei der Gruppe um eine Referenzgruppe auf einer lokalen Manager-Site handelt.

  Keine funktionalen Auswirkungen. Sie können jedoch keine weitere Gruppe mit demselben Richtlinienpfad erstellen wie die gelöschte Gruppe.

  Problemumgehung: Keine.

• Problem 2887037: NAT-Regeln können nach der Heraufstufung vom Manager- zum Richtlinienobjekt nicht aktualisiert oder gelöscht werden.

  Dies geschieht, wenn NAT-Regeln von einem PI-Benutzer (Prinzipalidentität) im Manager erstellt wurden, bevor die Heraufstufung ausgelöst wird. Vom PI-Benutzer erstellte NAT-Regeln können nach der Heraufstufung vom Manager- zum Richtlinienobjekt nicht aktualisiert oder gelöscht werden.

  Problemumgehung: NAT-Regeln mit derselben Konfiguration können vor der Heraufstufung vom Manager- zum Richtlinienobjekt mit einem nicht geschützten Benutzer, z. B. „admin“, erstellt werden.

• Problem 2888207: Lokale Benutzeranmeldedaten können nicht zurückgesetzt werden, wenn vIDM aktiviert ist.

  Sie können keine lokalen Benutzerkennwörter ändern, solange vIDM aktiviert ist.

  Problemumgehung: Die vIDM-Konfiguration muss (vorübergehend) deaktiviert, das Zurücksetzen der lokalen Anmeldedaten während dieser Zeit durchgeführt und die Integration dann erneut aktiviert werden.

• Problem 2889748: Das Löschen des Edge-Knotens schlägt fehl, wenn die erneute Bereitstellung fehlgeschlagen ist. Beim Löschen verbleibt der veraltete Intent im System und wird auf der Benutzeroberfläche angezeigt.

  Obwohl die Edge-VM gelöscht wird, bleiben der veraltete Edge-Intent und interne Objekte im System erhalten und der Löschvorgang wird intern erneut versucht. Keine Auswirkungen auf die Funktionalität, da die Edge-VMs gelöscht werden und nur der Intent veraltete Einträge aufweist.

  Problemumgehung: Keine.

• Problem 2875962: Der Upgrade-Workflow für cloudnative Setups unterscheidet sich für NSX-T 3.1 und NSX-T 3.2.

  Beim Ausführen des üblichen Workflows werden alle CSM-Daten gelöscht.

  Problemumgehung: Für das Upgrade wird Unterstützung durch VMware benötigt. Wenden Sie sich an den VMware Support.

• Problem 2888658: Erhebliche Auswirkungen auf die Leistung in Bezug auf Verbindungen pro Sekunde und Durchsatz, der bei NSX-T Gateway Firewall beobachtet wird, wenn die Funktion „Malware-Erkennung und Sandboxing“ aktiviert ist.

  Bei jedem Datenverkehr mit der Malware-Erkennung kommt es zu erheblichen Latenzen und möglicherweise Verbindungsfehlern. Wenn die Malware-Erkennung auf dem Gateway aktiviert ist, wirkt sich dies auch auf den L7FW-Datenverkehr aus, was Latenzen und Verbindungsfehler verursacht.

  Problemumgehung: Begrenzen Sie die Menge des Datenverkehrs, der der Malware-Erkennung unterliegt, indem Sie IDS-Regeln schreiben, die nur einem kleinen Unterabschnitt des Datenverkehrs entsprechen.

• Problem 2882574: Blockierte „Brownfield Config Onboarding“-APIs in NSX-T Version 3.2.0, da die Funktion nicht vollständig unterstützt wird.

  Sie können die Funktion „Brownfield Config Onboarding“ nicht verwenden.

  Problemumgehung: Keine.

• Problem 2890348: Das Umbenennen des Standard-VNI-Pools führt beim Upgrade auf NSX-T 3.2 zu einem inkonsistenten VNI-Pool.

  VNI-Zuteilung und zugehörige Vorgänge schlagen möglicherweise fehl.

  Problemumgehung: Benennen Sie vor dem Upgrade auf NSX-T 3.2 den Standard-VNI-Pool auf DefaultVniPool mit API PUT https://{{url}}/api/v1/pools/vni-pools/<vni-pool-id> um.

• Problem 2885820: Fehlende Übersetzungen für einige IP-Adressen für den IP-Bereich ab 0.0.0.0.

  NSGroup mit IP-Bereich ab 0.0.0.0 (z. B. „0.0.0.0-255.255.255.0“) weist Übersetzungsprobleme auf (fehlendes Subnetz 0.0.0.0/1).

  NSGroup mit IP-Bereich „1.0.0.0-255.255.255.0“ sind davon nicht betroffen.

  Problemumgehung: Um Gruppen mit einem IP-Bereich zu konfigurieren, der mit 0.0.0.0 beginnt, fügen Sie manuell 0.0.0.0/1 in die Gruppenkonfiguration ein.

• Problem 2871440: Arbeitslasten, die mit NSX Security auf vSphere dvPortGroups gesichert wurden, verlieren ihre Sicherheitseinstellungen, wenn sie mit vMotion auf einen Host verschoben werden, der mit einem inaktiven NSX Manager verbunden ist.

  Für Cluster, die mit NSX Security auf vSphere dvPortGroups-Funktion installiert sind, werden die DFW- und Sicherheitsregeln für VMs, die mit vMotion auf Hosts verschoben werden, die mit einem ausgefallenen NSX Manager verbunden sind, nicht erzwungen. Diese Sicherheitseinstellungen werden erneut erzwungen, wenn die Verbindung zu NSX Manager wiederhergestellt wird.

  Problemumgehung: Vermeiden Sie vMotion auf betroffenen Hosts, wenn NSX Manager inaktiv ist. Wenn andere NSX Manager-Knoten funktionieren, verschieben Sie die VM mit vMotion auf einen anderen Host, der mit einem fehlerfreien NSX Manager verbunden ist.

• Problem 2945515: NSX Tools-Upgrade in Azure kann auf Redhat Linux-VMs fehlschlagen.

  Standardmäßig ist NSX Tools im Verzeichnis „/opt“ installiert. Während der NSX Tools-Installation kann der Standardpfad jedoch mit der Option „--chroot-path“ überschrieben werden, die an das Installationsskript übergeben wird.

  Unzureichender Festplattenspeicher auf der Partition, auf der NSX Tools installiert ist, kann dazu führen, dass das Upgrade der NSX Tools fehlschlägt.

  Problemumgehung: Keine.

• Problem 2875563: Das Löschen der IN_PROGRESS LTA-Sitzung kann zu einem PCAP-Dateiverlust führen.

  Die PCAP-Datei geht verloren, wenn ein LTA mit einer PCAP-Aktion gelöscht wird, während der LTA-Sitzungsstatus „IN_PROGRESS“ lautet. Dies kann dazu führen, dass die /tmp-Partition der ESXi voll ist.

  Problemumgehung: Das Löschen der /tmp-Partition kann helfen.

• Problem 2875667: Das Herunterladen der LTA-PCAP-Datei führt zu einem Fehler, wenn die NSX-/tmp-Partition voll ist.

  Die LTA-PCAP-Datei kann nicht heruntergeladen werden, da die /tmp-Partition voll ist.

  Problemumgehung: Das Löschen der /tmp-Partition kann helfen.

• Problem 2883505: PSOD auf ESXi-Hosts während der NSX V2T-Migration.

  PSOD (Purple Screen of Death) auf mehreren ESXi-Hosts während der V2T-Migration. Das kann zu einem Ausfall des Datenpfads führen.

  Problemumgehung: Keine.

• Problem 2914934: DFW-Regeln für dvPortGroups gehen nach der Migration von NSX-V zu NSX-T verloren.

  Nach einer Migration von NSX-V zu NSX-T wird für alle noch mit vSphere dvPortGroup verbundenen Arbeitslasten keine DFW-Konfiguration durchgeführt.

  Problemumgehung: Nach einer Migration von NSX-V zu NSX-T werden VLAN-Segmente mit einer identischen DFW-Konfiguration konfiguriert. Verwenden Sie die VLAN-Segmente anstelle der dvPortGroups.

  Eine weitere Problemumgehung besteht darin, NSX-V zu deinstallieren und dann NSX-T im reinen Sicherheitsmodus zu installieren. Anschließend können Sie Arbeitslasten auf vorhandenen dvPortGroups verwenden.

• Problem 2921704: Es kann aufgrund des Deadlocks im nginx-Prozess zu einer Spitzenauslastung der Edge-Service-CPU kommen, wenn der L7-Lastausgleichsdienst mit dem IP-Hash-Lastausgleichsalgorithmus verwendet wird.

  Die Backend-Server hinter dem Lastausgleichsdienst können nicht mit verbunden werden.

  Problemumgehung: Wechseln Sie zur L4-Engine, um das Problem zu beheben. Wenn Sie weiterhin den L7-Lastausgleichsdienst verwenden möchten, ändern Sie den Lastausgleichsalgorithmus zu Round-Robin anstelle von ip-hash.

• Problem 2933905: Das Ersetzen eines NSX-T Manager führt dazu, dass die Verbindung der Transportknoten zum Controller unterbrochen wird.

  Das Hinzufügen oder Entfernen eines Knotens im Manager-Cluster kann dazu führen, dass einige Transportknoten die Controller-Verbindung verlieren.

  Problemumgehung: Starten Sie den NSX-Proxy-Dienst auf betroffenen Transportknoten neu, wenn ein Manager zum Verwaltungscluster hinzugefügt oder daraus entfernt wird. Dadurch wird die controller-info.xml neu befüllt und die Controller-Verbindung kann hergestellt werden.

• Problem 2927442: Der Datenverkehr trifft seit dem Upgrade von NSX-T 3.2.0.1 manchmal auf die DFW-Standardablehnungsregel auf VMs auf verschiedenen Hosts und Clustern.

  Nach der Migration von NSX for vSphere zu NSX-T 3.1.3 sind einige PSOD-Probleme aufgetreten. Aus diesem Grund wurde ein Upgrade auf 3.2.0.1 empfohlen. Allerdings wenden die Hosts die Regeln für verteilte Firewalls seitdem nicht mehr konsistent an. Verschiedene Hosts entsprechen unterschiedlichen Regeln, die nicht konsistent sind und nicht erwartet werden.

  Problemumgehung:

  – Wenn die obige Ausnahme auf einem bestimmten Controller auftritt, kann er neu gestartet werden, um das Problem vorübergehend zu beheben.

  – Wenn sich das Problem auf die DFW auswirkt, können oben in der Regelliste Any/Any-Regeln erstellt werden, um unerwünschte greifende Blockregeln zu umgehen.

• Problem 2937810: Der Datenpfaddienst kann nicht gestartet werden und einige Edge-Bridge-Funktionen (z. B. Edge-Bridge-Port) funktionieren nicht.

  Wenn Edge-Bridging auf Edge-Knoten aktiviert ist, sendet die zentrale Steuerungsebene (Central Control Plane, CCP) die DFW-Regeln an die Edge-Knoten, die nur an Hostknoten gesendet werden sollten. Wenn die DFW-Regeln eine Funktion enthalten, die von der Edge-Firewall nicht unterstützt wird, können die Edge-Knoten die nicht unterstützte DFW-Konfiguration nicht verarbeiten, wodurch der Datenpfad nicht gestartet werden kann.

  Problemumgehung: Entfernen oder deaktivieren Sie die DFW-Regeln, die von der Edge-Firewall nicht unterstützt werden.