Versionshinweise zu VMware NSX Data Center for vSphere 6.4.8

VMware NSX Data Center for vSphere 6.4.8 | Veröffentlicht am 10. August 2020 | Build 16724220 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.8

VMware NSX for vSphere 6.4.8 behebt ein Problem, das speziell in VMware NSX for vSphere 6.4.7 erkannt wurde, und das sowohl neue NSX-Kunden als auch Kunden, die ein Upgrade von vorherigen NSX-Versionen durchführen, betreffen kann. Weitere Informationen dazu finden Sie unter Behobene Probleme.

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.

Upgrade-Hinweise

• Allgemeine Upgrade-Hinweise
• Upgrade-Hinweise für NSX-Komponenten
• Upgrade-Hinweise für FIPS

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

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

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

10. August 2020: Erste Auflage.
17. August 2020: Zweite Auflage. Behobenes Problem 2306230 wurde hinzugefügt.
21. September 2020: Dritte Auflage. Die bekannten Probleme 2631548 und 2633165 wurden hinzugefügt.
26. April 2021. Vierte Auflage. Behobenes Problem 2584256 wurde hinzugefügt.

Behobene Probleme

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

• 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 2584256: Auf NSX Edge wurde eine hohe Speichernutzung gemeldet, die zu einem automatischen Neustart des Edge führte.

  Edge reagiert nicht und kann nicht verwaltet werden. Kritische Warnungen, die auf der Benutzeroberfläche gemeldet werden: „NSX Edge weist nicht genügend Arbeitsspeicher auf. Für Edge wird in 3 Sekunden ein Neustart durchgeführt.“

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 2631548: netcpa-Prozess auf ESXi-Host kann nach dem Neustart eines mit NSX 6.4.8-VIBs vorbereiteten ESXi-Hosts keine Verbindung zu CCP auf Port 1234 herstellen.

  Die netcpa-Verbindung von ESXi Host zum NSX Controller-Cluster kann nach dem Neustart des ESX-Host im Status „SYN_SENT“ bleiben. Grund hierfür ist eine Wettlaufbedingung in der Initialisierungssequenz des netcpad-Prozesses und des hostd-Prozesses, wobei der netcpad-Prozess früher als der hostd-Prozess initialisiert.

  Problemumgehung: Starten Sie den netcpad-Prozess mithilfe des Befehls „/etc/init.d/netcpad restart“ neu.
  Weitere Informationen erhalten Sie im VMware-Knowledgebase-Artikel 80607.

• Problem 2633165: REST API-Aufrufe zum Erstellen/Ändern/Löschen von Subschnittstellen schlagen fehl.

  Die Subschnittstellenvorgänge „Erstellen/Ändern/Löschen“ mithilfe von „REST API /api/4.0/edges/{edge-Id}/vnics/{vNic_Index}/subinterfaces/“ schlagen fehl. Der Fehler entsteht nur bei REST API mit URI 

  /api/4.0/edges/{edge-Id}/vnics/{vNic_Index}/subinterfaces/ und /api/4.0/edges/{edge-Id}/vnics/{vNic_Index}/subinterfaces/{subInterface-index}.

  Kunden, die Automatisierungsskripte zum Erstellen/Ändern/Löschen von Subschnittstellen mithilfe von „REST API /api/4.0/edges/{edge-Id}/vnics/{vNic_Index}/subinterfaces/“ verwenden, erhalten einen Fehler beim Subschnittstellenvorgang.

  Problemumgehung: Subschnittstellenvorgänge, die über die Benutzeroberfläche oder die vNIC-REST API durchgeführt werden, sind erfolgreich.
  1) Nutzen Sie die Benutzeroberfläche zum Erstellen/Ändern/Löschen von Subschnittstellen.
  2) Nutzen Sie „PUT api/4.0/edges/{edge-Id}/vnics/{index}“ mit Nutzlast zum Erstellen/Aktualisieren/Löschen von Subschnittstellen.

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