NSX für vSphere 6.1.3 | 23. März 2015 | Build 2591148

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

Neuigkeiten

NSX vSphere 6.1.3 ist kompatibel mit vSphere 6.0. 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.

Wenn Sie ein Upgrade von NSX 6.1.1 ausführen oder Data Security in Ihrer Umgebung nicht installiert ist, finden Sie Anweisungen zum Aktualisieren auf diese Version im Installations- und Upgrade-Handbuch für NSX .

Wenn Sie ein Upgrade von einer Version vor NSX 6.1.1 ausführen und Data Security in Ihrer Umgebung installiert ist, führen Sie die nachfolgenden Schritte aus, um auf diese Version zu aktualisieren:

  1. Deinstallieren Sie Data Security aus allen Clustern, in denen der Dienst installiert ist.
  2. Führen Sie ein Upgrade von NSX Manager auf Version 6.1.3 durch. Anweisungen finden Sie im Installations- und Upgrade-Handbuch für NSX .
  3. Installieren oder aktualisieren Sie Guest Introspection und andere Dienste in den entsprechenden Clustern.
  4. Installieren Sie Data Security in den entsprechenden Clustern.
  5. Aktualisieren Sie die übrigen Komponenten. Anweisungen finden Sie im Installations- und Upgrade-Handbuch für NSX .

 

Behobene Probleme

Die folgenden Probleme wurden in Version 6.1.3 behoben:

  • Problem 1407210: Gleichzeitige Bereitstellung einer großen Zahl virtueller Maschinen führt zu einem Netzwerkadapter-Verbindungsfehler
    HA bricht mehrere Failover-Versuche für virtuelle Maschinen nach der Bereitstellung ab und es werden keine „dvPort“-Daten geladen. Die betroffenen virtuellen Maschinen wurden für einen Start ohne verbundene Netzwerkadapter markiert. Virtuelle Maschinen verlieren den Schutz durch HA, weil die Markierung „cleanPowerOff“ fälschlicherweise auf „true“ gesetzt wurde, bevor die Konfiguration der virtuellen Maschine vollständig geladen wurde. Dies geschieht, wenn der „hostd“-Prozess großer Last ausgesetzt ist.
  • Problem 1365993: Bei virtuellen Maschinen tritt 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 werden
    Wenn eine virtuelle Maschine mit vMotion auf einen anderen Host verschoben wird, werden Firewall-Regeln und -Container an den Zielhost gesendet, damit vorhandene Sitzungen weiterhin funktionieren. Als Teil der vMotion-Aktivität sendet vCenter eine leere IP-Adresse für die virtuelle Maschine an NSX Manager, der die IP-Adresse der virtuellen Maschine aus den Firewall-Containern löscht. vCenter fragt die IP-Adresse anschließend erneut ab, sendet eine weitere Benachrichtigung an NSX Manager und der Firewall-Container wird mit der richtigen IP-Adresse aktualisiert. In dem Zeitraum zwischen dem Löschen und erneuten Ausfüllen der IP-Adresse wird eine ungültige Richtlinie auf die virtuelle Maschine auf dem Zielhost angewendet, was zum Verlust der Verbindung führt.
  • Problem 1301660: Beim Ändern von Anmelde- oder Abmeldeskripts wird ein Fehler angezeigt
    Wenn Sie ein Anmelde- oder Abmeldeskript ändern, wird der folgende Fehler angezeigt:
    ObjectNotFoundException: core-services:202: Das angeforderte Objekt logon1.logoff konnte nicht gefunden werden. Bei Objektbezeichnern wird die Groß-/Kleinschreibung berücksichtigt..
  • Problem 1312379: Wenn Protokollnachbarschaften auf Teilschnittstellen aktiviert sind, werden sie manchmal nicht erkannt
    Für OSPF wird eine OSPF-Nachbarschaft möglicherweise nicht erkannt und bleibt im Gegenverkehr stecken.
    Protokolle des dynamischen Routings werden auf Teilschnittstellen nicht unterstützt.
  • Durch das Aktivieren des ECMP-Routings (Equal Cost Multi-Path) auf einem logischen Router wird die Firewall auf der virtuellen Maschine des Router-Steuerelements deaktiviert
    Wenn ECMP auf der Registerkarte „Globales Routing“ aktiviert ist, wird die Firewall automatisch deaktiviert.

Bekannte Probleme

Bekannte Probleme gliedern sich wie folgt:

Upgrade- und Installationsprobleme

Problem 1375343: 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.

Problem 1396592: Bereitstellungsspezifikation mit Versionsangabe muss bei Verwendung von vCenter Server 6.0 und ESX 6.0 auf Version 6.0.x aktualisiert werden.
Partner, die NetX-Lösungen für vCloud Networking and Security registriert haben, müssen die Registrierung aktualisieren und eine Bereitstellungsspezifikation mit Versionsangabe (VersionedDeploymentSpec) für Version 6.0.x mit dem entsprechenden OVF einbinden.
Problemumgehung: Wenn die Basiskonfiguration aus Version 5.5.x mit vSphere 5.5 besteht und für die Infrastruktur vor dem Upgrade von vCloud Networking and Security ein Upgrade auf NSX durchgeführt wird, führen Sie die folgenden Schritte aus:

  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://engweb.eng.vmware.com/~netfvt/ovf/Rhel6-32bit-6.1svm/Rhel6-32bit-6.1svm.ovf</ovfUrl>
    <vmciEnabled>true</vmciEnabled>
    </versionedDeploymentSpec>
  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“.
    2. Klicken Sie auf „Verwaltung“.
    3. Wählen Sie in „Lösung“ die Option „vCenter Server-Erweiterungen“ aus.
    4. Klicken Sie auf „vSphere ESX Agent Manager“ und klicken Sie dann auf die Registerkarte „Verwalten“.
    5. Klicken Sie mit der rechten Maustaste auf den Agency-Status „Fehlgeschlagen“ und wählen Sie „Alle Probleme beheben“ aus.

 

Problem 1393503: Nach dem Upgrade von NSX vSphere von Version 6.0.7 auf Version 6.1.3 stürzt vShpere Web Client im Anmeldebildschirm ab
Nach dem Upgrade von VSM von Version 6.0.7 auf 6.1.3 werden im Anmeldebildschirm der Benutzeroberfläche von vSphere Web Client Ausnahmen angezeigt. Der Benutzer kann sich nicht 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.

Problem 1402307: 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.

Problem 1288506: 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.

Problem 1278690: 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.

Problem 1266433: 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.

Problem 1169078: 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. Wechseln Sie auf dem vSphere Server zum folgenden Speicherort:
    /var/lib/vmware/vsphere-client/vc-packages/vsphere-client-serenity
  2. Löschen Sie die folgenden Ordner:
    com.vmware.vShieldManager-6.0.x.1546773
    com.vmware.vShieldManager-6.0.1378053
  3. Starten Sie den vSphere Web Client-Dienst neu.
Damit wird die Bereitstellung des neuesten Plug-In-Pakets sichergestellt.

 

Problem 1088913: 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.

Problem 1088913: 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

Problem 1215460: Dienstgruppen werden in der Edge Firewall-Tabelle beim Upgrade von vCloud Networking and Security 5.5 auf NSX erweitert
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: Befolgen Sie die unten beschriebenen Schritte:

  1. Erstellen Sie die Dienstgruppen nach dem Upgrade auf der Registerkarte "Gruppieren von Objekten" neu.
  2. Bearbeiten Sie die Spalte "Service" für die betroffenen Firewall-Regeln und zeigen Sie auf die entsprechenden Dienstgruppen.

 

Problem 1088497: 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 „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 Netzwerken 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.

 

Problem 1312562: 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 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

Problem 1411125: 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“.
  2. Klicken Sie auf „Verwaltung“.
  3. Wählen Sie in „Lösung“ die Option „vCenter Server-Erweiterungen“ aus.
  4. Klicken Sie auf „vSphere ESX Agent Manager“ und klicken Sie dann auf die Registerkarte „Verwalten“.
  5. Klicken Sie auf "Auflösen".

 

Problem 1301627: Der Name der Sicherheitsrichtlinie darf maximal 229 Zeichen enthalten
Das Feld für den Namen der Sicherheitsrichtlinie auf der Registerkarte „Sicherheitsrichtlinie“ von Service Composer darf maximal 229 Zeichen enthalten. Grund hierfür ist, dass den Richtliniennamen intern ein Präfix vorangestellt wird.
Problemumgehung: Keine.

Probleme beim NSX-Manager

Problem 1386874: NSX Manager wird nicht gestartet, nachdem vSphere auf Version 6.0 aktualisiert wurde.
Da vSphere 6.0 den Benutzernamen „root“ nicht akzeptiert, wird NSX Manager nicht gestartet, wenn Sie sich als Root-Benutzer anmelden.
Problemumgehung: Melden Sie sich mit dem Benutzernamen „administrator@vsphere.local“ an.

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

Problem 1070905: 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.

Problem 1027066: Beim Verlagern des NSX-Managers unter Verwendung von vMotion kann der folgende Fehler angezeigt werden: Die virtuelle Ethernet-Karte 'Netzwerkadapter 1' wird nicht unterstützt
Sie können diesen Fehler ignorieren. Das Netzwerk funktioniert nach vMotion ordnungsgemäß.

Problem 1091117: Dienste von Drittanbietern können nach dem Wiederherstellen von NSX-Manager-Sicherungen nicht gelöscht werden
Bereitstellungen von einem oder mehreren Diensten von Drittanbietern können nur dann im vSphere Web Client gelöscht werden, wenn der wiederhergestellte Zustand des NSX-Managers die Dienstregistrierung der Drittanbieter enthält.
Problemumgehung: Sichern Sie die NSX-Manager-Datenbank, wenn alle Drittanbieterdienste registriert worden sind.

Probleme bei NSX Edge

Problem 1399955: Upgrade eines eigenständigen NSX Edge wird nicht unterstützt
Problemumgehung: Benutzer müssen ein neues Edge-OVF bereitstellen und die Einstellungen der Appliance neu konfigurieren.

Problem 1399863: 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.

Problem 1395183: SSL VPN Plus-Anmelde-/Abmelde-Skriptänderung funktioniert nicht
Das „modify“-Skript wird auf der NGC-Benutzeroberfläche korrekt dargestellt, im Gateway jedoch nicht.
Problemumgehung: Löschen Sie das ursprüngliche Skript und fügen Sie es erneut hinzu.

Problem 1364996: SSL VPN Mac-Client für OS X Yosemite zeigt einen Zertifikatauthentifizierungsfehler an
Da Yosemite „/Library/StartupItems/“ nicht als Startelement verwendet, wird das VMware-Startskript beim Hochfahren der Maschine nicht ausgeführt.
Problemumgehung: Befolgen Sie die unten beschriebenen Schritte:

  1. Führen Sie den folgenden Befehl aus, um „kext-dev-mode“ festzulegen:
    sudo nvram boot-args="kext-dev-mode=1"
  2. Starten Sie die Maschine neu.
  3. Installieren Sie den Client.

 

Problem 1278437: 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.

Problem 1288487: 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.

Probleme 1265605 und 1265548: 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.

Problem 1278728: 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.

Problem 1275788: Wenn Egress-Optimierung für L2 VPN aktiviert ist, wird der Lastausgleichsdienst 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 Egress-Optimierung.
  • Weisen Sie dem Lastausgleichsdienst eine andere IP-Adresse zu als die Egress-optimierte IP-Adresse.

Problem 1113491: 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.

Problem 1113755: 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.

Problem 1089745: 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.

Problem 1082549: 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.

Problem 1088400: 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.

Problem 1078618: 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.

Problem 859909: 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

Problem 1109671: 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 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

Problem 1110295: 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.