NSX for vSphere 6.1.4 | 7. Mai 2015 | Build 2691049

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

Neuigkeiten

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:

 

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

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.

Die Versionen 5.5.x, 6.0.x und 6.1.x können direkt auf 6.1.4 aktualisiert werden.

Um NSX vSphere auf 6.1.4 zu aktualisieren, befolgen Sie die unten beschriebenen Schritte:

  1. Aktualisieren Sie NSX Manager und alle NSX-Komponenten auf 6.1.4. Anweisungen finden Sie im Installations- und Upgrade-Handbuch für NSX .
    Wenn Sie vCenter Server und ESXi nicht auf 6.0 aktualisieren möchten, ist der Upgrade-Vorgang abgeschlossen.
    Wenn Sie vCenter Server und ESXi aktualisieren möchten, führen Sie die verbleibenden Schritte in diesem Vorgang aus.
  2. Führen Sie ein Upgrade von vCenter Server auf Version 6.0 durch. Anweisungen finden Sie in der Dokumentation zu VMware vSphere 6.0.
  3. Für ein Upgrade ohne Ausfallzeiten ermitteln Sie jene Hosts in Ihrer Umgebung, bei denen Sie ein Upgrade durchführen können. Versetzen Sie diese Hosts in den Wartungsmodus.
  4. Führen Sie ein Upgrade von ESXi auf Version 6.0 durch. Anweisungen 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 gestartet werden, überträgt NSX Manager die ESXi 6.0-VIBs auf die Hosts.
  5. Wenn die Hosts anzeigen, dass ein Neustart erforderlich ist (auf der Registerkarte „Hosts und Cluster“ auf der linken Seite des vSphere Web Client), starten Sie die Hosts ein zweites Mal neu.
    NSX-VIBs für ESXi 6.0 sind jetzt aktiviert.
  6. Deaktivieren Sie den Wartungsmodus für die Hosts, für die das Upgrade durchgeführt wurde.
  7. Wiederholen Sie die Schritte 3 bis 6 für die nächste Teilgruppe an Hosts, bis alle Hosts in der Umgebung aktualisiert sind.

Behobene Probleme

Die folgenden Probleme wurden in Version 6.1.4 behoben:

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

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.

Behobenes Problem 1406377: 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 anhaltend hoher CPU-Nutzung auf dem NSX Manager-Server führen.

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

Behobenes Problem 1409714 / 1405945: 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.

Behobenes Problem 1361424: 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 im NSX Edge-SSL VPN (seit Version 6.1.4). Informationen zum Reaktivieren der SSLv3-Unterstützung in dieser Komponente finden Sie im VMware- Knowledgebase-Artikel 2115871 .
  • 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 .
  • Das 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.
  • Ein Update der SSL-Bibliothek des vShield Edge-Systems auf OpenSSL 0.9.8zc.

 

Behobenes Problem 1363274: 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 vShield 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.

Bekannte Probleme

Bekannte Probleme gliedern sich wie folgt:

Upgrade- und Installationsprobleme

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 vSphere 6.1.3 einen Sicherungs- und Wiederherstellungsvorgang durchführen, zeigt der vSphere Web Client die Registerkarte „Netzwerk und Sicherheit“ nicht an.
Problemumgehung: Wenn eine NSX Manager-Sicherung wiederhergestellt wird, werden Sie vom Appliance 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
Die Problemumgehung hängt davon ab, ob Partner aktuell vCloud Networking and Security oder NSX for vSphere verwenden.

  • 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/<Dienst-ID>/servicedeploymentspec/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 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 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 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 vSphere 6.0.5 nicht unterstützt, daher kann das Upgrade nicht erfolgreich durchgeführt werden.
Problemumgehung: Importieren Sie ein neues SSL-Zertifikat mit einer unterstützten Schlüsselgröße, bevor Sie das Upgrade starten.

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 fehlende NSX Edges.
Dieses Problem tritt nicht beim Aktualisieren von NSX 6.0.1 oder höher auf.
Problemumgehung: Befolgen Sie die unten beschriebenen Schritte.

  1. Klicken Sie in vCenter auf „Inhalt“.
  2. Klicken Sie in der Spalte „Wert“ auf „ExtensionManager“.
  3. Suchen Sie nach [extensionList["com.vmware.vShieldManager"] und kopieren Sie die Zeichenfolge.
  4. Klicken Sie im Bereich „Methoden“ auf „UnregisterExtension“.
  5. Fügen Sie im Feld „Wert“ die Zeichenfolge ein, die Sie in Schritt 3 kopiert haben.
  6. Klicken Sie auf „Methode aufrufen“.

Damit wird die Bereitstellung des neuesten Plug-In-Pakets sichergestellt.

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

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 Netzwerk und Sicherheit und dann 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. Die 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 Firewallregeln über die Service Composer-Benutzeroberfläche.

 

Allgemeine Probleme

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

 

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.

Probleme beim NSX-Manager

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>

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.
Problemumgehung: Für den zweiten NSX Manager sollte derselbe Hostname wie für den gesicherten NSX Manager konfiguriert werden.

Für den Import eines von der Zertifizierungsstelle signierten Zertifikats muss der NSX Manager neu gestartet werden, damit es wirksam wird
Wenn Sie ein von der Zertifizierungsstelle signiertes NSX Manager-Zertifikat importieren, wird das neu importierte Zertifikat erst wirksam, nachdem Sie den NSX Manager neu gestartet haben.
Problemumgehung: Starten Sie den NSX Manager neu, indem Sie sich bei der virtuellen NSX Manager-Appliance anmelden oder indem Sie den CLI-Befehl reboot verwenden.

Registerkarte „Netzwerk und Sicherheit“ wird im vSphere Web Client nicht angezeigt
Nach dem Upgrade von vSphere auf Version 6.0 wird die Registerkarte „Netzwerk und Sicherheit“ 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.

Synchronisierung von Service Composer geht verloren, wenn Richtlinienänderungen durchgeführt werden, während einer der Service Manager ausgefallen ist.
Dieses Problem steht im Zusammenhang mit Instanzen mehrerer registrierter Dienste/Service Manager und Richtlinien, die mit Verweis auf diese Dienste erstellt wurden. Wenn in Service Composer Änderungen an einer solchen Richtlinie vorgenommen werden, während einer dieser Service Manager ausgefallen ist, schlagen die Änderungen aufgrund eines Fehlers beim Callback des ausgefallenen Service Manager fehl. Als Folge davon ist Service Composer nicht mehr synchronisiert.
Problemumgehung: Stellen Sie sicher, dass der Service Manager reagiert, und erzwingen Sie anschließend eine Synchronisierung über Service Composer.

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

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</portKeyv <!--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 gelöscht 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 Support von VMware, 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

In der Benutzeroberfläche wird 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 Firewallregeln 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 Support von VMware, 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.