Versionshinweise zu VMware NSX for vSphere 6.2.8

|

VMware NSX for vSphere 6.2.8   |   Veröffentlicht am 6. Juli 2017  |   Build 5901733

Siehe den Revisionsverlauf dieses Dokuments.

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

Neuigkeiten

Behobene kritische Probleme: Diese Version enthält eine Reihe kritischer behobener Probleme und Sicherheits-Updates. Darüber hinaus wurden die Protokollierungsinformationen bezüglich VTEP verbessert. Weitere Informationen finden Sie im Abschnitt Behobene Probleme.

 

Im Folgenden finden Sie die neuen und geänderten Funktionen in NSX 6.2.7, 6.2.6, 6.2.5, 6.2.4, 6.2.3, 6.2.2, 6.2.1 und 6.2.0.

Versionen, Systemanforderungen und Installation

Hinweis:

  • In der folgenden Tabelle sind empfohlene Versionen von VMware-Software aufgelistet.  Diese Empfehlungen sind allgemeiner Natur. Umgebungsspezifische Empfehlungen haben demgegenüber Vorrang.

  • Diese Informationen sind auf dem Stand des Veröffentlichungsdatums dieses Dokuments.

  • Die unterstützten Mindestversionen von NSX und anderen VMware-Produkten entnehmen Sie der VMware-Produkt-Interoperabilitätsmatrix. Die Einstufung als unterstützte Mindestversionen durch VMware erfolgt auf der Basis interner Tests.

Produkt oder Komponente Empfohlene Version
NSX for vSphere

VMware empfiehlt die neueste NSX for vSphere-Version für neue Bereitstellungen.

Wenn Sie für vorhandene Bereitstellungen ein Upgrade durchführen möchten, lesen Sie bitte die NSX-Versionshinweise oder wenden Sie sich an einen Mitarbeiter des technischen Supports von VMware für weitere Informationen zu spezifischen Problemen, bevor Sie ein Upgrade planen.

  • NSX for vSphere 6.2.4 behebt ein bekanntes Problem mit SSL VPN. Weitere Informationen finden Sie unter CVE-2016-2079. Kunden, die Version 6.2.2 oder niedriger verwenden, wird dringend empfohlen, ein Upgrade durchzuführen.
  • NSX for vSphere 6.2.4 mit vSphere 6.0 Update 3 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.
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 mit NSX for vSphere 6.2.4 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 oder höher
vCloud Director (vCD)
  • vCD 8.0 oder höher bei Migration von vCNS auf NSX
  • vCD 8.10.1 oder höher, wenn NSX bereits vorhanden ist

Systemanforderungen und Installation

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

Anweisungen zur Installation erhalten Sie im Installationshandbuch für NSX oder im Installationshandbuch zu Cross-vCenter 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 galt 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 galt als Ende der Verfügbarkeit (EOA, End of Availability) und des allgemeinen Supports (EOGS, End of General Support) der 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.

  • Für das Upgrade auf NSX 6.2.4 oder höher 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.

     

  • Mindestens 8 GB Arbeitsspeicher erforderlich: Ein Upgrade auf NSX 6.2.3 oder später kann auf Hosts mit weniger als 8 GB Arbeitsspeicher scheitern.
  • 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).
  • Bevor Sie ein Upgrade auf NSX 6.2.5 oder höher vornehmen, stellen Sie sicher, dass alle Lastenausgleichsdienst-Verschlüsselungslisten durch Doppelpunkte getrennt sind. 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>
  • 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.

  • Zur Überprüfung, ob Ihr Upgrade auf NSX 6.2.x erfolgreich durchgeführt wurde, erhalten Sie Erläuterungen im Knowledgebase-Artikel 2134525.
  • Kompatibilität mit Partnerdiensten: Wenn Ihre Site VMware-Partnerdienste für Guest Introspection oder für die Netzwerk-Introspektion 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.

Revisionsverlauf der Dokumente

6. Juli 2017: Erste Auflage. 
21. August 2017: Zweite Auflage. Probleme 1904842, 1878081 und 1910593 wurden hinzugefügt.
2. Oktober 2017: Dritte Auflage. Empfohlene Mindestversionen für NSX wurden aktualisiert.

Behobene Probleme

Die behobenen Probleme werden in die im Folgenden aufgeführten Kategorien unterteilt.

In NSX 6.2.8 behobene Probleme der Installation und des Upgrades
  • Behobenes Problem 1854519: VMs verlieren die Nord-Süd-Verbindung nach der Migration von einem VLAN zu einem überbrückten VXLAN

    Wenn das VM-Netzwerk von einem VLAN auf ein überbrücktes VXLAN auf dem DLR umgestellt wird, geht der eingehende Datenverkehr zur virtuellen Maschine verloren. Problem in 6.2.8 behoben.

In NSX 6.2.8 behobene Netzwerk- und Edge-Dienste-Probleme
  • Behobenes Problem 1849037: NSX Manager-API-Threads sind ausgeschöpft, wenn die Kommunikationsverbindung mit NSX Edge unterbrochen ist
    Wenn der Kommunikationskanal zwischen NSX Manager und der NSX Edge-VM unterbrochen ist, hängen die Status-/Statistikanforderungen an die Edge-VM und blockieren den API-Thread. Mehrere solcher Anforderungen können dazu führen, dass alle API-Threads ausgeschöpft werden. Problem in 6.2.8 behoben.

  • Behobenes Problem 1865394: Traffic-Shaping-Richtlinie wird im DvPortGroup-Port nicht gelöscht
    Die Traffic-Shaping-Richtlinie (TSP) wird für den mit der NSX Edge-vNIC verbundenen DvPortGroup-Port festgelegt, wenn Sie den Port konfigurieren. Erwartet wird, dass die TSP gelöscht wird, wenn eine vNIC von diesem Port getrennt wird. Die folgenden, vom NSX Manager ausgelösten Fälle führen dazu, dass der mit der NSX Edge-vNIC verbundene DvPortGroup-Port geändert/getrennt wird:
    • NSX Edge wird erneut bereitgestellt
    • NSX Edge wird aktualisiert
    • NSX Edge wird getrennt und erneut verbunden
    • Größe der NSX Edge-Appliance wird geändert
    • NSX Edge-Schnittstelle wird gelöscht
    • NSX Edge wird gelöscht
    Problem in 6.2.8 behoben.

  • Behobenes Problem 1704940: Es kann vorkommen, dass auf dem ESXi-Host der violette Diagnosebildschirm angezeigt wird, wenn die Anzahl der pCPUs 256 überschreitet
    NSX-DLR besitzt eine Flow-Tabelle pro pCPU und die Anzahl der pCPUs ist auf 256 beschränkt. Daher kommt es zu einem Absturz, wenn die Anzahl der pCPUs 256 überschreitet. Problem in 6.2.8 behoben.

  • Behobenes Problem 1892265: Das NSX Edge-Dateipaket wird nicht nach jedem Veröffentlichen aus dem Verzeichnis /common/tmp gelöscht, weshalb das Verzeichnis /common voll wird
    Das Verzeichnis /common wird voll und für NSX Manager ist nicht mehr genügend Speicherplatz verfügbar, weil das NSX Edge-Dateipaket (sslvpn-plus config) nicht aus /common/tmp gelöscht wird. Problem in 6.2.8 behoben.

  • Behobenes Problem 1681063: Der VPN Tunnel-Status einiger Edge Gateways wird in vCloud Director nicht korrekt angegeben.

    vCloud Director (vCD) und NSX zeigen unterschiedliche Statuszustände für IPSec VPN Tunnel an. vCD zeigt den IPSec Tunnel als ausgeschaltet an, obwohl er eingeschaltet ist und der Datenverkehr durchläuft. Problem in 6.2.8 behoben.

  • Behobenes Problem 1849760: Routing-Vorgang blockiert eventuell CPU-Leistung, wenn bestimmte Präfixe über das IBGP-Netzwerk abgerufen werden, etwa wenn der nächste Hop zum Präfixsubnetz gehört

    Das Problem tritt bei einer Konfiguration mit einem Peering der DLR-Kontroll-VM mit ESGs über IBGP und einem Peering der ESGs mit physischen Routern über EBGP auf. Darüber hinaus wird für die DLR-Kontroll-VM die Hochverfügbarkeit ausgeführt. Für die BGP-Sitzung werden eng getaktete Timer verwendet. Wenn das zugrunde liegende Netzwerk instabil wird und sich dieser Zustand auf die BGP-Nachbarn überträgt, ruft die DLR-Kontroll-VM auch erneut die Präfixe für den instabilen Nachbarn ab und muss diese auflösen. Wenn das abgerufene Präfixsubnetz sich auf die IP-Adresse des nächsten Hop bezieht (z. B. 10.0.0.0/8 über 10.1.1.2), kann der Routing-Vorgang in einer rekursiven Schleife münden. Problem in 6.2.8 behoben.

In NSX 6.2.8 behobene NSX Manager-Probleme
  • Behobenes Problem 1892208: Die NSX Manager-Datenbank zeigt nur einen Datenspeicher (Speicherort der VMX-Datei) an, die Benutzeroberfläche zeigt jedoch zwei Datenspeicher an (aktuell und konfiguriert).
    Problem in 6.2.8 behoben.

  • Behobenes Problem 1861785: 100 % CPU-Auslastung bei NSX Manager mit vCloud Director (vCD) und vRealize Operations (vROps)
    Wenn die Datenbank in den Tabellen system_event_message_params und system_event_event_metadata eine erhebliche Anzahl an verwaisten Datensätzen enthält, brauchen die APIs länger, um auf Anforderungen von vCD zu antworten, und in der Zwischenzeit wird der vCD-Client getrennt, weil er dieselben APIs erneut aufruft. Dies führt zu einer hohen CPU-Auslastung. Das Entfernen von verwaisten Datensätzen behebt dieses Problem. Problem in 6.2.8 behoben.

  • Behobenes Problem 1760940: Hohe CPU-Auslastung durch NSX Manager, ausgelöst durch viele gleichzeitige vMotion-Aufgaben
    DFW ist mit dynamischen Sicherheitsgruppen konfiguriert, deren Kriterien auf VM-Name oder VM-Gastbetriebssystem basieren. Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 2150668. Problem in 6.2.8 behoben.
In NSX 6.2.8 behobene Probleme der Sicherheitsdienste
  • Behobenes Problem 1836322: „Flash-Fehler“ beim Bearbeiten von NSX-Firewallregeln
    In manchen Fällen zeigt die Benutzeroberfläche von vSphere Web Client beim Bearbeiten von Sicherheitsgruppen einen Fehler im Zusammenhang mit dem Flash-Plug-In an. Problem in 6.2.8 behoben.

  • Behobenes Problem 1832912: Wenn ein Host in den Wartungsmodus versetzt wird, verlieren einige virtuelle Maschinen dieses Hosts zuvor angewendeten Firewallregeln
    Wenn ein Host in den Wartungsmodus versetzt wird und DRS alle virtuellen Maschinen auf einen anderen Host verschiebt, verlieren einige virtuelle Maschinen dieses Hosts zuvor angewendeten Firewallregeln. Das Problem kann umgangen werden, indem keine Sicherheitsgruppen mit dynamischen Kriterien erstellt werden, die auf dem Computernamen oder dem Namen des Computer-Betriebssystems basieren. Problem in 6.2.8 behoben.

  • Behobenes Problem 1818550: Aktualisierungen von Gruppierungsobjekten auf Hosts, die eine große Anzahl von virtuellen Maschinen und verschachtelte Sicherheitsgruppen besitzen, werden verzögert

    Auf Hosts, die eine große Anzahl von virtuellen Maschinen und verschachtelte Sicherheitsgruppen besitzen, führt eine einzelne Bestandsänderung zum Leeren eines Gruppierungsobjekt-Updates, was lange Verzögerungen bei der Aktualisierung von Gruppierungsobjekten auf den Hosts verursacht. Problem in 6.2.8 behoben.

  • Behobenes Problem 1800196: Die VMkernel-Protokollierung wird beendet, wenn eine große Anzahl von IP-Paketen mit Broadcast-MAC-Adressen einer DFW-Regel für die Ablehnung entspricht

    DFW sendet Ablehnungspakete nur an Unicast-MAC-Adressen. Wenn IP-Pakete mit einer Broadcast-MAC-Adresse einer Ablehnungsregel entsprechen, wird kein Ablehnungspaket gesendet. Dieses Ereignis wird aber in der Datei vmkernel.log protokolliert. Wenn das Netzwerk mit diesem Datenverkehr geflutet wird, nimmt vmkernel.log wegen Überlastung keine Meldungen mehr auf, und die Protokollierung wird beendet. Das Ablehnen von Paketen mit Broadcast-MAC-Adressen wird jetzt nur dann protokolliert, wenn das Debugging aktiviert ist. Problem in 6.2.8 behoben. Die Ablehnung von Paketen mit Broadcast-MAC-Adressen wird jetzt nur dann protokolliert, wenn das Debugging aktiviert ist.

  • Behobenes Problem 1798537: Für den DFW-Controller-Vorgang auf ESXi (vsfwd) steht eventuell nicht mehr genügend Arbeitsspeicher zur Verfügung

    In einer Umgebung mit einer großen Anzahl an Regeln oder mit großen Sicherheitsgruppen in der DFW-Konfiguration steht für den DFW-Controller-Vorgang auf ESXi (vsfwd) eventuell nicht mehr genügend Arbeitsspeicher zur Verfügung, sodass die Regeln für den Datenpfad nicht veröffentlicht werden können. Problem in 6.2.8 behoben.

  • Behobenes Problem 1853106: In der Benutzeroberfläche werden Fehler angezeigt, wenn die Zertifizierung deaktiviert wird oder wenn bestimmte Änderungen der IPsec-Konfiguration für das IPsec-VPN im PSK-Modus bearbeitet werden

    Sie sehen die Fehlermeldung „Fehler beim Lesen von Zertifikaten und geheimen Schlüsseln. : 002 Kennwörter vergessen“ auf der Registerkarte „Globale Konfiguration“, wenn die Zertifizierung des PSK-Modus für IPsec VPN mit zertifikatsbasierter Authentifizierung deaktiviert ist oder geändert wurde. Problem in 6.2.8 behoben.

In NSX 6.2.8 behobene Probleme der Lösungsinteroperabilität
  • Behobenes Problem 1838742: Die NSX Edge-Version kann in der angezeigten Benutzeroberflächen-/API-Version und der bereitgestellten Version in der VCD-Umgebung unterschiedlich sein
    Wenn während eines Upgrades von vCNS auf NSX der NSX Manager aktualisiert wird, müssen alle vCNS-Edges aktualisiert oder explizit erneut bereitgestellt werden, bevor Bearbeitungsvorgänge in vCloud Director ausgeführt werden. Wenn das Upgrade nicht initiiert wird, kann die NSX Edge-Version, die auf der Benutzeroberfläche und in der API angezeigt wird, von der bereitgestellten Version abweichen. Problem in 6.2.8 behoben.

Bekannte Probleme

Die bekannten Probleme gliedern sich in folgende Gruppen.

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 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
  • Neues Problem 1905064: Einige Hosts im Cluster verlieren während eines Host-Upgrades die TCP-Verbindungen zu NSX Manager und Controllern
    Wenn ein ESXi-Host während eines Upgrades die TCP-Verbindung zum NSX Manager verliert, kann er keine Controllerinformationen abrufen. Dies verhindert, dass der Controller zu NSX gehörende Konfigurationen an diesen Host weitergeben kann und sorgt dafür, dass alle virtuellen Maschinen auf diesem Host die Netzwerkkonnektivität verlieren.

    Problemumgehung: Starten Sie den betroffenen Host neu.

  • Neues Problem 1910593: Bei den Antwortparametern in der NSX Manager-Upgrade-API ist die Groß-und Kleinschreibung zu beachten
    Wenn Sie die NSX API zur Durchführung eines Upgrades von NSX Manager verwenden und SSH aktivieren oder am VMware CEIP-Programm teilnehmen wollen, müssen Sie „Ja“ (und nicht „JA“) für den Antwortparameter eingeben.

    Problemumgehung: Weitere Informationen zur Durchführung eines Upgrades mithilfe der API finden Sie im API-Handbuch zu NSX.

  • Problem 1838229: HTTP/HTTPS-Transaktion schlägt auf NSX-Load Balancer nach dem Upgrade auf NSX 6.1.5 oder höher fehl.
    Ab NSX 6.1.5 wird bei Aktivierung von X-forwarded-for der HTTP-Verbindungsmodus von passivem Schließen (option httpclose) auf den Standardmodus HTTP-Server-Close (option http-server-close) geändert, wodurch nach dem Empfang einer Antwort vom Server die clientseitige Verbindung offen bleibt, während die serverseitige Verbindung geschlossen wird. Dies führt zu Problemen bei einigen Anwendungen, weil in NSX-Versionen vor 6.1.5 der Load Balancer die Verbindung nicht proaktiv schloss, sondern stattdessen den Header „Connection:close“ in beide Richtungen einfügte, um dem Client oder Server mitzuteilen, dass die Verbindung geschlossen werden soll.

    Problemumgehung: Fügen Sie eine Anwendungsregel mit dem Skript option httpclose hinzu, und verknüpfen Sie sie mit dem virtuellen Server.

  • Problem 1820723: Filter werden auf ESXi nach dem Upgrade von Version 6.2.x auf 6.2.7 aufgrund einer fehlgeschlagenen Verbindung mit dem Host nicht angezeigt
    Nach dem Upgrade von NSX 6.2.x auf 6.2.7 und der Cluster-VIBs auf 6.2.7-Bits weist der Kommunikationskanalstatus die Verbindung von NSX Manager zum Firewallagenten und von NSX Manager zum Steuerungskomponentenagenten als inaktiv aus, auch wenn die Installation als erfolgreich und die Firewall als aktiviert angezeigt wird. Dies führt zum Scheitern der Veröffentlichung von Firewallregeln und Sicherheitsrichtlinien, und die VXLAN-Konfiguration kann nicht zu den Hosts gesendet werden.

    Problemumgehung: Führen Sie den API-Aufruf zur Synchronisierung des Nachrichtenbusses für den Cluster mithilfe folgender API durch: POST:https://<NSX-IP>/api/2.0/nwfabric/configure?action=synchronize.
    API-Text:

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

  • Problem 1435504: HTTP/HTTPS-Systemzustandsprüfung ergibt nach dem Upgrade von 6.0.x oder 6.1.x auf 6.2.x INAKTIV mit der Fehlermeldung „Rückgabecode 127 ist außerhalb des gültigen Bereichs – Plug-In fehlt möglicherweise“
    Wenn in den Versionen NSX 6.0.x und 6.1.x die URLs ohne doppelte Anführungszeichen ("") konfiguriert wurden, konnte die Systemstatusprüfung nicht durchgeführt werden. Es wurde dann folgender Fehler angezeigt: „Rückgabecode 127 ist außerhalb des gültigen Bereichs – Plug-In fehlt möglicherweise“. Als Problemumgehung wurde das Hinzufügen doppelter Anführungszeichen ("") in der eingegebenen URL empfohlen (dies war nicht für die Felder send/receive/expect erforderlich). Dieses Problem wurde in Version 6.2.0 behoben, was allerdings dazu führt, dass bei einem Upgrade von 6.0.x oder 6.1.x auf 6.2.x die Mitglieder des Pools durch die zusätzlichen doppelten Anführungszeichen in der Systemzustandsprüfung als INAKTIV angezeigt werden.

    Problemumgehung: Entfernen Sie nach dem Upgrade die doppelten Anführungszeichen ("") im URL-Feld aus allen betroffenen Konfigurationen der Systemstatusprüfung.

  • 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.7 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.7 unverändert. Beachten Sie, dass bei Upgrades von älteren NSX-Versionen möglicherweise eine Versionsänderung auf 6.2.7 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 verteilte Firewall von NSX 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 1386874: 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 1375794: 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 1112628: 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 die verteilte Firewall auf der Registerkarte „Hostvorbereitung“ der Installationsseite nicht angezeigt
    Wenn Sie Cluster für die Netzwerkvirtualisierung vorbereiten, ist die verteilte Firewall auf solchen Clustern aktiviert. Wenn in Ihrer Umgebung nicht alle Cluster vorbereitet sind, wird die Upgrade-Meldung für die verteilte Firewall auf der Registerkarte „Hostvorbereitung“ nicht angezeigt.

    Problemumgehung: Verwenden Sie den folgenden REST-Aufruf, um die verteilte 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 1263858: 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 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 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 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
  • Neues Problem 1904842: NSX Manager wird nicht beim vCenter Server oder Plattform Services Controller registriert.
    NSX Manager wird nicht auf der Benutzeroberfläche angezeigt und alle an NSX Manager gesendeten REST-Aufrufe schlagen fehl.

    Problemumgehung: Starten Sie den NSX-Verwaltungsdienst oder die NSX Manager-Appliance neu.

  • Neues Problem 1826225: Dienststatus für Partnerdienst-VMs wird in NSX Manager als „Unbekannt“ gemeldet.
    Der Dienststatus für Partnerdienst-VMs wird in NSX Manager als „Unbekannt“ gemeldet. Dieses Problem tritt auf, wenn veraltete Datenbankeinträge für Partner-VMs vorhanden sind.

    Problemumgehung: Wenden Sie sich an den VMware-Kundensupport.

  • Neu Problem 1713669: NSX Manager-Festplatte füllt sich mit IDFW-Daten

    Unabhängig davon, ob IDFW-Regeln verwendet bzw. nicht verwendet werden, werden von Guest Introspection und Ereignisprotokoll-Servern erkannte Anmeldeereignisse in der NSX Manager-Datenbank gespeichert und nach ihrem Ablauf 30 Tage lang in der Datenbank vorgehalten. In Umgebungen mit einem hohen Volumen an Anmeldeaktivitäten kann die Datenbank anwachsen und sich auf den Speicherplatz auf der NSX Manager-Festplatte auswirken.

    Problemumgehung: Für dieses Problem gibt es keine Umgehung. Falls dieses Problem auftritt, wenden Sie sich an den VMware-Kundensupport.

  • Problem 1806368: Im Falle eines Cross-VC-Failovers wird die DLR-Konfiguration nicht auf alle Hosts übertragen, wenn alte Controller für einen zuvor fehlgeschlagenen primären NSX Manager, der nach einem Failover erneut als primär verwendet wird, wiederverwendet werden.
    Fällt in einem Cross-VC-Setup der primäre NSX Manager aus, wird ein sekundärer NSX Manager zu einem primären heraufgestuft und ein neuer Controller-Cluster für die Verwendung mit dem neu heraufgestuften sekundären (jetzt primären) NSX Manager bereitgestellt. Wenn der primäre NSX Manager wieder in Betrieb ist, wird der sekundäre NSX Manager herabgestuft und der primäre NSX Manager wiederhergestellt. In diesem Fall wird die DLR-Konfiguration nicht an alle Hosts weitergegeben, wenn Sie die vorhandenen Controller wiederverwenden, die auf diesem primären NSX Manager vor dem Failover bereitgestellt wurden. Dieses Problem tritt nicht auf, wenn Sie stattdessen einen neuen Controller-Cluster erstellen.

    Problemumgehung: Stellen Sie einen neuen Controller-Cluster für den wiederhergestellten primären NSX Manager bereit.

  • Problem 1831131: Verbindung vom NSX Manager zu SSO schlägt bei Authentifizierung über LocalOS-Benutzer fehl
    Verbindung vom NSX Manager zu SSO schlägt bei Authentifizierung über LocalOS-Benutzer fehl und produziert folgenden Fehler: „Verbindung zum NSX Manager konnte nicht hergestellt werden. Wenden Sie sich an den Administrator.“

    Problemumgehung: Fügen Sie die Enterprise Admin-Rolle für nsxmanager@localos zusätzlich zu nsxmanager@domain hinzu.

  • 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 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 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 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 1460766: 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 1467382: 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
  • Neues Problem 1878081: Einige der Routen wurden aus der Weiterleitungstabelle im Gateway für die Edge-Dienste gelöscht
    In einigen wenigen Instanzen wurden einige der Routen aus der Weiterleitungstabelle gelöscht. Dies führt zu einem Ausfall des Datenverkehrs.

    Problemumgehung: Starten Sie den Edge-Knoten neu.

  • Problem 1798847: In einem Cross-VC-NSX-Setup kann es vorkommen, dass die Aktualisierung des VXLAN-UDP-Ports dauerhaft hängen bleibt
    Wenn der primäre NSX Manager über keinen konfigurierten sekundären NSX Manager verfügt, bleibt die Aktualisierung des VXLAN-UDP-Ports dauerhaft hängen.

    Problemumgehung: Setzen Sie mithilfe der NSX Manager-API die Aktualisierung des Ports auf dem primären NSX Manager fort.

  • Problem 1698286: Hardware-VTEP in einer Cross-vCenter NSX-Umgebung wird nur auf dem primären NSX Manager unterstützt
    In einer Cross-vCenter NSX-Umgebung werden Hardware-Gateway-Switch-Konfigurationen und -Vorgänge nur auf dem primären NSX Manager unterstützt. Hardware-Gateway-Switches müssen an nicht universelle logische Switches gebunden sein. Hardware-Gateway-Konfigurationen werden auf sekundären NSX Managern nicht unterstützt.

    Problemumgehung: In einer Cross-vCenter NSX-Umgebung wird empfohlen, für die Verbindung von logischen Switches mit physischen Netzwerken das L2-Bridging zu verwenden.

  • Problem 1844966: NSX Edge-Dateisystem ist schreibgeschützt
    Kommt es bei einem Edge zu Konnektivitätsproblemen mit dem Speicher, kann das Edge-Dateisystem in den schreibgeschützten Status übergehen, um das Dateisystem des Betriebssystems zu schützen. Dies ist ein erwartetes Verhalten bei einem Linux-Server. Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 2146870.

    Problemumgehung: Gehen Sie wie folgt vor:

    1. Stellen Sie das Edge erneut bereit.
    2. Starten Sie das Edge (beide Edges in einem HA-Paar) neu.
    3. Erzwingen Sie eine Synchronisierung des Edge.

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

  • 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 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 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 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 1647657: Show-Befehle auf einem ESXi-Host mit VDR stellen maximal 2000 Routen pro VDR-Instanz dar

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

    Problemumgehung: Das Problem kann nicht umgangen werden.

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

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

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

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

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

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

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

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

    PUT /api/4.0/edges/{edgeId}/firewall/config/global
    <globalConfig>
    <tcpPickOngoingConnections>true</tcpPickOngoingConnections>
    </globalConfig>
  • Problem 1374523: Erforderlicher Neustart von ESXi oder erforderliche Ausführung von [services.sh restart] nach der Installation von VXLAN VIB, um die VXLAN-Befehle mit esxcli verfügbar zu machen

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

    Problemumgehung: Verwenden Sie anstelle von esxcli den Befehl localcli.

  • Problem 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 1483426: 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 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 1089238: 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 1499978: 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 1489829: 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 1281425: 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> <!--port number of the DVPG where trunk vnic got connected-->
      </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.

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.

  • 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 die verteilte Firewall 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 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 die verteilte Firewall 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 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 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.

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

Bekannte Probleme bei der Lösungsinteroperabilität
  • Problem 1840744: VMware ESXi 6.0.0-Host zeigt einen violetten Diagnosebildschirm, wenn eine virtuelle Maschine in einer Neustartschleife hängt
    Dieses Problem tritt aufgrund einer Race Condition zwischen Erstellen/Löschen-Ereignissen in DVFilter auf, die von der virtuellen Maschine in der Neustartschleife erstellt werden. Weitere Informationen finden Sie im VMware-Knowledgebase-Artikel 2149782.

    Problemumgehung: Dieses Problem wurde in VMware ESXi 6.0 Patch 03 und späteren Versionen behoben; Sie finden sie unter VMware Downloads.
    Falls Sie nicht aktualisieren möchten, schalten Sie die betroffene virtuelle Maschine aus, um dieses Problem zu umgehen.

  • 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 1845087: NSX Controller-API wird beeinträchtigt, wenn die Festplattenlatenz sehr hoch ist
    Die NSX Controller-API antwortet möglicherweise nicht innerhalb des Zeitlimits des NSX Managers, wenn die E/A-Latenz des Speichers, der vom NSX Controller verwendet wird, zu hoch ist. Dies kann wiederum Upgrade- und andere Funktionen des NSX Controllers beeinträchtigen. Das Netzwerk- und Sicherheits-Plug-in des vSphere Web Client zeigt als Fehler „Hohe Controller-Festplattenlatenz“ an, wenn der Schweregrad einen bestimmten Grenzwert überschreitet.

    Problemumgehung: Um dieses Problem zu beheben, empfiehlt VMware, eine dedizierte lokale Festplatte und SSD-Laufwerke zu verwenden.

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