Versionshinweise zu VMware NSX for vSphere 6.2.4

|

Dokument aktualisiert: 28. November 2016
VMware NSX for vSphere 6.2.4   |   Freigegeben am 25. August 2016   |   Build 4292526

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.4, 6.2.3, 6.2.2, 6.2.1 und 6.2.0.

Informationen dazu finden Sie unter Wichtige Informationen zu NSX 6.2.3.

Neu in 6.2.4

Die Version 6.2.4 umfasst die nachfolgend dargestellte neue Funktion. Es auch einige Fehlerkorrekturen enthalten, die im Abschnitt Behobene Probleme dokumentiert wurden, sowie Korrekturen der im Abschnitt Wichtige Informationen zu NSX for vSphere 6.2.3 beschriebenen Probleme.

Änderungen in NSX for vSphere 6.2.4:

  • Änderungen der Firewallstatus-API (GET /api/4.0/firewall/globalroot-0/status)
    • Die Status-API für die Firewall wurde erweitert und umfasst jetzt auch den Status von Objekt-Updates, die in Firewallregeln verwendet werden: Die Status-API für die Firewall zeigt für jeden Regelsatz eine Generierungsnummer (generationNumber) an, mit der überprüft werden kann, ob eine Änderung an den Regelsätzen an einen Host weitergegeben wurde. In 6.2.4 wurde der Status-API eine Generierungsnummer für Objekte (generationNumberObjects) hinzugefügt. Damit können Sie feststellen, ob eine Änderung von Objekten, die in Firewallregeln verwendet werden, an einen Host weitergegeben wurde. Beachten Sie, dass sich die Objektgenerierungsnummer häufig ändern kann. Sie ist aber immer gleich groß oder größer als die Regelsatzgenerierungsnummer.
    • Hosts und Cluster, die nicht in die Firewall einbezogen sind, werden von der Ausgabe ausgeschlossen: Cluster (und Hosts in den Clustern) sind nicht mehr in der Statusausgabe enthalten, wenn die verteilte Firewall auf Clusterebene deaktiviert oder der Cluster nicht vorbereitet ist (keine installierten NSX-VIBs). In früheren Versionen von NSX waren diese Cluster und Hosts in der Ausgabe enthalten. Da sie jedoch nicht für die Firewall konfiguriert sind, erhalten sie nach einer Regelveröffentlichung für die Firewall den Status inprogress.

Wichtige Informationen zu NSX for vSphere 6.2.3

VMware bietet VMware NSX for vSphere 6.2.4 jetzt zum Download an. VMware NSX 6.2.4 korrigiert Fehler aus NSX 6.2.3 und liefert einen Sicherheits-Patch für die kritische Sicherheitslücke CVE-2016-2079 bei der Eingabevalidierung in Sites, die NSX SSL VPN verwenden.

Kunden, die SSL VPN verwenden, empfiehlt VMware dringend die Beachtung von CVE-2016-2079 sowie ein Upgrade auf NSX 6.2.4.
Kunden, bei denen NSX 6.2.3 oder 6.2.3a installiert ist, empfiehlt VMware die Installation von NSX 6.2.4, um wichtige Fehlerkorrekturen durchzuführen.

Neu in 6.2.3

Die Version 6.2.3 umfasst einen Sicherheits-Patch für CVE-2016-2079. Bei CVE-2016-2079 handelt es sich um eine kritische Sicherheitslücke bei der Eingabevalidierung in Sites, die NSX SSL VPN verwenden. Die Version enthält auch Fehlerkorrekturen, die im Abschnitt Behobene Probleme dokumentiert sind.

Änderungen in NSX for vSphere 6.2.3:

  • Logische Switches und Routing

    • Integration von NSX-Hardware-Schicht 2 Gateway: Erweiterung der physischen Konnektivität durch Integration von Hardware-Gateway-Switches von Drittanbietern in das logische Netzwerk

    • Neuer VXLAN-Port 4789 in NSX 6.2.3 und höher: Vor der Version 6.2.3 lautete die Standard-VXLAN-UDP-Portnummer 8472. Im Upgrade-Handbuch für NSX finden Sie dazu weitere Informationen.

  • Netzwerk- und Edge-Dienste

    • Neue Optionen für Edge DHCP: Die DHCP-Option 121 unterstützt die Option für statische Routen, die von DHCP-Servern zur Veröffentlichung statischer Routen verwendet wird. Die DHCP-Optionen 66, 67, 150 unterstützen DHCP-Optionen für PXE Boot. Die DHCP-Option 26 unterstützt die Konfiguration der DHCP-Client-Netzwerkschnittstelle MTU durch DHCP-Server.

    • Erhöhung in DHCP-Pools, Grenzwerte für statische Bindungen: Im Folgenden sind die neuen Grenzwerte für verschiedene Formfaktoren aufgeführt: Kompakt: 2048; Groß: 4096; Quad Large: 4096; und X-Large: 8192.

    • Edge-Firewall mit zusätzlichem SYN-Flood-Schutz: Durch Aktivierung des SYN-Flood-Schutzes für den Transit-Datenverkehr können Dienstunterbrechungen vermieden werden. Die Funktion ist standardmäßig deaktiviert und kann mit der NSX-REST-API aktiviert werden.

    • NSX Edge – Failover auf Abruf: Ermöglicht Benutzern die Initiierung eines Failover auf Abruf, wenn notwendig.

    • NSX Edge – Standardarbeitsspeicher für Quad Large NSX Edge: Gestiegen von 1 GB auf 2 GB.

    • NSX Edge – Reservierung von Ressourcen: Während der Erstellung wird CPU-Leistung/Arbeitsspeicher für NSX Edge reserviert. Die reservierte CPU/der reservierte Arbeitsspeicher basiert auf dem Formfaktor der Edge-Appliance. Sie können mithilfe dieser API die Standardprozentwerte für die Reservierung von CPU- und Arbeitsspeicherressourcen ändern. Durch Festlegung eines Prozentwertes von null für CPU/Arbeitsspeicher kann die Ressourcenreservierung jeweils deaktiviert werden.

      PUT https://<NSXManager>/api/4.0/edgePublish/tuningConfiguration

                  <tuningConfiguration>
                     <lockUpdatesOnEdge>false</lockUpdatesOnEdge>
                     <aggregatePublishing>true</aggregatePublishing>
                     <edgeVMHealthCheckIntervalInMin>0</edgeVMHealthCheckIntervalInMin>
                     <healthCheckCommandTimeoutInMs>120000</healthCheckCommandTimeoutInMs>
                     <maxParallelVixCallsForHealthCheck>25</maxParallelVixCallsForHealthCheck>
                     <publishingTimeoutInMs>1200000</publishingTimeoutInMs>
                     <edgeVCpuReservationPercentage>0</edgeVCpuReservationPercentage>
                     <edgeMemoryReservationPercentage>0</edgeMemoryReservationPercentage>
                     <megaHertzPerVCpu>1000</megaHertzPerVCpu>
                  </tuningConfiguration>
                

    • Änderung des Upgrade-Verhaltens für NSX Edge: Es werden Ersetzungs-VMs von NSX Edge vor dem Upgrade bzw. vor der erneuten Bereitstellung bereitgestellt. Der Host muss für das Upgrade oder für die erneute Bereitstellung eines Edge HA-Paars über ausreichend Ressourcen für vier NSX Edge-VMs verfügen. Der Standardwert für die Zeitüberschreitung bei TCP-Verbindungen wurde von bisher 3600 Sekunden auf 21600 Sekunden erhöht.

    • Cross-VC NSX – Upgrade für Universal Distributed Logical Router (UDLR): Automatisches Upgrade für den Universal DLR auf dem sekundären NSX Manager nach dem Upgrade des primären NSX Manager.

    • Flexible Regelerstellung für SNAT/DNAT: vnicId wird nicht mehr als Eingabeparameter benötigt. Die DNAT-Adresse muss nicht mehr die Adresse einer NSX Edge-vNIC sein.

    • Die NSX Edge-VM (ESG, DLR) zeigt jetzt sowohl den aktuellen wie den gewünschten Standort an. NSX Manager- und NSX APIs inklusive GET api/4.0/edges/ /appliances geben jetzt configuredResourcePool und configuredDataStore zusätzlich zum aktuellen Standort zurück.

    • Edge-Firewall mit zusätzlichem SYN-Flood-Schutz: Durch Aktivierung des SYN-Flood-Schutzes für den Transit-Datenverkehr können Dienstunterbrechungen vermieden werden. Die Funktion ist standardmäßig deaktiviert und kann mit der NSX-REST-API aktiviert werden.

    • NSX Manager zeigt den Namen des ESXi-Hosts an, auf dem die VM-Serie-Firewall-SVM von Drittanbietern ausgeführt wird, um die operative Handhabung in großen Umgebungen zu verbessern.

    • Die NAT-Regel kann jetzt nicht nur für eine IP-Adresse, sondern auch für eine vNIC-Schnittstelle angewendet werden.

    • Neue Konfigurationsoptionen zur Festlegung der Ablaufzeit einer Sitzung des Lastenausgleichsdiensts: Diese Version bietet eine neue Anwendungsregel, mit der das Limit für die Ablaufzeit der Sitzung für Server und Client festgelegt werden kann. Wenn der Pool von mehreren virtuellen Servern gleichzeitig verwendet wird, wird dafür der maximale Wert festgelegt.

    • NSX API gibt von nun an standardmäßig eine XML-Ausgabe zurück, wenn kein Header vom Typ „Accept“ angegeben wird: Wenn ab NSX 6.2.3 in einem REST API-Aufruf kein Header vom Typ „Accept:“ angegeben wird, lautet die Standardformatierung von NSX API-Rückgabewerten XML. Zuvor hatte die NSX API standardmäßig eine JSON-formierte Ausgabe zurückgegeben. Um eine JSON-formatierte Ausgabe zu erhalten, muss der API-Benutzer beim Aufrufen der Funktion den Ausdruck „application/json“ im Header vom Typ „Accept:“ explizit festlegen.

    • Neue NSX API für die Änderung der Einstellung zur automatischen Speicherung von Entwürfen für die Distributed Firewall von NSX: Ab der Version NSX 6.2.3 kann mit der folgenden PUT-API die Einstellung zur automatischen Speicherung von Entwürfen für die Distributed Firewall von NSX geändert werden:

      • Rufen Sie die vorhandene globale Konfiguration (GlobalConfiguration) ab:
        GET https://NSX-Manager-IP-Address/api/4.0/firewall/config/globalconfiguration
      • Anmerkung: GET zeigt nicht das Feld autoDraftDisabled an.

      • Fügen Sie der globalen Konfiguration die Konfigurationseigenschaft autoDraftDisabled hinzu und führen Sie einen PUT-API-Aufruf durch:
        PUT https://NSX-Manager-IP-Address/api/4.0/firewall/config/globalconfiguration
      • Anforderungstext:
          <globalConfiguration>
            <layer3RuleOptimize>...</layer3RuleOptimize>
            <layer2RuleOptimize>...</layer2RuleOptimize>
            <tcpStrictOption>...</tcpStrictOption>
            <autoDraftDisabled>true</autoDraftDisabled>
        </globalConfiguration>
          

  • Sicherheitsdienste

    • Distributed Firewall – TFTP ALG: Ermöglicht Anwendungsfälle wie etwa einen Netzwerkstart für VMs.

    • Firewall – Detaillierter Regelfilter: Vereinfacht die Fehlerbehebung durch Bereitstellung detaillierter Regelfilter über die Benutzeroberfläche auf der Basis von Quelle, Ziel, Aktion, Aktiviert/Deaktiviert, Protokollierung, Name, Kommentare, Regel-ID, Tag, Dienst, Protokoll.

    • Guest Introspection – Unterstützung von Windows 10

    • SSL VPN Client – Unterstützung von Mac OS El Capitan

    • Service Composer – Leistungsverbesserungen: Ermöglicht einen schnelleren Start/Neustart von NSX Manager durch Optimierung der Synchronisierung der Sicherheitsrichtlinie mit dem Firewalldienst und durch standardmäßige Deaktivierung der automatischen Speicherung von Firewallentwürfen.

    • Service Composer – Statusalarme: Löst Systemalarme aus, wenn die Sicherheitsrichtlinie nicht synchronisiert ist, und führt bestimmte Aktionen zur Behebung von Problemen auf der Basis der Alarmcodes aus.

    • Verringerte Heapspeicherauslastung durch Firewall: Um die Auslastung des Heapspeichers zu verringern, wurde die Verwendung von IP-Adressen-Sets durch die Firewall optimiert.

  • Operationen und Fehlerbehebung

    • NSX-Dashboard: Vereinfachte Fehlerbehebung durch Darstellung des allgemeinen Systemzustands von NSX-Komponenten in einer zentralen Ansicht.

    • Traceflow-Erweiterung – Netzwerk-Introspektionsdienste: Erweiterte Möglichkeiten zur Nachverfolgung eines Pakets von der Quelle bis zum Ziel durch Ermittlung, ob Pakete an Netzwerk-Introspektionsdienste von Drittanbietern weitergeleitet werden und ob das Paket von der Dienst-VM eines Drittanbieters zurückkommt.

    • SNMP-Unterstützung: Möglichkeit der Konfiguration von SNMP-Traps für Ereignisse von NSX Manager, NSX Controller und Edge.

    • Standardmäßige Aktivierung der Protokollierung für SSL VPN und L2 VPN. Die Standardprotokollierungsebene ist „Hinweis“.

    • Die Protokollierung für IPSec-VPN ist jetzt standardmäßig aktiviert. Als standardmäßige Protokollierungsebene ist „Warnung“ eingestellt. Wenn Sie die Protokollierung deaktivieren oder die Protokollierungsebene ändern möchten, finden Sie entsprechende Erläuterungen im Abschnitt „Aktivieren der Protokollierung für ein IPSec-VPN“ im Administratorhandbuch für NSX.

    • In der Benutzeroberfläche für Firewall-Regeln werden jetzt konfigurierte IP-Protokolle und TCP/UDP-Portnummern angezeigt, die Diensten zugeordnet sind.

    • Die Tech-Support-Protokolle für NSX Edge wurden erweitert und dokumentieren nun die Nutzung des Arbeitsspeichers für jeden Vorgang.

    • Erweiterte Überwachung des Kommunikationskanalstatus mit neuen Ereignisprotokollmeldungen, die generiert werden, wenn sich der Kommunikationskanalstatus für einen Server oder einen Kanal ändert.
    • Erweiterungen für die zentrale Befehlszeilenschnittstelle (CLI)

      • Zentrale Befehlszeilenschnittstelle (CLI) für den Hostsystemzustand: Anzeige des Hostsystemzustands mit mehr als 30 Überprüfungen in einem Befehl (inklusive Netzwerkkonfiguration, VXLAN-Konfiguration, Ressourcennutzung, etc.)

      • Zentrale Befehlszeilenschnittstelle (CLI) für die Paketerfassung: Erfassung von Paketen auf dem Host und Übertragung der Erfassungsdatei auf den Remote-Server des Benutzers. Dadurch benötigen Netzwerkadministratoren keinen Hypervisor-Zugriff mehr, wenn sie Probleme von logischen Netzwerken beheben müssen.

    • Tech-Support-Paket für jeden einzelnen Host: Erfassung von Protokollen pro Host und Erstellen eines Pakets, das gespeichert und an den Technischen Support von VMware zur Unterstützung weitergeleitet werden kann.

  • Lizenzerweiterungen

    • Änderung der Standardlizenz und der Verteilung des Auswertungsschlüssels: Die Standardlizenz nach der Installation ist „NSX für vShield Endpoint“, mit der die Verwendung von NSX zur Bereitstellung und Verwaltung von vShield Endpoint nur für das Abladen des Virenschutzes aktiviert werden kann. Auswertungslizenzschlüssel können vom VMware-Vertrieb angefordert werden.

    • Dokumentation der Lizenznutzung: Die Anzahl der verwendeten NSX-Lizenzen wird in der Benutzeroberfläche „Übersicht“ von NSX Manager angezeigt und kann über die API abgerufen werden. Die Anzahl der verwendeten NSX-Lizenzen wird nicht mehr über den vCenter-Lizenzdienst dokumentiert.

  • Erweiterungen für Load Balancer (LB)

    • Konfigurierbare Sitzungszeitüberschreitung für VIP ohne konfigurierte Beschleunigung: Möglichkeit der Konfiguration der VIP-Zeitüberschreitung für die Load-Balancing-L7-Engine (ohne aktivierte Beschleunigung) mit mehr als fünf Minuten mithilfe der Anwendungsregel „timeout client 3600s“ (Zeitüberschreitung für Client 3600 Sekunden).

    • Statistikverbesserungen für die CLI: Es sind nun über die CLI globale Statistiken verfügbar. Außerdem stehen Ihnen spezielle VIP- und Poolstatistiken zur Verfügung.

    • LB mit erweiterter Beschleunigung: Die Load-Balancing-L4-Engine (mit aktivierter Beschleunigung) berücksichtigt nun immer die Systemstatusprüfungen von UDP- und TCP-Quell-IP-Hash und setzt persistente Einträge außer Kraft.

    • Protokollverbesserungen: Es wurden die Protokolle für den Load Balancer verbessert.

    • Konfigurierbare SSL-Authentifizierung: Möglichkeit zur Konfiguration der SSL-Serverauthentifizierung bei VIPs mit End-to-End-SSL.

    • Verbesserung der Tabelle der Quell-IP-Persistenz: Auch nach der Änderung der Konfiguration ist die Tabelle der Quell-IP-Persistenz weiter verfügbar.

    • Der Parameter zur Systemsteuerung des NSX Edge-Load-Balancer (sysctl) sysctl.net.ipv4.vs.expire_nodest_conn wurde der NSX Manager-Positivliste hinzugefügt: Mit dem Parameter „sysctl.net.ipv4.vs.expire_nodest_conn“ lässt sich der persistente Verbindungsstatus ändern.

  • Lösungsinteroperabilität

    • Programm zur Verbesserung der Kundenzufriedenheit: NSX unterstützt statistische Berichtsdaten über das VMware-Programm zur Verbesserung der Benutzerfreundlichkeit (CEIP, Customer Experience Improvement Program). Die Teilnahme daran ist optional und kann im vSphere Web Client konfiguriert werden.

    • VMware vRealize Log Insight 3.3.2 for NSX bietet intelligente Protokollanalysen für NSX mit Funktionen zur Überwachung und Fehlerbehebung sowie anpassbare Dashboards für Netzwerkvirtualisierung, Flow-Analysen und Warnungen. Diese Version akzeptiert NSX-Lizenzschlüssel der Standard-/Advanced-/Enterprise-Edition für NSX 6.2.2+.​

    • Unterstützung der Verwaltung von vShield Endpoint: NSX unterstützt die Verwaltung der Antivirusfunktion von vShield Endpoint. Kunden, die vSphere mit vShield Endpoint (Essentials Plus und höher) erworben haben, können NSX von der vSphere-Download-Site herunterladen. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 2110078 und VMware-Knowledgebase-Artikel 2105558.

Neu in 6.2.2

Die Version 6.2.2 umfasst einen Sicherheits-Patch für die glibc-Sicherheitslücke und zahlreiche Fehlerkorrekturen, die im Abschnitt Behobene Probleme dokumentiert sind. Diese Version enthält dieselben wichtigen Fehlerkorrekturen, die mit allen 6.1.4-basierten und 6.1.5-basieren Patches bereitgestellt wurden. Für NSX 6.1.x-Benutzer steht derselbe Satz an Patch-Fixes in der NSX-Version 6.1.6 zur Verfügung.

Diese Version umfasst folgende wichtige Funktionen:

  • Sicherheits-Patch für CVE-2015-7547 (glibc): Dieser Patch bezieht sich auf CVE-2015-7547, auch bekannt als glibc-Sicherheitslücke.

  • Problem 1600484: Entfernen von Einschränkungsvalidierungen für DHCP-Domänennamenkonfigurationen: NSX 6.2.2 bietet wieder Unterstützung für DHCP-Pools mit „.local“-Domänen. Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2144097.

  • Problem 1586149: Verbesserungen an der DFW-Benutzeroberfläche für ein besseres Benutzererlebnis In der vorhergehenden Implementierung wurde in der Tabelle zum ersten Element des Rasters gescrollt, wenn ein Benutzer eine Änderung durchgeführt hat. In der verbesserten Implementierung wird nach dem Hinzufügen einer Regel zur dieser Regel im Raster gescrollt. Jetzt wird nach einer beliebigen Aktualisierung der Rasterdaten (z. B. nach der Veröffentlichung oder Zurücksetzung von Änderungen) die vertikale Scroll-Position des Rasters beibehalten.

  • Problem 1592562: Verändertes Verhalten nach der Konfiguration eines neuen Edge-Dienstes Vor der Version 6.2.2 wurde nach der Konfiguration eines neuen Edge-Dienstes dieser standardmäßig aktiviert. In 6.2.2 wurde dieses Verhalten geändert. Jetzt ist diese Funktion nur dann standardmäßig aktiviert, wenn die aktuelle Lizenz diese unterstützt. Andernfalls ist die Funktion deaktiviert.

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.

Empfohlene Versionen, Systemanforderungen und Installation

Empfohlene Versionen und Systemanforderungen

Die folgende Tabelle listet empfohlene und erforderliche Versionen von VMware-Software auf. Diese Informationen sind auf dem Stand des Veröffentlichungsdatums dieses Dokuments. Die neuesten Empfehlungen finden Sie im VMware-Knowledgebase-Artikel 2144295.

Produkt oder Komponente Empfohlene Version mindestens
NSX for vSphere 6.2.2

Hinweis: Es gibt ein bekanntes Problem mit SSL VPN. Weitere Informationen finden Sie unter CVE-2016-2079. Kunden, die Version 6.2.2 oder niedriger verwenden, wird empfohlen, den VMware-Support umgehend um Unterstützung zu bitten.

Informationen zum Kontakt mit dem VMware-Support finden Sie unter So reichen Sie in My VMware eine Support-Anfrage ein oder So übermitteln Sie eine Support-Anfrage.

vSphere 5.5U3 oder 6.0U2

Hinweis: Es gibt ein bekanntes Problem mit Objekten in vSphere 6.0 und NSX. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 2144605 „Mehrfache VTEPs in ESXi-Hosts nach dem Neustart von vCenter Server“.

Guest Introspection Guest Introspection-basierte Funktionen in NSX sind mit bestimmten VMware Tools (VMTools)-Versionen kompatibel. Zur Aktivierung der optionalen Thin Agent Network Introspection Driver-Komponente, die im Paket mit VMware Tools erhältlich ist, ist ein Upgrade auf eine der folgenden Versionen erforderlich:
  • VMware Tools 10.0.8 und höher für die Behebung des Problems verlangsamter VMs nach dem Upgrade von VMware Tools in NSX/vCloud Networking and Security (VMware-Knowledgebase-Artikel 2144236)

  • VMware Tools 10.0.9 und höher zur Unterstützung von Windows 10

vRealize Orchestrator NSX-vRO Plugin 1.0.3 oder späteres Plugin

Installation

Anweisungen zur Installation erhalten Sie im Installationshandbuch für NSX oder im Installationshandbuch zu Cross-vCenter NSX. Eine vollständige Liste der NSX-Installationsvoraussetzungen finden Sie im Abschnitt Systemvoraussetzungen für NSX im Installationshandbuch für NSX.

Eingestellte und nicht fortgeführte Funktionalität

Warnungen zum Ende der Lebensdauer und des Supports

Informationen zu NSX- und anderen VMware-Produkten, für die demnächst ein Upgrade durchgeführt werden muss, finden Sie unter der VMware-Lebenszyklus-Produktmatrix. Für die nachfolgenden Produkte endet der Support zu folgenden Zeitpunkten:

  • Für vCloud Networking and Security gilt als Ende der Verfügbarkeit (EOA, End of Availability) und des allgemeinen Supports (EOGS, End of General Support) der 19. September 2016. (Informationen hierzu finden Sie auch im VMware-Knowledgebase-Artikel 2144733.) (Informationen hierzu finden Sie auch im VMware-Knowledgebase-Artikel 2144620.)
  • Für NSX for vSphere 6.1.x gilt als Ende der Verfügbarkeit (EOA, End of Availability) und des allgemeinen Supports (EOGS, End of General Support) der Sonntag, 15. Januar 2017. (Informationen hierzu finden Sie auch im VMware-Knowledgebase-Artikel 2144769.)
  • Ab der Version NSX 6.2.3 wird die NSX Data Security-Funktion eingestellt. In NSX 6.2.3 können Sie diese Funktion noch auf eigene Verantwortung weiter benutzen. In künftigen NSX-Versionen ist diese Funktion jedoch nicht mehr enthalten.

  • Der Web Access Terminal (WAT) wird nicht mehr unterstützt und ist in künftigen Wartungsversionen nicht enthalten. VMware empfiehlt die Verwendung des Vollzugriffs-Clients bei SSL VPN-Bereitstellungen zur Verbesserung der Sicherheit.

Nicht unterstützte Controller-Befehle werden nicht mehr angezeigt

Im CLI-Handbuch finden Sie eine vollständige Liste unterstützter Befehle. Es stehen nur diejenigen Befehle zur Verfügung, die in diesem Handbuch dokumentiert sind. Der Befehl „join control-cluster“ wird für NSX for vSphere nicht unterstützt. Informationen hierzu finden Sie auch im VMware-Knowledgebase-Artikel 2135280.

Die Unterstützung für TLS 1.0 wurde mit NSX 6.2.3 eingestellt

Im NSX-VPN und in der IPSec-Verschlüsselungssammlung wird TLS 1.0 ab NSX 6.2.3 nicht mehr unterstützt. Die Unterstützung der Verschlüsselung wurde seit der vorherigen Version in einigen Punkten geändert. Diese Änderungen sind in den nachfolgenden Tabellen aufgeführt:

Unterstützung der SSL VPN-Verschlüsselungssammlung: Änderungen in 6.2.3

6.2.2 6.2.3
TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_AES_128_GCM_SHA256
  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Unterstützung der L2 VPN-Verschlüsselungssammlung: Änderungen in 6.2.3

6.2.2 6.2.3
AES128-SHA AES128-GCM-SHA256
AES256-SHA ECDHE-RSA-AES128-GCM-SHA256
AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384
DES-CBC3-SHA NULL-SHA256
NULL-MD5 NULL-MD5

IPSec-Verschlüsselungssammlung Änderungen in 6.2.3

6.2.2 6.2.3
AES_128-HMAC_SHA1 AES_128-HMAC_SHA1
AES(12)_256-SHA1(2)_000 AES(12)_256-SHA1(2)_000
3DES(3)_000-SHA1(2)_000 3DES(3)_000-SHA1(2)_000
AES_GCM_C_160-NONE AES_GCM_C_160-NONE

Upgrade-Hinweise

  • Herabstufungen werden nicht unterstützt:

    • Führen Sie vor der Durchführung eines Upgrades immer eine Sicherung von NSX Manager durch.

    • Nach einem erfolgreichen Upgrade von NSX ist kein Downgrade von NSX möglich.

  • Für das Upgrade auf NSX 6.2.4 müssen Sie ein vollständiges NSX-Upgrade einschließlich eines Hostcluster-Upgrades durchführen (wobei die Host-VIBs auf 6.2.4 aktualisiert werden). Anweisungen hierzu erhalten Sie im Upgrade-Handbuch für NSX im Abschnitt Aktualisieren der Host-Cluster auf NSX 6.2.

  • Controller-Festplattenlayout: Neue Installationen von NSX 6.2.3 oder höher stellen NSX Controller-Appliances mit aktualisierten Festplattenpartitionen für höhere Cluster-Ausfallsicherheit bereit. In früheren Versionen beeinträchtigte der Protokollüberlauf auf der Controller-Festplatte gelegentlich die Controller-Stabilität. Zusätzlich zu den Erweiterungen der Protokollverwaltung zur Verhinderung des Überlaufs verfügt die NSX Controller-Appliance über separate Festplattenpartitionen für Daten und Protokolle zum Schutz gegen solche Ereignisse. Wenn Sie ein Upgrade auf NSX 6.2.3 oder höher durchführen, bleibt das ursprüngliche Festplattenlayout der NSX Controller-Appliances erhalten.
  • Upgrade-Pfade:

    • Upgrade-Pfad von NSX 6.x: Die VMware-Produkt-Interoperabilitätsmatrix bietet Details zu den Upgrade-Pfaden von VMware NSX. Das Upgrade für Cross-vCenter NSX wird im Upgrade-Handbuch für NSX erläutert.

    • Upgrade-Pfad von vCNS 5,5.x: Mit dem NSX-Upgrade-Paket vom 9. Juni 2016 oder später können Sie das Upgrade direkt von VMware vCloud Network and Security (vCNS) 5.5.x auf NSX 6.2.4 durchführen. Anweisungen dazu erhalten Sie im Upgrade-Handbuch für NSX im Abschnitt Upgrade von vCloud Networking and Security auf NSX. In diesem Abschnitt finden Sie auch Anleitungen für das Upgrade von vCNS 5.5.x auf NSX in einer vCloud Director-Umgebung. In einem eigenen Handbuch, dem NSX-Upgrade-Handbuch zu vShield Endpoint, wird das Upgrade von vCNS 5.5.x auf NSX 6.2.4 für den Fall erläutert, dass Sie vShield Endpoint nur zum Virenschutz verwenden.

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

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

  • Zur Überprüfung, ob Ihr Upgrade auf NSX 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.

  • Kompatibilität mit Partnerdiensten: Wenn Ihre Site VMware-Partnerdienste für Guest Introspection oder Network Introspection verwendet, müssen Sie mithilfe des VMware-Kompatibilitäts-Handbuchs vor dem Upgrade prüfen, ob der Dienst Ihres Anbieters mit dieser NSX-Version kompatibel ist.
  • 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 für Arbeitsspeicher und CPU zur Installation und zum Upgrade von NSX Manager werden im Abschnitt Systemvoraussetzungen für NSX der NSX 6.2-Dokumentation dargestellt.

  • 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.x 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. Eventuell müssen Sie auch Ihren Browser-Cache oder Ihren Browser-Verlauf löschen.

  • 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.
  • Automatisch gespeicherte Entwürfe und Service Composer: In NSX 6.2.3 und höher ist das automatische Speichern von Entwürfen standardmäßig ausgeschaltet. Diese Einstellung betrifft das automatische Speichern von Firewallregeln für die NSX Distributed Firewall. Manuell konfigurierte Einstellungen werden beim Upgrade beibehalten. Zur Vermeidung von Leistungsproblemen empfiehlt VMware die Deaktivierung der Funktion zum automatischen Speichern von Entwürfen. Sie können den folgenden API-Aufruf verwenden, um die Einstellung für das automatische Speichern von Entwürfen für die NSX Distributed Firewall zu ändern:

    1. Rufen Sie die vorhandene globale Firewall-Konfiguration (GlobalConfiguration) ab:
      GET https://NSX-Manager-IP-Address/api/4.0/firewall/config/globalconfiguration
    2. Verwenden Sie einen PUT-Aufruf, um für die Eigenschaft autoDraftDisabled in der globalen Konfiguration „true“ festzulegen.
      PUT https://NSX-Manager-IP-Address/api/4.0/firewall/config/globalconfiguration
      Mit folgendem Anforderungstext:
      <globalConfiguration>
          <layer3RuleOptimize>...</layer3RuleOptimize>
          <layer2RuleOptimize>...</layer2RuleOptimize>
          <tcpStrictOption>...</tcpStrictOption>
          <autoDraftDisabled>true</autoDraftDisabled>
      </globalConfiguration>
      

      Beachten Sie, dass mit GET nicht das Feld autoDraftDisabled angezeigt wird.
  • Host bleibt eventuell im Installationsstadium hängen: Während umfangreicher NSX-Upgrades besteht die Gefahr, dass ein Host bei der Durchführung der Installation für längere Zeit hängen bleibt. Dies kann aufgrund von Problemen bei der Deinstallation alter NSX-VIBs auftreten. In diesem Fall wird der diesem Host zugeordnete EAM-Thread in der VI Client-Aufgabenliste als „Hängend“ vermerkt.
    Problemumgehung: Melden Sie sich bei vCenter mithilfe des VI Client an. Klicken Sie mit der rechten Maustaste auf die als „Hängend“ angegebene EAM-Aufgabe und brechen Sie diese ab. Vom vSphere Web Client initiieren Sie einen „Auflösen“-Vorgang im Cluster. Für den hängenden Host wird nun eventuell „Vorgang läuft“ angezeigt. Melden Sie sich beim Host an und initiieren Sie einen Neustart, um den Abschluss des Upgrades auf diesem Host zu erzwingen.

Bekannte Probleme

Bekannte Probleme gliedern sich wie folgt:

Allgemeine bekannte Probleme

Problem 1708769: Erhöhte Latenz bei SVM (Dienst-VM) nach Snapshot in NSX

Dieses Problem tritt auf, weil durch die Ausführung eines Snapshots eines Dienst-VMs (SVM) zusätzliche Netzwerklatenz verursacht werden kann. Ein Snapshot wird mitunter durch in der Umgebung ausgeführte Sicherungsanwendungen aufgerufen.

Problemumgehung: Erläuterungen dazu finden Sie im VMware-Knowledgebase-Artikel 2146769.

Problem 1700980: Bei Sicherheitspatch CVE-2016-2775 kann ein zu langer Abfragename zu einem Segmentierungsfehler in „lwresd“ führen.

Unter NSX 6.2.4 ist BIND 9.10.4 installiert, aber die Option „lwres“ wird in named.conf nicht verwendet. Daher ist das Produkt nicht anfällig.

Problemumgehung: Da das Produkt nicht anfällig ist, ist keine Problemumgehung erforderlich.

Problem 1718726: Synchronisation des Service Composers kann nicht erzwungen werden, wenn ein Benutzer den Abschnitt „Service Composer-Richtlinie“ mithilfe von DFW REST API manuell gelöscht hat

In einer cross-vCenter NSX-Umgebung wird jeder Versuch eines Benutzers, die Synchronisation der NSX Service Composer-Konfiguration zu erzwingen, fehlschlagen, wenn es nur einen Richtlinienabschnitt gab und dieser Richtlinienabschnitt (der über den Service Composer verwaltete Richtlinienabschnitt) zu einem früheren Zeitpunkt mit einem REST API-Aufruf gelöscht wurde.

Problemumgehung: Löschen Sie den über den Service Composer verwalteten Richtlinienabschnitt nicht mit einem REST API-Aufruf. (Bitte beachten Sie, dass bereits die UI das Löschen dieses Abschnittes verhindert.)

Problem 1685375: Remote-MAC ist im VXLAN-Gateway nicht vorhanden

Remote-MAC-Adressen werden nach einem erneuten Laden des Switch nicht gesendet. In seltenen Fällen werden die OVSDB-MAC-Adresstabellen vom NSX Controller nicht wieder mit Inhalt gefüllt, wenn ein HW-VTEP-Gateway erneut gestartet wird.

Problemumgehung: Jede der im Folgenden dargestellten Problemumgehungen führt dazu, dass der Controller die OVSDB-MAC-Adresstabelle im HW-VTEP erneut mit Inhalt füllt:

  1. In einer mit dem VXLAN verbundenen VM setzen Sie die entsprechende Netzwerkschnittstelle mit den folgenden Befehlen zurück:
    • ifconfig eth1 down
    • ifconfig eth1 up
  2. Über die NSX Manager-Benutzeroberfläche trennen Sie den Hardware-VXLAN-Gateway-Port und hängen Sie diesen Port dann erneut an.

Problem 1710624: Ereignisprotokollserver von Windows 2008 wird als „TYPE“ von „WIN2K3“ hinzugefügt, falls serverType nicht im REST-API-Anforderungstext angegeben ist

Wenn Sie eine API-Anforderung für den EventLog-Server erstellen, wird der Server als „TYPE“ von „WIN2K3“ hinzugefügt. Wenn Sie den EventLog-Server nur für IDFW verwenden, funktioniert IDFW eventuell nicht korrekt.

Problemumgehung: Fügen Sie serverType zum REST-API-Anforderungstext hinzu. Beispiel:

<EventlogServer>
  <domainId>1</domainId>
  <hostName>AD_server_IP</hostName>
  <enabled>true</enabled>
  <serverType>WIN2k8</serverType>
</EventlogServer>

Problem 1716328: Entfernen eines Host im Wartungsmodus kann später zu einem Fehler in der Clustervorbereitung führen

Wenn ein Administrator einen NSX-aktivierten ESXi-Host in den Wartungsmodus versetzt und dann aus einem vorbereiteten NSX-Cluster entfernt, kann NSX die ID-Nummer des entfernten Host nicht löschen. Nachdem die Installation in diesem Zustand ist, schlägt die Clustervorbereitung für dieses Cluster fehl, wenn in einem anderen Cluster ein anderer Host mit derselben ID vorhanden ist oder dieser Host einem anderen Cluster hinzugefügt wird.

Problemumgehung: Starten Sie NSX Manager neu oder führen Sie folgende API aus, um den zusätzlichen Eintrag zu entfernen. Führen Sie einen PUT-Aufruf für folgende API-Methode durch:
https://nsx-manager-address/api/internal/firewall/updatestatus

Problem 1659043: Für Guest Introspection wird als Dienststatus „Nicht bereit“ gemeldet, wenn die Zeit für die Kommunikation von NSX Manager mit der USVM überschritten wird

Wenn die vorgesehene Kennwortänderung mit NSX Manager auf dem internen Nachrichtenbus (RabbitMQ) nicht durchgeführt werden kann, wird für die globale Guest Introspection-SVM eventuell eine Fehlermeldung in der Art „PLAIN-Anmeldung zurückgewiesen: Benutzer ‚usvm-admin-host-14‘ - ungültige Anmeldedaten“ angezeigt.

Problemumgehung: Um die Verbindung zwischen der USVM und NSX Manager wiederherzustellen, starten Sie die USVM neu oder löschen Sie diese manuell und klicken Sie dann auf die Schaltfläche „Auflösen“ in der Benutzeroberfläche von Service Composer, um eine erneute Bereitstellung der USVM nur für den betroffenen Host anzufordern.

Problem 1662842: Guest Introspection: Die Verbindung zwischen MUX und USVM wird bei dem Versuch getrennt, nicht auflösbare Windows-SIDs aufzulösen
Der Guest Introspection-Dienst befindet sich dann im Status „Warnung“, wobei der Status jedes Guest Introspection-Modul den Status „Warnung“ abwechselnd annimmt und wieder verliert. Netzwerkereignisse werden erst wieder an den NSX Manager übermittelt, wenn die Verbindung mit der Guest Introspection-VM wiederhergestellt wurde. Dies hat Auswirkungen sowohl auf Activity Monitoring als auch auf die ID-Firewall, wenn über den Guest Introspection-Pfad Anmeldeereignisse erkannt werden.

Problemumgehung: Damit Guest Introspection wieder in einen stabilen Zustand zurückkehren kann, müssen die Guest Introspection-VMs so konfiguriert sein, dass Suchvorgänge nach diesen bekannten SIDs ignoriert werden. Dazu aktualisieren Sie die Konfigurationsdatei für jede Guest Introspection-VM und starten Sie den Dienst neu. Darüber hinaus kann der Active Directory Event Log Scraper als Problemumgehung für die Erkennung von Anmeldeereignissen ID-Firewall verwendet werden.

Um SID-Suchvorgänge für nicht auflösbare SIDs zu ignorieren, führen Sie folgende Schritte durch:
  1. Melden Sie sich bei der Guest Introspection-VM an.
  2. Bearbeiten Sie die Datei /usr/local/usvmmgmt/config/ignore-sids.lst.
  3. Fügen Sie die beiden folgenden Zeilen an:
    S-1-18-1
    S-1-18-2
  4. Speichern und schließen Sie die Datei.
  5. Starten Sie den Guest Introspection-Dienst mit folgendem Befehl neu:
    rcusvm restart.

Problem 1558285: Das Löschen von Clustern von Virtual Center mithilfe von Guest Introspection führt zu einer Nullzeiger-Ausnahme
Bevor ein Cluster von Virtual Center entfernt werden kann, müssen Dienste wie Guest Introspection entfernt werden

Problemumgehung: Löschen Sie die EAM-Agency für die Dienstbereitstellung ohne zugeordneten Cluster.

Problem 1629030: Für die Befehle der zentralen CLI zur Paketerfassung (debug packet capture und show packet capture) ist vSphere 5.5U3 oder höher erforderlich
Diese Befehle werden von früheren Versionen von vSphere 5.5 nicht unterstützt.

Problemumgehung: VMware empfiehlt allen NSX-Kunden die Verwendung von vSphere 5.5U3 oder höher.

Problem 1568180: Die Funktionsliste für NSX bei der Verwendung von vCSA 5.5 (vCenter Server Appliance) ist nicht korrekt
Sie können die Funktionen einer Lizenz im vSphere Web Client durch Auswahl der Lizenz und Klicken auf Aktionen > Funktionen anzeigen darstellen. Wenn Sie ein Upgrade auf NSX 6.2.3 durchführen, wird für Ihre Lizenz ein Upgrade auf eine Enterprise-Lizenz durchgeführt, mit der alle Funktionen aktiviert werden. Wenn allerdings NSX Manager mit vCSA 5.5 (vCenter Server Appliance) registriert wird, führt die Auswahl von Funktionen anzeigen zur Darstellung der Funktionen für die Lizenz, die vor dem Upgrade verwendet wurde, und nicht für die neue Enterprise-Lizenz.

Problemumgehung: Alle Enterprise-Lizenzen umfassen die gleichen Funktionen, auch wenn sie im vSphere Web Client nicht korrekt dargestellt werden. Weitere Informationen finden Sie auf der NSX-Lizenzseite.

Problem 1477280: Es können keine Hardware-Gateway-Instanzen erstellt werden, solange kein Controller bereitgestellt ist
Die Controller müssen vor der Konfiguration von Hardware-Gateway-Instanzen bereitgestellt werden. Ohne die vorausgehende Bereitstellung von Controllern wird die Fehlermeldung „Der Vorgang konnte auf dem Controller nicht ausgeführt werden“ eingeblendet.

Problemumgehung: Keine.

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

Bekannte Installations- und Upgrade-Probleme

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

Problem 1730017: Bei Upgrades von Version 6.2.3 auf Version 6.2.4 wird für Guest Introspection keine Versionsänderung angezeigt

Da das 6.2.3 Guest Introspection-Modul der aktuellen verfügbaren Version entspricht, bleibt die Version nach einem Upgrade auf 6.2.4 unverändert. Beachten Sie, dass bei Upgrades von älteren NSX-Versionen möglicherweise eine Versionsänderung auf 6.2.4 angezeigt wird.

Problemumgehung: Dies hat keine Auswirkungen auf die Funktionen.

Problem 1685894: Von Hosts mit installierten NSX 6.2.3-VIBs auf Hosts mit VIBs älterer Versionen migrierte VMs (mit aktiviertem DRS) werden vom Netzwerk getrennt
vMotion wird für virtuelle Maschinen von einem Host, auf dem eine neuere NSX-Version (NSX VIB mit neuerer export_version) ausgeführt wird, auf einen Host mit einer älteren Version von NSX VIB nicht unterstützt.

Problemumgehung: Dies ist ein bekanntes Problem, das NSX for vSphere 6.2.4-Versionen betrifft. Weitere Informationen enthält der VMware-Knowledgebase-Artikel 2146171.

Problem 1683879: Ein Upgrade auf NSX 6.2.3 kann auf Hosts mit weniger als 8 GB Arbeitsspeicher scheitern

NSX 6.2.3 erfordert mindestens 8 GB Arbeitsspeicher auf vorbereiteten Hosts für die Ausführung von Netzwerk- und Sicherheitsdiensten. Für die Ausführung von NSX reicht der Mindestarbeitsspeicher von 4 GB für ESXi 6.0 nicht aus.

Problemumgehung: Keine.

Problem 1673626: Die Verwendung eines Aliasnamens für einen Datenbankserver zur Erstellung eines DSN kann dazu führen, dass sich die Installation von vCenter Server nicht durchführen lässt

Nach dem Upgrade von vCloud Networking and Security auf NSX wird eine Fehlermeldung angezeigt, wenn Sie versuchen, die Einstellung „tcpLoose“ in der folgenden API-Anforderung zu ändern: /api/3.0/edges.

Problemumgehung: Verwenden Sie stattdessen die Einstellung „tcpPickOngoingConnections“ im Abschnitt „globalConfig“ der API-Anforderung /api/4.0/firewall/config.

Problem 1658720: Das Aktivieren von DFW für einen bestimmten Cluster scheitert bei einem Upgrade von vCNS auf NSX, wenn auf dem Cluster VXLAN installiert und vShield App in der vCNS-Bereitstellung nicht installiert ist (oder vor dem Upgrade entfernt wurde)

Dieses Problem resultiert daraus, dass der Synchronisierungsstatus des Clusters beim Upgrade der Hosts nicht aufgerufen wird.

Problemumgehung: Starten Sie NSX Manager neu.​

Problem 1600281: Für den USVM-Installationsstatus von Guest Introspection wird in der Registerkarte „Dienstbereitstellungen“ der Wert „Fehlgeschlagen“ angegeben

Wenn der unterstützende Datenspeicher für eine globale Guest Introspection-SVM offline geschaltet wurde oder wenn auf diesen nicht zugegriffen werden kann, muss die USVM eventuell neu gestartet oder erneut bereitgestellt werden.

Problemumgehung: Starten Sie die USVM zur Wiederherstellung neu oder stellen Sie sie erneut bereit.

Problem 1660373: vCenter unterbindet das Hinzufügen eines Hosts zu vSphere Distributed Switch aufgrund einer abgelaufenen NSX-Lizenz

Bei vSphere 5.5 Update 3 und vSphere 6.0.x ist vSphere Distributed Switch in der NSX-Lizenz enthalten. Allerdings blockiert vCenter das Hinzufügen von ESXi-Hosts zu einem vSphere Distributed Switch, wenn die NSX-Lizenz abgelaufen ist.

Problemumgehung: Ihre NSX-Lizenz muss aktiv sein, damit Sie einem vSphere Distributed Switch einen Host hinzufügen können.​

Problem 1569010/1645525: Beim Upgrade von 6.1.x auf NSX for vSphere 6.2.3 auf einem System, das mit Virtual Center 5.5 verbunden ist, wird im Feld „Produkt“ des Fensters „Lizenzschlüssel zuweisen“ die NSX-Lizenz als generischer Wert von „NSX for vSphere“ und nicht als eine genauer spezifizierte Version wie z. B. „NSX for vSphere - Enterprise“ dargestellt

Problemumgehung: Keine.

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

Problem 1636916: In einer vCloud Air-Umgebung werden Edge-Firewall-Regeln mit dem Wert „Alle“ des Quellprotokolls in „TCP:Alle, UDP:Alle“ geändert, wenn für die NSX Edge-Version ein Upgrade von vCNS 5.5.x auf NSX 6.x durchgeführt wurde
Als Folge davon ist der ICMP-Datenverkehr blockiert und es treten eventuell Paketverwerfungen auf.

Problemumgehung: Vor dem Upgrade Ihrer NSX Edge-Version erstellen Sie spezifischere Edge-Firewallregeln und ersetzen Sie „Alle“ mit bestimmten Quellportwerten.

Problem 1660355: Für VMs, die von 6.1.5 auf 6.2.3 migriert wurden, wird TFTP ALG nicht unterstützt
Auch wenn der Host aktiviert ist, wird für VMs, die von 6.1.5 auf 6.2.3 migriert wurden, TFTP ALG nicht unterstützt.

Problemumgehung: Fügen Sie die VM hinzu und entfernen Sie diese von der Ausschlussliste oder starten Sie die VM neu, damit der neue 6.2.3-Filter erstellt wird, der TFTP ALG unterstützt.

Problem 1394287: Durch Hinzufügen von VMs zu einer virtuellen Leitung oder durch Entfernen daraus wird die in den vShieldApp-Regeln festgelegte IP-Adresse nicht aktualisiert
Wenn für eine vorhandene Installation der vCNS vShield App-Firewall kein Upgrade auf die NSX Distributed Firewall im erweiterten Modus durchgeführt wurde, wird für neue VMs mit Firewallregeln auf der Basis von virtuellen Leitungen die IP-Adresse nicht aktualisiert. Dadurch werden diese VMs nicht durch die NSX-Firewall geschützt. Dieses Problem tritt nur in folgenden Fällen auf:

  • Wenn Sie ein Upgrade des Manager von vCNS auf NSX durchführen, ohne in den erweiterten DFW-Modus zu wechseln.
  • Wenn Sie einem VirtualWire neue VMs mit vShield App-Regeln hinzufügen, die diese VirtualWires verwenden, verfügen diese Regeln nicht über die neue IP-Adresse, die für die neuen VMs festgelegt wurde.
  • Dadurch sind die neuen VMs nicht durch vShieldApp geschützt.

Problemumgehung: Veröffentlichen Sie diese Regel erneut, damit die neue Adresse festgelegt wird.

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

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

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

  • Es werden keine Aufgaben wie z. B. Klonen, Neukonfigurieren usw. 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

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

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

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

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

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

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

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

Problem 1487752: 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.x kann kurzzeitig den Virenschutz für VMs 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.

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

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

Problem 1284735: 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 VMware-Knowledgebase-Artikel 2117821.

Problem 1495969: Nach dem Upgrade von vCNS 5.5.4 auf NSX 6.2.x bleibt die Firewall auf der Registerkarte "Hostvorbereitung" deaktiviert
Nach dem Upgrade von vCNS 5.5.x auf NSX 6.2.x 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.

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

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

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

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

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

Problem 1463767: In einer übergreifenden vCenter-Bereitstellung befindet sich unterhalb eines lokalen Konfigurationsabschnitts möglicherweise ein globaler Konfigurationsabschnitt für die Firewall.
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.

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

Problem 1462319: 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.
Ab NSX 6.2.3 wird zusätzlich zu den NSX VIBs „esx-vsip“ und „esx-vxlan“ das dritte VIB „esx-vdpi bereitgestellt. Bei einer erfolgreichen Installation werden alle 3 VIBs angezeigt.

Problemumgehung: Keine.

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

Problem 1485862: 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).

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

Problem 1411275: vSphere Web Client zeigt die Registerkarte „Netzwerk und Sicherheit“ nach der Sicherung und Wiederherstellung in NSX for vSphere 6.2 nicht an
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.

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

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

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.

Bekannte Probleme bei NSX Manager

Problem 1696750: Beim Zuweisen einer IPv6-Adresse zu NSX Manager über PUT API ist ein Neustart erforderlich
Beim Ändern der konfigurierten Netzwerkeinstellungen für NSX Manager via https://{NSX Manager IP address}/api/1.0/appliance-management/system/network ist ein Systemneustart erforderlich. Bis zum Neustart werden die alten Einstellungen angezeigt.

Problemumgehung: Keine.

Problem 1671067: Das NSX-Plug-In wird nicht im vCenter Web Client angezeigt, wenn das ESXTOP-Plug-In ebenfalls installiert ist
Nach der Bereitstellung von NSX und einer erfolgreichen Registrierung mit vCenter wird das NSX-Plug-In im vCenter Web Client nicht angezeigt. Dieses Problem entsteht aufgrund eines Konflikts zwischen dem NSX-Plug-In und dem ESXTOP-Plug-In.

Problemumgehung: Entfernen Sie das ESXTOP-Plug-In mit den folgenden Schritten:

  1. Stellen Sie sicher, dass eine aktuelle Sicherung des vCenter-Snapshot der vCenter-VM (ohne Stilllegung) vorhanden ist
  2. Löschen Sie /usr/lib/vmware-vsphere-client/plugin-packages/esxtop-plugin
    rm -R /usr/lib/vmware-vsphere-client/plugin-packages/esxtop-plugin
  3. Löschen Sie /usr/lib/vmware-vsphere-client/server/work
    rm -R /usr/lib/vmware-vsphere-client/server/work
  4. Starten Sie den Web Client neu
    service vsphere-client restart
  5. (Optional) Stellen Sie sicher, dass der folgende Befehl keine Ausgabe ergibt: „tail -f /var/log/vmware/vsphere-client/logs/eventlog.log | grep esx“
  6. Stellen Sie sicher, dass der vCenter-Snapshot konsolidiert ist, wenn dies die bevorzugte Rollback-Option ist

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

Problem 1529178: Das Hochladen eines Server-Zertifikats, das keinen allgemeinen Namen enthält, führt zur Meldung „Interner Serverfehler“.

Wenn Sie ein Server-Zertifikat ohne einen allgemeinen Namen hochladen, wird die Meldung „Interner Serverfehler“ eingeblendet.

Problemumgehung: Verwenden Sie ein Zertifikat, das sowohl einen SubAltName als auch einen allgemeinen Namen bzw. mindestens einen allgemeinen Namen enthält

Problem 1655388: Die Benutzeroberfläche von NSX Manager 6.2.3 wird in der englischen statt in der lokalen Sprache dargestellt, wenn der IE11-/Edge-Browser im Betriebssystem Windows 10 in Japanisch, Chinesisch oder Deutsch verwendet wird.

Wenn Sie NSX Manager 6.2.3 mit dem IE11-/Edge-Browser im Betriebssystem Windows 10 in Japanisch, Chinesisch und Deutsch starten, wird die Oberfläche in englischer Sprache dargestellt.

Problemumgehung:

Führen Sie die folgenden Schritte aus:

  1. Starten Sie den Microsoft Registrierungs-Editor (regedit.exe) und wechseln Sie zu Computer > HKEY_CURRENT_USER > SOFTWARE > Microsoft > Internet Explorer > International.
  2. Ändern Sie den Wert von AcceptLanguage in die lokale Sprache. Wenn Sie beispielsweise die Benutzeroberfläche auf Deutsch darstellen möchten, ändern Sie den Wert und setzen Sie DE an die erste Position.
  3. Starten Sie den Browser neu und melden Sie sich erneut beim NSX Manager an. Die entsprechende Sprache wird dann dargestellt.

Problem 1446649/1445281: Eine Änderung der IP oder des Fingerabdrucks des sekundären NSX Manager führt zu Replikationsfehlern bei globalen Objekten in einem Cross-vCenter-Setup.

Wird die IP oder der Fingerabdruck des sekundären NSX Manager geändert, löst dies Replikationsfehler bei globalen Objekten in einem Cross-vCenter-Setup aus, da der primäre NSX Manager dann die aktuelle IP bzw. den aktuellen Fingerabdruck des sekundären NSX Manager nicht erkennt.

Problemumgehung: Wenn nach dem Klicken auf „Globaler Synchronisierungsstatus“ für ein globales Objekt eine Ausnahmemeldung wie z. B. „Peer wurde nicht authentifiziert; eingebundene Ausnahme ist javax.net.ssl.SSLPeerUniverifiedException“ eingeblendet wird, zeigt dies eine Änderung von IP/Fingerabdruck an.

Problem 1660718: Für den Status der Service Composer-Richtlinie wird in der Benutzeroberfläche „Vorgang läuft“ und in der API-Ausgabe „Ausstehend“ angezeigt

Problemumgehung: Keine.

Problem 1620491: Der Synchronisierungsstatus auf Richtlinienebene in Service Composer zeigt nicht den Veröffentlichungsstatus der Regeln einer Richtlinie an

Wenn eine Richtlinie erstellt oder geändert wird, zeigt Service Composer den Status „Erfolg“ an, der sich aber nur auf den Persistenzstatus bezieht. Dieser Status sagt nichts darüber aus, ob die Regeln auf dem Host erfolgreich bereitgestellt wurden.

Problemumgehung: Verwenden Sie die Firewall-Benutzeroberfläche zur Anzeige des Veröffentlichungsstatus.

Problem 1435996: Im CSV-Format aus NSX Manager exportierte Protokolldateien sind mit einem Zeitstempel (Zeitraum, nicht Datum/Uhrzeit) versehen.
Protokolldateien, die als CSV aus NSX Manager mit vSphere Web Client exportiert werden, werden mit einem Zeitstempel mit der Epochenzeit in Millisekunden versehen, anstatt mit der entsprechenden Zeit basierend auf der Zeitzone.

Problemumgehung: Keine.

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

Problem 1644297: Das Hinzufügen/Löschen eines DFW-Abschnitts im primären NSX erstellt zwei gespeicherte DFW-Konfigurationen auf dem sekundären NSX
In einem Cross-vCenter-Setup werden, wenn dem primären NSX Manager ein zusätzlicher globaler oder lokaler DFW-Abschnitt hinzugefügt wurde, zwei DFW-Konfigurationen auf dem sekundären NSX Manager gespeichert. Dieses Problem beeinträchtigt zwar nicht die Funktionalität, führt aber dazu, dass die Obergrenze für gespeicherte Konfigurationen schneller erreicht wird, sodass eventuell zentrale Konfigurationen überschrieben werden.

Problemumgehung: Keine.

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

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

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

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

Problem 1317814: Die Synchronisierung von Service Composer geht verloren, wenn Richtlinienänderungen durchgeführt werden, während einer der Service Manager ausgefallen ist
Werden Richtlinienänderungen durchgeführt, wenn einer von mehreren Dienst-Managern inaktiv ist, können diese Änderungen nicht durchgeführt werden und Service Composer ist nicht mehr synchronisiert.

Problemumgehung: Stellen Sie sicher, dass der Dienst-Manager reagiert und erzwingen Sie eine Synchronisierung über den Service Composer.

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

Problem 1415480: 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://<nsxmgr-ip>/api/2.0/nwfabric/configure? action=synchronize

<nwFabricFeatureConfig>
  <featureId>com.vmware.vshield.nsxmgr.messagingInfra</featureId>
  <resourceConfig>
    <resourceId>HOST/CLUSTER MOID</resourceId>
  </resourceConfig>
</nwFabricFeatureConfig>

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

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

Problem 1027066: 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äß.

Problem 1406471: Syslog zeigt den Hostnamen der gesicherten NSX Manager-Instanz im wiederhergestellten NSX Manager an
Wenn ein zweiter NSX Manager mit der gleichen IP-Adresse und einem eindeutigen Hostnamen als erster NSX Manager installiert ist, wird durch Wiederherstellung der Konfiguration der Hostname des ersten NSX Manager nach der Wiederherstellung und der Hostname des zweiten NSX Manager nach dem Neustart angezeigt.

Problemumgehung: Für den zweiten NSX Manager sollte derselbe Hostname wie für den gesicherten NSX Manager konfiguriert werden.

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

Problem 1492880: Die NSX Manager-Benutzeroberfläche wird nach dem Ändern des Kennworts über die NSX-Befehlszeilenschnittstelle nicht automatisch abgemeldet
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.

Problem 1467866: Eigenständiger NSX Manager lässt fälschlicherweise den Import der globalen Firewallkonfiguration zu
Auf einem NSX Manager, der eigenständig ausgeführt wird, können globale Firewallregeln importiert werden, auch wenn sie nicht gültig sind. Nach dem Import haben Sie keine Möglichkeit, diese Regeln über die API oder den Web Client zu löschen. Stattdessen werden diese Regeln beibehalten und als lokaler Abschnitt behandelt.

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.

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

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

Problem 1489768: Ä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

Problem 1733146: Unter bestimmten Bedingungen schlägt die Erstellung oder Änderung von LIFs für eine Universal DLR fehl, wenn keine Kontroll-VM vorhanden ist

Dieses Problem tritt bekanntermaßen unter den folgenden Umständen auf:

  • ECMP mit zwei statischen Standardrouten
  • Statische Routen mit Flag für lokalen Ausgang
Dieses Problem tritt auf, da anstelle eines Delta-Updates eine vollständige Synchronisierung angefordert wird. Dies führt zur Ablehnung doppelter Entitäten und zum Fehlschlagen des Vorgangs. Es wird möglicherweise sinngemäß die folgende Meldung angezeigt:
2016-09-22 20:18:58.080 GMT ERROR TaskFrameworkExecutor-24 NvpRestClientManagerImpl:774 - NVP API returns error: [409] Route with the same prefix and priority already exist on router dc5e541a-d7a6-4cb9-8d8a-9334a9c51127

Problemumgehung:

  1. Löschen Sie den globalen logischen Router.
  2. Stellen Sie einen neuen globalen logischen Router bereit. Aktivieren Sie den lokalen Ausgang und deaktivieren Sie das Kontrollkästchen „Edge-Appliance bereitstellen“. Konfigurieren Sie zwei Uplink-Schnittstellen und eine Standard-Gateway-IP-Adresse über den ersten Uplink. Verwenden Sie dabei die Gebietsschema-ID des primären DLR (z. B. 1111xxxx).
  3. Fügen Sie nicht die statische Route 0.0.0.0/0 mit der für die sekundäre Site verwendeten Gebietsschema-ID (z. B. 2222xxxx) hinzu.
  4. Fügen Sie die folgenden beiden statischen Routen mit der erwarteten IP-Adresse des nächsten Hops und der Gebietsschema-ID der sekundären Site (z. B. 222xxxx) hinzu.
  5. Route 1: 0.0.0.0/1
    Route 2: 128.0.0.0/1

Problem 1716545: Eine Änderung der Appliance-Größe von Edge hat keinen Einfluss auf die CPU- und Arbeitsspeicherreservierung von Standby-Edges

Die Reservierungseinstellungen werden nur der ersten Edge-VM als Teil eines HA-Paares zugewiesen.
So konfigurieren Sie dieselbe CPU-/Arbeitsspeicherreservierung für beide Edge-VMs:

  • Verwenden Sie die PUT API „https:// /api/4.0/edgePublish/tuningConfiguration“, um für beide Edge-VMs explizite Werte festzulegen.
  • oder
  • Deaktivieren und reaktivieren Sie Edge HA. Dadurch wird die zweite Edge-VM gelöscht und es wird eine neue mit den Standardreservierungen bereitgestellt.

Problemumgehung: Keine.

Problem 1717369: Bei einer Konfiguration im HA-Modus können sowohl aktive als auch Standby-Edge-VMs auf demselben Host bereitgestellt werden

Dieses Problem kommt zustande, weil bei Vorgängen zur erneuten Bereitstellung und bei Upgrade-Vorgängen keine Anti-Affinitätsregeln erstellt und automatisch auf die vSphere-Hosts angewendet werden. Bei einer HA-Aktivierung auf einem vorhandenen Edge tritt dieses Problem nicht auf. In NSX-Versionen, in denen dieses Problem behoben ist, lautet das erwartete Verhalten wie folgt:

  • Wenn vSphere HA aktiviert ist, werden bei der erneuten Bereitstellung und bei Upgrades Anti-Affinitätsregeln für Edge-VMs eines HA-Paares erstellt.
  • Wenn vSphere HA deaktiviert ist, werden keine Anti-Affinitätsregeln für Edge-VMs eines HA-Paares erstellt.

Problemumgehung: Keine.

Problem 1510724: Nach der Universal Distributed Logical Router(UDLR)-Erstellung werden die Standardrouten auf den Hosts nicht aufgefüllt

Nach einer Änderung von NSX Manager vom eigenständigen in den primären Modus zum Konfigurieren von Cross-vCenter in NSX for vSphere 6.2.x treten möglicherweise die folgenden Symptome auf:

  • Beim Erstellen eines neuen UDLR werden die Standardrouten auf der Hostinstanz nicht aufgefüllt.
  • Die Routen werden zwar auf dem UDLR-Kontroll-VM, aber nicht auf der Hostinstanz aufgefüllt.
  • Beim Ausführen des Befehls show logical-router host host-ID dlr Edge-ID route werden keine Standardrouten angezeigt.

Problemumgehung: Informationen zur Behebung dieses Problems finden Sie im VMware Knowledgebase-Artikel 2145959.

Problem 1704540: Hohes Volumen an Aktualisierungen der MAC-Lerntabelle mit NSX L2 Bridge und LACP kann dazu führen, dass nicht genügend Arbeitsspeicher verfügbar ist

Wenn eine NSX L2 Bridge eine MAC-Adresse unter einem anderen Uplink erkennt, meldet sie den Controllern über den netcpa-Prozess eine Änderung der MAC-Lerntabelle. Netzwerkumgebungen mit LACP lernen dieselbe MAC-Adresse an mehreren Schnittstellen, was zu einem sehr hohen Volumen an Tabellenaktualisierungen und zu einer potenziellen Erschöpfung des Arbeitsspeichers führt, der vom netcpa-Prozess für die Meldung benötigt wird.

Problemumgehung: Vermeiden Sie beim Verwenden von LACP das Festlegen eines flussbasierten Hashing-Algorithmus für den physischen Switch. Verankern Sie stattdessen MAC-Adressen mit denselben Uplinks oder ändern Sie die Richtlinie in Quell-MAC.

Problem 1703247: VMs verlieren ihre Netzwerkkonnektivität in NSX mit DLR HA

In einer NSX 6.2.3-Umgebung mit dynamischem Routing und mit einer mit Hochverfügbarkeit (HA) konfigurierten DLR-Kontroll-VM verlieren virtuelle Maschinen ihre Netzwerkkonnektivität, nachdem die DLR-Kontoll-VM von einem Split-Brain-Syndrom wiederhergestellt ist.

Problemumgehung: Informationen zur Behebung dieses Netzwerkproblems finden Sie im VMware Knowledgebase-Artikel 2146413.

Problem 1492547: Die Konvergenz dauert mitunter sehr lange, wenn der NSX-basierte OSPF-Area-Border-Router mit der höchsten IP-Adresse heruntergefahren oder neu gestartet wird.
Wenn ein NSSA-Area-Border-Router, der nicht über die höchste IP-Adresse verfügt, heruntergefahren oder neu gestartet wird, konvergiert der Datenverkehr schnell auf einen anderen Pfad. Wird ein NSSA-Area-Border-Router mit der höchsten IP-Adresse heruntergefahren oder neu gestartet, so nimmt die erneute Konvergenz mitunter einen Zeitraum von mehreren Minuten in Anspruch. Der OSPF-Vorgang kann manuell bereinigt werden, um die Konvergenzzeit zu verringern.

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

Problem 1542416: Der Datenpfad funktioniert nach erneuter Bereitstellung des Edge und HA-Failover bei Teilschnittstellen 5 Minuten lang nicht
Nach erneuter Bereitstellung oder HA-Failover entsteht ein fünf Minuten langer Ausfall, wenn Teilschnittstellen verwendet werden. Das Problem wurde bei Schnittstellen nicht beobachtet.

Problemumgehung: Das Problem kann nicht umgangen werden.

Problem 1706429: Kommunikationsprobleme beim Aktivieren der Hochverfügbarkeit (HA) nach der anfänglichen Bereitstellung eines logischen (verteilten) Routers können dazu führen, dass beide logischen Router-Appliances aktiv sind.
Wenn Sie einen logischen Router ohne HA bereitstellen und HA später aktivieren (durch Bereitstellen einer neuen logischen Router-Appliance) oder wenn Sie HA deaktivieren und dann wieder aktivieren, fehlt einer der logischen Router-Appliances eine verbundene Route zur HA-Schnittstelle. Dies führt dazu, dass sich beide Appliances im Zustand „aktiv“ befinden.

Problemumgehung: Trennen Sie auf der logischen Router-Appliance, der die verbundene Route zur HA-Schnittstelle fehlt, den vNIC der logischen Router-Appliance und verbinden sie ihn erneut oder starten Sie die logische Router-Appliance neu.

Problem 1461421: In der Ausgabe des Befehls „show ip bgp neighbor“ für NSX Edge wird die bisherige Anzahl an zuvor eingerichteten Verbindungen beibehalten

Mit dem Befehl „show ip bgp neighbor“ wird angezeigt, wie oft für einen bestimmten Peer die Maschine mit dem Status „BGP“ in den Status „Eingerichtet“ übergegangen ist. Die Änderung des Kennworts einer MD5-Authentifizierung führt dazu, dass die Peer-Verbindung aufgehoben und dann erneut erstellt wird, wodurch die Zählung gelöscht wird. Dieses Problem tritt nicht mit einem Edge-DLR auf.

Problemumgehung: Zum Löschen der Zählung führen Sie den Befehl „clear ip bgp neighbor“ aus.

Problem 1676085: Eine Aktivierung der Edge-HA ist nicht möglich, wenn keine Ressourcenreservierung durchgeführt werden kann

Ab der Version NSX for vSphere 6.2.3 scheitert die Aktivierung der Hochverfügbarkeit (High Availability, HA) auf einem vorhandenen Edge, wenn nicht ausreichend Ressourcen für eine zweite Edge-VM-Appliance reserviert werden können. Die Konfiguration wird auf die letzte bekannte brauchbare Konfiguration zurückgesetzt. In vorherigen Versionen wird die Edge-VM, wenn die HA nach dem Scheitern der Edge-Bereitstellung und der Ressourcenreservierung aktiviert wird, trotzdem erstellt.

Problemumgehung: Dies ist eine erwartete Änderung des Verhaltens.

Problem 1656713: Auf dem NSX Edge sind nach einem HA-Failover keine IPSec-Sicherheitsrichtlinien vorhanden. Der Datenverkehr kann nicht über den Tunnel geleitet werden.

Ein Switchover mithilfe von Standby > Aktiv ist für den über IPSec-Tunnel verlaufenden Datenverkehr nicht möglich.

Problemumgehung: Deaktivieren/aktivieren Sie IPSec nach dem NSX Edge-Switchover.

Problem 1588450: Für eine virtuelle NSX Edge-Maschine kommt es im Verlauf eines vSphere-HA-Ereignisses zu keinem Failover

Dieses Problem tritt auf, wenn die virtuelle NSX Edge-Maschine nach der Konfiguration der vSphere-Hochverfügbarkeit (High Availability, HA) konfiguriert wird. Wenn die virtuelle NSX Edge-Maschine konfiguriert ist, wird sie der ESXi-Konfiguration für das automatische Herunterfahren/Starten hinzugefügt. Die virtuelle NSX Edge-Maschine wird dann aus der Liste der durch eine vSphere-HA geschützten VMs gelöscht, wenn ein Ausschaltereignis vom ESXi-Host empfangen wird.

Problemumgehung: Erläuterungen dazu finden Sie im VMware-Knowledgebase-Artikel 2143998.

Problem 1624663: Nach dem Klicken auf „Erweitertes Debugging konfigurieren“ wird die VC-Benutzeroberfläche aktualisiert und die Änderung wird nicht beibehalten

Nach dem Klicken auf „<Spezifische Edge-ID>“ > „Konfiguration“ > „Aktion“ > „Erweitertes Debugging konfigurieren“ wird die VC-Benutzeroberfläche aktualisiert und die Änderung wird nicht beibehalten.

Problemumgehung: Wechseln Sie direkt zum Edge-Listenmenü, markieren Sie das Edge und klicken Sie auf „Aktion“ > „Erweitertes Debugging konfigurieren“, um mit den Änderungen fortzufahren.

Problem 1354824: Wenn eine Edge-VM beschädigt ist oder aus anderen Gründen wie z. B. wegen eines Stromausfalls nicht erreicht werden kann, werden Systemereignisse generiert, wenn die Systemstatusprüfung von NSX Manager scheitert

Die Registerkarte „Systemereignisse“ zeigt Ereignisse zum Status „Edge Unreachability“ (Edge nicht erreichbar) an. In der NSX Edges-Liste wird aber möglicherweise weiterhin der Status „Bereitgestellt“ dargestellt.

Problemumgehung: Verwenden Sie die API https://NSX-Manager-IP-Address/api/4.0/edges/edgeId/status mit detailedStatus=true.

Problem 1556924: Der L3-Konnektivitätsverlust mit VXLAN führt zu einem „Würde blockieren“-Fehler

Wenn die DLR-LIFs auf dem Host konfiguriert sind, der zugrunde liegende VXLAN-Layer aber nicht komplett vorbereitet wurde, kann die Konnektivität einiger DLR-LIFs beeinträchtigt sein. Einige VMs des DLR sind nicht erreichbar. Möglicherweise sind Protokolleinträge in der Art „Failed to Create VXLAN trunk status: Would block“ (VXLAN-Trunk-Status kann nicht erstellt werden: Würde blockieren) in der Datei /var/log/vmkernel.log vorhanden.

Problemumgehung: Sie können die LIFs löschen und dann erneut erstellen. Eine andere Möglichkeit ist ein Neustart der betroffenen ESXi-Hosts.

Problem 1647657: Show-Befehle auf einem ESXi-Host mit VDR stellen maximal 2000 Routen pro VDR-Instanz dar

Show-Befehle auf einem ESXi-Host mit aktiviertem VDR stellen maximal 2000 Routen pro VDR-Instanz dar, auch wenn mehr Routen ausgeführt werden. Dabei handelt es sich aber nur um ein Anzeigeproblem, d. h. der Datenpfad ist für alle Routen wie vorgesehen funktionsfähig.

Problemumgehung: Das Problem kann nicht umgangen werden.

Problem 1634215: Die Ausgabe von OSPF CLI-Befehlen gibt nicht wieder, ob das Routing deaktiviert ist.

Wenn OSPF deaktiviert ist, wird in der Ausgabe der CLI-Routing-Befehle nicht "OSPF is disabled" angezeigt. Die Ausgabe ist leer.

Problemumgehung: Der Befehl show ip ospf stellt den korrekten Status dar.

Problem 1663902: Das Umbenennen einer NSX Edge-VM unterbricht den Datenverkehr durch das Edge

Problem 1647739: Durch die erneute Bereitstellung einer Edge-VM nach einem vMotion-Vorgang wird das Edge oder die DLR-VM wieder im ursprünglichen Cluster platziert

Problemumgehung: Um die Edge-VM in einem anderen Ressourcenpool oder in einem anderen Cluster zu platzieren, konfigurieren Sie mithilfe der NSX Manager-Benutzeroberfläche den gewünschten Speicherort.

Problem 1463856: Wenn die NSX Edge-Firewall aktiviert ist, werden vorhandene TCP-Verbindungen blockiert
TCP-Verbindungen werden über die statusorientierte Edge-Firewall blockiert, wenn der anfängliche Drei-Wege-Handshake nicht erkannt wird.

Problemumgehung: Gehen Sie wie folgt vor, um solche vorhandenen Flows zu steuern. Aktivieren Sie das Flag „tcpPickOngoingConnections“ in der globalen Firewall-Konfiguration mithilfe der NSX-REST-API. Dies schaltet die Firewall vom strikten Modus in den toleranten Modus um. Aktivieren Sie dann die Firewall. Nachdem die vorhandenen Verbindungen hergestellt wurden (möglicherweise erst einige Minuten nach der Aktivierung der Firewall), können Sie das Flag „tcpPickOngoingConnections“ wieder deaktivieren, um die Firewall zurück in den strikten Modus zu versetzen. (Diese Einstellung ist dauerhaft.)

PUT /api/4.0/edges/{edgeId}/firewall/config/global

<globalConfig>
<tcpPickOngoingConnections>true</tcpPickOngoingConnections>
</globalConfig>

Problem 1374523: Erforderlicher Neustart von ESXi oder erforderliche Ausführung von [services.sh restart] nach der Installation von VXLAN VIB, um die VXLAN-Befehle mit esxcli verfügbar zu machen

Nach der Installation von VXLAN VIB müssen Sie ESXi neu starten oder den Befehl [services.sh restart] ausführen, damit die VXLAN-Befehle mit esxcli verfügbar sind.

Problemumgehung: Verwenden Sie anstelle von esxcli den Befehl localcli.

Problem 1604514: Die Bearbeitung und Konfiguration des Standard-Gateway auf einem nicht verwalteten DLR scheitert nach dem Klicken auf „Veröffentlichen“

Wenn ein Standard-Gateway einem nicht verwalteten DLR hinzugefügt wird, scheitert die Veröffentlichung mit der Fehlermeldung „Routing Distance wird nur von NSX Edge Version 6.2.0 und später mit bereitgestellten NSX Edge-VMs unterstützt“. Die Ursache dafür ist der Standardwert „1“ für Admin Distance in der Benutzeroberfläche.

Problemumgehung: Entfernen Sie den Wert „1“ für Admin Distance, der standardmäßig eingestellt ist.

Problem 1642087: Nach der Änderung des Parameters securelocaltrafficbyip in der IPSec-VPN-Erweiterung scheitert die Weiterleitung zum Zielnetzwerk

Bei der Verwendung eines NSX Edge Services Gateway tritt folgendes Problem auf:

  • Nach der Änderung des Wertes securelocaltrafficbyip in der NSX-Benutzeroberfläche (Bildschirm „IPSec-VPN bearbeiten“) auf 0 funktioniert die Weiterleitung zu einem Remotesubnetz des IPSec-VPN-Tunnels nicht mehr
  • Nach der Änderung dieses Parameters werden die korrekten Informationen für ein Remotesubnetz nicht mehr in der IP-Routing-Tabelle angezeigt

Problemumgehung: Deaktivieren Sie den IPSec-VPN-Dienst und aktivieren Sie ihn dann erneut. Anschließend prüfen Sie, ob die erwarteten Routing-Informationen in der Befehlszeilenschnittstelle (CLI) und in der Benutzeroberfläche angezeigt werden.

Problem 1606785: Der NSX Edge-Load Balancer schreibt eventuell die Meldungen der Datei nagios.log nach /var/log/partition
Die Datei nagio.log für den NSX Edge-Load Balancer wird eventuell nach /var/log/partition geschrieben, wenn die tägliche Austauschrate der Protokolle nicht ausreicht, um die Protokolle rechtzeitig zurückzusetzen.

Problemumgehung: Schreiben Sie die Meldungen der Datei Nagios.log in eine Syslog-Datei.

Problem 1525003: Die Wiederherstellung einer NSX Manager-Sicherung mit einer fehlerhaften Passphrase scheitert ohne Rückmeldung, da auf zentrale Stammordner nicht zugegriffen werden kann

Problemumgehung: Keine.

Problem 1637639: Wenn der Windows 8 SSL VPN PHAT-Client verwendet wird, wird die virtuelle IP vom IP-Pool nicht zugewiesen
Unter Windows 8 wird die virtuelle IP-Adresse nicht wie vorgesehen vom IP-Pool zugewiesen, wenn eine neue IP-Adresse vom Edge Services Gateway zugewiesen wurde oder wenn sich der IP-Pool ändert und einen anderen IP-Bereich verwendet.

Problemumgehung: Dieses Problem tritt nur unter Windows 8 auf. Um dieses Problems zu vermeiden, verwenden Sie ein anderes Windows-Betriebssystem.

Problem 1628220: DFW- oder NetX-Beobachtungen werden auf der Empfängerseite nicht angezeigt
Traceflow zeigt eventuell keine DFW- und NetX-Beobachtungen auf der Empfängerseite an, wenn der mit der Ziel-VNIC verbundene Switchport geändert wird. Dieses Problem wird für vSphere 5.5-Versionen nicht behoben. Bei vSphere 6.0 und höher tritt dieses Problem nicht auf.

Problemumgehung: vNIC muss aktiviert bleiben. Starten Sie die VM neu.

Problem 1534603: Der Dienststatus für IPSec und L2 VPN wird als ausgeschaltet angezeigt, auch wenn der Dienst nicht aktiviert ist
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. Der L2 VPN- und IPSec-Dienst wird in der Registerkarte „Einstellungen“ immer als ausgeschaltet angezeigt, bis die Seite der Benutzeroberfläche aktualisiert wird.

Problemumgehung: Aktualisieren Sie die Seite.

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

Problem 1553600: 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. Allerdings tritt beim Warten auf ein Abrufereignis eventuell eine Verzögerung bei der Anzeige der zugewiesenen IP-Adresse auf. (Der logische NSX-Router ruft regelmäßig eventuelle Änderungen der Schnittstelle ab.)

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

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

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

Problem 1498243: Distributed Logical Router gibt falschen nächsten Hop für die Standardroute an, wenn BGP-Nachbarfilter auf „DENY, ANY, OUT“ gesetzt ist
Wenn auf einem NSX Distributed Logical Router (DLR) die Option "Default Originate" aktiviert ist und der BGP-Nachbarfilter „DENY, ANY, OUT“ 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:

  • Aktion: DENY
  • Netzwerk: ANY
  • Richtung: OUT

Problemumgehung: Keine.

Problem 1471561: Die BGP/OSPF-Nachbarschaftsbeziehung wurde nicht mit direkt verbundenen Routern eingerichtet
Das dynamische Routing funktioniert mit direkt verbundenen Routern nicht wie vorgesehen, wenn ECMP-Routen für dieses direkt verbundene Netzwerk vorhanden sind.

Problemumgehung: Starten Sie Edge neu ODER löschen Sie die zugeordnete vNIC-Schnittstelle und erstellen Sie diese neu.

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

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

Problem 1498965: Edge-Syslog-Meldungen erreichen den Remote-Syslog-Server nicht
Unmittelbar nach der Bereitstellung kann der Edge-Syslog-Server die Hostnamen für alle konfigurierten Remote-Syslog-Server nicht 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.

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

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

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

Problemumgehung: Löschen Sie die VXLAN-Trunk-Konfiguration wie folgt manuell:

  1. Wechseln Sie zum vCenter-MOB (Managed Object Browser), indem Sie Folgendes in einem Browserfenster eingeben:
    https://<vc-ip>/mob?vmodl=1
  2. Klicken Sie auf Inhalt.
  3. Rufen Sie den dvsUuid-Wert wie folgt ab:
    1. Klicken Sie auf den Root-Ordner-Link (zum Beispiel „group-d1(Datacenters)“).
    2. Klicken Sie auf den Datencenternamen-Link (zum Beispiel „datacenter-1“).
    3. Klicken Sie auf den networkFolder-Link (zum Beispiel group-n6).
    4. Klicken Sie auf den DVS-Namen-Link (zum Beispiel „dvs-1“).
    5. Kopieren Sie den Wert von uuid.
  4. Klicken Sie auf DVSManager und dann auf updateOpaqueDataEx.
  5. Fügen Sie in selectionSet folgendes XML-Segment hinzu.
    <selectionSet xsi:type="DVPortSelection">
      <dvsUuid>value</dvsUuid>
      <portKey>value</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

Problem 1704661: Verlust der VM-Netzwerkverbindung mit folgendem Fehler: Failed to restore PF state: Limit exceeded
Nach einem Upgrade von NSX for vSphere 6.1.x auf 6.2.4 treten möglicherweise die folgenden Symptome auf:

  • Bei einigen virtuellen Maschinen geht die Netzwerkverbindung nach einem vMotion-Vorgang verloren.
  • In der Datei /var/log/vmkernel.log des ESXi-Hosts, auf den die Migration der virtuellen Maschine erfolgt, finden Sie sinngemäß folgende Einträge:
    • 2016-07-28T09:07:00.764Z cpu21:33397)<6>host7: libfc: Link up on port ( 0)
    • 2016-07-28T09:07:00.766Z cpu11:1294844)Vmxnet3: 15253: Using default queue delivery for vmxnet3 for port 0x2000065
    • 2016-07-28T09:07:00.767Z cpu11:1294844)PFImportState: unsupported version: 0
    • 2016-07-28T09:07:00.767Z cpu11:1294844)vsip VSIPDVFRestoreState:2059: Failed to restore PF state: Limit exceeded
    • 2016-07-28T09:07:00.767Z cpu11:1294844)WARNING: NetPort: 1579: failed to enable port 0x2000065: Failure
    • 2016-07-28T09:07:00.767Z cpu11:1294844)Vmxnet3: 16236: Port_Enable failed for port 0x2000065
  • Dieses Problem tritt wegen eines bekannten Problems mit dem VSIP-Modul auf, wo die vMotion-Unterstützung virtueller, in NSX for vSphere 6.1.x bereitgestellter Maschinen fehlerhaft ist.

Problemumgehung: Dies ist ein bekanntes Problem, das NSX for vSphere 6.2.4-Versionen betrifft. Weitere Informationen enthält der VMware-Knowledgebase-Artikel 2146171.

Problem 1732337/1724222: NSX Manager kann Firewallregeln nicht an den ESXi 6.0 P03-Host weitergeben
NSX Manager kann Firewallregeln nicht an den ESXi 6.0 P03-Host weitergeben und die NSX Edge-Systemstatusprüfung schlägt aufgrund einer geschlossenen vsfwd-Verbindung fehl. Dies ist ein bekanntes Problem, das VMware NSX for vSphere 6.2.x mit ESXi 6.0 P03 (Build 4192238) betrifft. Dieses Problem tritt auf, wenn der /dev/random-Aufruf blockiert wird. Dies wirkt sich auf den NSX-Betrieb bei der Kennwortgenerierung aus.

Problemumgehung: Wenden Sie sich an den technischen Support von VMware. Weitere Informationen enthält der VMware-Knowledgebase-Artikel 2146873.

Problem 1620460: NSX kann nicht verhindern, dass Benutzer im Regelabschnitt von Service Composer Regeln erstellen
Im vSphere Web Client kann die Schnittstelle der Firewall für Netzwerk und Sicherheit nicht verhindern, dass Benutzer im Service Composer-Regelabschnitt Regeln hinzufügen. Das Hinzufügen von Regeln über/unter dem Service Composer-Abschnitt durch die Benutzer sollte zulässig sein, jedoch nicht innerhalb dieses Abschnitts.

Problemumgehung: Verwenden Sie nicht die „+“-Schaltfläche auf globaler Regelebene, um dem Service Composer-Regelabschnitt Regeln hinzuzufügen.

Problem 1682552: Schwellenwertereignisse für CPU/Speicher/CPS für Distributed Firewall (DFW) werden nicht gemeldet
Selbst wenn für die DFW-Schwellenwerte für CPU/Speicher/CPS die entsprechende Einstellung vorgenommen wurde, werden Schwellenwertereignisse beim Überschreiten von Schwellenwerten nicht gemeldet.

Problemumgehung:

  • Melden Sie sich an den einzelnen ESXi-Hosts an und starten Sie den DFW-Steuerungskomponentenprozess über folgenden Befehl neu:
  • /etc/init.d/vShield_Stateful_Firewall restart
  • Überprüfen Sie den Status mit folgendem Befehl:
  • /etc/init.d/vShield_Stateful_Firewall status
  • Ein Ergebnis ähnlich dem folgenden wird angezeigt:
  • „vShield-Stateful-Firewall is running“

Anmerkung: Seien Sie bei der Durchführung dieses Vorgangs vorsichtig, da hierbei alle DFW-Regeln erneut an alle Filter weitergegeben werden. Bei vielen Regeln kann es etwas länger dauern, bis sie an allen Filtern erzwungen werden.

Problem 1707931: Die Reihenfolge von Distributed Firewall-Regeln ändert sich, wenn in Service Composer definierte Dienstrichtlinien vorhanden sind und wenn eine Firewallregel geändert oder mit in der Firewall-UI angewandtem Filter veröffentlicht wird
Beim Ändern der Reihenfolge, Hinzufügen oder Löschen von in Service Composer erstellten Dienstrichtlinien, nachdem unter „Networking & Security > Firewall“ ein oder mehrere Veröffentlichungsvorgänge durchgeführt wurden, ändert sich die Reihenfolge der Firewallregeln. Dies kann auch nicht beabsichtigte Folgen haben.

Problemumgehung: Die folgenden Umgehungen stehen zur Verfügung:

  • Synchronisieren Sie Service Composer-Regeln mit Firewallregeln, indem Sie auf der Registerkarte „Sicherheitsrichtlinien“ im Menü „Aktionen“ die Option „Firewallregeln synchronisieren“ auswählen.
  • Verwenden Sie Filter nur zum Festlegen eines Regelsatzes und nicht zum Aktualisieren eines Regelsatzes.
  • Führen Sie eine vollständige Veröffentlichung durch, bevor Sie einen Filter über die REST API /api/4.0/firewall/globalroot-0/config PUT oder über die Benutzeroberfläche anwenden. Aktualisieren Sie dazu mehrere Abschnitte (keine einzelnen Abschnitte), um sicherzustellen, das die globale Firewallkonfiguration geändert wird.

Problem 1717635: Der Firewallkonfigurationsvorgang schlägt fehl, wenn mehrere Cluster in einer Umgebung vorhanden sind und parallel Änderungen vorgenommen werden
Wenn in einer Umgebung mit mehreren Clustern zwei oder mehr Benutzer dauerhaft die Firewallkonfiguration in einer engen Schleife ändern, (z. B. Hinzufügen/Löschen von Abschnitten oder Regeln), schlagen einige Vorgänge fehl, und dem Benutzer wird eine API-Antwort angezeigt, die der Folgenden ähnelt:
<?xml version="1.0" encoding="UTF-8"? >
neutron-server.log.1:70282:2016-08-23 17:58:23.429 30787 ERROR vmware_nsx.plugins.nsx_v.plugin
<error>
<details> org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update; nested exception is javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update </details>
<errorCode>258
</errorCode>
</error>

Problemumgehung: Vermeiden Sie eine gleichzeitige Änderung der Firewallkonfiguration.

Problem 1717994: Status-API-Abfrage für Distributed Firewall (DFW) meldet zwischenzeitlich den internen Serverfehler 500
Wird die Status-API-Abfrage für DFW ausgeführt, während ein neuer Host einem vorbereiteten Host-Cluster hinzugefügt wird, schlägt die API-Abfrage bei einigen Versuchen mit 500 internen Serverfehlern fehl und liefert erst dann wieder die korrekte Antwort, wenn auf dem Host mit der Installation von VIBs begonnen wird.

Problemumgehung: Verwenden Sie die Status-API-Abfrage für DFW erst nach der erfolgreichen Vorbereitung des Host.

Problem 1686036: Firewallregeln können nicht hinzugefügt, bearbeitet oder entfernt werden, wenn der Standardabschnitt gelöscht wird
Wenn der Layer2- oder Layer3-Standardabschnitt gelöscht wird, kann das Veröffentlichen einer Firewallregel fehlschlagen.

Problemumgehung: Löschen Sie die Standardregel nicht. Wenn die Konfiguration mit der Standardregel als Entwurf gespeichert wurde, gehen Sie folgendermaßen vor:

  1. Löschen Sie die vollständige Firewallkonfiguration über folgenden DELETE API-Aufruf:
  2. https://<NSX Manager IP>/api/4.0/firewall/globalroot-0/config.
    Dadurch wird der Standardabschnitt für die Firewall wiederhergestellt.
  3. Laden Sie den gespeicherten Entwurf der Firewallregeln mit dem Standardabschnitt in die Firewall.

Problem 1632235: Währen der Guest Introspection-Installation wird in der Netzwerk-Dropdown-Liste nur der Eintrag „Angegeben auf dem Host“ angezeigt
Bei der Installation von Guest Introspection mit der NSX-Lizenz nur für den Virenschutz und vSphere Essential oder mit der Standardlizenz enthält die Netzwerk-Dropdown-Liste nur die vorhandene Liste der DV-Portgruppen. Diese Lizenz unterstützt nicht die DVS-Erstellung.

Problemumgehung: Vor der Installation von Guest Introspection auf einem vSphere-Host mit einer dieser Lizenzen geben Sie zuerst das Netzwerk im Fenster „Agent-VM-Einstellungen“ an.

Problem 1652155: Das Erstellen oder Migrieren von Firewallregeln mithilfe von REST-APIs kann unter bestimmten Bedingungen nicht durchgeführt werden und ergibt dann einen HTTP 404-Fehler

Das Hinzufügen oder Migrieren von Firewallregeln mithilfe von REST-APIs wird unter folgenden Bedingungen nicht unterstützt:

  • Massenerstellung von Firewallregeln, wenn „autoSaveDraft=true“ festgelegt ist.
  • Gleichzeitiges Hinzufügen von Firewallregeln in mehreren Abschnitten.

Problemumgehung: Legen Sie für den Parameter autoSaveDraft im API-Aufruf „false“ fest, wenn Firewallregeln als Massenvorgang erstellt oder migriert werden.

Problem 1509687: Für die URL-Länge werden beim Zuweisen eines einzelnen Sicherheits-Tag zu vielen VMs in einem API-Aufruf gleichzeitig bis zu 16000 Zeichen unterstützt
Ein einzelnes Sicherheits-Tag kann in einem API-Aufruf nicht einer großen Anzahl an VMs gleichzeitig zugewiesen werden, wenn die URL-Länge 16000 Zeichen übersteigt.

Problemumgehung: Zur Optimierung der Leistung weisen Sie ein Tag in einem einzelnen Aufruf nur maximal 500 VMs zu.

Problem 1662020: Eine Veröffentlichung scheitert mit der Fehlermeldung „Die letzte Veröffentlichung ist auf Host Hostnummer fehlgeschlagen“ in den Abschnitten „Allgemein“ und „Partnersicherheitsdienste“ der DFW-Benutzeroberfläche

Nach der Änderung einer Regel wird in der Benutzeroberfläche die Meldung „Die letzte Veröffentlichung ist auf Host Hostnummerfehlgeschlagen“ angezeigt. Die in der Benutzeroberfläche aufgeführten Hosts verfügen eventuell nicht über die korrekte Version der Firewallregeln, sodass es zu Sicherheitslücken und/oder zu einer Netzwerkunterbrechung kommt.

Das Problem tritt in der Regel in folgenden Fällen auf:

  • Nach dem Upgrade einer älteren auf die neueste NSX-Version.
  • Nach der Verschiebung eines Hosts aus einem Cluster und seine Verschiebung zurück in den Cluster.
  • Nach der Verschiebung eines Hosts von einem Cluster in einen anderen.

Problemumgehung: Zur Wiederherstellung müssen Sie eine Synchronisierung der betroffenen Cluster erzwingen (nur Firewall).

Problem 1481522: Die Migration von Firewallregelentwürfen von 6.1.x auf 6.2.3 wird nicht unterstützt, da die Entwürfe der beiden Versionen nicht kompatibel sind

Problemumgehung: Keine.

Problem 1491046: Die IPv4-IP-Adresse wird nicht automatisch genehmigt, wenn die SpoofGuard-Richtlinie in VMware NSX for vSphere 6.2.x auf „Vertrauen bei erster Nutzung“ (TOFU, Trust On First Use) festgelegt ist

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

Problem 1628679: Bei Verwendung einer identitätsbasierten Firewall ist die VM von entfernten Benutzern weiterhin Teil der Sicherheitsgruppe

Wenn ein Benutzer aus einer Gruppe auf dem AD-Server entfernt wird, gehört die VM, für die der Benutzer angemeldet ist, weiterhin zur Sicherheitsgruppe. Dadurch werden die Firewallrichtlinien für die VM-vNIC auf dem Hypervisor beibehalten, sodass der Benutzer über einen kompletten Zugriff auf die Dienste verfügt.

Problemumgehung: Keine. Dieses Verhalten entspricht dem Programm-Design.

Problem 1662020: In einem Cross-vCenter-Setup wird in der DFW-Benutzeroberfläche auf den Registerkarten „Allgemein“ und „Partnersicherheitsdienste“ die Fehlermeldung "Die letzte Veröffentlichung ist auf Host 10.156.221.88 fehlgeschlagen" angezeigt

Diese Fehlermeldung wird eingeblendet, wenn die zugeordnete NIC für die Regeln nicht vorhanden ist.

Problemumgehung: Keine.

Problem 1637939: MD5-Zertifikate werden für die Bereitstellung von Hardware-Gateways nicht unterstützt

Beim Bereitstellen von Hardware-Gateway-Switches als VTEPs für ein logisches Bridging von L2 VLAN zu VXLAN unterstützen die physischen Switches mindestens SHA1 SSL-Zertifikate für eine OVSDB-Verbindung zwischen dem NSX Controller und dem OVSDB-Switch.

Problemumgehung: Keine.

Problem 1637943: Der Hybrid- oder Multicast-Replikationsmodus wird für VNIs, die über eine Hardware-Gateway-Bindung verfügen, nicht unterstützt.

Hardware-Gateway-Switches unterstützen, wenn sie als VTEPs für das L2 VXLAN-zu-VLAN Bridging verwendet werden, nur den Unicast-Replikationsmodus.

Problemumgehung: Verwenden Sie nur den Unicast-Replikationsmodus.

Problem 1462027: In übergreifenden vCenter NSX-Bereitstellungen werden mehrere Versionen von gespeicherten Firewallkonfigurationen 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>

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

Problem 1557880: 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 die Quell- oder Zielfelder die Option „Beliebig“ ausgewählt werden.

Problem 1505316: NSX NetX-Regel auf Host nicht veröffentlicht, wenn ausgewählter Dienst eine Dienstgruppe ist
Beim Festlegen einer L3-Umleitungsregel auf der Registerkarte „Partnerdienste“ in DFW wird bei der Auswahl einer Dienstgruppe die Regel nicht ordnungsgemäß erstellt.

Problemumgehung: Verwenden Sie beim Erstellen der Regel einzelne Dienste anstelle einer Dienstgruppe.

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

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

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

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

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

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

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

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

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

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

Problem 1443344: Einige Versionen der Networks-VM-Serien von Drittanbietern funktionieren nicht mit den 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.

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

Bekannte Probleme bei Überwachungsdiensten

Problem 1655593: Im NSX-Dashboard wird der Status „Fehlend“ angegeben, wenn eine Anmeldung mit der Rolle „Auditor“ oder „Security Administrator“ durchgeführt wurde

Beim Aufruf des NSX-Dashboard als Auditor oder Security Administrator wird die Fehlermeldung angezeigt „Benutzer ist nicht berechtigt, auf das Objekt ... und die Funktion ... zuzugreifen. Überprüfen Sie den Geltungsbereich für den Objektzugriff und die Funktionsberechtigungen für den Benutzer.“. Beispielsweise wird für einen Auditor möglicherweise nicht der „Status von logischem Switch“ im Dashboard angezeigt.

Problemumgehung: Keine.

Probleme bei der Lösungsinteroperabilität

Problem 1568861: Die NSX Edge-Bereitstellung scheitert im Zuge jeder Edge-Bereitstellung von einer vCD-Zelle, zu welcher der VC-Listener nicht gehört

Die NSX Edge-Bereitstellung scheitert im Zuge jeder Edge-Bereitstellung von einer vCD-Zelle, zu welcher der VC-Listener nicht gehört. Darüber hinaus scheitern alle NSX Edge-Aktionen vom vCD, inklusive einer erneuten Bereitstellung.

Problemumgehung: Stellen Sie ein NSX Edge von der vCD-Zelle bereit, zu welcher der VC-Listener gehört.

Problem 1530360: Nach einem Failover für eine NSX Manager-VM wird für Site Recovery Manager (SRM) fälschlicherweise ein Zeitüberschreitungsfehler angezeigt.

Nach einem Failover für eine NSX Manager-VM wird von SRM fälschlicherweise ein Zeitüberschreitungsfehler beim Warten auf VMware Tools angezeigt. In diesem Fall wird VMware Tools tatsächlich innerhalb eines Zeitüberschreitungsintervalls von 300 Sekunden ausgeführt.

Problemumgehung: Keine.

Bekannte Probleme von NSX Controller

Problem 1516207: Controller werden eventuell isoliert, wenn die IPSec-Kommunikation für NSX-Controller-Cluster erneut aktiviert wird

Wenn für einen NSX-Controller-Cluster die unverschlüsselte Controller-zu-Controller-Kommunikation zulässig ist (IPSec ist deaktiviert) und die IPSec-basierte Kommunikation später erneut aktiviert wird, kann es vorkommen, dass ein oder mehrere Controller aufgrund eines nicht übereinstimmenden, zuvor vereinbarten Schlüssels (Pre-Shared Key, PSK) von einem Großteil des Clusters isoliert werden. In diesem Fall ist es der NSX API eventuell nicht mehr möglich, die IPSec-Einstellungen der Controller zu ändern.

Problemumgehung:

Führen Sie zur Behebung dieses Problems folgende Schritte durch:

  1. Deaktivieren Sie IPSec mithilfe der NSX API.

    PUT /2.0/vdn/controller/node

    <controllerNodeConfig>
      <ipSecEnabled>false</ipSecEnabled>
    </controllerNodeConfig>

  2. Aktivieren Sie IPsec mithilfe der NSX API erneut.

    PUT /2.0/vdn/controller/node

    <controllerNodeConfig>
      <ipSecEnabled>true</ipSecEnabled>
    </controllerNodeConfig>

Um dieses Problem zu vermeiden, beachten Sie die nachfolgenden Empfehlungen:

  • Verwenden Sie für die Deaktivierung von IPSec immer die NSX API. Die Verwendung der NSX Controller-CLI zur Deaktivierung von IPSec wird nicht unterstützt.
  • Stellen Sie immer sicher, dass alle Controller aktiv sind, bevor Sie mit der API die IPSec-Einstellung ändern.

Problem 1306408: NSX Controller-Protokolle müssen nacheinander heruntergeladen werden
NSX Controller-Protokolle können nicht alle 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.

Behobene Probleme

Erfahren Sie mehr zu behobenen Problemen in 6.2.4 oder in 6.2.3 und früher.

In NSX 6.2.4 behobene Probleme

Die behobenen Probleme in 6.2.4 gliedern sich wie folgt:

In NSX 6.2.4 behobene allgemeine Probleme

  • Behobenes Problem 1696192: NTP-Synchronisierungsprobleme im NSX Manager
    In NSX 6.2.3 wurde eine neuere fcron-Version eingeführt. Da in der Datei fcrontab keine Umgebungsvariablen definiert sind, wird die Umgebung nicht für die Ausführung von Aufträgen durch Fcron initialisiert. Mit dem Skript kann der ntpdate-Befehl nicht ermittelt werden, da $PATH leer ist. Dieses Problem wurde in NSX 6.2.4 behoben.

In NSX 6.2.4 behobene Probleme der Installation und des Upgrades

  • Behobenes Problem 1710454: HA Dead Time-Inkonsistenz zwischen neu bereitgestellten und aktualisierten DLRs
    Dieses Problem ist aufgetreten, weil die neu aktualisierte HA Dead Time der DLRs während des Upgrades explizit von 15 in 6 Sekunden geändert wird.
    Problemumgehung: Erläuterungen dazu finden Sie im VMware-Knowledgebase-Artikel 2146714. Dieses Problem wurde in NSX 6.2.4 behoben.

In NSX 6.2.4 behobene NSX Manager-Probleme

  • Behobenes Problem 1668519: Hohe Nutzung der CPU im NSX Manager
    Bei NSX Manager kann es, speziell nach einem Neustart, zu einer dauerhaft hohen CPU-Nutzung kommen, wenn der purgetask-Vorgang eine sehr große Anzahl an Job-Einträgen in der NSX Manager-Datenbank verarbeiten oder löschen muss.
    Problemumgehung: Wenden Sie sich an den technischen Support von VMware. Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2145934. Dieses Problem wurde in NSX 6.2.4 behoben.

  • Behobenes Problem 1603954: NSX Manager zeigt für die Nutzung des Arbeitsspeichers beinahe durchgehend 100% an
    Durch den Neustart von NSX fällt die Arbeitsspeichernutzung weit unter 100 %. Allerdings steigt mit der Zeit der Nutzungswert wieder auf 100 % und die Anzeige verbleibt bei diesem Wert. Dieses Problem wurde in NSX 6.2.4 behoben.

In NSX 6.2.4 behobene Probleme logischer Netzwerke

  • Behobenes Problem 1696887: VMs werden vom Netzwerk vor dem DLR (Distributed Logical Router) getrennt
    Wenn eine VM den pMac des logischen Routers als MAC-Adresse für das Standard-Gateway anstelle der generischen MAC-Adresse des logischen Routers übernimmt, wird sie vor dem logischen Router getrennt.
    Problemumgehung: Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2146293. Dieses Problem wurde in NSX 6.2.4 behoben.

In NSX 6.2.4 behobene Probleme der NSX Edge-Dienste

  • Behobenes Problem 1703913: NSX-DLR-HA-Knoten verbleiben im Split-Brain-Zustand
    In einer NSX 6.2.3-Umgebung mit dynamischem Routing und mit einer mit Hochverfügbarkeit (HA) konfigurierten DLR-Kontroll-VM können sowohl der primäre als auch der sekundäre DLR-HA-Knoten gleichzeitig in den Zustand Aktiv wechseln und in ihm verbleiben.
    Problemumgehung: Erläuterungen dazu finden Sie im VMware-Knowledgebase-Artikel 2146506. Dieses Problem wurde in NSX 6.2.4 behoben.

  • Behobenes Problem 1674721: NSX Edge lässt sich nach einem Upgrade auf NSX 6.2.3 nicht mehr verwalten
    Dieses Problem tritt auf, wenn serverSsl oder clientSsl im Load Balancer konfiguriert sind, der Verschlüsselungswert in der vorherigen Version aber auf NULL festgelegt wurde.
    Problemumgehung: Erläuterungen dazu finden Sie im VMware-Knowledgebase-Artikel 2145887. Dieses Problem wurde in NSX 6.2.4 behoben.

  • Behobenes Problem 1698389: Nach der Änderung bestimmter Routing-Konfigurationen über den vSphere Web Client ist die Routing-Konfiguration fehlerhaft
    Das Sortieren und anschließende Bearbeiten führt zu einer fehlerhaften Konfiguration, wenn BGP-Nachbarn, die Schnittstellenzuordnung für die OSPF-Area, die Route Redistribution – IP-Präfixe oder BGP-Filter geändert werden. Wenn eine große Anzahl von BGP-Nachbarn konfiguriert wird, kann das Scrollen durch die Liste und anschließende Bearbeiten zu einer fehlerhaften Konfiguration führen.
    Problemumgehung: Erläuterungen dazu finden Sie im VMware-Knowledgebase-Artikel 2146363. Dieses Problem wurde in NSX 6.2.4 behoben.

In NSX 6.2.4 behobene Probleme der Sicherheitsdienste

  • Behobenes Problem 1694483: Nach der Installation von NSX for vSphere 6.2.3 oder der Durchführung eines Upgrades auf NSX for vSphere 6.2.3 mit konfigurierter Distributed Firewall (DFW) und konfigurierten Firewall (DFW) und konfigurierten Sicherheitsgruppen (SG) kann es zu einer Unterbrechung des Datenverkehrs kommen, wenn ein vMotion-Vorgang für virtuelle Maschinen durchgeführt wird
    Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2146227. Dieses Problem wurde in NSX 6.2.4 behoben.

  • Behobenes Problem 1689356: Das Bearbeiten einer Security Group über Suchvorgänge entfernt alle Objekte aus der Security Group
    Das Bearbeiten einer Security Group durch die Suche nach einem statisch eingebundenen Mitglied, z. B. eine VM, und das anschließende Entfernen dieses Mitglieds führt dazu, dass alle statisch eingebundenen Mitglieder aus der Security Group entfernt werden. Dieses Problem wurde in NSX 6.2.4 behoben.

  • Behobenes Problem 1675694: Die Distributed Firewall verwirft Pakete, wenn dieselbe IP und derselbe Port nach einer unterbrochenen Verbindung erneut verwendet werden
    Verbindungen im halb geschlossenen Status werden nicht getrennt, sodass keine neuen Verbindungen zu dieser IP-Adresse und zu diesem Port möglich sind. Dieses Problem wurde in NSX 6.2.4 behoben.

  • Behobenes Problem 1698863: Die erneute Übertragung des ursprünglichen TFTP-Pakets in einer eingerichteten TFTP-Sitzung führt bei aktivierter Distributed Firewall eventuell zu einem violetten Diagnosebildschirm
    Dieses Problem wurde in NSX 6.2.4 behoben.

  • Behobenes Problem 1701195: Bei der Distributed Firewall tritt eine Heap-Überlastung auf
    In größeren Bereitstellungen mit hohen Konsolidierungsraten (Anzahl der pro Host bereitgestellten VMs) kann es zu einer Überlastung des Heap-Arbeitsspeichers bei der Distributed Firewall kommen, da diese in VMkernel nur über einen begrenzten Speicher (bis zu 1,5 GB auf großen Arbeitsspeicherhosts) verfügt. Dieses Problem wurde in NSX 6.2.4 behoben. Die maximale Heap-Größe wurde auf 3 GB für ESXi 6.0-Hosts erhöht, die über einen Arbeitsspeicher von 96 GB oder mehr und damit über eine höhere Konsolidierungsrate verfügen.

  • Behobenes Problem 1712698: Die Regeln für die Sicherheitsrichtlinie von Service Composer werden gelöscht, nachdem versucht wurde, die Firewallregeln für die Sicherheitsrichtlinie zu ändern
    Dieses Problem wurde in NSX 6.2.4 behoben.

In NSX 6.2.4 behobene Probleme der Überwachungsdienste

  • Behobenes Problem 1697118: Alle IPFIX-Flows werden als neue statt als aktualisierte Flows gekennzeichnet, sodass häufige Updates für den IPFIX-Collector durchgeführt werden
    Außerdem wird beim Senden aktiver Flows der konfigurierte Zeitüberschreitungswert für aktive Flows nicht berücksichtigt. Dieses Problem wurde in NSX 6.2.4 behoben.

Die folgenden Probleme wurden in den Versionen 6.2.3, 6.2.2, 6.2.1 und 6.2.0 behoben:

In 6.2.3, 6.2.2, 6.2.1 und 6.2.0 behobene Probleme gliedern sich wie folgt:

In NSX 6.2.3 und früher behobene allgemeine Probleme

  • Behobenes Problem 1644529: Sicherheits-Patch CVE-2016-2079 für die Sicherheitslücke
    Die Version 6.2.3 umfasst einen Sicherheits-Patch für CVE-2016-2079.

  • Behobenes Problem 1571156: Der Neustart von vCenter 6.0 führt eventuell zu doppelten VTEPs auf für VXLAN vorbereitete ESXi-Hosts
    Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2144605. Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1529665: Der DaaS-Dienst funktioniert nicht, da er zwei unterschiedliche VIPs verwendet (eine VIP für HTTP und eine weitere für PCoIP), die über die identische Persistenz verfügen müssen
    Dieses Problem wurde in NSX 6.2.1 behoben.
  • Behobenes Problem 1631261: Wenn IDFW für die Zusammenarbeit mit Log Scraper konfiguriert und Guest Introspection (GI) installiert wurde, funktioniert IDFW nicht mehr, wenn die GI deinstalliert wird
    Dieses Problem wurde in NSX 6.2.2 behoben.

  • Behobenes Problem 1551773: Die Dropdown-Option für die HA-vNIC des Edge Security Gateway (ESG) ist in VMware NSX for vSphere 6.2.0 immer leer
    Dieses Problem wurde in NSX 6.2.2 behoben. Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2138158.

  • Behobenes Problem 1608608: Sicherheits-Patch für die glibc-Sicherheitslücke CVE-2015-7547
    Die Version 6.2.2 umfasst einen Sicherheits-Patch für CVE-2015-7547.

  • Behobenes Problem 1480581: netcpa-Sockets sind GESCHLOSSEN, und VM kann nicht über VNIs, Subnetze, kommunizieren
    Dieses Problem wurde durch einen Fix für die für Threads unsichere Verwendung von boost::asio in vmacore behoben. Dieses Problem wurde in NSX 6.2.2 behoben. Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2137011.

  • Behobenes Problem 1583566: Keine Regelweiterleitung an Host
    Planung von Updates der DFW-Regel/IP-Liste schlug aufgrund von Ressourceneinschränkungen des Aufgaben-Frameworks in NSX Manager fehl. Die Fehlermeldung wies auf einen Fehler beim Einreihen von Aufgaben in die Warteschlange für Änderungsbenachrichtigungs-Threads hin. Dieses Problem wurde in NSX 6.2.2 behoben.

  • Behobenes Problem 1573818: Datenverkehr wird für 50 Sekunden nach HA-Failover auf ESG unterbrochen
    Dieses Problem wurde verursacht, wenn die Synchronisierung der statischen Routen zwischen den HA NSX Edge-Knoten durch NSX fehlschlug. Dieses Problem wurde in NSX 6.2.2 behoben.

  • Behobenes Problem 1570808: NSX-Load-Balancer-Problem mit IP_HASH-Systemstatusprüfung
    Wenn die Größe des ausgewählten Backend-Servers gleich 0 ist, wird beim Verwenden des Quell-IP-Hash-Algorithmus in IPVS die Antwort „Dienst nicht verfügbar“ zurückgegeben – selbst wenn Backend-Server in einwandfreiem Zustand vorhanden sind. Dieses Problem wurde in NSX 6.2.2 behoben.

  • Behobenes Problem 1564005: In NSX NetX können keine Regeln zur Umleitung von Datenverkehr auf Partnergeräte hinzugefügt werden
    Kunden konnten keine Umleitungsregeln für Datenverkehr zu ihren NetX-Regelsätzen hinzufügen. Infolgedessen konnten Kunden keinen Datenverkehr auf Partnergeräte umleiten. Dies hatte Auswirkungen auf Regeln, die IP-Adresssätze verwendeten. Die Ursache für dieses Problem war eine fehlerhafte Behandlung von IP-Bereichen in den NetX-Regeln. Dieses Problem wurde in NSX 6.2.2 behoben.

  • Behobenes Problem 1587660: NSX NetX-Fehler in DVFilterProcessSlowPathPackets
    Die Verwendung von NSX NetX ohne DFW führte zu einem Fehler in DVFilter. Die vollständige Fehlermeldung wies auf einen NetX-Fehler PF (err=11,cr2=0x10) in DVFilterProcessSlowPathPackets hin: VSIPDVFProcessSlowPathPackets: PFFilterPacket. Dieses Problem wurde in NSX 6.2.2 behoben. Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2144018.

  • Behobenes Problem 1591673: Hinzufügen von ESXi-Host zu vSphere Distributed Switch schlägt mit Lizenzfehler fehl
    Nur in NSX 6.2.1 schlug das Hinzufügen eines ESXi-Hosts zu einem vSphere Distributed Switch mit folgendem Lizenzfehler fehl: "Host IP-Adresse is not licensed for the VDS feature. Cannot add this host to dvSwitch." Einzelheiten hierzu finden Sie im VMware-Knowledgebase-Artikel 2143397. Dieses Problem wurde in NSX 6.2.2 behoben.

  • Behobenes Problem 1590563: Enterprise-Lizenzfehler nach Upgrade
    Die NSX 6.2.1-Upgrade-Routine ermöglichte ein Upgrade auf 6.2.1 ohne VMware Enterprise-Lizenz. Nach dem Upgrade war jedoch die Enterprise-Lizenz erforderlich, um NSX zu nutzen. Dieses Problem wurde in NSX 6.2.2 behoben. Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2135310.

  • Behobenes Problem 1589046: Senden von Paket an LIF ohne DHCP-Relay führt zu PSOD
    Auf dem ESXi-Host wird ein PSOD angezeigt, wenn ein DHCP-Unicast-Paket an die IP eines LIF gesendet wird, für den DHCP-Relay aktiviert sein soll, wobei aber für die tatsächlich empfangende LIF kein DHCP-Relay aktiviert ist. Dieses Problem wurde in NSX 6.2.2 behoben. Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2144314.

  • Behobenes Problem 1593436: Im VXLAN-Hybrid-Modus löst die Controller-Verbindung fälschlicherweise ein Fallback in den Multicast-Modus aus
    Dieses Problem wurde in NSX 6.2.2 behoben. Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2144457.

  • Behobenes Problem 1574995: Fehler bei DFW-Veröffentlichung
    Das Ändern und Speichern von DFW-Regeln im gefilterten Modus konnte dazu führen, dass Regeln nicht gespeichert und veröffentlicht wurden. Dieses Problem wurde in NSX 6.2.2 behoben. Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2141155.

  • Behobenes Problem 1422110: Einer der NSX Controller übergibt die Masterrolle beim Herunterfahren nicht an andere Controller
    Dieses Problem wurde in NSX 6.1.5 und NSX 6.2.1 behoben.

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

  • Behobenes Problem 1487910: 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“. Dieses Problem wurde in NSX 6.2.0 behoben.

  • Behobenes Problem 1571548: In NSX for vSphere 6.2.0 und höher wird automatisch die alte IP-Adresse des VTEP freigegeben, wenn eine VTEP-IP-Adresse direkt auf einem Host oder in einem VC geändert wird
    Dieses Problem wurde in NSX 6.2.0 behoben.

  • Behobenes Problem 1551164: Die NSX-Benutzeroberfläche wird für einige Sekunden abgeblendet dargestellt und führt zu einer Verlangsamung in NSX for vSphere 6.2.0
    Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2141919. Dieses Problem wurde in NSX 6.2.1 behoben.

  • Behobenes Problem 1545840: Die NSX-Distributed Firewall (DFW) kann auf einem Host in VMware NSX for vSphere 6.x nicht deaktiviert werden
    Informationen hierzu finden Sie ebenfalls im VMware-Knowledgebase-Artikel 2141915. Dieses Problem wurde in NSX 6.2.1 behoben.

  • Behobenes Problem 1528680: 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(KB 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.

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

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

  • Behobenes Problem 1545830: 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 Absetzen eines Ping-Befehls von einer an einen NSX-Host-Switch angefügten vmknic führt zu einem Host-PSOD-Bildschirm, wenn die Daten größer als die MTU sind. Dieses Problem wurde in NSX 6.2.1 behoben.

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

In NSX 6.2.3 und früher behobene Probleme der Installation und des Upgrades

  • Behobenes Problem 1578509: Nach einem Neustart des EAM (ESX Agent Manager) gilt für den GI (Guest Introspection)-Dienststatus der Status „Warnung“
    Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1539203: Nach einem NSX-Upgrade wird das NSX-Plug-In vom primären VC während eines Cross-vCenter-Upgrades getrennt
    Dieses Problem wurde in NSX 6.2.3 behoben.

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

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

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

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

  • Behobenes Problem 1088497: Die Guest Introspection-Installation schlägt mit einem Fehler fehl
    Beim Installieren von Guest Introspection auf einem Cluster schlägt die Installation mit dem folgenden Fehler fehl:
    Ungültiges Format für VIB-Modul. Dieses Problem wurde in NSX 6.2.0 behoben.

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

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

  • Behobenes Problem 1418836: Die AES-Verschlüsselung ist für die Ausführung einer NSX-Sicherung mithilfe einer gesicherten Drittanbieter-FTP-Sicherung nicht verfügbar Dieses Problem wurde in NSX 6.2.0 behoben.

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

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

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

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

In 6.2.3 und früher behobene NSX Manager-Probleme

  • Behobenes Problem 1540187: Benutzer können sich nicht über den vSphere Web Client anmelden und das NSX-Plugin verwenden. Es wird die Fehlermeldung ausgegeben, dass der Benutzer bzw. die Gruppe keine Berechtigungen hat
    Dieses Problem hing von der Zeitüberschreitung ab, die beim Generieren eines saml-Tokens auftritt. Wenn die Anfrage bei einer Kommunikation mit dem SSO-Dienst nicht abgeschlossen wird, ist NSX manchmal nicht in der Lage, den Anbieter für Lösungsregistrierung intern zu aktualisieren. Sobald dies der Fall ist, führt jede weitere Anforderung zu einer Null-Pointer-Ausnahme.
    Dies wurde in NSX 6.2.3 durch Vermeiden der Null-Pointer-Ausnahme und Wiederherstellen der Verbindung mit dem SSO-Dienst auf Anforderung behoben.

  • Behobenes Problem 1640388: Obwohl das Deinstallieren einer Guest Introspection von einem Cluster keine VMs beinhaltet, wird die Fehlermeldung „Bereinigung vor der Deinstallation fehlgeschlagen“ angezeigt und der Status als nicht „Nicht aufgelöst“ angegeben
    Dies war ein bekanntes Problem des Deinstallationsvorgangs von Guest Introspection.
    Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1534588: Vorherige Sicherungen werden nicht in 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.
    Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1593910: Eine duplizierte NSX Manager-IP-Adresse wird nicht erkannt oder wird verhindert
    Wenn die IP-Adresse von NSX Manager einem anderen Gerät im Netzwerk zugewiesen ist, wird keine explizite Fehlermeldung und kein entsprechendes Ereignisprotokoll generiert. Als Ergebnis antworten NSX Controller und Hosts möglicherweise mit einer falschen MAC-Adresse auf NSX Manager, was zu einem Ausfall des Datenpfads führt. Problemumgehung: Ermitteln Sie das andere Netzwerkgerät und entfernen Sie es dann aus dem Netzwerk oder weisen Sie dieses Gerät einer anderen IP-Adresse zu. Aufgrund einer doppelten NSX Manager-IP im Netzwerk antworten Hosts sowie Controller mit der falschen MAC-Adresse auf NSX Manager und die VM. Dies beeinträchtigt die Kommunikation zwischen NSX Manager und ESX bzw. zwischen NSX Manager und NSX Controllern. Das kann zu einem Ausfall des Datenpfads führen. In diesem Fall sind die Anwendungen solange davon betroffen, bis die doppelte IP aus dem Netzwerk entfernt wird und die Kommunikationskanäle wiederhergestellt sind.
    Dieses Problem wurde in NSX 6.2.3 durch Hinzufügen eines Systemereignisses bei der Ermittlung einer doppelten IP-Adresse behoben.

  • Behobenes Problem 1489648: NSX ist aus dem vSphere Web Client-Plug-In nicht verfügbar, wenn eine NSX Manager-Sicherung mit einem stillgelegten Snapshot verwendet wird
    Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2142263. Dieses Problem wurde in NSX 6.2.3 behoben.

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

  • Behobenes Problem 1568861: 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 und die Konfiguration blockiert.

  • Behobenes Problem 1482989/1522092: „NSX-Netzwerk und -Sicherheit“ zeigt für alle Hosts den Status GRÜN an, der Clusterstatus wird aber fälschlich als ROT angegeben
    In NSX 6.1.4 und früher wurde unter bestimmten (seltenen) Bedingungen in der Registerkarte „NSX-Netzwerk und -Sicherheit“ für alle Hosts der Status GRÜN angezeigt, während der Clusterstatus fälschlich als ROT dargestellt wurde (der damit eine nicht vorhandene Fehlerbedingung anzeigt). Dieses Problem wurde in NSX 6.1.5 behoben.

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

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

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

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

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

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

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

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

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

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

In 6.2.3 und früher behobene logische Netzwerk- und NSX Edge-Routing-Probleme

  • Folgendes Problem behoben: Datenpfadprobleme für VNIs mit getrenntem NSX Controller
    Dieses Problem tritt auf, weil die erneute IPSec-Verschlüsselung in NSX-V 6.1.5, 6.1.6, 6.2, 6.2.1 und 6.2.2 deaktiviert ist, um ein anderes bekanntes IPSec-Problem zu vermeiden.

    Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2146973. Dieses Problem wurde in NSX 6.2.3 behoben.
  • Behobenes Problem 1591582: Für einige spezielle Bedingungen werden die von der VDR-Instanz gesendeten ARP-Anforderungen eventuell verworfen
    Die VDR-ARP-Anforderungen für Remote-VMs auf anderen Hosts werden eventuell bei der Verarbeitung der VDR-Uplink-Ausgabe verworfen und führen dann zu einem langsamen Verbindungsaufbau.

  • Behobenes Problem 1501900: Der Edge OSPF-Router verbleibt im ExchangeStart-Zustand, nachdem die IP-Adresse der OSPF-Schnittstelle geändert wurde
    Aufgrund einer Race Condition hat das Ändern der IP-Adresse einer OSPF-Schnittstelle dazu geführt, dass die OSPF-Nachbarn im ExchangeStart-Zustand verblieben. Unter normalen Umständen ist die Änderung der IP-Adresse einer OSPF-Schnittstelle ein unterstützter Vorgang.
    Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1498251: IS-IS wird nicht als Routing-Protokoll für den Edge Services Gateway-Router unterstützt
  • Die Verweise auf IS-IS wurden in NSX 6.2.3 aus der Benutzeroberfläche und aus APIs entfernt.

  • Behobenes Problem 1492738: Während der DLR(Distributed Logical Router)-Bereitstellung unter Verwendung von vSphere Web Client können nicht mehr als acht Uplink-Schnittstellen bereitgestellt werden
    Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1552038: Zeitweilige Trennung der Verbindung eines NSX Edge mit der DLR-Uplink-Schnittstelle
    Dieses Problem wird durch NSX Edge hervorgerufen, wenn in der ARP-Tabelle die MAC-Adresse der DLR-Kontroll-VM anstelle der MAC-Adresse der lokalen Instanz des DLR enthalten ist. In dieser Version wurde ein Filter für ausgehende ARPs hinzugefügt, der verhindert, dass die DLR-Kontroll-VM ARPs in Bezug auf die DLR-IP-Adresse generiert.

  • Behobenes Problem 1454161: Statische Routen mit einem nächsten Hop als /31-IP-Adresse können nicht konfiguriert werden
    Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1528443: Der VXLAN-ARP-Cache auf den Hosts wird nicht aktualisiert, wenn eine Edge-VM ein GARP im Zuge eines Failover sendet.
    Wenn sich in bestimmten Bereitstellungen die VMs und Edge im selben VXLAN-Segment befinden, wird der VXLAN-ARP-Cache auf dem Host nach einem Edge-Failover nicht aktualisiert. Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1600874: Isolierte VMs werden bei der Bereitstellung einer neuen Edge-VM nicht entfernt
    Beim Upgrade eines Edge verbleibt die ursprüngliche Edge-VM in der NSX Manager-Datenbank, wenn die Veröffentlichung und das Rollback zugleich scheitern, wobei das VC die ID-Nummer der neuen Edge-VM beibehält. Aufgrund dieses Problems scheitert die erneute Bereitstellung einer Edge-VM. Auch eine erzwungene Synchronisierung scheitert mit der Fehlermeldung „Virtuelle Maschine nicht gefunden“.

  • Behobenes Problem 1467774: Für das Feld „Admin Distance“ im Befehl „show ip bgp neighbor“ wird ein ungültiger Wert angezeigt
    Ein von einem EBGP-Peer abgerufene und für einen IBGP-Peer im selben AS angekündigte Route behält fälschlicherweise den vorherigen Admin-Distance-Wert bei. Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1613383: Für einen im L4-Modus ausgeführten NSX Edge-Load Balancer wird als Wert für die aktuellen Verbindungen fälschlicherweise die Anzahl der gesamten Verbindungen verwendet
    In dieser Version wurde das Problem durch Berechnung der Anzahl der aktuellen Verbindungen aus der Summe der aktiven Verbindungen behoben. Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1584664: Wenn VM-Mitglieder eines Load-Balancer-Pools manuell aus der vCenter-Bestandsliste ohne vorherige Aufhebung der Konfiguration in NSX entfernt werden, verbleiben die verwaisten Datenbankeinträge in der NSX Manager-Datenbank. In den NSX Manager-Protokollen ist ein Eintrag für ObjectNotFoundException enthalten
    Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1446809: NSX Edge kann nicht mehr von vCloud Director verwaltet werden, wenn kein Wiederherstellungsereignis der Systemstatusprüfung nach einem Edge-Neustart gesendet wird
    NSX Manager speichert den Edge-Konnektivitätsstatus im Arbeitsspeicher. Wenn eine Edge-VM auf eine Systemstatusprüfung nicht antwortet, wird ein Ereignis „Fehlend“ generiert und bei der Wiederherstellung ein Ereignis „Wiederhergestellt“. Wenn NSX Manager neu gestartet wird, wird das Wiederherstellungsereignis eventuell nicht gesendet, wenn keine Systemstatusprüfungen nach einem Neustart als „Fehlend“ gemeldet wurden. Da vCloud Director von diesen Ereignissen abhängt, kann ein fehlendes Wiederherstellungsereignis dazu führen, dass sich die Edge-VM von vCD aus nicht mehr verwalten lässt.

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

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

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

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

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

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

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

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

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

  • Behobenes Problem 1432420: Werden mehrere BGP-Regeln auf NSX Edge/DLR gleichzeitig entfernt, stürzt der Web Client ab. Dieses Problem wurde in NSX 6.2.0 behoben. Sie können jetzt gleichzeitig mehrere BGP-Regeln löschen.

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

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

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

In 6.2.3 und früher behobene Probleme mit den Edge-Diensten

  • Behobenes Problem 1633694: Ein Speicherfehler kann zu einem Verlust der VXLAN-Konfiguration in der NSX Manager-Datenbank führen
    Nach einem Speicherfehler meldet Virtual Center eventuell das Löschen des DVS, und NSX Manager antwortet darauf mit dem Entfernen der dem DVS zugeordneten VXLAN-Konfiguration. Ist dies der Fall, wird in den NSX Manager-Protokollen eine Meldung folgender Art generiert: „INFO DCNPool-9 VcDriver:1077 - Deleting vmknic info from host tables [host-21843 : 319]“ (]“ (INFO DCNPool-9 VcDriver:1077 - vmknic-Info wird aus den Hosttabellen gelöscht - [host-21843319]]).
    Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1456172: NAT überträgt die IP-Adressen nicht, wenn die NSX Edge-Firewall deaktiviert ist
    Wenn die Edge-Gateway-Firewall deaktiviert ist, werden alle statusorientierten Dienste ebenfalls deaktiviert, wenn das Edge-Gerät das Format 6.0 Extra Large oder 6.1 und 6.2 hat. In der Version NSX 6.2.3 wurde der Benutzeroberfläche die Warnung hinzugefügt, dass andere statusorientierte Dienste ebenfalls deaktiviert sind.

  • Behobenes Problem 1499601: Es kommt zu erweiterten HA-Failover-Zeiten für das Edge Services Gateway (ESG) oder den DLR der Edge-VM, wenn nur statische Routen verwendet werden
    Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1618289: Es tritt unvorhergesehen eine TCP-Unterbrechung bei TCP-Sitzungen während eines Edge High Availability(HA)-Failover in VMware NSX for vSphere 6.2.x auf
    Dieses Problem resultiert aus abgelaufenen internen Bibliotheken, die in VMware NSX for vSphere 6.2.x verwendet werden. Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1653484: NSX Edge-Core-Dumps zeigen keine Funktionsnamen an
    NSX 6.2.3 erweitert die Debugging-Möglichkeiten durch Darstellung der Adressinformationen des Arbeitsspeichers in der Core-Datei. Sie müssen aber Core-Dumps nur aktivieren, wenn dies vom Technischen Support von VMware angefordert wird.
    Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1604506: Wenn das Standard-Gateway für das statische Routing verwendet wird, kann der DLR ohne die NSX Edge-VM nicht bereitgestellt werden.

    Beim Bereitstellen eines neuen DLR (Distributed Logical Router) über den Web Client kann der DLR nicht erstellt werden, wenn bei der Konfiguration die Option „Standard-Gateway konfigurieren“ ausgewählt wird. Es wird dann die folgende Fehlermeldung in einem Popup-Fenster eingeblendet: „[Routing] Admin Distance wird nur von NSX Edge, Version 6.2.0 und später mit bereitgestellten NSX Edge-VMs unterstützt.“

    Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 2144551. Dieses Problem wurde in NSX 6.2.3 behoben.

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

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

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

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

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

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

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

  • Behobenes Problem 1599706: Das SYN/ACK-Paket geht bei der Kommunikation zwischen zwei VNIs über LDR verloren
    Dieses Problem wurde in NSX 6.2.2 behoben.

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

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

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

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

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

  • Behobenes Problem 1449461: Beim Ausführen des Befehls 'clear ip ospf neighbor' wird ein Segmentierungsfehler zurückgegeben
    Dieses Problem wurde in NSX 6.2.0 behoben.

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

In NSX Manager 6.2.3 und früher behobene Probleme der Sicherheitsdienste

  • Behobenes Problem 1620109: Die Bereitstellung von Drittanbieterdienst-VMs wird eventuell nicht wie vorgesehen abgeschlossen und als Installationsstatus wird „Fehlgeschlagen“ gemeldet
    So empfängt beispielsweise die SVM eventuell nicht die vorgesehene IP-Adresse. Die Fehlermeldung „Value provided for parameter property.info.key was not correct“ (Der an den Parameter property.info.key übergebene Wert ist nicht korrekt) wird in den Protokollen von NSX Manager aufgeführt.

    Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2145376. Dieses Problem wurde in NSX 6.2.3 behoben.
  • Behobenes Problem 1619570: In einer umfangreichen DFW-Konfiguration mit Millionen von Regeln und Service Composer benötigt die Regelbereitstellung eventuell einige Sekunden nach einem Neustart. In diesem Zeitraum können keine Regeln veröffentlicht werden
    In der Version NSX 6.2.3 wurde der Zeitaufwand für die Synchronisierung der Firewallregeln beim Neustart verringert, indem nur jene Firewallrichtlinien erneut synchronisiert werden, für die die letzte Revision aufgrund des Neustarts noch nicht verarbeitet wurde.

  • Behobenes Problem 1526781: Eine Abfrage der API getFirewallConfigLayer3SectionByName gibt auf NSX 6.2.x nicht das Feld responseHeaders zurück
    Dieses Problem wurde in 6.2.3 behoben und die ETag-Kopfzeileninformationen wurden in der API-Ausgabe reaktiviert.

  • Behobenes Problem 1599576: Eine bearbeitete Regel in einem globalen Firewallabschnitt wird eventuell nicht veröffentlicht, wenn im Feld „Globale Abschnitts-ID“ ein Nullwert festgelegt wurde.
    Es wird keine Fehlermeldung angezeigt. Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1558501: Die Installation von Guest Introspection lässt sich eventuell nicht durchführen, wenn die Verbindung der globalen SVM mit dem NSX Manager nicht hergestellt werden kann
    Wenn NSX Manager nur mit einem FQDN konfiguriert wurde, kann der Messaging-Kanal zwischen NSX Manager und der Guest Introspection-Dienst-VM fehlschlagen. Wenn dieses Problem auftritt, verbleibt der Status des Guest Introspection-Dienstes im Status „Warnung“. In der Datei eventmanager.log der USVM ist dann eine „UnknownHostException“-Meldung (Unbekannte Hostausnahme) enthalten. Dieses Problem wurde in NSX 6.2.3 durch Hinzufügen einer automatischen DNS-Unterstützung behoben.

  • Behobenes Problem 1673068: Die Bearbeitung von Firewallregeln im Abschnitt „Service Composer-Richtlinie“ führt dazu, dass die Konfiguration nicht synchronisiert ist
    Service Composer ist nicht mehr synchronisiert, wenn Firewallregeln im Abschnitt „Service Composer-Richtlinie“ des Bildschirms zur Firewallkonfiguration hinzugefügt oder bearbeitet wurden. Dieses Problem wurde in NSX 6.2.3 behoben, indem für den Abschnitt „Service Composer“ der Firewallkonfiguration ein Schreibschutz festgelegt wurde. Die mit Service Composer erstellten Regeln müssen mit Service Composer verwaltet werden. Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1639612: Es treten in NSX for vSphere 6.2.x MSRPC-Konnektivitätsprobleme mit Windows 2008 und höher auf
    In späteren Windows-Versionen, die eine 64-Bit-Adressierung unterstützen, wird das DCE/EPM-Protokoll NDR64 als Kodierungsformat für die Übertragung festlegt. Dies führt dazu, dass die Firewall das EPM-Antwortpaket nicht analysiert, sodass der dynamische Port, der geöffnet werden soll, nicht ermittelt werden kann. Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2145135. Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1567693: Die Verwendung von IPSet als Quelle/Ziel in einer NetX-Regel führt zum Fehler „Ungültiger Containertyp“: IPSet
    Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1407920: 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.
    Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1498504: Die VM verliert den Firewallschutz, wenn sie von einer der beiden überlappenden Dienstgruppen entfernt wird
    Vom Firewall-Workflow erstellte NetX-Filter auf dem Host werden entfernt, wenn ein anderer, durch den Service Composer-Workflow erstellter Dienst derselben VM zugeordnet wird. Dies kann beispielsweise auftreten, wenn ein Dienstprofil zwei überlappenden Dienstgruppen zugeordnet wurde. Wenn in einem solchen Fall eine VM in beiden Dienstgruppen vorhanden ist und dann aus einer entfernt wird, geht der Schutz verloren. Dieses Problem wurde in NSX 6.2.3 behoben. Dazu wurde das Feld Priorität in das Dienstprofil aufgenommen. Wenn zwei sich überlappende Dienstgruppen für eine vNIC auf einem Host vorhanden sind, wird das Dienstprofil mit der höchsten Priorität angewendet.

  • Behobenes Problem 1550370: Bei virtuellen Linux-Maschinen mit NFSv3-Bereitstellungen hängt das Betriebssystem, wenn der Upstream-Datenpfad länger als 15 Minuten ausfällt
    Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2133815. Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1494366: 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.
    Beim Kopieren einer Firewallregel mit aktivierter Option „Quelle ablehnen“ bzw. „Ziel ablehnen“ wird eine neue Firewall erstellt, bei der diese Option deaktiviert ist. Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1473767: 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. Dieses Problem wurde in NSX 6.2.3 behoben.
    Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2091376.

  • Behobenes Problem 1611238: In der 6.2.x Edge-Firewall werden nur die im Edge-Geltungsbereich erstellten Sicherheitsgruppen angezeigt (SGs im Edge-Geltungsbereich können nur mit REST angelegt werden)
    In 6.2.3 werden im globalen Geltungsbereich erstellte SGs (diese können in der Benutzeroberfläche erstellt werden) und im Edge-Geltungsbereich erstellte SGs (diese können nur über REST erstellt werden) beide in der Edge-Firewall in der Sicherheitsgruppenliste in den Spalten „Quelle“ und „Ziel“ angezeigt.
    Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1516460: Firewallregeln sind weiterhin als gültig markiert, auch wenn der logische Switch in der Regel, dem sie zugeordnet sind, gelöscht wurde
    Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1542157: Die Funktionalität der Distributed Firewall geht nach einer vMotion-Verschiebung geschützter VMs zum Zielhost verloren
    Das Entfernen eines NSX-vorbereiteten Hosts von der VC-Bestandsliste löscht den Hosteintrag in den internen Firewalltabellen. Durch das spätere erneute Hinzufügen dieses Hosts zur VC-Bestandsliste wurden die Einträge der Firewalltabellen nicht neu erstellt. Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1592439: Service Composer scheitert bei der Übertragung virtueller Maschinen in Sicherheitsgruppen
    Dieses Problem tritt aufgrund eines Deadlock in EpSecLib auf der USVM (Universal Service Virtual Machine) auf. Dieses Problem wurde in NSX 6.2.3 behoben.

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

  • Behobenes Problem 1491042: Es dauert sehr lange, bis LDAP-Domänenobjekte im Auswahlbildschirm für Sicherheitsgruppenobjekte angezeigt werden, oder sie werden dort gar nicht angezeigt. Dieses Problem wurde in NSX 6.1.5 und NSX 6.2.1 behoben.

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

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

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

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

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

  • Behobenes Problem 1545879: Die Umbenennung eines vorhandenen Firewallentwurfs kann nicht durchgeführt werden und es wird die Fehlermeldung „Interner Serverfehler“ angezeigt
    Dieses Problem wurde in NSX 6.2.1 behoben.

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

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

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

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

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

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

  • Behobenes Problem 1352926: 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. Dieses Problem wurde in NSX 6.2.0 behoben.

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

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

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

  • Behobenes Problem 1473585: Es kann keine Firewallregel mit Quelle und Ziel in der Form mehrerer kommagetrennter IP-Adressen hinzugefügt werden. Dieses Problem wurde in NSX 6.2.0 behoben.

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

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

In NSX Manager 6.2.3 und früher behobene Probleme der Überwachungsdienste

  • Behobenes Problem 1617561: Es kommt für vmkernel-Protokolldateien zu einem Überlauf mit „ALERT: vdrb: VdrArpInput:1015: CP:Malformed pkt“
    Dieser tritt auf, wenn ein Netzwerkgerät wie ein Server eine ARP-Anforderung im Format IEEE 802 Networks ARP sendet. Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1525620: Der Wert für icmpCode in einer Distributed-Firewall-Regel wurde nicht an den Host gesendet. Die Werte für protocolName und subProtocolName werden wie vorgesehen angewendet
    Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1563830: Die Anwendung einer Firewallregel in einer DLR-Appliance mit der Quelle bzw. mit dem Ziel ‚mgmtInterface‘ scheitert
    Die NSX Manager-Protokolle enthalten eine Meldung in der Art „vShield Edge:10014:Fehler bei der Konfiguration auf der NSX Edge-VM“. Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1474498: Der Import von Firewallregelentwürfen scheitert, nachdem eine vorhandene Firewallkonfiguration durch eine REST-API-Anforderung entfernt wurde
    Dieses Problem tritt auf, wenn die Entwürfe in VMware NSX for vSphere 6.1.x und 6.2.x mit section id = null erstellt wurden. Dieses Problem wurde in NSX 6.2.3 behoben.

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

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

  • Behobenes Problem 1288395: 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.
  • Behobenes Problem 1354728: 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.

In NSX Manager 6.2.3 und früher behobene Probleme der Lösungsinteroperabilität

  • Behobenes Problem 1571170: Einige Log Insight-Berichte werden in NSX 6.2 mit bestimmten Versionen des vRealize-Inhaltspakets nicht unterstützt
    Diese Probleme wurden mit der neuesten Version des Log Insight-Inhaltspakets behoben. Laden Sie das Inhaltspaket von VMware Solution Exchange herunter und installieren Sie es. Dieses Problem wurde in NSX 6.2.3 behoben.

  • Behobenes Problem 1484506: Während des ESXi-Upgrades wird der violette Diagnosebildschirm angezeigt
    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 violetten Diagnosebildschirm gestoppt. Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2137826. Dieses Problem wurde in NSX 6.2.3 behoben.

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

  • Behobenes Problem 1462006: In einer VIO-Bereitstellung können einige neu bereitgestellte VMs nicht auf das Netzwerk zugreifen, obwohl ihnen scheinbar ein gültiger Port und gültige IP-Adressen zugewiesen wurden. Dieses Problem wurde in NSX 6.1.5 und NSX 6.2.1 behoben.

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

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

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

Revisionsverlauf der Dokumente

20. August 2015: Erste Auflage für NSX 6.2.0.
17. Dezember 2015: Erste Auflage für NSX 6.2.1.
4. März 2016: Erste Auflage für NSX 6.2.2. Sicherheits-Patch für glibc-Sicherheitslücke.
9. Juni 2016 Erste Auflage für NSX 6.2.3.
25. August 2016: Erste Auflage für NSX 6.2.4.
02.September 2016: Zweite Auflage für NSX 6.2.4. Ein bekanntes Problem wurde hinzugefügt.
09.September 2016: Dritte Auflage für NSX 6.2.4. Ein bekanntes Problem wurde hinzugefügt.
23. September 2016: Vierte Auflage für NSX 6.2.4. 2 bekannte Probleme wurden behoben.
6. Oktober 2016: Fünfte Auflage für NSX 6.2.4. Bekannte Probleme wurden hinzugefügt.
16. November 2016: Sechste Auflage für NSX 6.2.4. KB hinzugefügt.
28. November 2016: Sechste Auflage für NSX 6.2.4. Änderungen zu Problem 1685894.