VMware NSX 4.1.0 | 28 FEB 2023 | Build 21332672

Prüfen Sie, ob Ergänzungen und Updates für diese Versionshinweise zur Verfügung stehen.

Neuigkeiten

NSX 4.1.0 bietet verschiedene neue Funktionen für virtualisierte Netzwerke und Sicherheit für Private Cloud, Public Cloud und Multi Cloud. Zu den Highlights zählen neue Funktionen und Verbesserungen in folgenden Schwerpunktbereichen:

  • IPv6-Unterstützung für die Kommunikation interner NSX-Steuerungs- und Verwaltungsebenen: In dieser Version wird die Kommunikation auf Steuerungsebene und Verwaltungsebene zwischen Transportknoten und NSX Managern über IPv6 eingeführt. In dieser Version muss der NSX Manager-Cluster weiterhin im Dual-Stack-Modus (IPv4 und IPv6) bereitgestellt werden und kann mit Transportknoten (ESXi-Hosts und Edge-Knoten) entweder über IPv4 oder IPv6 kommunizieren. Wenn der Transportknoten mit Dual-Stack (IPv4 und IPv6) konfiguriert ist, wird die IPv6-Kommunikation immer bevorzugt.

  • Mehrmandantenfähigkeit im Benutzeroberflächen-, API- und Alarm-Framework: Mit dieser Version erweitern wir das Nutzungsmodell von NSX durch die Einführung der Mehrmandantenfähigkeit. Dadurch können mehrere Benutzer in NSX ihre eigenen Objekte verbrauchen, ihre eigenen Alarme anzeigen und ihre VMs mit Traceflow überwachen. Dies ist möglich, da der Enterprise-Administrator die Plattform in Projekte segmentieren kann, sodass unterschiedliche Räume für unterschiedliche Benutzer bereitgestellt werden und gleichzeitig die Sichtbarkeit und Kontrolle beibehalten werden.

  • Verbesserungen bei der Integration von Antrea in NSX: Mit NSX 4.1 können Sie Firewall-Regeln sowohl mit K8s- als auch mit NSX-Objekten erstellen. Dynamische Gruppen können auch basierend auf NSX-Tags und K8s-Bezeichnungen erstellt werden. Dies verbessert die Benutzerfreundlichkeit und die Funktionalität bei der Verwendung von NSX zur Verwaltung von Antrea-Clustern.

  • Das Online-Diagnosesystem bietet vordefinierte Runbooks mit Debugging-Schritten zur Fehlerbehebung für bestimmte Probleme. Diese Runbooks können von der API aufgerufen werden und lösen Debugging-Schritte mithilfe der CLI, API und Skripts aus. Im Anschluss an das Debugging erhalten Sie Handlungsempfehlungen, um das Problem zu beheben. Die im Zusammenhang mit dem Debugging erzeugten Artefakte können zur weiteren Analyse heruntergeladen werden. Das Online-Diagnosesystem hilft bei der Automatisierung des Debugging und vereinfacht die Fehlerbehebung. 

Darüber hinaus wurden zu allen Produktteilen viele weitere Funktionen hinzugefügt. Weitere Informationen finden Sie unten in der detaillierten Beschreibung der hinzugefügten Funktionen.

Layer-2-Netzwerk

  • ESXi MultiTEP High Availability: Wenn mehrere TEPs auf einem Hypervisor konfiguriert sind, verfolgt NSX den Status der TEP-IP-Adressen und der BFD-Sitzungen, um ein Failover des Overlay-Datenverkehrs auf einen anderen Uplink zu erstellen. Diese Funktion bietet Hochverfügbarkeit bei Problemen mit physischen Switches wie z. B. ein physischer Switch-Port, der aktiv bleibt, wobei aber die Weiterleitung nicht ordnungsgemäß funktioniert.

Layer-3-Netzwerk

  • Administrative Distanz von BGP: In dieser Version wird die Änderung der Standardwerte für die administrativen Distanz von BGP unterstützt. Die administrative Distanz ist ein beliebiger Wert, der jedem Routing-Protokoll zugewiesen und für die Routenauswahl verwendet wird. Die Möglichkeit, die Admin Distance von BGP-Routen zu ändern, bietet zusätzliche Steuerungsmöglichkeiten bei der Routenauswahl.

  • Nummer des autonomen BGP-Systems (AS) pro Tier-0-VRF-Gateway und BGP-Nachbar: In dieser Version wird die Konfiguration einer anderen BGP-ASN (Autonomous System Number) pro Tier-0-VRF-Gateway und auch pro BGP-Nachbar eingeführt. Das Definieren einer separaten ASN pro VRF und BGP-Peer ist eine wichtige Funktion für Dienstanbieter- und Mehrmandantentopologien, bei denen Endbenutzer ihre eigene BGP-ASN in die Netzwerktopologien einbringen.

  • Inter-VRF-Routing: In dieser Version wird ein fortschrittlicheres VRF Interconnect- und Route Leaking-Modell eingeführt. Mit dieser Funktion können Benutzer das Inter-VRF-Routing mithilfe einfacher Workflows und fein abgestimmter Steuerelemente konfigurieren, indem sie Routen zwischen VRFs dynamisch importieren und exportieren.

  • Autonomer systemweiter eindeutiger BGP-Bezeichner – RFC6286: Diese Version unterstützt die Lockerung der Definition der BGP-Router-ID als 4-Oktet-Ganzzahl ohne Vorzeichen und lockert die Anforderung der "Eindeutigkeit" für eBGP-Peers, wie in RFC 6286 beschrieben.

  • IPv6-Unterstützung für die Kommunikation interner NSX-Steuerungs- und Verwaltungsebenen: In dieser Version wird die Kommunikation auf Steuerungsebene und Verwaltungsebene zwischen Transportknoten und NSX Managern über IPv6 eingeführt. In dieser Version muss der NSX Manager-Cluster weiterhin im Dual-Stack-Modus (IPv4 und IPv6) bereitgestellt werden und kann mit Transportknoten (ESXi-Hosts und Edge-Knoten) entweder über IPv4 oder IPv6 kommunizieren. Wenn der Transportknoten mit Dual-Stack (IPv4 und IPv6) konfiguriert ist, wird die IPv6-Kommunikation immer bevorzugt.

DPU-based Acceleration (DPU-basierte Beschleunigung)

  • UPT V2 ist produktionsbereit für NVIDIA Bluefield-2.

  • Sicherheit

    • NSX Distributed Firewall (statusbehaftete L2- und L3-Firewall) ist für die Produktionsbereitstellung mit DPU-Beschleunigung verfügbar.

    • NSX Distributed IDS/IPS (Tech Preview)

Edge-Knoten-Plattform

  • Unterstützung der Edge-Knoteneinstellungen in der Transportknoten-API

    • Die Edge-Knoten-API ermöglicht Ihnen die Festlegung der folgenden Parameter: Neustartpriorität (Edge-Knoten-VM); coalescingScheme und coalescingParams. Mit dieser Funktion können Kunden die Leistungseinstellungen und die Neustartpriorität über NSX Manager optimieren. Dies gewährleistet Konsistenz für die NSX-Objekteinstellungen, die über NSX Manager ausgeführt werden.

  • Upgrade des Edge-Knoten-Betriebssystems auf Ubuntu 20.04

    • Das Betriebssystem des Edge-Knotens wird auf Ubuntu 20.04 aktualisiert. Dies bietet eine bessere Hardwareunterstützung für Bare Metal Edge.

  • Edge-Plattform: Upgrade der Hardwareversion

    • Während des Upgrades auf NSX 4.1.0 aktualisiert das System Edge-VMs automatisch auf die neueste unterstützte Hardwareversion mit der besten Leistung.

Netzwerkerkennung und Reaktion (NDR)

  • Unterstützung für IDPS-Ereignisse der Gateway-Firewall: Ab NSX 4.1.0 werden IDPS-Ereignisse von der Gateway-/Edge-Firewall von NDR in Korrelationen/Eindringkampagnen verwendet.

Containernetzwerk und Sicherheit

  • Verbesserungen bei der Integration von Antrea zu NSX: Mit NSX 4.1.0 können Sie Firewall-Regeln sowohl für K8s- als auch mit NSX-Objekte erstellen. Dynamische Gruppen können auch basierend auf NSX-Tags und K8s-Bezeichnungen erstellt werden. Dies verbessert die Benutzerfreundlichkeit und die Funktionalität bei der Verwendung von NSX zur Verwaltung von Antrea-Clustern. Sie können jetzt Firewall-Richtlinien erstellen, die Datenverkehr zwischen virtuellen Maschinen und K8s-Pods in einer einzigen Regel zulassen/blockieren. Es wird auch ein neuer Enforcement Point eingeführt, der alle Endpoints umfasst, und die richtige Anwendung wird basierend auf den Zielvorgaben der Quell- und Zielgruppenmitglieder bestimmt. K8s-Netzwerkrichtlinien und -Ebenen im Antrea-Cluster können jetzt im Regelsatz der NSX-Richtlinie angezeigt werden. Darüber hinaus enthält NSX 4.1.0 auch Verbesserungen bei Traceflow und der Benutzeroberfläche, die eine bessere Fehlerbehebung und Verwaltung von K8s-Netzwerkrichtlinien sowie eine echte zentralisierte Verwaltung von K8s-Netzwerkrichtlinien über NSX ermöglichen.

Installation und Upgrade

  • Schnelle Wiederherstellung nach Upgrade-Fehlern: Eine Möglichkeit zur schnellen Wiederherstellung nach einem Fehler während NSX-Upgrades ist die Wiederherstellung in einer Sicherung. Manchmal kann die Nichtverfügbarkeit einer funktionsfähigen Sicherung diesen Vorgang jedoch verzögern, sodass ein langwieriges manuelles Eingreifen erforderlich wird. Mit NSX 4.1 wird eine automatische Sicherung von NSX implizit erstellt und auf der Appliance selbst gespeichert. Das bedeutet, dass der VMware Support bei einem Ausfall NSX mithilfe dieser integrierten Sicherung schnell wieder in einen funktionsfähigen Zustand versetzen kann. 

Betrieb und Überwachung

  • Das Online-Diagnosesystem bietet vordefinierte Runbooks mit Debugging-Schritten zur Fehlerbehebung für bestimmte Probleme. Diese Runbooks können von der API aufgerufen werden und lösen Debugging-Schritte mithilfe der CLI, API und Skripts aus. Im Anschluss an das Debugging erhalten Sie Handlungsempfehlungen, um das Problem zu beheben. Die im Zusammenhang mit dem Debugging erzeugten Artefakte können zur weiteren Analyse heruntergeladen werden. Das Online-Diagnosesystem hilft bei der Automatisierung des Debugging und vereinfacht die Fehlerbehebung.

Die folgenden vordefinierten Runbooks zur Behebung von Problemen mit ESXi Host-Transportknoten sind verfügbar. Sie können über die NSX API aufgerufen werden.

  • Runbooks zur Diagnose von Problemen mit Overlay-Tunnel, Controller-Konnektivitätsproblemen, Port-Blockierung und Problemen bezüglich der pNIC-Leistung.

VPN

  • IPv6-Unterstützung für IPsec-VPN: IPv6-Adressen können jetzt für die IPsec-VPN-Beendigung verwendet werden und bieten einen gesicherten Tunnel-Mechanismus über IPv6-Netzwerke. Über das IPv6-VPN kann NSX sowohl IPv4- als auch IPv6-Daten übertragen.

Guest Introspection

  • Unterstützung für GI-Treiber unter Windows 11: Ab NSX 4.1.0 werden virtuelle Maschinen mit Windows 11-Betriebssystemen für NSX Guest Introspection unterstützt.

Plattformsicherheit

  • Lebenszyklusverwaltung von lokalen Benutzern: Mit dieser Version können Kunden lokale Benutzer dem System hinzufügen und sie daraus entfernen.

  • Sichere Port-Änderungen für Installation und Upgrade: In dieser Version wird der Standard-TCP-Port 8080 für Installation und Upgrades zu TCP-Port 443 geändert, um eine bessere Sicherheit für die Plattform zu bieten.

  • Ersetzung interner Zertifikate: In dieser Version können Kunden die selbstsignierten internen Zertifikate durch von einer Zertifizierungsstelle signierte Zertifikate ersetzen.

Mehrmandantenfähigkeit

  • Mehrmandantenfähigkeit der NSX-Benutzeroberfläche: NSX 4.1.0 ermöglicht die Nutzung der Mehrmandantenfähigkeit über die Benutzeroberfläche für den Enterprise-Administrator (Anbieter) und die Projektbenutzer (Mandanten). 

    • Unterschiedliche Ansichten für verschiedene Benutzer: Sowohl Projektbenutzer (Mandanten) als auch Enterprise-Administratoren (Anbieter) können sich bei NSX anmelden und eine eigene Ansicht verwenden. Die Projektbenutzer sehen keine anderen Projekte oder Anbieterkonfigurationen.

    • Projekt-Switcher: In dieser Version wird oben auf der Benutzeroberfläche ein Dropdown-Menü eingeführt, mit dem Sie den Kontext entsprechend der Benutzer-RBAC von einem Projekt zum nächsten umschalten können. Konfigurationen, die außerhalb von Projekten durchgeführt werden, befinden sich im Standardkontext. Dies ist der Standard für die Rollen, die außerhalb von Projekten konfiguriert sind. Benutzer, die unter "Standard (/)" konfiguriert sind, können alle zu ihrer RBAC zugeordneten Projekte anzeigen und konfigurieren, während Benutzer, die an ein bestimmtes Projekt gebunden sind, nur Zugriff auf ihre eigenen Projekte haben.

  • Bildschirm "Alle Projekte": Zusätzlich zur Möglichkeit, zwischen Projekten zu wechseln, verfügt der Enterprise-Administrator über eine konsolidierte Ansicht mit allen Konfigurationen im System.

  • Projekt-Lebenszyklusverwaltung: Projekte sind optionale Konstrukte, die Mandantenfähigkeit bieten, die vom Enterprise-Administrator auf der NSX-Instanz konfiguriert werden kann.

    • CRUD-Projekt: Möglichkeit zum Erstellen dieser Projekte über die Benutzeroberfläche und zum Anzeigen einer konsolidierten Ansicht aller Projekte und deren Status/Alarme.

    • Benutzerzuteilung: Benutzer und Gruppen können Projekten zugeteilt werden (Benutzer "project_admin_1" ist beispielsweise Projektadministrator für Projekt 1, Projekt 2 und Projekt 4).

    • Kontingent : Kontingente können den verschiedenen Projekten zugeteilt werden, um die Anzahl der verfügbaren Konfigurationen nach Typ zu begrenzen (beispielsweise kann Projekt 1 10 Segmente erstellen).

    • Objektfreigabe: Objekte können vom Unternehmensadministrator aus dem Standardkontext (/infra) für alle oder für bestimmte Projekte freigegeben werden (beispielsweise wird die Gruppe "Gemeinsam genutzte Dienste" für alle Projekte freigegeben).

  • Mehrmandantenfähigkeit für Vorgänge und Überwachung

    • Mehrmandantenfähige Protokollierung für Sicherheitsprotokolle: Einführung der kurzen Protokoll-ID des Projekts. Dies ist eine Bezeichnung für Protokolle, die an ein Projekt angehängt werden. In dieser Version gilt diese kurze Protokoll-ID für die Protokolle der Gateway-Firewall und die Protokolle der verteilten Firewall.

    • Alarme mit mehreren Mandanten: Erweiterung des Alarm-Frameworks zur Unterstützung der Mehrmandantenfähigkeit. Projektadministratoren können jetzt ihre eigenen Alarme im Zusammenhang mit ihren eigenen Konfigurationen visualisieren.

    • Traceflow auf Projektebene: Der Projekt-Administrator kann Traceflow verwenden, um die Konnektivität zwischen seinen Arbeitslasten zu testen. Konfigurationen, die der Provider von außerhalb des Projekts auf sein Objekt anwendet, werden verschleiert.

  • NSX Manager-Plattform

    • Betriebssystem der NSX Manager-Appliance auf Ubuntu 20.04 aktualisieren.

      • Betriebssystem der NSX Manager-Appliance wurde auf Ubuntu 20.04 aktualisiert.

Veraltete Funktionen und APIs, Änderungen des Verhaltens

Ankündigung der Abkündigung für NSX Load Balancer

VMware beabsichtigt, den integrierten NSX Load Balancer einzustellen, und empfiehlt Kunden, so schnell wie möglich zu NSX Advanced Load Balancer (Avi) zu migrieren. VMware NSX Advanced Load Balancer (Avi) bietet eine Obermenge der NSX Load Balancing-Funktionalität und VMware empfiehlt, dass Sie VMware NSX Advanced Load Balancer (Avi) Enterprise erwerben, um Load Balancing auf Unternehmensniveau, GSLB, erweiterte Analysen, Container-Ingress, Anwendungssicherheit und WAF nutzen zu können.

Es wird im Voraus darauf hingewiesen, um es bestehenden Kunden, die den integrierten NSX Load Balancer-Dienst verwenden, nun zu ermöglichen, zu NSX Advanced Load Balancer (Avi) zu migrieren. Die Unterstützung des integrierten NSX Load Balancer-Diensts für Kunden, die NSX-T Data Center 3.x verwenden, bleibt für die Dauer der NSX-T Data Center 3.x-Versionsserie erhalten. Die Unterstützung des integrierten NSX-Load Balancer-Diensts für Kunden mit NSX 4.x bleibt für die Dauer der NSX 4.x-Versionsserie erhalten. Details zu beiden sind in der VMware Product Lifecycle Matrix beschrieben. Es ist nicht beabsichtigt, den integrierten NSX Load Balancer über die letzte NSX 4.x-Version hinaus zu unterstützen.

Weitere Informationen:

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

NSX 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 Manager-APIs und die erweiterten NSX-Benutzeroberflächen in einer kommenden Haupt- oder Nebenversion von NSX zu entfernen. Diese Version wird frühestens ein Jahr nach dem Datum der ursprünglichen Ankündigung am 16.12.2021, allgemein verfügbar sein. NSX 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-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.

Veraltete APIs und Änderungen des Verhaltens

  • Das API-Handbuch zu NSX wurde um neue Seiten zur API-Abkündigung ergänzt, um die API-Nutzung zu vereinfachen. Dort werden die veralteten APIs und Typen sowie die entfernten APIs und Typen aufgelistet.

  • Entfernte APIs: Die folgenden APIs wurden entfernt. Weitere Informationen finden Sie im API-Handbuch zu NSX.

Entfernte API

Ersatz

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

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

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

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

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

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

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

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

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

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

  • Veraltete APIs: Die folgenden APIs sind als veraltet markiert. Weitere Informationen finden Sie im API-Handbuch zu NSX.

Veraltete API

Ersatz

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

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

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

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

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

keine

GET /api/v1/node/services/policy

GET /api/v1/node/services/manager

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

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

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

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

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

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

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

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

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

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

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

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

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

POST /api/v1/batch

keine

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

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

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

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

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

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

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

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

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

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

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

keine

PUT /api/v1/node/services/policy

PUT /api/v1/node/services/manager

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.

Upgrade-Hinweise für diese Version

Anweisungen zum Upgrade von NSX-Komponenten finden Sie im Upgrade-Handbuch für NSX.

  • NSX 4.1.0 ist eine neue Version mit einer Vielzahl neuer Funktionen. Kunden, die diese Funktionen benötigen, sollten ein Upgrade durchführen, um die neue Funktionalität anzunehmen. Kunden, die diese Funktionalität derzeit nicht benötigen, sollten ein Upgrade auf die neueste verfügbare Version von NSX 3.2 (derzeit 3.2.2) durchführen, die weiterhin die empfohlene Version von VMware ist.

  • NSX 4.1.0 wird für mit Kunden mit NSX Cloud, die mit AWS-/Azure-Arbeitslasten bereitgestellt wurde, nicht unterstützt. Verwenden Sie NSX 4.1.0 nicht, um Ihre Umgebung in diesem Szenario zu aktualisieren.

Kunden, die ein Upgrade auf diese Version vornehmen, wird 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. Das Tool wird in den Upgrade-Workflow integriert, bevor Sie mit dem Upgrade der NSX Manager beginnen.

Verfügbare Sprachen

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

Revisionsverlauf der Dokumente

Revisionsdatum

Edition

Änderungen

28. Februar 2023

1

Erstedition

29. März 2023

2

Hinzugefügte bekannte Probleme: 3094405, 3106569, 3113067, 3113073, 3113076, 3113085, 3113093, 3113100, 3118868, 3121377, 3152174, 3152195.

12. Mai 2023

3

Bekanntes Problem 3210316 wurde hinzugefügt.

19. Mai 2023

4

Bekanntes Problem 3116294 wurde hinzugefügt.

1. Juni 2023

5

Die bekannten Probleme 3186573, 3155845 und 3163020 wurden hinzugefügt.

20. Juli 2023

6

Bekanntes Problem 3108693 wurde hinzugefügt.

8. September 2023

7

NSX Manager-Upgrade wurde zu „Neuigkeiten“ hinzugefügt.

14. Dezember 2023

8

Bekanntes Problem 3296976 wurde hinzugefügt.

10. Januar 2024

9

Bekanntes Problem 3222376 wurde hinzugefügt.

7. März 2024

10

Bekanntes Problem 3308657 wurde hinzugefügt.

Behobene Probleme

  • Behobenes Problem 3053647: Edge-Übernahme fehlgeschlagen, weil eines der NSX-V-ESGs während der Migration von NSX for vSphere zu NSX-T ausgeschaltet war.

    Vorgänge, die während der Migration auf ESG ausgeführt werden, schlagen fehl.

  • Behobenes Problem 3048603: UDP-basierter DNS-Datenverkehr hat Sitzungsinformationen erstellt, als neue Verbindungen eingingen, was dazu führte, dass der Arbeitsspeicher nach langer Ausführungszeit erschöpft war.

    Die Nutzung des Datenpfad-Mempools erreicht 100 % und überschreitet damit den Schwellenwert von 85 %.

  • Behobenes Problem 3106018: Die Dienstdatenebene kann in NSX 4.0.0.1 und 4.0.1.1 abstürzen, wenn der Edge ein IGMPv2-Berichtspaket empfängt.

    Der Datenpfad wird neu gestartet und verursacht eine Unterbrechung des Datenverkehrs.

  • Behobenes Problem 3073647: Falsch positiver DNS-Alarm "Zeitüberschreitung bei Weiterleitungs-Upstream-Server" tritt auf, wenn mindestens zwei Upstream-Server konfiguriert sind.

    Der falsch-positive Alarm ist verwirrend. Upstream-Server funktionieren alle ordnungsgemäß.

  • Behobenes Problem 3062615: Beim Löschen des Edge-Transportknotens werden möglicherweise veraltete Einträge in internen Edge-Tabellen hinterlassen.

    NSX Manager reagiert nach dem NSX-Upgrade aufgrund der veralteten Einträge nicht mehr.

  • Behobenes Problem 3059517: Arbeitsspeicherverlust bei der Programmierung von DNS-Übersichtsattributen.

    Je nach Umfang des Datenverkehrs kann dies kontinuierliche Kerne verursachen.

  • Behobenes Problem 3055437: Die SPF-Eigenschaft ist auch dann aktiviert, wenn die Overlay-Transportzone vom Host-Switch entfernt wird.

    VMs verlieren möglicherweise nach vMotion die Konnektivität.

  • Behobenes Problem 3046491: Die Beziehung zwischen IP-Pool und Infra-Segmenten wird während der Löschvalidierung nicht überprüft. Dadurch wird das Löschen von IP-Pools ermöglicht, während sie aktiv von Infra-Segmenten genutzt/referenziert werden, was zur Aufhebung der Zuteilung von IP-Adressen während der Verwendung führt.

    Funktionsbeeinträchtigungen aufgrund des Verlusts von IP-Adressen während der Verwendung durch Infra-Segmente.

  • Behobenes Problem 3044226: Die realisierte Intent-Revision in RealizationState von DhcpRelayConfig wurde nicht aktualisiert.

    Die Benutzeroberfläche zeigt den konsolidierten dhcp-relay-Status als "IN_PROGRESS" an, obwohl das DHCP-Relay ordnungsgemäß funktioniert.

  • Behobenes Problem 3056265: Die NSX Manager-Knotenbereitstellung schlägt mit demselben Hostnamen fehl, der zuvor von einem getrennten NSX Manager-Knoten verwendet wurde.

    Die Bereitstellung von NSX Manager-Knoten wird mit denselben Hostnamen blockiert, die zuvor getrennt wurden.

  • Behobenes Problem 3024587: Auf dem externen Syslog-Server empfangene IDPS-Protokolle werden abgeschnitten, obwohl für die Einstellung remote-host-max-msg-len ein höherer Wert festgelegt wurde.

    Die IDPS-Ereignisse können auf dem externen Syslog-Server in mehrere Zeilen aufgeteilt werden.

  • Behobenes Problem 3008229: Die CLI für den CCP-TN-Zeitüberschreitungssatz verfügt nicht über die Option zur Verwendung der Stundeneinheit.

    Die Stundeneinheit kann in der CLI für die CCP-TN-Zeitüberschreitung nicht verwendet werden.

  • Behobenes Problem 2863105: Eine von HCX verbrauchte Datenverkehrsgruppe kann erst dann aus NSX gelöscht werden, wenn Sie die zugehörigen Entitäten aus HCX gelöscht haben.

    Es ist nicht klar, wie HCX-Datenverkehrsgruppen/Verknüpfungszuordnungen gelöscht werden.

  • Behobenes Problem 3091229: Die EffectiveMembership-Rest-API für cloud-native-service-instances funktioniert nicht für Gruppen, die mehr als zwei CNS-Mitglieder haben.

    Die REST-API für die effektive Mitgliedschaft für CNS-Mitglieder funktioniert nicht wie erwartet.

  • Behobenes Problem 3056889: Statische Routen auf verteilten Routern und/oder Tier-1-Dienstroutern werden nicht an Transportknoten weitergegeben.

    Unterbrechung des Datenverkehrs, der für diese statischen Routen bestimmt ist. Ports von logischen Routern müssen vor der Konfiguration statischer Routen konfiguriert werden.

  • Behobenes Problem 3046448: Regel wird nicht vom ESX Hosts gelöscht, wenn das Löschen der NG-Gruppe auf der MP-Benutzeroberfläche erzwungen wird.

    Firewall-Regel mit gelöschter NSgroup in der Quelle oder im Ziel erzwingt weiterhin die Sicherheitsposition auf ESX-Hosts für alle Quellen bzw. Ziele.

  • Behobenes Problem 3044281: Edge-VM weist einen Fehler aufgrund einer veralteten Hardwarekonfiguration auf. Dies führt zu einem Validierungsfehler, wenn Änderungen an der Manager-Konfiguration angewendet werden.

    Die Edge-Konfiguration kann nicht über die PUT API oder die Benutzeroberfläche des Transportknotens bearbeitet werden, da ein Fehler aufgrund einer veralteten Konfiguration vorliegt.

  • Behobenes Problem 3043150: Veraltete Transportknotendaten werden vom CCP-LCP-Replikator zurückgelassen, nachdem der Transportknoten von MP entfernt wurde.

    Wenn ein neuer Transportknoten von MP hinzugefügt wird und die alte VTEP-IP mit einer anderen VTEP-MAC wiederverwendet wird, führt dies dazu, dass CCP falsche Daten meldet, da veraltete Daten des Transportknotens nicht bereinigt wurden.

  • Behobenes Problem 3037403: Bei Abfragen über RPC GetLportRealizedState überschreibt CCP die VLAN-ID der Bindung mit der VLAN-ID des Segments.

    Wenn Benutzer Adressbindungen abfragen, stellen sie möglicherweise fest, dass sich die VLAN-ID von der in manuellen Bindungen festgelegten VLAN-ID unterscheidet.

  • Behobenes Problem 3013563: Das Ändern des Gruppennamens in AD wirkt sich auf den Datenpfad aus: DFW-Regel wird nicht auf den Benutzer angewendet, der Teil der Gruppe mit geänderten Namen [nach vollständiger/Delta-Synchronisierung] ist.

    Der Datenpfad wird unterbrochen.

  • Behobenes Problem 3008229: Die CLI für den CCP-TN-Zeitüberschreitungssatz verfügt nicht über die Option zur Verwendung der Stundeneinheit.

    Die Stundeneinheit kann in der CLI für die CCP-TN-Zeitüberschreitung nicht verwendet werden.

  • Behobenes Problem 2982055: Mitglieder verschachtelter Gruppen werden auf Intelligence nicht synchronisiert.

    Die Gruppen-Flow-Topologie-API zeigt keine verschachtelten Gruppenmitglieder an.

  • Behobenes Problem 2930122: Bei der Migration von CCP-Daten von GC/HL zu einer höheren Version können Konflikte verursacht werden, was zu falschen Alarmen führen kann.

    Sie werden falsche Alarme zu getrennten Transportknoten bemerken, obwohl diese Knoten miteinander verbunden sind.

  • Behobenes Problem 2863105: Eine von HCX verbrauchte Datenverkehrsgruppe kann erst dann aus NSX gelöscht werden, wenn Sie die zugehörigen Entitäten aus HCX gelöscht haben.

    Es ist nicht klar, wie HCX-Datenverkehrsgruppen/Verknüpfungszuordnungen gelöscht werden.

  • Behobenes Problem 3062600: Der NSX-Proxy wird weiterhin neu gestartet, wenn die Datei controller-info.xml gelöscht wurde/leer ist.

    NSX Proxy wird kontinuierlich neu gestartet und es würde eine kontinuierliche Protokollierung für diesen durchgeführt.

  • Behobenes Problem 3063646: Nestdb-ops-agent-Verbindungsfehler wird auf der Unified Appliance protokolliert.

    Protokolle werden schneller ausgefüllt.

  • Behobenes Problem 3065925: Benutzerdefinierte VRF-RIB wird nicht mit IPv6-ECMP-Routen aufgefüllt.

    Für IPv6-ICMP-Routen fehlen Informationen.

  • Behobenes Problem 3071393: Gateway-Regel mit L7-Zugriffsprofil wird auf Edge nach der Aktivierung/Deaktivierung des Gateways nicht realisiert.

    Gateway-Regel mit L7-Zugriffsprofil wird auf Edge nach der Aktivierung/Deaktivierung des Gateways nicht realisiert.

  • Behobenes Problem 3072735: Die effektive Berechnung des IP Discovery-Profils auf CCP hat nicht wie erwartet Vorrang vor LSP-Profilen -> LS-Profilen -> Gruppenprofilen.

    In DFW-Gruppen können falsche IPs auftreten.

  • Behobenes Problem 3073055: Für Regeln wird versehentlich der Geltungsbereich von DHCP-Definitionen übernommen und sie werden an Edges gesendet.

    Regeln werden auf Edges realisiert, obwohl sie auf der Benutzeroberfläche nicht vorhanden sein sollten.

  • Behobenes Problem 3073457: Der Status des Remote-Tunnel-Endpoints wird nicht aktualisiert.

    Die Konnektivität von BGP-Sitzungen über den Remote-Tunnel-Endpoint ist intakt, es gibt keine Auswirkungen auf den Datenpfad, aber auf der Benutzeroberfläche wird nicht der entsprechende Status angezeigt.

  • Behobenes Problem 3078357: Die Kompatibilität der LM-LM-Version des Verbunds sollte +/-2 sein. CCP unterstützt nur +/-1.

    Zwei Verbund-Sites werden getrennt, wenn eine Site auf Version V und die andere auf Version V+2 oder V-2 ausgeführt wird.

  • Behobenes Problem 3081190: Der Suchdienst verwendet eine Root-Partition auf GM zum Speichern von Daten. Der Festplattenspeicher der Root-Partition wird belegt und ein Alarm wird ausgelöst.

    GM funktioniert nicht mehr ordnungsgemäß, nachdem die Festplatte der Root-Partition zu 100 % belegt ist.

  • Behobenes Problem 3081664: DFW-Regel wird versehentlich an EdgeNode gesendet. Wenn eine der an Edge übertragenen Regeln die falschen Parameter aufweist, kann dies zu einem Absturz der unbefristeten Datenebene führen.

    CCP hat den Downlink-Port als Teil des Geltungsbereichs der FW-Regel berechnet, wenn der logische Switch/LSP in "appliedTo" der Regel verwendet wird. Infolgedessen wird die DFW-Regel versehentlich an EdgeNode gesendet. Wenn eine der an Edge übertragenen Regeln die falschen Parameter aufweist, kann dies zu einem Absturz der unbefristeten Datenebene führen.

  • Behobenes Problem 3057573: Das Anwenden des TN-Profils auf einen vLCM-fähigen Cluster ist fehlgeschlagen.

    Die NSX-Installation ist auf einem LCM-fähigen Cluster fehlgeschlagen, da das Kennwort für das Dienstkonto abgelaufen ist.

  • Behobenes Problem 3046985: Einige Gateway-Firewalldienste werden nicht unterstützt ("MS_RPC_TCP, MS_RPC_UDP, SUN_RPC_TCP, SUN_RPC_UDP, ORACLE_TNS"). Der Veröffentlichungsvorgang schlägt mit einer Fehlermeldung fehl, wenn die Dienste ausgewählt sind.

    Die Dienste können auf der Benutzeroberfläche ausgewählt werden, aber während der Veröffentlichung wird ein Fehler angezeigt: "Nicht unterstützter ALG-Typ (Application Level Gateway): ORACLE_TNS."

  • Behobenes Problem 3040934: Änderungen an den Einstellungen für verteilte Firewall (DFW)/Gateway-Firewall (GWFW) können nicht veröffentlicht werden. Die Schaltfläche zum Veröffentlichen ist deaktiviert, wenn die verteilte Firewall (DFW)/Gateway-Firewall (GWFW) deaktiviert ist.

    Konfigurationsänderungen können nicht veröffentlicht werden, da Firewall (DFW)/Gateway-Firewall (GWFW) deaktiviert ist.

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

  • Behobenes Problem 3068125: Wenn BGP über die VTI-Schnittstelle in einer Edge-Bereitstellung im Modus "Aktiv/Standby" konfiguriert ist, wird erwartet, dass BGP auf dem Standby-Edge-Knoten inaktiv ist, aber auf dem Standby-Edge-Knoten wird weiterhin ein aktiver Alarm vom Typ "BGP inaktiv" generiert.

    Keine funktionalen Auswirkungen. Auf dem Standby-Edge-Knoten tritt jedoch ein falscher Alarm vom Typ "BGP inaktiv" auf.

  • Behobenes Problem 3057573: Das Anwenden des TN-Profils auf einen vLCM-fähigen Cluster ist fehlgeschlagen.

    Die NSX-Installation ist auf einem LCM-fähigen Cluster fehlgeschlagen, da das Kennwort für das Dienstkonto abgelaufen ist.

  • Behobenes Problem 3047608: Nach der Bereitstellung der CSM-Appliance kann nach der Anmeldung nicht mehr auf die CSM-Benutzeroberfläche zugegriffen werden und der nsx-cloud-service-Verwaltungsdienst ist inaktiv.

    Die Day0-CSM-Benutzeroberfläche ist nach der Anmeldung inaktiv.

  • Behobenes Problem 3045514: Flows von NSX-gestützten VMs können in vRNI nicht angezeigt werden.

    Der Benutzer kann keine Flows von NSX-gestützten VMs in vRNI anzeigen.

  • Behobenes Problem 3042523: Die von vm-tools für Segmentports von virtuellen Maschinen bereitgestellten erkannten Bindungen (IP-Adressen) sind leer, während Storage vMotion ausgeführt wird.

    Alle DFW-Regeln, die auf erkannten IP-Adressen von vm-tools als Quelle basieren, gelten während Storage vMotion der virtuellen Maschine nicht für IP.

  • Behobenes Problem 3038658: Wenn eine Wiederherstellung in einem 1K-Hypervisor-Skalierungs-Setup durchgeführt wird, stürzt der NSX-Dienst (Proton) aufgrund von OOM-Problemen ab.

    Der Wiederherstellungsvorgang läuft möglicherweise länger, wenn der NSX-Dienst neu gestartet wird.

  • Behobenes Problem 3027580: Wenn DVPGs in vCenter Server gelöscht werden, die an Hosts angehängt sind, die Teil eines für die Sicherheit vorbereiteten Clusters sind und erkannten Segmenten zugeordnet sind, die Teil von Bestandslistengruppen sind, werden die erkannten Segmente nie bereinigt.

    Es gibt keine funktionalen Auswirkungen. Die NSX Manager-Benutzeroberfläche zeigt veraltete Objekte an.

  • Behobenes Problem 3027473: 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.

  • Behobenes Problem 3025367: Wenn das Uplink-Profil über vier aktive Uplinks verfügt und in der TN-Konfiguration nur zwei Uplinks für die VDS Uplink-Zuordnung bereitgestellt werden, werden vier vmks auf der Hostseite erstellt.

    Keine Auswirkung auf die Funktionalität.

  • Behobenes Problem 3024658: Bei der Verarbeitung von Paketen mit SMB-Datenverkehr generiert NSX IDS/IPS eine hohe CPU-Nutzung und Latenz.

    In einigen Fällen stürzt der NSX IDS/IPS-Prozess aufgrund eines Fehlers wegen zu wenig Arbeitsspeicher bei der Verarbeitung von SMB-Datenverkehr ab.

  • Behobenes Problem 3024136: Änderungen in der VRF-BGP-Konfiguration werden nicht immer wirksam.

    Änderungen in der BGP-Konfiguration innerhalb einer VRF werden nicht immer wirksam.

  • Behobenes Problem 3024129: Globale Manager-Alarme werden häufig ausgelöst.

    Alarme werden ausgelöst, sobald ein Alarm gelöst wurde.

  • Behobenes Problem 3019893: NGINX stürzt ab, nachdem die Persistenz des Load Balancer deaktiviert wurde.

    Eine neue Verbindung kann aufgrund eines Deadlocks nicht hergestellt werden.

  • Behobenes Problem 2963524: UDP-Verbindungen werden nicht gemäß ihrer Ablaufzeitüberschreitung gelöscht.

    Auf der Benutzeroberfläche wird kein Feedback angezeigt.

  • Behobenes Problem 2947840: In der Netzwerktopologieansicht werden nicht alle Netzwerkkomponenten auf der Benutzeroberfläche angezeigt.

    Die vollständige Netzwerktopologie wird nicht angezeigt.

  • Behobenes Problem 2928725: IDPS-Signaturdownloads funktionieren nicht mit einem Proxy, der einen bestimmten Port verwendet.

    Der Aufruf zum Herunterladen der Signatur über den Proxy wurde für den NTICS-Server nicht zugelassen.

  • Behobenes Problem 3034373: Das DFW-IPFIX-Profil bleibt nach dem Upgrade von älteren Versionen als 3.2.0 auf 3.2.x oder 4.0.x beim Löschen hängen.

    DFW-IPFIX-Profile können nicht gelöscht werden.

  • Behobenes Problem 3043151: Die L7-Klassifizierung der Firewall-Flows ist möglicherweise für einen kurzen Zeitraum nicht verfügbar, wenn das System auf hohen Datenverkehr stößt, der die APPId ermitteln muss

    L7-Regeln werden auf Hosts, auf denen hoher Datenverkehr herrscht, möglicherweise nicht angewendet.

  • Behobenes Problem 3039159: vMotion von VMs mit Schnittstelle im UPT-Modus (Uniform Passthrough) und mit einer hohen Anzahl von Flows kann zu PSOD beim Host führen.

    Ein Host-PSOD wirkt sich während des vMotion von UPT-basierten VMs mit einer hohen Anzahl an Flows auf den Datenverkehr aus.

  • Behobenes Problem 3047608: Nach der Bereitstellung der CSM-Appliance kann nach der Anmeldung nicht mehr auf die CSM-Benutzeroberfläche zugegriffen werden und der nsx-cloud-service-Verwaltungsdienst ist inaktiv.

    Die Day0-CSM-Benutzeroberfläche ist nach der Anmeldung inaktiv.

  • Behobenes Problem 3027580: Wenn DVPGs in vCenter Server gelöscht werden, die an Hosts angehängt sind, die Teil eines für die Sicherheit vorbereiteten Clusters sind und erkannten Segmenten zugeordnet sind, die Teil von Bestandslistengruppen sind, werden die erkannten Segmente nie bereinigt.

    Es gibt keine funktionalen Auswirkungen. Die NSX Manager-Benutzeroberfläche zeigt veraltete Objekte an.

  • Behobenes Problem 3042382: Die Sitzung sollte erneut gesucht werden, wenn das Paket der No-SNAT-Regel entspricht.

    Der mit der No-SNAT-Regel übereinstimmende Datenverkehr bleibt hängen.

  • Behobenes Problem 3044704: NSX-Manager unterstützt nur HTTP-Proxys ohne SSL-BUMP, auch wenn die Konfigurationsseite ein HTTPS-Schema und ein -Zertifikat verwendet.

    Wenn Sie den Proxy über System -> Allgemeine Einstellungen -> Internet-Proxyserver konfiguriert haben, mussten Sie Details für Schema (HTTP oder HTTPS), Host, Port usw. angeben.

    Schema bezeichnet hier den Verbindungstyp, den Sie zwischen NSX Manager und dem Proxyserver herstellen möchten. Es bezieht sich nicht auf die Art des Proxyservers. In der Regel verwendet der HTTPS-Proxy das HTTPS-Schema. Proxyserver wie Squid, die mit http_port + SSL-Bump konfiguriert sind, stellen jedoch auch die HTTPS-Verbindung zwischen NSX-Manager und dem Proxyserver her. Dienste in NSX-Manager gehen jedoch immer davon aus, dass der Proxy mit dem HTTP-Port angezeigt wird. Daher wird das von Ihnen angegebene Zertifikat niemals in NSX Manager verwendet.

    Wenn Sie das HTTPS-Schema auswählen und das Zertifikat bereitstellen, zeigt das System den Fehler „Zertifikat xx ist kein gültiges Zertifikat für xx“ für einen HTTPS-Proxy auf der Konfigurationsseite an.

    Es wird kein Fehler angezeigt, wenn Sie versuchen, einen Squid-Proxy mit http_port + SSL-Bump zu verwenden, aber NSX Manager-Dienste können keine Anforderung an externe Server senden („Zertifikatskette kann nicht gefunden werden“ wird im Protokoll angezeigt)

  • Behobenes Problem 3025104: Der Host wechselt in den Status „Fehlgeschlagen“, wenn Sie eine Wiederherstellung mit einer anderen IP, aber mit demselben FQDN durchführen.

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

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

Bekannte Probleme

  • Problem 3308657: Beim Erstellen von Firewallabschnitten mit einer sehr großen Anzahl von Regeln dauert die API-Antwort zum Erstellen/Löschen von Regeln länger als 30 Minuten.

    Diese Verlangsamung führt zu 409/500-Fehlern oder zu einer Verlangsamung in API-Ausführungen für PODS.

    Problemumgehung: Reduzieren Sie die Anzahl der Regeln in einem Abschnitt.

  • Problem 3222376: Die NSX Funktion „Status überprüfen“ auf der Benutzeroberfläche der LDAP-Konfiguration meldet einen Fehler beim Herstellen einer Verbindung mit Windows Server 2012/Active Directory. Die Ursache dafür liegt darin, dass Windows 2012 nur schwächere TLS-Verschlüsselungssuites unterstützt, die aus Sicherheitsgründen von NSX nicht mehr unterstützt werden.

    Auch wenn eine Fehlermeldung angezeigt wird, funktioniert die LDAP-Authentifizierung über SSL, da sich der Satz der vom LDAP-Authentifizierungscode verwendeten Verschlüsselungssuites, von dem Satz unterscheidet, der vom Link „Status prüfen“ verwendet wird.

    Problemumgehung: Weitere Details finden Sie im Knowledgebase-Artikel 92869.

  • Problem 3296976: Die Gateway-Firewall lässt möglicherweise die Verwendung nicht unterstützter Layer-7-App-IDs als Teil von Kontext-/L7-Zugriffsprofilen zu.

    Auf der folgenden Dokumentationsseite finden Sie eine Liste der App-IDs, die für die einzelnen NSX-Versionen unterstützt werden – https://docs.vmware.com/de/NSX-Application-IDs/index.html.

    Problemumgehung: Keine.

  • Problem 3108693: Der Projektadministrator kann die DNS-Weiterleitungsfunktion nicht über die Benutzeroberfläche konfigurieren.

    Wenn Sie als Projektadministrator eingeloggt sind, werden T1s, die unter den Projektbereich fallen, nicht im Dropdown-Menü auf der Seite „DNS-Weiterleitung“ aufgeführt. Infolgedessen ist der Projektadministrator nicht in der Lage, die DNS-Weiterleitungsfunktion über die Benutzeroberfläche zu konfigurieren.

    Problemumgehung:

    1. Der Projektadministrator kann die gleiche Funktionalität über die API ausführen.

    2. Der Enterprise-Administrator kann DNS-Dienste im Projektbereich erstellen.

  • Problem 3186573: CorfuDB-Datenverlust.

    Plötzlicher Verlust einiger Konfigurationen. Einige Konfigurationen können nicht erstellt/aktualisiert werden.

    Problemumgehung: Weitere Details finden Sie im Knowledgebase-Artikel 92039.

  • Problem 3163020: Wenn sich der FQDN in DNS-Paketen bei der Groß-/Kleinschreibung mit den in den L7-Profilen der FQDN-Regeln konfigurierten Domänennamen unterscheidet, werden die DFW-FQDN-Regelaktionen nicht ordnungsgemäß angewendet.

    DFW-FQDN-Regelaktionen werden nicht ordnungsgemäß angewendet. Die DFW-FQDN-Filterung funktioniert nicht ordnungsgemäß.

    Problemumgehung: Konfigurieren Sie den FQDN im L7-Kontextprofil so, dass er mit dem Domänennamen im DNS-Paket übereinstimmt.

  • Problem 3155845: PSOD während vMotion, wenn die FQDN-Filterung konfiguriert ist.

    ESXi-Host wird neu gestartet.

    Problemumgehung: Entfernen Sie die FQDN-Konfiguration.

  • Problem 3116294: Regel mit verschachtelter Gruppe funktioniert auf Hosts nicht wie erwartet.

    Datenverkehr nicht zulässig oder ordnungsgemäß übersprungen.

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

  • Problem 3210316: Die vIDM-Konfiguration wird gelöscht, wenn (1) der Manager ein Dual-Stack-IPv4/IPv6 ist und (2) keine VIP-Adresse konfiguriert ist und (3) Sie in der vIDM-Konfiguration eine IP-Adresse anstelle eines FQDN für das Feld "NSX Appliance" in der eingeben.

    Sie können sich erst dann mit vIDM anmelden, wenn die vIDM-Konfiguration neu konfiguriert wurde.

    Problemumgehung: Verwenden Sie im Feld "NSX Appliance" den FQDN.

  • Problem 3152195: DFW-Regeln mit Kontextprofilen mit FQDN vom Typ .*XYZ.com können nicht erzwungen werden.

    Die Erzwingung der DFW-Regel funktioniert in diesem spezifischen Szenario nicht wie erwartet.

    Problemumgehung: Keine.

  • Problem 3152174: Die Hostvorbereitung mit VDS schlägt mit folgendem Fehler fehl: Host {UUID} wird nicht zum VDS-Wert hinzugefügt.

    Wenn auf vCenter Netzwerke in Ordnern verschachtelt sind, können Migrationen von NVDS zu CVDS oder von NSX-V zu NSX-T fehlschlagen, wenn die Migration auf CVDS in NSX-T erfolgt.

    Problemumgehung: Das erste Netzwerk des Hosts ist das erste Netzwerk, das im Netzwerkfeld auf der vCenter MOB-Seite https://<VC-IP>/mob?moid=host-moref angezeigt wird

    • Vor 3.2.1: Das erste oben erwähnte Netzwerk des Hosts und des betroffenen VDS sollte sich direkt unter demselben Ordner befinden. Der Ordner kann entweder "DataCenter" oder ein Netzwerkordner innerhalb von "DataCenter" sein.

    • Ab 3.2.1 und 4.0.0: Das erste Netzwerk des Hosts sollte sich wie oben erwähnt direkt unter einem Ordner befinden und der gewünschte VDS kann sich direkt unter demselben Ordner befinden oder im selben Ordner verschachtelt werden. Der Ordner kann entweder "DataCenter" oder ein Netzwerkordner innerhalb von "DataCenter" sein.

  • Problem 3118868: Falsche oder veraltete vNIC-Filter, die auf pNIC programmiert werden, wenn Overlay-Filter ungefähr zur gleichen Zeit programmiert werden, während eine pNIC aktiviert ist.

    Auf pNIC programmierte vNIC-Filter sind möglicherweise veraltet, falsch oder fehlend, wenn Overlay-Filter ungefähr zur gleichen Zeit programmiert werden, während eine pNIC aktiviert ist, was zu einer möglichen Leistungsregression führt.

    Problemumgehung: Keine.

  • Problem 3113100: Die IP-Adresse wird für einige VMs in den dynamischen Sicherheitsgruppen aufgrund eines veralteten VIF-Eintrags nicht realisiert.

    Wenn ein Cluster anfänglich mit Schnellstart für Netzwerk und Sicherheit eingerichtet, deinstalliert und dann nur für Sicherheit neu installiert wurde, funktionieren DFW-Regeln möglicherweise nicht wie vorgesehen. Dies liegt daran, dass die für Netzwerk und Sicherheit erstellte automatische TZ weiterhin vorhanden ist und entfernt werden muss, damit die DFW-Regeln ordnungsgemäß funktionieren.

    Problemumgehung: Löschen Sie die automatisch generierte TZ aus dem Schnellstart für Netzwerk und Sicherheit, der auf denselben DVS verweist, der nur für Sicherheit verwendet wird.

  • Problem 3113093: Neu hinzugefügte Hosts sind nicht für die Sicherheit konfiguriert.

    Wenn nach der Installation der Sicherheit ein neuer Host zu einem Cluster hinzugefügt und mit dem Distributed Virtual Switch verbunden wird, löst er nicht automatisch die Installation von NSX auf diesem Host aus.

    Problemumgehung: Aktualisieren Sie den vorhandenen VDS in VC (oder) fügen Sie einen neue VDS in VC hinzu und fügen Sie alle Hosts im Cluster zum VDS hinzu. Dadurch wird das TNP automatisch aktualisiert und das TNP wird erneut auf die TNC angewendet. Wenn die TNC aktualisiert wird, verfügt der neu hinzugefügte Host über die neueste TNP-Konfiguration.

  • Problem 3113085: DFW-Regeln werden bei vMotion nicht auf die VM angewendet.

    Wenn eine von DFW geschützte VM in einer Bereitstellung mit Security-Only-Installation mit vMotion von einem Host auf einen anderen verlagert wird, werden die DFW-Regeln möglicherweise nicht auf dem ESX-Host erzwungen, was zu einer falschen Klassifizierung der Regel führt.

    Problemumgehung: Verbinden Sie die VM mit einem anderen Netzwerk und verbinden Sie sie dann erneut mit der Ziel-DVPortgroup.

  • Problem 3113076: Für FRR-Daemon-Abstürze werden keine Core-Dumps erstellt.

    Bei FRR-Daemon-Abstürzen werden keine Core-Dumps vom System im Verzeichnis /var/dump erstellt. Dies kann dazu führen, dass ein BGP-Flap auftritt.

    Problemumgehung: Aktivieren Sie den Core-Dump für die FRR-Daemons, lösen Sie einen Absturz aus und rufen Sie den Core-Dump aus /var/dump ab.

    Verwenden Sie zum Aktivieren des Core-Dumps den folgenden Befehl auf dem Edge-Knoten, der als Root-Benutzer auf dem Edge-Knoten ausgeführt werden muss.

    prlimit --pid <pid of the FRR daemon> --core=500000000:500000000

    Um zu überprüfen, ob der Core-Dump für den FRR-Daemon aktiviert ist, verwenden Sie den folgenden Befehl und überprüfen Sie die SOFT- und HARD-Grenzwerte für die CORE-Ressource. Diese Grenzwerte müssen 500.000.000 Byte oder 500 MB betragen.

    prlimit --pid <pid of the FRR daemon>

  • Problem 3113073: DFW-Regeln werden nach dem Aktivieren des Sperrmodus für einige Zeit nicht erzwungen.

    Das Aktivieren des Sperrmodus auf einem Transportknoten kann zu einer Verzögerung bei der Erzwingung von DFW-Regeln führen. Dies liegt daran, dass bei aktiviertem Sperrmodus auf einem Transportknoten die zugeordnete VM möglicherweise aus der NSX-Bestandsliste entfernt und dann neu erstellt wird. Während dieser Zeitlücke werden DFW-Regeln möglicherweise nicht auf den VMs erzwungen, die mit diesem ESXi-Host verknüpft sind.

    Problemumgehung: Fügen Sie „da-user“ manuell zur Ausnahmeliste hinzu, bevor Sie ESX in den Sperrmodus versetzen.

  • Problem 3113067: Nach vMotion kann keine Verbindung zu NSX-T Manager hergestellt werden.

    Beim Upgrade von NSX vor NSX 3.2.1 werden NSX Manager-VMs nicht automatisch zur Firewall-Ausschlussliste hinzugefügt. Dies führt dazu, dass alle DFW-Regeln auf Manager-VMs angewendet werden, was zu Problemen mit der Netzwerkkonnektivität führen kann.

    Dieses Problem tritt bei neuen Bereitstellungen ab NSX 3.2.2 oder höher nicht auf. Wenn Sie jedoch ein Upgrade von NSX 3.2.1 oder früheren Versionen auf eine beliebige Zielversion bis einschließlich NSX 4.1.0 durchführen, kann dieses Problem auftreten.

    Problemumgehung: Wenden Sie sich an den VMware Support.

  • Problem 3106569: Die Leistung erreicht im EVPN-Routenserver-Modus nicht die erwarteten Werte.

    Auf pNIC programmierte vNIC-Filter sind möglicherweise veraltet, falsch oder fehlend, wenn Overlay-Filter in einer Gruppierungssituation auf die pNIC programmiert werden, was zu einer möglichen Leistungsregression führt.

    Problemumgehung: Keine.

  • Problem 3094405: Falsche oder veraltete vNIC-Filter, die auf pNIC programmiert sind, wenn Overlay-Netzwerke konfiguriert sind.

    vNIC-Overlay-Filter werden in einer bestimmten Reihenfolge aktualisiert. Wenn Updates in schneller Folge stattfinden, wird nur das erste Update beibehalten, und nachfolgende Updates werden verworfen, was zu einer falschen Filterprogrammierung und einer möglichen Leistungsregression führt.

    Problemumgehung: Keine.

  • Problem 3121377: PSOD auf ESX.

    Inaktiver Transportknoten, der den Datenverkehr beeinträchtigt.

    Problemumgehung:

    1. Ändern Sie die Arbeitslastkonfiguration, um das Senden von Datenverkehr an den ersten Hop-Router für Peer im selben Segment zu vermeiden.

    2. Akzeptieren Sie ICMP6-Umleitungen ordnungsgemäß vom Router des ersten Hops.

  • Problem 3098639: Das Upgrade von NSX Manager schlägt fehl, da der Reverse-Proxy-/Authentifizierungsdienst während des Upgrades nicht in den Wartungsmodus versetzt werden kann.

    Upgrade-Fehler von nsx-manager.

    Problemumgehung: Weitere Details finden Sie im Knowledgebase-Artikel 91120.

  • Problem 3114329: Intel QAT wird nach der Installation von Bare Metal NSX Edge nicht gestartet.

    Intel QuickAssist Technology (QAT) ist eine Hardwarebeschleunigungstechnologie, die entwickelt wurde, um rechenintensive kryptografische Algorithmen und Komprimierungs-/Dekomprimierungsalgorithmen von der CPU auf dedizierte Hardware auszulagern. Aufgrund dieses Problems können Sie Intel QAT nicht verwenden, um die Durchsatzleistung des VPN-Diensts mit Bare Metal NSX Edge zu verbessern.

    Problemumgehung: Keine.

  • Problem 3106950: Nach Erreichen des DFW-Kontingents schlägt die Erstellung einer neuen VPC im Projektbereich fehl.

    Sie können keine VPC unter dem Projekt erstellen, in dem das DFW-Kontingent erreicht wurde.

    Problemumgehung: Keine.

  • Problem 3094463: Eine Stateless Firewall-Regel mit ALG-Dienst-FTP kann über die veraltete MP-API erstellt werden. Dieser Vorgang wird über die Richtlinien-API nicht unterstützt.

    Im Falle problematischer Firewall-Regeln auf MP können Sie keine Migration von MP zur Richtlinie durchführen.

    Problemumgehung: Die problematische Firewall-Regel sollte aktualisiert werden, um statusbehaftet zu sein oder über keinen FTP-Dienst des ALG-Diensts zu verfügen.

  • Problem 3083358: Es dauert lange, bis der Controller dem Cluster nach dem Controller-Neustart beitritt.

    Nach dem Neustart des Controllers kann es bei den auf NSX Manager erstellten neuen Konfigurationen zu einer Realisierungsverzögerung kommen, da das Starten des Controllers einige Zeit in Anspruch nehmen kann.

    Problemumgehung: Entfernen Sie redundante böswillige IP-Gruppen und starten Sie neu.

  • Problem 3106317: Wenn eine VNIC-MAC-Adresse im Gastbetriebssystem geändert wird, werden die Änderungen möglicherweise nicht in den Filtern widergespiegelt, die für PNIC programmiert sind.

    Potenzielle Leistungsbeeinträchtigung.

    Problemumgehung: Deaktivieren Sie die Schnittstelle im Gastbetriebssystem und aktivieren Sie sie dann erneut.

  • Problem 3047727: CCP hat die aktualisierte RouteMapMsg nicht veröffentlicht.

    Routen, die nicht für die Veröffentlichung vorgesehen waren, werden veröffentlicht.

    Problemumgehung: Keine.

  • 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 3092154: Die aktuelle Netzwerkkarte unterstützt keinen IPv6-Routing-Erweiterungsheader.

    Jeder IPv6-Datenverkehr mit Routing-Erweiterungsheadern wird von der intelligenten Netzwerkkarte verworfen.

    Problemumgehung: Keine.

  • Problem 3079932: MTU-Änderung kann mit einer hohen Skalierung ausgelagerter TCP-Flows über UPT-Schnittstellen fehlschlagen.

    Bei einer hohen Skalierung von ausgelagerten TCP-Flows über UPT-Schnittstellen kann die MTU-Änderung manchmal fehlschlagen.

    Problemumgehung:

    1. Nehmen Sie während des Datenverkehrs keine MTU-Änderung vor.

    2. Sie können auch die Hardware-Offload-Funktion deaktivieren und anschließend eine MTU-Änderung durchführen.

  • Problem 3077422: SmartNIC-gestützte VMs und Ports werden in LTA nicht aufgelistet, da LTA auf smartNIC-gestützten VMs und Ports nicht unterstützt wird.

    LTA kann auf bestimmten VMs nicht erstellt werden.

    Problemumgehung: Keine.

  • Problem 3076771: "get physical-ports <physical-port-name> stats verbose" zeigt den Wert 0 für die Statistiken pro Warteschlange an.

    Unerwartete Nullwerte werden angezeigt, wenn die ausführlichen Portstatistiken für das Debugging verwendet werden.

    Problemumgehung: Sofern verfügbar, zeigt "get physical-ports <physical-port-name> xstats" Statistiken pro Warteschlange für die physischen Ports an.

  • Problem 3069003: Eine übermäßige Anzahl an LDAP-Vorgängen im LDAP-Verzeichnisdienst des Kunden bei Verwendung verschachtelter LDAP-Gruppen.

    Hohe Auslastung des LDAP-Verzeichnisdienstes in Fällen, in denen verschachtelte LDAP-Gruppen verwendet werden.

    Problemumgehung: Verwenden Sie für vROPS vor Version 8.6 den lokalen Benutzer "admin" anstelle eines LDAP-Benutzers.

  • Problem 3068100: Routenverluste werden nur im Falle eines symmetrischen Routings unterstützt. Asymmetrische Routenverluste zwischen VRFs können zu einem Datenverkehrsverlust führen.

    Wenn die VRF-Routen asymmetrisch zwischen den Edge-Knoten innerhalb des Clusters sind, werden solche asymmetrischen Routen nicht über den Edge-Cluster hinweg synchronisiert, obwohl das Inter-SR-Routing aktiviert ist. Diese Bedingung kann potenziell einen Datenverkehrsverlust von Süd nach Nord verursachen.

    Problemumgehung: Stellen Sie sicher, dass die Routen symmetrisch an alle Edge-Knoten im Cluster weitergegeben werden. In diesem Beispiel sollten die Präfixe 2.1.4.0/24 und 2.1.5.0/24 an die Edges e1 und e2 weitergegeben werden.

  • Problem 2855860: Der Edge-Datenpfad beendet die Weiterleitung auf unbestimmte Zeit, wenn das Edge-Dateisystem in den schreibgeschützten Modus wechselt.

    Verlust des Datenverkehrs. Der Zugriff auf die Edge-VM-Konsole kann darauf hindeuten, dass das Dateisystem in den schreibgeschützten Modus gewechselt ist.

    Problemumgehung: Keine.

  • Probleme 3046183 und 3047028: Nach der Aktivierung oder Deaktivierung einer der NSX-Funktionen, die auf der NSX Application Platform gehostet werden, ändert sich der Bereitstellungsstatus der anderen gehosteten NSX-Funktionen auf In Progress. Dies betrifft die NSX-Funktionen „NSX Network Detection and Response“, „NSX Malware Prevention“ und „NSX Intelligence“.

    Nach der Bereitstellung der NSX Application Platform führt die Aktivierung oder Deaktivierung der Funktion „NSX Network Detection and Response“ dazu, dass sich die Bereitstellungsstatus der Funktionen „NSX Malware Prevention“ und „NSX Intelligence“ in In Progress ändern. Ebenso führt das Aktivieren und Deaktivieren der NSX Malware Prevention-Funktion dazu, dass der Bereitstellungsstatus der NSX Network Detection and Response-Funktion auf In Progress geändert wird. Wenn NSX Intelligence aktiviert ist und Sie NSX Malware Prevention aktivieren, ändert sich der Status für die NSX Intelligence-Funktion in Down und Partially up.

    Problemumgehung: Keine. Das System wird eigenständig wiederhergestellt.

  • Problem 3041672: Sobald alle Migrationsphasen erfolgreich sind, rufen Sie für reine Konfigurations- und DFW-Migrationsmodi APIs nach der Migration auf, um Arbeitslasten zu verschieben. Wenn Sie die Anmeldedaten von NSX for vSphere, vCenter Server oder NSX ändern, nachdem die Migrationsphasen erfolgreich waren, schlägt der Aufruf der APIs für die Vor- und Nachmigration fehl.

    Sie können die Arbeitslasten nicht verschieben, da die API-Aufrufe vor der Migration, nach der Migration und zum Abschließen der Infrastruktur fehlschlagen.

    Problemumgehung: Führen Sie diese Schritte durch.

    1. Starten Sie den Migrationskoordinator neu.

    2. Geben Sie auf der Migrationsbenutzeroberfläche unter Verwendung desselben Migrationsmodus wie vor dem Neustart alle Authentifizierungsdetails an. Dadurch sollte der Migrationsfortschritt wieder synchronisiert werden.

    3. Führen Sie die APIs vor der Migration, nach der Migration und zum Abschließen der Infrastruktur aus.

  • Problem 3043600: Die NSX Application Platform-Bereitstellung schlägt fehl, wenn Sie ein privates (nicht standardmäßiges) Harbor-Repository mit einem selbstsignierten Zertifikat von einer weniger bekannten Zertifizierungsstelle verwenden.

    Wenn Sie versuchen, die NSX Application Platform mithilfe eines privaten (nicht standardmäßigen) Harbor-Repositorys mit einem selbstsignierten Zertifikat von einer weniger bekannten Zertifizierungsstelle bereitzustellen, schlägt die Bereitstellung fehl, da der Bereitstellungsauftrag die Helm-Diagramme und Docker-Images der NSX Application Platform nicht abrufen kann. Da die NSX Application Platform nicht erfolgreich bereitgestellt wurde, können Sie keine der NSX-Funktionen aktivieren (wie z. B. NSX Intelligence), die die Plattform hostet.

    Problemumgehung: Verwenden Sie eine bekannte vertrauenswürdige Zertifizierungsstelle, um das Zertifikat zu signieren, das Sie für Ihren privaten Harbor-Server verwenden.

  • Problem 2491800: Zertifikatattribute des Async Replicator-Kanalports werden nicht regelmäßig auf Ablauf oder Widerruf überprüft.

    Dies kann dazu führen, dass ein abgelaufenes/widerrufenes Zertifikat für eine vorhandene Verbindung verwendet wird.

    Problemumgehung: Bei jeder erneuten Verbindung werden die neuen Zertifikate verwendet (sofern vorhanden) oder es wird ein Fehler ausgegeben, da das alte Zertifikat abgelaufen ist oder widerrufen wurde. Um die erneute Verbindung auszulösen, ist ein Neustart des Appliance Proxy Hubs (APH) auf dem Manager-Knoten ausreichend.

  • Problem 2994066: Fehler beim Spiegeln von vmknic auf ESXi 8.0.0.0 und NSX 4.0.1 und höher.

    L3SPAN mit Spiegelungs-Stack kann nicht aktiviert werden, da vmknic nicht gespiegelt werden kann.

    Problemumgehung:

    1. Erstellen Sie an der ESXi-CLI-Eingabeaufforderung einen Spiegelungs-Stack auf ESXi.

    2. Erstellen Sie im vSphere Web Client eine vmknic.

    3. Führen Sie den folgenden Befehl aus:

    esxcli network ip netstack add -N mirror

  • Problem 3007396: Wenn der Remote-Knoten auf den langsamen LACP-Zeitüberschreitungsmodus festgelegt ist, kann es zu einem Datenverkehrsverlust von etwa 60 bis 90 Sekunden kommen, nachdem Sie einen der LAG-Links über den CLI-Befehl „esxcli network nic down -n vmnicX“ deaktiviert haben.

    Datenverkehrsverlust von etwa 60 bis 90 Sekunden, nachdem wir einen der LAG-Links über den CLI-Befehl „esxcli network nic down -n vmnicX“ deaktiviert haben.

    Das Problem tritt nur auf, wenn die LACP-Zeitüberschreitung des Remote-Knotens auf den SLOW-Modus festgelegt ist.

    Problemumgehung: Legen Sie die LACP-Zeitüberschreitung für den externen Switch auf FAST fest.

  • Problem 3013751: NSX-Installations-/Deinstallationsfortschritt wird auf der Fabric-Seite nicht automatisch angezeigt.

    Der Fortschritt wird nach dem manuellen Aktualisieren der Fabric-Seite angezeigt.

    Problemumgehung: Aktualisieren Sie die Fabric-Seite manuell.

  • Problem 3018596: Virtual Function (VF) wird freigegeben, wenn Sie die virtuelle NIC (vnic) MTU der VM auf der Gast-VM größer als die physische NIC MTU festlegen.

    Sobald die vnic MTU größer als die pNIC MTU ist, kann die VM keine VF erwerben. Daher befindet sich die VM nicht im UPT-Modus. Sie befindet sich im „emu vmnic“-Modus.

    Problemumgehung:

    1. Ändern Sie die MTU-Größe auf DVS von 1600 in 9100.

    2. VF wird wieder der VM vnic zugewiesen.

  • Problem 3003762: Die Deinstallation des NSX Malware-Schutzdiensts schlägt fehl, wenn Sie die Regeln des Malware-Schutzdiensts nicht aus der Richtlinie löschen, und es wird auch keine Fehlermeldung angezeigt, dass die Deinstallation fehlschlägt, da noch Regeln in der Richtlinie vorhanden sind.

    Die Deinstallation des NSX Malware-Schutzdiensts schlägt in diesem Szenario fehl.

    Problemumgehung: Löschen Sie Regeln und wiederholen Sie die Deinstallation.

  • Problem 3003919: Wenn die mit CNAMES übereinstimmenden DFW-Regeln andere Aktionen haben als die mit dem ursprünglichen Domänennamen übereinstimmende DFW-Regel, führt dies zu einer inkonsistenten Regelerzwingung.

    In dem unwahrscheinlichen Fall, dass eine Anwendung/ein Benutzer auf CNAME statt auf den ursprünglichen DOMÄNENNAMEN zugreift, kann es zu einer Umgehung oder dazu kommen, dass die DFW-Regeln dies fälschlicherweise verwerfen.

    Problemumgehung: Führen Sie einen dieser Schritte durch.

    • Konfigurieren Sie die DFW-Regeln nur für den ursprünglichen Domänennamen und nicht für CNAME.

    • Konfigurieren Sie die Regeln mit dem Domänennamen und CNAMES mit derselben Aktion.

  • Problem 3014499: Das Deaktivieren der Edge-Verarbeitung des siteübergreifenden Datenverkehrs führt zu einer Unterbrechung einiger Flows.

    Ein Teil des siteübergreifenden Datenverkehrs funktionierte nicht mehr.

    Problemumgehung: Fahren Sie den heruntergefahrenen Edge wieder hoch.

  • Problem 3014978: Wenn Sie den Mauszeiger über das Netzwerk- und Sicherheits-Flag auf der Fabric-Seite bewegen, werden ungeachtet des ausgewählten Netzwerks falsche Informationen angezeigt.

    Keine Auswirkung.

    Problemumgehung: Keine.

  • Problem 3014979: NSX-Installations-/Deinstallationsfortschritt wird auf der Fabric-Seite nicht automatisch angezeigt.

    Keine Auswirkung. Aktualisieren Sie die Seite manuell, um den Fortschritt anzuzeigen.

    Problemumgehung: Aktualisieren Sie die Fabric-Seite manuell.

  • Problem 3017885: Die FQDN-Analyse kann nur einen Sub-Cluster im statusbehafteten Aktiv/Aktiv-Modus unterstützen.

    Aktivieren Sie die Funktion nicht, wenn der statusbehaftete Aktiv/Aktiv-Cluster über mehr als einen Sub-Cluster verfügt.

    Problemumgehung: Stellen Sie nur einen Sub-Cluster bereit.

  • Problem 3010038: Wenn bei einer Linkzusammenfassungsgruppe (LAG) mit zwei Ports, die Edge Uniform Passthrough- (UPT-)VMs bedient, die physische Verbindung zu einem der LAG-Ports getrennt wird, funktioniert der Uplink nicht mehr, aber die Virtual Functions (VFs), die von diesen UPT-VMs verwendet werden, sind weiterhin betriebsbereit, sobald die Konnektivität über die andere LAG-Schnittstelle gewährleistet wird.

    Keine Auswirkung.

    Problemumgehung: Keine.

  • Problem 3009907: NSX VIBs werden nicht vom SmartNIC-Host gelöscht, wenn der Host während des Vorgangs „NSX entfernen“ auf dem Cluster den Status „Getrennt“ aufweist.

    Keine funktionalen Auswirkungen.

    Problemumgehung: Wechseln Sie in vCenter Server zur vLCM-Benutzeroberfläche und standardisieren Sie den Cluster.

  • 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 2889482: Die falsche Speicherbestätigung wird angezeigt, wenn Segmentprofile für erkannte Ports aktualisiert werden.

    Die Richtlinien-Benutzeroberfläche ermöglicht die Bearbeitung von erkannten Ports, sendet jedoch nicht die aktualisierte Bindungszuordnung für Port-Aktualisierungsanforderungen, wenn Segmentprofile aktualisiert werden. Nach dem Klicken auf „Speichern“ wird eine falsch-positive Meldung angezeigt. Segmente scheinen für erkannte Ports aktualisiert worden zu sein, sind es aber nicht.

    Problemumgehung: Verwenden Sie die MP-API oder -Benutzeroberfläche, um die Segmentprofile für erkannte Ports zu aktualisieren.

  • Problem 2898020: Der Fehler „FRR config failed: ROUTING_CONFIG_ERROR (-1)“ wird im Status der Transportknoten angezeigt.

    Der Edge-Knoten lehnt eine Route Map-Sequenz ab, die mit einer Ablehnungsaktion konfiguriert ist, an deren Übereinstimmungskriterien mehr als eine Community-Liste angehängt ist. Wenn die Edge-Knoten nicht über die vom Administrator vorgesehene Konfiguration verfügen, führt dies zu einem unerwarteten Verhalten.

    Problemumgehung: Keine.

  • Problem 2910529: Edge verliert nach der DHCP-Zuteilung die IPv4-Adresse.

    Nachdem die Edge-VM installiert und eine IP-Adresse vom DHCP-Server empfangen wurde, verliert sie innerhalb kurzer Zeit die IP-Adresse und kann nicht mehr aufgerufen werden. Dies liegt daran, dass der DHCP-Server kein Gateway bereitstellt, sodass der Edge-Knoten seine IP verliert.

    Problemumgehung: Stellen Sie sicher, dass der DHCP-Server die richtige Gateway-Adresse bereitstellt. Ist dies nicht der Fall, führen Sie die folgenden Schritte aus:

    1. Melden Sie sich bei der Konsole der Edge-VM als Admin an.

    2. Halten Sie die Dienstdatenebene an.

    3. Legen Sie die Verwaltung der DHCP-Ebene für die Schnittstelle <mgmt intf> fest.

    4. Starten Sie die Dienstdatenebene.

  • Problem 2919218: Die für die Hostmigration getroffene Auswahl wird nach dem Neustart des MC-Diensts auf die Standardwerte zurückgesetzt.

    Nach dem Neustart des MC-Diensts werden alle für die Hostmigration relevanten Auswahlen wie das Aktivieren oder Deaktivieren von Clustern, der Migrationsmodus, die Clustermigrationsreihenfolge usw., die zuvor vorgenommen wurden, auf die Standardwerte zurückgesetzt.

    Problemumgehung: Stellen Sie sicher, dass alle für die Hostmigration relevanten Auswahlen nach dem Neustart des MC-Diensts erneut vorgenommen werden.

  • Problem 2942900: Die Identitäts-Firewall funktioniert nicht für das Ereignisprotokoll-Scraping, wenn Active Directory-Abfragen eine Zeitüberschreitung aufweisen.

    Die Identitäts-Firewall gibt eine rekursive Active Directory-Abfrage aus, um die Gruppeninformationen des Benutzers zu erhalten. Bei Active Directory-Abfragen kann es zu einer Zeitüberschreitung mit folgender NamingException kommen: „LDAP response read timed out, timeout used: 60000 ms“ (Zeitüberschreitung beim Lesen der LDAP-Antwort, verwendete Zeitüberschreitung: 60.000 ms). Aus diesem Grund werden Firewallregeln nicht mit Ereignisprotokoll-Scraper-IP-Adressen aufgefüllt.

    Problemumgehung: Zur Verbesserung der rekursiven Abfragezeiten können Active Directory-Administratoren die AD-Objekte organisieren und indizieren.

  • Problem 2954520: Wenn ein Segment in einer Richtlinie erstellt wird und Bridge in MP konfiguriert ist, ist die Option zum Trennen von Bridging für dieses Segment über die Benutzeroberfläche nicht verfügbar.

    Sie können Bridging nicht über die Benutzeroberfläche trennen oder aktualisieren, wenn das Segment in einer Richtlinie erstellt und Bridge in MP konfiguriert wurde.

    Wenn ein Segment auf der Richtlinienseite erstellt wird, empfiehlt es sich, Bridging nur von der Richtlinienseite aus zu konfigurieren. Wenn ein logischer Switch auf der MP-Seite erstellt wird, sollten Sie Bridging entsprechend nur auf der MP-Seite konfigurieren.

    Problemumgehung: Verwenden Sie APIs, um das Bridging zu eliminieren.

    1. Aktualisieren Sie den betroffenen LogicalPort und entfernen Sie den Anhang.

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

    Fügen Sie dies den Kopfzeilen im Kopfzeilenfeld für die PUT-Nutzlast -> X-Allow-Overwrite : true hinzu

    2. LÖSCHEN von BridgeEndpoint

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

    3. Löschen des LogicalPort

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

  • Problem 3030847: Änderungen in der VRF-BGP-Konfiguration werden nicht immer wirksam.

    Änderungen in der BGP-Konfiguration innerhalb einer VRF werden nicht immer wirksam.

    Problemumgehung: Erstellen Sie eine statische Dummy-Route und entfernen Sie sie. Dies führt zu einem Konfigurations-Push, der die VRF-BGP-Konfiguration auf dem Edge umsetzt.

  • Problem 3005685: Beim Konfigurieren einer Open ID Connect-Verbindung als NSX LM-Authentifizierungsanbieter können Fehler auftreten.

    Die OpenID Connect-Konfiguration erzeugt Fehler bei der Konfiguration.

    Problemumgehung: Keine.

  • Problem 2949575: Wenn ein Kubernetes-Worker-Knoten aus dem Cluster entfernt wurde, ohne dass die Pods darauf zuvor geleert wurden, verbleiben die Pods für immer im Status „Terminating“.

    Die NSX Application Platform und die Anwendungen darauf funktionieren möglicherweise nur teilweise oder nicht wie erwartet.

    Problemumgehung: Löschen Sie die Pods, die den Status „Terminating“ anzeigen, mithilfe der folgenden Informationen manuell.

    1. Führen Sie auf dem NSX Manager- oder dem Runner-IP-Host (Linux-Jump-Host, von dem aus Sie auf den Kubernetes-Cluster zugreifen können) den folgenden Befehl aus, um alle Pods mit dem Status Terminating aufzulisten.

      kubectl get pod -A | grep Terminating

    2. Löschen Sie jeden aufgeführten Pod mit dem folgenden Befehl.

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

  • Problem 3017840: Es erfolgt kein Edge-Switchover, wenn die Uplink-IP-Adresse geändert wird.

    Ein falscher HA-Status kann zu einem Blackholing des Datenverkehrs führen.

    Problemumgehung: Wechseln Sie den BFD-Status. Bevor Sie die Uplink-IP einer Edge-Änderung ändern, versetzen Sie den Edge in den Wartungsmodus.

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