Versionshinweise zu VMware NSX for vSphere 6.2.6

|

Dokument aktualisiert am 21. August 2017
VMware NSX for vSphere 6.2.6   |   Freigegeben am 2. Februar 2017  |   Build 4977495

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.6, 6.2.5, 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.6

Die Version 6.2.6 enthält vor allem wichtige Fehlerkorrekturen für das Problem mit mehreren Verschlüsselungen und das OpenSSL-Upgrade. In Version 6.2.6 wird das NSX Edge OpenSSL-Paket auf 1.0.2j aktualisiert. Weitere Informationen finden Sie im Abschnitt Behobene Probleme.

Neu in 6.2.5

Die Version 6.2.5 behebt den Fehler, dass nach bestimmten vMotion-Vorgängen die Netzwerkverbindung bei Installationen getrennt wurde, bei denen auf manchen Hosts eine neuere und auf anderen Hosts eine ältere Version von NSX ausgeführt wurde. Weitere Informationen enthält der Abschnitt zu den behobenen Problemen.

Neu in 6.2.4

Die Version 6.2.4 umfasst die folgenden neuen Funktionen. Sie enthält auch einige Fehlerkorrekturen, die im Abschnitt Behobene Probleme dokumentiert sind.

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

  • Behobene kritische Probleme in NSX 6.2.3: NSX 6.2.4 umfasst einen Sicherheits-Patch für CVE-2016-2079 zur Behebung einer kritischen Sicherheitslücke 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 oder höher.

Neu in 6.2.3

Wichtige Informationen zu NSX for vSphere 6.2.3: Kunden, bei denen NSX 6.2.3 oder 6.2.3a installiert ist, empfiehlt VMware die Installation von NSX 6.2.4 oder höher, um wichtige Fehlerkorrekturen durchzuführen.

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 Mindestversionen, Systemanforderungen und Installation

Die folgende Tabelle listet mindestens empfohlene 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 Mindestversionen
NSX for vSphere

VMware empfiehlt NSX 6.2.6 für neue Bereitstellungen und NSX 6.2.2 als Mindestversion aufgrund von kritischen Fehlerkorrekturen, bei denen eine allgemeine Auswirkung auf eine NSX-Umgebung festgestellt wurde.

Für vorhandene Bereitstellungen mit einer Version vor 6.2.6 lesen Sie bitte die NSX-Versionshinweise und/oder wenden sich an einen Mitarbeiter des technischen Supports für weitere Informationen zu spezifischen Problemen, bevor Sie ein Upgrade planen.

vSphere VMware empfiehlt 5.5U3 und 6.0U3 als Mindestversionen in NSX-Umgebungen. In der VMware-Produktinteroperabilitätsmatrix finden Sie ebenfalls Informationen zur Interoperabilität.

Anmerkungen:

  • NSX 6.2.x ist nicht mit vSphere 6.5 kompatibel.
  • vSphere 6.0U3 behebt das Problem der doppelten VTEPs in ESXi-Hosts nach dem Neustart von vCenter Server. Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 2144605.
  • Für verteilte Service Insertion werden ESXi-Versionen 5.5 Patch 10 und ESXi 6.0U3 oder höher empfohlen. Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 2149704.
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. Informationen hierzu finden Sie im 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
VMware Integrated Openstack (VIO) VIO 2.5.1
vCloud Director (vCD)
  • vCD 8.0 bei Migration von vCNS auf NSX
  • vCD 8.10.1, wenn bereits auf NSX
  • 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, in den IPSec- und Load-Balancer-Verschlüsselungs-Suites wird TLS 1.0 ab NSX 6.2.3 nicht mehr unterstützt. Informationen zu Änderungen bei der Unterstützung der Verschlüsselung erhalten Sie unter VMware-Knowlegebase-Artikel 2147293.

    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.

    • Upgrade von Edge Services Gateway (ESG):
      Seit Version 6.2.5 wird die Ressourcenreservierung gleichzeitig mit dem NSX Edge-Upgrade vorgenommen. Wenn vSphere HA auf einem Cluster aktiviert wird, der nicht über ausreichende Ressourcen verfügt, schlägt der Upgrade-Vorgang möglicherweise fehl, da vSphere HA-Einschränkungen verletzt werden.

      Um derartige Upgrade-Fehler zu vermeiden, führen Sie die folgenden Schritte durch, bevor Sie ein ESG-Upgrade vornehmen:

      1. Stellen Sie grundsätzlich sicher, dass Ihre Installation den Empfehlungen für vSphere HA entspricht. Erläuterungen dazu finden Sie im VMware-Knowledgebase-Artikel 1002080.

      2. Verwenden Sie die NSX API für die Feinabstimmung der Konfiguration:
        PUT https://<NSXManager>/api/4.0/edgePublish/tuningConfiguration
        Stellen Sie dabei sicher, dass die Werte für edgeVCpuReservationPercentage und edgeMemoryReservationPercentage in die verfügbaren Ressourcen für den Formfaktor passen (siehe Standardwerte in nachfolgender Tabelle).

      Die folgenden Ressourcenreservierungen werden vom NSX Manager verwendet, sofern Sie nicht bei der Installation oder beim Upgrade ausdrücklich andere Werte festgelegt haben.

      NSX Edge
      Formfaktor
      CPU-Reservierung Arbeitsspeicherreservierung
      KOMPAKT 1000 MHz 512 MB
      GROSS 2000 MHz 1024 MB
      QUADLARGE 4000 MHz 2048 MB
      X-LARGE 6000 MHz 8192 MB

    • Deaktivieren Sie die Startoption für die virtuelle Maschine von vSphere, sofern vSphere HA aktiviert ist und Edges bereitgestellt sind. Nach dem Upgrade von NSX Edges 6.2.4 oder früher auf die Version 6.2.5 oder höher müssen Sie die Startoption für die virtuelle Maschine von vSphere für jede NSX Edge-Instanz in einem Cluster deaktivieren, für den vSphere HA aktiviert ist und Edges bereitgestellt sind. Öffnen Sie dazu den vSphere Web Client, suchen Sie nach dem ESXi-Host, auf dem sich die virtuelle NSX Edge-Maschine befindet, und klicken Sie auf „Verwalten“: „Einstellungen“, wählen Sie unter „Virtuelle Maschinen“ die Option „Starten/Herunterfahren von virtuellen Maschinen“ aus, klicken Sie auf „Bearbeiten“ und vergewissern Sie sich, dass die virtuelle Maschine auf den Modus „Manuell“ festgelegt ist (d. h., dass sie sich nicht auf der Liste für automatisches Starten/Herunterfahren befindet).

    • Neu Vor dem Upgrade auf NSX 6.2.5 oder höher müssen Sie sicherstellen, dass für alle Verschlüsselungslisten des Load Balancer der Doppelpunkt als Trennzeichen verwendet wird. Wenn in Ihrer Verschlüsselungsliste ein anderes Trennzeichen (z. B. das Komma) verwendet wird, führen Sie einen PUT-Aufruf für https://nsxmgr_ip/api/4.0/edges/EdgeID/loadbalancer/config/applicationprofiles durch und ersetzen Sie jede <ciphers>-Liste in <clientSsl> und <serverSsl> mit einer Liste mit Doppelpunkttrennung. Beispielsweise kann das betreffende Segment des Anforderungstextes das im Folgenden dargestellte Aussehen haben. Wiederholen Sie diesen Vorgang für alle Anwendungsprofile:

      <applicationProfile>
        <name>https-profile</name>
        <insertXForwardedFor>false</insertXForwardedFor>
        <sslPassthrough>false</sslPassthrough>
        <template>HTTPS</template>
        <serverSslEnabled>true</serverSslEnabled>
        <clientSsl>
          <ciphers>AES128-SHA:AES256-SHA:ECDHE-ECDSA-AES256-SHA</ciphers>
          <clientAuth>ignore</clientAuth>
          <serviceCertificate>certificate-4</serviceCertificate>
        </clientSsl>
        <serverSsl>
          <ciphers>AES128-SHA:AES256-SHA:ECDHE-ECDSA-AES256-SHA</ciphers>
          <serviceCertificate>certificate-4</serviceCertificate>
        </serverSsl>
        ...
      </applicationProfile>
    • 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-Upgradepaket können Sie direkt ein Upgrade von VMware vCloud Networking and Security (vCNS) 5.5.x auf NSX 6.2.x 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.x für den Fall erläutert, dass Sie vShield Endpoint nur zum Virenschutz verwenden.

        • Enthält Ihre Umgebung virtuelle Leitungen, müssen Sie Ihre Host-Cluster aktualisieren. Danach werden die virtuellen Leitungen in logische Switches umbenannt. Anweisungen dazu finden Sie unter Aktualisierung von Host-Clustern.

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

    • Legen Sie die richtige Verschlüsselungsversion für Clients mit Lastenausgleich fest, die TLS 1.0 verwenden: Dies wirkt sich auf vROPs-Poolmitglieder aus, die TLS Version 1.0 verwenden. Falls die Server, für deren Verkehr ein Lastenausgleich stattfindet, diese Version verwenden, müssen Sie ausdrücklich über die „ssl-version=10“-Einstellung im NSX Load Balancer einen Wert für die Überwachungserweiterung festlegen. Weitere Informationen erhalten Sie im Administratorhandbuch für NSX.

      {
          "expected" : null,
          "extension" : "ssl-version=10",
          "send" : null,
          "maxRetries" : 2,
          "name" : "sm_vrops",
          "url" : "/suite-api/api/deployment/node/status",
          "timeout" : 5,
          "type" : "https",
          "receive" : null,
          "interval" : 60,
          "method" : "GET"
      }

    • 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 können Sie die Funktion für automatische Entwürfe deaktivieren, indem Sie für autoDraftDisabled „true“ festlegen. Manuell konfigurierte Einstellungen werden beim Upgrade beibehalten. Durch das Deaktivieren der Funktion für automatische Entwürfe vor dem Vornehmen einer großen Anzahl von Änderungen an den Firewallregeln kann die Leistung verbessert werden und zuvor gespeicherte Entwürfe werden dadurch nicht überschrieben. Sie können folgenden API-Aufruf verwenden, um für die Eigenschaft autoDraftDisabled in der globalen Konfiguration „true“ festzulegen:

      1. Rufen Sie die vorhandene globale Firewall-Konfiguration (GlobalConfiguration) ab:
        GET https://NSX-Manager-IP-Address/api/4.0/firewall/config/globalconfiguration
        Beachten Sie, dass mit GET nicht das Feld autoDraftDisabled angezeigt wird.
      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>
        
    • 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 „InProgress“ 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 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

    Problem 1768144: Ältere NSX Edge-Appliance-Ressourcenreservierungen, die die neuen Grenzwerte überschreiten, können zu Fehlern bei Upgrades oder erneuten Bereitstellungen führen
    In NSX 6.2.4 und früher konnten beliebig große Ressourcenreservierungen für eine NSX Edge-Appliance festgelegt werden. In NSX war kein Höchstwert vorgegeben.
 Nach dem Upgrade des NSX Managers auf Version 6.2.5 oder höher treten bei Upgrades oder erneuten Bereitstellungen des Edge Fehler auf (wodurch ein Upgrade ausgelöst wird), wenn ein vorhandenes Edge reservierte Ressourcen (insbesondere Arbeitsspeicher) aufweist, die den neuen Höchstwert für den ausgewählten Formfaktor überschreiten. Hat ein Benutzer beispielsweise eine Arbeitsspeicherreservierung in Höhe von 1.000 MB auf einem LARGE Edge vor Version 6.2.5 festgelegt und ändert die Appliance-Größe nach einem Upgrade auf Version 6.2.5 in COMPACT, so überschreitet die Arbeitsspeicherreservierung den neuen Höchstwert – in diesem Fall 512 für ein COMPACT Edge – und der Vorgang scheitert.
    Unter Upgrade von Edge Services Gateway (ESG) erhalten Sie Informationen zur empfohlenen Ressourcenzuteilung in NSX 6.2.5.

    Problemumgehung: Verwenden Sie die Appliance-REST-API: PUT https://<NSXManager>/api/4.0/edges/<edge-Id>/appliances/ zum erneuten Konfigurieren der Arbeitsspeicherreservierung, sodass sie innerhalb der für den Formfaktor festgelegten Werte liegt, ohne weitere Appliance-Änderungen. Nach Abschluss dieses Vorgangs können Sie die Appliance-Größe ändern.

    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 1683879: Ein Upgrade auf NSX 6.2.3 oder später kann auf Hosts mit weniger als 8 GB Arbeitsspeicher scheitern

    NSX 6.2.3 und später 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: Das Ändern der Einstellung „tcpLoose“ über /api/3.0/edges ist nach dem Upgrade von vCloud Networking and Security auf NSX nicht zulässig

    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 dem Veröffentlichen einer Änderung an der Distributed Firewall-Konfiguration lautet der Status sowohl auf der Benutzeroberfläche als auch in der API permanent InProgress und der Datei „vsfwd.log“ wird kein Protokoll für L2- oder L3-Regeln hinzugefügt.

    Problemumgehung: Veröffentlichen Sie während eines NSX-Upgrades keine Änderungen an der Distributed Firewall-Konfiguration. Starten Sie zum Beenden des Status InProgress und zum Beheben des Problems die virtuelle NSX Manager-Appliance 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 cannot be set on host</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 1716619: vNIC-Änderung von NSX 5.x.x Edges scheitert in NSX 6.x.x Manager aufgrund fehlender Funktion „systemControl“
    Die Konfiguration von vNICs für NSX 5.x.x unter NSX 6.x.x scheitert, da kein „systemControl“-Eintrag für Edges vorhanden ist, die unter vCNS (vCloud Networking and Security) Manager erstellt wurden. Die Funktion „SystemControl“ wurde mit Version 6.1.5 eingeführt und ist unter vCNS oder vShield 5.5.x Manager nicht verfügbar. Dieses Problem tritt bei der Bearbeitung von Schnittstellenkonfigurationen älterer Edge-Appliances (vCNS oder vShield 5.5.x) ab NSX 6.1.5 bzw. NSX 6.2.x Manager auf.

    Problemumgehung: Wenden Sie sich an den technischen Support von VMware.

    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.

    Problem 1764460: Nach Abschluss der Hostvorbereitung erscheinen alle Clustermitglieder als „Bereit“, aber Clusterebene wird fälschlicherweise als „Ungültig“ angezeigt
    Nach dem Abschluss der Host-Vorbereitung erscheinen alle Cluster-Mitglieder korrekt als „Bereit“, aber das Cluster-Level wird als „Ungültig“ angegeben. Die dafür angezeigte Ursache ist ein benötigter Host-Neustart, obwohl dieser bereits durchgeführt wurde.

    Problemumgehung: Klicken Sie auf das rote Warnsymbol und wählen Sie „Lösen“.

    Bekannte Probleme bei NSX Manager

    Neu Problem 1772911: Auslastung des Festplattenspeichers durch NSX Manager steigt rapide an, die Größe der Aufgaben und Auftragstabellen nimmt mit starker CPU-Auslastung zu
    NSX Manager-CPU erreicht permanent 100 % oder regelmäßig Spitzenauslastungen von 100 %. Durch Ausführen des Befehls „Show Process Monitor“ in der NSX Manager-Befehlszeilenschnittstelle wird der CPU-intensivste Java-Prozess angezeigt. Durch die stark zunehmende DB-Größe wird mehr Festplattenspeicher benötigt. Dies wiederum führt zu einer Verlangsamung von NSX Manager.

    Problemumgehung: Wenden Sie sich an den technischen Support von VMware.

    Problem 1441874: Beim Upgrade eines einzelnen NSX Manager in einer vCenter-Umgebung im verknüpften Modus wird eine Fehlermeldung ausgegeben
    In einer Umgebung mit mehreren VMware vCenter-Servern, die mehrere NSX Manager umfassen, wird, wenn Sie einen oder mehrere NSX Manager unter „vSphere Web Client >Netzwerk und Sicherheit > Installation > Host-Vorbereitung“ auswählen, eine Fehlermeldung ausgegeben, die sinngemäß Folgendes besagt:
    „Verbindung zum NSX Manager konnte nicht hergestellt werden. Wenden Sie sich an den Administrator.“

    Problemumgehung: Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 2127061.

    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 1486403: 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 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 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 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 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 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 1833934:
    Alle vCNS-Edges (Version 5.5.4) und NSX Edges (6.1.x und 6.2.x), die im VIX-Kommunikationsmodus ausgeführt werden, lassen sich nach einem Storage vMotion nicht mehr verwalten.
    NSX Edges, die mit MessageBus als Kommunikationsmodus ausgeführt werden, sind davon nicht betroffen.

    Problemumgehung: Wenden Sie sich an den VMware-Kundensupport.

    Neu Problem 1799261: NSX Edge wird nach Upgrade oder erneuter Bereitstellung möglicherweise in Split-Brain-Zustand ausgeführt
    Mit dem CLI-Befehl show service highavailability zum Anzeigen der Hochverfügbarkeit wird für das NSX Edge im Standby-Modus „Standby“ angezeigt, der Config-Engine-Status wird jedoch als „Active“ angegeben.

    Problemumgehung: Starten Sie das NSX Edge im Standbymodus neu.

    Neu Problem 1777792: Wenn für den Peer-Endpoint „BELIEBIG“ festgelegt wurde, kann keine IPSec-Verbindung hergestellt werden
    Wenn in der IPSec-Konfiguration für NSX Edge der Remote-Peer-Endpoint auf „BELIEBIG“ festgelegt wurde, verhält sich das Edge wie ein IPSec-„Server“ und wartet auf Remote-Peers zur Initiierung von Verbindungen. Wenn vom Initiator eine Authentifizierungsanforderung über PSK und XAUTH gesendet wird, zeigt das Edge die folgende Fehlermeldung an: „initial Main Mode message received on XXX.XXX.XX.XX:500 but no connection has been authorized with policy=PSK+XAUTH“. IPsec kann nicht erstellt werden.

    Problemumgehung: Verwenden Sie bei der Konfiguration der IPSec-VPN-Verbindung eine spezifische Peer-Endpoint-IP oder einen FQDN anstelle von „ANY“.

    Problem 1741158: Erstellen eines neuen, nicht konfigurierten NSX Edge und Anwenden der Konfiguration kann zu vorzeitiger Aktivierung des Edge-Dienstes führen
    Wenn Sie die NSX API verwenden, um einen neuen, nicht konfigurierten NSX Edge zu erstellen, dann einen API-Aufruf durchführen, um einen der Edge-Dienste auf diesem Edge zu deaktivieren (also beispielsweise für „dhcp-enabled“ „false“ festlegen) und schließlich die Konfigurationsänderungen auf den deaktivierten Edge-Dienst anwenden, wird dieser umgehend aktiviert.

    Problemumgehung: Nachdem Sie eine Konfigurationsänderung an einem Edge-Dienst vornehmen, der deaktiviert bleiben soll, führen Sie sofort einen PUT-Aufruf durch, um das Aktivierungs-Flag für diesen Dienst auf „false“ festzulegen.

    Problem 1772004: Edge HA-Failover von Knoten 0 auf Knoten 1 nimmt mehr Zeit in Anspruch als erwartet
    Ein Failover von Knoten 0 auf Knoten 1 nimmt in Edge HA-konfigurierten Umgebungen mehr Zeit in Anspruch als erwartet, der Datenverkehr-Failover von Knoten 0 auf Knoten 1 verläuft hingegen normal.

    Problemumgehung: Keine.

    Problem 1758500: Statische Route mit mehreren nächsten Hops wird nicht in NSX Edge-Routing- und -Weiterleitungstabellen installiert, wenn es sich bei mindestens einem der nächsten konfigurierten Hops um die vNIC-IP-Adresse des Edge handelt
    Bei ECMP und mehreren Nächster-Hop-Adressen kann unter NSX die vNIC-IP-Adresse des Edge als nächster Hop konfiguriert werden, wenn zumindest eine der Nächster-Hop-IP-Adressen gültig ist. Dies wird ohne Fehlermeldungen und Warnungen zugelassen, aber die Netzwerkroute wird aus der Tabelle zum Edge-Routing/-Weiterleiten entfernt.

    Problemumgehung: Konfigurieren Sie die vNIC-IP-Adresse des Edge nicht als nächsten Hop in der statischen Route, wenn Sie ECMP verwenden.

    Problem 1733165: IPsec verursacht u. U. das Entfernen dynamischer Routen aus der NSX Edge-Tabelle zum Weiterleiten
    Wird ein über die dynamische Route erreichbares Subnetz als Remotesubnetz für die IPsec-Konfiguration verwendet, wird dieses Subnetz von NSX Edge aus der Tabelle zum Weiterleiten entfernt und nicht erneut installiert, auch nicht, nachdem dieses Subnetz aus der IPsec-Konfiguration entfernt wurde.

    Problemumgehung: Aktivieren/deaktivieren Sie das Routing-Protokoll oder bereinigen Sie die Routingumgebung.

    Problem 1726379: Wenn der IP-Multicast-Bereich in den letzten drei Oktetten einen oberen Grenzwert aufweist, der 99 überschreitet, schlägt die VXLAN-Trunk-Portgruppen-Konfiguration fehl.
    Wenn Sie beim Konfigurieren der Segment-ID einen Multicast-IP-Bereich erstellen, der einen oberen Grenzwert aufweist, der in den letzten drei Oktetten über 99 hinausgeht, beispielsweise 1.100.100.100, und zudem einen Multicast- oder hybriden logischen Switch mit demselben Multicast-IP-Bereich erstellen, schlägt die VXLAN-Trunk-Portgruppen-Konfiguration fehl.

    Problemumgehung: Verwenden Sie beim Konfigurieren der Segment-ID einen Multicast-IP-Bereich kleiner als 100 für jedes der drei letzten Oktette, zum Beispiel 100.1.1.1.

    Problem 1675659: Unverankerte statische Routen werden gegenüber dynamischen Routen (OSPF) bevorzugt
    Eine unverankerte statische Route zur Sicherung wird falsch in die Routing-Tabelle eines Edges eingegeben, wenn die Route Redistribution aktiviert ist, auch wenn eine OSPF-Route verfügbar ist.

    Problemumgehung: Um dieses Problem zu umgehen, stellen Sie die Route-Redistribution von statisch in OSPF um.
    Hinweis: Dieses Problem wirkt sich nicht auf den Datenpfad aus. Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2147998.

    Problem 1716464: NSX-Load Balancer führt keine Weiterleitung zu VMs durch, die kürzlich mit einem Sicherheits-Tag versehen wurden.
    Wenn wir zwei VMs mit einem bestimmten Tag bereitstellen und anschließend einen LB für die Weiterleitung zu dem entsprechenden Tag konfigurieren, führt der LB die Weiterleitung zu diesen beiden VMs erfolgreich durch. Falls wir jedoch eine dritte VM mit dem entsprechenden Tag bereitstellen, führt der LB die Weiterleitung nur zu den ersten beiden VMs durch. Problemumgehung: Klicken Sie im LB-Pool auf „Speichern“. Dadurch werden die VMs neu geprüft und das Routing zu den neu gekennzeichneten VMs wird gestartet.

    Problem 1776073: Wenn ein Edge mit einem privaten lokalen AS Weiterleitungen an EBGP-Peers sendet, werden sämtliche private AS-Pfade aus den gesendeten BGP-Routing-Aktualisierungen gelöscht.
    NSX weist derzeit eine Beschränkung auf, die verhindert, dass der vollständige AS-Pfad für eBGP-Nachbarn freigegeben wird, wenn der AS-Pfad nur private AS-Pfade enthält. Auch wenn dies in den meisten Fällen das gewünschte Verhalten ist, gibt es Fälle, in denen der Administrator möglicherweise private AS-Pfade für einen eBGP-Nachbarn freigeben möchte.

    Problemumgehung: Es ist keine Umgehung verfügbar, bei der der Edge alle AS-Pfade in der BGP-Aktualisierung ankündigt.

    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:// <NSXManager>/api/4.0/edgePublish/tuningConfiguration, um explizite Werte für beide Edge-VMs 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 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 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 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 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 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.

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

    Bekannte Probleme bei Sicherheitsdiensten

    Problem 1474650: NetX-Benutzer sehen bei ESXi 5.5.x- und 6.x-Hosts einen violetten Diagnosebildschirm mit der Meldung ALERT: NMI: 709: NMI IPI received
    Wenn eine große Anzahl von Paketen von einer Dienst-VM übertragen oder empfangen wird, dominiert DVFilter weiterhin die CPU, was Taktsignalverlust und einen violetten Diagnosebildschirm zur Folge hat. Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 2149704.

    Problemumgehung: Upgrade des ESXi-Hosts auf eine der folgenden Mindestversionen von ESXi, die für die Verwendung von NetX erforderlich sind:

    • 5.5 Patch 10
    • ESXi 6.0U3

    Problem 1741844: Die Adressermittlung einer vNIC mit mehreren IP-Adressen mithilfe von ARP-Snooping führt zu einer CPU-Auslastung von 100 %.
    Dieses Problem tritt auf, wenn die vNIC einer virtuellen Maschine mit mehreren IP-Adressen konfiguriert wurde und ARP-Snooping für die IP-Erkennung aktiviert wurde. Das Modul für die IP-Erkennung sendet weiter ständig vNIC-IP-Aktualisierungen an den NSX Manager, um die vNIC-IP-Zuordnung für alle VMs zu ändern, die mit mehreren IP-Adressen konfiguriert wurden.

    Problemumgehung: Für dieses Problem gibt es keine Umgehung. Zurzeit unterstützt die Funktion für das ARP-Snooping nur eine IP-Adresse pro vNIC. Weitere Informationen finden Sie im Abschnitt IP-Erkennung für virtuelle Maschinen im Administratorhandbuch für NSX.

    Problem 1689159: Die Funktion „Regel hinzufügen“ im Flow Monitoring funktioniert nicht korrekt für ICMP-Flows
    Beim Hinzufügen einer Regel über das Flow Monitoring bleibt das Feld „Dienste“ leer, wenn es nicht explizit auf „ICMP“ festgelegt wird. Infolgedessen wird gegebenenfalls eine Regel mit dem Diensttyp „ANY“ hinzugefügt.

    Problemumgehung: Aktualisieren Sie das Feld „Dienste“, um den ICMP-Datenverkehr widerzuspiegeln.

    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 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 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 1066277: 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 oder später 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 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 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 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 1648578: NSX erzwingt das Hinzufügen von Cluster/Netzwerk/Speicher, wenn eine neue Host-basierte NetX-Dienstinstanz erstellt wird
    Wenn Sie über den vSphere Web Client eine neue Dienstinstanz für Host-basierte NetX-Dienste, beispielsweise eine Firewall, IDS und IPS, erstellen, werden Sie gezwungen, Cluster/Netzwerk/Speicher hinzuzufügen, auch wenn diese nicht erforderlich sind.

    Problemumgehung: Beim Erstellen einer neuen Dienstinstanz können Sie beliebige Informationen für Cluster/Netzwerk/Speicher angeben, um die Felder auszufüllen. Auf diese Weise ist es Ihnen möglich, die Dienstinstanz zu erstellen und wunschgemäß fortfahren.

    Problem 1772504: Service Composer unterstützt keine Sicherheitsgruppen mit MAC Set
    Service Composer erlaubt die Verwendung von Sicherheitsgruppen in Richtlinienkonfigurationen. Für den Fall, dass eine Sicherheitsgruppe einen MAC Set enthält, akzeptiert Service Composer die entsprechende Sicherheitsgruppe ohne Warnung, es können jedoch keine Regeln für den entsprechenden MAC Set erzwungen werden. Dies ist darauf zurückzuführen, dass Service Composer auf Layer3 arbeitet und keine Layer2-Konstrukte unterstützt. Beachten Sie, dass falls eine Sicherheitsgruppe sowohl einen IP Set als auch einen MAC Set enthält, der IP Set nach wie vor wirksam ist, wohingegen der MAC Set ignoriert wird. Es kann nicht schaden, eine Sicherheitsgruppe, die einen MAC Set enthält, zu referenzieren – der Benutzer muss sich bewusst sein, dass der MAC Set ignoriert wird.

    Problemumgehung: Falls der Benutzer beabsichtigt, Firewallregeln mithilfe eines MAC Sets zu erstellen, sollte er die DFW-Layer2-/Ethernetkonfiguration anstelle von Service Composer verwenden.

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

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

    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 1626233: Wenn die NetX-Dienst-VM (SVM) Pakete verwirft, generiert Traceflow keine entsprechende Beobachtung

    Die Traceflow-Sitzung wird nach dem Senden des Pakets an die NetX-Dienst-VM (SVM) beendet. Wenn die SVM Pakete verwirft, generiert Traceflow keine entsprechende Beobachtung.

    Problemumgehung: Für dieses Problem gibt es keine Umgehung. Wird das Traceflow-Paket nicht wieder eingefügt, ist davon auszugehen, dass die SVM das Paket verworfen hat.

    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 1765354: <deployType> ist eine erforderliche Eigenschaft, wird aber nicht verwendet
    <deployType> ist eine erforderliche Eigenschaft, wird aber nicht verwendet und hat keine Bedeutung.

    Problem 1760102: Nach dem Löschen und erneuten Bereitstellen eines NSX Controllers zur Wiederherstellung nach einem Speicherausfall können virtuelle Maschinen gegebenenfalls nicht kommunizieren.
    Ein NSX Controller für die vSphere 6.2.x-Umgebung erhält im Fall eines Speicherausfalls möglicherweise nur Lesezugriff. Wenn Sie den Controller in diesem Zustand löschen und erneut bereitstellen, können einige VMs möglicherweise nicht mehr kommunizieren. Bei einem Speicherausfall eines Controllers sollte er sich nach einem Neustart nicht mehr im schreibgeschützten Modus befinden. Aktuell ist dies aber in NSX nicht der Fall.

    Problemumgehung: Starten Sie den NSX Management Service neu.

    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.6 oder in 6.2.5 und früher.

    In NSX 6.2.6 behobene Probleme

    Die behobenen Probleme in 6.2.6 gliedern sich wie folgt:

    In NSX 6.2.6 behobene Probleme der Installation und des Upgrades

    • Behobenes Problem 1767149/1782802: Wenn eine Verschlüsselungskette angegeben ist, die durch Kommas (,) getrennt ist, schlagen Upgrades von NSX for vSphere 6.1.x, 6.2.0 und 6.2.1 auf NSX for vSphere 6.2.5 fehl.
      Ab Version 6.2.6 können Verschlüsselungen durch Doppelpunkte (:) anstelle von Kommas (,) getrennt werden, bevor das Upgrade ausgeführt wird. Problem in 6.2.6 behoben.

    In NSX 6.2.6 behobene Netzwerk- und Edge-Dienste-Probleme

    • Behobenes Problem 1722988: NSX Edge OpenSSL-Paket wird nicht auf 1.0.2j aktualisiert
      In Version 6.2.6 wird das NSX Edge OpenSSL-Paket auf 1.0.2j aktualisiert. Problem in 6.2.6 behoben.

    Erfahren Sie mehr zu behobenen Problemen in 6.2.5 und früher.

    In NSX 6.2.5 behobene Probleme

    Die behobenen Probleme in 6.2.5 gliedern sich wie folgt:

    In NSX 6.2.5 behobene allgemeine Probleme

    • Behobenes 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. Problem in 6.2.5 behoben.

    In NSX 6.2.5 behobene Probleme logischer Netzwerke

    • Behobene Probleme 1663902, 1717370: Die Durchführung von UPDATE/PUT-Vorgängen an einem ESG/DLR-Edge während der Produktion kann den Datenverkehr für einen kurzen Zeitraum beeinträchtigen
      Sie werden für einen kurzen Zeitraum Störungen des Datenverkehrs feststellen, wenn Sie während der Produktion UPDATE/PUT-Vorgänge an einem ESG/DLR durchführen. Problem in 6.2.5 behoben.

    • Behobenes Problem 1737807, 1703913: VMs verlieren ihre Netzwerkkonnektivität in NSX mit DLR HA
      In einer NSX-Umgebung mit dynamischem Routing und Hochverfügbarkeit (High Availability, HA), die auf einer DLR-Kontroll-VM konfiguriert ist, wird die Netzwerkverbindung der virtuellen Maschinen getrennt, wenn die DLR-Kontroll-VMs nach einer Split-Brain-Zustand wiederhergestellt werden (sowohl primärer als auch sekundärer DLR-HA-Knoten verbleiben gleichzeitig im Status Aktiv). Problem in 6.2.5 behoben.

    • Behobenes 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. Problem in 6.2.5 behoben.

    • Behobenes Problem 1717371: Bei virtuellen NSX Edge-Maschinen kommt es im Verlauf eines vSphere-HA-Ereignisses zu keinem Failover
      Wenn NSX Edges auf einem vSphere-Cluster installiert oder erneut bereitgestellt werden, auf dem vSphere HA aktiviert ist, aktiviert NSX Manager während der NSX Edge-Bereitstellung Automatic Startup Manager für den ESX-Host, auf dem das Edge bereitgestellt wird. Dies ist mit vSphere HA inkompatibel, sodass vSphere HA für die Edge-VM nicht bereitstellt. Problem in 6.2.5 behoben. Weitere Informationen finden Sie im Upgrade-Hinweis zu Automatic Startup Manager.

    • Behobenes Problem 1606785, 1736095: Der NSX Edge Load Balancer schreibt eventuell die Meldungen der Datei nagios.log auf die /var/log/ -Partition
      Die /var/log-Partition auf dem NSX Edge Load Balancer wird zu voll. Problem in 6.2.5 behoben.

    In NSX 6.2.5 behobene Netzwerk- und Edge-Dienste-Probleme

    • Behobenes Problem 1777121: 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. Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2147181. Problem in 6.2.5 behoben.

    • Behobenes Problem 1771285: Multicast-IP wird während des Vorgangs zur Controller-Synchronisierung bei einem überbrückten VXLAN-Netzwerk nicht auf dem Host festgelegt, wodurch ein Fehler bei der Steuerungskomponenten-Konnektivität auftritt.
      Die Steuerungsebene wird als inaktiv markiert, was zu einer Unterbrechung des Datenverkehrs führt, sobald die Controller-Synchronisierung aus einem der folgenden Gründe ausgelöst wird:

      • VDR wird erneut bereitgestellt, aktualisiert oder die Synchronisierung wird erzwungen

      • Statussynchronisierung des VSM-Ebenen-Controllers

      • Controller wird neu gestartet oder getrennt und dann wieder verbunden

      Problem in 6.2.5 behoben.

    • Behobenes Problem 1766624: Zufälliges Verwerfen von Paketen beim Passieren des Datenverkehrs eines Bridge-DLRs auf NSX
      Pakete werden zufällig verworfen, wenn der Datenverkehr ein Brücken-DLR auf NSX passiert und der Ping-Befehl mehrere Benachrichtigungen des Typs „Zeit für Anforderung wurde überschritten“ anzeigt. Problem in 6.2.5 behoben.
      Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 2148175.

    • Behobenes Problem 1779313: Konnektivitätsausfall nach Neustart des NSX Managers
      Nach dem Neustart des NSX Managers wurde ein Konnektivitätsausfall festgestellt. Dieser ist auf eine Bereinigung des ESX-Hosts von Distributed Logical Router(DLR)-Instanzen aufgrund einer teilweise inkorrekten Synchronisierung des VDR zurückzuführen. Bei Auftreten dieses Fehlers konnte die NSX-Umgebung durch eine erzwungene Synchronisation des VXLAN-/Routing-Dienstes wiederhergestellt werden. Problem in 6.2.5 behoben.

    • Behobenes Problem 1730633: Falscher Überwachungsstatus bei der Verwendung des Gruppierungsobjekts
      In der CLI wird der Überwachungsstatus bei der Verwendung des Gruppierungsobjekts nicht korrekt angezeigt. Problem in 6.2.5 behoben.

    • Behobenes Problem 1745928: NTLM-Authentifizierung schlägt fehl, wenn die Anwendungsregel no option http-server-close konfiguriert wurde
      Wenn Sie die Anwendungsregel no option http-server-close konfigurieren, schlägt die NTLM-Authentifizierung fehl. Problem in 6.2.5 behoben.

    • Behobenes Problem 1736941: Web-Client für die NSX Edge-Firewall sehr langsam
      Der Web-Client für die NSX Edge-Firewall reagiert beim Scrollen durch die Edge-Firewall-Regeltabelle schwerfällig. Problem in 6.2.5 behoben.

    • Behobenes Problem 1729066: Die Edge SCSI-Festplatten-Zeitüberschreitung wird nicht angewendet.
      Die Edge SCSI-Festplatten-Zeitüberschreitung wird aufgrund falscher Startskriptdatei-Berechtigungen nicht angewendet. Problem in 6.2.5 behoben.

    • Behobenes Problem 1649098: DHCP-Relay-Agenten funktionieren nicht in NSX.
      Wenn der DHCP-Server mehr als 10 Hops entfernt ist, läuft die TTL im Transit ab und DHCP-Pakete kommen nicht beim konfigurierten Relay-Server an. Problem in 6.2.5 behoben.

    In NSX 6.2.5 behobene Probleme der Sicherheitsdienste

    • Behobenes Problem 1767402: DFW-Regeln, für die „Angewendet auf“ auf eine Sicherheitsgruppe festgelegt wurde, werden nicht auf Hosts veröffentlicht.
      DFW-Regeln, bei denen das Feld „Angewendet auf“ auf eine Sicherheitsgruppe festgelegt wurde, werden nicht auf ESXi-Hosts in einem neuen Cluster veröffentlicht. Problem in 6.2.5 behoben.

    • Behobenes Problem 1760081: NetX-/Dienstprofilregeln werden nach dem Veröffentlichen nicht in den Hosts angezeigt
      In skalierten Umgebungen nimmt die Verarbeitung des NetX-/Dienstprofil-Regelsatz Stunden in Anspruch, bevor dieser sich nach der Veröffentlichung neuer oder geänderter Regeln auf die Hosts auswirkt. Problem in 6.2.5 behoben.

    • Behobenes Problem 1738421: DFW-Controller wird aufgrund einer ungültigen Adresse für die Netzwerkkarte (NIC) einer VM unerwartet beendet.
      Unter bestimmten (seltenen) Bedingungen können vCenter-Administratoren für die NIC einer VM eine ungültige Adresse festlegen, sodass der DFW-Controller-Prozess unerwartet beendet wird. Problem in 6.2.5 behoben.

    • Behobenes Problem 1723946: Gelöschte Regeln werden vorübergehend in ANY-ANY-Regeln umgewandelt.
      In einem System, in dem grundsätzlich gleichzeitig sehr viele Regeln bereitgestellt werden und in dem Regeln geändert oder gelöscht werden, kann es vorkommen, dass eine Regel, die hinzugefügt und anschließend beim nächsten Aufruf wieder gelöscht wird, vorübergehend als ANY-ANY-Regel veröffentlicht wird, bis der Löschvorgang durchgeführt wird. Problem in 6.2.5 behoben.

    • Folgendes Problem behoben: 1738588: Einige VMs wurden keiner Sicherheitsgruppe hinzugefügt
      Es kommt vor, dass VMs erst dann einer Sicherheitsgruppe mit dynamischen Kriterien hinzugefügt werden, wenn die Gruppenmitgliedschaft durch eine Aktivität aktualisiert wird. Problem in 6.2.5 behoben.

    • Behobenes Problem 1733763: Die NSX Distributed Firewall wendet falsches TFTP-ALG an.
      Die NSX Distributed Firewall wendet bei der Verarbeitung einer TCP-Sitzung an Port 69 ein falsches TFTP ALG an. Problem in 6.2.5 behoben.

    • Behobenes Problem 1738419: Ungültige Adresse für NIC einer VM führt zum Beenden des DFW-Controller-Prozesses.
      Unter bestimmten (seltenen) Bedingungen können vCenter-Administratoren für die Netzwerkkarte (NIC) einer VM eine ungültige Adresse festlegen, sodass der DFW-Controller-Prozess unerwartet beendet wird. Problem in 6.2.5 behoben.

    • Behobenes Problem 1704661, 1739613: Verlust der VM-Netzwerkverbindung mit folgendem Fehler: „Failed to restore PF state: Limit exceeded.“ (PF-Status konnte nicht wiederhergestellt werden. Grenzwert überschritten.)
      Verlust der VM-Netzwerkverbindung mit folgendem Fehler: „Failed to restore PF state: Limit exceeded.“ (PF-Status konnte nicht wiederhergestellt werden. Grenzwert überschritten.) Problem in 6.2.5 behoben.

    • Behobenes 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 fehl. Problem in 6.2.5 behoben.

    • Behobenes Problem 1460363: 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. Problem in 6.2.5 behoben.

    Die folgenden Probleme wurden in früheren 6.2.x-Versionen behoben:

    In 6.2.4 und früher 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. Problem in 6.2.4 behoben.

    • 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. Problem 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
      Problem 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
      Problem 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. Problem 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. Problem 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. Problem 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. Problem 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. Problem 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. Problem 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
      Problem 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. Problem 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
      Problem 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. Problem 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
      Problem 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. Problem 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. Problem 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. Problem 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. Problem 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. Problem 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 Starten des Ping über den mit dem NSX-Host-Switch verbundenen vmnknic führt zu einem PSOD-Bildschirm, wenn der Datenblock größer als die MTU ist. Problem 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.

      Problem 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.4 und früher 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. Erläuterungen dazu finden Sie im VMware-Knowledgebase-Artikel 2146714. Problem in 6.2.4 behoben.

    • Behobenes Problem 1578509: Nach einem Neustart des EAM (ESX Agent Manager) gilt für den GI (Guest Introspection)-Dienststatus der Status „Warnung“
      Problem 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
      Problem 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. Problem 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. Problem 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. Problem 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. Problem 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. Problem 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. Problem 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 Problem 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. Problem 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. Problem 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. Problem 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. Problem in NSX 6.2.0 behoben.

    In 6.2.4 und früher 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. Weitere Informationen enthält der VMware-Knowledgebase-Artikel 2145934. Problem in 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. Problem in 6.2.4 behoben.

    • 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.
      Das Problem wurde in NSX 6.2.3 durch Vermeidung der Null-Pointer-Ausnahme und Wiederherstellung 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.
      Problem 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.
      Problem 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. Problem 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älschlicherweise als ROT dargestellt wurde (der damit eine nicht vorhandene Fehlerbedingung anzeigt). Problem 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. Problem 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
      Problem 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. Problem 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. Problem 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. Problem 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. Problem in NSX 6.2.1 behoben. Problem 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. Problem 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. Problem in NSX 6.2.0 behoben. Problem 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. Problem 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>
      . Problem in NSX 6.2.0 behoben.

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

    • 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. Problem in 6.2.4 behoben.

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

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

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

    • 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. Problem in 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. Problem in 6.2.4 behoben.

    • 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]]).
      Problem 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
      Problem 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. Problem 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.
      Problem 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. Problem 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. Problem 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. Problem 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. Problem 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. Problem 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. Problem 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. Problem in NSX 6.2.1 behoben.

    • Behobenes Problem 1599706: Das SYN/ACK-Paket geht bei der Kommunikation zwischen zwei VNIs über LDR verloren
      Problem 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. Problem 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. Problem 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. Problem 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. Problem in NSX 6.2.0 behoben.

    • Behobenes Problem 1449461: Beim Ausführen des Befehls 'clear ip ospf neighbor' wird ein Segmentierungsfehler zurückgegeben
      Problem 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. Problem in NSX 6.2.0 behoben.

    In 6.2.4 und früher behobene Probleme der Sicherheitsdienste

    • Behobene Probleme 1558051, 1769174: Für Cluster mit einer deaktivierten Distributed Firewall (DFW) werden keine Ausschlusslisten-Updates durchgesetzt und es werden Filter für die Ausschlusslisten erstellt
      Es werden keine Ausschlusslisten-Updates durchgesetzt, wenn einer der Cluster über eine deaktivierte DFW verfügt. Dies tritt auf, da die isFirewallEnabled-API eine genaue Prüfung umfasst und nur dann ˜„true“ zurückgibt, wenn alle Hosts die DFW aktiviert haben. Wenn die Firewall für einen Cluster in der Umgebung deaktiviert war, wurde bisher „false“ zurückgegeben.
      Nach der Fehlerbehebung überprüft die API nun, ob die Firewall für einen Cluster aktiviert ist und gibt „true“ zurück, wenn für einen der Cluster in der Umgebung die Firewall aktiviert ist.
      Darüber hinaus wurden Filter für Ausschlusslisten-Updates auf Hosts erstellt, bei denen die DFW deaktiviert ist. Nach der Fehlerbehebung ruft die API für jede der ausgeschlossenen VMs das Cluster ab und wenn für das Cluster die Firewall aktiviert ist, werden die System-vNIC-IDs des Clusters und die vNIC-IDs der VM hinzugefügt und die Ausschlussliste für jedes einzelne Cluster veröffentlicht. Die Migration von VMs von einem Cluster zu einem anderen erfolgt durch Veröffentlichen der Ausschlussliste für das VM-Cluster. Problem in 6.2.4 behoben.

    • 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. Problem in 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. Problem in 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. Problem in 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
      Problem in 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. Problem in 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
      Problem in 6.2.4 behoben.

    • 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. Problem 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. Problem 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. Das Problem wurde in NSX 6.2.3 durch Hinzufügen der 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. Das Problem wurde durch Änderung des Service Composer-Abschnitts der Firewallkonfiguration in „Schreibgeschützt“ behoben. Die mit Service Composer erstellten Regeln müssen mit Service Composer verwaltet werden. Problem 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. Problem 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
      Problem 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.
      Problem 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. Problem 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. Problem 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. Problem 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.
      Problem 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
      Problem in 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. Problem in 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. Problem in 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. Problem 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. Problem 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. Problem 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. Problem 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. Problem 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. Problem 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. Problem 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
      Problem 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. Problem 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. Problem 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
      Problem 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. Problem 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. Problem 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. Problem 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. Problem 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. Problem 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. Problem 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. Problem 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. Problem 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. Problem 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. Problem in NSX 6.2.0 behoben.

    In 6.2.4 und früher 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. Problem in 6.2.4 behoben.

    • 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. Problem in 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
      Problem in 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“. Problem in 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. Problem in 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. Problem 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. Problem 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

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

    In 6.2.4 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
      Die Probleme wurden mit der neuesten Version des Log Insight-Inhaltspakets behoben. Laden Sie das Inhaltspaket von VMware Solution Exchange herunter und installieren Sie es. Problem 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. Problem in 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. Problem 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. Problem 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. Problem 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. Problem 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. Problem 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.
    5. Januar 2017: Erste Auflage für NSX 6.2.5.
    10. Januar 2017: Zweite Auflage für NSX 6.2.5. Behobene Probleme wurden hinzugefügt.
    2. Februar 2017: Erste Auflage für NSX 6.2.6.
    21. Februar 2017: Zweite Auflage für NSX 6.2.6. Änderungen zu Problem 1772911.
    30. März 2017: Dritte Auflage für NSX 6.2.6. Bekanntes Problem 1474650 wurde hinzugefügt.
    10. April 2017: Vierte Auflage für NSX 6.2.6. Die Tabelle der empfohlenen Mindestversionen wurde ergänzt.
    14. April 2017: Fünfte Auflage für NSX 6.2.6. Bekanntes Problem 1833934 wurde hinzugefügt.
    20. April 2017: Sechste Auflage für NSX 6.2.6. Die behobenen Probleme 1663902 und 1717370 wurden hinzugefügt.
    21. August 2017: Siebte Auflage für NSX 6.2.6. Problem wurde gelöscht.