VMware NSX for vSphere 6.4.0 | Veröffentlicht am 16. Januar 2018 | Build 7564187

Siehe den Revisionsverlauf dieses Dokuments.

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

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

Neuigkeiten in NSX 6.4.0

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

Änderungen in NSX for vSphere 6.4.0:

Sicherheitsdienste:

Identitätsbasierte Firewall: Die identitätsbasierte Firewall (IDFW) unterstützt jetzt Benutzersitzungen auf Remote-Desktop- und Remoteanwendungsservern (RDSH) mit einer gemeinsamen IP-Adresse. Die neue „Fast-Path“-Architektur verbessert die Verarbeitungsgeschwindigkeit von IDFW-Regeln. Die Active Directory-Integration ermöglicht jetzt eine selektive Synchronisierung für schnellere AD-Aktualisierungen.
Verteilte Firewall: Die verteilte Firewall (Distributed Firewall, DFW) fügt einen auf Anwendungsschicht 7 basierenden Kontext für die Planung der Flow-Steuerung und Mikrosegmentierung hinzu. Application Rule Manager (ARM) empfiehlt jetzt Sicherheitsgruppen und Richtlinien für eine geschlossene und umsetzbare Mikrosegmentierungsstrategie.
Regeln der verteilten Firewall können jetzt als statusfreie Regeln pro DFW-Abschnitt erstellt werden.
Die verteilte Firewall unterstützt eine VM-IP-Realisierung im Hypervisor. So können Benutzer überprüfen, ob eine bestimmte VM-IP Teil von Sicherheitsgruppen/Clustern/Resourcenpools/Hosts ist, die in den Feldern „Quelle“, „Ziel“ oder „AppliedTo“ der DFW-Regel verwendet werden.
Erkennungsmechanismen für IP-Adressen für VMs: Für die autoritative Erzwingung von Sicherheitsrichtlinien basierend auf VM-Namen oder anderen vCenter-basierten Attributen ist es erforderlich, dass NSX die IP-Adresse der VM kennt. In NSX 6.2 wurde die Option zur Erkennung der IP-Adresse einer VM mithilfe von DHCP-Snooping oder ARP-Snooping eingeführt. In NSX 6.4.0 wurde die maximale Anzahl der IP-Adressen, die von ARP erkannt werden können, auf 128 erhöht. Es kann eine Zahl von 1 bis 128 konfiguriert werden. Mit diesen neuen Erkennungsmechanismen kann NSX die auf IP-Adressen basierten Sicherheitsregeln auf VMs erzwingen, auf denen VMware Tools nicht installiert ist.
Guest Introspection: Bei vCenter 6.5 und höher erhalten Guest Introspection(GI)-VMs den Namen „Guest Introspection (XX.XX.XX.XX)“, wobei „XX.XX.XX.XX“ die IPv4-Adresse des Hosts ist, auf dem sich die GI-Maschine befindet. Dieser Vorgang erfolgt während der ersten Bereitstellung von GI.

NSX-Benutzeroberfläche:

Unterstützung für vSphere Client (HTML5): Einführung des VMware NSX-UI-Plug-Ins für vSphere Client (HTML5). Eine Liste der unterstützten Funktionalität finden Sie unter VMware NSX for vSphere-UI-Plug-In-Funktionalität im vSphere Client.
HTML5-Kompatibilität mit vSphere Web Client (Flash): Die NSX-Funktionalität, die in HTML5 entwickelt wurde (z. B. Dashboard), bleibt sowohl mit vSphere Client als auch mit vSphere Web Client kompatibel. Dies ermöglicht eine nahtlose Erfahrung für Benutzer, für die der sofortige Übergang zu vSphere Client nicht möglich ist.
Verbessertes Navigationsmenü: Reduzierte Anzahl von Klicks für den Zugriff auf wichtige Funktionen, wie z. B. Gruppierungsobjekte, Tags, Ausschlussliste und Systemkonfiguration.

Vorgänge und Fehlerbehebung:

Upgrade-Koordinator bietet ein einheitliches Portal zur Vereinfachung der Planung und Ausführung eines NSX-Upgrades. Der Upgrade-Koordinator bietet eine vollständige Systemansicht aller NSX-Komponenten mit aktuellen und Zielversionen, Upgrade-Statusanzeigen, One-Click- oder benutzerdefinierten Upgrade-Plänen sowie Vorher-/Nachher-Überprüfungen.
Ein neues, verbessertes HTML5-Dashboard steht zusammen mit vielen neuen Komponenten zur Verfügung. Das Dashboard ist jetzt Ihre Standardstartseite. Sie können auch vorhandene systemdefinierte Widgets anpassen und eigene benutzerdefinierte Widgets über die API erstellen.
Das neue Dashboard Systemskalierung erfasst Informationen zur aktuellen Systemskalierung und zeigt die Maximalwerte für die Konfiguration der unterstützten Skalierungsparameter an. Außerdem können Warnungen und Alarme für den Fall konfiguriert werden, dass die Grenzwerte erreicht oder überschritten werden.
Verbesserungen bei der Guest Introspection-Zuverlässigkeit und -Fehlerbehebung. Funktionen wie die EAM-Statusbenachrichtigung, der Upgrade-Fortschritt, benutzerdefinierte Namen für SVMs, zusätzlicher Arbeitsspeicher und mehr verbessern die Zuverlässigkeit und Fehlerbehebung von GI-Bereitstellungen.
Eine zentrale CLI für logische Switches, logische Router und verteilte Edge-Firewalls beschleunigt die Fehlerbehebung durch einen zentralen Zugriff auf verteilte Netzwerkfunktionen.
Die neue Registerkarte Support-Paket ist verfügbar, damit Sie das Support-Paket über die Benutzeroberfläche mit einem einzigen Klick erfassen können. Sie können jetzt die Support-Paketdaten für NSX-Komponenten wie NSX Manager, Hosts, Edges und Controller erfassen. Sie können entweder das aggregierte Support-Paket herunterladen oder das Paket direkt auf einen Remoteserver hochladen. Sie können den Gesamtstatus der Datenerfassung und den Status für jede einzelne Komponente anzeigen.
Die neue Registerkarte Paketerfassung steht zum Erfassen von Paketen über die Benutzeroberfläche zur Verfügung. Wenn sich ein Host nicht in einem fehlerfreien Zustand befindet, erhalten Sie ein Paketspeicherabbild für diesen Host und der Administrator kann die Paketinformationen für das Debuggen weiter untersuchen.
Sie können jetzt den Modus für den Betrieb mit getrenntem Controller (Controller Disconnected Operation, CDO) über die Registerkarte Management auf der sekundären Site aktivieren, um temporäre Konnektivitätsprobleme zu vermeiden. Im CDO-Modus wird sichergestellt, dass in einer Umgebung mit mehreren Sites bei einem Konnektivitätsverlust der primären Site die Konnektivität auf Datenebene nicht beeinträchtigt wird.
Multi-Syslog-Unterstützung für bis zu 5 Syslog-Server.
API-Verbesserungen einschließlich JSON-Unterstützung. NSX bietet jetzt die Auswahl zwischen JSON- und XML-Datenformaten. XML bleibt die Standardeinstellung für die Abwärtskompatibilität.
Einige der NSX Edge-Systemereignismeldungen enthalten jetzt Edge-ID- und/oder VM-ID-Parameter. Beispiel: Ereigniscode 30100, 30014, 30031.
Diese Meldungsparameter sind nicht für ältere Systemereignisse verfügbar. In solchen Fällen zeigt die Ereignismeldung {0} oder {1} für Edge-ID- und/oder VM-ID-Parameter an.
Sie können jetzt die NSX API verwenden, um den Status des Hypervisors herauszufinden. Die Überwachung des Zustands des Hypervisor-Tunnels hilft dabei, Probleme schnell zu beheben. Die API-Antwort beinhaltet den pNIC-Status, den Tunnelstatus, den Hypervisor für den Verbindungsstatus der Steuerungskomponente und den Hypervisor für den Verbindungsstatus der Managementkomponente.

NSX Edge-Verbesserungen:

Verbesserung der Systemdiagnose für den Edge-Lastausgleich. Drei neue Diagnoseparameter wurden hinzugefügt: DNS, LDAP und SQL.
Sie können jetzt Routen für die Neuverteilung filtern, indem Sie LE/GE-Werte für die Präfixlänge der Ziel-IP angeben.
Unterstützung für BGP und statisches Routing über GRE-Tunnel.
NAT64 bietet eine Übersetzung von IPv6 in IPv4.
Schnelleres Failover der Edge-Routing-Dienste.
Routing-Ereignisse generieren jetzt Systemereignisse in NSX Manager.
Verbesserungen der L3 VPN-Leistung und Stabilität.

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 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 NSX-Versionshinweise 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.0: Unterstützt: 6.0 Update 2, 6.0 Update 3 Empfohlen: 6.0 Update 3. vSphere 6.0 Update 3 behebt das Problem der duplizierten VTEPs in ESXi-Hosts nach dem Neustart von vCenter Server. Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 2144605. Für vSphere 6.5: Unterstützt: 6.5a, 6.5 Update 1 Empfohlen: 6.5 Update 1. vSphere 6.5 Update 1 behebt das Problem des OutOfMemory-Fehlers bei EAM. Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 2135378. Hinweis: vSphere 5.5 wird mit NSX 6.4.0 nicht unterstützt.
Guest Introspection für Windows	Es werden alle Versionen von VMware Tools unterstützt. Für einige Guest Introspection-basierte Funktionen sind neuere Versionen von VMware Tools erforderlich: Verwenden Sie VMware Tools 10.0.9 und 10.0.12 für die Aktivierung der optionalen, in VMware Tools enthaltenen Thin Agent-Komponente des Netzwerk-Introspektions-Treibers. Führen Sie ein Upgrade auf VMware Tools 10.0.8 und höher für die Behebung des Problems verlangsamter VMs nach dem Upgrade von VMware Tools in NSX/vCloud Networking and Security durch (siehe VMware-Knowledgebase-Artikel 2144236). Verwenden Sie VMware Tools 10.1.0 und höher zur Unterstützung von Windows 10. Verwenden Sie VMware Tools 10.1.10 und höher zur Unterstützung von Windows Server 2016.
Guest Introspection für Linux	Diese NSX-Version unterstützt die folgenden Linux-Versionen: RHEL 7 GA (64 Bit) SLES 12 GA (64 Bit) Ubuntu 14.04 LTS (64 Bit)

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.

Entfernung von APIs und Änderungen des Verhaltens

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 im Abschnitt 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 6.4: NSX 6.4 ist nicht mit vSphere 5.5 kompatibel.
- Upgrade auf vSphere 6.5a oder höher: Wenn Sie ein Upgrade von vSphere 6.0 auf vSphere 6.5a oder höher durchführen möchten, müssen Sie zuerst ein Upgrade auf NSX 6.3.0 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.
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.

Upgrade-Hinweise für NSX-Komponenten

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

Controller-Upgrade

Der NSX Controller-Cluster muss für ein Upgrade auf NSX 6.3.3 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

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"
}
```

Upgrade für Guest Introspection

Guest Introspection-VMs enthalten nun zusätzliche Informationen über die Hostidentität in einer XML-Datei auf der Maschine. Bei der Anmeldung bei der Guest Introspection-VM sollte die Datei „/opt/vmware/etc/vami/ovfEnv.xml“ Informationen über die Hostidentität enthalten.

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

16. Januar 2018: Erste Auflage.
17. Januar 2018: Zweite Auflage. Die behobenen Probleme 1461421, 1499978, 1628679, 1634215, 1716464, 1753621, 1777792, 1787680, 1792548, 1801685, 1849043 wurden hinzugefügt.
22. Januar 2018: Dritte Auflage. Bekanntes Problem 2036024 wurde hinzugefügt.
24. Januar 2018: Vierte Auflage. Upgrade-Hinweise wurden aktualisiert.
1. Februar 2018: Fünfte Auflage. Aktualisierte FIPS-Konformitätsinformation.
22. Februar 2018: Sechste Auflage. Die behobenen Probleme 1773240, 1839953, 1920574, 1954964 und 1965589 wurden hinzugefügt. Die bekannten Probleme 2013820, 2016689, 2017806 und 2026069 wurden hinzugefügt.
2. März 2018: Siebte Auflage. Der Abschnitt „Neuerungen“ wurde aktualisiert.
6. April 2018: Achte Auflage. Bekanntes Problem 2014400 wurde hinzugefügt. Die behobenen Probleme 2029693 und 2003453 wurden hinzugefügt. Änderungen des Verhaltens und veraltete Elemente wurden aktualisiert.
27. Apr. 2018: Neunte Auflage. Änderungen des Verhaltens und veraltete Elemente wurden aktualisiert.
7. Mai 2018: Zehnte Auflage. Die behobenen Probleme 1772473 und 1954628 wurden hinzugefügt. Die bekannten Probleme 1993691, 2005900 und 2007991 wurden hinzugefügt.
14. September 2018: Elfte Auflage. Bekanntes Problem 2006576 wurde hinzugefügt.
5. Oktober 2018: Zwölfte Auflage. Bekanntes Problem 2164138 wurde hinzugefügt.

Behobene Probleme

Die behobenen Probleme werden in die im Folgenden aufgeführten Kategorien unterteilt.

Allgemeine behobene Probleme
Behobene Probleme bei logischen Netzwerken und NSX Edge
Behobene Probleme beim NSX Manager
Behobene Probleme bei Sicherheitsdiensten

Allgemeine behobene Probleme

Behobenes Problem 1783528: Die CPU-Nutzung von NSX Manager steigt freitagnachts/samstagmorgens stark an
NSX fragt LDAP freitagnachts ab, um eine volle Synchronisierung durchzuführen. Es gibt keine Option zum Konfigurieren einer bestimmten Active Directory-Organisationseinheit oder eines bestimmten Containers. Deshalb ruft NSX alle Objekte ab, die mit der angegebenen Domäne in Zusammenhang stehen.
Behobenes Problem 1801685: Filter werden auf ESXi nach dem Upgrade von Version 6.2.x auf 6.3.0 aufgrund einer fehlgeschlagenen Verbindung mit dem Host nicht angezeigt
Nach dem Upgrade von NSX 6.2.x auf 6.3.0 und der Cluster-VIBs auf 6.3.0-Bits weist der „Kommunikationskanalstatus“ die Verbindung von NSX Manager zum Firewallagenten und von NSX Manager zum Steuerungskomponentenagenten als inaktiv aus, auch wenn die Installation als erfolgreich und die Firewall als aktiviert angezeigt wird. Dies führt zum Scheitern der Veröffentlichung von Firewallregeln und Sicherheitsrichtlinien, und die VXLAN-Konfiguration kann nicht zu den Hosts gesendet werden.
Behobenes Problem 1780998: NSX Manager speichert nur 100.000 Überwachungsprotokolleinträge anstelle der dokumentierten 1.000.000 Einträge
Es sind nur 100.000 Protokolleinträge in den Überwachungsprotokollen verfügbar.
Behobenes Problem 1874735: „Upgrade verfügbar“-Link wird bei Clusteralarm nicht angezeigt
Benutzer können die neue Dienstspezifikation nicht an den EAM weitergeben, da der Link fehlt, und es erfolgt kein Upgrade des Diensts.
Behobenes Problem 1893299: ODS-Scan von nicht regulären Dateien, z. B. für Block- oder Zeichengeräte, kann zum Absturz oder „Hängen“ des Systems führen
ODS prüft nur reguläre Dateien und symbolische Links. Es wird nicht direkt auf nichtreguläre Dateien, z. B. für ein Blockgerät oder Zeichengerät, zugegriffen. Dies ist jedoch möglich, wenn diese Dateien das Ziel von symbolischen Links sind. Der Zugriff auf diese Dateien kann zu unbeabsichtigten Aktionen wie dem Absturz oder „Hängen“ des Systems führen.
Behobenes Problem 1897878: Eine hohe Auslastung des Arbeitsspeichers (und in einigen Fällen der CPU) auf der USVM führen zu Betriebsproblemen für die VMs auf demselben Host
Eine hohe Arbeitsspeicherauslastung führt dazu, dass sich nicht reagierende VMs nicht anmelden können.
Behobenes Problem 1882345: CPU-Auslastung nimmt im Zeitablauf zu und bleibt bei 100 %
Wenn ARP-Snooping als Mechanismus für die IP-Erkennung aktiviert ist, und die Umgebung VMs mit mehreren IP-Adressen pro vNIC enthält, nimmt die CPU-Auslastung allmählich zu und erreicht 100 %, wobei es zu schwerwiegenden Leistungsbeeinträchtigungen kommt.
Behobenes Problem 1920343: Serverzertifikat kann ohne einen privaten Schlüssel erstellt werden
Wenn die Daten des privaten Schlüssels im Zertifikatinhalt bereitgestellt werden, wird der private Schlüssel ignoriert.
Behobenes Problem 1926060: Das Kontrollkästchen „Quelle ablehnen“ unter „Firewall“ > „Quelle oder Ziel angeben“ wird auch dann aktiviert, wenn Sie daneben klicken
Das Kontrollkästchen „Quelle ablehnen“ wird aktiviert, wenn Sie Objekte aus der Liste der verfügbaren Objekte in die Liste der ausgewählten Objekte verschieben.
Behobenes Problem 1965589: Veröffentlichung von mit Versionen vor 6.4.0 generierten Entwürfen verteilter Firewalls schlägt in 6.4.0 fehl
Vor der Version 6.4 erstellte Entwürfe verfügen über keine Schicht-2-Abschnitte mit statusfreiem Flag-Attribut. Wenn solche Entwürfe in eine 6.4-Konfiguration geladen oder damit veröffentlicht werden, schlagen diese fehl, da für Schicht-2-Abschnitte das statusfreie Flag ab NSX 6.4 auf „True“ festgelegt sein muss. Da aufgrund des Fehlens des Attributs ein Standardwert gilt (d. h. „False“), schlägt die Validierung fehl und ein Veröffentlichungsfehler wird ausgegeben.

Behobene Probleme bei logischen Netzwerken und NSX Edge

Folgendes Problem behoben: Controller-Protokolle werden mit einer Fehlermeldung der Bridge überflutet, die darauf hinweist, dass das Hinzufügen und Löschen des Mac-Datensatzes „MacRecord“ für eine nicht vorhandene Bridge-Instanz fehlschlagen ist.
Wenn sich das Sharding ändert, kann die Bridge keine Join-Anforderung an den Controller senden. Problem in 6.4.0 behoben.
Behobenes Problem 2014400: NSX Edge im Standbymodus reagiert auf IPv6-Datenverkehr, wenn die Firewall-Funktion auf dem Edge deaktiviert ist.
Wenn IPv6 auf NSX Edge aktiviert ist und ein Failover ausgelöst wird, werden Upstream-Geräte mit MAC-Adressen des Standby-Edge aktualisiert, wodurch der N-S-Datenverkehr zum falschen Edge weitergeleitet werden kann. Problem in 6.4.0 behoben.
Behobenes Problem 1783065: Bei Load Balancer ist die gemeinsame Konfiguration von UDP-Port und TCP über IPv4- und IPv6-Adressen nicht möglich
UDP unterstützt nur IPv4-IPv4, IPv6-IPv6 (Frontend-Backend). NSX Manager enthält einen Fehler. Auch wenn die IPv6-Link-Local-Adresse gelesen und als eine IP-Adresse des Gruppierungsobjekts übertragen wird, können Sie das IP-Protokoll nicht für die LB-Konfiguration verwenden.
Im Folgenden finden Sie eine beispielhafte LB-Konfiguration, die das Problem veranschaulicht:
In der Load-Balancer-Konfiguration wird der Pool „vCloud_Connector“ mit einem Gruppierungsobjekt (vm-2681) als Poolmitglied konfiguriert. Dieses Objekt enthält sowohl IPv4- als auch IPv6-Adressen. Dies wird von der LB-L4-Engine nicht unterstützt.
```
{
              "algorithm" : {
        ...
    },
              "members" : [
        {
            ...  ,
            ...
        }
              ],
              "applicationRules" : [],
              "name" : "vCloud_Connector",
              "transparent" : {
                 "enable" : false
              }
        }

  {
              "value" : [
                 "fe80::250:56ff:feb0:d6c9",
                 "10.204.252.220"
              ],
              "id" : "vm-2681"
            }
```
Behobenes Problem 1764258: Der Datenverkehr geht nach einem Hochverfügbarkeits-Failover oder nach einer erzwungenen Synchronisierung auf einem NSX Edge, das mit einer Teilschnittstelle konfiguriert ist, bis zu acht Minuten verloren
Wenn ein Hochverfügbarkeits-Failover ausgelöst oder eine erzwungene Synchronisierung über eine Teilschnittstelle gestartet wird, geht der Datenverkehr bis zu acht Minuten lang verloren.
Behobenes Problem 1850773: NSX Edge NAT meldet eine ungültige Konfiguration, wenn in der Load-Balancer-Konfiguration mehrere Ports verwendet werden
Dieses Problem tritt jedes Mal auf, wenn Sie einen virtuellen Load-Balancer-Server mit mehr als einem Port konfigurieren. Die NAT kann bei einer solchen Konfiguration des betroffenen NSX Edge nicht mehr verwendet werden.
Behobenes Problem 1733282: NSX Edge unterstützt keine statischen Geräterouten mehr
NSX Edge unterstützt keine Konfiguration statischer Routen mit NULL-Nexthop-Adresse.
Behobenes Problem 1711013: Synchronisierung der FIB zwischen aktivem und Standby-NSX Edge nach dem Neustart der Standby-VM dauert 15 Minuten
Wenn ein Standby-NSX Edge ausgeschaltet ist, wird die TCP-Sitzung zwischen dem aktiven und dem Standby-Modus nicht geschlossen. Das aktive Edge erkennt, dass der Standby-Modus nach dem Keepalive (KA-)Ausfall inaktiv ist (15 Minuten lang). Nach 15 Minuten wird eine neue Socket-Verbindung mit dem Standby-Edge hergestellt, und die FIB wird zwischen dem aktivem Edge und dem Standby-Edge synchronisiert.
Behobenes Problem 1781438: Auf den ESG- oder DLR-NSX Edge-Appliances zeigt der Routing-Dienst keine Fehlermeldungen an, wenn das BGP-Pfadattribut MULTI_EXIT_DISC mehr als einmal empfangen wird
Der Edge-Router oder der Distributed Logical Router zeigt keine Fehlermeldung an, wenn er mehr als einmal das BGP-Pfadattribut MULTI_EXIT_DISC empfängt. Gemäß RFC 4271 [Abschnitt 5] darf das gleiche Attribut (d. h. Attribute gleichen Typs) nur einmal im Feld „Pfadattribute“ einer bestimmten UPDATE-Meldung enthalten sein.
Behobenes Problem 1860583: Verwendung von Remote-Syslog-Servern als FQDN kann das Routing beeinträchtigen, wenn DNS nicht erreichbar ist
Wenn auf einem NSX Edge Remote-Syslog-Server mithilfe des FQDN konfiguriert sind und DNS nicht erreichbar ist, können davon die Routing-Funktionen beeinträchtigt werden. Das Problem tritt eventuell nur sporadisch auf.
Behobenes Problem 1242207: Änderungen an der Router-ID während der Laufzeit werden in der OSPF-Topologie nicht wiedergegeben
Wenn Sie versuchen, die Router-ID zu ändern, ohne OSPF zu deaktivieren, werden die neuen externen Verbindungsstatus-Ankündigungen (link-state advertisements, LSAs) mit dieser Router-ID nicht neu generiert, was zu einem Verlust von externen OSPF-Routen führt.
Behobenes Problem 1767135: Fehler beim Versuch, auf Zertifikate und Anwendungsprofile unter Load Balancer zuzugreifen
Benutzer mit Security-Administrator-Rechten und Edge-Geltungsbereich können bei Verwendung des Load Balancer nicht auf Zertifikate und Anwendungsprofile zugreifen. Im vSphere Web Client werden entsprechende Fehlermeldungen angezeigt.
Behobenes Problem 1844546: Konfigurierte einem Benutzer zugewiesene IP-Adresse auf der DLR-HA-Schnittstelle funktioniert nicht
Die Eingabe einer einzelnen einem bestimmten Benutzer zugewiesenen IP-Adresse für die HA-Schnittstelle eines DLR wird nicht berücksichtigt. Die Eingabe von mehr als einer IP-Adresse führt zu einem internen Serverfehler.
Behobenes Problem 1874782: NSX Edge kann aufgrund eines Problems bei der Herstellung einer Verbindung mit dem Nachrichtenbus nicht verwaltet werden
Wenn bei NSX Edge Probleme beim Verbindungsaufbau mit dem Nachrichtenbus auftreten, kann NSX Manager die Konfiguration nicht ändern oder keine Informationen von NSX Edge abrufen.
Behobenes Problem 1461421: In der Ausgabe des Befehls „show ip bgp neighbor“ für NSX Edge wird die bisherige Anzahl an zuvor eingerichteten Verbindungen beibehalten
Mit dem Befehl „show ip bgp neighbor“ wird angezeigt, wie oft für einen bestimmten Peer die Maschine mit dem Status „BGP“ in den Status „Eingerichtet“ übergegangen ist. Die Änderung des Kennworts einer MD5-Authentifizierung führt dazu, dass die Peer-Verbindung aufgehoben und dann erneut erstellt wird, wodurch die Zählung gelöscht wird. Dieses Problem tritt nicht mit einem Edge-DLR auf.
Behobenes Problem 1499978: Edge-Syslog-Meldungen erreichen den Remote-Syslog-Server nicht
Unmittelbar nach der Bereitstellung kann der Edge-Syslog-Server die Hostnamen für alle konfigurierten Remote-Syslog-Server nicht auflösen.
Behobenes Problem 1916360: Hochverfügbarkeits-Failover schlägt möglicherweise aufgrund einer vollen Festplatte fehl, wenn mehr als 100 Routen installiert sind
Wenn mehr als 100 Routen installiert sind, übermittelt der VMware Tools-Daemon auf dem Standby-Edge alle 30 Sekunden 2 Warnprotokollmeldungen. Die Protokolle werden in einer Datei namens „/var/log/vmware-vmsvc.log“ gespeichert, die im Laufe der Zeit den gesamten Speicherplatz der Protokollpartition belegen kann. Die Protokollrotation ist für diese Protokolldatei nicht konfiguriert. Wenn dieses Problem auftritt, schlägt das Hochverfügbarkeits-Failover möglicherweise fehl.
Behobenes Problem 1634215: Die Ausgabe von OSPF CLI-Befehlen gibt nicht wieder, ob das Routing deaktiviert ist.
Wenn OSPF deaktiviert ist, wird in der Ausgabe der CLI-Routing-Befehle nicht "OSPF is disabled" angezeigt. Die Ausgabe ist leer.
Behobenes Problem 1716464: NSX-Load Balancer führt keine Weiterleitung zu VMs durch, die kürzlich mit einem Sicherheits-Tag versehen wurden.
Wenn wir zwei VMs mit einem bestimmten Tag bereitstellen und anschließend einen LB für die Weiterleitung zu dem entsprechenden Tag konfigurieren, führt der LB die Weiterleitung zu diesen beiden VMs erfolgreich durch. Falls wir jedoch eine dritte VM mit dem entsprechenden Tag bereitstellen, führt der LB die Weiterleitung nur zu den ersten beiden VMs durch.
Behobenes Problem 1935204: DLR benötigt 1 bis 1,5 Sekunden für die ARP-Auflösung
Wenn die ARP-Unterdrückung fehlschlägt, dauert die lokale ARP-Auflösung durch den DLR für eine VM, die auf einem Remotehost ausgeführt wird, ca. 1 bis 1,5 Sekunden.
Behobenes Problem 1777792: Wenn für den Peer-Endpoint „BELIEBIG“ festgelegt wurde, kann keine IPSec-Verbindung hergestellt werden
Wenn in der IPSec-Konfiguration für NSX Edge der Remote-Peer-Endpoint auf „BELIEBIG“ festgelegt wurde, verhält sich das Edge wie ein IPSec-„Server“ und wartet auf Remote-Peers zur Initiierung von Verbindungen. Wenn allerdings der Initiator eine Anforderung zur Authentifizierung mithilfe von PSK+XAUTH sendet, wird von Edge folgende Fehlermeldung angezeigt: „Ursprüngliche Nachricht des Hauptmodus wurde unter XXX.XXX.XX.XX:500 empfangen, aber es wurde keine Verbindung mit der Richtlinie PSK+XAUTH autorisiert“. IPSec kann dann nicht eingerichtet werden.
Behobenes Problem 1881348: Problem bei der Konfiguration von AS_TRANS (ASN 23456) als lokale Autonomous System Number (ASN) für BGP.
Wenn AS_TRANS (ASN 23456) als lokale Autonomous System Number (ASN) für BGP konfiguriert wird, kommt es zu einem ESG/DLR-Problem.
BGP-Nachbarn werden nicht angezeigt, auch wenn die Autonomous System Number (ASN) in eine gültige Nummer geändert wird.
Behobenes Problem 1792548: NSX Controller bleibt möglicherweise mit folgender Meldung hängen: „Warten auf Verknüpfung mit Cluster“
NSX Controller bleibt möglicherweise mit folgender Meldung hängen: „Warten auf Verknüpfung mit Cluster“ (CLI-Befehl:show control-cluster status). Dieses Problem tritt auf, wenn bei der Aktivierung des Controllers für die Schnittstellen eth0 und breth0 dieselbe IP-Adresse konfiguriert wurde. Sie können dies mithilfe des folgenden CLI-Befehls auf dem Controller überprüfen: show network interface
Behobenes Problem 1983497: Violetter Bildschirm wird angezeigt, wenn gleichzeitig ein Brücken-Failover und eine Brücken-Konfigurationsänderung erfolgen
Wenn ein Brücken-Failover und eine Brücken-Konfigurationsänderung gleichzeitig erfolgen, kann dies zu einem Deadlock und einem violetten Bildschirm führen. Die Wahrscheinlichkeit eines Deadlocks ist gering.
Behobenes Problem 1849042/1849043: Das Administratorkonto wird gesperrt, wenn der Ablauf von Kennwörtern auf der NSX Edge-Appliance konfiguriert ist
Wenn für den Admin-Benutzer auf der NSX Edge-Appliance der Ablauf von Kennwörtern konfiguriert ist, wird der Benutzer nach dem Ablauf des Kennworts in einem Zeitraum von sieben Tagen zur Änderung des Kennworts aufgefordert, wenn er sich bei der Appliance anmeldet. Kommt es beim Ändern des Kennworts zu Fehlern, wird das Konto gesperrt. Wenn darüber hinaus das Kennwort zum Zeitpunkt der Anmeldung an der CLI-Eingabeaufforderung geändert wird, erfüllt das neue Kennwort eventuell nicht die Richtlinie für sichere Kennwörter, die von der Benutzeroberfläche und REST erzwungen wird.
Behobenes Problem 1982690: Der NSX Controller speichert den MAC-Eintrag der Workload-VM nicht auf dem ESXi-Host, auf dem die aktive L2-Bridging-Kontroll-VM ausgeführt wird.
Möglicherweise wird der Datenverkehr für alle Arbeitslast-VMs verworfen, die auf dem Hypervisor installiert sind, auf dem die aktive Bridging-Kontroll-VM ausgeführt wird.
Behobenes Problem 1753621: Wenn ein Edge mit einem privaten lokalen AS Weiterleitungen an EBGP-Peers sendet, werden sämtliche private AS-Pfade aus den gesendeten BGP-Routing-Aktualisierungen gelöscht.
NSX for vSphere weist derzeit eine Einschränkung auf, die verhindert, dass der vollständige AS-Pfad für eBGP-Nachbarn freigegeben wird, wenn der AS-Pfad nur private AS-Pfade enthält. Auch wenn dies in den meisten Fällen das gewünschte Verhalten ist, gibt es Fälle, in denen der Administrator möglicherweise private AS-Pfade für einen externen BGP-Nachbarn freigeben möchte. Durch diese Behebung können Sie das Verhalten des „privaten AS-Pfads“ für externe BGP-Peers ändern. Das Standardverhalten für diese Funktion ist „private ASN entfernen“ in Übereinstimmung mit vorherigen Versionen von NSX for vSphere-Versionen.
Behobenes Problem 1954964: HA-Engine-Status wird auf Standby-ESG nach einem Split-Brain nicht korrekt aktualisiert
In einigen Fällen wird nach einer Split-Brain-Wiederherstellung der Status der Standby-ESG-Config-Engine nicht korrekt aktualisiert. Dies ist führt zu einem inkonsistenten Status, in dem es für Kunden zeitweilig zur Verwerfung des Datenverkehrs kommt.
Behobenes Problem 1920574: Teilschnittstellen für ein Edge können nicht konfiguriert werden
Das Erstellen von Teilschnittstellen auf einem Edge ist mit NSX for vSphere 6.3.2/6.3.3 nicht möglich (Teilschnittstelle mit der IP-Adresse kann nicht veröffentlicht werden).
Behobenes Problem 1772473: SSLVPN-Clients können IP-Adresse nicht vom IP-Pool abrufen
Clients können keine Verbindung mit privaten Netzwerken herstellen, da aus dem IP-Pool keine IP-Adresse zugewiesen wird. Die IP-Adresse aus dem IP-Pool wird bei einer automatischen erneuten Verbindungsherstellung verbraucht.

Clients können keine Verbindung mit einem privaten Netzwerk herstellen, da vom IP-Pool keine IP zugewiesen wird, wenn der Client sich automatisch neu mit dem Server verbindet. Außerdem wird die alte IP, die dem Client vom IP-Pool zugewiesen wurde, nicht bereinigt.

Behobene Probleme beim NSX Manager

Behobenes Problem 1804116: Der logische Router meldet einen fehlerhaften Status auf einem Host, für den keine Kommunikation mit NSX Manager möglich ist
Wenn ein logischer Router auf einem Host eingeschaltet oder erneut bereitgestellt wird, der nicht mit NSX Manager kommunizieren kann (aufgrund eines NSX-VIB-Upgrade-/Installationsfehlers oder eines Hostkommunikationsproblems), meldet der logische Router einen fehlerhaften Status, und die fortlaufende automatische Wiederherstellung über eine erzwungene Synchronisierung kann nicht durchgeführt werden.
Behobenes Problem 1786515: Benutzer mit Sicherheitsadministratorrechten können die Load Balancer-Konfiguration nicht über die Benutzeroberfläche von vSphere Web Client bearbeiten
Ein Benutzer mit den Rechten eines Sicherheitsadministrators für ein bestimmtes NSX Edge kann die globale Load-Balancer-Konfiguration für dieses Edge nicht mit der Benutzeroberfläche von vSphere Web Client bearbeiten. Die folgende Fehlermeldung wird angezeigt: „Der Benutzer ist nicht berechtigt, auf das Objekt ‚Global‘ und die Funktion si.service zuzugreifen. Überprüfen Sie den Geltungsbereich für den Objektzugriff und die Funktionsberechtigungen für den Benutzer.“
Behobenes Problem 1801325: In NSX Manager mit hoher CPU- und/oder Festplattenauslastung generierte „kritische“ Systemereignisse und Protokollmeldungen
Bei hoher Festplattenauslastung, umfangreichen Änderungen der Auftragsdaten oder einer großen Auftragswarteschlange auf NSX Manager können ein oder mehrere der folgenden Probleme auftreten:
- „Kritische“ Systemereignisse im vSphere Web Client
- Hohe Festplattenauslastung auf NSX Manager für die Partition /common
- Hohe CPU-Auslastung über einen längeren Zeitraum oder in regelmäßigen Intervallen
- Negative Auswirkungen auf die Leistung von NSX Manager
Problemumgehung: Wenden Sie sich an den VMware-Kundensupport. Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 2147907.
Behobenes Problem 1902723: Das NSX Edge-Dateipaket wird nicht nach jeder Veröffentlichung aus dem Verzeichnis /common/tmp gelöscht, weshalb sich das Verzeichnis /common anfüllt
Das Verzeichnis /common füllt sich an und für NSX Manager ist nicht mehr genügend Speicherplatz verfügbar, weil das NSX Edge-Dateipaket (sslvpn-plus config) nicht aus /common/tmp gelöscht wird.
Behobenes Problem 1954628: Wiederherstellungsvorgang schlägt fehl, sobald der Datenträger „/common“ voll ist.
Wenn eine Sicherung auf einem NSX Manager wiederhergestellt wird und auf dem Datenträger „/common“ nicht ausreichend Speicherplatz verfügbar ist, schlägt die Wiederherstellung möglicherweise fehl. Der Fehler wird auf der Seite „Zusammenfassung“ der Appliance gemeldet. Der NSX Manager erreicht einen inkonsistenten Zustand, aus dem keine Wiederherstellung möglich ist.

Behobene Probleme bei Sicherheitsdiensten

Behobenes Problem 2029693: In einer DFW-Skalierungsumgebung (mit mehr als 65.000 Regeln) dauert die Veröffentlichung von DFW-Regeln möglicherweise etwas länger.
Firewallregeln werden erst 10 bis 15 Minuten nach der Veröffentlichung wirksam. Problem in 6.4.0 behoben.
Behobenes Problem 1662020: Eine Veröffentlichung scheitert mit der Fehlermeldung „Die letzte Veröffentlichung ist auf Host Hostnummer fehlgeschlagen“ in den Abschnitten „Allgemein“ und „Partnersicherheitsdienste“ der Benutzeroberfläche der verteilten Firewall
Nach der Änderung einer Regel wird in der Benutzeroberfläche die Meldung „Die letzte Veröffentlichung ist auf Host Hostnummerfehlgeschlagen“ angezeigt. Die in der Benutzeroberfläche aufgeführten Hosts verfügen eventuell nicht über die korrekte Version der Firewallregeln, sodass es zu Sicherheitslücken und/oder zu einer Netzwerkunterbrechung kommt.

Das Problem tritt in der Regel in folgenden Fällen auf:
- Nach dem Upgrade einer älteren auf die neueste NSX-Version.
- Nach der Verschiebung eines Hosts aus einem Cluster und seine Verschiebung zurück in den Cluster.
- Nach der Verschiebung eines Hosts von einem Cluster in einen anderen.
Behobenes Problem 1496273: Auf der Benutzeroberfläche können Sie NSX-Firewallregeln für beide Richtungen erstellen, die nicht auf Edges angewendet werden können
Fälschlicherweise lässt der Web Client das Erstellen einer NSX-Firewallregel zu, die auf einen oder mehrere NSX Edges angewendet wird, wenn die Regel über Datenverkehr verfügt, der in eine der beiden Richtungen gesendet wird, bzw. wenn es sich bei dem Pakettyp um IPV4 oder IPV6 handelt. Auf der Benutzeroberfläche sollte das Erstellen solcher Regeln nicht zulässig sein, da NSX diese nicht auf NSX Edges anwenden kann.
Behobenes Problem 1854661: In einem Cross-VC-Setup zeigen die gefilterten Firewallregeln nicht den Indexwert beim Wechsel zwischen NSX Managern an
Nach der Anwendung von Kriterien einer Filterregel auf einen NSX Manager und dem Wechsel zu einem anderen NSX Manager zeigt der Index der Regel für alle gefilterten Regeln „0“ statt der tatsächlichen Position der Regel an.
Behobenes Problem 2000749: Verteilte Firewall bleibt bei bestimmten Firewall-Konfigurationen im Zustand „Veröffentlichen“
Die verteilte Firewall bleibt im Zustand „Veröffentlichen“, wenn Sie über eine Sicherheitsgruppe verfügen, die ein IPSet mit 0.0.0.0/0 als AUSSCHLUSS-Mitglied, als EINSCHLUSS-Mitglied oder als Teil einer dynamischen Mitgliedschaft mit Schnittmenge (UND) enthält.
Behobenes Problem 1628679: Bei Verwendung einer identitätsbasierten Firewall ist die VM von entfernten Benutzern weiterhin Teil der Sicherheitsgruppe
Wenn ein Benutzer aus einer Gruppe auf dem AD-Server entfernt wird, gehört die VM, für die der Benutzer angemeldet ist, weiterhin zur Sicherheitsgruppe. Dadurch werden die Firewallrichtlinien für die VM-vNIC auf dem Hypervisor beibehalten, sodass der Benutzer über einen kompletten Zugriff auf die Dienste verfügt.
Behobenes Problem 1787680: Globaler Firewallabschnitt kann nicht gelöscht werden, wenn sich NSX Manager im Transitmodus befindet
Wenn Sie versuchen, einen globalen Firewallabschnitt über die Benutzeroberfläche von NSX Manager im Transitmodus zu löschen und dann eine Veröffentlichung durchzuführen, schlägt dies fehl. Sie sind dann nicht mehr in der Lage, NSX Manager in den eigenständigen Modus zu versetzen.
Behobenes Problem 1773240: Rolle „Security Administrator“ darf keine Service Insertion-/Umleitungsregeln bearbeiten oder veröffentlichen
Wenn ein Benutzer mit der Rolle/Berechtigung „Security Administrator“ versucht, Service Insertion-Regeln zu erstellen, zu ändern oder zu veröffentlichen, schlägt der Vorgang fehl.
Behobenes Problem 1845174: Auf der Benutzeroberfläche werden keine Sicherheitsgruppen mehr angezeigt, nachdem die Sicherheitsrichtlinie zugewiesen wurde
Auf der Benutzeroberfläche werden keine Sicherheitsgruppen mehr angezeigt, nachdem die Sicherheitsrichtlinie zugewiesen wurde.
Behobenes Problem 1839953: ARP-Unterdrückung der Teilschnittstellen-IP-Adressen von Gast-VMs schlägt fehl
Die ARP-Auflösung dieser Schnittstellen dauert beim ersten Mal etwas länger als üblich (1 Sekunde).

Bekannte Probleme

Die bekannten Probleme gliedern sich in folgende Gruppen.

Allgemeine bekannte Probleme
Bekannte Installations- und Upgrade-Probleme
Bekannte Probleme bei NSX Manager
Probleme bei logischen Netzwerken und NSX Edge
Bekannte Probleme bei Sicherheitsdiensten
Bekannte Probleme bei Überwachungsdiensten

Allgemeine bekannte Probleme

Problem 1931236: Auf Registerkarten der Benutzeroberfläche wird Systemtext angezeigt
Auf Registerkarten der Benutzeroberfläche wird Systemtext angezeigt, z. B. „Dashboard.System.Scale.Title“ anstelle von „Systemskalierung“.

Problemumgehung: Löschen Sie die Browser-Cookies und aktualisieren Sie den Browser oder melden Sie sich bei vSphere Client ab und wieder an.
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 1944031: Die DNS-Überwachung verwendet den Standardport 53 für die Systemdiagnose anstelle von anderen Ports
Der Überwachungsport des Poolmitglieds wird von der Dienstüberwachung verwendet, um Systemdiagnosen anhand des Backend-Servers durchzuführen. Die DNS-Überwachung verwendet Standardport 53 unabhängig vom definierten Überwachungsport. Ändern Sie den Überwachungsport des Backend-DNS-Servers nicht in einen anderen Wert als 53, sonst schlägt die DNS-Überwachung fehl.
Problem 1874863: Fehler bei der Authentifizierung mit einem geänderten Kennwort nach der Deaktivierung/Aktivierung des SSL VPN-Dienstes bei einem lokalen Authentifizierungsserver
Wenn der SSL VPN-Dienst bei Verwendung einer lokalen Authentifizierung deaktiviert und dann wieder aktiviert wurde, können sich Benutzer mit geänderten Kennwörtern nicht anmelden.

Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 2151236.
Problem 1702339: Bei Schwachstellenprüfungen wird möglicherweise die Quagga-Schwachstelle „bgp_dump_routes“ (CVE-2016-4049) gemeldet
Bei Schwachstellenprüfungen in NSX for vSphere wird möglicherweise die Quagga-Schwachstelle „bgp_dump_routes“ (CVE-2016-4049) gemeldet. NSX for vSphere verwendet Quagga, doch die BGP-Funktionalität (die die Schwachstelle erkennt) ist nicht aktiviert. Diese Schwachstellenwarnung kann bedenkenlos ignoriert werden.

Problemumgehung: Da das Produkt nicht anfällig ist, ist keine Problemumgehung erforderlich.
Problem 1926467: In Chrome Version 59.0.3071.115 wird der Cursor in der NSX Manager-Appliance nicht angezeigt
Beim Öffnen der NSX Manager-Appliance mit Chrome Version 59.0.3071.115 können Sie den Cursor bei der Eingabe von Benutzername und Kennwort nicht sehen. Sie können dennoch Ihre Anmeldedaten eingeben, auch wenn der Cursor nicht sichtbar ist.

Problemumgehung: Führen Sie ein Upgrade Ihres Browsers auf Chrome Version 61.0.3163.100, 64.0.3253.0 oder höher durch.
Problem 2015520: Bridging-Konfiguration schlägt fehl, wenn der Bridge-Name mehr als 40 Zeichen lang ist
Die Bridging-Konfiguration schlägt fehl, wenn der Bridge-Name mehr als 40 Zeichen lang ist.

Problemumgehung: Geben Sie bei der Bridge-Konfiguration nicht mehr als 40 Zeichen für den Bridge-Namen ein.
Problem 1934704: Nicht-ASCII-Name wird für Bridge-Namen nicht unterstützt
Wenn Sie Nicht-ASCII-Zeichen für Bridge-Namen in VDR verwenden, wird die Bridge-Konfiguration auf dem Host nicht angezeigt und der Bridge-Datenpfad funktioniert nicht.

Problemumgehung: Verwenden Sie ASCII-Zeichen für den Bridge-Namen.
Problem 1529178: Das Hochladen eines Server-Zertifikats, das keinen allgemeinen Namen enthält, führt zur Meldung „Interner Serverfehler“.
Wenn Sie ein Server-Zertifikat ohne einen allgemeinen Namen hochladen, wird die Meldung „Interner Serverfehler“ eingeblendet.
Problem 2013820: Gruppierungsobjekt kann als Poolmitglied nicht in verschiedenen Pools gemeinsam genutzt werden, die unterschiedliche IP-Filter-Richtlinien verwenden
Ein Gruppierungsobjekt kann als Poolmitglied nicht in verschiedenen Pools gemeinsam genutzt werden, die unterschiedliche IP-Filter-Richtlinien verwenden.

Problemumgehung:
1. Wenn das Gruppierungsobjekt als Poolmitglied von mehreren Pools gemeinsam genutzt werden soll, müssen Sie sicherstellen, dass alle Pools die gleiche IP-Filterrichtlinie verwenden.
2. Verwenden Sie direkt die IP-Adresse des Gruppierungsobjekts, wenn es als Poolmitglied von verschiedenen Pools mit unterschiedlichen IP-Filterrichtlinien gemeinsam genutzt werden soll.
Problem 2016689: SMB-Anwendung wird für RDSH-Benutzer nicht unterstützt
Wenn Sie eine RDSH-Firewallregel erstellen, die eine SMB-Anwendung blockiert/zulässt, ist diese Regel nicht wirksam.

Problemumgehung: Keine.
Problem 2007991: Remote-Desktop(RDP)-Server oder -Client-Versionen 4.0, 5.0, 5.1, 5.2 und 6.0 werden nicht von der DFW als L7-Protokoll klassifiziert.
Wird in der Umgebung des Kunden RDP-Server- oder -Client-Version 4.0, 5.0, 5.1, 5.2 oder 6.0 verwendet, so wird der RDP-Datenverkehr durch die Schicht-7-DFW-Regel nicht als RDP-Datenverkehr mit APP_RDP als Dienst identifiziert. Wenn der RDP-Datenverkehr von der DFW-Regel blockiert werden soll, geschieht dies möglicherweise nicht.

Problemumgehung: Erstellen Sie eine Schicht-4-Regel mit dem Schicht-4-RDP-Dienst entsprechend dem RDP-Datenverkehr.
Problem 1993691: Das Entfernen eines Hosts, ohne diesen zunächst als Replizierungsknoten zu entfernen, kann zu veralteten Einträgen in NSX Manager führen.
Wenn ein Host als Replizierungsknoten für einen HW-VTEP dient und aus dem übergeordneten Cluster entfernt werden muss, stellen Sie zunächst sicher, dass er kein Replizierungsknoten mehr ist, bevor Sie ihn aus dem Cluster entfernen. Andernfalls behält er in einigen Fällen seinen Status als Replizierungsknoten in der NSX Manager-Datenbank, was bei der Bearbeitung von weiteren Replizierungsknoten zu Fehlern führen kann.

Problemumgehung: Weitere Informationen finden Sie im Knowledgebase-Artikel 52418.
Problem 2164138: Beim Vorbereiten eines Clusters für NSX wird der ixgbe-Treiber auf Hosts mit physischen Netzwerkkarten mit ausgeführtem ixgbe-Treiber erneut geladen
Der ixgbe-Treiber wird erneut geladen, um die RSS-Option (Receive Side Scaling) zu aktivieren, um den VXLAN-Durchsatz zu verbessern. Das erneute Laden des ixgbe-Treibers sorgt dafür, dass die vmNICs, die den ixgbe-Treiber verwenden, nur wenige Sekunden lang ausfallen und gesichert werden. In seltenen Fällen kann der ixgbe-Treiber nicht erneut geladen werden und die vmNICs, die den ixgbe-Treiber verwenden, bleiben inaktiv, bis der ESXi-Host neu gestartet wird.

Problemumgehung: Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 52980.

Bekannte Installations- und Upgrade-Probleme

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

Problem 2036024: NSX Manager-Upgrade bleibt aufgrund der Datenbankfestplattenauslastung bei „Verifying uploaded file“ (Hochgeladene Datei wird überprüft) hängen
Die Upgrade-Protokolldatei „vsm-upgrade.log“ enthält außerdem die folgende Meldung: „Database disk usage is at 75%, but it should be less than 70%“ (Datenbankfestplattenauslastung ist bei 75 %, sollte jedoch unter 70 % liegen). Sie können die Datei „vsm-upgrade.log“ im NSX Manager-Support-Paket anzeigen. Navigieren Sie zu Networking & Security > Support-Paket und wählen Sie die Einstellung zur Einbindung der NSX Manager-Protokolle aus.

Problemumgehung: Wenden Sie sich an den VMware-Kundensupport.
Problem 2033438: vSphere Web Client zeigt „Kein NSX Manager verfügbar“ an, wenn ein Upgrade auf NSX 6.4.0 durchgeführt wird und nur TLS 1.0 aktiviert ist
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.

Problemumgehung: 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.
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“.

Problemumgehung: Beenden Sie den Wartungsmodus für den Host manuell. Klicken Sie auf „Nicht bereit“ und dann auf dem Cluster auf „Alle auflösen“.
Problem 1959940: Fehler bei der Bereitstellung von NSX Manager OVF mithilfe von ovftool: „Ungültiger OVF-Name (VSMgmt) in der angegebenen net-Zuordnung“
Ab der Version NSX 6.4.0 ist „VSMgmt“ kein gültiger Name für die net-Zuordnung in der OVF-Appliance mehr und wird durch „Verwaltungsnetzwerk“ ersetzt.

Problemumgehung: Verwenden Sie stattdessen „Verwaltungsnetzwerk“. Verwenden Sie beispielsweise anstatt „--net:VSMgmt='VM Network' use --net:'Management Network=VM Network'“.
Problem 2001988: Während eines NSX-Hostcluster-Upgrades wechselt der Installationsstatus für den gesamten Cluster auf der Registerkarte „Hostvorbereitung“ zwischen „Nicht bereit“ und „Wird installiert“, wenn jeder Host im Cluster aktualisiert wird
Während eines NSX-Upgrades wird durch Klicken auf „Upgrade verfügbar“ ein Host-Upgrade für NSX-vorbereitete Cluster ausgelöst. Bei als „DRS FULL AUTOMATIC“ konfigurierten Clustern wechselt der Installationsstatus zwischen „Wird installiert“ und „Nicht bereit“, obwohl die Hosts im Hintergrund problemlos aktualisiert werden.

Problemumgehung: Dieses Problem betrifft die Benutzeroberfläche und kann ignoriert werden. Warten Sie den Fortschritt des Hostcluster-Upgrades ab.
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.

Problemumgehung: Beenden Sie den Wartungsmodus für die Hosts manuell. Dieses Problem tritt nicht auf, wenn Hosts mit vCenter Server Version 6.5a und höher verwaltet werden.
Problem 1797929: Der Nachrichtenbuskanal ist nach einem Hostcluster-Upgrade nicht verfügbar
Nach einem Hostcluster-Upgrade wird von vCenter 6.0 (und früher) das Ereignis „Erneut verbinden“ nicht generiert. Dies führt dazu, dass NSX Manager keine Messaging-Infrastruktur auf dem Host einrichtet. Dieses Problem wurde in vCenter 6.5 behoben.

Problemumgehung: Synchronisieren Sie erneut die Messaging-Infrastruktur, wie im folgenden API-Aufruf dargestellt:
POST https://<ip>:/api/2.0/nwfabric/configure?action=synchronize
```
<nwFabricFeatureConfig>
  <featureId>com.vmware.vshield.vsm.messagingInfra</featureId>
  <resourceConfig>
    <resourceId>host-15</resourceId>
  </resourceConfig>
</nwFabricFeatureConfig>
```
Problem 1263858: SSL VPN sendet keine Upgrade-Benachrichtigung an den Remote-Client
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 1979457: Wenn die GI-SVM während des Upgrades im Abwärtskompatibilitätsmodus gelöscht oder entfernt wird, ist die identitätsbasierte Firewall über Guest Introspection (GI) nur dann funktionsfähig, wenn der GI-Cluster aktualisiert wird.
Die identitätsbasierte Firewall ist nicht funktionsfähig und es werden keine Protokolle im Zusammenhang mit der identitätsbasierten Firewall angezeigt. Der identitätsbasierte Firewall-Schutz ist aufgehoben, bis der Cluster aktualisiert wird.

Problemumgehung: Aktualisieren Sie den Cluster, damit die neuere Version der GI-SVM auf allen Hosts ausgeführt wird.

-oder-

Aktivieren Sie den Log Scraper, damit die identitätsbasierte Firewall funktioniert.
Problem 2016824: NSX-Kontext-Engine kann nach Guest Introspection-Installation und/oder -Upgrade nicht gestartet werden
Dieses Problem tritt auf, wenn Guest Introspection (GI) installiert oder aktualisiert wird, bevor die Hostvorbereitung abgeschlossen ist. Die identitätsbasierte Firewall für RDSH-VMs funktioniert nicht, wenn die Kontext-Engine nicht gestartet wird.

Problemumgehung: Details finden Sie im VMware-Knowledgebase-Artikel 51973.
Problem 2027916: Der Upgrade-Koordinator zeigt möglicherweise an, dass Controller mit fehlgeschlagenem Upgrade erfolgreich aktualisiert wurden.
Wenn bei einem Controller-Cluster mit drei Knoten der dritte Controller beim Upgrade fehlgeschlagen ist und entfernt wird, wird das gesamte Upgrade des Controller-Clusters möglicherweise als erfolgreich gekennzeichnet, obwohl das Upgrade fehlgeschlagen ist.

Problemumgehung: Überprüfen Sie die Registerkarte „Installieren & Upgrade durchführen“ > „Management“ und stellen Sie sicher, dass alle Controller den Status „Aktualisiert“ aufweisen, bevor Sie für andere Komponenten (Hosts, Edges usw.) ein Upgrade durchführen.

Bekannte Probleme bei NSX Manager

Problem 1991125: Gruppierungsobjekte, die in einer Application Rule Manager-Sitzung auf 6.3.x erstellt wurden, werden nach dem Upgrade von NSX Manager auf 6.4.0 nicht auf dem Dashboard angezeigt
Gruppierungsobjekte, die in einer Application Rule Manager-Sitzung auf 6.3.x erstellt wurden, werden nach dem Upgrade von NSX Manager auf 6.4.0 nicht auf dem Dashboard angezeigt.

Problemumgehung: Gruppierungsobjekte, die in einer Application Rule Manager-Sitzung auf 6.3.x erstellt wurden, sind nach dem Upgrade von NSX Manager auf 6.4.0 verfügbar. Die Gruppierungsobjekte stehen auf der entsprechenden Seite im Abschnitt „Gruppieren von Objekten“ zur Verfügung.
Problem 1892999: Die eindeutigen Auswahlkriterien können nicht geändert werden, auch wenn keine virtuellen Maschinen an ein universelles Sicherheits-Tag angehängt sind
Wenn eine virtuelle Maschine, die an ein universelles Sicherheits-Tag angehängt ist, gelöscht wird, bleibt ein internes Objekt für die virtuelle Maschine weiterhin mit dem universellen Sicherheits-Tag verbunden. Dies führt dazu, dass die globalen Auswahlkriterien nicht geändert werden können und eine Fehlermeldung eingeblendet wird, dass die universellen Sicherheits-Tags weiterhin mit den virtuellen Maschinen verbunden sind.

Problemumgehung: Löschen Sie alle universellen Sicherheits-Tags und ändern Sie die globalen Auswahlkriterien.

Probleme bei logischen Netzwerken und NSX Edge

Problem 1983902: In einer Umgebung zur Skalierungseinrichtung wird netcpad nach dem Neustart von NSX Manager nicht sofort mit vsfwd verbunden
Dies wirkt sich nicht auf Datenpfade aus. Das System wird ohne Eingriff nach 13 Minuten wiederhergestellt.

Problemumgehung: Keine
Problem 1747978: OSPF-Nachbarschaften werden mit der MD5-Authentifizierung nach einem NSX Edge-HA-Failover gelöscht
Wenn in einer NSX for vSphere 6.2.4-Umgebung NSX Edge für eine Hochverfügbarkeit mit OSPF ein ordnungsgemäßer Neustart konfiguriert ist und MD5 für die Authentifizierung verwendet wird, kann OSPF nicht ordnungsgemäß neu starten. Es werden nur dann Nachbarschaften gebildet, wenn der Lebensdauer-Timer auf den OSPF-Nachbarschaftsknoten abgelaufen ist.

Problemumgehung: Keine
Problem 1525003: Die Wiederherstellung einer NSX Manager-Sicherung mit einer fehlerhaften Passphrase scheitert ohne Rückmeldung, da auf zentrale Stammordner nicht zugegriffen werden kann

Problemumgehung: Keine.
Problem 1995142: Host wird nach dem Entfernen aus der vCenter-Bestandsliste nicht vom Replizierungscluster entfernt
Wenn ein Benutzer einen Host zu einem Replizierungscluster hinzufügt und den Host dann aus der vCenter-Bestandsliste entfernt, bevor er vom Cluster entfernt wurde, verbleibt der Legacyhost im Cluster.

Problemumgehung: Stellen Sie beim Entfernen eines Hosts zunächst sicher, dass er ggf. bereits vom Replizierungscluster entfernt wurde.
Problem 2005973: Routing-Daemon MSR verliert die gesamte Routing-Konfiguration, nachdem einige GRE-Tunnel gelöscht wurden und anschließend eine Synchronisierung des Edge-Knotens über die Managementebene erzwungen wurde
Dieses Problem kann auf einem Edge mit BGP-Sitzungen über GRE-Tunnel auftreten. Wenn einige GRE-Tunnel gelöscht werden und dann eine erzwungene Synchronisierung des Edge über die Managementebene durchgeführt wird, verliert das Edge die gesamte Routing-Konfiguration.

Problemumgehung: Starten Sie den Edge-Knoten neu.
Problem 2015368: Firewallprotokollierung führt unter bestimmten Umständen zu unzureichendem Arbeitsspeicher
Wenn die Edge-Firewall in umfangreichen Konfigurationen aktiviert ist und die Firewallprotokollierung für einige oder alle Regeln aktiviert ist, kommt es in seltenen Fällen auf dem Edge zu Problemen aufgrund von unzureichendem Arbeitsspeicher (OOM, Out-Of-Memory). Dies ist insbesondere der Fall, wenn die Protokollierungsregeln sehr viel Datenverkehr verarbeiten müssen. Wenn eine OOM-Bedingung auftritt, wird die Edge-VM automatisch neu gestartet.

Problemumgehung: Die Firewallprotokollierung sollte am besten nur für Debugging-Zwecke verwendet und für die normale Anwendung wieder deaktiviert werden. Um dieses OOM-Problem zu vermeiden, deaktivieren Sie jegliche Firewallprotokollierung.
Problem 2005900: Routing-Daemon MSR auf Edge bleibt bei 100 % CPU-Auslastung stehen, wenn alle GRE-Tunnel in einer Skalierungstopologie mit 8-Wege-iBGP/Multihop-BGP-ECMP fluktuieren.
Dieses Problem kann in einer Skalierungstopologie auftreten, für die iBGP oder Multihop-BGP auf ESG mit mehreren Nachbarn über viele GRE-Tunnel konfiguriert ist. Wenn mehrere GRE-Tunnel fluktuieren, bleibt MSR möglicherweise für unbestimmte Zeit bei 100 % der CPU-Auslastung hängen.

Problemumgehung: Starten Sie den Edge-Knoten neu.

Bekannte Probleme bei Sicherheitsdiensten

Problem 1948648: Änderungen der AD-Gruppenmitgliedschaft werden bei Verwendung von identitätsbasierten RDSH-Firewallregeln für angemeldete Benutzer nicht sofort wirksam
Identitätsbasierte RDSH-Firewallregeln werden erstellt. Ein Active Directory-Benutzer meldet sich bei seinem RDS-Desktop an, und die Firewallregeln werden angewendet. Der AD-Administrator nimmt dann Änderungen an der Gruppenmitgliedschaft des AD-Benutzers vor, und eine Delta-Synchronisierung auf dem NSX Manager wird durchgeführt. Allerdings wird die Änderung der AD-Gruppenmitgliedschaft für den angemeldeten Benutzer nicht sofort sichtbar und führt nicht zu einer Änderung der aktiven Firewallregeln des Benutzers. Dieses Verhalten ist eine Beschränkung von Active Directory.

Problemumgehung: Benutzer müssen sich ab- und wieder anmelden, damit die Änderungen an der AD-Gruppenmitgliedschaft wirksam werden.
Problem 2017806: Fehlermeldung beim Hinzufügen von Mitgliedern zu Sicherheitsgruppen, die in RDSH-Firewallabschnitten von Sicherheitsrichtlinien verwendet werden, ist nicht eindeutig
Wenn eine Sicherheitsgruppe in RDSH-Firewallabschnitten von Sicherheitsrichtlinien verwendet wird, können Sie dieser nur Verzeichnisgruppenmitglieder hinzufügen. Wenn Sie versuchen, ein anderes Mitglied als eine Verzeichnisgruppe hinzuzufügen, wird die folgende Fehlermeldung angezeigt:
„Sicherheitsgruppe wird von Service Composer-Firewall verwendet und kann nicht geändert werden“

Der Fehlermeldung ist nicht zu entnehmen, dass die Sicherheitsgruppe nicht geändert werden kann, weil die Sicherheitsgruppe in RDSH-Firewallabschnitten von Sicherheitsrichtlinien verwendet wird.

Problemumgehung: Keine.
Problem 2026069: Verwendung der Triple DES-Verschlüsselung als Verschlüsselungsalgorithmus im NSX Edge-IPSec-VPN-Dienst kann nach einem Upgrade zum Verlust von IPSec-Tunneln bei IPSec-Sites führen
VMware rät aus Sicherheitsgründen von der Verwendung von 3DES als Verschlüsselungsalgorithmus im NSX Edge-IPSec-VPN-Dienst ab. Dieser Verschlüsselungsalgorithmus ist jedoch aus Gründen der Interoperabilität in NSX-Versionen bis zur Version 6.4 verfügbar. Vor dem Hintergrund von Sicherheitsempfehlungen wird diese Verschlüsselung ab der nächsten Version von NSX for vSphere nicht mehr unterstützt. Sie sollten deshalb Triple DES nicht mehr als Verschlüsselungsalgorithmus verwenden und stattdessen zu einer im IPSec-Dienst verfügbaren sicheren Verschlüsselung 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 nach dem Upgrade 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.

Problemumgehung: Ersetzen Sie den Triple DES-Verschlüsselungsalgorithmus in der IPSec-Site-Konfiguration durch eine unterstützte AES-Variante (AES/AES256/AES-GCM). So sollte beispielsweise in jeder IPSec-Site-Konfiguration mit Triple DES als Verschlüsselungsalgorithmus dieser durch AES ersetzt werden. Aktualisieren Sie entsprechend die IPSec-Konfiguration am Peer-Endpoint.
Problem 1648578: NSX erzwingt das Hinzufügen von Cluster/Netzwerk/Speicher, wenn eine neue Host-basierte NetX-Dienstinstanz erstellt wird
Wenn Sie über den vSphere Web Client eine neue Dienstinstanz für Host-basierte NetX-Dienste, beispielsweise eine Firewall, IDS und IPS, erstellen, werden Sie gezwungen, Cluster/Netzwerk/Speicher hinzuzufügen, auch wenn diese nicht erforderlich sind.

Problemumgehung: Beim Erstellen einer neuen Dienstinstanz können Sie beliebige Informationen für Cluster/Netzwerk/Speicher angeben, um die Felder auszufüllen. Auf diese Weise ist es Ihnen möglich, die Dienstinstanz zu erstellen und wunschgemäß fortfahren.
Problem 2018077: Firewallveröffentlichung schlägt fehl, wenn für die Regel ein benutzerdefinierter L7-ALG-Dienst ohne Zielport und Protokoll verwendet wird
Wenn Sie einen L7-Dienst durch Auswählen einer der folgenden L7-ALG-APPs (APP_FTP, APP_TFTP, APP_DCERPC, APP_ORACLE) erstellen, ohne einen Zielport und ein Protokoll anzugeben, und diese dann in Firewallregeln verwenden, schlägt die Veröffentlichung der Firewallregeln fehl.

Problemumgehung: Geben Sie die entsprechenden Werte für Zielport und Protokoll (TCP/UDP) beim Erstellen eines benutzerdefinierten L7-Dienstes für die folgenden ALG-Dienste an:
- APP_FTP: Port 21-Protokoll: TCP
- APP_TFTP: Port 69-Protokoll: UDP
- APP_DCERPC: Port 135-Protokoll: TCP
- APP_ORACLE: Port 1521-Protokoll: TCP
Problem 1980551: NSX Manager unterstützt TLSv1 nicht standardmäßig
Wenn Sie versuchen, eine Verbindung mit NSX Manager unter Verwendung von TLSv1 herzustellen, schlägt dies fehl.

Problemumgehung: Verwenden Sie höhere TLS-Versionen: TLSv1.1 oder TLSv1.2.

Von einer Verwendung von TLSv1.0 wird abgeraten. Die Unterstützung für dieses Protokoll soll in einer künftigen Version entfernt werden. Zurzeit kann es in NSX Manager jedoch noch aktiviert werden. Anweisungen finden Sie unter „Arbeiten mit Sicherheitseinstellungen“ im API-Handbuch zu NSX for vSphere. Beachten Sie, dass NSX Manager durch Ändern der Sicherheitseinstellungen neu gestartet wird.
Problem 2006576: Der gespeicherte Zustand (Verbindungsinformationen, die für Datenverkehr mit erreichten Service Insertion-Filtern gespeichert werden) geht verloren, wenn die Gast-VM mit Service Insertion-Filter darauf von einem Cluster zu einem anderen verschoben wird (sofern bei beiden Clustern derselbe Dienst bereitgestellt wird).
Bei Gast-VMs mit konfigurierten NetX-Regeln (Service Insertion) gehen diese NetX-Regeln vorübergehend verloren, wenn der Ziel-Cluster für einen vMotion-Vorgang nicht mit dem Ursprungs-Cluster übereinstimmt.

Problemumgehung: Begrenzen Sie vMotion-Vorgänge der Gast-VM mit einem Service Insertion-Filter im Cluster.

Bekannte Probleme bei Überwachungsdiensten

Problem 1466790: Mit dem NSX-Tool Traceflow können keine VMs in überbrückten Netzwerken ausgewählt werden
Wenn Sie das NSX-Tool Traceflow verwenden, können Sie nur VMs auswählen, die mit einem logischen Switch verbunden sind. Das bedeutet, dass VMs in einem L2-überbrückten Netzwerk nicht mit dem VM-Namen als Quell- oder Zieladresse für die Traceflow-Untersuchung ausgewählt werden können.

Problemumgehung: Verwenden Sie für VMs, die an L2-überbrückte Netzwerke angeschlossen sind, die IP-Adresse oder MAC-Adresse der Schnittstelle, die Sie als Ziel in einer Traceflow-Untersuchung angeben möchten. Sie können an L2-überbrückte Netzwerke angeschlossene VMs nicht als Quelle verwenden. Weitere Informationen finden Sie im Knowledgebase-Artikel 2129191.