Versionshinweise zu NSX for vSphere 6.1.5

NSX for vSphere 6.1.5 | 1. Oktober 2015 | Build 3102213 | Aktualisiertes Dokument vom 20. Mai 2016

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

Neuigkeiten

Erfahren Sie Neuigkeiten und Änderungen in 6.1.5, 6.1.4, 6.1.3, 6.1.2, 6.1.1 und 6.1.0.

Neu in 6.1.5

Änderungen in NSX for vSphere 6.1.5:

  • Controllerkonnektivitätsstatus: Die Benutzeroberfläche von NSX Manager wurde so erweitert, dass sie nun den Status der Konnektivität zwischen NSX-Controllern im Controller-Cluster anzeigt. Hierdurch werden Konnektivitätsunterschiede zwischen Knoten sichtbar. In einem Cluster mit drei Controllern, A, B und C, könnten Sie anhand des Konnektivitätsstatus beispielsweise eine partielle Clusterpartition identifizieren, bei der A mit B und mit C verbunden ist, B und C einander jedoch nicht sehen können.

Neu in 6.1.4

Änderungen in NSX for vSphere 6.1.4:

  • Sicherheits-Fixes: Diese Version vervollständigt eine Reihe von Fixes für die Schwachstellen Skip-TLS (CVE-2014-6593), FREAK (CVE-2015-0204) und POODLE (CVE-2014-3566) sowie Fixes für andere Probleme. Weitere Informationen finden Sie in diesem Dokument im Abschnitt Behobene Probleme. Überprüfen Sie, dass Komponenten von Drittanbietern (z. B. Lösungen von Drittanbieterpartnern) die aktualisierten JRE- und OpenSSL-Versionen unterstützen, die in NSX verwendet werden.
    Weitere Informationen finden Sie unter:

  • Kompatibilität mit vSphere 6.0: NSX 6.1.4 ist mit vSphere 6.0 kompatibel. Die neuen vSphere-Funktionen in vSphere 6.0 wurden jedoch nicht mit NSX getestet. Diese neuen vSphere-Funktionen sollten nicht in Umgebungen verwendet werden, in denen NSX installiert ist, da sie nicht unterstützt werden. Eine Aufstellung der Einschränkungen bei NSX im Hinblick auf vSphere 6.0 finden Sie im VMware-Knowledgebase-Artikel 2110197.

  • Möglichkeit, die Veröffentlichung der Konfiguration auf neuen NSX Controller-Bereitstellungen zu erzwingen: In NSX for vSphere 6.1.4 wird ein Befehl zum Erzwingen der Controller-Synchronisierung eingeführt, um Informationen zum logischen Switch an neu bereitgestellte NSX Controller zu übertragen. Der folgende API-Aufruf für NSX Manager überträgt wieder die ursprüngliche Konfiguration an jeden der neu bereitgestellten Controller.
    Methode:

    PUT https://<NSX-Manager-IP>/api/2.0/vdn/controller/synchronize?
  • OSPF für Teilschnittstellen: OSPF wird jetzt für Teilschnittstellen unterstützt (behobenes Problem 1436023).

  • Beendigung der MSRPC-Unterstützung in ALG-Regeln: NSX Edge unterstützt nicht mehr das MSRPC-Protokoll für Gateway-Regeln auf Anwendungsebene für die Edge-Firewall.

Neu in 6.1.3

Änderungen in NSX for vSphere 6.1.3:

  • Protokolle für das dynamische Routing werden für Teilschnittstellen unterstützt.
  • ECMP und Logical Firewall werden gleichzeitig für das logische Routing unterstützt.

Neu in 6.1.2

In NSX for vSphere 6.1.2 wurden NSX Edge und NSX Controller auf OpenSSL 101j aktualisiert und mehrere weitere CVEs behoben. Diese Version umfasste einen aktualisierten API-Aufruf, um die POODLE-Schwachstelle zu beheben. Mit diesem API-Aufruf können Sie SSLv3 auf bestimmten NSX Edges in Ihrer Umgebung deaktivieren. Weitere Informationen finden Sie unter Behobene Probleme.

Neu in 6.1.1

NSX for vSphere 6.1.1 stellte Patches für alle NSX-Appliances bereit, mit denen die „BASH Shellshock“-Schwachstelle behoben wurde.

Neu in 6.1.0

NSX for vSphere 6.1 enthielt mehrere neue Funktionen sowie Verbesserungen in Bezug auf Betrieb, Nutzung und Sicherheitshärtung:

  • Hoch verfügbare NSX Edge-Cluster mit höheren Uplink-Geschwindigkeiten: Mit NSX können Sie hoch verfügbare und verteilte NSX Edge-Cluster erstellen, Sie erhalten Uplink-Verbindungen mit hoher Bandbreite zu physischen Netzwerken, und die Aktiv/Aktiv-Redundanz am Netzwerkvirtualisierungs-Edge wird sichergestellt. ECMP auf NSX Edge ermöglicht aggregierte Nord-Süd-Bandbreite mit hohem Durchsatz und horizontale Skalierung von NSX Edge.
  • Verbesserte Mikro-Segmentierungs- und Firewall-Abläufe: NSX 6.1 verbessert die Mikro-Segmentierungsfähigkeiten durch verbesserte Bereitstellung, Fehlerbehebung und Überwachung bei NSX Distributed- und Edge-Firewalls. Es gibt eine neue einheitliche Benutzeroberfläche zum Konfigurieren von Distributed- und Edge-Firewalls. Dank der Integration von NSX und VMware vRealize Automation 6.1 (vRA 6.1, früher VMware vCloud Automation Center) können Administratoren ihre Workflows für die Sicherheitsautomatisierung und die Computing-Automatisierung integrieren. Außerdem ermöglicht NSX 6.1 die Umleitung des Datenverkehrs zu Partnerprodukten wie Firewalls der nächsten Generation und Diensten zur Abwehr von Eindringversuchen.
  • Verbinden Sie mehrere Rechenzentren oder bieten Sie Hybrid Cloud-Services im Software-Defined Data Center (SDDC): Mit Layer-2-VPN auf NSX Edge können IT-Teams Workloads migrieren, Rechenzentren konsolidieren oder erweiterte Anwendungsschichten über mehrere Rechenzentren hinweg erstellen. Dienstanbieter können Mandanten-Onboarding und Cloud-Bursting-Dienste anbieten, wobei Mandanten-Anwendungsnetzwerke über Rechenzentren hinweg erhalten bleiben, ohne dass NSX an den Kundenstandorten benötigt wird.
  • Einheitliches Management von IP-Adressen im gesamten Rechenzentrum: Mit einem DHCP-Relay können Sie vorhandene DHCP-Services, die in physischen Rechenzentren zur Verfügung stehen, in das SDDC integrieren, um einheitliche IP-Adressierungsrichtlinien und eine einfache IP-Verwaltung im gesamten Rechenzentrum sicherzustellen. NSX for vSphere 6.1 unterstützt mehrere DHCP-Server auf einem einzelnen logischen Router und ermöglicht die Integration mehrerer vorhandener DHCP-Server.
  • Verbesserung des NSX-Lastausgleichsdienstes: Um Lastausgleich und Hochverfügbarkeit für mehr in NSX gehostete Anwendungen zu ermöglichen, wurde in NSX 6.1.0 der UDP-Lastausgleich eingeführt. Damit kann NSX den Lastausgleich für Anwendungen wie syslog, NTP und DNS bereitstellen.
  • Verwendung von Anwendungsbereitstellungs-Controllern (ADCs) im Kontext eines Software-Defined Datacenter (SDDC): Mit NSX 6.1 können Kunden, die ADCs von NSX-Partnern verwenden, ihre Investition schützen und erweiterte ADC-Services von kompatiblen Anbietern nutzen.
  • Erweiterte Host- oder Netzwerk-Sicherheitsservices im SDDC: Die erweiterte Integration von Partnerlösungen und NSX Service Composer unterstützt mehrere Sicherheitsservices einschließlich Produktpaketlösungen, die host- und netzwerkbasierte Services in einer einzelnen Richtlinie umfassen.
  • Dynamischer und sicherer Self-Service im SDDC: NSX 6.1 mit vCloud Automation CenterĀ® hilft Ihnen bei der Optimierung der Ressourcennutzung und -skalierung durch dynamisches Verbinden von Self-Service-Anwendungen mit logischen NSX-Netzwerken, während gleichzeitig sichergestellt wird, dass die Infrastruktursicherheitsrichtlinien automatisch angewendet werden, um Anwendungen zu isolieren und zu schützen. Eine Liste der Funktionen finden Sie in den Versionshinweisen zu VMware vCloud Automation Center.

Systemanforderungen und Installation

Die VMware-Produkt-Interoperabilitätsmatrix enthält Details zur Kompatibilität aktueller und vorheriger Versionen von VMware-Produkten und -Komponenten, wie z. B. VMware vCenter Server.

Informationen finden Sie in den Hinweisen weiter oben in Bezug auf die Kompatibilität mit vSphere 6.0.

Upgrade-Hinweise

Hinweise zu künftigen Upgrades von NSX 6.1.x:

  • Upgrades von NSX 6.1.6 auf NSX 6.2.0, 6.2.1 und 6.2.2 werden nicht unterstützt.

  • Upgrades von NSX 6.1.5 auf NSX 6.2.0 oder auf 6.2.1 werden nicht unterstützt. VMware empfiehlt ein Upgrade von 6.1.5 auf 6.2.2 oder höher für die neuesten Sicherheitsaktualisierungen.

Die Versionen 5.5.x, 6.0.x und 6.1.x können direkt auf 6.1.5 aktualisiert werden. Um NSX for vSphere auf Version 6.1.5 zu aktualisieren, führen Sie die folgenden Schritte durch:

Bevor Sie mit dem Upgrade Ihrer Hosts beginnen, versetzen Sie die Hosts in den Wartungsmodus. Die Datenebene für VMs arbeitet nicht wie erwartet, wenn der Wartungsmodus für Hosts beendet wird und VMs eingeschaltet werden.

  1. Aktualisieren Sie NSX Manager und alle NSX-Komponenten auf 6.1.5. Anweisungen finden Sie im Installations- und Upgrade-Handbuch für NSX. Wenn Sie ein Upgrade von vCNS 5.5.x durchführen, lesen Sie Behobenes Problem 1429432.

    Hinweis: Die folgenden Schritte zeigen Ihnen, wie ein Upgrade für weitere VMware-Komponenten durchgeführt wird. Wenn Sie kein Upgrade auf vCenter Server 6.0 und ESXi 6.0 durchführen möchten, müssen Sie die folgenden Schritte nicht durchführen.

    Wenn Sie ein Upgrade für vCenter Server und ESXi durchführen möchten, müssen Sie die übrigen Schritte in diesem Verfahren durchführen.

  2. Führen Sie ein Upgrade von vCenter Server auf Version 6.0 durch. Informationen finden Sie in der Dokumentation zu VMware vSphere 6.0.

  3. Für ein Upgrade ohne Ausfallzeiten ermitteln Sie eine Teilgruppe der Hosts in Ihrer Umgebung, für die Sie ein Upgrade durchführen können.

  4. Versetzen Sie die Hosts in den Wartungsmodus.

  5. Führen Sie ein Upgrade von ESXi auf Version 6.0 durch. Informationen finden Sie in der Dokumentation zu VMware vSphere 6.0.
    Abhängig von den Hosteinstellungen und dem Upgrade-Verfahren werden die Hosts entweder automatisch neu gestartet oder Sie müssen sie manuell neu starten.
    Wenn die Hosts neu gestartet werden, überträgt NSX Manager die ESXi 6.0-VIBs auf die Hosts.

  6. Wenn für die Hosts Neustart erforderlich angezeigt wird (auf der Registerkarte „Hosts und Cluster“ auf der linken Seite des vSphere Web Client), starten Sie die Hosts wiederum neu.
    NSX-VIBs für ESXi 6.0 sind jetzt aktiviert.

  7. Deaktivieren Sie den Wartungsmodus für die Hosts, für die das Upgrade durchgeführt wurde.

    Hinweis: Beenden Sie den Wartungsmodus für die Hosts nicht vor diesem Schritt.

  8. Wiederholen Sie die Schritte 4 bis 7 für die nächste Teilgruppe an Hosts, bis alle Hosts in der Umgebung aktualisiert sind.

Bekannte Probleme

Bekannte Probleme gliedern sich wie folgt:

Upgrade- und Installationsprobleme

DVPort kann aufgrund eines Problems mit der Hostvorbereitung nicht mit Würde blockieren aktiviert werden
Auf einem NSX-fähigen ESXi-Host kann der DVPort aufgrund eines Problems mit der Hostvorbereitung nicht mit "Würde blockieren" aktiviert werden. Tritt dieser Fall ein, variiert die zuerst angezeigte Fehlermeldung (dies kann beispielsweise als ein VTEP-Erstellungsfehler in VC/hostd.log, ein DVPort-Verbindungsfehler in vmkernel.log oder ein SIOCSIFFLAGS-Fehler im Gast angezeigt werden). Dies geschieht, wenn VIBs geladen werden, nachdem die DVS-Eigenschaften durch vCenter übertragen wurden. Dies kann während des Upgrades geschehen.

Problemumgehung: In NSX 6.1.4 und früher ist zum Beheben dieser Art von DVPort-Fehlern in Sites mit einem logischen NSX-Router ein zusätzlicher Neustart erforderlich. In NSX 6.1.5 wird eine Problemminderung mit der NSX-Software zur Verfügung gestellt. Mit dieser Problemminderung ist in den meisten Fällen kein zweiter Neustart mehr erforderlich. Die Hauptursache ist ein bekanntes Problem in vSphere. Details dazu finden Sie im VMware-Knowledgebase-Artikel 2107951.

Kein Lastausgleich für virtuelle Server möglich
Wenn Sie beim Upgrade von NSX Edge von 6.1.1 auf 6.1.3 im Anwendungsprofil für einen virtuellen Server Poolside-SSL und CA-Zertifikate aktivieren, versucht NSX Edge automatisch, das Poolside-Zertifikat im Back-End zu überprüfen. Für den Datenverkehr ist nur dann ein Passthrough durch den Back-End-Pool möglich, wenn die konfigurierten CA-Zertifikate in NSX Edge das Serverzertifikat überprüfen können. Der Server für den Back-End-Pool muss stets über ein gültiges Zertifikat verfügen.

Problemumgehung: Wenn Sie NSX 6.1.3 verwenden, deaktivieren Sie in der Poolside-Zertifikatkonfiguration die Option „Dienstzertifikat konfigurieren“ für Poolzertifikate und CA-Zertifikate. Wenn Sie Version 6.1.1 verwenden, müssen Sie diesen Schritt nicht durchführen. In Version 6.1.1 besteht das Serverzertifikat die Überprüfung auch dann, wenn die konfigurierte CA das vom Back-End-Server gesendete Serverzertifikat nicht überprüfen kann.

Für Upgrades von vCNS 5.5.x sind weitere Schritte erforderlich
Wenn Sie ein Upgrade von VMware vCloud Networking and Security 5.5.x auf VMware NSX 6.1.x durchführen möchten, sollten Sie überprüfen, ob Informationen zum Namen des Uplink-Ports in der NSX-Datenbank fehlen.
Problemumgehung: Anweisungen hierzu finden Sie in diesem VMware-Knowledgebase-Artikel.

Ein Neustart von NSX Manager während eines Upgrades führt zu einem Problem bei der Synchronisierung des Bestands
Wenn NSX Manager während eines Upgrades neu gestartet wird, wird auf der NSX-Registerkarte „Hostvorbereitung“ die Option „Installieren“ statt der Option „Upgrade durchführen“ für vorbereitete Cluster angezeigt. NSX Manager sollte nicht zurückgesetzt werden, während ein Upgrade durchgeführt wird.

Problemumgehung: Klicken Sie auf die Option Installieren, um die NSX-VIBs auf die Hosts zu übertragen, oder führen Sie alternativ den folgenden API-Aufruf durch:
POST https://<vsm-ip>/api/2.0/si/deploy?startTime=<time>&ignoreDependency=<true/false>

Kurzzeitiger Verlust des Virenschutzes bei Antivirensoftware von Drittanbietern während des Upgrades
Das Upgrade von NSX 6.0.x auf NSX 6.1.x oder 6.2.0 kann kurzzeitig den Virenschutz durch Antivirensoftware von Drittanbietern außer Kraft setzen. Dieses Problem tritt beim Upgrade von NSX 6.1.x auf NSX 6.2 nicht auf.

Problemumgehung: Keine.

Bei der Migration von NSX-Appliances muss der automatische Start auf dem Zielhost aktiviert sein
Auf den Hosts, auf denen NSX Edge-Appliances und NSX-Controller zuerst bereitgestellt werden, aktiviert NSX das automatische Starten/Herunterfahren von virtuellen Maschinen. Wenn die NSX-Appliance- oder -Controller-VMs später zu anderen Hosts migriert werden, ist auf den neuen Hosts das automatische Starten/Herunterfahren von virtuellen Maschinen möglicherweise nicht aktiviert.

Problemumgehung: Wenn Sie NSX-Appliances oder -Controller zu einem neuen Cluster migrieren, sollten Sie alle Hosts im Cluster überprüfen, um sicherzustellen, dass das automatische Starten/Herunterfahren aktiviert ist.

Firewall-Regeln können nicht von einer NSX-Installation, die von vCNS aktualisiert wurde, in eine von Grund auf neue NSX-Installation importiert werden
Die Anwendungs-ID für jedes bekannte Protokoll oder jeden bekannten Service (beispielsweise ICMPv6) ist für alle Versionen neu installierter NSX-Umgebungen gleich. In einer Installation, die von vCNS auf NSX aktualisiert wurde, stimmt die Anwendungs-ID eines gegebenen Services jedoch möglicherweise nicht mit der Anwendungs-ID überein, die in einer NSX-Neuinstallation für diesen Service verwendet wird. Dies ist ein bekanntes Verhalten, da neue Anwendungs-IDs zu NSX, nicht jedoch zu vCNS hinzugefügt wurden. Daher stimmen die Anzahl der Anwendungs-IDs in vCNS und die Anzahl der Anwendungs-IDs in NSX nicht überein. Aufgrund dieses Konflikts können Sie Firewall-Regeln (DFW-Regeln) nicht aus einer aktualisierten NSX-Installation exportieren und in eine NSX-Neuinstallation importieren.

Problemumgehung: Keine.

SSO kann nach dem Upgrade nicht neu konfiguriert werden
Wenn es sich bei dem in NSX Manager konfigurierten SSO-Server um den nativen vCenter-Server handelt, können Sie nach dem Upgrade von vCenter Server auf Version 6.0 und dem Upgrade von NSX Manager auf Version 6.1.3 SSO-Einstellungen in NSX Manager nicht neu konfigurieren.

Problemumgehung: Keine.

Die Benutzeroberfläche für die Dienstbereitstellung zeigt die Fehlermeldung vAppConfig für VM nicht vorhanden an

Problemumgehung: Überprüfen Sie Folgendes, falls die obige Fehlermeldung angezeigt wird:

  1. Die Bereitstellung der Dienst-VM wurde abgeschlossen.
  2. Im vCenter Server-Aufgabenbereich werden keine Aufgaben wie etwa Klonen, Neukonfiguration usw. für diese virtuelle Maschine ausgeführt.

Löschen Sie die Dienst-VM, nachdem Sie die Schritte 1 und 2 ausgeführt haben. In der Benutzeroberfläche für die Dienstbereitstellung wird die Bereitstellung als Fehlgeschlagen angezeigt. Durch Klicken auf das rote Symbol wird ein Alarm angezeigt, dass die Agent-VM für den Host nicht verfügbar ist. Wenn Sie den Alarm beheben, wird die virtuelle Maschine erneut bereitgestellt und eingeschaltet.

vSphere Web Client zeigt nach der Sicherung und Wiederherstellung nicht die Registerkarte „Netzwerk und Sicherheit“ an
Wenn Sie nach dem Upgrade auf NSX for vSphere 6.1.3 einen Sicherungs- und Wiederherstellungsvorgang durchführen, zeigt der vSphere Web Client die Registerkarte „Netzwerk und Sicherheit“ nicht an.

Problemumgehung: Bei der Wiederherstellung einer NSX Manager-Sicherung werden Sie vom Virtual Appliance Management-Portal von NSX Manager abgemeldet. Warten Sie ein paar Minuten, bevor Sie sich beim vSphere Web Client anmelden.

Bereitstellungsspezifikation mit Versionsangabe muss bei Verwendung von vCenter Server 6.0 und ESX 6.0 auf Version 6.0.* aktualisiert werden
Problemumgehungen: Die Problemumgehung hängt davon ab, ob der Partner aktuell vCloud Networking and Security oder NSX for vSphere verwendet.

  • Partner, die NetX-Lösungen für vCloud Networking and Security registriert haben, müssen die Registrierung aktualisieren und mithilfe von REST-API-Aufrufen eine Bereitstellungsspezifikation mit Versionsangabe (VersionedDeploymentSpec) für Version 6.0.* mit dem entsprechenden OVF einbinden.
    1. Führen Sie ein Upgrade für vSphere von Version 5.5 auf Version 6.0 durch.
    2. Fügen Sie die Bereitstellungsspezifikation mit Versionsangabe für Version 6.0.x mithilfe des folgenden API-Aufrufs hinzu:
      
      POST https://<vCNS-IP>/api/2.0/si/service/<service-id>/service  \
      deploymentspec/versioneddeploymentspec
      <versionedDeploymentSpec> <hostVersion>6.0.x</hostVersion> <ovfUrl>http://sample.com/sample.ovf</ovfUrl> <vmciEnabled>true</vmciEnabled> </versionedDeploymentSpec>

      Die URL für die OVF-Datei wird vom Partner bereitgestellt.
    3. Aktualisieren Sie den Dienst mithilfe des folgenden REST-Aufrufs
      POST https://<vsm-ip>/api/2.0/si/service/config?action=update
    4. Beheben Sie den EAM-Alarm durch Ausführen der folgenden Schritte:
      1. Klicken Sie im vSphere Web Client auf „Home“ und anschließend auf „Verwaltung“.
      2. Wählen Sie in „Lösung“ die Option „vCenter Server-Erweiterungen“ aus.
      3. Klicken Sie auf „vSphere ESX Agent Manager“ und klicken Sie dann auf die Registerkarte „Verwalten“.
      4. Klicken Sie mit der rechten Maustaste auf den Agency-Status „Fehlgeschlagen“ und wählen Sie „Alle Probleme beheben“ aus.
  • Wenn Partner, die NetX-Lösungen für NSX registriert haben, ein Upgrade von vSphere auf Version 6.0 durchführen, müssen sie die Registrierung aktualisieren und eine Bereitstellungsspezifikation mit Versionsangabe (VersionedDeploymentSpec) für Version 6.0.* mit dem entsprechenden OVF einbinden. Befolgen Sie die unten beschriebenen Schritte:

    1. Fügen Sie die Bereitstellungsspezifikation mit Versionsangabe für Version 6.0.* mithilfe der folgenden Schritte hinzu:
      1. Klicken Sie im vSphere Web Client auf „Home“ und anschließend auf „Netzwerk und Sicherheit“.
      2. Klicken Sie auf „Service Definitions“ und dann auf „Dienstname“.
      3. Klicken Sie auf „Verwalten“ und dann auf „Bereitstellung“.
      4. Klicken Sie auf das Pluszeichen (+) und fügen Sie ESX-Versionen als 6.0.* und die OVF-URL mit der entsprechenden Dienst-VM-URL hinzu.
      5. Klicken Sie auf „OK“.
    2. Beheben Sie das Problem durch Ausführen der folgenden Schritte:
      1. Klicken Sie auf „Installation“.
      2. Klicken Sie auf „Dienstbereitstellungen“.
      3. Wählen Sie die Bereitstellung aus und klicken Sie auf „Auflösen“.

Nach dem Upgrade von NSX for vSphere von Version 6.0.7 auf Version 6.1.3 stürzt der vSphere Web Client im Anmeldebildschirm ab
Nach dem Upgrade von NSX Manager von 6.0.7 auf 6.1.3 werden im Anmeldebildschirm der vSphere Web Client-Benutzeroberfläche Ausnahmen angezeigt. Sie können sich weder bei vCenter noch bei NSX Manager anmelden und keine Vorgänge in vCenter oder NSX Manager ausführen.

Problemumgehung: Melden Sie sich bei VCVA als Root-Benutzer an und starten Sie den vSphere Web Client-Dienst neu.

Wird vCenter während des NSX for vSphere-Upgradevorgangs neu gestartet, wird ein falscher Clusterstatus angezeigt
Wenn Sie während eines Upgrades eine Hostvorbereitung in einer Umgebung mit mehreren für NSX vorbereiteten Clustern durchführen und der vCenter Server neu gestartet wird, nachdem mindestens ein Cluster vorbereitet wurde, wird für die übrigen Cluster möglicherweise statt eines Updatelinks der Clusterstatus „Nicht bereit“ angezeigt. Für die Hosts in vCenter wird möglicherweise zudem „Neustart erforderlich“ angezeigt.

Problemumgehung: Starten Sie vCenter während der Hostvorbereitung nicht neu.

Nach dem Upgrade von vCloud Networking and Security 5.5.3 auf NSX for vSphere 6.0.5 oder höher wird NSX Manager nicht gestartet, wenn Sie ein SSL-Zertifikat mit Schlüsselgröße DSA-1024 verwenden
SSL-Zertifikate mit der Schlüsselgröße DSA-1024 werden ab NSX for vSphere 6.0.5 nicht unterstützt, daher kann das Upgrade nicht erfolgreich durchgeführt werden.

Problemumgehung: Importieren Sie vor dem Starten des Upgrades ein neues SSL-Zertifikat mit der Schlüsselgröße 2048.

NSX Edge-Upgrade schlägt fehl, wenn L2 VPN auf Edge aktiviert ist
L2 VPN-Konfigurations-Upgrade von 5.x oder 6.0.x auf 6.1 wird nicht unterstützt. Deshalb schlägt das Upgrade von Edge fehl, wenn L2 VPN darauf konfiguriert ist.

Problemumgehung: Löschen Sie die L2 VPN-Konfiguration vor dem Aktualisieren von NSX Edge. Konfigurieren Sie L2 VPN nach dem Upgrade neu.

SSL VPN sendet keine Upgrade-Benachrichtigung an den Remote-Client
Das SSL VPN-Gateway sendet keine Upgrade-Benachrichtigung an den Benutzer. Der Administrator muss dem Remotebenutzer manuell mitteilen, dass das SSL VPN-Gateway (Server) aktualisiert wurde, und ihn bitten, den Client zu aktualisieren.

Nach dem Aktualisieren von NSX von Version 6.0 auf 6.0.x oder 6.1 sind keine NSX Edges auf der Benutzeroberfläche aufgeführt
Wenn Sie von NSX 6.0 auf NSX 6.0.x oder NSX 6.1 aktualisieren, wird das vSphere Web Client-Plug-In möglicherweise nicht ordnungsgemäß aktualisiert. Dies kann zu Anzeigeproblemen auf der Benutzeroberfläche führen, wie zum Beispiel fehlenden NSX Edges.
Dieses Problem tritt nicht beim Aktualisieren von NSX 6.0.1 oder höher auf.

Problemumgehung: Keine.

vSphere Distributed Switch MTU wird nicht aktualisiert
Wenn Sie beim Vorbereiten eines Clusters einen MTU-Wert festlegen, der kleiner als der MTU-Wert des vSphere Distributed Switch ist, wird der vSphere Distributed Switch nicht auf diesen Wert aktualisiert. Damit soll sichergestellt werden, dass der vorhandene Datenverkehr mit der höheren Frame-Größe nicht versehentlich unterbrochen wird.

Problemumgehung: Stellen Sie sicher, dass der MTU-Wert, den Sie beim Vorbereiten des Clusters festlegen, mindestens so groß wie der aktuelle MTU-Wert des vSphere Distributed Switch ist. Der erforderliche Mindest-MTU-Wert für VXLAN beträgt 1550.

Wenn in Ihrer Umgebung nicht alle Cluster vorbereitet sind, wird die Upgrade-Meldung für Distributed Firewall auf der Registerkarte „Hostvorbereitung“ der Installationsseite nicht angezeigt
Wenn Sie Cluster für die Netzwerkvirtualisierung vorbereiten, ist Distributed Firewall auf solchen Clustern aktiviert. Wenn in Ihrer Umgebung nicht alle Cluster vorbereitet sind, wird die Upgrade-Meldung für Distributed Firewall auf der Registerkarte „Hostvorbereitung“ nicht angezeigt.

Problemumgehung: Verwenden Sie den folgenden REST-Aufruf, um die Distributed Firewall zu aktualisieren:

PUT https://vsm-ip/api/4.0/firewall/globalroot-0/state/vsm-ip

Wenn eine Dienstgruppe nach dem Upgrade geändert wird und Dienste hinzugefügt oder entfernt werden, werden diese Änderungen nicht in der Firewall-Tabelle widergespiegelt.
Von Benutzern erstellte Dienstgruppen werden in der Edge-Firewall-Tabelle beim Upgrade erweitert, d. h., in der Spalte „Service“ in der Firewall-Tabelle werden alle Dienste innerhalb der Dienstgruppe angezeigt. Wenn die Dienstgruppe nach dem Upgrade zum Hinzufügen oder Entfernen von Diensten modifiziert wird, werden diese Änderungen nicht in der Firewall-Tabelle widergespiegelt.

Problemumgehung: Erstellen Sie eine neue Dienstgruppe mit einem anderen Namen und verwenden Sie dann diese Dienstgruppe in der Firewallregel.

Die Guest Introspection-Installation schlägt mit einem Fehler fehl
Beim Installieren von Guest Introspection auf einem Cluster schlägt die Installation mit dem folgenden Fehler fehl:
Ungültiges Format für VIB-Modul

Problemumgehung: Wechseln Sie im vCenter Web Client zu „vCenter-Home“ > „Hosts und Cluster“ und starten Sie die Hosts neu, für die in der Bestandsliste auf der linken Seite „Neustart erforderlich“ angezeigt wird.

Die Dienst-VM, die über die Registerkarte "Dienstbereitstellungen" auf der Installationsseite bereitgestellt wurde, wird nicht eingeschaltet

Problemumgehung: Befolgen Sie die unten beschriebenen Schritte.

  1. Entfernen Sie die Dienst-VM manuell vom ESX Agent-Ressourcenpool im Cluster.

  2. Klicken Sie auf Networking and Security und anschließend auf Installation.

  3. Klicken Sie auf die Registerkarte Dienstbereitstellungen.

  4. Wählen Sie den entsprechenden Dienst aus und klicken Sie auf das Symbol Auflösen.
    Die Dienst-VM wird neu bereitgestellt.

Wenn ein in 6.0.x erstelltes Dienstprofil sowohl an eine Sicherheitsgruppe als auch eine verteilte Portgruppe bzw. einen logischen Switch gebunden ist, sind die Service Composer-Firewallregeln nach dem Upgrade auf NSX 6.1.x nicht synchronisiert
Wenn eine Dienstprofilbindung in 6.0.x sowohl mit einer Sicherheitsgruppe als auch einer verteilten Portgruppe oder einem logischen Switch erfolgt, sind die Service Composer-Regeln nach dem Upgrade auf 6.1 nicht synchronisiert. Regeln können nicht über die Service Composer-Benutzeroberfläche veröffentlicht werden.

Problemumgehung: Befolgen Sie die unten beschriebenen Schritte.

  1. Heben Sie die Bindung des Dienstprofils mit der verteilten Portgruppe bzw. dem logischen Switch über die Benutzeroberfläche der Dienstdefinition auf.
  2. Erstellen Sie eine neue Sicherheitsgruppe und fügen Sie die erforderliche verteilte Portgruppe bzw. den erforderlichen logischen Switch zu dieser Sicherheitsgruppe hinzu.
  3. Binden Sie das Dienstprofil über die Benutzeroberfläche der Dienstdefinition an die neue Sicherheitsgruppe.
  4. Synchronisieren Sie die Firewall-Regeln über die Service Composer-Benutzeroberfläche.

Allgemeine Probleme

Distributed Logical Router schlagen mit der Fehlermeldung Würde blockieren fehl
Bei Distributed Logical Routern von NSX kann es vorkommen, dass diese nach Änderungen der Hostkonfiguration nicht mehr funktionieren. Dies tritt dann auf, wenn vSphere keinen erforderlichen VDR-Port auf dem Host erstellen kann. Dieser Fehler tritt als DVPort-Verbindungsfehler in vmkernel.log oder als SIOCSIFFLAGS-Fehler im Gastbetriebssystem auf. Dies kann der Fall sein, wenn VIBs geladen werden, nachdem die vDS-Eigenschaften (vSphere Distributed Switch) durch vCenter übertragen wurden.

Problemumgehung: Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2107951.

Die Längenbeschränkung für URLs in NSX beträgt 16.000 Zeichen, wenn Benutzer x VMs gleichzeitig in einem API-Aufruf ein einzelnes Sicherheit-Tag zuweisen möchten
Anwender können nicht x VMs gleichzeitig mit einem einzelnen API-Aufruf ein einzelnes Sicherheit-Tag zuweisen, wenn die Länge der URL 16.000 Zeichen übersteigt. Die Länge der URL darf höchstens 16.000 Zeichen betragen.

Problemumgehung:

  1. Die Länge der URL sollte weniger als 16.000 Zeichen betragen.

  2. Optimale Leistung wird erzielt, wenn ca. 500 VMs in einem einzelnen Aufruf mit Tags versehen werden. Wenn mehr VMs in einem einzelnen Aufruf mit Tags versehen werden, kann die Leistung sinken.

ESXi-Hosts lernen nicht die Liste der verfügbaren NSX-Controller
Um zu überprüfen, ob dieses Problem auftritt, überprüfen Sie, ob auf den Hosts die Datei config-by-vsm.xml vorhanden ist. Unter normalen Bedingungen ist eine Datei mit den IP-Adressen der Controller vorhanden. Dieses Problem kann durch einen temporären Ausfall des Nachrichtenbusses entstehen.

Problemumgehung: Suchen Sie nach Fehlermeldungen zu Kennwörtern und synchronisieren Sie den Nachrichtenbus erneut. Verwenden Sie die folgende REST-API, um den Nachrichtenbus erneut zu synchronisieren:

/api/2.0/nwfabric/configure?action=synchronize
[edit] http method
POST
[edit] Body
<nwFabricFeatureConfig>
  <featureId>com.vmware.vshield.vsm.messagingInfra</featureId>
  <resourceConfig>
   <resourceId<{HOST/CLUSTER MOID}</resourceId>
   </resourceConfig>
</nwFabricFeatureConfig>

Unterstützung für die vCNS-Funktion SSL VPN-Plus unter Windows 10
Das SSL VPN-Portal kann unter Windows 10 nicht im Browser Internet Explorer/Edge geöffnet werden; mit anderen Browsern funktioniert es jedoch.

Problemumgehung: SSL VPN-Clients mit PHAT funktionieren unter Windows 10.

Name der Sicherheitsrichtlinie darf nicht länger als 229 Zeichen sein
In das Feld für den Namen der Sicherheitsrichtlinie auf der Registerkarte „Sicherheitsrichtlinie“ von Service Composer können bis zu 229 Zeichen eingegeben werden. Grund hierfür ist, dass den Richtliniennamen intern ein Präfix vorangestellt wird.

Problemumgehung: Keine.

Einschalten der Gast-VM nicht möglich
Beim Einschalten einer Gast-VM wird möglicherweise die Fehlermeldung Zurzeit sind nicht alle erforderlichen virtuellen Agentmaschinen bereitgestellt angezeigt.

Problemumgehung: Befolgen Sie die unten beschriebenen Schritte.

  1. Klicken Sie im vSphere Web Client auf „Home“ und anschließend auf „Verwaltung“.

  2. Wählen Sie in „Lösung“ die Option „vCenter Server-Erweiterungen“ aus.

  3. Klicken Sie auf „vSphere ESX Agent Manager“ und klicken Sie dann auf die Registerkarte „Verwalten“.

  4. Klicken Sie auf Auflösen.

Die Längenbeschränkung für URLs in NSX beträgt 16.000 Zeichen, wenn Benutzer „x“ VMs gleichzeitig in einem API-Aufruf ein einzelnes Sicherheit-Tag zuweisen möchten
Sie können nicht x VMs gleichzeitig mit einem einzelnen API-Aufruf ein einzelnes Sicherheit-Tag zuweisen, wenn die Länge der URL 16.000 Zeichen übersteigt. Die Länge der URL kann höchstens 16.000 Zeichen betragen.

Problemumgehung:

  1. Die Länge der URL sollte weniger als 16.000 Zeichen betragen.
  2. Optimale Leistung wird erzielt, wenn ca. 500 VMs in einem einzelnen Aufruf mit Tags versehen werden. Wenn mehr VMs in einem einzelnen Aufruf mit Tags versehen werden, kann die Leistung sinken.

Wenn NSX in vCSA 6.0 installiert ist, kann ein betriebssystemlokaler Benutzer NSX nicht in vSphere Web Client sehen
Wenn Sie NSX in vCSA 6.0 installiert haben, kann ein über das Unternehmen authentifizierter vSphere-Benutzer die Registerkarte für NSX-Netzwerk und -Sicherheit in vSphere Web Client anzeigen, ein betriebssystemlokaler vSphere-Benutzer jedoch nicht.

Problemumgehung: Führen Sie die folgenden Schritte aus:

  1. Melden Sie sich an vSphere Web Client als „administrator@vsphere.local“-Benutzer an.
  2. Wechseln Sie zur Registerkarte „Verwaltung > Benutzer und Gruppen > Gruppen“ und wählen Sie unter der Domäne „vsphere.local“ die Administratorgruppe aus.
  3. Klicken Sie für das Raster der Gruppenmitglieder auf die Schaltfläche „Mitglied hinzufügen“ und fügen Sie dieser Gruppe den Root-Benutzer hinzu.
  4. Wechseln Sie zu NSX Manager und klicken Sie auf die Registerkarte für Netzwerk und Sicherheit > NSX Manager > Verwalten > Benutzer und klicken Sie auf die Schaltfläche „Benutzer hinzufügen“ (+).
  5. Weisen Sie die Root-Benutzerrolle zu und klicken Sie auf die Schaltfläche zum Fertigstellen.
  6. Melden Sie sich ab und melden Sie sich als Root-Benutzer wieder an.

Probleme bei NSX Manager

NSX Manager Flow Monitoring zeigt möglicherweise keine Flows für das Zeitintervall „Letzte 15 Minuten“ oder „Letzte Stunde“ an

In NSX-Installationen mit umfangreichem Datenverkehr zeigt die Flow Monitoring-Benutzeroberfläche von NSX Manager die Meldung „Keine Flow-Datensätze verfügbar“, wenn das ausgewählte Zeitintervall „Letzte 15 Minuten“ oder „Letzte Stunde“ lautet. Dies tritt auf, wenn Flow-Datensätze nicht ausreichend häufig aktualisiert werden, um sicherzustellen, dass die aktuellen Flow-Datensätze verfügbar sind.

Problemumgehung: Für Installationen mit hohem Datenverkehr schlägt VMware den Kunden vor, entweder IPFix zu verwenden oder sich an einem Remote-Server mit syslog anzumelden (beispielsweise mit VMware LogInsight), um Flows zu erfassen.

NSX Manager wird automatisch neu gestartet, wenn sich zu viele Service Composer-Ablaufentwürfe ansammeln
Wenn sich in Ihren Firewall-Regeln zahlreiche Objekte im Feld „Quelle“, „Ziel“ oder „Angewendet auf“ befinden und NSX viele Service Composer-Abläufe automatisch gespeichert hat, wird NSX Manager möglicherweise unerwartet neu gestartet. Dies kann auch passieren, wenn Sie Service Composer verwenden, um Richtlinien auf zahlreiche Dienstgruppen anzuwenden, und NSX viele Service Composer-Abläufe automatisch gespeichert hat.

Problemumgehung: Wenn Ihre Installation der obigen Beschreibung entspricht und unerwartete Neustarts von NSX Manager auftreten, wenden Sie sich an den VMware-Support, um Hilfe beim Löschen von Service Composer-Abläufen zu erhalten, die als Entwürfe gespeichert sind.

Nachdem die NSX Manager-Sicherung wiederhergestellt ist, zeigt der REST-Aufruf den Status des Fabric-Features „com.vmware.vshield.vsm.messagingInfra“ als „Rot“ an.
Wenn Sie die Sicherung eines NSX Manager wiederherstellen und den Status des Fabric-Features „com.vmware.vshield.vsm.messagingInfra“ mithilfe eines REST-API-Aufrufs überprüfen, wird es als „Rot“ anstatt „Grün“ angezeigt.

Problemumgehung: Verwenden Sie den folgenden REST-API-Aufruf, um die Kommunikation zwischen NSX Manager und einem einzelnen Host oder allen Hosts in einem Cluster zurückzusetzen.
POST https://<nsxmgr-ip>/api/2.0/nwfabric/configure?action=synchronize
<nwFabricFeatureConfig>
<featureId>com.vmware.vshield.vsm.messagingInfra</featureId>
<resourceConfig>
    <resourceId>HOST/CLUSTER MOID</resourceId>
</resourceConfig>
</nwFabricFeatureConfig>

Registerkarte „Networking & Security“ wird im vSphere Web Client nicht angezeigt
Nach dem Upgrade von vSphere auf Version 6.0 wird die Registerkarte „Networking & Security“ nicht angezeigt, wenn Sie sich mit dem Root-Benutzernamen beim vSphere Web Client anmelden.

Problemumgehung: Melden Sie sich als „administrator@vsphere.local“ oder als beliebiger anderer vCenter-Benutzer an, der vor dem Upgrade in vCenter Server vorhanden war und dessen Rolle in NSX Manager definiert war.

Entfernen und erneutes Hinzufügen eines Hosts zu einem Cluster, der durch Guest Introspection und Lösungen von Drittanbietern geschützt wird, ist nicht möglich
Wenn Sie einen Host aus einem durch Guest Introspection und Lösungen von Drittanbietern geschützten Cluster entfernen, indem Sie die Verbindung des Hosts zu vCenter Server trennen und ihn anschließend aus diesem entfernen, treten möglicherweise Probleme auf, wenn Sie versuchen, denselben Host erneut demselben Cluster hinzuzufügen.

Problemumgehung: Um einen Host aus einem geschützten Cluster zu entfernen, versetzen Sie den Host zunächst in den Wartungsmodus. Verschieben Sie den Host im nächsten Schritt in einen nicht geschützten Cluster oder außerhalb aller Cluster. Trennen Sie dann die Verbindung und entfernen Sie den Host.

vMotion von NSX Manager zeigt möglicherweise folgenden Fehler an: Die virtuelle Ethernet-Karte 'Netzwerkadapter 1' wird nicht unterstützt
Sie können diesen Fehler ignorieren. Das Netzwerk funktioniert nach vMotion ordnungsgemäß.

Probleme bei NSX Edge und logischem Routing

Bei der Änderung einer BGP-Nachbar-Filterregel werden die vorhandenen Filter möglicherweise bis zu 40 Sekunden lang nicht angewendet
Wenn BGP-Filter auf einen NSX Edge angewendet werden, auf dem IBGP ausgeführt wird, kann es möglicherweise bis zu 40 Sekunden dauern, bis die Filter im Rahmen der IBGP-Sitzung angewendet werden. Zu diesem Zeitpunkt kündigt NSX Edge möglicherweise Routen an, die im BGP-Filter für den IBGP-Peer verweigert werden.

Problemumgehung: Keine.

Nach der Aktivierung von ECMP auf einem logischen Router erhält der nach Norden ausgerichtete Edge keine Präfixe vom logischen Router

Problemumgehung: Befolgen Sie die unten beschriebenen Schritte:

  1. Deaktivieren Sie ECMP auf dem logischen Router.
  2. Deaktivieren Sie OSPF.
  3. Aktivieren Sie ECMP.
  4. Aktivieren Sie OSPF.

Wenn die Zertifikatauthentifizierung in der Authentifizierungskonfiguration des SSL VPN-Plus-Diensts aktiviert ist, schlägt die Verbindungsherstellung mit dem SSL VPN-Server über eine ältere Version des Windows-Clients fehl
Wenn die Zertifikatauthentifizierung aktiviert ist, schlägt der TLS-Handshake zwischen einer älteren Version des Windows-Clients und der neuesten Version von SSL VPN fehl. Dadurch wird der Windows-Client an der Verbindungsherstellung mit SSL VPN gehindert. Bei Linux- und Mac-Clients oder bei einer browserbasierten Verbindung mit SSL VPN tritt dieses Problem nicht auf.

Problemumgehung: Aktualisieren Sie den Windows-Client auf die neueste Version, d. h. 6.1.4.

Upgrade eines eigenständigen NSX Edge als L2 VPN-Client wird nicht unterstützt

Problemumgehung: Sie müssen ein neues eigenständiges Edge-OVF bereitstellen und die Einstellungen der Appliance neu konfigurieren.

Wird das direkte kumulierte Netzwerk im lokalen und Remote-Teilnetz eines IPsec VPN-Kanals entfernt, wird auch die kumulierte Route zu den indirekten Teilnetzen des Peer-Edges nicht mehr angezeigt
Wenn auf dem Edge kein Standard-Gateway vorhanden ist und Sie beim Konfigurieren von IPsec alle Direktverbindungsteilnetze in lokalen Teilnetzen und einige der Remote-Teilnetze gleichzeitig entfernen, sind die verbleibenden Peer-Teilnetze für IPsec VPN nicht mehr erreichbar.

Problemumgehung: Deaktivieren und reaktivieren Sie IPsec VPN auf NSX Edge.

SSL VPN Plus-Anmelde-/Abmelde-Skriptänderung funktioniert nicht
Das „modify“-Skript wird im vSphere Web Client korrekt dargestellt, im Gateway jedoch nicht.

Problemumgehung: Löschen Sie das ursprüngliche Skript und fügen Sie es erneut hinzu.

Das Hinzufügen einer dem Protokoll nach "verbundenen" Route führt dazu, dass in der FIB-Tabelle (Forwarding Information Base) sowohl verbundene als auch dynamisch gelernte Routen angezeigt werden
Wenn Sie eine Route hinzufügen, die dem Protokoll nach bereits "verbunden" ist, werden in der lokalen FIB sowohl verbundene als auch dynamisch gelernte Routen angezeigt. Die dynamisch gelernte Route wird gegenüber der direkt verbundenen Route als bevorzugte Route angezeigt.

Problemumgehung: Entfernen Sie die gelernte Route aus der Routen-Ankündigung, sodass sie aus der FIB-Tabelle gelöscht wird, und konfigurieren Sie nur die verbundene Route.

Wenn eine NSX Edge-VM mit einer Teilschnittstelle, die durch einen logischen Switch gesichert ist, über die Benutzeroberfläche von vCenter Web Client gelöscht wird, funktioniert der Datenpfad eventuell nicht für eine neue virtuelle Maschine, die mit demselben Port verbunden ist
Wenn die Edge-VM über die Benutzeroberfläche von vCenter Web Client (und nicht über NSX Manager) gelöscht wird, wird der auf dvPort über einem opaken Kanal konfigurierte VXLAN-Trunk nicht zurückgesetzt. Die Trunk-Konfiguration wird nämlich von NSX Manager verwaltet.
 
Problemumgehung: Löschen Sie die VXLAN-Trunk-Konfiguration wie folgt manuell:

  1. Wechseln Sie zum vCenter-MOB (Managed Object Browser), indem Sie Folgendes in einem Browserfenster eingeben:
    https://vc-ip/mob?vmodl=1
  2. Klicken Sie auf Inhalt.
  3. Rufen Sie den dvsUuid-Wert wie folgt ab:
    1. Klicken Sie auf den Root-Ordner-Link (zum Beispiel „group-d1(Datacenters)“).
    2. Klicken Sie auf den Datencenternamen-Link (zum Beispiel „datacenter-1“).
    3. Klicken Sie auf den networkFolder-Link (zum Beispiel group-n6).
    4. Klicken Sie auf den DVS-Namen-Link (zum Beispiel „dvs-1“).
    5. Kopieren Sie den Wert von uuid.
  4. Klicken Sie auf DVSManager und dann auf updateOpaqueDataEx.
  5. Fügen Sie in selectionSet folgendes XML-Segment hinzu
    <selectionSet xsi:type="DVPortSelection">
            <dvsUuid>value</dvsUuid>
        <portKey>value</portKey> <!--Portnummer der DVPG, wo Trunk vNIC angeschlossen wurde-->
    </selectionSet>
  6. Fügen Sie in opaqueDataSpec folgendes XML-Segment hinzu:
    <opaqueDataSpec>
            <operation>remove</operation>
            <opaqueData>
                <key>com.vmware.net.vxlan.trunkcfg</key>
                <opaqueData></opaqueData>
            </opaqueData>
    </opaqueDataSpec>
  7. Setzen Sie isRuntime auf "false".
  8. Klicken Sie auf Methode aufrufen.
  9. Wiederholen Sie die Schritte 5 bis 8 für jeden Trunk-Port, der auf der gelöschten Edge-VM konfiguriert wurde.

Wenn "Standardeinstellung erzeugen" aktiviert ist, wird der BGP-Filter zum Ablehnen der Standardroute nicht angewendet
Wenn "Standardeinstellung erzeugen" für BGP in NSX Edge aktiviert ist, wird die Standardroute ohne Einschränkung für alle BGP-Nachbarn angekündigt. Wenn ein BGP-Nachbar nicht die durch diesen BGP-Speaker angekündigte Standardroute installieren soll, müssen Sie eine Eingangsrichtlinie auf diesem BGP-Nachbarn zum Ablehnen der Standardroute konfigurieren.
 
Problemumgehung: Konfigurieren Sie eine Eingangsrichtlinie auf dem entsprechenden BGP-Nachbarn zum Ablehnen der Standardroute.

Im Bridge- oder Mandantennamen für den logischen Router können keine Nicht-ASCII-Zeichen hinzugefügt werden
NSX-Controller-APIs unterstützen Nicht-ASCII-Zeichen nicht.
 
Problemumgehung: Verwenden Sie ASCII-Zeichen in Bridge- und Mandantennamen. Sie können dann die Namen bearbeiten und Nicht-ASCII-Zeichen einfügen.

SNAT und Lastausgleichsdienst (mit L4 SNAT), die auf der Teilschnittstelle konfiguriert sind, funktionieren nicht
Die SNAT-Regelkonfiguration wird bei NSX Edge weitergeleitet, aber der Datenpfad für die Regel funktioniert wegen der RP-Filterprüfungen nicht.
 
Problemumgehung: Wenden Sie sich an den VMware-Support, wenn Sie Hilfe beim Schwächen der RP-Filterprüfung in NSX Edge benötigen.

Wenn Egress-Optimierung für L2 VPN aktiviert ist, werden Lastausgleichsdienste mit Poolmitgliedern, die sich über die Site erstrecken, als ausgeschaltet angezeigt
Bei Egress-Optimierung haben L2 VPN-Client und -Server dieselbe interne IP-Adresse. Deshalb kann kein Paket von einem Poolmitglied zum Lastausgleichsdienst NSX Edge erreichen.
 
Problemumgehung: Führen Sie einen der folgenden Schritte aus:

  • Deaktivieren Sie die Egress-Optimierung.
  • Weisen Sie dem Lastausgleichsdienst eine andere IP-Adresse zu als die Egress-optimierte IP-Adresse.

Statische Routen werden nicht per Push an Hosts übertragen, wenn keine Adresse für den nächsten Hop festgelegt ist
Die Benutzeroberfläche ermöglicht es Ihnen, eine statische Route auf einem NSX Edge-Gerät zu erstellen, ohne eine Adresse für den nächsten Hop anzugeben. Wenn Sie keine Adresse für den nächsten Hop angeben, wird die statische Route nicht an die Hosts übertragen.
 
Problemumgehung: Geben Sie für statische Routen immer eine Adresse für den nächsten Hop an.

NSX-Firewall kann nicht unter Verwendung von Sicherheitsgruppen oder anderen Gruppierungsobjekten, die unter dem globalen Geltungsbereich definiert sind, konfiguriert werden
Administratorbenutzer, die unter dem Geltungsbereich von NSX Edge definiert sind, können nicht auf Objekte zugreifen, die unter dem globalen Geltungsbereich definiert sind. Wenn beispielsweise Benutzer abc unter dem Geltungsbereich von NSX Edge und Sicherheitsgruppe sg-1 unter dem globalen Geltungsbereich definiert ist, kann abc die Sicherheitsgruppe sg-1 in der Firewall-Konfiguration auf dem NSX Edge nicht verwenden.

Problemumgehung: Der Administrator darf nur Gruppierungsobjekte verwenden, die unter dem Geltungsbereich von NSX Edge definiert sind, oder er muss eine Kopie der global definierten Objekte unter dem Geltungsbereich von NSX Edge erstellen.

LIF-Routen des logischen Routers werden durch das Upstream-Edge Services Gateway angekündigt, auch wenn OSPF auf dem logischen Router deaktiviert ist
Das Upstream-Edge Services Gateway kündigt aus den mit dem logischen Router verbundenen Schnittstellen übernommene, OSPF-externe LSAs weiterhin an, auch wenn OSPF auf dem logischen Router deaktiviert ist.

Problemumgehung: Deaktivieren Sie manuell die Neuverteilung der Routen in OSPF und veröffentlichen Sie vor dem Deaktivieren des OSPF-Protokolls. Auf diese Weise wird sichergestellt, dass die Routen ordnungsgemäß zurückgezogen werden.

Wenn Hochverfügbarkeit (HA) auf einem Edge Services Gateway aktiviert ist und das OSPF-Hallo- bzw. Ausfallintervall auf andere Werte als 30 bzw. 120 Sekunden eingestellt ist, kann ein Teil des Datenverkehrs während eines Failovers verloren gehen
Wenn das primäre NSX Edge fehlschlägt, während OSPF ausgeführt wird und HA aktiviert ist, überschreitet die bis zum Wechsel in den Standby-Modus benötigte Zeit die für einen unterbrechungsfreien Neustart festgelegte Höchstdauer und führt dazu, dass OSPF-Nachbarn gelernte Routen aus ihren FIB-Tabellen (Forwarding Information Base) entfernen. Dies führt zu einem Ausfall der Datenebene, bis OSPF erneut konvergiert.

Problemumgehung: Stellen Sie die Standardwerte für die Zeitüberschreitung beim Hallo- bzw. Ausfallintervall auf allen benachbarten Routern auf 30 Sekunden für das Hallo- und auf 120 Sekunden für das Ausfallintervall. Dies ermöglicht ein erfolgreiches Failover ohne Verlust von Datenverkehr.

Die Benutzeroberfläche erlaubt das Hinzufügen von mehreren IP-Adressen zur Schnittstelle eines logischen Routers, obwohl diese nicht unterstützt wird
Diese Version unterstützt für die Schnittstelle eines logischen Routers nicht mehrere IP-Adressen.

Problemumgehung: Keine.

SSL VPN unterstützt keine Zertifikatswiderrufslisten (Certificate Revocation List, CRL)
Sie können zwar eine CRL zu einem NSX Edge hinzufügen, aber diese CRL wird von SSL VPN nicht verarbeitet.

Problemumgehung: CRL wird nicht unterstützt, aber Sie können die Benutzerauthentifizierung mit Clientzertifikatauthentifizierung aktivieren.

Zum Hinzufügen eines externen Authentifizierungsservers zu SSL VPN-Plus muss eine IP-Adresse und kein Hostname verwendet werden
Sie können den FQDN oder den Hostnamen des externen Authentifizierungsservers nicht verwenden.

Problemumgehung: Sie müssen die IP-Adresse des externen Authentifizierungsservers verwenden.

Firewall-Probleme

Von Service Composer erstellte Firewall-Regeln werden automatisch deaktiviert, wenn die Löschung von Diensten, auf die sie verweisen, erzwungen wird
Wenn Sie die Löschung von Diensten erzwingen, auf die Service Composer-Regeln verweisen, bemerken Sie, dass die Regeln, die auf gelöschte Dienste verweisen, ohne Warnung oder Benachrichtigung des Benutzers automatisch deaktiviert werden. Dies passiert, damit Service Composer nicht unsynchronisiert wird.

Problemumgehung: Sie müssen die Firewall-Regel in der Sicherheitsrichtlinie mit dem ungültigen Dienst korrigieren. Erzwingen Sie nicht die Löschung von Diensten und Sicherheitsgruppen, die in Firewall-Regeln für Service Composer verwendet werden.

Wenn einem logischen Switch eine neue VM hinzugefügt wird, werden nicht automatisch Firewall-Regeln für NSX Edge veröffentlicht
Wenn Sie einem logischen Switch neue VMs hinzufügen, bemerken Sie möglicherweise, dass die Firewall-Regeln für NSX Edge nicht automatisch veröffentlicht werden. Möglicherweise müssen Sie die Firewall-Regeln manuell erneut veröffentlichen, damit auf die neuen VMs die richtige Regel angewendet wird.

Problemumgehung: Platzieren Sie jeden logischen Switch in einer Sicherheitsgruppe. Wenn die Firewall-Regeln mithilfe der „securityGroup“ definiert sind, der der logische Switch angehört, und die neue VM zu diesem logischen Switch hinzugefügt wird, werden die zugeordneten Firewall-Regeln automatisch so aktualisiert, dass sie „ipAddress“ für die neue VM enthalten. Sie müssen die Firewall-Regeln nicht erneut bereitstellen.

Nach der Verwendung von DELETE API schlägt das erneute Veröffentlichen einer Firewallregel fehl
Wenn Sie die gesamte Firewall-Konfiguration mithilfe der Methode DELETE API löschen und dann versuchen, alle Regeln erneut anhand eines zuvor gespeicherten Entwurfs der Firewall-Regeln zu veröffentlichen, schlägt die Regelveröffentlichung fehl.

Problemumgehung: Keine.

Einige Versionen der Palo Alto Networks VM-Serie funktionieren nicht mit Standardeinstellungen von NSX Manager
Einige Komponenten von NSX 6.1.4 deaktivieren SSLv3 standardmäßig. Stellen Sie vor dem Upgrade sicher, dass keine der in Ihre NSX-Bereitstellung eingebundenen Drittanbieterlösungen von der SSLv3-Kommunikation abhängt. Zum Beispiel erfordern einige Versionen der Lösung der Palo Alto Networks VM-Serie Unterstützung für SSLv3. Bitten Sie deshalb Ihre Anbieter um die entsprechenden Versionsanforderungen.

In der Benutzeroberfläche wird trotz erfolgreicher Veröffentlichung die sinngemäße Fehlermeldung Firewall-Veröffentlichung fehlgeschlagen angezeigt
Angenommen, Distributed Firewall ist für einen Teil der Cluster in Ihrer Umgebung aktiviert, und Sie aktualisieren eine Anwendungsgruppe, die in einer oder mehreren aktiven Firewall-Regeln verwendet wird. In diesem Fall wird für jeden Veröffentlichungsvorgang in der Benutzeroberfläche eine Fehlermeldung mit IDs der Hosts angezeigt, die zu den Clustern gehören, für die die NSX-Firewall nicht aktiviert ist.
Trotz der Fehlermeldungen werden die Regeln erfolgreich veröffentlicht und auf den Hosts erzwungen, auf denen Distributed Firewall aktiviert ist.
 
Problemumgehung: Wenden Sie sich an den VMware-Support, um die Benutzeroberflächenmeldungen zu entfernen.

Wenn Sie die Firewall-Konfiguration mit einem REST-API-Aufruf löschen, können Sie gespeicherte Konfigurationen nicht laden oder veröffentlichen
Wenn Sie die Firewall-Konfiguration löschen, wird ein neuer Standardabschnitt mit einer neuen Abschnitts-ID erstellt. Wenn Sie einen gespeicherten Entwurf laden (der denselben Abschnittsnamen aber eine ältere Abschnitts-ID besitzt), kommt es zu einem Konflikt bei den Abschnittsnamen und es wird der folgende Fehler angezeigt:
Doppelter Schlüsselwert verletzt eindeutige Beschränkung firewall_section_name_key
 
Problemumgehung: Führen Sie einen der folgenden Schritte aus:

  • Benennen Sie den aktuellen Standard-Firewall-Abschnitt nach dem Laden einer gespeicherten Konfiguration um.
  • Benennen Sie den Standardabschnitt in einer geladenen gespeicherten Konfiguration vor dem Veröffentlichen um.

Wenn IPFix-Konfiguration für Distributed Firewall aktiviert ist, werden Firewallports in der ESXi-Verwaltungsschnittstelle für NetFlow für vDS oder SNMP möglicherweise entfernt
Wenn ein Collector-IP und ein Port für IPFix definiert sind, wird die Firewall für die ESXi-Verwaltungsschnittstelle in der Ausgangsrichtung für die festgelegten UDP-Collector-Ports geöffnet. Mit dieser Operation wird die dynamische Regelsatzkonfiguration auf der ESXi-Verwaltungsschnittstellen-Firewall eventuell für die folgenden Dienste entfernt, wenn sie zuvor auf dem ESXi-Host konfiguriert waren:

  • Konfiguration des Netflow-Collector-Ports auf vDS
  • Konfiguration des SNMP-Zielports

Problemumgehung: Um die dynamischen Regelsatzregeln wieder hinzuzufügen, müssen Sie die NetFlow-Einstellungen für vDS im vCenter Web Client aktualisieren. Sie müssen außerdem das SNMP-Ziel mithilfe von „esxcli system snmp“-Befehlen wieder hinzufügen. Diese Schritte müssen wiederholt werden, wenn der ESXi-Host neu gestartet wird, nachdem die IPFix-Konfiguration aktiviert wurde, oder wenn das ESX-vsip-VIB auf dem Host deinstalliert wird.

Probleme beim logischen Switch

Das Erstellen einer großen Zahl logischer Switches mit hoher Gleichzeitigkeit unter Verwendung eines API-Aufrufs kann zu Fehlern führen
Dieses Problem kann auftreten, wenn Sie eine große Zahl von logischen Switches unter Verwendung des folgenden API-Aufrufs erstellen:

POST https://<nsxmgr-ip>/api/2.0/vdn/scopes/scopeID/virtualwires

Einige logische Switches werden möglicherweise nicht erstellt.
 
Problemumgehung: Führen Sie den API-Aufruf erneut aus.

Dienstbereitstellungsprobleme

Der Data Security-Dienst wird als betriebsbereit eingestuft, obwohl die IP-Verbindung nicht hergestellt wurde
Die Data Security-Appliance hat möglicherweise nicht die IP-Adresse von DHCP erhalten oder ist mit einer falschen Portgruppe verbunden.
 
Problemumgehung: Stellen Sie sicher, dass die Data Security-Appliance die IP-Adresse vom DHCP/IP-Pool bezieht und über das Verwaltungsnetzwerk erreicht werden kann. Überprüfen Sie, ob Ping für die Data Security-Appliance von NSX/ESX aus erfolgreich ausgeführt wird.

Alte Dienst-VMs funktionieren nicht
Die Verbindung zu alten Dienst-VMs, die bei der Hostentfernung vom vCenter Server auf den Hosts zurückgelassen wurden, bleibt getrennt und diese Dienst-VMs funktionieren nicht, wenn der Host wieder demselben vCenter Server hinzugefügt wird.
 
Problemumgehung: Befolgen Sie die unten beschriebenen Schritte:

  1. Verschieben Sie den Host vom geschützten Cluster zu einem nicht geschützten Cluster oder in einen Bereich außerhalb aller Cluster. Damit werden die Dienst-VMs auf dem Host deinstalliert.
  2. Entfernen Sie den Host aus dem vCenter Server.

Service Insertion-Probleme

Beim Löschen von Sicherheitsregeln über REST wird ein Fehler angezeigt
Wenn ein REST-API-Aufruf verwendet wird, um Sicherheitsregeln zu löschen, die durch Service Composer erstellt wurden, wird der entsprechende Regelsatz nicht im Cache des Dienstprofils gelöscht. Dies führt zu dem Fehler ObjectNotFoundException.
 
Problemumgehung: Keine.

Die Synchronisierung der Firewall geht verloren, da Sicherheitsrichtlinien als Portbereich konfiguriert sind
Durch die Konfiguration von Sicherheitsrichtlinien als Portbereich (z. B. „5900-5964“) geht die Synchronisierung der Firewall verloren und die Fehlermeldung NumberFormatException wird angezeigt.
 
Problemumgehung: Sie müssen die Richtlinien für die Firewallsicherheit als eine durch Kommata getrennte Protokollportliste konfigurieren.

Behobene Probleme

Erfahren Sie behobene Probleme in 6.1.5, 6.1.4, 6.1.3, 6.1.2, 6.1.1 und 6.1.0.

Die folgenden Probleme wurden in Version 6.1.5 behoben:

  • Das Kopieren einer VM über vCloud Connector schlägt fehl, wenn die Route den NSX-Lastausgleichsdienst durchquert

    Dieses Problem wurde in NSX 6.1.5 behoben.

  • Der ESXi-Host verliert möglicherweise die Netzwerkkonnektivität
    Ein ESXi-Host kann die Netzwerkkonnektivität verlieren und Stabilitätsprobleme aufweisen, wenn mehrere Fehlermeldungen ähnlich der folgenden protokolliert sind:
    WARNING: Heartbeat: 785: PCPU 63 didn't have a heartbeat for 7 seconds; *may* be locked up.

    Dieses Problem wurde in NSX 6.1.5 behoben.

  • Keine Steuerungsebenenkonnektivität für NSX-Controller
    Für einen Controller wurde ein Fehler bei der Steuerungsebenenkonnektivität festgestellt. Dies wird in netcpa als Fehler im Zusammenhang mit txInProgress angezeigt.

    Dieses Problem wurde in NSX 6.1.5 behoben.

  • Auf dem NSX Manager Web Client wird folgender Fehler angezeigt: Code 301002
    Beschreibung: Wenn Sie zu „NSX Manager > Überwachen > Systemereignisse“ wechseln, wird in Web Client die folgende Meldung angezeigt: Filterkonfiguration wird nicht auf vnic angewendet. Code 301002.

    Dieses Problem wurde in NSX 6.1.5 behoben.

  • Nach dem NSX-Upgrade kann Guest Introspection nicht mit NSX Manager kommunizieren
    Nach dem Upgrade von NSX 6.0.x auf NSX 6.1.x oder von NSX 6.0.x auf NSX 6.2 und vor dem Upgrade des Guest Introspection-Dienstes kann NSX Manager nicht mit der Guest Introspection-USVM kommunizieren.

    Dieses Problem wurde in NSX 6.1.5 behoben.

  • Die Verbindung von VMs wird während eines vMotion-Vorgangs unterbrochen
    In NSX 6.0.8 wird die Verbindung von VMs während eines vMotion-Vorgangs mit einer Meldung getrennt, die sinngemäß Folgendes besagt: VISP-Heap aufgebraucht.

    Dieses Problem wurde in NSX 6.1.5 behoben.

  • LDAP-Domänenobjekte benötigen sehr viel Zeit, bis sie im Auswahlbildschirm für Sicherheitsgruppenobjekte angezeigt werden, oder werden dort gar nicht angezeigt

    Dieses Problem wurde in NSX 6.1.5 behoben.

  • Verzögerte Mausbewegung beim Anzeigen von Firewallregeln
    Im Abschnitt für NSX-Netzwerk und -Sicherheit von vSphere Web Client werden Ergebnisse bei jeder Mausbewegung mit einer Verzögerung von 3 Sekunden angezeigt, wenn die Maus über Zeilen in den Firewallregeln bewegt wird.

    Dieses Problem wurde in NSX 6.1.5 behoben.

  • Einige IP-Spoofguard-Regeln in NSX-v werden nicht korrekt angewendet
    Einige IP-Spoofguard-Regeln in NSX-v werden nicht korrekt angewendet. Die Instanz ist in der Sicherheitsgruppe in NSX-v nicht vorhanden und muss manuell zur Sicherheitsgruppe hinzugefügt werden.

    Dieses Problem wurde in NSX 6.1.5 behoben.

  • In der VIO-Bereitstellung können einige VMs nicht auf das Netzwerk zugreifen, obwohl ihnen anscheinend gültige Ports und IP-Adressen zugewiesen wurden

    Dieses Problem wurde in NSX 6.1.5 behoben.

  • Einer der NSX Controller übergibt die Masterrolle beim Herunterfahren nicht an andere Controller
    Ein NSX-Controller, der die Masterrolle für die Vorgänge übernommen hat und kurz vor dem Herunterfahren steht, übergibt in der Regel automatisch die Masterrolle an andere Controller. In diesem Fehlerfall übergibt der Controller die Rolle nicht an andere Controller, der Status ändert sich auf „unterbrochen“, und der Modus „unterbrochen“ wird aktiv.

    Dieses Problem wurde in NSX 6.1.5 behoben.

  • Die Registrierung von NSX Manager 6.1.4 bei vCenter schlägt mit einer Meldung fehl, die besagt, dass der NSX Management Service-Vorgang fehlgeschlagen ist

    Dieses Problem wurde in NSX 6.1.5 behoben.

  • Eine erneute Bereitstellung von NSX Edge ist nicht möglich, wenn der L2VPN-Dienst mit einem von der Zertifizierungsstelle signierten Zertifikat konfiguriert ist
    Eine erneute Bereitstellung oder Änderung der Größe von NSX Edge ist nicht möglich, wenn der L2VPN-Dienst mit einem von der Zertifizierungsstelle signierten oder einem selbst signierten Zertifikat konfiguriert ist.

    Dieses Problem wurde in NSX 6.1.5 behoben.

  • Beim Massenlöschen über die Service Composer-Benutzeroberfläche wird sinngemäß die Meldung für „zwischen 0 und 0“ generiert
    Beim Massenlöschen von Richtlinien (~100) über die NSX Service Composer-Benutzeroberfläche wird sinngemäß die Meldung „Der Wert muss zwischen 0 und 0 liegen“ generiert. Sie können diese Meldung ignorieren.

    Dieses Problem wurde in NSX 6.1.5 behoben.

  • Langsame Anmeldung auf der NSX-Registerkarte von vSphere Web Client mit AD-gestütztem Single Sign-On
    In NSX for vSphere-Installationen, die das Single Sign-On für die AD-Authentifizierung verwenden, dauert die erstmalige Anmeldung des Benutzers im Abschnitt für NSX-Netzwerk und -Sicherheit von vSphere Web Client sehr lange.

    Dieses Problem wurde in NSX 6.1.5 behoben.

  • Ein Hintergrundvorgang bei der Richtlinienlöschung kann sehr lange dauern und zu einer hohen CPU-Auslastung führen
    Beim Löschen einer Richtlinie werden alle verbleibenden Richtlinien im Hintergrund neu bewertet. Dies kann über eine Stunde dauern, wenn die Installation viele Richtlinien, viele Sicherheitsgruppen und/oder viele Regeln pro Richtlinie umfasst.

    Dieses Problem wurde in NSX 6.1.5 und 6.2 behoben.

  • Nach dem Hinzufügen zu einer Active Directory-Domäne ist die Auslastung der NSX Manager-CPU hoch
    Nach dem Hinzufügen zu einer Active Directory-Domäne ist die Auslastung der NSX Manager-CPU hoch. In den Systemprotokollen von NSX Manager ist zu erkennen, dass mehrere Postgres-Threads ausgeführt werden.

    Dieses Problem wurde in NSX 6.1.5 behoben.

  • Konnektivitätsverlust nach dem Entfernen einer logischen Schnittstelle (LIF) in Installationen mit dynamischem Routing
    Im logischen NSX-Router (Edge/DLR) wurde bei Verwendung von dynamischem Routing (OSPF & BGP) ein Problem erkannt, das zu einem Verlust der Netzwerkkonnektivität nach dem Entfernen einer logischen Schnittstelle (LIF) führt. Dies betrifft die NSX-Versionen 6.0.x bis 6.1.4.

    In NSX-Installationen, die dynamisches Routing verwenden, ist jeder logischen Schnittstelle (LIF) eine Index-ID der Neuverteilungsregel zugeordnet. Wenn ein Benutzer eine logische Schnittstelle (LIF) in solchen Installationen löscht, ändern sich möglicherweise die Index-IDs, die einigen aktiven logischen Schnittstellen (LIFs) zugewiesen sind. Diese Indexänderung kann zu einem temporären Verlust der Netzwerkkonnektivität für logische Schnittstellen (LIFs) führen, deren Index-IDs geändert werden. Wenn die logische Schnittstelle (LIF) serialisiert ist, dauert die Unterbrechung bei betroffenen logischen Schnittstellen (LIFs) nach jeder Löschung einer logischen Schnittstelle (LIF) 5-30 Sekunden. Wenn die Löschung zahlreicher logischer Schnittstellen gleichzeitig erfolgt, dauert die Unterbrechung bei betroffenen logischen Schnittstellen insgesamt 5-30 Sekunden.

    Dieses Problem wurde in NSX 6.1.5 behoben.

  • Alle veröffentlichungsfähigen Aufgaben, die in die Warteschlange eingereiht sind, werden nach einem standardmäßigen Timeout von 20 Minuten als fehlgeschlagen markiert
    Warteschlangen werden pro NSX Edge verwaltet und können für verschiedene Edges gleichzeitig veröffentlichen. Die in die Warteschlange eingereihten veröffentlichungsfähigen Aufgaben werden nacheinander ausgeführt, wobei jede Aufgabe ungefähr 3 bis 4 Sekunden benötigt und 300 bis 400 Aufgaben in 20 Minuten ausgeführt werden. Falls mehr als 400 Veröffentlichungsaufgaben für einen Edge in kurzer Zeit in die Warteschlange eingereiht werden und sie das Veröffentlichungszeitlimit von 20 Minuten überschreiten, während sie auf die Ausführung warten, werden die Aufgaben automatisch als fehlgeschlagen markiert. NSX Manager reagiert auf den Fehler, indem er zur letzten funktionierenden Konfiguration zurückkehrt, in der die Veröffentlichung beim Edge erfolgreich war. Anwendungen oder Plug-ins, die Konfigurationsaktualisierungen für einen Edge im Burst-Modus an NSX Manager senden, müssen den Erfolgs- oder Fehlerstatus der Aufgabe anhand der zugeordneten Job-ID überwachen.

    Dieses Problem wurde in NSX 6.1.5 behoben.

  • Nach einem Neustart von NSX Edge kann der Start des Nachrichtenbusses fehlschlagen
    Nach dem Neustart einer Edge-VM kann der Nachrichtenbus nach dem Einschalten häufig nicht gestartet werden und ein weiterer Neustart ist erforderlich.

    Dieses Problem wurde in NSX 6.1.5 und NSX 6.2.0 behoben.

  • NSX Manager funktioniert nach dem Ausführen des Befehls „write erase“ nicht mehr
    Wenn Sie NSX Manager nach dem Ausführen des Befehls „write erase“ neu starten, bemerken Sie möglicherweise, dass NSX Manager nicht funktioniert wie erwartet. Beispielsweise fehlt möglicherweise der Setup-Befehl in der CLI von NSX.

    Dieses Problem wurde in NSX 6.1.5 und NSX 6.2.0 behoben.

  • Syslog zeigt den Hostnamen der gesicherten NSX Manager-Instanz im wiederhergestellten NSX Manager an
    Angenommen, der Hostname des NSX Manager lautet „A“ und eine Sicherungskopie wird für diesen NSX Manager erstellt. Nun wird ein zweiter NSX Manager installiert und gemäß den Sicherungs- und Wiederherstellungsdokumenten mit derselben IP-Adresse wie die alte Manager-Instanz konfiguriert, aber der Hostname lautet „B“. Die Wiederherstellung wird für diesen NSX Manager ausgeführt. Für den wiederhergestellten NSX Manager wird der Hostname „A“ unmittelbar nach der Wiederherstellung und wiederum der Hostname „B“ nach dem Neustart angezeigt.

    Dieses Problem wurde in NSX 6.1.5 und NSX 6.2.0 behoben.

Die folgenden Probleme wurden in Version 6.1.4 behoben:

  • In VXLAN-Konfigurationen mit NIC-Teaming auf Hosts, auf denen der DVS-Switch über vier physische NIC-Uplinks (PNIC-Uplinks) verfügt, erhält nur eine der vier VMKNICs die IP-Adresse
    Wenn Sie in NSX 6.1.3 das VXLAN mit einer Teaming-Quellport-ID konfigurieren, wobei der DVS über vier physische NIC-Uplinks (PNIC-Uplinks) verfügt, erstellt NSX vier VMKNICs auf dem Host. Im Teaming-Modus sollte allen vier VMKNICs die IP-Adresse zugewiesen werden; aufgrund eines Problems in NSX 6.1.3 wird jedoch nur einer VMKNIC auf jedem Host die IP-Adresse zugewiesen.

    Dieses Problem wurde in NSX 6.1.4 behoben.

  • NSX Manager reagiert nicht mehr
    Der NSX Manager reagiert nicht mehr, wenn er den Netzwerkadapter nicht erkennt. Dieser Fix ersetzt den e1000-Netzwerkadapter der vCNS Manager-Appliance durch einen vmxnet3-Adapter. In Neuinstallationen von vCNS 5.5.4.1 und höher wird dieser Fix automatisch angewendet. Wenn Sie ein Upgrade von vCNS 5.5.x auf NSX 6.1.4 oder höher durchführen, müssen Sie den Fix manuell anwenden, wie im VMware-Knowledgebase-Artikel 2115459 erläutert.

    Dieses Problem wurde in NSX 6.1.4 behoben.

  • Behobenes Problem 1443458: In Installationen mit mehreren vSphere-Clustern werden Hosts möglicherweise nicht auf der Installations-Registerkarte angezeigt.
    In Installationen mit mehreren vSphere-Clustern kann es auf dem Bildschirm für die Hostvorbereitung in NSX Manager ca. 3 Minuten dauern, alle Cluster zu laden. Die Hosts werden möglicherweise vorübergehend nicht in dem Fenster angezeigt.

    Dieses Problem wurde in NSX 6.1.4 behoben.

  • Behobenes Problem 1424992: Auf der Registerkarte für NSX-Netzwerk und -Sicherheit von vSphere Web Client wird möglicherweise ein Zeitüberschreitungsfehler des Datenservices angezeigt, wenn ein großer AD-Speicher verwendet wird
    In NSX-Installationen mit vSphere 6.0 wird auf der Registerkarte für NSX-Netzwerk und -Sicherheit von vSphere Web Client möglicherweise ein Zeitüberschreitungsfehler des Datenservices angezeigt, wenn ein großer AD-Speicher verwendet wird. Für dieses Problem gibt es keine Umgehung. Laden Sie den Web Client in Ihrem Browser neu.

    Dieses Problem wurde in NSX 6.1.4 behoben.

  • Virtuelle Maschinen, die mit einem logischen VMware NSX for vSphere-Switch und einem Distributed Router verbunden sind, weisen eine sehr geringe Bandbreite bzw. einen sehr niedrigen Durchsatz auf.
    Dieser Fix behebt das in VMware-Knowledgebase-Artikel 2110598 beschriebene Problem.

    Dieses Problem wurde in NSX 6.1.5 behoben.

  • Behobenes Problem 1421287: L2VPN wird heruntergefahren, nachdem ein Ping für die Broadcast-IP ausgeführt wurde. tap0-Schnittstelle wird auf Standalone Edge heruntergefahren.
    Wenn ein Ping für die Broadcast-Adresse ausgeführt wird, wurden die MAC-Adressen abgerufen, aber der L2VPN-Tunnel wird heruntergefahren. Die tap0-Schnittstelle wird heruntergefahren, nachdem Edge viele MAC-Adressen abgerufen hat.

    Dieses Problem wurde in NSX 6.1.4 behoben.

  • Hohe CPU-Nutzung bei NSX Manager während vCenter-Bestandslisten-Updates
    Zur Bereitstellung von Firewall-Regeln mit vielen Sicherheitsgruppen wird eine große Zahl von Verbindungen mit der internen Postgres-Datenbank benötigt. Gleichzeitig ausgeführte CPU-Threads können zu einem langen Zeitraum mit hoher CPU-Auslastung auf dem NSX Manager-Server führen.

    Dieses Problem wurde in NSX 6.1.4 behoben.

  • Lange Ladezeiten für NSX Manager bei großen Domänenkonten
    Wenn sich Domänenbenutzer mit einer größeren Anzahl an Gruppen bei vSphere Web Client anmelden, dauert es sehr lange, Zugriff auf die NSX Manager-Schnittstelle zu erhalten.

    Dieses Problem wurde in NSX 6.1.4 behoben.

  • Fixes für die Schwachstellen CVE-2014-6593 („Skip-TLS“) und CVE-2015-0204 („FREAK“) (zusammen „SMACK“-Schwachstellen)
    Dieser Fix behandelt die Probleme, die allgemein als die „SMACK“-Schwachstellen bekannt sind. Dazu gehört die „FREAK“-Schwachstelle, die OpenSSL-basierte Clients betrifft, indem zugelassen wird, dass sie fälschlicherweise Exportverschlüsselungssammlungen verwenden. SSL VPN-Clients wurden mit OpenSSL Version 1.0.1L aktualisiert, um dieses Problem zu behandeln. OpenSSL auf NSX Edge wurde auch auf Version 1.0.1L aktualisiert.
     
    Dieser Fix behandelt auch die „Skip-TLS“-Schwachstelle. Das JRE-Paket von Oracle (Sun) wurde auf 1.7.0_75 (Version 1.7.0, Update 75) aktualisiert, da Skip-TLS Java-Versionen vor dem Update 75 beeinträchtigte. Oracle hat die in JRE 1.7.0_75 verwendeten CVE-Bezeichner im Oracle Java SE Critical Patch Update Advisory für Januar 2015 dokumentiert.

  • Fixes für die POODLE-Schwachstelle CVE-2014-3566
    Die Version 6.1.4 enthält Änderungen, die die Schwachstelle CVE-2014-3566 behandeln (die als „POODLE“ bekannte Schwachstelle in SSLv3). Zu den Änderungen gehören:
    • Das standardmäßige Deaktivieren von SSLv3 in NSX Manager (seit Version 6.1.2). Zum Reaktivieren der SSLv3-Unterstützung in dieser Komponente wenden Sie sich an den VMware-Support.
    • Das standardmäßige Deaktivieren von SSLv3 im NSX Edge-Lastausgleichsdienst (seit Version 6.1.4). Informationen zum Reaktivieren der SSLv3-Unterstützung in dieser Komponente finden Sie im VMware-Knowledgebase-Artikel 2116104.
    • Eine neue API-Methode, mit der Sie SSLv3 für das SSL VPN von NSX Edge deaktivieren und reaktivieren können (seit Version 6.1.4). Informationen zum Deaktivieren und Reaktivieren der SSLv3-Unterstützung in dieser Komponente finden Sie im VMware-Knowledgebase-Artikel 2115871.
    • Ein Update der SSL-Bibliothek des NSX Edge-Systems auf OpenSSL 0.9.8zc.

Die folgenden Probleme wurden in Version 6.1.3 behoben:

  • VMs verlieren die Konnektivität zu Netzwerken, die über gültige Distributed Logical Router-Konfigurationen verbunden sind
    Dies trat aufgrund eines Fehlers auf, der verhinderte, dass NSX Manager mit dem neuesten NSX Controller-Zustand aktualisiert wurde. Während dieser Fehlerbedingung konnte NSX nach einem Neustart von NSX Manager keine Synchronisierung des SSL-Zustands (<controllerConfig><sslEnabled>true/false</sslEnabled></controllerConfig>) mit dem ESX-Host durchführen.

    Dieses Problem wurde in NSX 6.1.3 behoben.

  • Upgrade auf NSX for vSphere-Controller von vCNS 5.0.x oder 5.1.x ist nicht möglich
    Wenn bei der Migration von vCNS zu NSX for vSphere ursprünglich vCNS 5.0.x oder 5.1.x vorhanden war, schlug die Bereitstellung von NSX for vSphere-Controllern aufgrund von Datenbankschemaänderungen zwischen den Versionen fehl.

    Dieses Problem wurde in NSX 6.1.3 behoben.

  • Hostvorbereitung/VIB-Installation schlug fehl, wenn für den ESXi-Host der Sperrmodus konfiguriert war
    Hostvorbereitung und Installation von VXLAN-VIBs schlugen fehl, wenn für den ESXi-Host der Sperrmodus konfiguriert war.

    Dieses Problem wurde in NSX 6.1.3 behoben.

  • Validierung von Serverzertifikaten für Linux- und OS X-Clients im SSL VPN
    Anhand von Kundenfeedback haben wir das Management von Vertrauensstellungen für SSL VPN-Clients mit Mac und Linux verbessert. Wir verwenden jetzt Standardtools, die auf diesen Plattformen zur Verfügung stehen, um bessere Vertrauensstellungen mit unserem SSL VPN-Server einzurichten. Der Windows-VPN-Client nutzt bereits den Vertrauensspeicher der Plattform, wenn er mit aktivierter Zertifikatüberprüfung installiert wird. Weitere Informationen finden Sie im NSX-Administratorhandbuch.

    Dieses Problem wurde in NSX 6.1.3 behoben.

  • Für OSPF-fähige NSX Edge Services Gateways wurde die OSPF-Nachbarschaft nicht eingerichtet und die Aushandlung verblieb im bidirektionalen Status
    Die OSPF-Nachbarschaft konnte nicht eingerichtet werden und verblieb im bidirektionalen Status.
    Protokolle für das dynamische Routing wurden für die Ausführung auf Teilschnittstellen nicht unterstützt.

    Dieses Problem wurde in NSX 6.1.3 behoben.

  • Durch das Aktivieren des ECMP-Routings (Equal Cost Multi-Path) auf einem logischen Router wurde die Firewall deaktiviert
    Wenn ECMP auf der Registerkarte „Globales Routing“ aktiviert war, wurde die Firewall automatisch deaktiviert.

    Dieses Problem wurde in NSX 6.1.3 behoben.

  • Die Konfiguration des Layer-2-Bridgings auf einem Distributed Logical Router schlug fehl
    Die Konfiguration des Layer-2-Bridgings auf einem Distributed Logical Router in NSX for vSphere 6.1.2 schlug mit der Fehlermeldung Der Benutzer ist nicht berechtigt, auf das Objekt edge-XX und die Funktion edge.bridging zuzugreifen fehl. Weitere Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2099414.

    Dieses Problem wurde in NSX 6.1.3 behoben.

  • Zwei ungleiche Kostenpfade wurden in FIB installiert
    Wenn NSX Edge eine statische Route für ein Netzwerk aufweist und außerdem eine dynamische Route für dieselbe Route ermittelt, wird die statische Route korrekterweise vor der dynamischen Route gewählt, da die statische Route bevorzugt wird. Wenn allerdings die Schnittstelle, die der statischen Route entspricht, umgestellt wurde, installierte die FIB fälschlicherweise zwei Pfade zu diesem Netzwerk.

    Dieses Problem wurde in NSX 6.1.3 behoben.

  • SSL VPN Mac-Client für OS X Yosemite zeigte einen Zertifikatauthentifizierungsfehler an
    Da Yosemite „/Library/StartupItems/“ nicht als Startelement verwendete, wurde das VMware-Startskript beim Hochfahren der Maschine nicht ausgeführt.

    Dieses Problem wurde in NSX 6.1.3 behoben.

  • Die Veröffentlichung der Firewallregel schlug aufgrund von eingefügten Leerzeichen fehl
    Die Veröffentlichung der Firewallregel schlug fehl, da die IP-Übersetzung Leerzeichen in generierten IP-Bereichen einfügte, wenn verschachtelte Sicherheitsgruppen ausgeschlossene Mitglieder aufwiesen.

    Dieses Problem wurde in NSX 6.1.3 behoben.

  • Bei virtuellen Maschinen trat nach einem vMotion-Vorgang von einem ESXi-Host auf einen anderen eine Netzwerkunterbrechung für bis zu 30 Sekunden auf, wenn in den Feldern „Quelle“ und/oder „Ziel“ von Distributed Firewall-Regeln Sicherheitsgruppen verwendet wurden
    Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 2110197.

    Dieses Problem wurde in NSX 6.1.3 behoben.

  • Firewall-IP-Regelsatz mit Leerzeichen wurde zwar von der Firewall-Benutzeroberfläche akzeptiert, aber nicht auf den Hosts veröffentlicht
    Ein IP-Regelsatz mit Leerzeichen dazwischen, wie beispielsweise „10.10.10.2 ,10.10.10.3“, wurde in der Firewall-Benutzeroberfläche akzeptiert, aber die Regeln wurden nicht auf den Hosts veröffentlicht.

    Dieses Problem wurde in NSX 6.1.3 behoben.

  • Gleichzeitige Bereitstellung einer großen Zahl virtueller Maschinen führte zu einem Netzwerkadapter-Verbindungsfehler
    HA brach mehrere Failover-Versuche für virtuelle Maschinen nach der Bereitstellung ab und es wurden keine „dvPort“-Daten geladen. Die betroffenen virtuellen Maschinen wurden für einen Start ohne verbundene Netzwerkadapter markiert.

    Dieses Problem wurde in NSX 6.1.3 behoben.

  • Logischer Switch konnte nicht zu einer Sicherheitsgruppe hinzugefügt werden
    Das Hinzufügen eines neuen logischen Switches oder das Bearbeiten eines vorhandenen logischen Switches als ein- oder auszuschließender Wert in einer Service Composer-Sicherheitsgruppe war nicht möglich, und die Benutzeroberfläche reagierte anscheinend nicht mehr.

    Dieses Problem wurde in NSX 6.1.3 behoben.

  • VM-Einstellungen können im Web Client nicht angezeigt werden, wenn die virtuelle Maschine Sicherheits-Tags aufwies
    Das Anzeigen der Einstellungen einer virtuellen Maschine (VM) im vSphere Web Client schlug für Benutzer ohne NSX-Rolle fehl und die Fehlermeldung Statuscode = 403, Statusmeldung = [Verboten] wurde angezeigt, falls die VM Sicherheits-Tags enthielt.

    Dieses Problem wurde in NSX 6.1.3 behoben.

Die folgenden Probleme wurden in Version 6.1.2 behoben:

  • Der ARP-Filter für die IP-Adresse der Weiterleitungs-/Uplink-Schnittstelle fehlt in VDR
    Der ARP-Filter für die IP-Adresse der Weiterleitungs-/Uplink-Schnittstelle fehlte in der Steuerungs-VM von NSX Edge. Dies führte zu Instanzen, in denen der Distributed Logical Router (DLR) von NSX auf ARP-Anforderungen antwortete, die die Steuerungs-VM hätte verarbeiten sollen.

    Aktivieren Sie OSPF. Dieses Problem wurde in NSX 6.1.2 behoben.

  • vNICs werden ausgeworfen, weil der HEAP-Arbeitsspeicher von ESXi nicht ausreicht
    Aufgrund der Anzahl der Filter, Firewall-Regeln und Gruppierungskonstrukte auf einem ESXi-Host wird der auf dem Host zugewiesene HEAP-Arbeitsspeicher möglicherweise überschritten. Dies führt dazu, dass die vNICs getrennt werden.
    Der HEAP-Arbeitsspeicher für ESXi wurde in dieser Version auf 1,5 GB erhöht.

    Dieses Problem wurde in NSX 6.1.2 behoben.

  • Wenn in Firewall-Regeln verwendete Objekte umbenannt werden, wird der neue Name nicht in der Firewall-Tabelle verwendet

    Dieses Problem wurde in NSX 6.1.2 behoben.

  • Anfrage, im NSX Edge-Lastausgleichsdienst von Unterstützung für die NTLM-Authentifizierung hinzuzufügen

    Dieses Problem wurde in NSX 6.1.2 behoben.

  • CPU-Lizenzen von NSX for vSphere werden als VM-Lizenzen angezeigt
    CPU-Berechtigungen von NSX for vSphere werden auf der Registerkarte zur vSphere-Lizenzierung als VM-Berechtigungen angezeigt. Wenn ein Kunde z. B. Lizenzen für 100 CPUs besitzt, werden in der Benutzeroberfläche 100 VMs angezeigt.

    Dieses Problem wurde in NSX 6.1.2 behoben.

  • Implizite Ablehnungsregel für BGP-Filter wird auf dem Edge Services Gateway erstellt, aber nicht auf dem logischen Router
    Wenn ein ausgehender BGP-Nachbarfilter auf einem Edge Services Gateway konfiguriert ist, werden nur Präfixe mit expliziter Akzeptanzrichtlinie angekündigt. Deshalb wird eine implizite Ablehnungsregel automatisch erstellt. Auf einem logischen Router werden alle Präfixe angekündigt, wenn sie nicht ausdrücklich gesperrt sind.

    Dieses Problem wurde in NSX 6.1.2 behoben.

Das folgende Problem wurde in Version 6.1.1 behoben:

  • NSX-Appliances anfällig für „BASH Shellshock“-Schwachstelle
    Mit diesem Patch werden Bash-Bibliotheken in den NSX-Appliances aktualisiert, um mehrere kritische Sicherheitsprobleme zu beheben, die im Allgemeinen als Shellshock bezeichnet werden. Von dem Projekt „Common Vulnerabilities and Exposures“ (cve.mitre.org) wurden diesen Problemen die Namen CVE-2014-6271, CVE-2014-7169, CVE-2014-7186 und CVE-2014-7187 zugewiesen.
    Um diese Sicherheitslücke zu schließen, müssen Sie alle NSX-Appliances aktualisieren. Folgen Sie zum Aktualisieren den Anweisungen im Installations- und Upgrade-Handbuch für NSX.

    Dieses Problem wurde in NSX 6.1.1 behoben.

Die folgenden Probleme wurden in Version 6.1.0 behoben:

  • Failover von Microsoft-Clusteringdiensten funktioniert mit logischen Switches nicht korrekt
    Wenn virtuelle Maschinen ARP Probes während des Prozesses zur Erkennung doppelter Adressen (DAD) senden, reagiert die VXLAN-ARP-Unterdrückungsschicht auf die ARP-Anforderung. Dies führt zu einem Fehler beim Abrufen der IP-Adresse und somit zu einem Fehler im DAD-Prozess.

    Dieses Problem wurde in NSX 6.1.0 behoben.

  • NSX Manager wird nicht korrekt aus dem Backup wiederhergestellt
    Nach der Wiederherstellung von NSX Manager aus einem Backup werden die Kommunikationskanäle mit der virtuellen Maschine für die Steuerung des logischen Routers nicht korrekt wiederhergestellt. Daher können logische Switches und Portgruppen nicht mit dem logischen Router verbunden bzw. von diesem getrennt werden.

    Dieses Problem wurde in NSX 6.1.0 behoben.

  • Konfiguration des logischen Routing funktioniert nicht in einer zustandslosen Umgebung
    Bei Verwendung zustandsloser ESXi-Hosts mit NSX sendet der NSX Controller möglicherweise Informationen zur verteilten Routing-Konfiguration an die Hosts, bevor der verteilte virtuelle Switch erstellt wird. Dadurch entsteht ein nicht synchronisierter Zustand, und es kommt zu Fehlern bei der Konnektivität zwischen zwei Hosts auf unterschiedlichen Switches.

    Dieses Problem wurde in NSX 6.1.0 behoben.

  • Die Aktivierung von HA auf einem bereitgestellten logischen Router führt dazu, dass der Router seine verteilten Routen auf ESXi-Hosts verliert
    Beim Aktivierungsprozess für HA wird die Instanz des logischen Routers gelöscht und auf ESXi-Hosts erneut erstellt. Nachdem die Instanz neu erstellt wurde, werden die Routing-Informationen von der Steuer-VM des Routers nicht richtig neu synchronisiert. Dadurch verliert der Router seine verteilten Routen auf ESXi-Hosts.

    Dieses Problem wurde in NSX 6.1.0 behoben.

  • REST schlägt mit dem Fehler HTTP/1.1 500 – Interner Serverfehler fehl
    Wenn das Single Sign-On (SSO) nicht korrekt konfiguriert ist, schlagen alle REST-API-Aufrufe mit dieser Meldung fehl, weil NSX die Anmeldeinformationen nicht überprüfen kann.

    Dieses Problem wurde in NSX 6.1.0 behoben.

  • Beim Navigieren zwischen NSX Edge-Geräten bleibt vSphere Web Client hängen oder zeigt eine leere Seite an

    Dieses Problem wurde in NSX 6.1.0 behoben.

  • Logischer Router mit aktivierter HA verteilt Routen nach Upgrade oder erneuter Bereitstellung nicht neu
    Wenn Sie ein Upgrade oder eine erneute Bereitstellung für einen logischen Router durchführen, für den High Availability aktiviert ist, werden die Routen nicht neu verteilt.

    Dieses Problem wurde in NSX 6.1.0 behoben.

  • OSPF kann nicht für mehr als einen NSX Edge-Uplink konfiguriert werden
    Es ist nicht möglich, OSPF für mehr als einen der NSX Edge-Uplinks zu konfigurieren.

    Dieses Problem wurde in NSX 6.1.0 behoben.

  • Fehler beim Konfigurieren von IPSec VPN
    Wenn Sie den Dienst für das IPSec VPN konfigurieren, wird möglicherweise der folgende Fehler angezeigt:
    [Ipsec] Das localSubnet ''xxx.xxx.xx.x/xx'' ist nicht erreichbar. Es muss über das statische Routing oder ein Subnetz von internen Edge-Schnittstellen erreichbar sein.

    Dieses Problem wurde in NSX 6.1.0 behoben.

  • Probleme beim Löschen von EAM-Agencies
    Um EAM-Agencies erfolgreich vom ESX Agent Manager (EAM) zu entfernen, muss der NSX Manager, der die den EAM-Agencies zugeordneten Dienste bereitgestellt hat, verfügbar sein.

    Dieses Problem wurde in NSX 6.1.0 behoben.

  • Keine Anzeige einer Warnung, wenn ein logischer Switch, der von einer Firewall-Regel verwendet wird, gelöscht wird
    Sie können einen logischen Switch auch dann löschen, wenn er von einer Firewall-Regel verwendet wird. Die Firewall-Regel wird als ungültig markiert, aber der logische Switch wird ohne Hinweis darauf gelöscht, dass der Switch gerade von dieser Firewall-Regel verwendet wird.

    Dieses Problem wurde in NSX 6.1.0 behoben.

  • Mitglied des Lastausgleich-Pools zeigt Warnmeldung an
    Obwohl ein Mitglied des Lastausgleich-Pools eine Warnmeldung anzeigt, kann es weiterhin Datenverkehr verarbeiten. Sie können diese Meldung ignorieren.

    Dieses Problem wurde in NSX 6.1.0 behoben.

  • Nicht gekennzeichnete Schnittstellen für einen logischen Router können nicht konfiguriert werden
    Die VLAN-ID für den vSphere Distributed Switch, mit dem ein logischer Router eine Verbindung herstellt, kann nicht 0 sein.

    Dieses Problem wurde in NSX 6.1.0 behoben.

  • L2 VPN mit IPV6 wird in NSX 6.1.x-Versionen nicht unterstützt

    Dieses Problem wurde in NSX 6.1.0 behoben.

  • Firewall-Regeln, die ungültige logische Switches als Quelle oder Ziel verwenden, werden angezeigt
    Ein logischer Switch kann unabhängig von der Firewall-Regel gelöscht werden. Da vor dem Löschen eines logischen Switches keine Bestätigungsmeldung angezeigt wird, löschen Sie möglicherweise einen logischen Switch, ohne zu bemerken, dass er in einer Firewall-Regel verwendet wird.

    Dieses Problem wurde in NSX 6.1.0 behoben.

  • Nach dem Upgrade von 5.5 auf 6.0.x geht die VXLAN-Konnektivität verloren, wenn erweitertes LACP-Teaming aktiviert ist
    Wenn ein Rechenzentrum mindestens einen Cluster aufweist, für den erweitertes LACP-Teaming aktiviert ist, kann die Kommunikation zwischen zwei Hosts in jeglichen derartigen Clustern beeinträchtigt sein. Dieses Problem tritt beim Upgrade von NSX 6.0.x auf NSX 6.1 nicht auf.

    Dieses Problem wurde in NSX 6.1.0 behoben.

  • Die Richtlinienkonfiguration wird erst bei einer Konfigurationsänderung aktualisiert

    Dieses Problem wurde in NSX 6.1.0 behoben.

Revisionsverlauf der Dokumente

  • 1. Oktober 2015: Erste Auflage für NSX 6.1.5.
  • 22. November 2015: Zweite Auflage für NSX 6.1.5. Das Würde-blockieren-Problem (1328589) wurde geklärt. Dies bleibt ein bekanntes Problem, bis in vSphere ein Fix bereitgestellt wird. In NSX 6.1.5 und 6.2.0 wird eine Problemminderung zur Verfügung gestellt.
  • 20. Mai 2016 Dritte Auflage für NSX 6.1.5. Bekannte Einschränkungen für ein Upgrade von 6.1.x