VMware NSX Data Center for vSphere 6.4.7 | Veröffentlicht am 09. Juli 2020 | Build 16509800

Siehe den Revisionsverlauf dieses Dokuments.

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

Neuigkeiten
Versionen, Systemanforderungen und Installation
Eingestellte und nicht fortgeführte Funktionalität
Upgrade-Hinweise
FIPS-Konformität
Revisionsverlauf
Behobene Probleme
Bekannte Probleme

Neuigkeiten in NSX Data Center for vSphere 6.4.7

Wichtige Informationen zu NSX for vSphere 6.4.7

Anmerkung: VMware hat ein Problem in VMware NSX for vSphere 6.4.7 ermittelt, das neue NSX-Kunden und Kunden, die ein Upgrade von vorherigen NSX-Versionen durchführen, betreffen kann. Aus diesem Grund hat VMware beschlossen, die Verteilung von NSX 6.4.7 einzustellen. Die aktuell verfügbare Version von NSX for vSphere ist 6.4.6. VMware arbeitet mit Hochdruck an der nächsten Version, die NSX for vSphere 6.4.7 ersetzen soll.

Weitere Details finden Sie im VMware-Knowledgebase-Artikel 80238.

In NSX Data Center for vSphere 6.4.7 wurden Verbesserungen in Bezug auf Nutzbarkeit und Betriebsfähigkeit vorgenommen, und einige von Kunden gemeldete Probleme wurden behoben. Weitere Informationen dazu finden Sie unter Behobene Probleme.

Änderungen in NSX Data Center for vSphere 6.4.7:

vSphere 7.0-Unterstützung
Multicast-Verbesserungen: Fügt Unterstützung für Folgendes hinzu:
- PIM über einen GRE-Tunnel, ohne PIM zur gleichen Zeit über andere Uplinks.
- Statische Routen, die von der Unicast-Konnektivität verwendet werden.
- Aktiv/Standby-Modus.
- Edge-Firewall für Multicast.
- Verteilte Firewall für Multicast.
VMware NSX – Funktionalitätsaktualisierungen für vSphere Client (HTML): Eine Liste der unterstützten Funktionalität finden Sie unter VMware NSX for vSphere-UI-Plug-In-Funktionalität im vSphere Client.

Versionen, Systemanforderungen und Installation

Hinweis:

In der folgenden Tabelle sind empfohlene Versionen von VMware-Software aufgelistet. Diese Empfehlungen sind allgemeiner Natur. Umgebungsspezifische Empfehlungen haben demgegenüber Vorrang. Diese Informationen sind auf dem Stand des Veröffentlichungsdatums dieses Dokuments.
Die unterstützten Mindestversionen von NSX und anderen VMware-Produkten entnehmen Sie der VMware-Produkt-Interoperabilitätsmatrix. Die Einstufung als unterstützte Mindestversionen durch VMware erfolgt auf der Basis interner Tests.

Produkt oder Komponente	Version
NSX Data Center for vSphere	VMware empfiehlt die neueste NSX-Version für neue Bereitstellungen. Wenn Sie für vorhandene Bereitstellungen ein Upgrade durchführen möchten, lesen Sie bitte die Versionshinweise zu NSX Data Center for vSphere oder wenden Sie sich an einen Mitarbeiter des technischen Supports von VMware für weitere Informationen zu spezifischen Problemen, bevor Sie ein Upgrade planen.
vSphere	Für vSphere 6.5: Empfohlen: 6.5 Update 3 Hinweis: vSphere 6.5 Update 1 behebt das Problem des OutOfMemory-Fehlers bei EAM. Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 2135378. Wichtiger Hinweis: Wenn Sie Multicast-Routing mit vSphere 6.5 verwenden, wird das vSphere 6.5-Update 2 oder höher empfohlen. Bei Verwendung von NSX Guest Introspection auf vSphere 6.5 wird vSphere 6.5 P03 oder höher empfohlen. Für vSphere 6.7: Empfohlen: 6.7 Update 2 Wichtiger Hinweis: Wenn Sie NSX Guest Introspection auf vSphere 6.7 verwenden, lesen Sie den Knowledgebase-Artikel 57248, bevor Sie NSX 6.4.6 installieren, und wenden Sie sich an den VMware-Kundensupport. Hinweis: vSphere 5.5 wird mit NSX 6.4 nicht unterstützt. Hinweis: vSphere 6.0 hat das Ende des allgemeinen Supports erreicht und wird ab NSX 6.4.7 nicht mehr unterstützt.
Guest Introspection für Windows	Es wird empfohlen, VMware Tools vor dem Upgrade von NSX for vSphere auf 10.3.10 zu aktualisieren.
Guest Introspection für Linux	Stellen Sie sicher, dass auf der virtuellen Gastmaschine eine unterstützte Version von Linux installiert ist. ImAdministratorhandbuch für VMware NSX finden Sie die aktuelle Liste der unterstützten Linux-Versionen.

Systemanforderungen und Installation

Eine vollständige Liste der NSX-Installationsvoraussetzungen finden Sie im Abschnitt Systemvoraussetzungen für NSX im Installationshandbuch für NSX.

Anweisungen zur Installation erhalten Sie im Installationshandbuch für NSX oder im Installationshandbuch zu Cross-vCenter NSX.

Eingestellte und nicht fortgeführte Funktionalität

Warnungen zum Ende der Lebensdauer und des Supports

Informationen zu NSX- und anderen VMware-Produkten, für die demnächst ein Upgrade durchgeführt werden muss, finden Sie unter der VMware-Lebenszyklus-Produktmatrix.

Für NSX for vSphere 6.1.x gilt als Ende der Verfügbarkeit (EOA, End of Availability) und des allgemeinen Supports (EOGS, End of General Support) der 15. Januar 2017. (Informationen hierzu finden Sie auch im VMware-Knowledgebase-Artikel 2144769.)
vCNS-Edges werden nicht mehr unterstützt. Vor dem Upgrade auf NSX 6.3 oder höher müssen Sie zuerst ein Upgrade auf ein NSX Edge durchführen.
NSX for vSphere 6.2.x erreicht das Ende des allgemeinen Supports (End of General Support, EOGS) am 20. August 2018.
Gemäß Sicherheitsempfehlungen wird 3DES als Verschlüsselungsalgorithmus im NSX Edge-IPsec-VPN-Dienst nicht mehr unterstützt.
Es wird empfohlen, dass Sie zu einer der sicheren im IPsec-Dienst verfügbaren Verschlüsselungen wechseln. Diese Änderung in Bezug auf den Verschlüsselungsalgorithmus gilt für IKE SA (Phase 1) als auch für die Aushandlung der IPSec SA (Phase 2) für eine IPSec-Site.

Wenn der 3DES-Verschlüsselungsalgorithmus zum Zeitpunkt des Upgrades auf die Version, in der er nicht mehr unterstützt wird, vom NSX Edge-IPSec-Dienst verwendet wird, wird er durch eine andere empfohlene Verschlüsselung ersetzt. IPSec-Sites, die 3DES verwenden, werden deshalb nicht gestartet, solange die Konfiguration auf dem Remote-Peer nicht so geändert wird, dass der Verschlüsselungsalgorithmus mit dem in NSX Edge verwendeten Verschlüsselungsalgorithmus übereinstimmt.

Wenn Sie 3DES-Verschlüsselung verwenden, passen Sie den Verschlüsselungsalgorithmus in der IPsec-Site-Konfiguration an, um 3DES durch eine der unterstützten AES-Varianten zu ersetzen (AES/AES256/AES-GCM). So sollte beispielsweise in jeder IPSec-Site-Konfiguration mit 3DES als Verschlüsselungsalgorithmus dieser durch AES ersetzt werden. Aktualisieren Sie entsprechend die IPSec-Konfiguration am Peer-Endpoint.

Allgemeine Änderungen des Verhaltens

Wenn Sie über mehr als einen vSphere Distributed Switch verfügen und wenn VXLAN auf einem von ihnen konfiguriert ist, müssen Sie alle Distributed Logical Router-Schnittstellen mit Portgruppen auf diesem vSphere Distributed Switch verbinden. Ab der Version NSX 6.4.1 wird diese Konfiguration in der Benutzeroberfläche und API erzwungen. In früheren Versionen wurden Sie nicht daran gehindert, eine ungültige Konfiguration zu erstellen. Wenn Sie ein Upgrade auf NSX 6.4.1 oder höher durchführen und über falsch verbundene DLR-Schnittstellen verfügen, müssen Sie dieses Problem beheben. Nähere Informationen dazu finden Sie in den Upgrade-Hinweisen.

Entfernung von Elementen und Änderungen an der Benutzeroberfläche

In NSX 6.4.1 wurde die Service Composer-Arbeitsfläche entfernt.
In NSX 6.4.7 ist die folgende Funktionalität in vSphere Client 7.0 veraltet:
- NSX Edge: SSL VPN-Plus (weitere Informationen finden Sie im Knowledgebase-Artikel KB 79929)
- Tools: Endpoint-Überwachung (alle Funktionen)
- Tools: Flow-Überwachung (Dashboard zur Flow-Überwachung, Details nach Dienst und Konfiguration)
- Systemereignisse: NSX Ticket Logger

Änderungen am Installationsverhalten

Ab Version 6.4.2 ist die empfangsseitige Skalierung (Receive Side Scaling, RSS) bei einer Installation von NSX Data Center for vSphere auf Hosts, die über physische Netzwerkkarten (NICs) mit ixgbe-Treibern verfügen, auf den ixgbe-Treibern nicht standardmäßig aktiviert. Sie müssen RSS manuell auf den Hosts aktivieren, bevor Sie NSX Data Center installieren. Achten Sie darauf, RSS nur auf den Hosts zu aktivieren, die Netzwerkkarten (NICs) mit ixgbe-Treibern haben. Detaillierte Anweisungen zum Aktivieren von RSS finden Sie im VMware-Knowledgebase-Artikel https://kb.vmware.com/s/article/2034676. In diesem Knowledgebase-Artikel werden die empfohlenen RSS-Einstellungen für verbesserten VXLAN-Paketdurchsatz beschrieben.

Dieses neue Verhalten tritt nur auf, wenn Sie eine Neuinstallation von Kernel-Modulen (VIB-Dateien) auf den ESXi-Hosts durchführen. Es sind keine Änderungen erforderlich, wenn Sie für von NSX verwaltete Hosts ein Upgrade auf 6.4.2 durchführen.

Entfernung von APIs und Änderungen des Verhaltens

Veraltete Elemente in NSX 6.4.2

Das folgende Element ist veraltet und wird in einer künftigen Version möglicherweise entfernt:

GET/POST/DELETE /api/2.0/vdn/controller/{controllerId}/syslog. Verwenden Sie stattdessen GET/PUT /api/2.0/vdn/controller/cluster/syslog.

Änderungen des Verhaltens in NSX 6.4.1

Wenn Sie einen neuen IP-Pool mit POST /api/2.0/services/ipam/pools/scope/globalroot-0 erstellen oder einen bestehenden IP-Pool mit PUT /api/2.0/services/ipam/pools/ändern und im Pool mehrere IP-Bereiche definiert sind, erfolgt eine Validierung, um sicherzustellen, dass die Bereiche sich nicht überlappen. Diese Validierung wurde zuvor nicht durchgeführt.

Veraltete Elemente in NSX 6.4.0
Die folgenden Elemente sind veraltet und werden in einer künftigen Versionen möglicherweise entfernt.

Der Parameter systemStatus in GET /api/4.0/edges/edgeID/status ist veraltet.
GET /api/2.0/services/policy/serviceprovider/firewall/ ist veraltet. Verwenden Sie stattdessen GET /api/2.0/services/policy/serviceprovider/firewall/info.
Die Einstellung tcpStrict im globalen Konfigurationsbereich von „Verteilte Firewall“ ist veraltet. Ab Version NSX 6.4.0 wird tcpStrict auf Abschnittsebene definiert. Anmerkung: Wenn Sie ein Upgrade auf NSX 6.4.0 oder höher durchführen, wird die globale Konfigurationseinstellung für tcpStrict verwendet, um tcpStrict in jedem bestehenden Abschnitt der Ebene 3 zu konfigurieren. tcpStrict wird in Abschnitten der Ebene 2 und in Umleitungsabschnitten der Ebene 3 auf „false“ gesetzt. Weitere Informationen finden Sie im API-Handbuch zu NSX im Abschnitt zum Arbeiten mit der Konfiguration der verteilten Firewall.

Änderungen des Verhaltens in NSX 6.4.0
In NSX 6.4.0 ist der Parameter <name> erforderlich, wenn Sie einen Controller mit POST /api/2.0/vdn/controller erstellen.

In NSX 6.4.0 werden folgende Änderungen in Bezug auf die Fehlerbehandlung eingeführt:

Bisher gab POST /api/2.0/vdn/controller die Antwort 201 Created zurück, um anzugeben, dass der Auftrag zum Erstellen des Controllers durchgeführt wurde. Doch das Erstellen des Controllers konnte trotzdem fehlgeschlagen sein. Ab Version NSX 6.4.0 lautet die Antwort 202 Accepted.
Wenn Sie bisher eine API-Anforderung gesendet haben, die im Übergangsmodus oder im eigenständigen Modus nicht zulässig ist, lautete der Antwortstatus 400 Bad Request. Ab Version 6.4.0 lautet der Antwortstatus 403 Forbidden.

Entfernungen von CLI und Änderungen des Verhaltens

Verwenden Sie keine nicht unterstützten Befehle auf NSX Controller-Knoten
Es sind nicht dokumentierte Befehle zur Konfiguration von NTP und DNS auf NSX Controller-Knoten vorhanden. Diese Befehle werden nicht unterstützt und dürfen nicht auf NSX Controller-Knoten verwendet werden. Es stehen nur diejenigen Befehle zur Verfügung, die im NSX-CLI-Handbuch dokumentiert sind.

Hinweis: Eine Liste der bekannten Probleme, die Auswirkungen auf die Installation und auf Upgrades haben, finden Sie unter Bekannte Installations- und Upgrade-Probleme.

Allgemeine Upgrade-Hinweise

Für das Upgrade von NSX müssen Sie ein vollständiges NSX-Upgrade einschließlich eines Hostcluster-Upgrades durchführen (wobei die Host-VIBs aktualisiert werden). Anweisungen hierzu erhalten Sie im Upgrade-Handbuch für NSX im Abschnitt Aktualisieren der Hostcluster.
Ein Upgrade von NSX-VIBs auf Host-Clustern mithilfe von VUM wird nicht unterstützt. Verwenden Sie zum Durchführen des Upgrades von NSX-VIBs auf Host-Clustern den Upgrade-Koordinator, die Hostvorbereitung oder die zugehörigen REST-APIs.
Systemvoraussetzungen: Die Informationen zu den Systemanforderungen für die Installation und das Upgrade von NSX werden im Abschnitt Systemvoraussetzungen für NSX der NSX-Dokumentation dargestellt.
Upgrade-Pfad für NSX: Die VMware-Produkt-Interoperabilitätsmatrix bietet Details zu den Upgrade-Pfaden von VMware NSX.
Das Upgrade für Cross-vCenter NSX wird im Upgrade-Handbuch für NSX erläutert.
Herabstufungen werden nicht unterstützt:
- Führen Sie vor der Durchführung eines Upgrades immer eine Sicherung von NSX Manager durch.
- Nach einem erfolgreichen Upgrade von NSX ist kein Downgrade von NSX möglich.
Zur Überprüfung, ob Ihr Upgrade auf NSX 6.4.x erfolgreich durchgeführt wurde, finden Sie Erläuterungen im Knowledgebase-Artikel 2134525.
Upgrades von vCloud Networking and Security auf NSX 6.4.x werden nicht unterstützt. Sie müssen zuerst ein Upgrade auf eine unterstützte 6.2.x-Version durchführen.
Interoperabilität: Überprüfen Sie vor dem Upgrade die VMware-Produkt-Interoperabilitätsmatrix für alle betreffenden VMware-Produkte.
- Upgrade auf NSX Data Center for vSphere 6.4.7: VIO ist aufgrund mehrerer Skalierungsprobleme nicht mit NSX 6.4.7 kompatibel.
- Upgrade auf NSX Data Center for vSphere 6.4: NSX 6.4 ist nicht mit vSphere 5.5 kompatibel.
- Upgrade auf NSX Data Center for vSphere 6.4.5: Wenn NSX mit VMware Integrated OpenStack (VIO) bereitgestellt wird, aktualisieren Sie VIO auf 4.1.2.2 oder 5.1.0.1, da 6.4.5 aufgrund des Spring-Updates des Pakets auf Version 5.0 nicht mit früheren Versionen kompatibel ist.
- Upgrade auf vSphere 6.5: Wenn Sie ein Upgrade auf vSphere 6.5a oder höhere 6.5-Versionen durchführen möchten, müssen Sie zuerst ein Upgrade auf NSX 6.3.0 oder höher vornehmen. NSX 6.2.x ist nicht mit vSphere 6.5 kompatibel. Weitere Informationen dazu finden Sie unter Upgrade von vSphere in einer NSX-Umgebung im Upgrade-Handbuch für NSX.
- Upgrade auf vSphere 6.7: Wenn Sie ein Upgrade auf vSphere 6.7 durchführen möchten, müssen Sie zuerst ein Upgrade auf NSX 6.4.1 oder höher vornehmen. Frühere Versionen von NSX sind nicht mit vSphere 6.7 kompatibel. Weitere Informationen dazu finden Sie unter Upgrade von vSphere in einer NSX-Umgebung im Upgrade-Handbuch für NSX.
Kompatibilität mit Partnerdiensten: Wenn Ihre Site VMware-Partnerdienste für Guest Introspection oder für die Netzwerk-Introspektion verwendet, müssen Sie mithilfe des VMware-Kompatibilitäts-Handbuchs vor dem Upgrade prüfen, ob der Dienst Ihres Anbieters mit dieser NSX-Version kompatibel ist.
Networking & Security-Plug-In: Nach dem Upgrade von NSX Manager müssen Sie sich vom vSphere Web Client abmelden und wieder bei ihm anmelden. Wenn das NSX-Plug-In nicht ordnungsgemäß angezeigt wird, löschen Sie den Browser-Cache und den Verlauf. Wenn das Networking & Security-Plug-In nicht im vSphere Web Client angezeigt wird, setzen Sie den vSphere Web Client-Server wie im Upgrade-Handbuch für NSX beschrieben zurück.
Zustandsfreie Umgebungen: Bei NSX-Upgrades in einer statusfreien Hostumgebung werden die neuen VIBs während des NSX-Upgrades im Vorfeld zum Host-Image-Profil hinzugefügt. Das Verfahren von NSX-Upgrades auf statusfreien Hosts muss daher in folgender Reihenfolge durchgeführt werden:
In Versionen vor NSX 6.2.0 wurde eine einzelne URL in NSX Manager verwendet, über die VIBs für eine bestimmte Version von ESX Host ermittelt werden konnten. (Der Administrator musste also nur eine einzige URL kennen, unabhängig von der NSX-Version.) In NSX 6.2.0 und höher sind die neuen NSX-VIBs über mehrere URLs verfügbar. Führen Sie die folgenden Schritte aus, um die richtigen VIBs zu ermitteln:
1. Suchen Sie unter https://<nsxmanager>/bin/vdn/nwfabric.properties nach der neuen VIB-URL.
2. Rufen Sie die VIBs der erforderlichen ESX-Hostversion über die jeweilige URL ab.
3. Fügen Sie sie zu einem Image-Profil hinzu.
Die Funktion „Service Definitions“ wird auf der Benutzeroberfläche von NSX 6.4.7 für vSphere Client 7.0 nicht unterstützt:
Wenn Sie für vSphere 6.5 oder 6.7 eine alte Trend Micro-Dienstdefinition registriert haben, befolgen Sie eine der folgenden beiden Optionen:
- Option 1: Navigieren Sie vor dem Upgrade auf vSphere 7.0 im vSphere Web Client zur Registerkarte Dienstdefinition, ändern Sie die Dienstdefinition in 7.0 und führen Sie dann ein Upgrade auf vSphere 7.0 aus.
- Option 2: Führen Sie nach dem Upgrade auf vSphere 7.0 die folgende NSX-API aus, um die Dienstdefinition für 7.0 hinzuzufügen oder zu bearbeiten.

POST https://<nsmanager>/api/2.0/si/service/<Dienst-ID>/servicedeploymentspec/versioneddeploymentspec

Upgrade-Hinweise für NSX-Komponenten

Unterstützung für VM-Hardwareversion 11 für NSX-Komponenten

Für neue Installationen von NSX Data Center for vSphere 6.4.2 gilt für die NSX-Komponenten (Manager, Controller, Edge, Guest Introspection) die VM-Hardwareversion 11.
Bei Upgrades auf NSX Data Center for vSphere 6.4.2 wird für die NSX Edge- und Guest Introspection-Komponenten automatisch ein Upgrade auf VM-Hardwareversion 11 vorgenommen. Die NSX Manager- und NSX Controller-Komponenten weisen auch nach einem Upgrade die VM-Hardwareversion 8 auf. Benutzer haben die Möglichkeit, für die VM-Hardware ein Upgrade auf Version 11 vorzunehmen. Informationen zum Upgrade von VM-Hardwareversionen finden Sie in der KB (https://kb.vmware.com/s/article/1010675).
Für neue Installationen von NSX 6.3.x, 6.4.0 und 6.4.1 gilt für die NSX-Komponenten (Manager, Controller, Edge, Guest Introspection) die VM-Hardwareversion 8.

NSX Manager-Upgrade

Wichtiger Hinweis: Wenn Sie für NSX 6.2.0, 6.2.1 oder 6.2.2 ein Upgrade auf NSX 6.3.5 oder höher durchführen, müssen Sie vor Beginn des Upgrades eine Problemumgehung durchführen. Details finden Sie im VMware-Knowledgebase-Artikel 000051624.
Wenn Sie ein Upgrade von NSX 6.3.3 auf NSX 6.3.4 oder höher durchführen möchten, müssen Sie zunächst die Anweisungen zur Problemumgehung im VMware-Knowledgebase-Artikel 2151719 befolgen.
Wenn Sie SFTP für NSX-Sicherungen verwenden, ändern Sie nach dem Upgrade auf Version 6.3.0 oder höher den Sicherheitsalgorithmus auf hmac-sha2-256, da hmac-sha1 nicht unterstützt wird. Eine Liste der unterstützten Sicherheitsalgorithmen finden Sie im VMware-Knowledgebase-Artikel 2149282 .
Beim Upgrade von NSX Manager auf NSX 6.4.1 wird automatisch eine Sicherung erstellt und als Teil des Upgrade-Vorgangs lokal gespeichert. Weitere Informationen finden Sie unter Upgrade von NSX Manager.
Wenn Sie ein Upgrade auf NSX 6.4.0 durchführen, werden die TLS-Einstellungen beibehalten. Wenn Sie nur TLS 1.0 aktiviert haben, werden die NSX-Plug-Ins in vSphere Web Client angezeigt, NSX Manager sind aber nicht sichtbar. Dies hat keine Auswirkung auf den Datenpfad, es kann jedoch auch keine NSX Manager-Konfiguration geändert werden. Melden Sie sich bei der Web-Benutzeroberfläche für das NSX-Appliance-Management unter https://nsx-mgr-ip/ an und aktivieren Sie TLS 1.1 und TLS 1.2. Damit wird die NSX Manager-Appliance neu gestartet.

Controller-Upgrade

Der NSX Controller-Cluster muss drei Controller-Knoten enthalten. Bei weniger als drei Controllern müssen Sie die entsprechende Anzahl an Controllern vor dem Start des Upgrades hinzufügen. Weitere Informationen finden Sie unter Bereitstellen des NSX Controller-Clusters.
In NSX 6.3.3 hat sich das zugrunde liegende Betriebssystem des NSX Controllers geändert. Bei einem Upgrade von NSX 6.3.2 oder früher auf NSX 6.3.3 oder höher wird deshalb nicht die vorhandene Software aktualisiert. Es werden stattdessen die bestehenden Controller einzeln nacheinander gelöscht und neue Photon OS-basierte Controller bereitgestellt, die dieselben IP-Adressen verwenden.

Wenn die Controller gelöscht werden, werden auch alle zugehörigen DRS-Anti-Affinitätsregeln gelöscht. Sie müssen neue Anti-Affinitätsregeln in vCenter erstellen, um zu verhindern, dass sich die neuen Controller-VMs auf demselben Host befinden.

Weitere Informationen zu Controller-Upgrades finden Sie unter Upgrade von NSX Controller-Clustern.

Hostcluster-Upgrade

Wenn Sie ein Upgrade von NSX 6.3.2 oder früher auf NSX 6.3.3 oder höher durchführen, ändern sich die NSX-VIB-Namen.
Die esx-vxlan- und esx-vsip-VIBs werden mit esx-nsxv ersetzt, wenn Sie über NSX 6.3.3 oder höher verfügen, das auf ESXi 6.0 oder höher installiert ist.
Upgrade ohne Neustart und Deinstallation auf den Hosts: Bei vSphere 6.0 und höher ist nach einem Upgrade von NSX 6.2.x auf NSX 6.3.x oder höher für alle nachfolgenden NSX-VIB-Änderungen kein Neustart erforderlich. Stattdessen müssen die Hosts in den Wartungsmodus wechseln, um die VIB-Änderung abzuschließen. Dies betrifft sowohl das NSX-Hostcluster-Upgrade als auch das ESXi-Upgrade. Weitere Informationen dazu finden Sie im Upgrade-Handbuch für NSX.

Upgrade von NSX Edge

Validierung in NSX 6.4.1 hinzugefügt, um ungültige Distributed Logical Router-Konfigurationen nicht zuzulassen: In Umgebungen, in denen VXLAN konfiguriert ist und mehr als ein vSphere Distributed Switch vorhanden ist, dürfen Distributed Logical Router-Schnittstellen nur mit dem VXLAN-konfigurierten vSphere Distributed Switch verbunden werden. Ein Upgrade von DLR auf NSX 6.4.1 oder höher schlägt in diesen Umgebungen fehl, wenn der DLR über Schnittstellen verfügt, die mit dem nicht für VXLAN konfigurierten vSphere Distributed Switch verbunden sind. Verwenden Sie die API für die Verbindung fälschlicherweise konfigurierter Schnittstellen mit Portgruppen am VXLAN-konfigurierten vSphere Distributed Switch. Sobald die Konfiguration gültig ist, wiederholen Sie das Upgrade. Sie können die Schnittstellenkonfiguration unter Verwendung von PUT /api/4.0/edges/{edgeId} oder PUT /api/4.0/edges/{edgeId}/interfaces/{index} ändern. Weitere Informationen dazu finden Sie im API-Handbuch zu NSX.

Löschen Sie die UDLR-Kontroll-VM vom vCenter Server, die mit dem sekundären NSX Manager verknüpft ist, bevor Sie UDLR von 6.2.7 auf 6.4.5 aktualisieren:
Wenn Sie in einer Multi-vCenter-Umgebung NSX-UDLRs von 6.2.7 auf 6.4.5 aktualisieren, schlägt das Upgrade der virtuellen UDLR-Appliance (UDLR-Kontroll-VM) auf dem sekundären NSX Manager fehl, wenn HA auf der UDLR-Kontroll-VM aktiviert ist. Während des Upgrades wird die VM mit dem HA-Index #0 im HA-Paar aus der NSX-Datenbank entfernt. Diese VM ist jedoch weiterhin auf dem vCenter Server vorhanden. Wenn daher die UDLR-Kontroll-VM auf dem sekundären NSX Manager aktualisiert wird, schlägt das Upgrade fehl, da der Name der VM mit einer vorhandenen VM auf dem vCenter Server kollidiert. Um dieses Problem zu beheben, löschen Sie die Kontroll-VM vom vCenter Server, die mit dem UDLR auf dem sekundären NSX Manager verknüpft ist, und aktualisieren Sie UDLR dann von 6.2.7 auf 6.4.5.
Host-Cluster müssen vor dem Upgrade von NSX Edge-Appliances für NSX vorbereitet werden: Ab 6.3.0 wird eine Kommunikation der Managementebene zwischen NSX Manager und Edge über den VIX-Kanal ist nicht mehr unterstützt. Es wird nur der Nachrichtenbuskanal unterstützt. Wenn Sie ein Upgrade von NSX 6.2.x oder früher auf NSX 6.3.0 oder höher durchführen, müssen Sie sicherstellen, dass die Hostcluster, auf denen NSX Edge-Appliances bereitgestellt werden, für NSX vorbereitet sind und dass für die Messaging-Infrastruktur der Status GRÜN (GREEN) gilt. Wenn die Hostcluster nicht für NSX vorbereitet sind, schlägt das Upgrade der NSX Edge-Appliance fehl. Ausführliche Informationen finden Sie unter Upgrade von NSX Edge im Upgrade-Handbuch für NSX.

Upgrade von Edge Services Gateway (ESG):
Ab Version NSX 6.2.5 wird die Ressourcenreservierung gleichzeitig mit dem NSX Edge-Upgrade vorgenommen. Wenn vSphere HA auf einem Cluster aktiviert wird, der nicht über ausreichende Ressourcen verfügt, schlägt der Upgrade-Vorgang möglicherweise fehl, da vSphere HA-Einschränkungen verletzt werden.

Um derartige Upgrade-Fehler zu vermeiden, führen Sie die folgenden Schritte durch, bevor Sie ein ESG-Upgrade vornehmen:

Die folgenden Ressourcenreservierungen werden vom NSX Manager verwendet, sofern Sie nicht bei der Installation oder beim Upgrade ausdrücklich andere Werte festgelegt haben.

NSX Edge Formfaktor	CPU-Reservierung	Arbeitsspeicherreservierung
KOMPAKT	1000 MHz	512 MB
GROSS	2000 MHz	1024 MB
QUADLARGE	4000 MHz	2048 MB
X-LARGE	6000 MHz	8192 MB

Stellen Sie grundsätzlich sicher, dass Ihre Installation den Empfehlungen für vSphere HA entspricht. Erläuterungen dazu finden Sie im VMware-Knowledgebase-Artikel 1002080.
Verwenden Sie die NSX-API für die Feinabstimmung der Konfiguration:
PUT https://<nsxmanager>/api/4.0/edgePublish/tuningConfiguration
Stellen Sie dabei sicher, dass die Werte für edgeVCpuReservationPercentage und edgeMemoryReservationPercentage in die verfügbaren Ressourcen für den Formfaktor passen (siehe Standardwerte in der Tabelle oben).

Deaktivieren Sie die Startoption für die virtuelle Maschine von vSphere, sofern vSphere HA aktiviert ist und Edges bereitgestellt sind. Nach dem Upgrade von NSX Edges 6.2.4 oder früher auf die Version 6.2.5 oder höher müssen Sie die Startoption für die virtuelle Maschine von vSphere für jede NSX Edge-Instanz in einem Cluster deaktivieren, für den vSphere HA aktiviert ist und Edges bereitgestellt sind. Dazu müssen Sie den vSphere Web Client öffnen, den ESXi-Host ermitteln, auf dem sich die NSX Edge-VM befindet, auf „Verwalten“ > „Einstellungen“ klicken und unter „Virtuelle Maschinen“ die Option „VM starten/herunterfahren“ auswählen. Klicken Sie auf „Bearbeiten“ und stellen Sie sicher, dass sich die virtuelle Maschine im manuellen Modus befindet (d. h., sie darf nicht in der Liste „Automatisches Starten/Herunterfahren“ enthalten sein).
Bevor Sie ein Upgrade auf NSX 6.2.5 oder höher vornehmen, stellen Sie sicher, dass alle Load-Balancer-Verschlüsselungslisten durch Doppelpunkte getrennt sind. Falls in Ihrer Verschlüsselungsliste ein anderes Trennzeichen als ein Komma verwendet wird, führen Sie einen PUT-Aufruf für https://nsxmgr_ip/api/4.0/edges/EdgeID/loadbalancer/config/applicationprofiles durch und ersetzen Sie jede <ciphers> </ciphers>-Liste in <clientssl> </clientssl> und <serverssl> </serverssl> durch eine durch Kommas getrennte Liste. Beispielsweise kann das betreffende Segment des Anforderungstextes das im Folgenden dargestellte Aussehen haben. Wiederholen Sie diesen Vorgang für alle Anwendungsprofile:
```
<applicationProfile>
  <name>https-profile</name>
  <insertXForwardedFor>false</insertXForwardedFor>
  <sslPassthrough>false</sslPassthrough>
  <template>HTTPS</template>
  <serverSslEnabled>true</serverSslEnabled>
  <clientSsl>
    <ciphers>AES128-SHA:AES256-SHA:ECDHE-ECDSA-AES256-SHA</ciphers>
    <clientAuth>ignore</clientAuth>
    <serviceCertificate>certificate-4</serviceCertificate>
  </clientSsl>
  <serverSsl>
    <ciphers>AES128-SHA:AES256-SHA:ECDHE-ECDSA-AES256-SHA</ciphers>
    <serviceCertificate>certificate-4</serviceCertificate>
  </serverSsl>
  ...
</applicationProfile>
```
Legen Sie die richtige Verschlüsselungsversion für Clients mit Lastausgleichsdienst auf vROPs-Versionen vor 6.2.0 fest: vROPs-Poolmitglieder auf vROPs-Versionen vor 6.2.0 verwenden TLS-Version 1.0, weshalb Sie explizit einen Wert für die Überwachungserweiterung festlegen müssen, indem Sie die Einstellung "ssl-version=10" in der NSX-Load-Balancer-Konfiguration festlegen. Anweisungen dazu finden Sie unter Erstellen eines Dienstmonitors im Administratorhandbuch für NSX.
```
{
    "expected" : null,
    "extension" : "ssl-version=10",
    "send" : null,
    "maxRetries" : 2,
    "name" : "sm_vrops",
    "url" : "/suite-api/api/deployment/node/status",
    "timeout" : 5,
    "type" : "https",
    "receive" : null,
    "interval" : 60,
    "method" : "GET"
}
```
Nach dem Upgrade auf NSX 6.4.6 können L2-Bridges und -Schnittstellen auf einem DLR keine Verbindungen zu logischen Switches herstellen, die zu unterschiedlichen Transportzonen gehören: In NSX 6.4.5 oder früheren Versionen unterstützen L2-Bridge-Instanzen und -Schnittstellen auf einem Distributed Logical Router (DLR) die Verwendung logischer Switches, die zu verschiedenen Transportzonen gehörten. Ab NSX 6.4.6 wird diese Konfiguration nicht mehr unterstützt. Die L2-Bridge-Instanzen und -Schnittstellen auf einem DLR müssen mit logischen Switches verbunden sein, die sich in einer einzelnen Transportzone befinden. Wenn logische Switches aus mehreren Transportzonen verwendet werden, wird das Edge-Upgrade während Validierungsüberprüfungen vor dem Upgrade blockiert, wenn Sie NSX auf 6.4.6 aktualisieren. Um dieses Problem mit dem Edge-Upgrade zu beheben, stellen Sie sicher, dass die Bridge-Instanzen und Schnittstellen auf einem DLR mit logischen Switches in einer einzelnen Transportzone verbunden sind.
Nach dem Upgrade auf NSX 6.4.7 können Bridges und Schnittstellen auf einem DLR keine Verbindungen mit dvPortGroups herstellen, die zu unterschiedlichen VDS gehören: Wenn eine solche Konfiguration vorhanden ist, wird das NSX Manager-Upgrade auf Version 6.4.7 bei Validierungsüberprüfungen vor dem Upgrade blockiert. Um dies zu beheben, stellen Sie sicher, dass Schnittstellen und L2-Bridges eines DLR mit einem einzelnen VDS verbunden sind.
Nach dem Upgrade auf NSX 6.4.7 kann der DLR nicht mit von VLAN-gestützten Portgruppen verbunden werden, wenn die Transportzone des logischen Switches, mit dem er verbunden ist, mehr als einen VDS umfasst: Dadurch wird die ordnungsgemäße Ausrichtung von DLR-Instanzen mit den dvPortGroups logischer Switches über Hosts hinweg sichergestellt. Wenn eine solche Konfiguration vorhanden ist, wird das NSX Manager-Upgrade auf Version 6.4.7 bei Validierungsüberprüfungen vor dem Upgrade blockiert. Stellen Sie zum Beheben dieses Problems sicher, dass keine logischen Schnittstellen mit den von VLAN-gestützten Portgruppen verbunden sind, wenn eine logische Schnittstelle mit einem logischen Switch vorhanden ist, der zu einer Transportzone gehört, die mehrere VDS umfasst.
Nach dem Upgrade auf NSX 6.4.7 können sich die Schnittstellen und L2-Bridges verschiedener DLRs nicht im selben Netzwerk befinden: Wenn eine solche Konfiguration vorhanden ist, wird das NSX Manager-Upgrade auf Version 6.4.7 bei Validierungsüberprüfungen vor dem Upgrade blockiert. Stellen Sie zum Beheben dieses Problems sicher, dass ein Netzwerk nur in einem einzigen DLR verwendet wird.

Upgrade-Hinweise für FIPS

Wenn Sie ein Upgrade von einer NSX-Version vor NSX 6.3.0 auf NSX 6.3.0 oder höher durchführen möchten, dürfen Sie den FIPS-Modus nicht vor dem Abschluss des Upgrades aktivieren. Wenn Sie den FIPS-Modus vor Abschluss des Upgrades aktivieren, wird die Kommunikation zwischen aktualisierten und nicht aktualisierten Komponenten unterbrochen. Weitere Informationen dazu finden Sie unter Grundlegendes zum FIPS-Modus und zum NSX-Upgrade im Upgrade-Handbuch für NSX.

Auf OS X Yosemite und OS X El Capitan unterstützte Verschlüsselungen: Wenn Sie auf OS X 10.11 (EL Capitan) einen SSL-VPN-Client verwenden, können Sie mit den Verschlüsselungen AES128-GCM-SHA256, ECDHE-RSA-AES128-GCM-SHA256, ECDHE-RSA-AES256-GCM-SHA38, AES256-SHA und AES128-SHA eine Verbindung herstellen. Auf OS X 10.10 (Yosemite) haben Sie nur mit den Verschlüsselungen AES256-SHA und AES128-SHA die Möglichkeit, eine Verbindung herzustellen.
Aktivieren Sie den FIPS-Modus erst, wenn das Upgrade auf NSX 6.3.x abgeschlossen ist. Weitere Informationen dazu finden Sie unter Grundlegendes zum FIPS-Modus und zum NSX-Upgrade im Upgrade-Handbuch für NSX.
Vor der Aktivierung des FIPS-Modus müssen Sie sicherstellen, dass die Partnerlösungen für den FIPS-Modus zertifiziert sind. Informationen dazu finden Sie im VMware-Kompatibilitäts-Handbuch und in der jeweiligen Partnerdokumentation.

FIPS-Konformität

NSX 6.4 verwendet FIPS 140-2-validierte kryptografische Module für die gesamte sicherheitsbezogene Kryptografie, wenn diese korrekt konfiguriert sind.

Hinweis:

Controller und Clustering-VPN: Der NSX Controller verwendet das IPSec-VPN zur Herstellung einer Verbindung mit Controller-Clustern. Das IPSec-VPN verwendet das VMware-Verschlüsselungsmodul für den Linux-Kernel (VMware Photon OS 1.0-Umgebung), das gerade der CMVP-Validierung unterzogen wird.
Edge-IPSec-VPN: Das NSX Edge-IPSec-VPN verwendet das VMware-Verschlüsselungsmodul für den Linux-Kernel (VMware Photon OS 4.4-Umgebung), das gerade der CMVP-Validierung unterzogen wird.

Revisionsverlauf der Dokumente

9. Juli 2020: Erste Auflage.
4. August 2020: Zweite Auflage. Bekanntes Problem 2614777 wurde hinzugefügt.
17. August 2020: Dritte Auflage. Behobenes Problem 2306230 wurde hinzugefügt.

Behobene Probleme

Behobenes Problem 2445396: Die Pool-Ports des Load Balancers werden gelöscht, wenn der Load Balancer-Pool nach dem Bearbeiten gespeichert wird.
Beim Bearbeiten des Load Balancer-Pools und beim Speichern der Konfiguration werden die Portnummern aller Mitglieder gelöscht.
Behobenes Problem 2448235: Nach dem Upgrade auf NSX-v 6.4.6 können Sie Firewallregeln möglicherweise nicht nach Protokoll, Quellport und Zielport filtern.
Sie können Firewallregeln nicht mit den Filtern für Protokoll, Quellport, Zielport filtern.
Behobenes Problem 2306230: Die Nachrichteninfrastruktur fällt bei Hosts aufgrund von Taktsignalverzögerungen aus.
Die Hostkennwörter werden zurückgesetzt. Benutzer können bei getrennter Verbindung möglicherweise keine Konfigurationen auf den Hosts vornehmen.
Behobenes Problem 1859572: Bei der Deinstallation von NSX-VIBs der Version 6.3.x auf ESXi-Hosts, die von vCenter Version 6.0.0 verwaltet werden, verbleibt der Host im Wartungsmodus.
Wenn Sie die NSX-VIBs der Version 6.3.x auf einem Cluster deinstallieren, gehört zum Workflow das Versetzen der Hosts in den Wartungsmodus, das Deinstallieren der VIBs und das anschließende Beenden des Wartungsmodus für die Hosts durch den EAM-Dienst. Wenn jedoch solche Hosts von vCenter Server Version 6.0.0 verwaltet werden, führt dies dazu, dass die Hosts nach der Deinstallation der VIBs im Wartungsmodus verbleiben. Der für die Deinstallation der VIBs vorgesehene EAM-Dienst versetzt die Hosts in den Wartungsmodus, ist aber nicht in der Lage, den Wartungsmodus für die Hosts wieder zu deaktivieren.
Behobenes Problem 2006028: Host-Upgrade schlägt möglicherweise fehl, wenn das vCenter Server-System während des Upgrades neu gestartet wird.
Wenn das zugeordnete vCenter Server-System im Verlauf eines Host-Upgrades neu gestartet wird, schlägt das Host-Upgrade möglicherweise fehl und der Host verbleibt im Wartungsmodus. Auch das Klicken auf „Auflösen“ beendet nicht den Wartungsmodus für den Host. Der Clusterstatus lautet „Nicht bereit“.
Behobenes Problem 2233029: ESX unterstützt 10K-Routen nicht.
ESX muss keine 10.000 Routen unterstützen. Designbedingt liegt der maximale Grenzwert für ESX bei 2.000 Routen.
Behobenes Problem 2391153: NSX Manager aktualisiert die vdn_vmknic_portgroup- und vdn_cluster-Tabelle nicht, nachdem vCenter-Vorgänge auf vmknic dvportgroup durchgeführt wurden.
Wenn Sie die PUT-API-Anforderung https://nsx_manager_ip/api/2.0/nwfabric/configure ausführen, aktualisiert NSX Manager die vdn_vmknic_portgroup- und die vdn_cluster-Tabelle nicht, nachdem vCenter-Vorgänge auf „vmknic distributed virtual portgroup“ durchgeführt wurden. Die vCenter-Benutzeroberfläche zeigt weiterhin die alte VLAN-ID an.
Behobenes Problem 2367906 – Die CPU-Nutzung auf dem NSX Edge erreicht 100 %, wenn die HTTP-Dienstüberwachung beim Load Balancer mit der Erweiterung „no-body“ konfiguriert ist.
Dieses Problem tritt auf, wenn Sie die HTTP-Dienstüberwachung mit einer „no-body“-Erweiterung konfigurieren, während Sie das „nagios“-Plug-in beim Load Balancer (NSX-specific) verwenden. Der Load Balancer verliert die Verbindung mit allen Back-End-Servern und die Anforderung des Benutzers wird unterbrochen.
Behobenes Problem 2449643: Der vSphere Web Client zeigt nach dem Upgrade von NSX 6.4.1 auf 6.4.6 den Fehler „Kein NSX Manager verfügbar“ an.
In vSphere Web Client wird auf den Seiten „Firewall“ und „Logischer Switch“ die folgende Fehlermeldung angezeigt:
„Kein NSX Manager verfügbar. Vergewissern Sie sich, dass dem aktuellen Benutzer auf NSX Manager eine Rolle zugewiesen wurde.“

Da die Seiten „Firewall“ und „Logischer Switch“ auf der Benutzeroberfläche nicht verfügbar sind, können Benutzer möglicherweise keine Firewallregeln konfigurieren oder logische Switches erstellen. Außerdem antworten NSX APIs nur sehr langsam.

In der Datei /usr/nsx-webserver/logs/localhost_access_log befinden sich Einträge wie die folgenden:
127.0.0.1 - - [27/Oct/2019:08:38:22 +0100] "GET /api/4.0/firewall/globalroot-0/config HTTP/1.1" 200 1514314 91262
127.0.0.1 - - [27/Oct/2019:08:43:21 +0100] "GET /api/4.0/firewall/globalroot-0/config HTTP/1.1" 200 1514314 90832

127.0.0.1 - - [27/Oct/2019:11:07:39 +0100] "POST /remote/api/VdnInventoryFacade HTTP/1.1" 200 62817 264142
127.0.0.1 - - [27/Oct/2019:11:07:40 +0100] "POST /remote/api/VdnInventoryFacade HTTP/1.1" 200 62817 265023
127.0.0.1 - - [27/Oct/2019:11:07:40 +0100] "POST /remote/api/VdnInventoryFacade HTTP/1.1" 200 62817 265265
Behobenes Problem 2551523: Die Veröffentlichung einer neuen Regel schlägt möglicherweise fehl, wenn die Regel eine IP mit vier Nullen (0.0.0.0/0) enthält, nachdem ein Upgrade von NSX 6.3.6 auf NSX 6.4.6 durchgeführt wurde.
Firewallregeln mit einer 0.0.0.0/0-IP-Adresse in der Quelle oder im Ziel können nicht veröffentlicht werden.
Behobenes Problem 2536058: Lange API-Reaktionszeit von NSX Manager für „get flowstats“-APIs.
Beim Abfragen der Firewallkonfiguration und IPSets ist die Reaktionszeit für diese APIs lang.
Behobenes Problem 2513773: IDFW-Regeln werden nicht auf VDIs angewendet, nachdem deren Sicherheitsgruppen während der Sitzung entfernt wurden.
VDI-Sitzungen werden zufällig verworfen, weil die an die IDFW-Regeln angehängten Sicherheitsgruppen entfernt wurden.
Behobenes Problem 2509224: Eine übermäßig große Flowtabelle auf NSX Edge in Hochverfügbarkeit führt zu Verbindungsabbrüchen.
Wenn eine übergroße Verbindungsnachverfolgungstabelle vom Standby-NSX Edge zum aktiven NSX Edge synchronisiert wird, werden neue Verbindungen verworfen.
Behobenes Problem 2502739: Lange API-Reaktionszeit von NSX Manager für FW- und IPSet-APIs.
Beim Abfragen von Firewallkonfiguration und IPSets ist die Reaktionszeit für diese APIs lang.
Behobenes Problem 2498988: Die Reaktionszeit ist lang, wenn Gruppierungsobjekte abgefragt werden.
Beim Abfragen von Gruppierungsobjekten ist die Reaktionszeit für diese APIs lang.
Behobenes Problem 2458746: Nicht unterstützte LIF-Konfigurationen haben auf mehreren Hosts zum PSOD geführt.
Hostvalidierungen wurden implementiert, um das Hinzufügen duplizierter LIFs über verschiedene DLRs hinweg zu verhindern.
Behobenes Problem 2452833: Auf einem ESXi-Host, der eine DLR-Kontroll-VM bedient, kann ein PSOD auftreten, wenn sowohl beim Bridging als auch als LIF in zwei verschiedenen DLRs dasselbe VXLAN verwendet wird.
Ein ESXi, der die DLR-Kontroll-VM bedient, kann PSOD verwenden, wenn für Bridging und als LIF dieselbe virtuelle Leitung verbraucht wird.
Behobenes Problem 2451586: LB-Anwendungsregeln funktionieren nach dem Upgrade von NSX auf 6.4.6 nicht.
Wenn sich HTTP(S)-Back-End-Server als Teil von NSX Edge hinter einem NSX-Load Balancer befinden, kommunizieren die Clients über den Load Balancer mit den Back-End-Servern. Der Load Balancer sendet Header in Kleinbuchstaben, obwohl diese vom Server in Groß-/Kleinschreibung gesendet wurden.
Behobenes Problem 2448449: Anwendungsregeln, die mit req_ssl_sni konfiguriert wurden, schlagen beim Upgrade auf NSX for vSphere 6.4.6 möglicherweise mit einem Analysefehler fehl.
Wenn beim Upgrade auf NSX for vSphere 6.4.6 ein Load Balancer mit einer mit SNI verbundenen Regel konfiguriert ist oder wenn Sie eine neue mit SNI verbundene Regel in dieser Version erstellen oder konfigurieren, tritt möglicherweise ein Problem auf, weswegen das Upgrade oder das Erstellen der zugehörigen Regel fehlschlägt.
Behobenes Problem 2444275: Auf dem Host tritt ein PSOD auf, wenn die Funktion für die Latenz der virtuellen Infrastruktur aktiviert ist.
Auf dem ESXi-Host tritt ein PSOD auf, wenn die Funktion für die Latenz der virtuellen Infrastruktur in VRNI in einer Umgebung mit mehr als 975 BFD-Tunneln pro Host aktiviert ist. In einer Skalierungsumgebung kommt es auf dem ESXi-Host zum PSOD, wenn die Latenz aktiviert ist.
Behobenes Problem 2493095: Die Unterstützung von durch Kommas getrennten IP-Listen in der DFW wurde von der Benutzeroberfläche und aus der Datenbank entfernt.
Nach dem Upgrade früherer Versionen von NSX-v auf NSX-v 6.4.6 wurde die kommagetrennte IP-Liste in der DFW entfernt. Benutzer mit einer vorhandenen Firewallkonfiguration mit durch Kommas getrennten IP-Adressen konnten die Konfiguration nicht aktualisieren.
Behobenes Problem 2459936: Das Netzwerk kann nicht in zwei Teile aufgeteilt werden, indem statische Routen mit Netzwerk verwendet werden (0.0.0.0/1 und 128.0.0.0/1).
Bei NSX 6.4.0 bis 6.4.6 waren statische Routen nur für 0.0.0.0/0-Netzwerke zulässig. Ab NSX 6.4.7 ist das Hinzufügen einer statischen Route mit einem 0.0.0.0/x-Netzwerk zulässig, wobei 0 < = x < = 32 gilt.
Behobenes Problem 2430886: In der NSX Manager-Datenbank wird für deaktivierte Cluster ein falscher Hoststatus angezeigt.
Auf der Seite „Hostvorbereitung“ wird als Firewallzustand „Fehler“ angezeigt, selbst wenn der Cluster die Firewall aktiviert hat.
Behobenes Problem 2383382: In der Liste der Standardbefehle für die NSX Manager-CLI werden beim Befehl „delete“ falsche Hilfeinformationen angezeigt.
Als Hilfeinformationen für den Befehl „delete“ wird „Informationen zum ausgeführten System anzeigen“ angezeigt.
Behobenes Problem 2407662: Der Guest Introspection-Dienst funktioniert nicht, wenn der ESXi-Host und vCenter Server gleichzeitig neu gestartet werden.
Der Status des Guest Introspection-Dienst ist nicht grün, nachdem der ESXi-Host neu gestartet wurde oder wenn die GI-VM manuell eingeschaltet wird, während vCenter nicht ausgeführt wurde.

Die folgende Fehlermeldung wird in der Datei „/usr/local/usvmmgmt/logs/eventmanager.log“ angezeigt:
```
ERROR taskScheduler-4 PasswordChangeHelper:139 - Cmd does not exit normally, exit value = 1
```
Behobenes Problem 2410743: Das Verbinden der logischen Schnittstellen eines DLR mit dvPorGgroups mehrerer Distributed Switches mit vSphere führt bei einigen logischen Schnittstellen zu einer Unterbrechung des Datenverkehrs.
Der Datenverkehr bei einigen der logischen Schnittstellen funktioniert nicht ordnungsgemäß. Auf Hosts wird angezeigt, dass logische Schnittstellen mit falschen Distributed Switches mit vSphere verbunden sind.
Behobenes Problem 2413213: Die Wartungsaufgaben werden nicht geplant und die Tabelle „ai_useripmap“ nimmt zu.
Die Tabelle „ai_useripmap“ wird nicht bereinigt.
Behobenes Problem 2430753: Wenn beim Erstellen eines-IP-Pools in der Gateway-IP-Adresse ein zusätzliches Leerzeichen hinzugefügt wird, dann erstellt der ESXi-Host die IP-Adresse des Gateways für den VTEP nicht.
Die Verbindung von VTEP zu VTEP ist aufgrund eines fehlenden Gateways in der Konfiguration des IP Pools unterbrochen.
Behobenes Problem 2438649: Bei einigen Distributed Logical Routers auf dem Host gehen alle logischen Schnittstellen verloren.
VMs verlieren die Verbindung mit dem DLR aufgrund fehlender logischer Schnittstellen auf den DLRs.
Behobenes Problem 2439627: Die Datei „muxconfig.xml“ kann nach dem Upgrade von NSX Manager nicht auf den ESXi-Host übertragen werden.
Der Guest Introspection-Dienst ist nicht verfügbar. Der Status des GI-Diensts zeigt für alle Hosts die folgende Warnmeldung an:
```
Der Guest Introspection-Dienst ist nicht bereit.
```
Behobenes Problem 2440903: Bei der Verwendung der zentralen NSX-CLI für NSX Edge werden Daten einer passiven Edge-VM angezeigt.
Die Ausgabe der zentralen NSX-CLI für NSX Edge stammt möglicherweise von der falschen Edge-VM.
Behobene Probleme 2445183 und 2454653: Nach dem Ersetzen des SSL-Zertifikats der NSX Manager-Appliance ist NSX Manager in der vSphere-Bestandsliste nicht verfügbar.
Die folgende Fehlermeldung wird in vSphere Client angezeigt:
```
„Kein NSX Manager verfügbar. Vergewissern Sie sich, dass dem aktuellen Benutzer auf NSX Manager eine Rolle zugewiesen wurde.“
```
Behobenes Problem 2446265: vSphere Web Client sendet als vCenter-GUID im API-Aufruf NULL, wenn die Liste der ausgeschlossenen VMs abgerufen wird.
Wenn in vSphere Web Client auf die Schaltfläche Hinzufügen geklickt wird, um in der Ausschlussliste neue Mitglieder (VMs) hinzuzufügen, wird die folgende Fehlermeldung angezeigt, bevor die vollständigen Daten auf der Benutzeroberfläche geladen werden:
```
Kommunikation mit vCenter Server fehlgeschlagen.
```
Das Dialogfeld zum Hinzufügen ausgeschlossener Mitglieder wird nicht ordnungsgemäß angezeigt.
Behobenes Problem 2447697: NSX Edge wird aufgrund eines Konfigurationsfehlers und eines Rollback-Fehlers in einen ungültigen Status versetzt.
Edge kann nach dem Konfigurationsfehler wieder verwaltet werden.
Behobenes Problem 2453083: Der veraltete Eintrag in der Tabelle „vnvp_vdr_instance“ führt dazu, dass bei der Aktualisierung der DLR-Konfiguration ein Fehler auftritt und auf dem Host keine logischen Schnittstellen vorhanden sind.
Der Datenverkehrsfluss wird unterbrochen. Beim Versuch, den DLR erneut zu bereitstellen, zu synchronisieren oder zu aktualisieren, tritt ein Fehler auf.
Behobenes Problem 2460987: Die Dienst-VM erhält mit Priorität getaggte Frames.
VXLAN-gekapselte Frames auf Uplinks mit festgelegtem dot1p-Bit führen dazu, dass SVM mit Priorität getaggte Frames erhält. Die Pakete werden bei den SVM-Ports verworfen.
Behobenes Problem 2461125: Auf der Seite mit dem NSX-System-Dashboard wird für UDLR eine falsche Anzahl an BGP-Nachbarn angezeigt.
Das Problem tritt aufgrund mehrerer Einträge für die Weiterleitungsfunktion in der Tabelle „edge_service_config“ auf.
Behobenes Problem 2465697: Bei der Controller-Bereitstellung tritt ein Fehler auf, wenn NSX Manager die Version 6.4.x hat und NSX Controller die Version 6.3.x aufweisen.
Nach dem Upgrade von NSX Manager von 6.3.x auf Version 6.4.x und vor dem Upgrade von NSX Controllern auf Version 6.4.x tritt beim Bereitstellen von NSX Controllern der Version 6.3.x ein Fehler auf, da der Syslog-Server in Version 6.3.x nicht unterstützt wird.
Behobenes Problem 2465720: Bei der Aktualisierung virtueller Edge-Appliances für Edge-A werden versehentlich auch die virtuellen Appliances von Edge-B aktualisiert.
Sowohl Edge-A als auch Edge-B wechseln in den Status der erneuten Bereitstellung. Aufgrund unerwünschter oder unbeabsichtigter Änderungen bei anderen Edge-Appliances können mehrere Probleme wie Netzwerklatenzen, Auswirkungen auf Unternehmensdienste usw. auftreten.
Behobenes Problem 2467360: Der Guest Introspection-Dienst befindet sich im Warnungsstatus, da in der NSX-Bestandsliste keine VM vorhanden ist.
Der Guest Introspection-Dienst befindet sich im Warnungsstatus, da während der Überwachung des Endpoint-Integritätsstatus keine VM gefunden werden kann. Die von MUX gesendete XML-Datei zum Integritätsstatus enthält eine VM, die in der NSX-Bestandsliste nicht vorhanden ist.
Behobenes Problem 2468786: Der Verdacht, dass eine frühere Active Directory-Synchronisierung unterbrochen wurde, führt zur Datenbankintegrität (ai_group hat als primary_id null) und verhindert alle zukünftigen Active Directory-Synchronisierungen. Dadurch sind künftige Aktualisierungen in NSX nicht sichtbar.
Bei der Active Directory-Synchronisierung treten weiterhin Fehler auf und künftige Active Directory-Änderungen werden von NSX nicht erkannt. Während vorhandene Firewallregeln für vorhandene Benutzer und Gruppen funktionieren, werden Active Directory-Änderungen von NSX nicht erkannt. Benutzer können keine neu erstellten Active Directory-Gruppen oder andere Active Directory-Änderungen wie neue Benutzer, gelöschte Benutzer, Active Directory-Gruppen hinzugefügte Benutzer oder aus diesen entfernte Benutzer usw. anzeigen.
Behobenes Problem 2470918: CLI-Befehle im Zusammenhang mit „show ip bgp *“ generieren einen Core Dump.
Routen werden gelöscht, bis der Routing-Daemon neu gestartet wird. Dies führt zu einem Dienstausfall, bis die Routen erneut hinzugefügt wurden.
Behobenes Problem 2475392: Wenn derselbe logische Switch als Bridge und als logische Schnittstelle in zwei verschiedenen DLRs verwendet wird, kann ein PSOD auf dem Host auftreten, auf dem sich die Steuerungs-VM des DLR mit der Bridge befindet.
Eine solche Konfiguration könnte erfolgreich sein, wenn die Konfiguration auf dem zweiten DLR vorgenommen wird, bevor der ausstehende Auftrag auf dem ersten DLR abgeschlossen ist. Vor dem Purple Screen of Death (PSOD) wird die folgende Fehlermeldung in der Datei „vsm.log“ angezeigt:
```
Die beiden Edge Distributed Router „edge-A“ und „edge-B“ können nicht mit demselben Netzwerk „virtualwire-x“ verbunden werden.
```
Behobenes Problem 2478262: Mit dem Befehl „show host <Host-ID> health-status“ wird ein kritischer Status angezeigt, selbst wenn die Controller-Kommunikation ordnungsgemäß funktioniert.
Der mit diesem Befehl angezeigte Integritätsstatus ist falsch-positiv. Dies wirkt sich nicht auf die Funktionalität aus.
Behobenes Problem 2479599: Der vserrdd-Prozess sorgt für eine vollständige CPU-Auslastung.
Die CPU ist vollständig ausgelastet und dies wirkt sich wahrscheinlich auf die anderen Prozesse aus.
Behobenes Problem 2480450: Fehler im Fehlerpfad, wenn ESXi-Host nicht über Heap-Speicher verfügt.
Der PSOD tritt möglicherweise auf, wenn für den ESXi-Host zu einem ungünstigen Zeitpunkt kein Heap-Speicher verfügbar ist.
Behobenes Problem 2488759: Falscher Datenspeicherpfad in der NSX Manager-Datenbank während Storage vMotion.
Mux stürzt wiederholt ab und das Gastbetriebssystem wird häufig angehalten.
Behobenes Problem 2491042: Hohe CPU-Auslastung bei NSX Manager, die durch einen postgres-Prozess verursacht wird.
postgres-Prozesse verbrauchen fast die gesamte CPU-Ressource, wie durch den oberen Befehl zu sehen ist.
Behobenes Problem 2491749: Das erneut übertragene SYN-Paket wird im Maschinennachverfolgungscode für den TCP-Status nicht immer ordnungsgemäß verarbeitet.
Abhängig von den Sequenznummern kann ein erneut übertragenes SYN-Paket zu einem Verlust nachfolgender Pakete führen.
Behobenes Problem 2491914: Bei Verwendung der Netzwerk-Erweiterbarkeit (NetX) wird nach vMotion bei mit TCP eingerichteten Sitzungen die Statuszeitüberschreitung nicht berücksichtigt.
Nach vMotion der Status mit NetX wird die TCP-Sitzung zwar fortgesetzt, aber der Leerlauf-Timer startet und endet nach 12 Stunden. Die TCP-Sitzung wird unerwartet beendet und die Flows werden unterbrochen.
Behobenes Problem 2499225: Das DHCP-Relay auf einem Distributed Logical Router überträgt das Broadcast nicht ordnungsgemäß.
Wenn ein Client Computer eine DHCP-Erkennungs- oder -Anforderungsnachricht mit festgelegtem Broadcast-Bit sendet, sendet das DHCP-Relay auf dem DLR kein Antwortpaket als Broadcast. Dies kann dazu führen, dass einige Client Computer das Antwortpaket nicht erhalten.
Behobenes Problem 2503002: Beim Veröffentlichungsvorgang der verteilten Firewall (DFW) tritt eine Zeitüberschreitung auf, aber die Regeln werden dennoch veröffentlicht.
Dieses Problem tritt in einer großen Umgebung mit einer großen Anzahl an DFW-Regeln auf. Die Seite der verteilten Firewall wird auf der Benutzeroberfläche langsam geladen. In der Datei localhost_access_log.txt ist angegeben, API für die Firewallveröffentlichung mehr als 2 Minuten benötigt. Die Konfiguration der DFW-Regeln wird von der API veröffentlicht. Auf der Benutzeroberfläche wird jedoch eine Zeitüberschreitungsmeldung angezeigt.
Behobenes Problem 2506402: Auf der Edge-Benutzeroberfläche und in der CLI auf der VM werden Diskrepanzen bei gleichzeitigen Verbindungen angezeigt.
Seit NSX 6.4.0 werden die Flows durch eine Erweiterung des schnellen HA-Switchovers vom aktiven Edge-Knoten zum Standby-Edge-Knoten synchronisiert. Dies führte dazu, dass in den Edge-Schnittstellenstatistiken doppelte Daten angezeigt werden.
Behobenes Problem 2510798: Das Feld für die NSX Edge-Beschreibung kann nach der Bereitstellung nicht bearbeitet werden.
Das Beschreibungsfeld kann nach der Bereitstellung des Edge auf der Benutzeroberfläche und in der API nicht bearbeitet werden.
Behobenes Problem 2524239: Das Änderungsprotokoll des BFD-Status kann auf dem Syslog-Server nicht gedruckt werden.
Das Änderungsprotokoll des BFD-Status wird als eine unvollständige Nachricht gedruckt und der Syslog-Server kann sie nicht empfangen.
Behobenes Problem 2531966: Die Veröffentlichung der Firewallregel führt zu einer Zeitüberschreitung in vCenter.
Wenn die Firewallkonfiguration über mehr als 7000 Regeln verfügt, führt das Hinzufügen oder Löschen von Ergebnissen des Firewallregelabschnitts bei der Kommunikation zwischen vCenter und NSX Manager zu einer Zeitüberschreitung.
Behobenes Problem 2541643: Die Bereinigungsaufgabe verarbeitet keine Aufträge mit dem Zeitplantyp „FIXED_DATE“.
Das System kann aufgrund des geringen Festplattenspeichers oder der hohen Arbeitsspeicherauslastung langsamer werden. Aufgabenbezogene Tabellen enthalten eine große Anzahl an Datensätzen.
Behobenes Problem 2544344: Es kann kein GRE-Tunnel für Nicht-Administratorbenutzer erstellt werden, denen Administratorrechte zugewiesen sind.
Nicht-Administratorbenutzer, denen vollständige Enterprise-Administratorrechten zugewiesen sind, können keine GRE-Tunnel erstellen. Der Administrator kann jedoch GRE-Tunnel erstellen.
Behobenes Problem 2554069: Der Load Balancer für NSX Edge stürzt in NSX 6.4.6 ab.
Segmentierungsfehler, auf die der HAProxy-Dienst folgt, führen zu häufigen Neustarts.
Behobenes Problem 2556706: Für einige Konfigurationen auf dem NSX Controller konnte kein lokaler FQDN angegeben werden.
In der NSX Controller-Syslog-API tritt ein Fehler bei der Konfiguration auf, wenn als lokale Adresse ein FQDN angegeben ist.
Behobenes Problem 2560152: Der PSOD tritt auf dem ESXi-Host auf, während Hostprotokollpakete im für NSX vorbereiteten Cluster exportiert werden.
Dieses Problem tritt auf, wenn mehr als 100 VTEPs auf einem logischen Switch vorhanden sind. VMkernel-zdumps werden unter „/var/core“ generiert.
Problem 2560422: Auf der Benutzeroberfläche werden auf der Seite mit der Ausschlussliste der VM nicht die richtigen Daten angezeigt.
Von der Benutzeroberfläche werden mehrere API-Aufrufe vorgenommen, um die Ausschlussliste abzurufen. Die Daten werden auf der Seite mit der Ausschlussliste auf der Benutzeroberfläche langsam geladen. Auf der Seite wird möglicherweise nur einen Teil der Ausschlussliste im Raster angezeigt.
Behobenes Problem 2561009: Der SSL-VPN-Server-Daemon stürzt ab, wenn eine große Anzahl von Benutzern versucht, sich mit Anmeldedaten für einen einzelnen Benutzer anzumelden.
Der SSL-VPN-Daemon stürzt ab und wird neu gestartet.
Behobenes Problem 2566512: Die NSX Edge-Firewall unterstützt keine Firewallregeln, die mit IGMP-Mitgliedschaftsüberprüfung, -bericht und -aufhebung konfiguriert wurden.
Die NSX Edge-Appliance unterstützt noch keine IGMP-Aufhebungs- und -Mitgliedschaftsdienste.
Behobenes Problem 2567085: Der VSFWD-Prozess stürzt möglicherweise aufgrund der Verarbeitung der Trefferanzahl für die Regel ab.
VSFWD-Kerndatei auf dem Host mit einer Backtrace, die auf die Verarbeitung der Treffer für die Regel verweist. Der VSFWD-Watchdog startet den Vorgang nach dem Absturz automatisch neu.
Behobene Probleme 2444941 und 2574374: In einer großen NSX-Umgebung tritt der PSOD bei ESXi-Hosts auf, wenn die Latenz aktiviert ist.
Wenn BFD aktiviert ist, ist die Messung der Netzwerklatenz aktiviert. Der PSOD kann auftreten, wenn die Anzahl der BFD-Sitzungen 975 überschreitet.
Behobenes Problem 2586872: Der SSL-VPN-Server-Daemon stürzt ab, wenn der Benutzer versucht, das Kennwort vom SSL-VPN-Client zu ändern und die Sitzung nicht gefunden wurde.
Der SSL-VPN-Daemon stürzt ab und wird neu gestartet. Alle vorhandenen SSL-VPN-Sitzungen werden beendet und müssen neu gestartet werden. Alle SSL-VPN-Clients verlieren Ihre Sitzung und müssen sich erneut beim SSL-VPN-Server anmelden.
Behobenes Problem 2358130: Wenn globale Adresssätze aktiviert sind und ein vMotion-Export vorgenommen wird, werden die Tabellen nicht zum Zielhost migriert.
vMotion wird möglicherweise erfolgreich abgeschlossen, aber auf dem Zielhost sind erst Tabellen vorhanden, wenn die Konfiguration über die Management Plane veröffentlicht wird.

In der Datei „vmkernel.log“ auf dem Quellhost wird die folgende Meldung angezeigt:
```
Erstellen von tbl fehlgeschlagen: -1
```
Behobenes Problem 2382346: Wenn der WIN2K8-Ereignisprotokollserver mithilfe der Benutzeroberfläche hinzugefügt wird, wird der Ereignisprotokollserver fälschlicherweise als Win2k3 erkannt.
Die Funktion zum Identifizieren der Firewall (IDFW) wird unterbrochen.
Behobenes Problem 2397810: Wenn das Gebietsschema auf der NSX Manager-Benutzeroberfläche auf „Englisch USA (en_US)“ und das Browsergebietsschema auf „Französisch“ festgelegt ist, werden einige Felder im Syslog fälschlicherweise auf Französisch protokolliert.
Änderungen an Firewallregeln werden auf dem Syslog-Server auf Französisch und nicht auf Englisch protokolliert.
Behobenes Problem 2417536: Die IP-Übersetzung der Sicherheitsgruppen mit Ressourcenpools als Mitglied verbraucht viel Arbeitsspeicher und CPU, wenn mehrere vNICs pro VM im System vorhanden sind.
Die hohe CPU-Auslastung führt dazu, dass NSX Manager häufig neu gestartet wird.
Behobenes Problem 2449644: Die NSX Manager-Auftragswarteschlange ist überlastet.
Die Aktionen der Management Plane werden auf dem Hypervisor nicht realisiert.

Behobenes Problem 2459817: Bei der Synchronisierung der NSX-Bestandsliste tritt wiederholt ein Fehler auf.

In vCenter werden für verschiedene VMs ähnliche Instanz-UUIDs erkannt. Dies hat zur Folge, dass für verschiedene vNICs dieselben vNIC-IDs generiert werden. Benutzer müssen dieses Problem in der Datei „vsm.log“ erkennen.

Beispielsweise werden die folgenden Informationsmeldungen in der Datei „vsm.log“ angezeigt:

INFO ViInventoryThread VimVnic:159 - - [nsxv@6876 comp="nsx-manager" level="INFO" subcomp="manager"] Existing portgroupId : null , New portgroupId : dvportgroup-40  << indicate network change INFO ViInventoryThread VimVnic:217 - - [nsxv@6876 comp="nsx-manager" level="INFO" subcomp="manager"] network id : dvportgroup-40 , vnic id : 501c0ab1-e03c-b3ee-b662-9fd4649005d4.000 <= vnic id derived from instance uuid 501c0ab1-e03c-b3ee-b662-9fd4649005d4.

Behobenes Problem 2462523: Es wurde eine hohe Latenz beim VM-Datenverkehr festgestellt.
Eine hohe Anzahl von Änderungen bei der NSX-Konfiguration führt zur Latenz auf der VM. Wenn eine hohe Anzahl an Konfigurationen den Hypervisor erreicht, versucht die lokale Steuerungsebene, den Datenpfad zu konfigurieren. Dadurch wird der Datenverkehr vorübergehend blockiert, was zu einer Latenz führt. Die Änderung der Konfiguration wird möglicherweise durch VMs erzeugt, die in einem Datencenter, in dem diese VMs in Gruppen verwendet werden, kontinuierlich ein- oder ausgeschaltet werden.

Um dieses Problem abzuschwächen, aktivieren Sie den globalen Adresssatz, der die Konfiguration auf nur eine Instanz anstatt auf eine Instanz pro Filter auf dem Hypervisor reduziert. Alternativ können Sie die Filteranzahl von etwa 25 bis 40 beibehalten.
Behobenes Problem 2535292: IPv6 CIDR, das größer als /64 ist, wird aufgrund der Validierung der Management Plane nicht akzeptiert.
Bei der Firewallregel tritt ein Fehler auf, wenn sie in der Quelle oder dem Ziel der Regeldefinition IPv6 CIDR mit einem Präfix enthält, das größer als /64 ist.
Behobenes Problem 2214872: Im Rahmen der vSphere Update Manager- und ESX Agent Manager-Integration ruft EAM die VUM ImportFile-API einer HTTP-URL auf und VUM lädt das Paket von dieser URL herunter.
Die VUM FileUploadManagerImpl::ImportFile()-API wurde nur für die Verwendung mit URLs konzipiert, die eine Erweiterung oder mindestens „.“ in der URL enthalten. Wenn diese Bedingung nicht erfüllt ist, gibt die GetUrlFileNameExtension()-Methode eine Ausnahme aus. vSphere EAM-Agencys, die Clustern auf der Registerkarte für die NSX-V-Hostvorbereitung entsprechen, werden als fehlgeschlagen angezeigt.

Bekannte Probleme

Die bekannten Probleme gliedern sich in folgende Gruppen.

Bekannte Installations- und Upgrade-Probleme
Allgemeine bekannte Probleme
Probleme bei logischen Netzwerken und NSX Edge
Interoperabilitätsprobleme

Bekannte Installations- und Upgrade-Probleme

Bevor Sie das Upgrade durchführen, lesen Sie den Abschnitt Upgrade-Hinweise weiter oben in diesem Dokument.

Problem 1263858 – SSL VPN sendet keine Upgrade-Benachrichtigung an den Remoteclient.
SSL VPN-Gateway sendet keine Upgrade-Benachrichtigung an Benutzer. Der Administrator muss Remotebenutzern manuell mitteilen, dass das SSL VPN-Gateway (Server) aktualisiert wurde, und sie bitten, ihre Clients zu aktualisieren.

Problemumgehung: Benutzer müssen die ältere Version des Client deinstallieren und die neuste Version manuell installieren.
Problem 2429861: End2End-Latenz wird auf der vRNI-Benutzeroberfläche nach dem Upgrade auf NSX Version 6.4.6 nicht mehr angezeigt.
End2End-Latenz wird mit vRNI-Interoperabilität für vRNI 4.2 und vRNI 5.0 verringert.

Problemumgehung: Aktualisieren Sie vRNI auf 5.0.0-P2.
Problem 2417029: Falscher Pfad für Domänenobjekte in der NSX Manager-Datenbank.
- Beim Upgrade oder der erneute Bereitstellung von NSX Edge tritt ein Fehler mit der folgenden Fehlermeldung auf:
```
Cluster/ResourcePool „resgroup-XXX“ muss vorbereitet werden, damit Netzwerk-Fabric in der Lage ist, das Upgrade für Edge „edge-XX“ durchzuführen.
```
- In der Dropdown-Liste „Ordner“ werden im Dialogfeld „Controller hinzufügen“ nicht alle VM-Ordner angezeigt.
- Mindestens ein Cluster kann den Status „Nicht bereit“ zur Folge haben.
Problemumgehung: Wenden Sie sich für die Problemumgehung dieses Problems an den VMware Support.
Problem 2238989: Nach dem Upgrade des vSphere Distributed Switch auf dem ESXi-Host wird die Software RSS-Funktion des VDS nicht wirksam.
Bei Hosts, auf denen Software Receive Side Scaling (SoftRSS) aktiviert ist, wird die VDS-Eigenschaft com.vmware.net.vdr.softrss nach dem Upgrade von VDS nicht wiederhergestellt. Dies führt dazu, dass SoftRSS deaktiviert wird. In der Datei „/var/run/log/vmkernel.log“ werden Fehler im Zusammenhang mit der Konfiguration der softrss-Eigenschaft angezeigt.

Problemumgehung:

Entfernen Sie die softrss-Eigenschaft vor dem Upgrade des VDS und konfigurieren Sie sie nach dem Upgrade des VDS erneut.
Problem 2107188: Wenn der Namen eines VDS-Switches Nicht-ASCII-Zeichen enthält, tritt beim Upgrade von NSX-VIBs auf ESXi-Hosts ein Fehler auf.
In der Datei „/var/run/log/esxupdate.log“ wird der Upgrade-Status angezeigt.

Problemumgehung:

Ändern Sie den Namen des VDS so, dass nur ASCII-Zeichen verwendet werden, und führen Sie das Upgrade erneut aus.
Problem 2590902: Nach dem Upgrade auf NSX 6.4.7 können die VMs bei Zuweisung einer statischen IPv6-Adresse zu Arbeitslast-VMs in einem IPv6-Netzwerk nicht die Schnittstelle des IPv6-Gateways des Edge anpingen.
Dieses Problem tritt nach dem Upgrade der vSphere Distributed Switches von Version 6.x auf 7.0 auf.

Problemumgehung 1:

Wählen Sie den VDS aus, mit dem alle Hosts verbunden sind, öffnen Sie die Einstellung zum Bearbeiten und wechseln Sie unter „Multicast“ zu „Standard“.

Problemumgehung 2:

Fügen Sie der Edge-Firewall die folgenden Regeln hinzu:
- Regeln zum Zulassen von Ping.
- Regel zum Zulassen von Multicast Listener Discover (MLD), wobei es sich um ICMPv6, Typ 130 (v1) und Typ 143 (v2) handelt.

Allgemeine bekannte Probleme

Wenn Sie in vSphere Web Client eine Flex-Komponente öffnen, die eine HTML-Ansicht überlagert, ist die Ansicht nicht sichtbar
Wenn Sie eine Flex-Komponente, z. B. ein Menü oder ein Dialogfeld, öffnen, die eine HTML-Ansicht überlagert, wird die Ansicht vorübergehend ausgeblendet.
(Referenz: http://pubs.vmware.com/Release_Notes/en/developer/webclient/60/vwcsdk_600_releasenotes.html#issues)

Problemumgehung: Keine.
Problem 2543977: Der IPFIX-Collector für die verteilte Firewall kann keine Flows von den UDP-Ports 137 oder 138 erkennen.
Wenn IPFIX für die verteilte Firewall aktiviert ist, wurden die NetBIOS-Flows für die Ports 137 oder 138 vom Host nicht gesendet.

Problemumgehung:

Verwenden Sie vSphere Client oder NSX Rest API, um die ausgeschlossenen Ports 137 oder 138 aus Flow-Ausschlüssen zu entfernen.
Problem 2302171 und 2590010: Wenn IPFIX auf einem vSphere Distributed Switch mit einer Abtastrate von 100 % aktiviert ist, sinkt der Durchsatz.
Es treten Leistungsbeeinträchtigungen beim Datenpfad auf und der Durchsatz des Datenpfads reduziert sich auf die Hälfte des Grenzwerts für die Bandbreite des Netzwerkkanals

Problemumgehung: Legen Sie die Sampling-Rate auf weniger als 10 % fest.
Problem 2574333: Die Konfiguration des Edge-vNIC dauert mehr als zwei Minuten, wenn NAT mit 8000 Regeln konfiguriert ist.
Der vSphere Client zeigt an, dass NSX Manager nicht verfügbar ist. Bei der Benutzeroberfläche tritt nach zwei Minuten eine Zeitüberschreitung auf. Die vNIC-Konfiguration wird in 2–3 Minuten erfolgreich abgeschlossen.

Problemumgehung: Keine
Problem 2443830: Bei einem VXLAN-Netzwerk treten Leistungsbeeinträchtigungen beim Datenpfad auf, wenn der ixgben-NIC-Treiber verwendet wird.
Der Durchsatz des VXLAN-Netzwerks wird reduziert.

Problemumgehung:
- Führen Sie den folgenden Befehl auf dem ESXi-Host aus:
```
esxcli system module parameters set -p "RSS=1,1" -m ixgben
```
- Starten Sie den Host neu.
Problem 2547022: Wenn in der untergeordneten Active Directory-Gruppe ein neuer Active Directory-Benutzer hinzugefügt wird, ist der Benutzer nicht in der Sicherheitsgruppe enthalten, die auf der übergeordneten Active Directory-Gruppe basiert.
Die Sicherheitsgruppe, die auf dem übergeordneten Active Directory basiert, verfügt nicht über den Benutzer.

Problemumgehung:

Fügen Sie Sicherheitsgruppen hinzu, die auf der untergeordneten Active Directory-Gruppe basieren.
Problem 2614777: Die Veröffentlichung der DFW-Regel schlägt fehl, wenn eine Regel aus zwei Diensten mit sich überlappenden Dienstports bzw. einer Reihe von Dienstports besteht.
Die Veröffentlichung der DFW-Regel schlägt fehl.

Problemumgehung: Weitere Informationen erhalten Sie im VMware-Knowledgebase-Artikel 80238.

Probleme bei logischen Netzwerken und NSX Edge

Problem 1993241: IPSec-Tunnel-Redundanz mit statischem Routing wird nicht unterstützt
IPSec-Datenverkehr schlägt fehl, wenn der primäre Tunnel ausfällt. Dies führt zur Unterbrechung des Datenverkehrs. Dieses Problem ist seit NSX 6.4.2 bekannt.

Problemumgehung: Deaktivieren und aktivieren Sie den Dienst.
Problem 2430805 und 2576416: Die DLR-Instanzen werden an alle für NSX vorbereiteten Hosts gesendet, die mit dem VDS verbunden sind.
Es werden Probleme im Zusammenhang mit einer designierten VLAN-Instanz festgestellt. Der VM-Datenverkehr wird unterbrochen, wenn die designierte VLAN-Instanz einen ungültigen Host erreicht.

Problemumgehung:
- Konfigurieren Sie VXLAN auf für NSX vorbereiteten Hosts mit demselben VDS.
- Starten Sie den Host neu, damit er die neue Konfiguration erhält.
Problem 2576294: Wenn die logischen Schnittstellen auf einem DLR mit mehreren VDS verbunden sind, werden die logischen Schnittstellen mit falschen VDS auf dem Host verbunden, sofern der Host Teil zweier VXLAN-VDS ist.
Wenn der DLR in einem falsch konfigurierten Status erzwungen oder erneut bereitgestellt wird, werden alle logischen Schnittstellen des DLR mit dem falschen VDS verbunden. Zudem werden die logischen Schnittstellen für alle neuen DLRs mit dem falschen VDS auf dem Host verbunden. Der Datenverkehr des Datenpfads wird unterbrochen.

Problemumgehung:
- Entfernen Sie den zweiten VDS, der nicht für die VXLS-Vorbereitung des Clusters verwendet wurde.
- Abhängig vom aktuellen Status der Hostkonfiguration können Sie entweder die Synchronisierung erneut bereitstellen oder die Synchronisierung erzwingen oder den Routendienst synchronisieren, um die Konfiguration auf dem Host zu korrigieren.
Problem 2582197: Wenn eine NSX Edge-Schnittstelle mit einer /32-Subnetzmaske konfiguriert ist, wird die verbundene Route in der Routing- oder Weiterleitungstabelle nicht angezeigt.
Der Datenverkehr zu dieser Schnittstelle funktioniert möglicherweise dennoch, aber es wäre eine statische Route erforderlich, um Peers zu erreichen. Benutzer können keine Schnittstellen mit /32-Subnetzmaske verwenden. Es gibt keine Probleme, wenn eine andere Subnetzmaske verwendet wird.

Problemumgehung: Mit Ausnahme der /32-Subnetzmaske können alle anderen Subnetzmasken verwendet werden.
Problem 2594802: In Service Composer können Benutzer eine Sicherheitsrichtlinie mit dem Dialogfeld „Priorität verwalten“ nicht über die 200. Position hinaus verschieben.
Dieses Problem wurde in NSX 6.4.3 und höher beobachtet und es tritt nur dann auf, wenn mehr als 200 Sicherheitsrichtlinien vorhanden sind. Im Dialogfeld Priorität verwalten werden nur die ersten 200 Richtlinien angezeigt. Daher können Benutzer eine Sicherheitsrichtlinie nicht über die 200. Position hinaus verschieben.

Problemumgehung:

Identifizieren Sie die Gewichtung Ihrer Sicherheitsrichtlinie, damit die Sicherheitsrichtlinie auf diesen bestimmten Rang verschoben werden kann. Angenommen, der Rangfolge 300 hat beispielsweise die Gewichtung 1000 und der Rang 301 hat die Gewichtung 1200. Um Ihre Sicherheitsrichtlinie auf Rang 301 zu verschieben, geben Sie die Gewichtung 1100 ein (d. h. eine Zahl zwischen 1200 und 1100).

Befolgen Sie diese Schritte:
1. Öffnen Sie das Dialogfeld Sicherheitsrichtlinie bearbeiten.
2. Ändern Sie die Gewichtung Ihrer Sicherheitsrichtlinie in 1100, sodass sie an die Position 301 verschoben werden kann.
3. Klicken Sie auf Beenden.
4. Beobachten Sie, ob die Richtlinie auf die Position 301 verschoben wurde.
Problem 2395158: Der Firewallabschnitt ist abgeblendet, wenn die Rolle „Enterprise-Administrator“ einer Active Directory-Gruppe zugewiesen ist.
Die Rolle „Enterprise-Administrator“ wird einer Active Directory-Gruppe zugewiesen, indem Sie zu Benutzer und Domänen > Benutzer > Identitätsbenutzer > vCenter-Gruppe angeben navigieren. Wenn sich Benutzer, die zu einer Active Directory-Gruppe gehören, anmelden und einen Firewallabschnitt sperren, wird der gesperrte Abschnitt für diese Benutzer nach der Aktualisierung der Seite abgeblendet dargestellt.

Problemumgehung:

Anstatt der Active Directory-Gruppe die Rolle „Enterprise-Administrator“ zuzuweisen, weisen Sie diese Rolle direkt den Benutzern zu, indem Sie zu Benutzer und Domänen > Benutzer > Identitätsbenutzer > vCenter-Benutzer angeben navigieren.
Problem 2444677: Bei NSX Edge tritt ein Kernel-Panic-Fehler auf, wenn große Dateien per L2-VPN über IPSec-VPN-Tunnel übertragen werden.
Dieser Fehler tritt auf, wenn die MTU auf 1500 Byte festgelegt ist.

Problemumgehung:

Legen Sie die MTU auf 1600 Byte fest.
Problem 2574260: Das Aktualisieren einer vorhandenen Konfiguration für den logischen Switch zum Aktivieren der Verwendung von Gast-VLANs (Virtual Guest Tagging oder 802.1q-VLAN-Tagging) führt nicht zum erwarteten Ergebnis.
Die mit dem logischen Switch verknüpfte VDS-Portgruppe wird nicht entsprechend aktualisiert.

Problemumgehung: Keine
Problem 2562965: Wenn eine Konfiguration der DFW-Regel gespeichert wird, dreht sich die Schaltfläche „Speichern“ einige Minuten lang und schließlich gibt die Benutzeroberfläche einen Fehler aus.
Die folgende Fehlermeldung wird in vSphere Client angezeigt:
```
„Kein NSX Manager verfügbar. Vergewissern Sie sich, dass dem aktuellen Benutzer auf NSX Manager eine Rolle zugewiesen wurde.“
```
Dieses Problem tritt nur beim Speichern der Konfiguration einer DFW-Regel auf. Dies hat keine Auswirkung auf die Veröffentlichung der DFW-Regel.

Problemumgehung: Keine
Problem 2595144: In NSX 6.4.6 überschreitet die Auslastung des Quad Large Edge-Arbeitsspeichers 90 %, wenn die Anzahl der aktiven Schnittstellen 6 oder mehr beträgt.
Dieses Problem wurde in NSX 6.4.6 und höher beobachtet, da die Änderung für die Größe des Rx-Ringpuffers in 4096 auf Quad Large Edges eingeführt wurde.
- NSX Edge meldet eine hohe Arbeitsspeicherauslastung, wenn die Anzahl der Schnittstellen 6 oder mehr beträgt.
- Auf der NSX Edge-VM zeigt die Ausgabe des Befehls top -H eine normale Benutzerplatzauslastung an.
- Die Ausgabe des Befehls slabtop -o zeigt eine Objektanzahl von mehr als 100.000 für skbuff_head_cache an.
Problemumgehung: Wenden Sie sich für die Problemumgehung dieses Problems an den VMware Support.

Interoperabilitätsprobleme

Problem 2586381: VMware Integrated Openstack (VIO) ist aufgrund mehrerer Skalierungsprobleme nicht mit NSX 6.4.7 kompatibel.
NSX 6.4.7 unterstützt die Interoperabilität mit VIO nicht.

Problemumgehung: Keine