Versionshinweise zu VMware NSX for vSphere 6.2.0

|

VMware NSX for vSphere 6.2.0 | 20. August 2015 | Build 2986609 | Dokument aktualisiert am 22. November 2015

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

Neuigkeiten

NSX for vSphere 6.2 beinhaltet 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.

    • 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. Zudem wird mit dieser Funktion der Verlust von Konfigurationsmeldungen vom NSX Manager erkannt, bevor diese auf einen Host angewendet werden, und der Host wird angewiesen, seine NSX-Konfiguration neu zu laden, wenn solche Meldungsfehler auftreten.

    • CLI des eigenständigen Edge L2-VPN-Clients: In Versionen vor NSX 6.2 konnte ein eigenständiger NSX Edge L2-VPN-Client nur über OVF-Parameter 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. Das OVF-Tool wird jetzt nur für die erstmalige Konfiguration verwendet.

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

    • Funktion zur Beibehaltung von VLAN-Tags über VXLAN.

    • 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 Integritätsprü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. In NSX 6.2 wird die Option zur Erkennung der IP-Adresse der VM mithilfe von DHCP-Snooping oder ARP-Snooping eingeführt. Mit diesen neuen Erkennungsmechanismen kann NSX die auf IP-Adressen basierten Sicherheitsregeln 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 1.0.2: Mit der Version NSX 6.2 steht das NSX-vRO-Plug-In v1.0.2 in vRealize Automation (vRA) bereit.

Systemanforderungen und Installation

Guest Introspection- und Network Introspection-basierte Funktionen in NSX sind mit bestimmten VMware Tools (VMTools)-Versionen kompatibel. Um die im Lieferumfang von VMware Tools enthaltene optionale NSX Network Introspection Driver-Komponente zu aktivieren, ist ein Upgrade von VMware Tools auf die folgenden Versionen erforderlich:

  • VMware Tools 5.1 P07 und höher

  • VMware Tools 5.5 P04 und höher

  • VMware Tools 6.0

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

Upgrade-Hinweise

  • Die VMware-Produkt-Interoperabilitätsmatrix bietet Details zu unterstützten Upgrade-Pfaden für VMware NSX.

  • Upgrades von NSX 6.1.5 auf NSX 6.2.0 werden nicht unterstützt. Stattdessen müssen Sie ein Upgrade von NSX 6.1.5 auf NSX 6.2.1 oder höher durchführen.

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

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

  • Die Speicher- und CPU-Anforderungen für die Installation und das Upgrade von NSX Manager haben sich geändert. Informationen hierzu finden Sie unter Systemanforderungen für NSX in der Dokumentation NSX 6.2-Installation oder NSX 6.2-Upgrade.

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

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

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

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

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

  • 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.
  • Vor dem Upgrade von VMware vCloud Network and Security 5.x auf VMware NSX for vSphere 6.2: Wenn Sie ein Upgrade auf VMware NSX for vSphere 6.2 von VMware vCloud Network and Security 5.5.x planen, überprüfen Sie, ob die Informationen zum Uplink-Portnamen in den Tabellen fehlen, indem Sie den folgenden REST-API-Aufruf ausführen:
    GET https://<nsxmgr-IP>/api/2.0/vdn/switches
    Suchen Sie in der Ausgabe nach dem Feld uplinkPortName. Beispiel:

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

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

Bekannte Probleme

Bekannte Probleme gliedern sich wie folgt:

Allgemeine bekannte Probleme

Distributed Logical Router schlagen mit der Fehlermeldung Würde blockieren fehl
Bei Distributed Logical Routern von NSX kann es vorkommen, dass diese nach Änderungen der Hostkonfiguration nicht mehr funktionieren. Dies tritt dann auf, wenn vSphere keinen erforderlichen VDR-Port auf dem Host erstellen kann. Dieser Fehler tritt als DVPort-Verbindungsfehler in vmkernel.log oder als SIOCSIFFLAGS-Fehler im Gastbetriebssystem auf. Dies kann der Fall sein, wenn VIBs geladen werden, nachdem die vDS-Eigenschaften (vSphere Distributed Switch) durch vCenter übertragen wurden.

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

In VMware ESXi 5.x und 6.x wird bei der IP-Ermittlung ein violetter Diagnosebildschirm (auch als PSOD bezeichnet) angezeigt
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.

Problemumgehung: Anweisungen hierzu finden Sie unter http://kb.vmware.com/kb/2134329.

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

Problemumgehung: Keine.

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

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

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

Problemumgehung: Keine.

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

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

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.

Problemumgehung: Keine.

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

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

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

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

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

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

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

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

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

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

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

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

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

Einschalten der Gast-VM nicht möglich
Beim Einschalten einer Gast-VM wird möglicherweise die Fehlermeldung Zurzeit sind nicht alle erforderlichen virtuellen Agentmaschinen bereitgestellt angezeigt.

Problemumgehung: Führen Sie die folgenden Schritte aus:

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

Bekannte Installations- und Upgrade-Probleme

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

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 zuerst angezeigte Fehlermeldung (dies kann beispielsweise 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 DVS-Eigenschaften durch vCenter übertragen wurden. Dies kann während des Upgrades geschehen.

Problemumgehung: In NSX 6.1.4 und früher ist zum Beheben dieser Art von DVPort-Fehlern in Sites mit einem logischen NSX-Router ein zusätzlicher Neustart erforderlich. In NSX 6.2.0 wird eine Problemminderung mit der NSX-Software zur Verfügung gestellt. Mit dieser Problemminderung ist in den meisten Fällen kein zweiter Neustart mehr erforderlich. Die Hauptursache ist ein bekanntes Problem in vSphere. Details dazu finden Sie im VMware-Knowledgebase-Artikel 2107951. Beachten Sie, dass für NSX 6.1.x-Kunden diese Minderung auch in NSX 6.1.5 und höher verfügbar ist.

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

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

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

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

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

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

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

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

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

    shell.set --enabled True

    shell

    localhost:~ # cd /bin

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

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

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

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

    service-control --stop vsphere-client

    service-control --start vsphere-client

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

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

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

Problemumgehung: Keine.

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

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

  • Die Bereitstellung der virtuellen Maschine wurde abgeschlossen.

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

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

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

Wenn in Ihrer Umgebung nicht alle Cluster vorbereitet sind, wird die Upgrade-Meldung für Distributed Firewall auf der Registerkarte „Hostvorbereitung“ der Installationsseite nicht angezeigt
Wenn Sie Cluster für die Netzwerkvirtualisierung vorbereiten, ist Distributed Firewall auf diesen Clustern aktiviert. Wenn in Ihrer Umgebung nicht alle Cluster vorbereitet sind, wird die Upgrade-Meldung für Distributed Firewall auf der Registerkarte „Hostvorbereitung“ nicht angezeigt.

Problemumgehung: Verwenden Sie den folgenden REST-Aufruf, um die Distributed Firewall zu aktualisieren:

PUT https://<nsxmgr-ip>/api/4.0/firewall/globalroot-0/state

Wenn eine Dienstgruppe nach dem Upgrade geändert wird und Dienste hinzugefügt oder entfernt werden, werden diese Änderungen nicht in der Firewall-Tabelle widergespiegelt.
Von Benutzern erstellte Dienstgruppen werden in der Edge-Firewall-Tabelle beim Upgrade erweitert, d. h., in der Spalte „Service“ in der Firewall-Tabelle werden alle Dienste innerhalb der Dienstgruppe angezeigt. Wenn die Dienstgruppe nach dem Upgrade zum Hinzufügen oder Entfernen von Diensten modifiziert wird, werden diese Änderungen nicht in der Firewall-Tabelle widergespiegelt.

Problemumgehung: Erstellen Sie eine neue Dienstgruppe mit einem anderen Namen und verwenden Sie dann diese Dienstgruppe in der Firewallregel.

Die Dienst-VM, die über die Registerkarte "Dienstbereitstellungen" auf der Installationsseite bereitgestellt wurde, wird nicht eingeschaltet

Problemumgehung: Befolgen Sie die unten beschriebenen Schritte.

  1. Entfernen Sie die Dienst-VM manuell vom ESX Agent-Ressourcenpool im Cluster.
  2. Klicken Sie auf Networking and Security und anschließend auf Installation.
  3. Klicken Sie auf die Registerkarte Dienstbereitstellungen.
  4. Wählen Sie den entsprechenden Dienst aus und klicken Sie auf das Symbol Auflösen.
    Die Dienst-VM wird neu bereitgestellt.

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

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

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

Problemumgehung: Keine.

Nach dem Upgrade von vCloud Networking and Security 5.5.3 auf NSX for vSphere 6.0.5 oder höher wird NSX Manager nicht gestartet, wenn Sie ein SSL-Zertifikat mit Schlüsselgröße DSA-1024 verwenden
SSL-Zertifikate mit der Schlüsselgröße DSA-1024 werden ab NSX for vSphere 6.0.5 nicht unterstützt, daher kann das Upgrade nicht erfolgreich durchgeführt werden.

Problemumgehung: Importieren Sie ein neues SSL-Zertifikat mit einer unterstützten Schlüsselgröße, bevor Sie das Upgrade starten.

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

Nach dem Aktualisieren von NSX von Version 6.0 auf 6.0.x oder 6.1 sind keine NSX Edges auf der Benutzeroberfläche aufgeführt
Wenn Sie von NSX 6.0 auf NSX 6.0.x oder NSX 6.1 aktualisieren, wird das vSphere Web Client-Plug-In möglicherweise nicht ordnungsgemäß aktualisiert. Dies kann zu Anzeigeproblemen auf der Benutzeroberfläche führen, wie zum Beispiel fehlende NSX Edges.
Dieses Problem tritt nicht beim Aktualisieren von NSX 6.0.1 oder höher auf.

Problemumgehung: Befolgen Sie die unten beschriebenen Schritte.

  1. Klicken Sie auf der vCenter Mob-Benutzeroberfläche auf Inhalt.

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

  3. Suchen Sie nach dem Eigenschaftswert extensionList (zum Beispiel: com.vmware.vShieldManager) und kopieren Sie die Zeichenfolge.

  4. Klicken Sie im Bereich „Methoden“ auf UnregisterExtension.

  5. Fügen Sie im Feld „Wert“ die Zeichenfolge ein, die Sie in Schritt 3 kopiert haben.

  6. Klicken Sie auf Methode aufrufen.

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

NSX Edge-Upgrade schlägt fehl, wenn L2 VPN auf Edge aktiviert ist
L2 VPN-Konfigurations-Upgrade von 5.x oder 6.0.x auf 6.1 wird nicht unterstützt. Deshalb schlägt das Upgrade von Edge fehl, wenn L2 VPN darauf konfiguriert ist.

Problemumgehung: Löschen Sie die L2 VPN-Konfiguration vor dem Aktualisieren von NSX Edge. Konfigurieren Sie L2 VPN nach dem Upgrade neu.

Wird vCenter während des NSX for vSphere-Upgradevorgangs neu gestartet, wird ein falscher Clusterstatus angezeigt
Wenn Sie während eines Upgrades eine Hostvorbereitung in einer Umgebung mit mehreren für NSX vorbereiteten Clustern durchführen und der vCenter Server neu gestartet wird, nachdem mindestens ein Cluster vorbereitet wurde, wird für die übrigen Cluster möglicherweise statt eines Updatelinks der Clusterstatus „Nicht bereit“ angezeigt. Für die Hosts in vCenter wird möglicherweise zudem „Neustart erforderlich“ angezeigt.

Problemumgehung: Starten Sie vCenter während der Hostvorbereitung nicht neu.

Kurzzeitiger Verlust des Virenschutzes bei Antivirensoftware von Drittanbietern während des Upgrades
Das Upgrade von NSX 6.0.x auf NSX 6.1.x oder 6.2.0 kann kurzzeitig den Virenschutz durch Antivirensoftware von Drittanbietern außer Kraft setzen. Dieses Problem tritt beim Upgrade von NSX 6.1.x auf NSX 6.2 nicht auf.

Problemumgehung: Keine.

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

Problemumgehung: Verwenden Sie den folgenden REST-API-Aufruf, um die Kommunikation zwischen NSX Manager und einem einzelnen Host oder allen Hosts in einem Cluster zurückzusetzen.

POST https://<NSX Manager IP>/api/2.0/nwfabric/configure?action=synchronize

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

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

Problemumgehung: Keine.

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

Problemumgehung: Keine.

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

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

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

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

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

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

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

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

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

Problemumgehung: Starten Sie den ESXi-Host neu und fahren Sie mit dem Upgrade fort.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Problemumgehung: Keine.

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

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

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

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

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

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

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

Problemumgehung: Wenn eine NSX Manager-Sicherung wiederhergestellt wird, werden Sie vom Appliance Manager abgemeldet. Warten Sie ein paar Minuten, bevor Sie sich beim vSphere Web Client anmelden.

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

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

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

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

Der Data Security-Dienst wird als betriebsbereit eingestuft, obwohl die IP-Verbindung nicht hergestellt wurde
Die Data Security-Appliance hat möglicherweise nicht die IP-Adresse von DHCP erhalten oder ist mit einer falschen Portgruppe verbunden.

Problemumgehung: Stellen Sie sicher, dass die Data Security-Appliance die IP-Adresse vom DHCP/IP-Pool bezieht und über das Verwaltungsnetzwerk erreicht werden kann. Überprüfen Sie, ob Ping für die Data Security-Appliance von NSX/ESX aus erfolgreich ausgeführt wird.

Bekannte Probleme bei NSX Manager

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

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

Registerkarte „Networking & Security“ wird im vSphere Web Client nicht angezeigt
Nach dem Upgrade von vSphere auf Version 6.0 wird die Registerkarte „Networking & Security“ nicht angezeigt, wenn Sie sich mit dem Root-Benutzernamen beim vSphere Web Client anmelden.

Problemumgehung: Melden Sie sich als „administrator@vsphere.local“ oder als beliebiger anderer vCenter-Benutzer an, der vor dem Upgrade in vCenter Server vorhanden war und dessen Rolle in NSX Manager definiert war.

Nach der Wiederherstellung der NSX Manager-Sicherung zeigt der REST-Aufruf den Status der Fabric-Funktion com.vmware.vshield.nsxmgr.messagingInfra in Rot an
Wenn Sie die Sicherung einer NSX Manager-Instanz wiederherstellen und den Status der Fabric-Funktion com.vmware.vshield.nsxmgr.messagingInfra unter Verwendung eines REST-API-Aufrufs überprüfen, wird der Status in Rot und nicht in Grün angezeigt.

Problemumgehung: Verwenden Sie den folgenden REST-API-Aufruf, um die Kommunikation zwischen NSX Manager und einem einzelnen Host oder allen Hosts in einem Cluster zurückzusetzen.

POST https://<NSX Manager IP>/api/2.0/nwfabric/configure?action=synchronize

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

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

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

vMotion von NSX Manager zeigt möglicherweise folgenden Fehler an: „Die virtuelle Ethernet-Karte 'Netzwerkadapter 1' wird nicht unterstützt“
Sie können diesen Fehler ignorieren. Das Netzwerk funktioniert nach vMotion ordnungsgemäß.

Syslog zeigt den Hostnamen der gesicherten NSX Manager-Instanz im wiederhergestellten NSX Manager an
Angenommen, der Hostname des NSX Manager lautet „A“ und eine Sicherungskopie wird für diesen NSX Manager erstellt. Nun wird ein zweiter NSX Manager installiert und gemäß den Sicherungs- und Wiederherstellungsdokumenten mit derselben IP-Adresse wie die alte Manager-Instanz konfiguriert, aber der Hostname lautet „B“. Die Wiederherstellung wird für diesen NSX Manager ausgeführt. Für den wiederhergestellten NSX Manager wird der Hostname „A“ unmittelbar nach der Wiederherstellung und wiederum der Hostname „B“ nach dem Neustart angezeigt.

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

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

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

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

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

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

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

  1. Melden Sie sich beim vSphere Web Client an.

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

  3. Klicken Sie auf die Registerkarte Firewall.

  4. Klicken Sie auf die Registerkarte Gespeicherte Konfigurationen.

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

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

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

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

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

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

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

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

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

  4. Klicken Sie auf Bearbeiten neben DNS-Server.

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

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

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

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

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

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

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

Problemumgehung: Keine.

Bekannte Probleme bei NSX Edge und logischem Routing

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

  • Richtung: OUT
  • Aktion: Deny
  • Netzwerk: Beliebig

Problemumgehung: Keine.

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

Problemumgehung: Keine.

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

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

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

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

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

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

  1. Legen Sie für den DNS-Client-XML-Server dieselben Einstellungen wie für die Weiterleitung fest.

  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-Datei angegeben sind.

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

    Problemumgehung: Keine.

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

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

    1. Wechseln Sie zum vCenter-MOB (Managed Object Browser), indem Sie Folgendes in einem Browserfenster eingeben:
      https://<vc-ip>/mob?vmodl=1
    2. Klicken Sie auf Inhalt.
    3. Rufen Sie den dvsUuid-Wert wie folgt ab:
      1. Klicken Sie auf den Root-Ordner-Link (zum Beispiel „group-d1(Datacenters)“).
      2. Klicken Sie auf den Datencenternamen-Link (zum Beispiel „datacenter-1“).
      3. Klicken Sie auf den networkFolder-Link (zum Beispiel group-n6).
      4. Klicken Sie auf den DVS-Namen-Link (zum Beispiel „dvs-1“).
      5. Kopieren Sie den Wert von uuid.
    4. Klicken Sie auf DVSManager und dann auf updateOpaqueDataEx.
    5. Fügen Sie in selectionSet folgendes XML-Segment hinzu.
      <selectionSet xsi:type="DVPortSelection">
        <dvsUuid>value</dvsUuid>
        <portKey>value</portKey> <!--Portnummer der DVPG, auf der Trunk-vNIC verbunden wurde-->
      </selectionSet>
    6. Fügen Sie in opaqueDataSpec folgendes XML-Segment hinzu:
      <opaqueDataSpec>
        <operation>remove</operation>
        <opaqueData>
          <key>com.vmware.net.vxlan.trunkcfg</key>
          <opaqueData></opaqueData>
        </opaqueData>
      </opaqueDataSpec>
    7. Setzen Sie isRuntime auf "false".
    8. Klicken Sie auf Methode aufrufen.
    9. Wiederholen Sie die Schritte 5 bis 8 für jeden Trunk-Port, der auf der gelöschten Edge-VM konfiguriert wurde.

    Bekannte Probleme bei Sicherheitsdiensten

    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.

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

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

    Name der Sicherheitsrichtlinie darf nicht länger als 229 Zeichen sein
    In das Feld für den Namen der Sicherheitsrichtlinie auf der Registerkarte „Sicherheitsrichtlinie“ von Service Composer können bis zu 229 Zeichen eingegeben werden. Grund hierfür ist, dass den Richtliniennamen intern ein Präfix vorangestellt wird.

    Problemumgehung: Keine.

    Einige Versionen der Palo Alto Networks VM-Serie funktionieren nicht mit Standardeinstellungen von NSX Manager
    Einige Komponenten von NSX 6.1.4 deaktivieren SSLv3 standardmäßig. Stellen Sie vor dem Upgrade sicher, dass keine der in Ihre NSX-Bereitstellung eingebundenen Drittanbieterlösungen von der SSLv3-Kommunikation abhängt. Zum Beispiel erfordern einige Versionen der Lösung der Palo Alto Networks VM-Serie Unterstützung für SSLv3. Bitten Sie deshalb Ihre Anbieter um die entsprechenden Versionsanforderungen.

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

    Wenn Sie die Firewall-Konfiguration mit einem REST-API-Aufruf löschen, können Sie gespeicherte Konfigurationen nicht laden oder veröffentlichen
    Wenn Sie die Firewall-Konfiguration löschen, wird ein neuer Standardabschnitt mit einer neuen Abschnitts-ID erstellt. Wenn Sie einen gespeicherten Entwurf laden (der denselben Abschnittsnamen aber eine ältere Abschnitts-ID besitzt), kommt es zu einem Konflikt bei den Abschnittsnamen und es wird der folgende Fehler angezeigt:
    Doppelter Schlüsselwert verletzt eindeutige Beschränkung firewall_section_name_key

    Problemumgehung: Führen Sie einen der folgenden Schritte durch:

    • Benennen Sie den aktuellen Standard-Firewall-Abschnitt nach dem Laden einer gespeicherten Konfiguration um.
    • Benennen Sie den Standardabschnitt in einer geladenen gespeicherten Konfiguration vor dem Veröffentlichen um.

    Bekannte Probleme bei Überwachungsdiensten

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

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

    Behobene Probleme

    Die folgenden Probleme wurden in Version 6.2.0 behoben.

    Behobene Probleme gliedern sich wie folgt:

    Behobene Installations- und Upgrade-Probleme

    • Nach dem Upgrade von NSX for vSphere von Version 6.0.7 auf Version 6.1.3 stürzt der vSphere Web Client im Anmeldebildschirm ab
      Nach dem Upgrade von NSX Manager von 6.0.7 auf 6.1.3 werden im Anmeldebildschirm der vSphere Web Client-Benutzeroberfläche Ausnahmen angezeigt. Sie können sich weder bei vCenter noch bei NSX Manager anmelden und keine Vorgänge in vCenter oder NSX Manager ausführen.

      Dieses Problem wurde in NSX 6.2.0 behoben.

    • Die Guest Introspection-Installation schlägt mit einem Fehler fehl
      Beim Installieren von Guest Introspection auf einem Cluster schlägt die Installation mit dem folgenden Fehler fehl:
      Ungültiges Format für VIB-Modul

      Dieses Problem wurde in NSX 6.2.0 behoben.

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

    • Nach einem Neustart von NSX Edge kann der Start des Nachrichtenbusses fehlschlagen
      Nach dem Neustart einer Edge-VM kann der Nachrichtenbus nach dem Einschalten häufig nicht gestartet werden und ein weiterer Neustart ist erforderlich.

      Dieses Problem wurde in NSX 6.2.0 behoben.

    Behobene Probleme beim NSX Manager

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

    • Für den Import eines von der Zertifizierungsstelle signierten Zertifikats muss der NSX Manager neu gestartet werden, damit es wirksam wird
      Wenn Sie ein von der Zertifizierungsstelle signiertes NSX Manager-Zertifikat importieren, wird das neu importierte Zertifikat erst wirksam, nachdem Sie den NSX Manager neu gestartet haben.

      Dieses Problem wurde in NSX 6.2.0 behoben.

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

    • NSX Manager funktioniert nach dem Ausführen des Befehls write erase nicht mehr
      Wenn Sie NSX Manager nach dem Ausführen des Befehls write erase neu starten, arbeitet NSX Manager möglicherweise nicht wie erwartet. Beispiel: Das Kennwort für den Zugriff auf die Linux-Shell wurde zurückgesetzt, der Setup-Befehl fehlt usw.

      Dieses Problem wurde in NSX 6.2.0 behoben.

    Behobene Probleme bei logischen Netzwerken

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

    • Im Bridge- oder Mandantennamen für den logischen Router können keine Nicht-ASCII-Zeichen hinzugefügt werden
      NSX-Controller-APIs unterstützen Nicht-ASCII-Zeichen nicht.

      Dieses Problem wurde in NSX 6.2.0 behoben.

    • Bei der Änderung einer BGP-Nachbar-Filterregel werden die vorhandenen Filter möglicherweise bis zu 40 Sekunden lang nicht angewendet
      Wenn BGP-Filter auf einen NSX Edge angewendet werden, auf dem IBGP ausgeführt wird, kann es möglicherweise bis zu 40 Sekunden dauern, bis die Filter im Rahmen der IBGP-Sitzung angewendet werden. Zu diesem Zeitpunkt kündigt NSX Edge möglicherweise Routen an, die im BGP-Filter für den IBGP-Peer verweigert werden.

      Dieses Problem wurde in NSX 6.2.0 behoben.

    • Einer der NSX Controller übergibt die Masterrolle beim Herunterfahren nicht an andere Controller
      Ein Controller, der die Masterrolle für die Vorgänge übernommen hat und kurz vor dem Herunterfahren steht, übergibt in der Regel automatisch die Masterrolle an andere Controller. In diesem Fall übergibt der Controller die Rolle nicht an andere Controller, der Status lautet „unterbrochen“, und der Modus „unterbrochen“ ist aktiv.

      Dieses Problem wurde in NSX 6.2.0 behoben.

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

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

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

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

    Behobene Probleme bei Netzwerk- und Edge-Diensten

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

    Behobene Probleme bei Sicherheitsdiensten

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

    • In der Benutzeroberfläche wird die sinngemäße Fehlermeldung Firewall-Veröffentlichung fehlgeschlagen angezeigt
      Angenommen, Distributed Firewall ist für einen Teil der Cluster in Ihrer Umgebung aktiviert und Sie aktualisieren eine Anwendungsgruppe, die in einer oder mehreren aktiven Firewallregeln verwendet wird. In diesem Fall wird für jeden Veröffentlichungsvorgang in der Benutzeroberfläche eine Fehlermeldung mit IDs der Hosts angezeigt, die zu den Clustern gehören, für die die NSX-Firewall nicht aktiviert ist.
      Trotz der Fehlermeldungen werden die Regeln erfolgreich veröffentlicht und auf den Hosts erzwungen, auf denen Distributed Firewall aktiviert ist.

      Dieses Problem wurde in NSX 6.2.0 behoben.

    • Beim Löschen von Sicherheitsregeln über REST wird ein Fehler angezeigt
      Wenn ein REST-API-Aufruf verwendet wird, um Sicherheitsregeln zu löschen, die durch Service Composer erstellt wurden, wird der entsprechende Regelsatz nicht im Cache des Dienstprofils gelöscht. Dies führt zu dem Fehler ObjectNotFoundException.

      Dieses Problem wurde in NSX 6.2.0 behoben.

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

    • Die Synchronisierung der Firewall geht verloren, da Sicherheitsrichtlinien als Portbereich konfiguriert sind
      Durch die Konfiguration von Sicherheitsrichtlinien als Portbereich (z. B. „5900-5964“) geht die Synchronisierung der Firewall verloren und die Fehlermeldung NumberFormatException wird angezeigt.

      Dieses Problem wurde in NSX 6.2.0 behoben.

    Behobene Probleme bei Überwachungsdiensten

    • 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 0M/s angezeigt, aber nicht die Bandbreite/Geschwindigkeit der Schnittstelle von NSX Edge vNic_0.

      Dieses Problem wurde in NSX 6.2.0 behoben.

    • Wenn IPFix-Konfiguration für Distributed Firewall aktiviert ist, werden Firewallports in der ESXi-Verwaltungsschnittstelle für NetFlow für vDS oder SNMP möglicherweise entfernt
      Wenn ein Collector-IP und ein Port für IPFix definiert sind, wird die Firewall für die ESXi-Verwaltungsschnittstelle in der Ausgangsrichtung für die festgelegten UDP-Collector-Ports geöffnet. Mit dieser Operation wird die dynamische Regelsatzkonfiguration auf der ESXi-Verwaltungsschnittstellen-Firewall eventuell für die folgenden Dienste entfernt, wenn sie zuvor auf dem ESXi-Host konfiguriert waren:

      • Konfiguration des Netflow-Collector-Ports auf vDS

      • Konfiguration des SNMP-Zielports


      Dieses Problem wurde in NSX 6.2.0 behoben.

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

    Behobene Probleme bei der Lösungsinteroperabilität

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

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

      Dieses Problem wurde in NSX 6.2.0 behoben.

    Revisionsverlauf der Dokumente

    20. August 2015: Erste Auflage für NSX 6.2.0.
    4. September 2015: Zweite Auflage für NSX 6.2.0. Nicht benötigte Upgrade-Warnung wurde entfernt.
    22. November 2015: Dritte Auflage für NSX 6.2.0. Das Würde-blockieren-Problem (1328589) wurde von der Liste der behobenen Probleme in die Liste der bekannten Probleme übertragen. Dies bleibt ein bekanntes Problem, bis in vSphere ein Fix bereitgestellt wird. In NSX 6.1.5 und 6.2.0 wird eine Problemminderung zur Verfügung gestellt.