Versionshinweise zu VMware NSX for vSphere 6.2.1

|

Aktualisiert am 20. Mai 2016
VMware NSX for vSphere 6.2.1 | Freigegeben am 17. Dezember 2015 | Build 3300239 |

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

Neuigkeiten

Im Folgenden finden Sie die neuen und geänderten Funktionen in NSX 6.2.1 und 6.2.0.

Neu in 6.2.1

Die Version 6.2.1 enthält zahlreiche Fehlerkorrekturen, die im Abschnitt Behobene Probleme dokumentiert sind.

  • Problemhebungen in 6.1.5: Diese Version enthält dieselben Korrekturen wie die Version NSX for vSphere 6.1.5.

  • Der eingeführte neue Befehl 'show control-cluster network ipsec status' ermöglicht die Überprüfung des IPSEC-Status (Internet Protocol Security, Internetprotokollsicherheit).

  • Konnektivitätsstatus: Die Benutzeroberfläche des NSX Manager zeigt jetzt den Konnektivitätsstatus des NSX Controller-Clusters an.

  • Unterstützung von vRealize Orchestrator-Plug-In für NSX 1.0.3: In der Version NSX 6.2.1 ist die NSX-vRO-Plug-in-Version 1.0.3 für die Verwendung mit vRealize Automation 7.0.0 enthalten. Dieses Plug-In enthält Korrekturen zur Verbesserung der Leistung, wenn vRealize Automation 7.0 die Version NSX for vSphere 6.2.1 als Netzwerk- und Sicherheitsendpunkt verwendet.

  • Beim Start in 6.2.1 ruft NSX Manager alle Controller-Knoten im Cluster ab, um die Verbindungsinformationen zwischen diesem Controller und den anderen Controllern im Cluster zu erfassen.
    Diese werden in der Ausgabe der NSX-REST-API bereitgestellt (Befehl “GET https://[NSX-MANAGER-IP-ADDRESS]/api/2.0/vdn/controller“), die nun den Peer-Verbindungsstatus zwischen den Controller-Knoten anzeigt. Wenn der NSX Manager feststellt, dass die Verbindung zwischen zwei Controller-Knoten unterbrochen ist, wird ein Systemereignis zur Warnung des Benutzers generiert.

  • Service Composer bietet nun eine API, mit der Benutzer die automatische Erstellung von Firewall-Entwürfen für Service Composer-Workflows konfigurieren können.
    Diese Einstellung kann mithilfe der REST-API aktiviert bzw. deaktiviert und die Änderungen können über Neustarts hinaus gespeichert werden. Ist die Einstellung deaktiviert, wird kein Entwurf in der DFW (Distributed Firewall, Verteilte Firewall) für Richtlinien-Workflows erstellt. Damit wird die Anzahl der automatisch im System erstellten Entwürfe beschränkt und die Leistung verbessert.

Neu in 6.2.0

NSX for vSphere 6.2.0 umfasste die folgenden neuen und geänderten Funktionen:

  • Cross vCenter Networking and Security

    • NSX 6.2 mit vSphere 6.0 unterstützt Cross vCenter NSX, wobei logische Switches, Distributed Logical Router (DLR) und verteilte Firewalls auf mehreren vCenter-Instanzen bereitgestellt werden können und logische Netzwerkfunktionen und Sicherheitsfunktionen für Anwendungen mit Arbeitslasten (VMs) aktiviert werden, die mehrere vCenter oder mehrere physische Speicherorte umfassen.

    • Konsistente Firewallrichtlinie für mehrere vCenter: Firewallregelabschnitte in NSX können jetzt als "Global" deklariert werden, da die in diesen Abschnitten definierten Regeln für mehrere NSX Manager repliziert werden. Dies vereinfacht die Arbeitslasten für die Definition konsistenter Firewallrichtlinien für mehrere NSX-Installationen.

    • Cross vCenter vMotion mit DFW: Virtuelle Maschinen mit den in den Abschnitten "Global" definierten Richtlinien können bei Erzwingung von konsistenten Sicherheitsrichtlinien auf andere Hosts verschoben werden, die zu anderen vCenter-Instanzen gehören.

    • Globale Sicherheitsgruppen: Sicherheitsgruppen in NSX 6.2, die auf einer IP-Adresse, einem IP-Satz, einer MAC-Adresse oder einem MAC-Satz basieren, können jetzt in globalen Regeln verwendet werden, wobei die Gruppen und Gruppenmitgliedschaften auf mehreren NSX Managern synchronisiert werden. Hierdurch wird die Konsistenz in Objektgruppendefinitionen für mehrere NSX Manager verbessert und die Erzwingung von konsistenten Sicherheitsrichtlinien ermöglicht.

    • Globaler logischer Switch (Universal Logical Switch, ULS): Diese in NSX 6.2 als Teil von Cross vCenter NSX eingeführte neue Funktion ermöglicht das Erstellen von logischen Switches für mehrere vCenter sowie das Erstellen einer zusammenhängenden L2-Domäne für eine Anwendung oder einen Mandanten.

    • Universal Distributed Logical Router (UDLR): Diese in NSX 6.2 als Teil von Cross vCenter NSX eingeführte neue Funktion ermöglicht das Erstellen von Distributed Logical Routern für mehrere vCenter. Die Universal Distributed Logical Router ermöglichen das Routing für mehrere der zuvor beschriebenen globalen logischen Switches. Ein NSX-UDLR ist ebenfalls in der Lage, ein lokalisiertes Routing (Nord-Süd) basierend auf dem physischen Speicherort der Arbeitslasten durchzuführen.

  • Verbesserungen bei Betrieb und Fehlerbehebung

    • Neues Traceflow-Fehlerbehebungs-Tool: Traceflow ist ein Fehlerbehebungs-Tool, mit dem ermittelt werden kann, ob sich das Problem im virtuellen oder im physischen Netzwerk befindet. Es bietet die Möglichkeit, ein Paket von der Quelle zum Ziel zu verfolgen und zu beobachten, wie das Paket die verschiedenen Netzwerkfunktionen im virtuellen Netzwerk durchläuft.

    • Flow Monitoring und IPFIX-Trennung: In NSX 6.1.x wurde die IPFIX-Berichterstellung unterstützt. Diese Funktion konnte jedoch nur aktiviert werden, wenn Flow Monitoring ebenfalls für NSX Manager aktiviert war. Ab NSX 6.2.0 können diese Funktionen unabhängig voneinander eingesetzt werden. In NSX 6.2.0 und höher können Sie IPFIX unabhängig von der Flow Monitoring-Funktion in NSX Manager aktivieren.

    • Neue CLI-Befehle zur Überwachung und Fehlerbehebung in 6.2: Weitere Informationen finden Sie im Knowledgebase-Artikel 2129062.

    • Zentrale Befehlszeilenschnittstelle (CLI): Durch die zentrale Befehlszeilenschnittstelle (CLI) wird die Fehlerbehebungszeit für verteilte Netzwerkfunktionen verringert. Befehle werden über die Befehlszeile im NSX Manager ausgeführt und Informationen werden von Controllern, Hosts und dem NSX Manager abgerufen. Dies ermöglicht den schnellen Zugriff auf und den Vergleich von Informationen aus mehreren Quellen. Die zentrale Befehlszeilenschnittstelle stellt Informationen über logische Switches, logische Router, verteilte Firewall und Edges bereit.

    • Mit dem ping-Befehl an der CLI werden eine konfigurierbare Paketgröße und ein do-not-fragment-Flag hinzugefügt: Ab NSX 6.2.0 bietet der ping-Befehl an der NSX-CLI Optionen zum Angeben der Datenpaketgröße (ohne den ICMP-Header) sowie zum Festlegen des do-not-fragment-Flags. Einzelheiten hierzu finden Sie in der NSX-CLI-Referenz.

    • Integrität der Kommunikationskanäle anzeigen: In NSX 6.2.0 können Sie jetzt die Integrität der Kommunikationskanäle anzeigen. Der Status der Kanalintegrität zwischen NSX Manager und dem Firewall-Agent, zwischen NSX Manager und dem Steuerungskomponenten-Agent sowie zwischen dem Host und dem NSX-Controller kann auf der NSX Manager-UI angezeigt werden. Darüber hinaus bietet der Hostbefehlskanal eine größere Fehlertoleranz.

    • CLI des eigenständigen Edge L2-VPN-Clients: Vor der Version NSX 6.2 konnte ein eigenständiger NSX Edge L2-VPN-Client nur über die Einstellungen zum Bereitstellen für das virtuelle Center im OVF-Format (Open Virtualization Format) konfiguriert werden. Es wurden speziell für den eigenständigen NSX Edge-Client geltende Befehle hinzugefügt, um die Konfiguration unter Verwendung der CLI zu ermöglichen.

  • Logisches Netzwerk und Routing

    • L2-Bridging-Interoperabilität mit Distributed Logical Router: Mit VMware NSX for vSphere 6.2 kann das L2-Bridging jetzt in das verteilte logische Routing einbezogen werden. Das VXLAN-Netzwerk, mit dem die Bridge-Instanz verbunden ist, wird verwendet, um die Routing-Instanz mit der Bridge-Instanz zu verbinden.

    • Unterstützung von /31-Präfixen auf ESG- und DLR-Schnittstellen mit RFC 3021.

    • Verbesserte Unterstützung für DHCP-Anforderung mittels Relay auf dem ESG-DHCP-Server.

    • Die VLAN-IDs/-Kopfzeilen können innerhalb virtueller NSX-Netzwerke beibehalten werden.

    • Genaue Übereinstimmung bei Neuverteilungsfiltern: Der Neuverteilungsfilter hat denselben Übereinstimmungsalgorithmus wie ACL, sodass ein genaues Präfix standardmäßig übereinstimmt (außer, wenn le- oder ge-Optionen verwendet werden).

    • Unterstützung der Verwaltungsdistanz für statische Route.

    • Die Überprüfung kann pro Schnittstelle auf dem Edge aktiviert, gelockert bzw. deaktiviert werden.

    • Anzeige von AS-Pfad in CLI-Befehl show ip bgp

    • Ausschluss der HA-Schnittstelle aus der Neuverteilung in Routing-Protokolle auf der DLR-Steuerungs-VM.

    • Durch das Erzwingen der Synchronisierung des DLR (Distributed Logical Router) wird Datenverlust beim Routing von Datenverkehr (Ost-West) für den DLR vermieden. Bei vertikalem Routing (Nord-Süd) und Bridging kann weiterhin eine Unterbrechung auftreten.

    • Anzeige des aktiven Edge in HA-Paar: Im NSX 6.2 Web Client können Sie feststellen, ob eine NSX Edge-Appliance aktiv ist oder als Sicherung in einem HA-Paar eingesetzt wird.

    • REST-API unterstützt umgekehrten Pfadfilter (rp_filter) auf Edge: Unter Verwendung der REST-API in der Systemsteuerung kann rp_filter sysctl über die Benutzeroberfläche konfiguriert werden und wird ebenfalls über die REST-API für vNIC-Schnittstellen und -Teilschnittstellen offen gelegt. Weitere Informationen finden Sie in der NSX-API-Dokumentation.

    • Verhalten des IP-Präfix GE und des IP-Präfix LE für BGP-Routenfilter: In NSX 6.2 wurden die folgenden Verbesserungen für BGP-Routenfilter vorgenommen:

      • Nicht zulässige LE-/GE-Schlüsselwörter: Für die Nullrouten-Netzwerkwerkadresse (definiert als ANY oder im CIDR-Format 0.0.0.0/0) sind die Schlüsselwörter Less-Than-Or-Equal-To (LE) und Greater-Than-Or-Equal-To (GE) nicht mehr zulässig. In früheren Versionen waren diese Schlüsselwörter zulässig.

      • LE- und GE-Werte im Bereich 0 bis 7 werden jetzt als gültig behandelt. In früheren Versionen war dieser Bereich nicht gültig.

      • Für ein gegebenes Routen-Präfix können Sie keinen GE-Wert mehr angeben, der größer als der angegebene LE-Wert ist.

  • Netzwerk- und Edge-Dienste

    • Die Verwaltungsschnittstelle des DLR wurde in HA-Schnittstelle umbenannt. Dieser Schritt wurde vorgenommen, um der Tatsache Rechnung zu tragen, dass die HA den Datenverkehr über diese Schnittstelle abwickelt und dass Unterbrechungen des Datenverkehrs an dieser Schnittstelle zu einer Split-Brain-Bedingung führen können.

    • Verbesserungen bei der Systemüberwachung des Load Balancer: Bietet eine detaillierte Systemüberwachung mit Fehlerberichten, Berichten zur letzten Systemstatusprüfung und Statusänderungen sowie Berichten zu Fehlerursachen.

    • Unterstützung für VIP und Pool-Portbereich: Möglichkeit der Load-Balancer-Unterstützung für Anwendungen, für die ein Portbereich erforderlich ist.

    • Erhöhung der maximalen Anzahl an virtuellen IP-Adressen (VIPs): Anstieg der VIP-Unterstützung auf 1024.

  • Verbesserungen des Sicherheitsdienstes

    • Neue Erkennungsmechanismen für IP-Adressen für VMs: Für die autoritative Erzwingung von Sicherheitsrichtlinien basierend auf VM-Namen oder anderen vCenter-basierten Attributen ist es erforderlich, dass NSX die IP-Adresse der VM kennt. In NSX 6.1 und früheren Versionen basierte die IP-Adressenerkennung für jede VM auf dem Vorhandensein von VMware Tools (vmtools) auf dieser VM oder auf der manuellen Autorisierung der IP-Adresse für diese VM. NSX 6.2 enthält nun die Option zur Ermittlung der IP-Adresse der VM durch den Hypervisor. Mit diesen neuen Erkennungsmechanismen kann NSX die objektbasierten verteilten Firewallregeln auf VMs erzwingen, auf denen VMware Tools nicht installiert ist.

  • Lösungsinteroperabilität

    • Unterstützung für vSphere 6.0 Platform Services Controller-Topologien: Neben den bereits eingebetteten PSC-Konfigurationen unterstützt NSX jetzt externe Platform Services Controller (PSC).

    • Unterstützung von vRealize Orchestrator-Plug-In für NSX: NSX 6.2 unterstützt das NSX-vRO-Plug-In für die Integration von NSX mit vRealize Orchestrator.

Systemanforderungen und Installation

Produkt oder Komponente Empfohlene Version
NSX for vSphere 6.2.1
vSphere 5.5U3 oder 6.0U1
Guest Introspection Guest Introspection- und Netzwerk-Introspektion-basierte Funktionen in NSX sind mit bestimmten VMware Tools (VMTools)-Versionen kompatibel. Zur Aktivierung der optionalen NSX Network Introspection Driver-Komponente, die im Paket mit VMware Tools erhältlich ist, ist ein Upgrade auf eine der folgenden Versionen erforderlich:
  • VMware Tools 5.1 P07 und höher

  • VMware Tools 5.5 P04 und höher

  • VMware Tools 6.0 P01 und höher

  • VMware Tools 10.0 und höher

vRealize Orchestrator NSX-vRO-Plug-In 1.0.3

Eine vollständige Liste der NSX-Installationsvoraussetzungen finden Sie im Abschnitt Systemvoraussetzungen für NSX im NSX 6.2-Installationshandbuch.

Upgrade-Hinweise

  • Upgrade-Pfade:

    • Von NSX 6.x: Siehe die VMware-Interoperabilitätsmatrix: Upgrade-Pfade für die unterstützten Upgrade-Pfade. Beachten Sie, dass eine höhere Versionsnummer kein Kennzeichen für einen unterstützten Upgrade-Pfad ist.

    • For Cross-VC-Sites: Wenn Sie ein Upgrade für eine Cross-vCenter NSX-Installation durchführen, finden Sie dazu Erläuterungen im Abschnitt Cross-vCenter-Upgrades weiter unten in diesem Dokument.

    • Von vCNS 5.x: Direkte Upgrades von vCNS 5.x auf NSX 6.2.1 werden nicht unterstützt. Stattdessen können Sie mit dem NSX 6.2.2-Upgrade-Paket vom 31. März 2016 oder später das Upgrade direkt von VMware vCloud Network and Security (vCNS) 5.1.x oder 5.5.x auf NSX 6.2.2 durchführen. Anweisungen dazu erhalten Sie im Upgrade-Handbuch für NSX im Abschnitt Upgrade von vCloud Networking and Security 5.5.x auf NSX 6.2.

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

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

  • Zur Überprüfung, ob Ihr Upgrade auf 6.2.x erfolgreich durchgeführt wurde, erhalten Sie Erläuterungen im Knowledgebase-Artikel 2134525.

  • Durchführen eines Upgrades als Teil eines umfassenderen VMware-Produkt-Upgrades: Wenn Sie ein Upgrade von NSX im Kontext anderer VMware-Produkt-Upgrades durchführen, wie zum Beispiel vCenter und ESXi, müssen Sie die im Knowledgebase-Artikel 2109760 erläuterte unterstützte Upgrade-Reihenfolge einhalten.

  • Bekannte Probleme, die Upgrades betreffen: Im Abschnitt Bekannte Installations- und Upgrade-Probleme weiter unten in diesem Dokument finden Sie eine Liste der bekannten Probleme beim Upgrade.

  • Neue Systemanforderungen: Die Anforderungen an Arbeitsspeicher und CPU für das Upgrade des NSX Manager sind bei NSX 6.1.x und NSX 6.2.x unterschiedlich. Informationen hierzu finden Sie unter Systemanforderungen für NSX in der Dokumentation NSX 6.2-Installation oder NSX 6.2-Upgrade.

  • Maximale Anzahl von NAT-Regeln: Bei NSX Edge-Versionen vor 6.2 konnte der Benutzer 2.048 SNAT-Regeln und 2.048 DNAT-Regeln separat konfigurieren. Somit lag die Höchstgrenze bei insgesamt 4.096 Regeln. Seit der Version NSX Edge 6.2 und höher wird die Höchstgrenze für die zulässige Anzahl an NAT-Regeln abhängig von der Größe der NSX Edge-Appliance bestimmt:

      Bei COMPACT Edge sind es maximal 1.024 SNAT-Regeln und 1.024 DNAT-Regeln mit einer Höchstgrenze von insgesamt 2.048 Regeln.

      Bei LARGE Edge und QUADLARGE Edge sind es maximal 2.048 SNAT-Regeln und 2.048 DNAT-Regeln mit einer Höchstgrenze von insgesamt 4.096 Regeln.

      Bei XLARGE Edge sind es maximal 4.096 SNAT-Regeln und 4.096 DNAT-Regeln mit einer Höchstgrenze von insgesamt 8.192 Regeln.

    Sollte die Gesamtanzahl der NAT-Regeln (Summe von SNAT und DNAT) eines vorhandenen COMPACT Edge die Höchstgrenze von 2.048 übersteigen, dann kann beim Upgrade des NSX Edge auf die Version 6.2 keine Validierung und somit auch kein Upgrade durchgeführt werden. In diesem Fall ist es erforderlich, die Appliance-Größe in LARGE/QUADLARGE zu ändern und das Upgrade erneut durchzuführen.

  • erhaltensänderung bei Neuverteilungsfiltern auf verteiltem logischem Router (DLR) und Edge Services Gateway (ESG): Ab Version 6.2 funktionieren Neuverteilungsregeln im DLR und ESG nur als ACLs. Wenn es sich also bei einer Regel um eine genaue Übereinstimmung handelt, wird die entsprechende Aktion ausgeführt.

  • VXLAN-Tunnel-ID: Vor dem Upgrade auf NSX 6.2.0 müssen Sie sicherstellen, dass Ihre Installation die VXLAN-Tunnel-ID 4094 für keine Tunnel verwendet. Die VXLAN-Tunnel-ID 4094 kann nicht mehr eingesetzt werden. Führen Sie hierzu die folgenden Schritte aus:

    1. Navigieren Sie in vCenter zu Home > Netzwerk und Sicherheit > Installation und wählen Sie die Registerkarte Hostvorbereitung aus.
    2. Klicken Sie in der Spalte "VXLAN" auf Konfigurieren.

    3. Legen Sie im Fenster "VXLAN-Netzwerk konfigurieren" die VLAN-ID auf einen Wert zwischen 1 und 4093 fest.

  • Setzen Sie den vSphere Web Client zurück: Nach dem Upgrade von NSX Manager müssen Sie den vSphere Web Client-Server wie in der Dokumentation zum NSX-Upgrade erläutert zurücksetzen. Bevor Sie diesen Schritt ausführen, wird die Registerkarte Netzwerk und Sicherheit im vSphere Web Client möglicherweise nicht angezeigt.

  • Zustandsfreie Umgebungen: Für NSX-Upgrades in einer statusfreien Hostumgebung werden neue VIB-URLs verwendet: Bei NSX-Upgrades in einer statusfreien Hostumgebung werden die neuen VIBs während des NSX-Upgrades im Vorfeld zum Host-Image-Profil hinzugefügt. Das Verfahren von NSX-Upgrades auf statusfreien Hosts muss daher in folgender Reihenfolge durchgeführt werden:

    1. Laden Sie die aktuellen NSX-VIBs vom NSX Manager über eine feste URL herunter.

    2. Fügen Sie die VIBs zum Host-Image-Profil hinzu.

    In Versionen vor NSX 6.2.0 wurde eine einzelne URL in NSX Manager verwendet, über die VIBs für eine bestimmte Version von ESX Host ermittelt werden konnten. (Der Administrator musste also nur eine einzige URL kennen, unabhängig von der NSX-Version). In NSX 6.2.0 und höher sind die neuen NSX-VIBs über mehrere URLs verfügbar. Führen Sie die folgenden Schritte aus, um die richtigen VIBs zu ermitteln:

    • Suchen Sie die neue VIB-URL über https://<NSX-Manager-IP>/bin/vdn/nwfabric.properties.
    • Rufen Sie die VIBs der erforderlichen ESX-Hostversion über die jeweilige URL ab.
    • Fügen Sie sie zu einem Image-Profil hinzu.
  • Cross-vCenter-Upgrades: Das Handbuch zum Upgrade von NSX enthält keine Upgrade-Anweisungen für Sites, in denen Cross-vCenter NSX ausgeführt wird. Um ein Upgrade für Ihre Cross-vCenter NSX-Installation durchzuführen, folgen Sie den nachfolgend aufgeführten Anweisungen:

    1. Führen Sie das Upgrade für alle NSX Manager durch, wie im NSX-Upgrade-Handbuch erläutert. Führen Sie das Upgrade zuerst für den primären NSX Manager durch und anschließend für alle sekundären NSX Manager. Sie müssen für alle NSX Manager ein Upgrade auf dieselbe Version durchführen. VMware unterstützt keine gemischten Versionen von NSX Manager in einer einzelnen Cross-vCenter NSX-Installation.
    2. Führen Sie das Upgrade für alle NSX-Controller durch, wie im NSX-Upgrade-Handbuch erläutert. Es wird empfohlen, ein Upgrade der Controller im selben Wartungsfenster wie das für NSX Manager durchzuführen.
    3. Schließen Sie das Upgrade ab wie im NSX Upgrade-Handbuch im Abschnitt „Upgrade Host Clusters to NSX 6.2“ (Upgrade für Hostcluster auf NSX 6.2 durchführen) beschrieben.

  • vCNS-Upgrades: Vor dem Upgrade von VMware vCloud Network and Security 5.x auf VMware NSX for vSphere 6.2: Wenn Sie ein Upgrade auf VMware NSX for vSphere 6.2 von VMware vCloud Network and Security 5.5.x planen, überprüfen Sie, ob die Informationen zum Uplink-Portnamen in den Tabellen fehlen, indem Sie den folgenden REST-API-Aufruf ausführen:

    GET https://<nsxmgr-IP>/api/2.0/vdn/switches
    Suchen Sie in der Ausgabe nach dem Feld uplinkPortName. Beispiel:

    <?xml version="1.0" encoding="UTF-8"?>
    <vdsContexts>
       <vdsContext>
          <switch>
             <objectId>dvs-22</objectId>
          <objectTypeName>VmwareDistributedVirtualSwitch</objectTypeName>
             <nsxmgrUuid>4236F6CA-3B1A-56BE-4B55-1EF82B8CA12D</nsxmgrUuid>
             <revision>2</revision>
             <type>
                <typeName>VmwareDistributedVirtualSwitch</typeName>
             </type>
             <name>1-vds-20</name>
             <scope>
                <id>datacenter-3</id>
                <objectTypeName>Datacenter</objectTypeName>
                <name>datacenter-1</name>
             </scope>
             <clientHandle />
             <extendedAttributes />
          </switch>
          <mtu>1600</mtu>
          <teaming>FAILOVER_ORDER</teaming>
          <uplinkPortName>uplink2</uplinkPortName>
          <promiscuousMode>false</promiscuousMode>
       </vdsContext>
    </vdsContexts>
    

    Wenn die Ausgabe dieses Befehls mindestens einen Uplink-Portnamen für jeden verteilten vSphere-Switch enthält, können Sie mit dem Upgrade fortfahren. Wenn der Uplink-Portname in der Ausgabe fehlt, lesen Sie den Knowledgebase-Artikel 2129200.

Bekannte Probleme

Bekannte Probleme gliedern sich wie folgt:

Allgemeine bekannte Probleme

Einige Log Insight-Berichte werden in NSX 6.2 nicht unterstützt
Aufgrund von Kompatibilitätsproblemen zwischen NSX 6.2 und dem vRealize-Inhaltspaket für NSX werden die nachfolgend aufgeführten vRealize Log Insight-Berichte durch NSX 6.2 nicht mehr unterstützt.

  • In Dashboard: NSX-vSphere-Infrastruktur: Der Host - Controller: Das Widget für Kommunikationsfehler wird nicht unterstützt
  • In Dashboard: Übersicht über logische Switches – die folgenden Widgets werden nicht unterstützt:
    • Logische Switches erstellen Überwachungsereignisse
    • Logische Switches aktualisieren Überwachungsereignisse
    • Logische Switches löschen Überwachungsereignisse
  • In Dashboard: Übersicht über logische Router – die folgenden Widgets werden nicht unterstützt:
    • Logische Router erstellen Überwachungsereignisse
    • Logische Router aktualisieren Überwachungsereignisse

Problemumgehung: Keine. Aktuelle Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2143058.

Es sind eventuell keine Schicht 2-Regeln (L2, Layer 2) vorhanden, wenn die MAC-Adresse einer virtuellen Maschine in den Regeln verändert wurde.
Da die L2-Regeloptimierung standardmäßig AKTIVIERT ist, werden L2-Regeln, wenn Quell- und Zielfelder angegeben sind (keine Auswahl von „Beliebig“), nur für vNICs (oder Filter) angewendet, wenn die vNIC-MAC-Adresse mit der Quell- oder Ziel-MAC-Adressliste übereinstimmt. Für Hosts mit virtuellen Maschinen, die nicht den Quell- oder Ziel-MAC-Adressen entsprechen, werden diese L2-Regeln nicht angewendet.

Problemumgehung: Damit L2-Regeln auf alle vNICs (oder Filter) angewendet werden können, muss für ein Quell- oder Zielfeld die Option „Beliebig“ ausgewählt werden.

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.

Der auf der Benutzeroberfläche angezeigte Dienststatus stimmt nicht mit dem Dienststatus in der API überein
In der Registerkarte „Einstellungen“ der Benutzeroberfläche wird der L2-Dienststatus als nicht aktiviert angezeigt. Die API hingegen zeigt den L2-Status als aktiviert an.

Problemumgehung: Aktualisieren Sie die Seite.

Auf der Benutzeroberfläche können Sie NSX-Firewallregeln für beide Richtungen erstellen, die nicht auf Edges angewendet werden können
Fälschlicherweise lässt der Web Client das Erstellen einer NSX-Firewallregel zu, die auf einen oder mehrere NSX Edges angewendet wird, wenn die Regel über Datenverkehr verfügt, der in eine der beiden Richtungen gesendet wird, bzw. wenn es sich bei dem Pakettyp um IPV4 oder IPV6 handelt. Auf der Benutzeroberfläche sollte das Erstellen solcher Regeln nicht zulässig sein, da NSX diese nicht auf NSX Edges anwenden kann.

Problemumgehung: Keine.

Benutzer müssen NSX-Controller-Protokolle nacheinander herunterladen
NSX-Controller-Protokolle können zur Fehlerbehebung heruntergeladen werden. Aufgrund eines bekannten Problems können nicht mehrere Controller-Protokolle gleichzeitig heruntergeladen werden. Selbst wenn der Download über mehrere Controller stattfindet, muss der Download über den aktuellen Controller abgeschlossen sein, bevor Sie den Download über den nächsten Controller starten. Beachten Sie, dass Sie den Download eines Protokolls nicht abbrechen können, nachdem er gestartet wurde.

Problemumgehung: Warten Sie, bis der Download über den aktuellen Controller abgeschlossen ist, bevor Sie den Download eines weiteren Protokolls starten.

Im CSV-Format aus NSX Manager exportierte Protokolldateien sind mit einem Zeitstempel (Zeitraum, nicht Datum/Uhrzeit) versehen.
Wenn Sie Protokolldateien im CSV-Format aus NSX Manager unter Verwendung von vSphere Web Client exportieren, stellen Sie möglicherweise fest, dass die Protokolldateien mit einem Zeitstempel (Zeitraum in Millisekunden) und nicht mit der jeweiligen auf der Zeitzone basierten Zeit versehen sind.

Problemumgehung: Keine.

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

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

Flow Monitoring ignoriert Flows, die einen Grenzwert von 2 Millionen Flows innerhalb von 5 Minuten überschreiten
NSX Flow Monitoring behält bis zu 2 Millionen Fow-Datensätze bei. Wenn Hosts mehr als 2 Millionen Datensätze in 5 Minuten generieren, werden neue Flows verworfen.

Beachten Sie, dass NSX Flow Monitoring zwar produktionsbereit ist, allerdings nur in Fällen mit niedrigeren Anforderungen für Durchsatz/Verbindung pro Sekunde angewendet werden kann. Es lässt sich auch zur Fehlerbehebung sowie zum Erstellen von Regeln für eine begrenzte Dauer verwenden. Bei einem hohen Durchsatz können Probleme wie eine hohe CPU-Nutzung durch den NSX Manager, ein RMQ-Nachrichtenbusüberlauf und Fehler bei der Bereitstellung von Richtlinienaktualisierungen auftreten. Darüber hinaus sind Probleme mit großen UDP-Arbeitslasten festgestellt worden. Für eine fortlaufende Erfassung von Flow-Informationen auf Unternehmensebene wird die Verwendung von IPFIX empfohlen. Beachten Sie, dass es bei Deaktivierung des Flow Monitoring bis zu 15 Tage dauern kann, bis die Datenbank von den Flow-Daten bereinigt ist.

Problemumgehung: Keine.

NSX API gibt unter bestimmten Umständen JSON anstelle von XML zurück
Gelegentlich wird bei einer API-Anforderung JSON anstelle von XML an den Benutzer zurückgegeben.

Problemumgehung: Fügen Sie im Anforderungs-Header Accept: application/xml hinzu.

NSX Manager akzeptiert keine DNS-Suchzeichenfolgen mit einem Leerzeichen als Trennzeichen
NSX Manager akzeptiert keine DNS-Suchzeichenfolgen mit einem Leerzeichen als Trennzeichen. Sie können nur ein Komma als Trennzeichen verwenden. Wenn der DHCP-Server eng.sample.com und sample.com für die DNS-Suchliste angibt, ist NSX Manager mit eng.sample.com sample.com konfiguriert.

Problemumgehung: Trennen Sie durch Kommas. NSX Manager akzeptiert nur Kommas als Trennzeichen für die DNS-Suchzeichenfolge.

In übergreifenden vCenter NSX-Bereitstellungen werden mehrere Versionen von gespeicherten Konfigurationen auf sekundäre NSX Manager kopiert.
Bei der globalen Synchronisierung werden mehrere Kopien von globalen Konfigurationen auf sekundären NSX Managern gespeichert. Die Liste der gespeicherten Konfigurationen enthält mehrere Entwürfe, die während der Synchronisierung für NSX Manager mit demselben Namen und derselben Zeit oder mit einer Zeitdifferenz von 1 Sekunde erstellt wurden.

Problemumgehung: Führen Sie den API-Aufruf aus, um doppelte Entwürfe zu löschen.

DELETE : https://<nsxmgr-ip>/api/4.0/firewall/config/drafts/

Suchen Sie die zu löschenden Entwürfe, indem Sie alle Entwürfe anzeigen:

GET: https://<nsxmgr-ip>/api/4.0/firewall/config/drafts

In der folgenden Beispielausgabe weisen die Entwürfe 143 und 144 denselben Namen auf und sie wurden zur selben Zeit erstellt. Sie stellen daher Duplikate dar. Ebenso weisen die Entwürfe 127 und 128 denselben Namen auf, jedoch mit einer Sekunde Zeitdifferenz. Sie stellen daher auch Duplikate dar.

<firewallDrafts>
    <firewallDraft id="144" name="AutoSaved_Wednesday, August 5, 2015 11:08:40 PM GMT" timestamp="1438816120917"> 
        <description>Auto saved configuration</description>
        <preserve>false</preserve>
        <user>replicator-1fd96022-db14-434d-811d-31912b1cb907</user>
        <mode>autosaved</mode>
    </firewallDraft>
    <firewallDraft id="143" name="AutoSaved_Wednesday, August 5, 2015 11:08:40 PM GMT" timestamp="1438816120713">
        <description>Auto saved configuration</description>
        <preserve>false</preserve>
        <user>replicator-1fd96022-db14-434d-811d-31912b1cb907</user>
        <mode>autosaved</mode>
    </firewallDraft>
   <firewallDraft id="128" name="AutoSaved_Wednesday, August 5, 2015 9:08:02 PM GMT" timestamp="1438808882608">
        <description>Auto saved configuration</description>
        <preserve>false</preserve>
        <user>replicator-1fd96022-db14-434d-811d-31912b1cb907</user>
        <mode>autosaved</mode>
    </firewallDraft>
    <firewallDraft id="127" name="AutoSaved_Wednesday, August 5, 2015 9:08:01 PM GMT" timestamp="1438808881750">
        <description>Auto saved configuration</description>
        <preserve>false</preserve>
        <user>replicator-1fd96022-db14-434d-811d-31912b1cb907</user>
        <mode>autosaved</mode>
    </firewallDraft>
</firewallDrafts>

Wenn eine Firewallrichtlinie im Service Composer aufgrund einer gelöschten Sicherheitsgruppe nicht synchronisiert ist, kann die Firewallregel nicht auf der Benutzeroberfläche korrigiert werden.

Problemumgehung: Auf der Benutzeroberfläche können Sie die ungültige Firewallregel löschen und sie anschließend erneut hinzufügen. Sie können auch in der API die Firewallregel korrigieren, indem Sie die ungültige Sicherheitsgruppe löschen. Synchronisieren Sie anschließend die Firewallkonfiguration: Wählen Sie Service Composer: Sicherheitsrichtlinien aus und klicken Sie für jede Sicherheitsrichtlinie mit verbundenen Firewallregeln auf Aktionen und wählen Sie Firewallkonfiguration synchronisieren aus. Um dieses Problem zu vermeiden, verändern Sie die Firewallregeln so, dass sie sich nicht auf Sicherheitsgruppen beziehen, bevor Sie die Sicherheitsgruppen löschen.

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: Führen Sie die folgenden Schritte aus:

  1. Klicken Sie im vSphere Web Client auf Home und anschließend auf Verwaltung.
  2. Wählen Sie unter "Lösung" die Option vCenter Server-Erweiterung aus.
  3. Klicken Sie auf vSphere ESX Agent Manager und dann auf die Registerkarte Verwalten.
  4. Klicken Sie auf Auflösen.

Bekannte Installations- und Upgrade-Probleme

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

Nach dem Upgrade von NSX 6.2 auf 6.2.1 wird im Zuge eines übergreifenden Upgrades des vCenters die Verbindung von NSX zum primären VC getrennt

Problemumgehung: Löschen Sie die NSX-Bundles und starten Sie den VC Web Client neu.

Windows:

  1. Navigieren Sie zu C:\ProgramData\VMware\vCenterServer\cfg\vsphere-client\vc-packages\vsphere-client-serenity.
  2. Entfernen Sie den Ordner com.vmware.vShieldManagerxxxxx (es ist keine Sicherung erforderlich).
  3. Starten Sie den VC Web Client neu.

Unix

  1. Navigieren Sie zu /etc/vmware/vsphere-client/vc-packages/vsphere-client-serenity.
  2. Entfernen Sie den Ordner com.vmware.vShieldManagerxxxxx (es ist keine Sicherung erforderlich).
  3. Starten Sie den VC Web Client neu.

Nach dem Upgrade von NSX Edge von 6.1.x auf 6.2.x enthält die NSX Manager-Protokolldatei vsm.log den Eintrag „Ungültige DHCP-Konfiguration“
Wenn eine Schnittstelle mit einem IPv6-Subnetz vorhanden ist, generiert DHCP ein leeres freigegebenes Subnetz und behandelt es als einen ungültigen Vorgang.

Problemumgehung: Deaktivieren Sie den DHCP-Dienst und führen Sie ein Upgrade für NSX Edge durch. Nach dem Upgrade aktivieren Sie DHCP.

Die Statusanzeige der Guest Introspection-Installation lautet „Erfolg“, obwohl der Host offline ist.
Nach der Installation von Guest Introspection auf dem Cluster, in dem ein Host offline ist, lautet der Installationsstatus des Hosts, der offline ist, „Erfolg“ und der Status „Unbekannt“.

Problemumgehung: Keine.

Die Aktualisierung des Edge Service Gateway schlägt mit der Fehlermeldung „Zeitüberschreitung beim Warten auf Edge-VM“ fehl.
Wird der NSX-Verwaltungsschnittstelle eine IPv6-Adresse zugewiesen, verwendet der NSX Manager den Hostnamen. Der vsfwd-Proxy, der die Edge-VM mit dem NSX Manager verbindet, kann einen FQDN nicht korrekt verarbeiten. Eine Fehlermeldung ähnlich der folgenden wird angezeigt: „FEHLER TaskFrameworkExecutor-6 AbstractEdgeApplianceManager:185 - Zeitüberschreitung beim Warten auf Edge-VM {}. Zeitüberschreitung der VM beim Starten und Antworten für com.vmware.vshield.edge.exception.VshieldEdgeException“.

Problemumgehung: Ändern Sie die Konfiguration mit einem Befehl wie „esxcfg-advcfg -q -s "10.20.233.160" /UserVars/RmqIpAddress“ oder entfernen Sie die IPv6-Adresse aus der Konfiguration der Verwaltungsschnittstelle und verwenden Sie nur IPv4.


Für die NSX Manager-Zertifikatsersetzung ist ein Neustart von NSX Manager und möglicherweise ein Neustart von vSphere Web Client erforderlich.
Wenn Sie das NSX Manager-Appliance-Zertifikat ersetzt haben, müssen Sie die NSX Manager-Appliance immer neu starten. In bestimmten Fällen zeigt vSphere Web Client nach dem Ersetzen des Zertifikats nicht die Registerkarte "Netzwerk und Sicherheit" an. Führen Sie in diesem Fall die folgenden Schritte zur Problemumgehung aus.

Problemumgehung: Starten Sie die NSX Manager-Appliance und dann den vSphere Web Client neu.

Führen Sie die folgenden Schritte aus, um NSX Manager neu zu starten:

  1. Melden Sie sich bei der NSX Manager-CLI an.

  2. Wechseln Sie in den Aktivierungs- bzw. Berechtigungsmodus, indem Sie en eingeben.

  3. Beenden Sie den web-manager-Dienst, indem Sie no web-manager eingeben. Warten Sie auf das OK, um die Beendigung zu bestätigen.

  4. Starten Sie NSX Manager, indem Sie web-manager eingeben. Warten Sie auf das OK, um den Neustart zu bestätigen.

  5. Um den vSphere Web Client neu zu starten, öffnen Sie in vCenter 5.5 https://{vcenter-ip}:5480 und starten Sie den Web Client-Server neu.

  6. Melden Sie sich in der vCenter 6.0-Appliance bei der vCenter Server-Shell als Root-Benutzer an und führen Sie die folgenden Befehle aus:

    shell.set --enabled True

    shell

    localhost:~ # cd /bin

    localhost:~ # service-control --stop vsphere-client

    localhost:~ # service-control --start vsphere-client

  7. Führen Sie in vCenter Server 6.0 die folgenden Befehle aus:

    cd C:\Program Files\VMware\vCenter Server\bin

    service-control --stop vsphere-client

    service-control --start vsphere-client

Nach dem vCenter-Upgrade kann es zu einem Verbindungsabbruch zwischen vCenter und NSX kommen.
Wenn Sie das in vCenter eingebettete SSO verwenden und Sie ein Upgrade von vCenter 5.5 auf vCenter 6.0 durchführen, wird die Verbindung von vCenter zu NSX möglicherweise getrennt. Dies geschieht, wenn vCenter 5.5 bei NSX unter Verwendung des Root-Benutzernamens registriert wurde. In NSX 6.2 ist die vCenter-Registrierung mit Root veraltet. HINWEIS: Wenn Sie externes SSO verwenden, sind keine Änderungen erforderlich. Sie können denselben Benutzernamen, z. B. „admin@mybusiness.mydomain“, beibehalten. Dann wird die vCenter-Verbindung nicht getrennt.

Problemumgehung: Registrieren Sie vCenter mit NSX, indem Sie den administrator@vsphere.local-Benutzernamen anstelle des Root-Benutzernamens verwenden.

Herunterfahren des Gastbetriebssystems für Agent-VMs (SVA) vor dem Ausschalten
Wenn ein Host in den Wartungsmodus versetzt wird, werden alle Dienstanwendungen ausgeschaltet und nicht ordnungsgemäß heruntergefahren. Dies kann zu Fehlern innerhalb von Anwendungen von Drittanbietern führen.

Problemumgehung: Keine.

Dienst-Appliance, die mit der Ansicht „Dienstbereitstellungen“ bereitgestellt wurde, kann nicht eingeschaltet werden

Problemumgehung: Bevor Sie den Vorgang fortsetzen, überprüfen Sie Folgendes:

  • Die Bereitstellung der virtuellen Maschine wurde abgeschlossen.

  • Aufgaben wie z. B. Klonen, Neukonfigurieren usw. werden für die im Aufgabenbereich „VC“ angezeigte virtuelle Maschine ausgeführt.

  • Im VC-Ereignisfenster der virtuellen Maschine werden die folgenden Ereignisse nach der Initiierung der Bereitstellung angezeigt:
     
    Agent-VM <VM-Name> wurde bereitgestellt.
    Markieren Sie den Agenten als verfügbar, um mit dem Agent-Workflow fortzufahren.
     

    Löschen Sie in einem solchen Fall die virtuelle Dienstmaschine. In der Dienstbereitstellungs-Benutzeroberfläche wird die Bereitstellung als „Fehlgeschlagen" angezeigt. Durch Klicken auf das rote Symbol wird ein Alarm wegen einer nicht verfügbaren Agent-VM für den Host angezeigt. Wenn Sie den Alarm beheben, wird die virtuelle Maschine erneut bereitgestellt und eingeschaltet.

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 diesen 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://<nsxmgr-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 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.

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.

SSO kann nach dem Upgrade nicht neu konfiguriert werden
Wenn der in NSX Manager konfigurierte SSO-Server der einzige native Server in vCenter Server ist, können Sie die SSO-Einstellungen in NSX Manager nach dem Upgrade von vCenter Server auf Version 6.0 und dem Upgrade von NSX Manager auf Version 6.x nicht neu konfigurieren.

Problemumgehung: Keine.

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 ein neues SSL-Zertifikat mit einer unterstützten Schlüsselgröße, bevor Sie das Upgrade starten.

SSL VPN sendet keine Upgrade-Benachrichtigung an den Remote-Client
SSL VPN-Gateway sendet keine Upgrade-Benachrichtigung an Benutzer. Der Administrator muss Remotebenutzern manuell mitteilen, dass das SSL VPN-Gateway (Server) aktualisiert wurde, und sie bitten, ihre Clients zu aktualisieren.

Problemumgehung: Benutzer müssen die ältere Version des Client deinstallieren und die neuste Version manuell installieren.

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 auf der vCenter Mob-Benutzeroberfläche auf Inhalt.

  2. Klicken Sie in der Spalte "Wert" auf ExtensionManager.

  3. Suchen Sie nach dem Eigenschaftswert extensionList (zum Beispiel: 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.

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.

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.

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.

Host-Fehlermeldung wird beim Konfigurieren von Distributed Firewall angezeigt
Wenn beim Konfigurieren der Distributed Firewall eine Fehlermeldung im Zusammenhang mit dem Host angezeigt wird, überprüfen Sie den Status der Fabric-Funktion „com.vmware.vshield.nsxmgr.messagingInfra”. Wenn der Status "Rot" lautet, führen Sie das folgende Verfahren zur Problemumgehung durch.

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://<NSX Manager IP>/api/2.0/nwfabric/configure?action=synchronize

<nwFabricFeatureConfig>
  <featureId>com.vmware.vshield.vsm.messagingInfra</featureId>
  <resourceConfig>
    <resourceId>{HOST/CLUSTER MOID}</resourceId>
  </resourceConfig>
</nwFabricFeatureConfig>

Beim Kopieren und Einfügen einer Firewallregel mit Aktivierung der Option „Quelle ablehnen“ bzw. „Ziel ablehnen“ wird eine neue Regel aufgelistet, für die die Option „Quelle ablehnen“ bzw. „Ziel ablehnen“ deaktiviert ist.
Wenn eine Firewallregel mit Aktivierung der Option „Quelle ablehnen“ bzw. „Ziel ablehnen“ kopiert und eingefügt wird, wird nach dem Einfügen eine neue Firewallregel generiert. Für diese Regel ist die Option „Quelle ablehnen“ bzw. „Ziel ablehnen“ jedoch deaktiviert.

Problemumgehung: Keine.

Im NSX Manager-Protokoll werden nach dem Upgrade auf NSX 6.2 Meldungen mit dem Text WARN messagingTaskExecutor-7 angezeigt
Nach dem Upgrade von NSX 6.1.x auf NSX 6.2 wird das NSX Manager-Protokoll mit so oder ähnlich lautenden Meldungen überflutet: WARN messagingTaskExecutor-7 ControllerInfoHandler:48 - Host ist unbekannt: host-15 gibt leere Liste zurück. Dies wirkt sich nicht auf die Funktionsfähigkeit aus.

Problemumgehung: Keine.

Nach dem Upgrade von vCNS können keine neuen Gruppierungsobjekte in einigen aktualisierten Gruppierungsobjekten platziert werden
vCNS 5.x unterstützte die Erstellung von Gruppierungsobjekten in Geltungsbereichen unterhalb des GlobalRoot (unterhalb des NSX-weiten Geltungsbereichs). Beispielsweise konnten Sie in vCNS 5.x ein Gruppierungsobjekt als DC- oder PG-Ebene erstellen. Dagegen erstellt die NSX 6.x-Benutzeroberfläche solche Objekte im GlobalRoot. Diese neu erstellten Gruppierungsobjekte können dann vorhandenen Gruppierungsobjekten nicht hinzugefügt werden, wenn diese in einem niedrigeren Geltungsbereich (DC oder PG) in Ihrer vCNS-Installation vor dem Upgrade erstellt wurden.

Problemumgehung: Informationen hierzu finden Sie im Artikel 2117821 der VMware-Knowledgebase

Nach dem Upgrade von vCNS 5.5.4 auf NSX 6.2.0 bleibt die Firewall auf der Registerkarte „Hostvorbereitung“ deaktiviert
Nach dem Upgrade von vCNS 5.5.x auf NSX 6.2.0 und dem Upgrade aller Cluster bleibt die Firewall auf der Registerkarte „Hostvorbereitung“ deaktiviert. Außerdem wird die Option zum Aktualisieren der Firewall nicht auf der Benutzeroberfläche angezeigt. Dies geschieht nur, wenn Hosts vorhanden sind, die nicht Teil irgendwelcher vorbereiteter Cluster im Datencenter sind, weil die VIBs nicht auf diesen Hosts installiert werden.

Problemumgehung: Verschieben Sie zum Beheben des Problems die Hosts in einen vorbereiteten NSX 6.2-Cluster.

Während eines Upgrades werden die L2- und L3-Firewallregeln nicht für Hosts veröffentlicht
Nach der Veröffentlichung einer Änderung an der Distributed Firewall-Konfiguration wird der Status Vorgang läuft in der Benutzeroberfläche und der API ununterbrochen beibehalten und es wird kein Protokoll für L2- oder L3-Regeln in die vsfwd.log-Datei geschrieben.

Problemumgehung: Veröffentlichen Sie während eines NSX-Upgrades keine Änderungen an der Distributed Firewall-Konfiguration. Um den Status Vorgang läuft zu verlassen und das Problem zu beheben, starten Sie die virtuelle Appliance von NSX Manager neu.

Der NSX-REST-API-Aufruf zur Aktivierung bzw. Deaktivierung der IP-Erkennung scheint keine Auswirkungen zu haben
Wenn die Clustervorbereitung auf dem Host noch nicht abgeschlossen ist, hat der NSX-REST-API-Aufruf zum Aktivieren bzw. Deaktivieren der IP-Erkennung (https://<nsxmgr-ip>/api/2.0/xvs/networks/universalwire-5/features) keine Auswirkungen.

Problemumgehung: Stellen Sie vor dem Erteilen dieses API-Aufrufs sicher, dass die Hostclustervorbereitung abgeschlossen ist.

NSX 6.0.7 SSL VPN-Clients können keine Verbindung zu NSX 6.2 SSL VPN-Gateways herstellen
In NSX 6.2 SSL VPN-Gateways sind die SSLv2- und SSLv3-Protokolle deaktiviert. Das heißt, dass das SSL VPN-Gateway nur das TLS-Protokoll akzeptiert. Die SSL VPN 6.2-Clients wurden aktualisiert, um das TLS-Protokoll standardmäßig beim Verbindungsaufbau zu verwenden. In NSX 6.0.7 verwendet der SSL VPN-Client eine ältere Version der OpenSSL-Bibliothek und das SSLv3-Protokoll zum Aufbau einer Verbindung. Wenn ein NSX 6.0.x-Client versucht, eine Verbindung zu einem NSX 6.2-Gateway herzustellen, schlägt der Verbindungsaufbau auf SSL-Handshake-Ebene fehl.

Problemumgehung: Aktualisieren Sie nach dem Upgrade auf NSX 6.2 den SSL VPN-Client auf NSX 6.2. Anleitungen zum Upgrade finden Sie in der Dokumentation zum NSX Upgrade.

PSOD bei ESXi-Upgrade
Wenn Sie ein Upgrade eines NSX-aktivierten vSphere 5.5U2-Hosts auf vSphere 6.0 durchführen, werden einige der ESXi-Host-Upgrades möglicherweise mit einem lilafarbenen Diagnosebildschirm (auch als PSOD bezeichnet) gestoppt.

Problemumgehung: In diesem Fall finden Sie entsprechende Informationen im Knowledgebase-Artikel 2137826.

Ein Segment-ID-Pool für neue oder aktualisierte logische Router muss erstellt werden
In NSX 6.2 muss ein Segment-ID-Pool mit verfügbaren Segment-IDs vorhanden sein, bevor Sie ein Upgrade eines logischen Routers auf 6.2 durchführen oder einen neuen logischen Router 6.2 erstellen können. Dies gilt auch dann, wenn Sie keine logischen NSX-Switches in Ihrer Bereitstellung verwenden möchten.

Problemumgehung: Wenn es in Ihrer NSX-Bereitstellung keinen lokalen Segment-ID-Pool gibt, erstellen Sie einen als eine Voraussetzung für das Upgrade oder die Installation eines logischen NSX-Routers.

Fehler beim Konfigurieren eines VXLAN-Gateways
Wenn beim Konfigurieren von VXLAN mit einem statischen IP-Pool (unter Networking & Security > Installation> Hostvorbereitung > VXLAN konfigurieren) keine Gateway-IP für den IP-Pool auf dem VTEP festgelegt werden kann (weil das Gateway nicht ordnungsgemäß konfiguriert oder nicht erreichbar ist), wechselt der Status der VXLAN-Konfiguration für den Host-Cluster in den Fehlerstatus (ROT).

Die Fehlermeldung lautet VXLAN-Gateway kann auf Host nicht festgelegt werden und der Fehlerstatus ist VXLAN_GATEWAY_SETUP_FAILURE. Im REST-API-Aufruf GET https://<nsxmgr-ip>/api/2.0/nwfabric/status?resource=<cluster-moid> lautet der VXLAN-Status wie folgt:

<nwFabricFeatureStatus>
  <featureId>com.vmware.vshield.nsxmgr.vxlan</featureId>
  <featureVersion>5.5</featureVersion>
  <updateAvailable>false</updateAvailable>
  <status>RED</status>
  <message>VXLAN-Gateway kann auf Host nicht festgelegt werden</message>
  <installed>true</installed>
  <enabled>true</enabled>
  <errorStatus>VXLAN_GATEWAY_SETUP_FAILURE</errorStatus>
</nwFabricFeatureStatus>

Problemumgehung: Es gibt zwei Optionen, den Fehler zu beheben.

  • Option 1: Entfernen Sie die VXLAN-Konfiguration für den Host-Cluster, korrigieren Sie das zugrunde liegende Gateway-Setup im IP-Pool, indem Sie sicherstellen, dass das Gateway ordnungsgemäß konfiguriert ist, und konfigurieren Sie VXLAN für den Host-Cluster anschließend neu.

  • Option 2: Führen Sie die folgenden Schritte aus.

    1. Korrigieren Sie das zugrunde liegende Gateway-Setup im IP-Pool, indem Sie sicherstellen, dass das Gateway ordnungsgemäß konfiguriert und erreichbar ist.

    2. Versetzen Sie den Host (oder Hosts) in den Wartungsmodus, um sicherzustellen, dass auf dem Host kein VM-Datenverkehr aktiv ist.

    3. Löschen Sie die VXLAN VTEPs aus dem Host.

    4. Deaktivieren Sie den Wartungsmodus für den Host. Durch das Deaktivieren des Wartungsmodus für den Host wird der VXLAN VTEP-Erstellungsvorgang auf NSX Manager ausgelöst. NSX Manager versucht, die erforderlichen VTEPs auf dem Host erneut zu erstellen.

In einer übergreifenden vCenter-Bereitstellung befindet sich unterhalb eines lokalen Konfigurationsabschnitts möglicherweise ein globaler Konfigurationsabschnitt.
Wenn Sie einen sekundären NSX Manager in den eigenständigen Status (Transit) versetzen und anschließend wieder in den sekundären Status wechseln, werden alle lokalen Konfigurationsänderungen, die Sie vorgenommen haben, als sich der NSX Manager vorübergehend im eigenständigen Status befunden hat, über den Abschnitten der replizierten globalen Konfiguration aufgelistet, die vom primären NSX Manager vererbt wurden. Dadurch kommt es zum Fehlerzustand universeller Abschnitt muss sich oberhalb aller anderen Abschnitte auf den sekundären NSX Managern befinden.

Problemumgehung: Verwenden Sie die UI-Option, um Abschnitte nach oben oder nach unten zu verschieben, sodass sich der lokale Abschnitt unterhalb des globalen Abschnitts befindet.

Nach einem Upgrade sind Firewallregeln und Netzwerk-Introspektionsdienste möglicherweise nicht mehr mit NSX Manager synchronisiert
Nach dem Upgrade von NSX 6.0 auf NSX 6.1 oder 6.2 zeigt die NSX-Firewallkonfiguration die folgende Fehlermeldung an: Synchronisierung fehlgeschlagen / nicht synchronisiert. Durch die Verwendung der Aktion ForceSync-Dienste: Firewall wird das Problem nicht behoben.

Problemumgehung: In NSX 6.1 und NSX 6.2 können entweder Sicherheitsgruppen oder dvPortgroups an ein Dienstprofil gebunden werden, jedoch nicht beide. Ändern Sie Ihre Dienstprofile, um das Problem zu beheben.

Das VIB „esx-dvfilter-switch-security“ ist nicht mehr in der Ausgabe des Befehls „esxcli software vib list | grep esx“ vorhanden.
Ab NSX 6.2 sind die Module „esx-dvfilter-switch-security“ innerhalb des VIB esx-vxlan enthalten. Die einzigen NSX VIBs, die für 6.2 installiert sind, sind esx-vsip und esx-vxlan. Bei einem Upgrade von NSX auf 6.2 wird das alte VIB „esx-dvfilter-switch-security“ aus den ESXi-Hosts entfernt.

Problemumgehung: Keine.

Nach dem Upgrade können logische Router, für die explizites Failover-Teaming konfiguriert ist, Pakete möglicherweise nicht ordnungsgemäß weiterleiten
Wenn auf den Hosts ESXi 5.5 ausgeführt wird, unterstützt die explizite Failover-Teaming-Richtlinie für NSX 6.2 nicht mehrere aktive Uplinks auf Distributed Logical Routern.

Problemumgehung: Ändern Sie die explizite Failover-Teaming-Richtlinie, sodass es nur einen aktiven Uplink gibt und sich die anderen Uplinks im Standby-Modus befinden.

Das Deinstallieren von NSX aus einem Hostcluster führt manchmal zu einem Fehlerzustand
Bei Verwendung der Aktion "Deinstallieren" auf der Registerkarte Installation: Hostvorbereitung kann ein Fehler auftreten, bei dem die Nachricht eam.issue.OrphanedAgency in den EAM-Protokollen für die Hosts angezeigt wird. Nach Verwendung der Aktion „Beheben“ und dem Neustart der Hosts bleibt der Fehlerzustand bestehen, selbst wenn die NSX-VIBs erfolgreich deinstalliert wurden.

Problemumgehung: Löschen Sie die verwaiste Agency auf dem vSphere ESX Agent Manager (Verwaltung: vCenter Server-Erweiterungen: vSphere ESX Agent Manager).

SSLv2 und SSLv3 sind in NSX 6.2 auslaufend
Ab NSX 6.2 akzeptiert das SSL VPN-Gateway nur das TLS-Protokoll. Nach dem Upgrade von NSX verwenden neu erstellte NSX 6.2-Clients automatisch das TLS-Protokoll beim Verbindungsaufbau. Wenn ein NSX 6.0.x-Client versucht, eine Verbindung zu einem NSX 6.2-Gateway herzustellen, schlägt der Verbindungsaufbau beim SSL-Handshake-Schritt fehl.

Problemumgehung: Nach dem Upgrade auf NSX 6.2 deinstallieren Sie die alten SSL VPN-Clients und installieren Sie die NSX 6.2-Version der SSL VPN-Clients.

Im vSphere Web Client wird die Registerkarte "Netzwerk und Sicherheit" nach dem Sichern und Wiederherstellen in NSX for vSphere 6.2 nicht angezeigt
Wenn Sie nach dem Upgrade auf NSX for vSphere 6.2 eine Sicherung und Wiederherstellung durchführen, wird die Registerkarte Netzwerk und Sicherheit im vSphere Web Client nicht angezeigt.

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.

Nach dem Upgrade auf NSX 6.2 wird NSX Manager mehr als 100 % des physischen Arbeitsspeichers zugewiesen
Ab NSX 6.2 erfordert NSX Manager einen reservierten Arbeitsspeicher von 16 GB. Vorher waren 12 GB erforderlich.

Problemumgehung: Erhöhen Sie den reservierten Arbeitsspeicher der virtuellen NSX Manager-Appliance auf 16 GB.

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.

Bekannte Probleme bei NSX Manager

Mit einer japanischen Firefox-Oberfläche kann kein sekundärer NSX Manager hinzugefügt werden
Beim Hinzufügen eines sekundären NSX Manager mit einem Firefox-Browser mit deutschem, japanischem, koreanischem oder französischem Gebietsschema wird das Dialogfeld „Fingerabdruck“ nicht angezeigt. Aus diesem Grund ist die Konfiguration eines sekundären NSX Manager nicht möglich, solange diese Gebietsschemata verwendet werden.

Problemumgehung: Verwenden Sie Internet Explorer oder englischsprachige Gebietsschemata.

Der NSX Manager-Dienst wird nicht gestartet, wenn der Hostname mehr als 64 Zeichen enthält.
Bei der Erstellung eines Zertifikats über die OpenSSL-Bibliothek darf der Hostname nicht länger als 64 Zeichen sein.

Die NSX Manager-Auflistung erfolgt für die Anzeige in Web Client sehr langsam
In vSphere 6.0-Umgebungen mit mehreren NSX Managern kann es vorkommen, dass der vSphere Web Client bis zu zwei Minuten benötigt, um die Liste der NSX Manager anzuzeigen, wenn für die Validierung des angemeldeten Benutzers eine große Anzahl von AD-Gruppen verwendet wird. Beim Versuch, die NSX Manager-Liste anzuzeigen, kann es zu einem Zeitüberschreitungsfehler in Bezug auf den Datendienst kommen. Für dieses Problem gibt es keine Umgehung. Warten Sie, bis die Liste geladen ist bzw. bis Sie erneut angemeldet sind, um die NSX Manager-Liste einsehen zu können.

Der NSX Controller wird als getrennt angezeigt
Die NSX Manager-Protokolle geben an, dass die Verbindung zu den Controllern getrennt wurde. Die dazugehörige Fehlermeldung lautet ähnlich wie etwa „FEHLER http-nio-127.0.0.1-7441-exec-16908 BaseRestController:339 - Ausnahme : 'E/A-Fehler: Zeitüberschreitung beim Lesen; eingebundene Ausnahme ist java.net.SocketTimeoutException: Zeitüberschreitung beim Lesen'“. Dies geschieht, wenn eine dazwischenliegende Firewall im Netzwerk die TCP/IP FIN-Meldung blockiert, nachdem die Zeit für den Leerlauf überschritten ist. In diesem Fall wird die Anzahl der Verbindungen mit dem NSX Manager erhöht.

Die Seite der Hostvorbereitung kann nicht geladen werden
Bei der Ausführung von Virtual Center im verknüpften Modus müssen alle VCs mit einem NSX Manager derselben NSX-Version verbunden sein. Sollten die NSX-Versionen nicht übereinstimmen, kann der vSphere Web Client nur mit dem NSX Manager kommunizieren, der die höhere NSX-Version ausführt. Es erscheint eine Fehlermeldung etwa in der Form „Konnte keine Verbindung zum NSX Manager herstellen. Wenden Sie sich an den Administrator“ auf der Registerkarte „Hostvorbereitung“.

Problemumgehung: Es wird empfohlen, für alle NSX Manager ein Upgrade auf dieselbe NSX-Softwareversion durchzuführen.

Vorherige Sicherungen werden nicht auf der Benutzeroberfläche des NSX Manager angezeigt.
Bei der Ausführung einer Sicherung wird der erfolgreiche Abschluss nicht auf der NSX Manager-Benutzeroberfläche angezeigt. Eines dieser Probleme tritt möglicherweise auf, wenn eine große Anzahl von Sicherungsdateien im Zielordner gespeichert ist. Jede einzelne Sicherungsdatei muss auf ihre Kompatibilität hin überprüft werden, bevor die Liste auf derselben Seite angezeigt wird. Der aktuelle Vorgang zur Erstellung einer Dateiliste kann eine Zeitüberschreitung für die Seite nach sich ziehen.

Problemumgehung: Verringern Sie die Anzahl der im Sicherungsordner gespeicherten Dateien mithilfe eines periodischen Bereinigens auf Ihrem Storage-Server oder verschieben Sie ältere Sicherungen in einen anderen Ordner. Um zu überprüfen, ob die Sicherung abgeschlossen wurde, suchen Sie in der Protokolldatei des NSX Manager nach einer Meldung, die etwa wie die folgende lautet: 2015-07-01 22:10:55.869 GMT INFO http-nio-443-exec-250 VsmServiceBackupRestoreExecutor:236 - Sicherungsskript ausführen - Start 2015-07-01 22:14:35.992 GMT INFO http-nio-443-exec-250 VsmServiceBackupRestoreExecutor:278 - Sicherungsskript ausführen - Abgeschlossen

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 Dienst-Manager reagiert und erzwingen Sie eine Synchronisierung über den Service Composer.

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.

Nach der Wiederherstellung der NSX Manager-Sicherung zeigt der REST-Aufruf den Status der Fabric-Funktion com.vmware.vshield.nsxmgr.messagingInfra in Rot an
Wenn Sie die Sicherung einer NSX Manager-Instanz wiederherstellen und den Status der Fabric-Funktion com.vmware.vshield.nsxmgr.messagingInfra unter Verwendung eines REST-API-Aufrufs überprüfen, wird der Status in Rot und nicht in 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://<NSX Manager IP>/api/2.0/nwfabric/configure?action=synchronize

<nwFabricFeatureConfig>
  <featureId>com.vmware.vshield.vsm.messagingInfra</featureId>
  <resourceConfig>
    <resourceId>{HOST/CLUSTER MOID}</resourceId>
  </resourceConfig>
</nwFabricFeatureConfig>

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 die folgende Fehlermeldung an: „Die virtuelle Ethernet-Karte 'Netzwerkadapter 1' wird nicht unterstützt“
Sie können diesen Fehler ignorieren. Das Netzwerk funktioniert nach vMotion ordnungsgemäß.

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.

Auf der Übersichtsseite der virtuellen NSX Manager-Appliance wird kein DNS-Name angezeigt
Beim Anmelden bei der virtuellen NSX Manager-Appliance weist die Zusammenfassungsseite ein Feld für den DNS-Namen auf. Dieses Feld bleibt leer, selbst wenn ein DNS-Name für die NSX Manager-Appliance festgelegt wurde.

Problemumgehung: Sie können den NSX Manager-Hostnamen und die Suchdomänen auf der Seite "Verwalten: Netzwerk" anzeigen.

Die NSX Manager-Benutzeroberfläche meldet Benutzer nach dem Ändern des Kennworts über die NSX-Befehlszeilenschnittstelle nicht automatisch ab
Wenn Sie bei NSX Manager angemeldet sind und Ihr Kennwort über die CLI kürzlich geändert haben, können Sie mit Ihrem alten Kennwort an der NSX Manager-CLI angemeldet bleiben. Normalerweise sollten Sie vom NSX Manager-Client bei einer Zeitüberschreitung der Sitzung nach Inaktivität automatisch abgemeldet werden.

Problemumgehung: Melden Sie sich bei der NSX Manager-Benutzeroberfläche ab und mit dem neuen Kennwort wieder an.

Eigenständiger NSX Manager lässt fälschlicherweise den Import der globalen Firewallkonfiguration zu
NSX Manager, die in einer eigenständigen Rolle ausgeführt werden, sollten normalerweise nur den Import von lokalen Firewallregeln zulassen. Ab NSX-Version 6.2 kann NSX Manager in einer eigenständigen Rolle (Verwalten von Netzwerken für eine vCenter-Instanz) oder im übergreifenden vCenter-Modus ausgeführt werden, wodurch Sie fälschlicherweise die Möglichkeit haben, eine globale Firewallregel in eine NSX Manager-Umgebung zu importieren, die in einer eigenständigen Rolle ausgeführt wird. Sobald die globalen Firewallregeln importiert wurden, können Sie sie nicht mehr über die REST-API oder den vSphere Web Client löschen. Dies ist darauf zurückzuführen, dass der Manager derzeit in einer eigenständigen Rolle ausgeführt wird, für die der globale Abschnitt als lokaler Abschnitt betrachtet wird.

Problemumgehung: Wenn Sie NSX Manager in einer eigenständigen Rolle ausführen, importieren Sie nicht eine Firewallkonfiguration, die globale Regeln enthält. Wenn Sie bereits eine universelle Firewallregel in einen eigenständigen NSX Manager importiert haben, korrigieren Sie das Problem, indem Sie eine gespeicherte Firewallkonfigurationsdatei importieren, die keine universellen Regeln enthält. Veröffentlichen Sie diese Konfigurationsdatei, indem Sie sie in die Firewalltabelle laden.
Führen Sie die folgenden Schritte aus:

  1. Melden Sie sich beim vSphere Web Client an.

  2. Klicken Sie auf Networking & Security und anschließend auf Firewall.

  3. Klicken Sie auf die Registerkarte Firewall.

  4. Klicken Sie auf die Registerkarte Gespeicherte Konfigurationen.

  5. Klicken Sie auf das Symbol Konfiguration importieren (Import).

  6. Klicken Sie auf Durchsuchen und wählen Sie die Datei mit der Konfiguration aus, die Sie importieren möchten.

    Regeln werden anhand der Regelnamen importiert. Beim Importvorgang stellt Firewall sicher, dass jedes in der Regel referenzierte Objekt in Ihrer Umgebung auch vorhanden ist. Wird ein Objekt nicht gefunden, wird die Regel als ungültig gekennzeichnet. Wenn eine Regel auf eine dynamische Sicherheitsgruppe verweist, wird die dynamische Sicherheitsgruppe beim Importvorgang in NSX Manager erstellt.

  7. Fügen Sie den Knoten als einen sekundären Knoten erneut hinzu. Bei der Synchronisierung der NSX Manager wird der globale Abschnitt automatisch ordnungsgemäß synchronisiert und die erforderliche Bereinigung wird vollständig durchgeführt.

    Nach der erfolgreichen Veröffentlichung der Konfigurationsdatei werden die Regeln an den Host übertragen und wirken sich auf den Datenpfad aus. Das System funktioniert wie erwartet.

Hostname des Netzwerks kann nicht bearbeitet werden
Nachdem Sie sich bei der virtuellen NSX Manager-Appliance angemeldet haben und zu Appliance Management navigiert sind, auf die Einstellungen „Appliance verwalten“ und dann auf „Netzwerk“ unter „Einstellungen“ geklickt haben, um den Hostnamen des Netzwerks zu verwalten, erhalten Sie möglicherweise einen Fehler in Bezug auf eine ungültige Domänennamenliste. Dies geschieht, wenn die im Feld „Suchdomänen“ angegebenen Domänennamen durch Leerraumzeichen anstatt durch Kommas getrennt sind. NSX Manager akzeptiert nur Domänennamen, die durch Kommas getrennt sind.
Problemumgehung: Führen Sie die folgenden Schritte aus:

  1. Melden Sie sich bei der virtuellen NSX Manager-Appliance an.

  2. Klicken Sie unter Appliance-Verwaltung auf Appliance-Einstellungen verwalten.

  3. Klicken Sie im Fensterbereich „Einstellungen“ auf Netzwerk.

  4. Klicken Sie auf Bearbeiten neben DNS-Server.

  5. Ersetzen Sie im Feld „Suchdomänen“ alle Leerraumzeichen durch Kommas.

  6. Klicken Sie auf OK, um die Änderungen zu speichern.

Falsches Systemereignis wird generiert, selbst nach der erfolgreichen Wiederherstellung von NSX Manager aus einer Sicherung
Nach der erfolgreichen Wiederherstellung des NSX Manager über eine Sicherung werden die folgenden Systemereignisse im vSphere Web Client angezeigt, wenn Sie zu Networking & Security: NSX Manager: Überwachen: Systemereignisse navigieren.

  • Das Wiederherstellen von NSX Manager aus der Sicherung ist fehlgeschlagen (mit Schweregrad „Kritisch“).

  • Das Wiederherstellen von NSX Manager wurde erfolgreich abgeschlossen (mit Schweregrad „Zur Information“.

Problemumgehung: Wenn die abschließende Systemereignisnachricht als erfolgreich angezeigt wird, können Sie die vom System generierten Ereignisnachrichten ignorieren.

Änderung im Verhalten des NSX REST-API-Aufrufs zum Hinzufügen eines Namespace in einem Datencenter
In NSX 6.2 gibt der REST-API-Aufruf POST https://<nsxmgr-ip>/api/2.0/namespace/datacenter/ eine URL mit einem absoluten Pfad zurück. Beispiel: http://198.51.100.3/api/2.0/namespace/api/2.0/namespace/datacenter/datacenter-1628/2. In früheren Versionen von NSX hat dieser API-Aufruf eine URL mit einem relativen Pfad zurückgegeben. Beispiel: /api/2.0/namespace/datacenter/datacenter-1628/2.

Problemumgehung: Keine.

Bekannte Probleme bei logischen Netzwerken und bekannte Probleme bei NSX Edge

Multicast-Datenverkehr wird auf einigen logischen Switches unterbrochen, die von einem Arista-Switch mit EOS-4.12.7.1 unterstützt werden.
In NSX-Installationen, in denen zum physischen Netzwerk Arista-Switches mit Switch-Version EOS-4.12 gehören, wird der logische Multicast-Datenverkehr möglicherweise unterbrochen. Dies ist der Fall, wenn zwei ESX-VTEPS über VXLAN-Port 8472 unter Verwendung eines betreffenden Arista-Switches als physische Grundlage miteinander kommunizieren. Alle Arista-Produkte der Reihe 7150 sind betroffen, wenn eine aktuelle Hauptversion oder Wartungsversionen von EOS 4.12 darauf ausgeführt werden.

Problemumgehung: Kunden mit Arista-Switches haben zwei Möglichkeiten, um das Problem zu umgehen:

  1. Führen Sie ein Upgrade Ihrer Arista-Switches auf EOS 4.13.0 oder höher aus.
  2. Konfigurieren Sie NSX mithilfe der NSX-REST-API zur Nutzung eines anderen UDP-Ports. VMware empfiehlt die Verwendung von Port 4789 gemäß der VXLAN-Spezifikation.

Durch Verzögerungen bei der Herstellung einer Verbindung mit dem NSX-Load balancer kommen keine konsistenten Verbindungen über mehrere VIPs zustande
Wenn der Load Balancer für die Verwendung des Quell-IP-Hash-Load-Balancing konfiguriert ist, erhält eine verbundene Clientsitzung eine konsistente Verbindung mit einem Backend-Server. Der Load Balancer sollte ebenso in der Lage sein, für einen gegebenen verbundenen Client konsistente Verbindungen über mehrere VIPs bereitzustellen, wenn diese VIPs vom selben Serverpool als Backend unterstützt werden. Das heißt, wenn ein Backend-Server mehrere VIPs bedient, sollte eine gegebene Clientverbindung mit einem der VIPs des Backend-Servers sicherstellen, dass dieser Client denselben Backend-Server für die Verbindung mit anderen VIPs verwendet, die von diesem Backend-Server bedient werden. Ein bekanntes Problem verhindert, dass der NSX-Load Balancer solche konsistenten Verbindungen über mehrere VIPs bereitstellen kann.

Es kommt zu Verzögerungen bei der Herstellung einer Verbindung mit RIB und FIB nach der Zuweisung der IP-Adresse zur Schnittstelle
Beim Versuch, einer Schnittstelle eine IP-Adresse zuzuweisen, werden die Schnittstelleninformationen in der Regel sofort aktualisiert. Wird jedoch das Abrufintervall erhöht, kann es bei der Zuweisung der IP-Adresse zu einer Verzögerung kommen.

Langsame Konvergenz beim Herunterfahren des OSPF Area Border Router mit der höchsten IP-Adresse
Die Konvergenz dauert sehr lang, wenn der NSX-basierte OSPF Area Border Router (ABR) mit der höchsten IP-Adresse heruntergefahren oder neu gestartet wird. Wenn ein ABR, der nicht über die numerisch höchste IP-Adresse verfügt, heruntergefahren oder neu gestartet wird, konvergiert der Datenverkehr schnell auf einen anderen Pfad. Wird jedoch der ABR mit der höchsten IP-Adresse heruntergefahren oder neu gestartet, so nimmt die erneute Konvergenz einen Zeitraum von mehreren Minuten in Anspruch. Der OSPF-Vorgang kann manuell bereinigt werden, um die Konvergenzzeit zu verringern.

Die Gesamtanzahl der statischen Bindungen auf einem dhcp-Edge darf nicht höher als 2.048 sein
Wenn es mehr als 2.048 sind, wird die folgende Fehlermeldung angezeigt: „Die Gesamtzahl von Bindungen und Pools darf 2.048 nicht überschreiten“.

Einige TCP-basierten Anwendungen überschreiten möglicherweise den zulässigen Zeitraum, wenn sie eine Verbindung über NSX Edge herstellen
Der Zeitüberschreitungswert für die Inaktivität bei hergestellten TCP-Verbindungen beträgt standardmäßig 3.600 Sekunden. NSX Edge löscht jede Verbindung, die länger im Leerlauf ist, als es der Zeitüberschreitungswert für eine Inaktivität erlaubt, und trennt diese Verbindungen.

Problemumgehung:
  1. Wenn sich die Anwendung eine relativ lange Zeit im Leerlauf befindet, aktivieren Sie die TCP-„KeepAlives“ auf dem Host mit einem „KeepAlive“-Intervall mit weniger als 3.600 Sekunden.
  2. Erhöhen Sie den Edge TCP-Zeitüberschreitungswert für die Inaktivität mithilfe der folgenden NSX-REST-API auf über zwei Stunden. So können Sie den Zeitüberschreitungswert zum Beispiel auf 9.000 Sekunden erhöhen. NSX-API-URL:
    /api/4.0/edges/{edgeId}/systemcontrol/config PUT Method <systemControl> <property>sysctl.net.netfilter.nf_conntrack_tcp_timeout_established=9000</property> </systemControl>

In der Benutzeroberfläche wird der Modus der Edge-Verwaltungsebene (VIX/MSGBUS) nicht angezeigt und die Option zum Wechseln von VIX zu MSGBUS wird nicht angeboten
Wenn eine Edge-Appliance sich im VIX-Modus befindet, kann sie für eine Einbindung in DFW nicht ausgewählt werden, und die Ausführung zentraler CLI-Befehle dauert im Vergleich zum MSGBUS-Modus sehr viel länger.

Problemumgehung: Stellen Sie sicher, dass der Cluster, auf dem Edge bereitgestellt wird, für NSX vorbereitet wurde und dass sein „NSX Manager an Firewall-Agent“ aktiviert ist, und stellen Sie Edge erneut bereit.

Distributed Logical Router gibt falschen nächsten Hop für die Standardroute an, wenn BGP-Nachbarfilter auf "ANY, OUT, DENY" gesetzt ist
Wenn auf einem NSX Distributed Logical Router (DLR) die Option "Default Originate" aktiviert ist und der BGP-Nachbarfilter "ANY, OUT, DENY" auf dem DLR festgelegt ist, zeigt der DLR für die Standardroute eine falsche Adresse für den nächsten Hop an. Dieser Fehler tritt nur auf, wenn ein BGP-Nachbarfilter mit den folgenden Attributen hinzugefügt wird:

  • Richtung: OUT
  • Aktion: Deny
  • Netzwerk: Any

Problemumgehung: Keine.

Die Deaktivierung eines Routing-Protokolls auf einem NSX Edge kann zu einem vorübergehenden Verlust des Datenverkehrs führen
Bei der Deaktivierung eines Routing-Protokolls auf einem NSX Edge wird keine Anforderung zum Zurückweisen der Route (route-withdraw) an den Peer gesendet, sodass der Datenverkehr so lange gepuffert wird, bis der aktivierte Zeitgeber bzw. der Ausfallzeitgeber abläuft.

Problemumgehung: Keine.

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.

Das ESG-Syslog kann nicht an den Remoteserver gesendet werden. Obwohl der DNS-Auflöser funktioniert, wird eine Fehlermeldung angezeigt, dass der Hostname nicht aufgelöst werden kann
Das Syslog kann unmittelbar nach der Edge-Bereitstellung keine Hostnamen für einen konfigurierten Remote-Syslog-Server auflösen.

Problemumgehung: Konfigurieren Sie Remote-Syslog-Server unter Verwendung der entsprechenden IP-Adressen oder verwenden Sie die Benutzeroberfläche, um die Edge-Synchronisierung zu erzwingen. Dieses Problem wurde erstmalig in Version 6.2 festgestellt.

Die Einstellungen für die Konfiguration des DNS-Clients für logische Router werden nach dem Update der REST-Edge-API nicht vollständig angewendet

Problemumgehung: Wenn Sie die REST-API zum Konfigurieren der DNS-Weiterleitung (Auflöser) verwenden, führen Sie die folgenden Schritte durch:

  1. Geben Sie die Einstellungen für den DNS Client XML-Server so an, dass diese der Einstellung der DNS-Weiterleitung entsprechen.

  2. Aktivieren Sie die DNS-Weiterleitung und stellen Sie sicher, dass die Einstellungen für die Weiterleitung den Einstellungen für den DNS-Client-Server entsprechen, die in der XML-Konfiguration angegeben sind.

Validierung und Fehlernachricht für ungültigen nächsten Hop in statischer Route nicht vorhanden, ECMP-aktiviert
Beim Versuch, eine statische Route hinzuzufügen, wenn ECMP aktiviert ist, wird keine Fehlermeldung angezeigt und die statische Route nicht installiert, wenn die Routing-Tabelle keine Standardroute enthält und es einen nicht erreichbaren nächsten Hop in der Konfiguration der statischen Route gibt.

Problemumgehung: Keine.

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, auf der Trunk-vNIC verbunden 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.

Bekannte Probleme bei Sicherheitsdiensten

Keine Konnektivität bei VLAN-ID 0 in L2 VPN
Die NSX L2 VPN-Konfiguration lässt fälschlicherweise zu, dass der Benutzer ein L2 VPN mit VLAN-ID 0 konfiguriert. Sobald dies konfiguriert wurde, ist kein Datenverkehr mehr in diesem VPN möglich.

Problemumgehung: Problemumgehung: Verwenden Sie eine zulässige VLAN-ID im Bereich von 1 bis 4094.

Cipher 3C (SHA-256)-Verschlüsselungsalgorithmen für SSLVPN-Plus werden nicht unterstützt

Der globale logische Switch ist für die Verwendung im Feld „AppliedTo“ einer lokalen DFW-Regel zulässig
Wenn ein globaler logischer Switch als Mitglied einer Sicherheitsgruppe benutzt wird, kann die DFW-Regel diese Sicherheitsgruppe im Feld „AppliedTo“ verwenden. Dadurch wird indirekt die Regel auf den globalen logischen Switch angewendet. Dies sollte nicht erlaubt sein, da es zu einem nicht vorhersehbaren Verhalten dieser Regeln führen kann.

Problemumgehung: Keine.

Die Verwendung von IPSet als Quelle/Ziel in einer NetX-Regel führt zum Fehler „Ungültiger Containertyp“: IPSet
Problemumgehung: Statt IPSet als Quelle/Ziel für netX-Regeln zu verwenden, erstellen Sie eine Sicherheitsgruppe und nehmen IPSet als Mitglied darin auf.

Dies ist ein bekanntes Problem in 6.2.1

Eine Firewall-Ausschlussliste von Cross-vCenter NSX wird nicht veröffentlicht, wenn die Firewall auf einem Cluster deaktiviert wurde
In Cross-vCenter NSX wird für alle Cluster keine Firewall-Ausschlussliste veröffentlicht, wenn die Firewall auf einem Cluster deaktiviert wurde.

Problemumgehung: Führen Sie eine Synchronisierung der betroffenen NSX-Edges durch.

Dies ist ein bekanntes Problem in 6.2.1

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

Dies ist ein bekanntes Problem in 6.1.5 und 6.2.1

In VMware NSX for vSphere 6.1.x und 6.2.x können Distributed-Firewallregeln (DFW) nicht veröffentlicht werden, nachdem das Objekt, auf das verwiesen wird, gelöscht wurde

Problemumgehung: In diesem Fall finden Sie entsprechende Informationen im Knowledgebase-Artikel 2126275.

Es können keine neuen universellen Regeln erstellt werden und vorhandene universelle Regeln können nicht über die Benutzeroberfläche von Flow Monitoring bearbeitet werden

Problemumgehung: Globale Regeln können nicht über die Flow Monitoring-UI hinzugefügt oder bearbeitet werden. EditRule wird automatisch deaktiviert.

Mit der NSX-Benutzeroberfläche dauert es beim Erstellen der Sicherheitsgruppe drei Minuten oder länger, bis die Active Directory-Benutzer/-Gruppen geladen werden

Bei der Konfiguration von Sicherheitsgruppen und bei der Auswahl von „Verzeichnisgruppe“ benötigt die NSX-Benutzeroberfläche drei Minuten oder länger, um die Liste der Active Directory-Benutzer und -Gruppen zu füllen. Für dieses Problem gibt es keine Umgehung.

Firewallkonfiguration für Service Composer nicht synchronisiert
Wenn in NSX Service Composer eine Firewallrichtlinie ungültig ist (z. B. wenn Sie eine Sicherheitsgruppe gelöscht haben, die aktuell in einer Firewallregel verwendet wurde), wird durch das Löschen oder Ändern einer anderen Firewallrichtlinie bewirkt, dass Service Composer nicht mehr synchronisiert ist. Es wird die Fehlermeldung Firewallkonfiguration nicht synchronisiert angezeigt.

Problemumgehung: Löschen Sie ungültige Firewallregeln und synchronisieren Sie anschließend die Firewallkonfiguration. Wählen Sie Service Composer: Sicherheitsrichtlinien aus und klicken Sie für jede Sicherheitsrichtlinie mit verbundenen Firewallregeln auf Aktionen und wählen Sie Firewallkonfiguration synchronisieren aus. Um dieses Problem zu vermeiden, korrigieren oder löschen Sie immer ungültige Firewallkonfigurationen, bevor Sie weitere Änderungen an der Firewallkonfiguration vornehmen.

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.

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 aktualisierten NSX-Installationen führt das Veröffentlichen einer Firewallregel möglicherweise zu einer Null-Pointer-Ausnahme in Web Client
In aktualisierten NSX-Installationen führt das Veröffentlichen einer Firewallregel möglicherweise zu einer Null-Pointer-Ausnahme auf der Benutzeroberfläche. Die Regeländerungen werden gespeichert. Dieses Problem betrifft nur die Anzeige.

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 durch:

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

Bekannte Probleme bei Überwachungsdiensten

Während der DLR(Distributed Logical Router)-Bereitstellung unter Verwendung von vSphere Web Client können nicht mehr als acht Uplink-Schnittstellen bereitgestellt werden

Problemumgehung: Warten Sie, bis die DLR-Bereitstellung abgeschlossen ist, und fügen Sie dann weitere Schnittstellen zu Distributed Logical Router hinzu.

Behobene Probleme

Die folgenden Probleme wurden in den Versionen 6.2.0 und 6.2.1 behoben.

Behobene Probleme gliedern sich wie folgt:

Allgemeine behobene Probleme

  • VMware ESXi 5.x und 6.x zeigen einen violetten Diagnosebildschirm an, wenn Sie die IP-Ermittlung in VMware NSX for vSphere 6.2.0 (2134329) verwenden
    Wenn Sie die IP-Ermittlung für logische Switches in VMware NSX for vSphere 6.2.0 verwenden, schlagen die ESXi 5.x- und ESXi 6.x-Hosts mit einem violetten Diagnosebildschirm fehl wie im Knowledgebase-Artikel 2134329 beschrieben.

    Dieses Problem wurde in NSX 6.2.1 behoben.

  • Die Verwaltungsoption des Sicherheits-Tag-Portlets wird standardmäßig abgeblendet dargestellt
    Auf der Übersichtsseite einer virtuellen Maschine ist die Option „Verwalten“ für das Sicherheits-Tag-Portlet nicht aktiviert, bis der Benutzer ein neues Sicherheits-Tag erstellt.

    Dieses Problem wurde in NSX 6.2.1 behoben.

  • Einige Controller-Protokolle sind nicht für den Syslog-Export verfügbar
    Controller-Protokolle und die darin enthaltenen Zookeeper-Clustering-Protokolle sind kein Bestandteil des Syslog-Exports.

    Dieses Problem wurde in NSX 6.2.1 behoben.

  • In ESXi 6.0 auf vdl2 wird ein violetter Diagnosebildschirm (PSOD, Purple Screen of Death) angezeigt, wenn beim Pingen die Größe der Datenblöcke die verfügbare Datengröße für die maximale Übertragungseinheit (Maximum Transmission Unit, MTU) übersteigt
    Das Starten des Ping über den mit dem NSX-Host-Switch verbundenen vmnknic führt zu einem PSOD-Bildschirm, wenn der Datenblock größer als die MTU ist.

    Dieses Problem wurde in NSX 6.2.1 behoben.

  • Benutzer mussten für das TCP- und UDP-Protokoll dieselbe IP-Adresse und Portnummer konfigurieren
    In dieser Version wurden auch die folgenden Probleme behoben:

    • Die Verwendung eines virtuellen UDP-Servers ohne Poolkonfiguration führt zu einem Konfigurationsfehler.
    • Die Statistiken enthalten falsche Daten, wenn der virtuelle UDP-Server keinem Pool zugeordnet ist.

    Dieses Problem wurde in NSX 6.2.1 behoben. In der Version 6.2.1 können Benutzer dieselbe IP-Adresse und Portnummer sowohl für TCP als auch für UDP mit und ohne zugeordnetem Pool verwenden.

Behobene Installations- und Upgrade-Probleme

  • Eine Installation von SSL VPN-Client auf Mac OS X Yosemite und höher ist nicht möglich
    Vorherige Versionen von Mac OS X werden jedoch unterstützt.

    Dieses Problem wurde in NSX 6.2.1 behoben.

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

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • 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

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • 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 Fehlermeldung, z. B. kann dies 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 vDS-Eigenschaften (vSphere Distributed Switch) durch vCenter übertragen wurden. Dies kann während des Upgrades geschehen. Weitere Informationen hierzu finden Sie im Knowledgebase-Artikel 2107951.

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • Versuche, ein vorhandenes NSX Edge Gateway zu löschen, schlagen in einer auf NSX 6.1.4 aktualisierten Umgebung fehl
    In von 6.1.3 auf 6.1.4 aktualisierten NSX-Installationen können die vorhandenen NSX Edge Gateways nach dem Aktualisieren auf 6.1.4 nicht gelöscht werden. Dieses Problem tritt nicht bei neuen Edge Gateways auf, die nach dem Upgrade erstellt werden. Installationen, die direkt von 6.1.2 oder älteren Versionen aktualisiert wurden, sind von diesem Problem nicht betroffen.

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • Die AES-Verschlüsselung ist bei Ausführung einer NSX-Sicherung unter Verwendung einer gesicherten Drittanbieter-FTP-Sicherung nicht verfügbar

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • Beim Neustart eines Hosts werden auf der Benutzeroberfläche von NSX Manager keine benutzerfreundlichen Fehlermeldungen angezeigt
    In dieser Version 6.2 ist die Benutzeroberfläche von NSX Manager aktualisiert und zeigt detaillierte Fehlermeldungen an, die die Probleme beschreiben, die beim Neustart eines Hosts möglicherweise auftreten, und eine mögliche Lösung anbieten.

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • NSX VIB kann nicht installiert werden
    Die Installation von NSX VIB wird möglicherweise nicht wie erwartet abgeschlossen, wenn ein ixgbe-Treiber aufgrund einer Sperrung nicht über ein Drittanbietermodul geladen werden und daher nicht für die Installation eingesetzt werden kann.

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • Nach dem Aktualisieren von vCloud Networking and Security (vCNS) 5.5.3 kann der NSX Manager-Dienst nicht gestartet werden
    Nach dem Upgrade von vCloud Networking and Security (vCNS) 5.5.3 auf NSX-Version 6.1.3 hängt der NSX Manager-Dienst und kann nicht mehr erfolgreich gestartet werden.

    Dieses Problem wurde in NSX 6.2.0 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.2.0 behoben.

Behobene Probleme beim NSX Manager

  • Beim Start in 6.2.1 ruft NSX Manager alle Controller-Knoten im Cluster ab, um die Verbindungsinformationen zwischen diesem Controller und den anderen Controllern im Cluster zu erfassen.
    Diese werden in der Ausgabe der NSX-REST-API bereitgestellt(“GET https://[NSX-MANAGER-IP-ADDRESS]/api/2.0/vdn/controller“ command), die nun den Peer-Verbindungsstatus zwischen den Controller-Knoten anzeigt. Wenn der NSX Manager feststellt, dass die Verbindung zwischen zwei Controller-Knoten unterbrochen ist, wird ein Systemereignis zur Warnung des Benutzers generiert.

    Dieses Problem wurde in NSX 6.2.1 behoben.

  • Die erzwungene Synchronisierung des Controllers wird unterbrochen, wenn die Wiederherstellung einer Manager-Sicherung in einer anderen Appliance ausgeführt wird
    Wenn eine NSX Manager-Appliance geklont und/oder aus einer Sicherung wiederhergestellt ist, kann keine erzwungene Synchronisierung mit einem NSX Controller-Cluster durchgeführt werden. Dieses Problem tritt nicht bei einem NSX Manager auf, der von Grund auf bereitgestellt wurde.

    Dieses Problem wurde in NSX 6.2.1 behoben.

  • Die NSX-Taktsignalprotokollierung kann nicht für Hosts durchgeführt werden, die kein Bestandteil der NSX-Installation sind
    Wenn ein NSX-vorbereiteter Host direkt aus dem vCenter-Bestand entfernt wird (ohne dessen Vorbereitung vorher in NSX aufzuheben), empfängt NSX einen unerwarteten „Host-verbundenen“ DCN, der das Löschen von Teilen der Komponenten der Nachrichteninfrastruktur vom Host zur Folge hat. Dies kann dazu führen, dass der Nachrichten-Link zwischen NSX und dem Host aktiv bleibt, obwohl er entfernt sein sollte, und dass NSX möglicherweise falsche Systemereignisse des Typs 'Warnung' für den Host generiert. Dieses Problem wurde in NSX 6.2.1 behoben.

    Dieses Problem wurde in NSX 6.2.1 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, arbeitet NSX Manager möglicherweise nicht wie erwartet. Beispiel: Das Kennwort für den Zugriff auf die Linux-Shell wurde zurückgesetzt, der Setup-Befehl fehlt usw.

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • Beim Hinzufügen einer Domäne wird bei der LDAP-Option mit Anmeldedaten der Domäne verwenden ein Fehler angezeigt
    In NSX 6.1.x hat der Web Client beim Versuch, eine LDAP-Domäne hinzuzufügen, den Fehler Benutzername wurde nicht angegeben ausgegeben, selbst dann, wenn der Benutzername auf der Benutzeroberfläche angegeben wurde. Dieses Problem wurde in NSX 6.2.0 behoben.

    Dieses Problem wurde in NSX 6.2.0 behoben.

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

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • Fehler beim Import von NSX Manager in die LDAPS-Domäne
    Wenn Sie versuchen, NSX Manager zur LDAPS-Domäne hinzuzufügen, wird die folgende Fehlermeldung angezeigt:
    Verbindung zum Host nicht möglich <Server FQDN>
    Fehlermeldung: Einfaches Binden fehlgeschlagen: <Server FQDN:Number>

    Dieses Problem wurde in NSX 6.2.0 behoben.

Behobene Probleme bei logischen Netzwerken und behobene Probleme bei NSX Edge

  • Die Konfiguration des RADIUS-Authentifizierungsservers kann in NSX Edge nicht durchgeführt werden
    In NSX 6.1.5 und früher lag die Längenbeschränkung der Zeichenfolge für den geheimen Schlüssel des RADIUS-Servers bei 32 Zeichen. War die Zeichenfolge länger, dann konnte der RADIUS-Server keine Verbindung mit NSX Edge herstellen. Die Längenbeschränkung liegt nun bei 64 Zeichen.

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • Für VMware NSX for vSphere 6.x Edge kann die VIO Heat-Stapelbereitstellung zwischenzeitlich nicht durchgeführt werden. Die zugehörige Fehlermeldung lautet: Es konnte kein Arbeitsspeicher zugeteilt werden
    Die Arbeitsspeichernutzung der Überwachung des Systemzustands steigt mit der Zeit und kann Edge-Fehler verursachen.

    Dieses Problem wurde in NSX 6.2.1 behoben.

  • BGP-Filter benötigen ungefähr 40 Sekunden, um wirksam eingesetzt werden zu können.
    Während dieses Zeitraums werden alle Neuverteilungsrichtlinien ohne Filter angewendet. Diese Verzögerung gilt nur für NSX-DLR (Distributed Logical Router) für OUT-Richtungen.

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • An NSX Edge-Teilschnittstellen werden ICMP-Umleitungen gesendet, auch wenn die Option ICMP-Umleitung senden deaktiviert ist
    Die Option ICMP-Umleitung senden ist für NSX Edge-Teilschnittstellen standardmäßig deaktiviert. Obwohl diese Option deaktiviert ist, werden ICMP-Umleitungen auf Edge-Teilschnittstellen gesendet.

    Dieses Problem wurde in NSX 6.2.0 behoben.

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

    Dieses Problem wurde in NSX 6.2.0 behoben.

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

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • Einer der NSX Controller übergibt die Masterrolle beim Herunterfahren nicht an andere Controller
    Ein 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 Fall übergibt der Controller die Rolle nicht an andere Controller, der Status lautet „unterbrochen“, und der Modus „unterbrochen“ ist aktiv.

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • Es können keine VXLAN-Daten zwischen Hosts mit Unicast oder Multicast ausgetauscht werden
    VMs, die sich auf demselben Host befinden, können auf dem VXLAN mit Unicast oder Multicast kommunizieren, dies ist aber nicht für VMs auf verschiedenen Hosts möglich.

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • Beim gleichzeitigen Entfernen mehrerer BGP-Regeln auf NSX Edge/DLR stürzt Web Client ab

    Dieses Problem wurde in NSX 6.2.0 behoben. Sie können jetzt gleichzeitig mehrere BGP-Regeln löschen.

  • Nach dem Hinzufügen einer Ablehnungsregel für Border Gateway Protocol (BGP) wird die Protokolladresse kurz angezeigt
    Möglicherweise wird nach dem Hinzufügen einer Ablehnungsregel für Border Gateway Protocol (BGP) im NSX Edge Services Gateway die Protokolladresse kurz angezeigt.

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • Die Verbindung von VMs wird während eines vMotion-Vorgangs unterbrochen
    Die Verbindung von VMs wird während eines vMotion-Vorgangs möglicherweise unterbrochen oder möglicherweise werden Warnungen zu VMs mit verbindungslosen Netzwerkkarten angezeigt.

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • Controller-Snapshot kann nicht heruntergeladen werden
    Beim Herunterladen von Controller-Snapshots können Sie möglicherweise den Snapshot für den letzten Controller nicht herunterladen. Beispiel: Bei drei Controllern können Sie Snapshots der ersten zwei erfolgreich herunterladen, aber der Snapshot des dritten Controllers kann möglicherweise nicht heruntergeladen werden.

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • Beim Konfigurieren eines virtuellen Servers wird die zuvor ausgewählte IP-Adresse verwendet
    Beim Erstellen eine neuen virtuellen Servers kann es vorkommen, dass die IP-Adresse automatisch aus der Liste des zuvor ausgewählten ID-Pools übernommen wird. Dies ist dann der Fall, wenn Sie vorher einen IP-Pool zur Bestimmung der virtuellen Server-IP ausgewählt haben. Wenn Sie nun die IP-Pool-Informationen des virtuellen Servers bearbeiten, werden die Informationen nicht automatisch von der Benutzeroberfläche an das Backend gesendet und es wird automatisch die aus dem IP-Pool übernommene IP-Adresse angewendet.

    Dieses Problem wurde in NSX 6.2.1 behoben.

  • 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-Neuinitiierungen konvergieren.

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • VMs können kein Ping vom Edge DHCP-Server empfangen
    Die virtuellen Maschinen können zwar das Edge Gateway anpingen, aber kein DHCP-Ping von einem Edge Gateway-Trunk über ein Overlay-Netzwerk empfangen. Der Edge DHCP-Server ist als Trunk-Port eingerichtet und kann keine Daten durchlassen bzw. empfangen. Wenn sich das Edge-Gateway und das DHCP Edge jedoch auf demselben Host befinden, können sie sich gegenseitig anpingen. Wenn das DHCP Edge auf einen anderen Host verschoben wird, kann das DHCP Edge kein Ping vom Edge Gateway empfangen.

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • Statistiken des Edge-Load Balancer werden nicht ordnungsgemäß in vSphere Web Client angezeigt
    Der Load Balancer zeigt nicht die Statistik zur Anzahl der gleichzeitigen Verbindungen im Diagramm in der Benutzeroberfläche von vSphere Web Client an.

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • Wenn das Direct Aggregate-Netzwerk im lokalen und im Remotesubnetz eines IPSec-VPN-Kanals entfernt wird, wird die Aggregate-Route zu den indirekten Subnetzen des Peer-Edge ebenfalls nicht mehr angezeigt
    Wenn auf dem Edge kein Standard-Gateway vorhanden ist und Sie beim Konfigurieren von IPsec alle Direktverbindungssubnetze in lokalen Subnetzen und einige der Remotesubnetze gleichzeitig entfernen, sind die verbleibenden Peer-Subnetze für IPsec-VPN nicht mehr erreichbar.

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • Nach dem Upgrade auf NSX 6.1.2 oder höher kann der Datenverkehr nicht über den Load Balancer übertragen werden
    Bei Verwendung der Option „‚X-Forwarded-For‘ einfügen“ auf dem NSX Edge-Load Balancer wird der Datenverkehr möglicherweise nicht über den Load Balancer weitergeleitet.

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • Beim Ausführen des Befehls 'clear ip ospf neighbor' wird ein Segmentierungsfehler zurückgegeben

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • Kerberos-Anfrage kann nicht verarbeitet werden
    Bestimmte Kerberos-Anfragen schlagen fehl, wenn sie mit einem NSX Edge verteilt werden.

    Dieses Problem wurde in NSX 6.2.0 behoben.

Behobene Probleme bei Sicherheitsdiensten

  • Die Umbenennung eines vorhanden Firewallentwurf kann nicht durchgeführt werden und es wird die Fehlermeldung „Interner Serverfehler“ angezeigt

    Dieses Problem wurde in NSX 6.2.1 behoben.

  • Einige zentrale DFW-Befehlszeilenschnittstellen (CLIs) zeigen „FEHLER-Ausgabe 100“ an
    In einigen Fällen kann es vorkommen, dass die vNIC-Statusinformationen (Virtual Network Adapter, Virtueller Netzwerkadapter) im NSX Manager nicht mit jenen des Hosts übereinstimmen, wenn ein virtueller Netzwerkadapter getrennt wurde. Es wird dann die Meldung „FEHLER-Ausgabe 100“ in der zentralen CLI angezeigt.

    Dieses Problem wurde in NSX 6.2.1 behoben.

  • Die Liste der Anwendungsprofile ist nicht sortiert.
    Die Liste der Namen der Anwendungsprofile in NSX Edge ist bei aktivierter Service Insertion nicht geordnet. Dies wurde in dieser Version behoben. Die Liste der Namen der Anwendungsprofile erscheint nun sortiert.

    Dieses Problem wurde in NSX 6.2.1 behoben.

  • Zentrale CLI-Befehle, die für einen spezifischen ESXi-Host ausgeführt werden, verursachen bei manchen Setups eine Zeitüberschreitung.

    Dieses Problem wurde in NSX 6.2.1 behoben.

  • Die Datei „vsfwd.log“ wird schnell mit vielen Container-Updates überschrieben
    Nach dem Ändern der SpoofGuard-Richtlinie sendet der NSX Manager sofort die Änderung an den Host. Der Host benötigt jedoch länger, um die Änderung zu verarbeiten und den SpoofGuard-Zustand der virtuellen Maschine zu ändern.

    Dieses Problem wurde in NSX 6.2.0 behoben.

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

    Dieses Problem wurde in NSX 6.2.0 behoben.

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

    Dieses Problem wurde in NSX 6.2.0 behoben.

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

    Dieses Problem wurde in NSX 6.2.0 behoben.

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

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • Die Firewallregeln berücksichtigen nicht die neu hinzugefügte virtuelle Maschine
    Nach dem Hinzufügen neuer VMs zum logischen Switch werden die Firewallregeln nicht richtig aktualisiert, um die neu hinzugefügten VMs zu berücksichtigen. Wenn Sie Änderungen an der Firewall vornehmen und die Änderungen veröffentlichen, werden die neuen Objekte der Richtlinie hinzugefügt.

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • Beim Konfigurieren von Sicherheitsgruppen können keine Active Directory-Objekte ausgewählt werden
    In NSX 6.1.x benötigen AD- bzw. LDAP-Domänenobjekte sehr lange, bis sie im Auswahlbildschirm "Sicherheitsgruppenobjekte" erneut angezeigt werden.

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • Es kann keine Firewallregel mit Quelle/Ziel als mehrere kommagetrennte IP-Adressen hinzugefügt werden

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • Der NSX Distributed Firewall (DFW)-Abschnitt kann nicht an den Anfang der Liste verschoben werden
    Beim Verwenden von Service Composer zum Erstellen einer Sicherheitsgruppenrichtlinie kann der in der DFW-Tabelle erstellte Abschnitt am Anfang der Liste nicht hinzugefügt werden. Der DFW-Abschnitt kann nicht nach oben oder unten verschoben werden.

    Dieses Problem wurde in NSX 6.2.0 behoben.

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

    Dieses Problem wurde in NSX 6.2.0 behoben.

Behobene Probleme bei Überwachungsdiensten

  • Bei der Anzeige der Flow-Statistiken werden Index 0 (eingehende Bytes) und Index 1 (ausgehende Bytes) manchmal vertauscht.
    Index 0 enthält den Zähler für den Datenverkehr in der Ursprungsrichtung und Index 1 umfasst den Zähler für den Datenverkehr in der umgekehrten Richtung.

    Dieses Problem wurde in NSX 6.2.1 behoben.

  • Der Befehl #show interface zeigt nicht die Bandbreite/Geschwindigkeit der vNic_0-Schnittstelle an
    Nach dem Ausführen des Befehls „#show interface“ wird die Vollduplex-Geschwindigkeit „0 M/s“ angezeigt, aber nicht die Bandbreite/Geschwindigkeit der Schnittstelle von NSX Edge vNic_0.

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • 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

    Dieses Problem wurde in NSX 6.2.0 behoben.
  • Verweigert/Sperren-Ereignisse können nicht durch das IPFix-Protokoll verarbeitet werden
    In der Regel ist der vsfwd-Benutzerprozess für die Flow-Erfassung zuständig, einschließlich der gelöschten/verweigerten Flows, und verarbeitet die Flows für IPFix. Dies geschieht, wenn der IPFix Collector die Verweigert/Sperren-Ereignisse nicht sieht, weil die vSIP-Warteschlange für zu verwerfende Pakete entweder zu klein ist oder durch inaktive Flow-Ereignisse eingehüllt ist. In dieser Version ist die Funktion zum Senden von Verweigert/Sperren-Ereignissen unter Verwendung des IPFIX-Protokolls implementiert.

    Dieses Problem wurde in NSX 6.2.0 behoben.

Behobene Probleme bei der Lösungsinteroperabilität

  • Das Organisationsnetzwerk kann nicht eingerichtet werden
    Beim Versuch, ein organisationsweites Netzwerk einzurichten, schlägt vCloud Director mit einer Fehlermeldung fehl.

    Dieses Problem wurde in NSX 6.2.0 behoben.

  • Mit dem VIO-Setup können nicht mehrere VMs gestartet werden
    Benutzer von VMware Integrated OpenStack konnten weder zahlreiche VMs starten noch viele Firewallregeln in einem kurzen Zeitraum veröffentlichen. Dies führte zu Meldungen wie etwa Fehler beim Veröffentlichen des IP für vnic im Protokoll.

    Dieses Problem wurde in NSX 6.2.0 behoben.

Die folgenden Probleme wurden in den Versionen 6.1.5 und 6.2.1 behoben.

Behobene Probleme gliedern sich wie folgt:

Allgemeine behobene Probleme

  • 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 und NSX 6.2.1 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 und NSX 6.2.1 behoben.

Behobene Installations- und Upgrade-Probleme

  • 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 der NSX Manager nicht mit der Guest Introspection-USVM (Universal Service Virtual Machine) kommunizieren. Durch die fehlende Kommunikation zwischen NSX Manager und Guest Introspection kommt es zu einem Wegfall des Schutzes für VMs im NSX-Cluster, wenn Änderungen an den VMs vorgenommen werden, wie beispielsweise das Hinzufügen von VMs, vMotions oder durch Löschen von VMs. Auf der Registerkarte Dienstbereitstellungen für die NSX-Installation wird die aktuelle Guest Introspection-Version angezeigt. Ist dieses Problem vorhanden, wird eine Warnung in der Spalte „Dienststatus“ angezeigt. Die Warnung enthält eine Liste der betroffenen Hosts sowie die Fehlermeldung Guest Introspection nicht bereit.

    Problemumgehung: Um dieses Problem zu beheben, führen Sie das in der Dokumentation zum NSX-Upgrade beschriebene Verfahren für das Guest Introspection-Upgrade durch.

    Dieses Problem wurde in NSX 6.1.5 und NSX 6.2.1 behoben.

Behobene Probleme beim NSX Manager

  • 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 und NSX 6.2.1 behoben.

  • Die Registrierung von NSX Manager 6.1.4 bei vCenter scheitert mit einer Meldung, dass der NSX Management Service-Vorgang fehlgeschlagen ist

    Dieses Problem wurde in NSX 6.1.5 und NSX 6.2.1 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 und NSX 6.2.1 behoben.

Behobene Probleme bei logischen Netzwerken

  • 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 und NSX 6.2.1 behoben.

Behobene Probleme bei Netzwerk- und Edge-Diensten

  • Für das NSX Edge-Dienst-Gateway (ESG) konfigurierte OSPF-Weiterleitungen werden im logischen Router (DLR) nicht berücksichtigt und die betroffenen Pakete werden gelöscht
    Dieses Problem tritt auf, wenn für OSPF die IP_HDRINCL-Option verwendet wird. Bei bestimmten Linux-Kernel verhindert diese Option, dass der IP-Stapel die Pakete fragmentiert. Dadurch werden alle Pakete, die größer als die maximale Übertragungseinheit (MTU) der Schnittstelle sind, gelöscht.

    Dieses Problem wurde in NSX 6.1.5 und NSX 6.2.1 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.1 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 und NSX 6.2.1 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 und NSX 6.2.1 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 und NSX 6.2.1 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.1 behoben.

Behobene Probleme bei Sicherheitsdiensten

  • Bei NSX for vSphere 6.x-Controllern wird die Verbindung immer wieder unterbrochen
    Aufgrund eines IPSEC-Fehlers im mit Version 6.1.4 und früheren Versionen ausgelieferten StrongSWAN-Paket wurden nach der erneuten Schlüsselerstellung für IPSEC die Tunnel zwischen den Controllern nicht eingerichtet. Dies führte teilweise zu Verbindungsfehlern zwischen den Controllern und nachfolgend zu verschiedenen Problemen. Weitere Informationen finden Sie im Knowledgebase-Artikel 2127655.

    Dieses Problem wurde in NSX 6.1.5 und 6.2.1 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 und NSX 6.2.1 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 und NSX 6.2.1 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 und NSX 6.2.1 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 und NSX 6.2.1 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 NSX 6.2.1 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 und NSX 6.2.1 behoben.

Behobene Probleme bei der Lösungsinteroperabilität

  • Das Kopieren einer VM über vCloud Connector scheitert, wenn die Route über den NSX-Load-Balancer verläuft

    Dieses Problem wurde in NSX 6.1.5 und NSX 6.2.1 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 und NSX 6.2.1 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 und NSX 6.2.1 behoben.

Revisionsverlauf der Dokumente

20. August 2015: Erste Auflage für NSX 6.2.0.
4. September 2015: Zweite Auflage für NSX 6.2.0. Nicht benötigte Upgrade-Warnung wurde entfernt.
17. Dezember 2015 Erste Auflage für NSX 6.2.1.
27. Februar 2016: Zweite Auflage für NSX 6.2.1. Die NSX-Log Insight-Kompatibilität wurde geklärt.
20. Mai 2016 Dritte Auflage für NSX 6.2.2. Bekannte Einschränkungen für ein Upgrade von 6.1.x