This site will be decommissioned on January 30th 2025. After that date content will be available at techdocs.broadcom.com.

 

VMware SASE 5.1.0 | 18. Dezember 2023

  • VMware SASE™ Orchestrator-Version R51010-20231215-GA

  • VMware SD-WAN™ Gateway Version R5103-20230621-GA

  • VMware SD-WAN™ Edge-Version R5102-20230310-GA

Prüfen Sie, ob Ergänzungen und Updates für diese Versionshinweise zur Verfügung stehen.

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

Empfohlene Verwendung

Diese Version wird für alle Kunden empfohlen, die die Funktionen benötigen, erstmals in Version 5.1.0 zur Verfügung gestellt werden.

Kompatibilität

Version 5.1.0 für Orchestrator-Instanzen, Gateways und Hub-Edges unterstützt alle früheren Versionen von VMware SD-WAN Edge ab Version 3.4.0.

Die folgenden SD-WAN-Interoperabilitätskombinationen wurden explizit getestet:

Orchestrator

Gateway

Edge

Hub

Zweigstelle/Spoke

5.1.0 

5.1.0 

3.4.5 

3.4.5 

5.1.0 

5.1.0 

3.4.6 

3.4.6 

5.1.0 

5.1.0 

5.1.0 

3.4.5 

5.1.0 

5.1.0 

3.4.6 

5.1.0 

5.1.0 

4.2.2 

4.2.2 

4.2.2 

5.1.0 

5.1.0 

4.2.2 

4.2.2 

5.1.0 

5.1.0 

5.1.0 

4.2.2 

5.1.0 

5.1.0 

4.2.2 

5.1.0 

5.1.0 

4.3.0 

4.3.0 

4.3.0 

5.1.0 

5.1.0 

4.3.0 

4.3.0 

5.1.0 

5.1.0 

5.1.0 

4.3.0 

5.1.0 

5.1.0 

4.3.0 

5.1.0 

5.1.0 

4.3.1 

4.3.1 

4.3.1 

5.1.0 

5.1.0 

4.3.1 

4.3.1 

5.1.0 

5.1.0 

5.1.0 

4.3.1 

5.1.0 

5.1.0 

4.3.1 

5.1.0 

5.1.0 

4.5.0 

4.5.0 

4.5.0 

5.1.0 

5.1.0 

4.5.0 

4.5.0 

5.1.0 

5.1.0 

5.1.0 

4.5.0 

5.1.0 

5.1.0 

4.5.0 

5.1.0 

5.1.0 

4.5.1 

4.5.1 

4.5.1 

5.1.0 

5.1.0 

4.5.1 

4.5.1 

5.1.0 

5.1.0 

5.1.0 

4.5.1 

5.1.0 

5.1.0 

4.5.1 

5.1.0 

5.1.0 

5.0.1 

5.0.1 

5.0.1 

5.1.0 

5.1.0 

5.0.1 

5.0.1 

5.1.0 

5.1.0 

5.1.0 

5.0.1 

5.1.0 

5.1.0 

5.0.1 

5.1.0 
Hinweis:

Die obige Tabelle gilt nur für Kunden, die SD-WAN-Dienste nutzen. Kunden, die Zugriff auf VMware Cloud Web Security oder VMware Secure Access benötigen, müssen ihre Edges auf Release 4.5.0 oder höher aktualisieren.

Vorsicht:

Die VMware SD-WAN-Versionen 3.2.x, 3.3.x und 3.4.x haben das Ende des Supports erreicht.

  • Die Versionen 3.2.x und 3.3.x erreichen das Ende des allgemeinen Supports (End of General Support, EOGS) am 15. Dezember 2021 und das Ende der technischen Anleitung (End of Technical Guidance, EOTG) am 15. März 2022.

  • Version 3.4.x für Orchestrator und Gateway hat am 30. März 2022 das Ende des allgemeinen Supports (End of General Support, EOGS) und am 30. September 2022 das Ende der technischen Anleitung (End of Technical Guidance, EOTG) erreicht.

  • Version 3.4.x für den Edge hat das Ende des allgemeinen Supports (End of Support, EOGS) am 31. Dezember 2022 und das Ende der technischen Anleitung (End of Technical Guidance, EOTG) am 31. März 2023 erreicht.

  • Weitere Informationen finden Sie im Knowledgebase-Artikel: Ankündigung: Ende des Supports für VMware SD-WAN, Version 3.x (84151) (Announcement: End of Support Life for VMware SD-WAN Release 3.x (84151))

Wichtig:

VMware SD-WAN 4.0.x hat das Ende des Supports erreicht; Version 4.2.x und 4.3.x haben das Ende des Supports für Gateways und Orchestrator-Instanzen erreicht, und Version 4.5.x nähert sich dem Ende des Supports für Gateways und Orchestrator-Instanzen.

  • Version 4.0.x hat das Ende des allgemeinen Supports (End of General Support, EOGS) am 30. September 2022 und das Ende der technischen Anleitung (End of Technical Guidance, EOTG) am 31. Dezember 2022 erreicht. 

  • Version 4.2.x für Orchestrator-Instanzen und Gateways hat das Ende des allgemeinen Supports (End of General Support, EOGS) am 30. Dezember 2022 und das Ende der technischen Anleitung (End of Technical Guidance, EOTG) am 30. März 2023 erreicht.

  • Version 4.2.x für Edges hat am 30. Juni 2023 das Ende des allgemeinen Supports (End of General Support, EOGS) erreicht und wird am 30. September 2025 das Ende der technischen Anleitung (End of Technical Guidance, EOTG) erreichen.

  • Version 4.3.x für Orchestrator-Instanzen und Gateways haben das Ende des allgemeinen Supports (End of General Support, EOGS) am 30. Juni 2023 und das Ende der technischen Anleitung (End of Technical Guidance, EOTG) am 30. September 2023 erreicht.

  • Version 4.3.x für Edges erreicht das Ende des allgemeinen Supports (End of General Support, EOGS) am 30. Juni 2023 und wird am 30. September 2025 das Ende der technischen Anleitung (End of Technical Guidance, EOTG) erreichen.

  • Version 4.5.x für Orchestrator-Instanzen und Gateways hat am 30. September 2023 das Ende des allgemeinen Supports (End of General Support, EOGS) erreicht und wird am 31. Dezember 2023 das Ende der technischen Anleitung (End of Technical Guidance, EOTG) erreichen.

  • Weitere Informationen finden Sie im Knowledgebase-Artikel: Ankündigung: Ende des Supports für VMware SD-WAN, Version 4.x (88319).

Hinweis:

Version 3.x hat AES-256-GCM nicht ordnungsgemäß unterstützt. Dies bedeutet, dass Kunden, die AES-256 verwendeten, ihre Edges immer mit deaktiviertem GCM (AES-256-CBC) einsetzten. Wenn ein Kunde AES-256 verwendet, muss er GCM im Orchestrator explizit deaktivieren, bevor er ein Upgrade seiner Edges auf eine Version 4.x oder 5.x durchführt. Sobald auf allen Edges eine 4.x-/5.x-Version ausgeführt wird, kann der Kunde zwischen AES-256-GCM und AES-256-CBC wählen.

Upgrade-Pfade für Orchestrator, Gateway und Edge

Im Folgenden sind die Pfade für Kunden aufgeführt, die ein Upgrade ihres Orchestrators, Gateways oder Edge von einer älteren Version auf Version 5.1.0 durchführen möchten.

Orchestrator

Orchestrator-Instanzen mit Version 4.0.0 oder höher können auf Version 5.1.0 aktualisiert werden. 

Gateway

Das Upgrade eines Gateways mit Version 4.0.0 oder höher auf Version 5.1.0 wird für alle Gateway-Typen vollständig unterstützt.

Wichtig:

Wenn Sie ein neues Gateway mit Version 5.1.0 bereitstellen, muss die VMware ESXi-Instanz mindestens Version 6.7, Update 3 bis Version 7.0 sein. Die Verwendung einer früheren ESXi-Instanz führt dazu, dass der Datenebene-Dienst des Gateways beim Versuch, Version 5.1.0 oder höher auszuführen, fehlschlägt.

Wichtig:

Vor dem Upgrade eines Gateways auf Version 5.1.0 muss ein Upgrade der ESXi-Instanz auf mindestens Version 6.7, Update 3 bis Version 7.0 durchgeführt werden. Die Verwendung einer früheren ESXi-Instanz führt dazu, dass der Datenebene-Dienst des Gateways beim Versuch, Version 5.1.0 oder höher auszuführen, fehlschlägt.

Edge

Für einen Edge kann ein direktes Upgrade auf Version 5.1.0 von einer beliebigen Version, 3.x oder höher, durchgeführt werden.

Neue SD-WAN-Funktionen

Hub- oder Cluster-Interconnect

Zum ersten Mal können mehrere Hub-Edges oder Hub-Cluster über das Overlay statt über das Underlay miteinander verbunden werden und die Reichweite der Spoke-Edges, die miteinander kommunizieren können, erhöhen. Hubs können nun Routen miteinander teilen, sodass Spoke-Edges, die mit einem Hub-Edge oder Hub-Cluster verbunden sind, über das Overlay mit den Spoke-Edges kommunizieren können, die mit einem anderen Hub-Edge oder Hub-Cluster verbunden sind. Spoke-Edges in einer Multi-Hub-Bereitstellung können jetzt die dynamische Mehrfachpfadoptimierung (Dynamic Multi-Path Optimization, DMPO) nutzen, um die Qualität des Datenverkehrs zu verbessern und gleichzeitig eine vollständige End-to-End-Sichtbarkeit des gesamten Datenverkehrs im Netzwerk zu gewährleisten. Hub- oder Cluster-Interconnect bietet dem Kunden höhere Skalierbarkeit, Zuverlässigkeit und Verfügbarkeit in seinem Multi-Hub-Edge- oder Hub-Cluster-Netzwerk.

Wichtig:

Die Aktivierung von Hub- oder Cluster-Interconnect führt zu einer grundlegenden Änderung des VMware SD-WAN-Routing-Protokolls, da es Paketen erlaubt, mehr als einen Hop im Netzwerk zu durchlaufen. Obwohl diese Änderung in repräsentativen Topologien getestet wurde, ist es nicht möglich, alle Routing-Szenarien zu testen, die bei einer solchen Änderung, die die Verteilung von entfernten Routen zulässt, auftreten können. Aus diesem Grund gibt VMware diese Funktion als Early Access frei und wird Bereitstellungen, in denen sie aktiviert ist, genau auf unerwartetes Routing-Verhalten überwachen.

Neue Benutzeroberfläche von Orchestrator

Orchestrator Version 5.1.0 enthält die vollständige Implementierung unserer neuen Benutzeroberfläche, die erstmals in Version 4.0.0 eingeführt wurde. Die neue Benutzeroberfläche bietet verbesserte Benutzerfreundlichkeit und ein einheitliches Look & Feel für alle VMware SASE-Dienste. Darüber hinaus enthält die neue Benutzeroberfläche eine integrierte Produkthilfe, die Benutzer auf relevante Dokumentationen und andere Materialien verweist, die bei der Nutzung des SD-WAN-Diensts hilfreich sein können.

Die neue Benutzeroberfläche ist die Standardoberfläche von Version 5.1.0 Orchestrator. Der Benutzer hat jedoch weiterhin die Möglichkeit, bei der Verwendung von SD-WAN zur Classic Orchestrator-Benutzeroberfläche zu wechseln.

Hinweis:

Die Unterstützung für die Classic-Benutzeroberfläche wird in der nächsten Nebenversion von VMware SASE Orchestrator eingestellt. Kunden wird dringend empfohlen, die neue Orchestrator-Benutzeroberfläche zu verwenden und sich mit ihr vertraut zu machen.

Flow-Sichtbarkeit

In früheren Versionen zeigt die Orchestrator-Benutzeroberfläche aggregierte Flow-Informationen und -Statistiken nur einzeln aus der Sicht der Anwendung, der Quelle oder des Ziels an und kombiniert nicht alle diese Informationen auf einem Bildschirm, um eine einzige End-to-End-Ansicht zu bieten. Infolgedessen werden Überwachung, Fehlerbehebung und Berichterstellung durch den Mangel an detaillierter Sichtbarkeit der einzelnen Flows behindert.

Mit Version 5.1.0 enthält die neue Orchestrator-Benutzeroberfläche eine Registerkarte „Flows“, auf der die konsolidierten Daten für jeden Datenverkehrs-Flow angezeigt werden. Die Orchestrator-Benutzeroberfläche zeigt die wichtigsten Parameter jedes Flows in einer einzigen Ansicht an. Darüber hinaus ermöglicht die Funktion Flow-Sichtbarkeit (Flow Visibility) Kunden die Anzeige historischer Flow-Daten, die Filterung von Daten auf der Grundlage übereinstimmender Parameter und den Download von End-to-End-Flow-Statistiken.

Lokale DNS-Einträge

Version 5.1.0 unterstützt lokale DNS-Einträge auf dem Edge, um den Datenverkehr auf bestimmte Domänen zu verweisen. Wenn lokales DNS konfiguriert ist, sucht der Edge zunächst in der lokalen Hostdatei, bevor er versucht, eine Domäne über einen DNS-Server aufzulösen.

Power-On Self-Test (POST) für Orchestrator, Gateway und Edge

Version 5.1.0 bietet eine verbesserte Gerätehärtung und -sichtbarkeit durch einen Power-On Self-Test (POST). Der POST ist ein Vorgang, der von einer Softwareroutine durchgeführt wird, die automatisch unmittelbar nach dem Einschalten oder Neustart eines Geräts aufgerufen wird. Der POST-Vorgang umfasst folgende Schritte:

  • Überprüfung der Software-Integrität.

  • Überprüfung der Algorithmen des kryptografischen Moduls – Known Answer Test (KAT).

  • Test der Entropiequelle (Rauschen).

  • Anzeige der POST-Ergebnisse: Bestanden/Nicht bestanden (Pass/Fail). Das System fährt nur dann mit dem Starten der restlichen Anwendungen fort, wenn der POST bestanden wurde. Bei nicht bestandenem POST werden Fehlermeldungen angezeigt, wo der Test fehlgeschlagen ist, und die Startsequenz des Systems wird abgebrochen.

Für Orchestrator-Instanzen und Gateways ist diese Funktion nur in einer Greenfield-Bereitstellung verfügbar. Bei Edges ist diese Funktion nicht standardmäßig aktiviert und muss von einem Benutzer über die Orchestrator-Benutzeroberfläche aktiviert werden.

Neue SD-WAN-Verbesserungen

Synchronisierung der lokalen HA-Route (High Availability) und BGP für Graceful Restart

Für eine in einer Hochverfügbarkeitstopologie bereitgestellte Site, in der auch BGP oder OSPF verwendet wird, kann ein HA-Failover die Übertragung des Kundendatenverkehrs verlangsamen und sich negativ auf diesen auswirken, da es während der Synchronisierung der Routen durch den Standby-Edge zu hohen Paketverlusten kommt. VMware führt zwei Verbesserungen ein, um HA-Failover zu beschleunigen und die negativen Auswirkungen zu verringern: Synchronisierung der lokalen HA-Route und BGP für Graceful Restart.

Mithilfe der Synchronisierung der lokalen HA-Route werden Routen zwischen dem aktiven und dem Standby-Edge automatisch synchronisiert. Diese Routen werden dann für die Weiterleitung auf dem aktiven Edge verwendet, wobei sichergestellt wird, dass die Routentabelle nach einem HA-Failover sofort verfügbar ist.

BGP für Graceful Restart sorgt für schnellere Edge-Neustarts und HA-Failover, indem die benachbarten BGP-Geräte am Neustart teilnehmen und somit sichergestellt wird, dass für die Dauer des Neustarts keine Routenänderungen im Netzwerk vorgenommen werden. Ohne BGP für Graceful Restart löscht der Peer-Edge alle Routen, sobald die TCP-Sitzung zwischen BGP-Peers beendet wird, und diese Routen müssen nach dem Edge-Neustart oder HA-Failover neu erstellt werden. BGP für Graceful Restart ändert dieses Verhalten dahingehend, dass Peer-Edges keine Routen löschen, wenn eine neue Sitzung innerhalb eines konfigurierbaren Restart-Timers eingerichtet wird.

Wichtig:

Für optimale Leistung sollte DCC (Dynamic Cost Calculation, dynamische Kostenberechnung) auch im Kundenunternehmen aktiviert werden. Bei aktivierter DCC werden Voreinstellungs- und Ankündigungsentscheidungen für den Edge lokal getroffen. Der Edge wird dann von „Aktiv (Active)“ in „Standby“ synchronisiert, sobald er die Routen aus dem Routing-Vorgang erlernt. Weitere Informationen zu DCC finden Sie unter Übersicht über VMware SD-WAN-Routing und Konfigurieren von DCC (Distributed Cost Calculation).

Hinweis:

Die Synchronisierung der lokalen HA-Route ist nur für Unternehmen verfügbar, die BGP verwenden. Die Synchronisierung der lokalen HA-Route mithilfe von OSPF steht in einer zukünftigen Version zur Verfügung.

RADIUS-Authentifizierung auf einer geswitchten Schnittstelle

Kunden können RADIUS-Authentifizierung über das 802.1x-Protokoll an geswitchte Ports verwenden, die bisher auf geroutete Ports beschränkt waren. Die RADIUS-Authentifizierung an geswitchten Ports wird über ein VLAN konfiguriert, das mit diesem Port verbunden ist. Diese Verbesserung kommt Kunden-Sites zugute, an denen keine anderen Router zur Erweiterung des lokalen Zugangs verfügbar sind, die aber eine sichere Geräteauthentifizierung über 802.1x benötigen.

MAC-Adressen-Umgehung (MAB)

Auf gerouteten Schnittstellen können Kunden jetzt MAC-Adressen mit einer Liste auf einem RADIUS-Server abgleichen, um 802.1x für LAN-Geräte zu umgehen, die keine 802.1x-Authentifizierung unterstützen. MAB vereinfacht den IT-Betrieb, spart Zeit und verbessert die Skalierbarkeit, da Kunden nicht mehr jede MAC-Adresse, die möglicherweise eine Authentifizierung benötigt, manuell konfigurieren müssen.

Wichtig:

RADIUS-basiertes MAB wird für VLANs nicht unterstützt und kann daher nicht für geswitchte Ports verwendet werden. RADIUS-basiertes MAB wird nur für geroutete Schnittstellen unterstützt.

Konfigurationsänderungen, die einen Edge-Neustart verursachen

Mehrere Edge-Konfigurationsänderungen, die zuvor einen Neustart des Edge-Diensts auslösten, tun dies in Version 5.1.0 nicht mehr. Insbesondere häufig verwendete Konfigurationsänderungen an der Edge-Schnittstelle wie das Bearbeiten einer Edge-LAN-IP-Adresse auf einer geswitchten Schnittstelle oder das Ändern einer CIDR-IP, eines CIDR-Präfixes oder einer festen IP führen nicht mehr zu einem störenden Edge-Neustart. Eine vollständige Liste finden Sie im KB-Artikel VMware SD-WAN Edge-Konfigurationsänderungen, die einen Neustart des Edge-Diensts auslösen können (60247).

SNMP

Version 5.1.0 bietet die folgenden Verbesserungen für SNMP:

  • SNMPv2, Unterstützung für zusätzliche Community-Zeichenfolgen und 64-Bit-Indikatoren.

  • SNMPv3, Unterstützung für SHA2, zusätzliche Benutzernamen und Kennwörter sowie separate Authentifizierung und private Schlüssel.

  • Die MIB fügt die folgende Telemetrie hinzu:

    • Zuordnung von Link-UUID zu Schnittstellennamen.

    • Link-Bandbreite/-Kapazität.

    • Link-Durchsatz.

Erhöhung der Flow-Kapazität beim Edge 2000, 3800 und 3810

Bei den Edge-Modellen 2000, 3800 und 3810 erhöht sich die maximale Flow-Kapazität von 1,9 Millionen Flows auf 3,8 Millionen Flows bei Verwendung der Edge-Softwareversion 5.1.0.

Hinweis:

Das Edge-Modell 3400 ist von dieser Änderung nicht betroffen, und die maximale Flow-Kapazität dieses Modells beträgt weiterhin 1,9 Millionen Flows.

Paketerfassung (Packet Capture, PCAP) auf Gateways

Ein Benutzer kann eine PCAP auf einem Gateway über die Orchestrator-Benutzeroberfläche initiieren. Es können bis zu 120 Sekunden des Gateway-Datenverkehrs aufgezeichnet werden, wobei die Möglichkeit besteht, einfache oder komplexe Filter zu definieren, um sicherzustellen, dass der Benutzer nur das erfasst, was er benötigt. Diese Funktion ist für Benutzer wie folgt zugänglich:

  • Partner-Administratoren können eine PCAP nur für ihre eigenen Partner-Gateways initiieren.

  • Operatoren können eine PCAP sowohl auf Partner-Gateways als auch auf gehosteten Gateways initiieren.

Externe Zertifizierungsstelle (CA)

Die Funktion „Externe Zertifizierungsstelle (External CA)“ wurde um zwei neue API-fähige Modi ergänzt:

  • Manueller Modus (Manual Mode) unterstützt eine beliebige Zertifizierungsstelle und bietet Flexibilität und Kontrolle, da der Benutzer jeden Schritt im Zertifikatsprozess manuell durchführen kann.

  • Asynchroner Modus (Asynchronous Mode) bietet Unterstützung für jede Zertifizierungsstelle mit der Möglichkeit, die manuellen Schritte und die wiederkehrenden Aufgaben zu automatisieren.

Nicht SD-WAN (NSD)- und Cloud-Security-Service (CSS)-Tunnel

In früheren SD-WAN-Versionen wurden die Tunnel für ein NSD oder einen CSS nur dann aufgebaut, wenn Datenverkehr durch sie lief, und blieben so lange bestehen, wie Datenverkehr durch sie geleitet wurde. Wenn über einen bestimmten Zeitraum kein Datenverkehr stattfand, wurde der Tunnel abgebaut und musste neu aufgebaut werden, wenn das nächste Mal Datenverkehr in eine der beiden Richtungen gesendet wurde, wodurch eine Latenz für diesen Datenverkehr entstand, während der Tunnel neu aufgebaut wurde. Ab Version 5.1.0 werden alle NSD- und CSS-Tunnel bei der Erstkonfiguration eines der beiden Dienste ausgelöst und aufgebaut und bleiben bestehen, unabhängig davon, ob über einen bestimmten Zeitraum Datenverkehr stattfindet oder nicht.

Wichtige Hinweise

An die BGP-Präfixe angehängter erweiterter BGP-Community-String

Intra-Cluster-BGP-Routen werden automatisch mit einer internen BGP-Community gekennzeichnet, die von jedem Edge an die vorhandenen BGP-Communitys angehängt wird. Dieser zusätzliche Community-String kombiniert 1 Byte für die Hop-Anzahl und 3 Byte, die von der logischen Edge-ID abgeleitet werden. Infolgedessen sollten Kunden, die BGP-Peering auf der Spoke-/Hub-LAN-Seite verwenden, die von den Edges angekündigten BGP-Präfixe nicht mit dem neuen BGP-Community-String filtern.

Dead Peer Timeout (DPD) für Nicht-SD-WAN-Ziele

Version 5.1.0 bringt wichtige Änderungen am Dead Peer Timeout (DPD) für Nicht-SD-WAN-Ziele. In früheren Versionen betrug der Standardwert des DPD 20 Sekunden, und ein Benutzer konnte DPD deaktivieren, indem er den DPD-Zeitüberschreitungs-Timer auf 0 Sekunden konfigurierte. Mit der Umstellung von VMware SD-WAN auf das QuickSec IPsec-Toolkit ändert sich DPD wie folgt:

  • Prüfintervall: Exponential (0,5 Sekunden, 1 Sekunde, 2 Sekunden, 4 Sekunden, 8 Sekunden, 16 Sekunden).

  • Standardmäßiges minimales DPD-Intervall: 47,5 Sekunden (QuickSec wartet 16 Sekunden nach dem letzten Wiederholungsversuch. Daher 0,5+1+2+4+8+16+16 = 47,5).

  • Standardmäßiges minimales DPD-Intervall + DPD-Zeitüberschreitung (Sekunden): 67,5 Sekunden.

Aufgrund der oben genannten Änderungen kann ein Benutzer DPD nicht deaktivieren, indem er den DPD-Zeitüberschreitungs-Timer auf 0 Sekunden konfiguriert. Der DPD-Zeitüberschreitungswert in Sekunden wird dem Standardwert von 47,5 Sekunden hinzugefügt. Selbst wenn also ein Benutzer DPD für 0 Sekunden konfiguriert hat, würde der DPD-Wert in Wirklichkeit 47,5 betragen.

Funktionen, die in Classic Orchestrator konfiguriert werden müssen

Mit Version 5.1.0 stellt VMware die neue Benutzeroberfläche als Standardoberfläche für Orchestrator zur Verfügung, sodass ein Benutzer alle Überwachungs- und Konfigurationsaufgaben über diese Oberfläche ausführen kann. Einige Funktionen sind jedoch nicht vollständig in die neue Benutzeroberfläche integriert:

  • Secure Access – Edge- und Profileinstellungen

  • Zscaler – Edge- und Profileinstellungen

  • TACACS – Seite „Edge-Einstellungen und Netzwerkdienste“

  • Partnereinstellungen – Seite „Partner“

Um die oben genannten Funktionen zu konfigurieren, kann ein Kunde die Option Classic Orchestrator öffnen (Open Classic Orchestrator) am oberen Rand des Orchestrator-Bildschirms auswählen, wodurch eine neue Browser-Registerkarte auf der Classic-Benutzeroberfläche geöffnet wird.


Diese Funktionen werden in einer späteren Orchestrator-Softwareversion vollständig in die neue Benutzeroberfläche integriert.

Das Mischen von WLAN-fähigen und Nicht-WLAN-fähigen Edges in Hochverfügbarkeit wird nicht unterstützt 

Ab 2021 führte VMware SD-WAN Edge-Modelle ein, die kein WLAN-Modul enthalten: die Edge-Modelle 510N, 610N, 620N, 640N und 680N. Obwohl diese Modelle bis auf die WLAN-Funktionalität mit ihren WLAN-fähigen Gegenstücken identisch sind, wird die Bereitstellung eines WLAN-fähigen Edge und eines nicht WLAN-fähigen Edge desselben Modells (z. B. eines Edge 640 und eines Edge 640N) als Hochverfügbarkeitspaar nicht unterstützt. Kunden sollten sicherstellen, dass die als Hochverfügbarkeitspaar bereitgestellten Edges denselben Typ aufweisen: sowohl WLAN-fähig als auch nicht WLAN-fähig.

Änderung des Trennzeichens in der BGPv4-Filterkonfiguration für das Voranstellen des AS-PATH

Bis Version 3.x unterstützte die VMware SD-WAN BGPv4-Filterkonfiguration für das Voranstellen von AS-PATH sowohl komma- als auch leerzeichenbasierte Trennzeichen. Ab Version 4.0.0 unterstützt VMware SD-WAN jedoch nur noch ein auf Leerzeichen basierendes Trennzeichen in einer AS-Pfad-Voreinstellungskonfiguration. Kunden, die von 3.x auf 4.x oder 5.x upgraden, müssen ihre AS-PATH-Voranstellungskonfigurationen so bearbeiten, dass sie „Kommas durch Leerzeichen ersetzen“, bevor sie das Upgrade durchführen, um eine falsche Auswahl der besten BGP-Route zu vermeiden.

Erweiterte Upgrade-Zeit für Edge 3x00-Modelle

Upgrades auf diese Version dauern bei Edge 3x00-Modellen (d. h. 3400, 3800 und 3810) länger als normal (3-5 Minuten), wenn der Edge direkt von Version 4.0.0, 4.0.1 oder 4.2.0 aktualisiert wird. Dies ist auf ein Firmware-Upgrade zurückzuführen, das das Problem 53676 behebt. Wenn beim Upgrade eines Edge 3400 oder 3800 auf Version 5.1.0 eine andere Edge-Version verwendet wird, wird der Edge wie erwartet aktualisiert. Weitere Informationen finden Sie unter Behobenes Problem 53676 in den entsprechenden Versionshinweisen.

Einschränkung bei BGP über IPsec auf Edge und Gateway sowie Azure Virtual WAN-Automatisierung

Die Funktion BGP über IPsec auf Edge und Gateway ist nicht mit Azure Virtual WAN-Automatisierung von Edge oder Gateway kompatibel. Es werden nur statische Routen unterstützt, wenn die Konnektivität von einem Edge oder Gateway zu einem Azure vWAN automatisiert wird.

Einschränkung beim Deaktivieren der automatischen Aushandlung auf den VMware SD-WAN Edge-Modellen 520, 540, 620, 640, 680, 3400, 3800 und 3810

Dieses Problem betrifft die Ports GE1 bis GE4 auf einem VMware SD-WAN Edge-Modell 620, 640 oder 680, die Ports GE3 oder GE4 auf einem Edge-Modell 3400, 3800 oder 3810 sowie auf einem Edge-Modell 520/540 bei Verwendung eines SFP mit einer Kupferschnittstelle auf den Ports SFP1 oder SFP2. Wenn ein Benutzer die automatische Aushandlung deaktiviert, um eine bestimmte Geschwindigkeit und den Duplexmodus für die obigen drei betroffenen Modelle und Ports zu erzwingen, stellt der Benutzer fest, dass die Verbindung auch nach einem Neustart nicht hergestellt werden kann.

Dies liegt daran, dass alle aufgeführten Edge-Modelle den Intel Ethernet Controller i350 verwenden, der die Einschränkung hat, dass bei nicht erfolgter automatischer Aushandlung auf beiden Seiten der Verbindung die geeigneten Leitungen für die Übertragung und den Empfang nicht dynamisch erkannt werden können (Auto-MDIX). Wenn beide Seiten der Verbindung auf denselben Leitungen übertragen und empfangen, wird die Verbindung nicht erkannt. Wenn die Peer-Seite auch kein Auto-MDIX ohne automatische Aushandlung unterstützt und die Verbindung nicht mit einem geraden Kabel hergestellt werden kann, wird ein Crossover-Ethernet-Kabel benötigt, um die Verbindung herzustellen.

Weitere Informationen finden Sie im KB-Artikel Einschränkung beim Deaktivieren der automatischen Aushandlung auf den VMware SD-WAN Edge-Modellen 520, 540, 620, 640, 680, 3400, 3800 und 3810 (87208).

Verfügbare Sprachen

Der VMware SASE Orchestrator in der Version 5.1.0 ist in folgende Sprachen lokalisiert: Tschechisch, Englisch, europäisches Portugiesisch, Französisch, Deutsch, Griechisch, Italienisch, Spanisch, Japanisch, Koreanisch, vereinfachtes Chinesisch und traditionelles Chinesisch.

Änderungen an der Orchestrator-API

Änderungen an der Orchestrator-API seit Version 5.0.0

Änderungen an der VMware SASE Orchestrator-Portal-API („API v1“)

Das vollständige API-Änderungsprotokoll steht unter developer.vmware.com zum Download zur Verfügung (siehe „VMware SD-WAN Orchestrator API v1“).

Die folgenden Änderungen erfordern möglicherweise ein Eingreifen der Entwickler:

  • Problem 66795: Mit diesem Fix wird ein Mechanismus eingeführt, durch den ein API-Token nur dann gültig ist und vom Orchestrator für nicht native Benutzer akzeptiert wird, wenn sie sich im Status aktiviert (enabled) befinden und wenn der SSO-Benutzer in seinem jeweiligen Identitätsanbieter aktiv ist. Wenn ein nicht nativer Benutzer inaktiv wird (d. h. im Identitätsanbieter gelöscht wird oder über kein gültiges Aktualisierungstoken verfügt), werden alle API-Token für diesen Benutzer über einen Backend-Auftrag widerrufen.

Hinweis:

  • Token, die im Namen eines SSO-aktivierten Benutzers vor diesem Fix ausgestellt wurden, unterliegen dem Legacy-Verhalten, d. h., sie werden vom Orchestrator weiterhin berücksichtigt, bis sie ablaufen.

  • SSO-Benutzer von Identitätsanbietern, die keine Aktualisierungstoken oder Introspektions-Endpunkte unterstützen, können die Funktion der tokenbasierten Authentifizierung nicht verwenden. 

  • Problem 87878:vcoInventory/getPendingInventory hat die Antwortnutzlast geändert. Felder token, vcoInstanceLogicalId, vcoUrl, edgeMappingId, enterpriseId, enterpriseProxyId, uuid, mac, imei, owner wurden entfernt. Sie werden nicht auf dem Frontend verwendet, und dies hat keine Auswirkungen auf die Benutzeroberfläche, da diese Felder nicht auf der Benutzeroberfläche verwendet wurden. Diese API soll dazu dienen, eine Liste der verfügbaren ZTP-Edges abzurufen, und diese Felder sind für die Edge-Zuweisung nicht erforderlich (nur serialNumber ist erforderlich). Wenn ein Kunde diese API für ZTP verwendet und eine strenge Validierung der Nutzdaten vornimmt, kann dies Auswirkungen haben (abhängig von der Implementierung). Im Allgemeinen sind die zurückgegebenen Informationen für einen erfolgreichen ZTP-Flow ausreichend.

  • Problem 84303: Es wurde eine Validierung für das Attribut maxHop des BGP-Nachbarn hinzugefügt, um die Konfiguration eines maxHop-Werts von weniger als 2 zu verhindern, wenn eine localIP des Nachbarn vorhanden ist. Zuvor war die Konfiguration eines maxHop-Werts von 1 erlaubt, unabhängig davon, ob die localIP des Nachbarn vorhanden ist oder nicht. Nun ist gemäß der Änderung bei Vorhandensein einer Nachbar-localIP mindestens ein MaxHop-Wert von 2 zulässig, und wenn ein Benutzer versucht, einen maxHop-Wert von weniger als 2 zu konfigurieren, erhält er die Fehlermeldung Invalid MaxHop for Neighbor. MaxHop value ranges from 2 to 255 when localIp is present. Es wird ein Patch geschrieben, um die bestehende Konfiguration zu korrigieren.

  • Problem 84114: Durch die Migration von Clientgeräten von MySQL zu ClickHouse wurde das Feld clientDeviceId eliminiert. Da kein externer Client mithilfe des Felds clientDeviceId angegeben wurde, sollten die Auswirkungen vernachlässigbar sein. Der einzige Client, der den Client-Geräte-Endpunkt mit clientDeviceId verwendet, scheint die Classic Orchestrator-Benutzeroberfläche zu sein. Die Benutzeroberfläche wurde verbessert, um Datensätze in ClickHouse mithilfe der Kombination logicalId oder ipAddress und macAddress zu aktualisieren oder abzurufen. Externe Clients sollten sich daran orientieren, wenn sie den Client-Geräte-Endpunkt zur Aktualisierung des Hostnamens oder zum Abrufen bestimmter Geräte nach ID verwenden.

Änderungen an der VMware SASE Orchestrator-API v2

  • Problem 98750: Das Feld lastContact im Edge-Datensatz, das von Edge-bezogenen APIs zurückgegeben wird, ist veraltet und sollte nicht mehr verwendet werden. Stattdessen sollte das Feld edgeState in der Antwort verwendet werden, um den tatsächlichen Status des Edge als einzige Quelle festzulegen. Wenn im Client-Code das Feld lastContact verwendet wird, das nicht durch das Feld edgeState ersetzt werden kann, stellt API v1 weiterhin ein genaues Feld vom Typ lastContact in der Antwort bereit. Hierbei handelt es sich um einen Kompromiss, der allerdings nicht empfohlen wird.

  • Problem 30901: Mit der in Version 5.1.0 eingeführten Funktion „Flow-Sichtbarkeit (Flow Visibility)“ ist die obligatorische groupBy-Klausel für Flowstats nicht mehr erforderlich. Bei Nichterwähnung der groupBy-Klausel wird standardmäßig davon ausgegangen, dass der API-Endpunkt den Flow-Sichtbarkeit-API-Endpunkt abfragt oder aufruft, der wiederum für alle Resolver wie Anwendung, Client-Geräte usw. aufgelöst wird. Dies gilt jedoch nur für den Aufruf der Metrik-API für Flow-Statistiken, die Serien-API für Flow-Statistiken bleibt gleich.

  • Problem 95089: Das APIv2-Ratenbegrenzungsmodul hat entgegen unserer Absicht nicht dieselbe Standardrichtlinie durchgesetzt wie der Ratenbegrenzer der Portal-API. Eine Änderung in dieser Version setzt diese Richtlinie für APIv2 in Kraft. Wir raten den Benutzern, die Best Practices zur Vermeidung der Auslösung des Ratenbegrenzers und zur Behandlung von Antworten zu überprüfen, bei denen die Ratenbegrenzung ausgelöst wurde.

Hinweis zur Entwicklerdokumentation

In der Vergangenheit wurde die VMware SASE-/SD-WAN-API-Dokumentation auf VMware {code} unter code.vmware.com gehostet. VMware {code} wurde kürzlich zu einer neuen Domäne migriert, developer.vmware.com. Infolge der Migration funktionieren einige Permalinks zu bestimmten Seiten, die zuvor unter code.vmware.com gehostet wurden, möglicherweise nicht mehr wie erwartet.

In Verbindung mit der Migration wird VMware weiterhin das Dokumentationsportal für Entwickler unter https://developer.vmware.com/apis nutzen, in dem die gesamte VMware SASE-/SD-WAN-API-Dokumentation jetzt zu finden ist.

Dokumentierter Revisionsverlauf

18. Dezember 2023. 24. Auflage.

  • Der neue Orchestrator-Rollup-Build R51010-20231215-GA wurde zum Abschnitt „Behobene Probleme bei Orchestrator“ hinzugefügt. Dies ist der zehnte Orchestrator-Rollup-Build und der neue Standard-Orchestrator-GA-Build für Version 5.1.0.

  • Orchestrator-Build R51010-20231215-GA enthält Fixes für die Probleme #117941, #125006, #128310, #129239, und #131789, die jeweils in diesem Abschnitt beschrieben werden.

9. Oktober 2023. 23. Auflage.

  • Der neue Orchestrator-Rollup-Build R5109-20231003-GA wurde zum Abschnitt „Behobene Probleme bei Orchestrator“ hinzugefügt. Dies ist der neunte Orchestrator-Rollup-Build und der neue Standard-Orchestrator-GA-Build für Version 5.1.0.

  • Orchestrator-Build R5109-20231003-GA enthält die Fixes für die Probleme #119938 und #128310, die jeweils in diesem Abschnitt dokumentiert sind.

  • Das offene Problem #105933 wurde zum Abschnitt „Bekannte Probleme bei Edge/Gateway“ hinzugefügt.

20. September 2023. 22. Auflage.

  • Der neue Orchestrator-Rollup-Build R5108-20230916-GA wurde zum Abschnitt „Behobene Probleme bei Orchestrator“ hinzugefügt. Dies ist der achte Orchestrator-Rollup-Build und der neue Standard-Orchestrator-GA-Build für Version 5.1.0.

  • Orchestrator-Build R5108-20230916-GA enthält die Fixes für die Probleme #94610, #104775, #105580#106191, #115981, #116531, #117822, #118728, #121085, #121441, #121469 und #124778, die jeweils in diesem Abschnitt dokumentiert sind.

  • Das offene Problem #62701 wurde vom Abschnitt Bekannte Probleme bei Edge/Gateway zum Abschnitt Behobene Probleme bei Edge/Gateway für den ursprünglichen GA-Build R5100-20221204-GA verschoben. Diese Maßnahme hätte bereits in der 1. Auflage dieser Versionshinweise durchgeführt werden sollen.

  • Offene Probleme #115136 und #117037 wurden zum Abschnitt „Bekannte Probleme bei Edge und Gateway“ hinzugefügt.

  • Der Dokumentierter Versionsverlauf wurde neu organisiert, sodass er nun von den neuesten bis zu den ältesten Einträgen gelesen wird, um die Benutzerfreundlichkeit zu verbessern.

22. August 2023. 21. Auflage.

3. August 2023. Zwanzigste Auflage.

26. Juli 2023. 19. Auflage.

  • Das behobene Problem #103708 wurde zum Abschnitt „Behobene Probleme bei Edge/Gateway“ für den zweiten Edge-Rollup-Build R5102-20230310-GA hinzugefügt. Dieses Problem wurde in der zehnten Auflage der Versionshinweise zu Version 5.0.1 ausgelassen.

23. Juli 2023. Achtzehnte Auflage.

  • Der neue Orchestrator-Rollup-Build R5107-20230722-GA wurde zum Abschnitt „Behobene Probleme bei Orchestrator“ hinzugefügt. Dies ist der siebte Orchestrator-Rollup-Build und der neue Standard-Orchestrator-GA-Build für Version 5.1.0.

  • Orchestrator-Build R5107-20230722-GA enthält den Fix für Problem #122271, der in diesem Abschnitt dokumentiert ist.

  • Das offene Problem #53359 wurde aus dem Abschnitt Bekannte Probleme bei Edge/Gateway entfernt, weil es in 4.3.0 behoben wurde.

  • Offene Probleme #103708 und #117775 wurden zum Abschnitt Bekannte Probleme bei Edge/Gateway hinzugefügt.

15. Juli 2023. Siebzehnte Auflage.

6. Juli 2023. Sechzehnte Auflage.

  • Der neue Orchestrator-Rollup-Build R5106-20230705-GA wurde zum Abschnitt „Behobene Probleme bei Orchestrator“ hinzugefügt. Dies ist der sechste Orchestrator-Rollup-Build und der neue Standard-Orchestrator-GA-Build für Version 5.1.0.

  • Orchestrator-Build R5106-20230705-GA enthält Fixes für die Probleme #84772, #115411, #115433, #116633, #117772, #117988, #117993, #118074, #118544, #118733, #119733 und #120606, die jeweils in diesem Abschnitt beschrieben werden.

  • Behobenes Problem #95565wurde zum Abschnitt „Behobene Probleme bei Edge/Gateway“ für den ursprünglichen GA-Build R5100-20221204-GA hinzugefügt. Dieses Problem wurde in den ursprünglichen Versionshinweisen zu Version 5.1.0 irrtümlich ausgelassen.

  • Das offene Problem #107994 wurde zum Abschnitt Bekannte Probleme bei Edge/Gateway hinzugefügt.

  • Das offene Problem #112826 wurde zum Abschnitt Bekannte Probleme bei Orchestrator hinzugefügt.

23. Juni 2023. Fünfzehnte Auflage.

  • Ein neuer Gateway-Rollup-Build R5103-20230621-GA wurde zum Abschnitt „Behobene Probleme bei Edge/Gateway“ hinzugefügt. Dies ist der dritte Gateway-Rollup-Build und ist der neue Gateway-GA-Build für Version 5.1.0.

  • Edge- und Gateway-Build R5103-20230621-GA enthält die Fixes für die Probleme #82808, #100172, #101536, #104619, #107309, #108473, #111646, #111888, #111924, #112016, #112017, #112019, #112020, #112800, #114052, #114084, #114282, #114932, #115604, #115692 und #116182, die jeweils in diesem Abschnitt dokumentiert sind.

  • Offene Probleme #115148 und #119033 wurden zum Abschnitt Bekannte Probleme bei Edge/Gateway hinzugefügt.

13. Juni 2023. Vierzehnte Auflage.

  • Der neue Orchestrator-Rollup-Build R5105-20230611-GA wurde zum Abschnitt „Behobene Probleme bei Orchestrator“ hinzugefügt. Dies ist der fünfte Orchestrator-Rollup-Build und der neue Orchestrator-GA-Build für Version 5.1.0.

  • Orchestrator-Build R5105-20230611-GA enthält Fixes für die Probleme #87089, #105861, #106295, #107180, #107766, #110826, #111957, #112044, #112333, #112451, #112500, #112605, #112809, #112906, #112912, #112992, #113209, #113254, #113366, #113375, #113963, #114240, #114291, #114564, #114602, #114912, #115307, #115439, #115624, #115653, #115719, #116141, #116523, #116770, #116790, #116976, #117527, #117800 und #118071.

  • Die folgenden offenen Probleme wurden dem Abschnitt Bekannte Probleme bei Edge/Gateway hinzugefügt: #82808, #107309, #111924, #112016, #112017, #112019, #114084, #114282, #115692 und #116182. Alle diese Probleme wirken sich auf das VMware SD-WAN Gateway aus.

11. Mai 2023. Dreizehnte Auflage.

  • Die folgenden offenen Probleme wurden dem Abschnitt Bekannte Probleme bei Edge/Gateway hinzugefügt: #108473, #111646, #111888, #112020, #112800, #114052 und #114932. Alle diese Probleme wirken sich auf das VMware SD-WAN Gateway aus.

27. April 2023. Zwölfte Auflage.

  • Der neue Orchestrator-Rollup-Build R5104-20230426-GA wurde zum Abschnitt „Behobene Probleme bei Orchestrator“ hinzugefügt. Dies ist der vierte Orchestrator-Rollup-Build für Version 5.1.0.

  • Orchestrator-Build R5104-20230426-GA enthält Fixes für die Probleme #95631, #104785, #106327, #106929, #107071, #107349, #107980, #108072, #108363, #109284, #109300, #109532, #109533, #109715, #109788, #109836, #109911, #110094, #110330, #110946, #111104, #111407, #111444, #111665, #111934, #111944, #111946, #112094, #112201, #112224, #112437, #112458, #112885 und #114475. Jedes Problem wird in diesem Abschnitt dokumentiert.

  • Zwei der behobenen Tickets, #106907 und #106929, wurden ursprünglich als behoben in Orchestrator Version 5.1.0.2 markiert. Die Fixes waren jedoch in 5.1.0.2 unvollständig, und die Probleme wurden nur in Orchestrator-Version 5.1.0.4 vollständig behoben. Infolgedessen wurden diese Tickets aus dem Abschnitt „Behobene Probleme“ der Orchestrator-Version 5.1.0.2 entfernt und in 5.1.0.4 verschoben.

  • #94612 wurde dem Abschnitt „Behobene Probleme bei Edge/Gateway“ für den ursprünglichen Build R5100-20221204-GA hinzugefügt. Dieses Problem wurde in den ursprünglichen Versionshinweisen zu Version 5.1.0 irrtümlich ausgelassen.

  • Der Abschnitt Kompatibilität wurde aktualisiert, um für alle 3.x-Versionen das Ende der Lebensdauer (End of Service Life, EOSL) zu kennzeichnen. Außerdem wurde der Abschnitt 4.x aktualisiert, um Orchestrator-Instanzen und Gateways der Version 4.2.x für das Ende des Supports (End of Support Life, EOSL) zu kennzeichnen.

  • Es wurde der Abschnitt Wichtige Hinweise mit dem Titel An die BGP-Präfixe angehängter erweiterter BGP-Community-String hinzugefügt.

15. März 2023. Elfte Auflage.

  • Der neue Orchestrator-Rollup-Build R5103-20230315-GA wurde zum Abschnitt „Behobene Probleme bei Orchestrator“ hinzugefügt. Dies ist der dritte Orchestrator-Rollup-Build für Version 5.1.0.

  • Orchestrator-Build R5103-20230315-GA enthält die Fixes für die Probleme #107587, #107725, #108533, #108833 und #109064. Jedes Problem wird in diesem Abschnitt dokumentiert. R5104-202304xx-GA

14. März 2023. Zehnte Auflage.

  • Ein neuer Edge- und Gateway-Rollup-Build R5102-20230310-GA wurde zum Abschnitt „Behobene Probleme bei Edge/Gateway“ hinzugefügt. Dies ist der zweite Edge-/Gateway-Rollup-Build und der neue Edge- und Gateway-GA-Build für Version 5.1.0.

  • Edge- und Gateway-Build R5102-20230310-GA enthält die Fixes für die Probleme #98782, #104141, #105744 und #106587, die jeweils in diesem Abschnitt dokumentiert sind.

6. März 2023. Neunte Auflage.

  • Im Abschnitt Neue SD-WAN-Verbesserungen wurde der Eintrag Erhöhung der Flow-Kapazität beim Edge 3x00 überarbeitet. Im ursprünglichen Eintrag wurde der Edge 2000 aus- und der Edge 3400 fälschlicherweise eingeschlossen. Der überarbeitete Eintrag lautet nun:

    • Erhöhung der Flow-Kapazität beim Edge 2000, 3800 und 3810

    • Bei den Edge-Modellen 2000, 3800 und 3810 erhöht sich die maximale Flow-Kapazität von 1,9 Millionen Flows auf 3,8 Millionen Flows bei Verwendung der Edge-Softwareversion 5.1.0.

    • Ein Hinweis wird hinzugefügt, der deutlich macht, dass das Edge-Modell 3400 von dieser Änderung nicht betroffen ist und die maximale Flow-Kapazität dieses Modells weiterhin 1,9 Millionen Flows beträgt.

28. Februar 2023. Achte Auflage.

  • Der Orchestrator-Rollup-Build R5102-20230216-GA wurde durch R5102-20230222-GA ersetzt. Der neue Orchestrator-Build behebt ein Upgrade-Problem, das vom VMware Operations-Team beim Upgrade eines Orchestrators auf Build R5102-20230216-GA festgestellt wurde. Das Upgrade-Problem wurde durch einen Versionskonflikt im Manifest des Upgrade-Pakets verursacht.

  • Der neue Build enthält auch Fixes für: #106907, #108074 und #108309.

17. Februar 2023. Siebte Auflage.

  • Der neue Orchestrator-Rollup-Build R5102-20230216-GA wurde zum Abschnitt „Behobene Probleme bei Orchestrator“ hinzugefügt. Dies ist der zweite Orchestrator-Rollup-Build für Version 5.1.0.

  • Orchestrator-Build R5102-20230216-GA enthält Fixes für Probleme #40584, #105610, #106159, #106242, #106592, #106806, #106929, #107410, #107637 und #107885. Jedes Problem wird in diesem Abschnitt dokumentiert.

  • #89725 wurde dem Abschnitt „Behobene Probleme bei Edge/Gateway“ für den ursprünglichen Build R5100-20221204-GA hinzugefügt. Dieses Problem wurde in den ursprünglichen Versionshinweisen zu Version 5.1.0 irrtümlich ausgelassen.

  • Das Problem #39659 wurde aus dem Abschnitt „Bekannte Probleme bei Edge/Gateway“ entfernt, da es sich um ein Duplikat eines anderen Tickets (#39501) handelt, das in Version 4.3.0 behoben wurde.

29. Januar 2023. Sechste Auflage.

  • Im Abschnitt Kompatibilität wurde der Import-Hinweis zum Ende des Supports für 4.2.x überarbeitet und Version 4.3.x hinzugefügt, um die neu überarbeiteten Daten für die SD-WAN Edge-Software zu berücksichtigen.

  • Im Abschnitt Neue SD-WAN-Verbesserungen wurden die Erweiterungen Nicht-SD-WAN-Ziel (NSD)- und Cloud-Security-Service-(CSS)-Tunnel hinzugefügt. Dies wurde in der ersten Auflage der Versionshinweise irrtümlich ausgelassen.

  • Im Abschnitt Wichtige Hinweise wurde ein Hinweis zu Dead Peer Timeout (DPD) für Nicht-SD-WAN-Ziele hinzugefügt. Dieser Hinweis bezieht sich auf das geänderte DPD-Verhalten infolge der Umstellung der VMware SD-WAN-Software auf das QuickSec IPsec-Toolkit. Dieses Material wurde in der ersten Auflage der Versionshinweise irrtümlich ausgelassen.

20. Januar 2023. Fünfte Auflage.

  • Ein neuer Gateway-Rollup-Build R5101-20230112-GA wurde zum Abschnitt „Behobene Probleme bei Edge/Gateway“ hinzugefügt. Dies ist der erste Gateway-Rollup-Build und ist der neue Gateway-GA-Build für Version 5.1.0.

  • Gateway-Build R5101-20230112-GA enthält die Fixes für die Probleme #97272, #104487, die jeweils in diesem Abschnitt dokumentiert sind.

  • Die Sprache für die erweiterte Funktion MAC-Adressen-Umgehung (MAC Address Bypass, MAB) wurde geändert, um deutlich zu machen, dass diese Funktion nicht für VLANs unterstützt wird und daher nicht für geswitchte Ports verwendet werden kann, die für die 802.1x-Authentifizierung auf ein VLAN angewiesen sind. Daher wird MAB ab dieser Version 5.1.0 nur auf gerouteten Schnittstellen unterstützt.

12. Januar 2023. Vierte Auflage.

  • Version 5.1.0 wurden zwei Verbesserungen hinzugefügt: Synchronisierung der lokalen HA-Route und BGP für Graceful Restart.

5. Januar 2023. Dritte Auflage.

  • Der neue Orchestrator-Rollup-Build R5101-20221220-GA wurde zum Abschnitt „Behobene Probleme bei Orchestrator“ hinzugefügt. Dies ist der erste Orchestrator-Rollup-Build für Version 5.1.0.

  • Orchestrator-Build R5101-20221220-GA enthält die Fixes für die Probleme #100133, #101835, #102806 und #103622,, die jeweils in diesem Abschnitt dokumentiert sind.

15. Dezember 2022. Zweite Auflage.

  • Das offene Problem #39134 wurde aus den bekannten Problemen für Edges/Gateways entfernt, da es von der technischen Abteilung als behoben betrachtet wurde. Fälschlicherweise wurde dieses Ticket bereits in der ersten Ausgabe der Versionshinweise zu Version 5.1.0 zu den behobenen Problemen für Edges/Gateways hinzugefügt.

08. Dezember 2022. Erste Auflage.

Behobene Probleme bei Edge und Gateway

Behoben in Gateway-Version R5103-20230621-GA

Gateway-Build R5103-20230621-GA wurde am 23.06.2023 veröffentlicht und ist der dritte Gateway-Rollup für Version 5.1.0.

Dieser Gateway-Rollup-Build behebt die folgenden kritischen Probleme ab dem zweiten Gateway-Rollup R5102-20230310-GA.

  • Behobenes Problem 82808: Bei einem VMware SD-WAN Edge, der einen Cloud-Security-Service (CSS) verwendet und auf dem die L7-Integritätsprüfung aktiviert ist, kann der Kunde beobachten, dass der Datenverkehr über diese CSS-Tunnel fehlschlägt, obwohl der VMware SASE Orchestrator die Tunnel weiterhin als AKTIV markiert.

    Obwohl der L7-Test mit einem 4XX-HTTP-Fehler fehlschlägt, bestätigt das VMware SD-WAN Gateway den Fehler nicht und fordert den Orchestrator nicht dazu auf, die CSS-Tunnel als INAKTIV zu markieren.

  • Behobenes Problem 100172: Wenn ein Benutzer versucht, über ein VMware SD-WAN Gateway per SSH auf einen Edge zuzugreifen, kann es zu einem Ausfall des Datenebene-Diensts und zur Generierung eines Speicherauszugs kommen, gefolgt von einem Neustart zur Wiederherstellung.

    Dieses Problem kann beim Gateway auftreten, wenn ein Benutzer versucht, über das Gateway per SSH auf einen Edge zuzugreifen, und diese SSH-Sitzung eine ICMP-Fehlermeldung FRAG_NEEDED ICMP erzeugt.

  • Behobenes Problem 101536: Bei einem VMware SD-WAN Gateway kann es zu einem Ausfall des Datenebene-Diensts kommen, wodurch ein Core-Fehler generiert und ein Neustart zur Wiederherstellung ausgelöst wird.

    Wenn der Benutzer in der Kerndatei nachschaut, sieht er eine Protokollierung, die sich auf den Mutex-Monitor des Gateways bezieht und auftreten kann, wenn Hub und Cluster Interconnect von einem Kundenunternehmen verwendet werden, das mit diesem Gateway verbunden ist.

  • Behobenes Problem 104619: Wenn zwei oder mehr Unternehmen dasselbe Partner-Gateway nutzen und alle über eine Partnerübergabekonfiguration verfügen, bei der die Unternehmen IPv4 verwenden, schlägt die Einrichtung einer Sicherheitsverbindung (Security Association, SA) für die anderen mit diesem Partner-Gateway verbundenen Unternehmen fehl, wenn eine Partnerübergabe in einem Unternehmen entfernt wird.

    Wenn beispielsweise zwei Unternehmen mit den Namen Unternehmen-1 und Unternehmen-2 ein Partner-Gateway verwenden und eine Partnerübergabe in beiden Unternehmen konfiguriert ist, legt der SD-WAN-Dienst eine einzige IP-Adresse in der virtuellen Netzwerkschnittstelle des Gateways fest. Wenn ein Benutzer die Partnerübergabe in Unternehmen-2 deaktiviert, geht der SD-WAN-Dienst zum nächsten Flow über und löscht diese IP-Adresse aus der virtuellen Netzwerkschnittstelle, obwohl dieselbe IP-Adresse für die Übergabe in Unternehmen-1 verwendet wird. Infolgedessen ist Unternehmen-1 nicht in der Lage, IPsec-Tunnel mit seinen Edges aufzubauen.

    Wenn dieses Problem bei einem Gateway auftritt und nicht behoben wurde, kann das Problem durch einen Neustart des Gateways behoben werden.

  • Behobenes Problem 107309: Wenn ein Kunde die L7-Integritätsprüfung für ein Nicht-SD-WAN-Ziel über Edge auf einem 4.x-Orchestrator konfiguriert und der Kunde nach der Aktualisierung des Orchestrators auf Version 5.x versucht, den Wiederholungswert für den L7-Test zu ändern, wendet der Edge den neuen Wert nicht an.

    Beispiel: Wenn der Wiederholungswert für den L7-Integritätsprüfungstest 3 lautet (der Tunnel wird bei 3 fehlgeschlagenen Tests als ausgefallen markiert) und der Kunde diesen Wert in 1 ändert, verwendet die L7-Integritätsprüfung weiterhin den ursprünglichen Wert von 3 Wiederholungen, bevor der Tunnel als ausgefallen markiert wird.

  • Behobenes Problem 108473: Bei einem VMware SD-WAN Gateway kann es zu einem Ausfall des Datenebene-Diensts kommen, wodurch ein Kern erzeugt und ein Neustart zur Wiederherstellung des Diensts durchgeführt wird.

    Auf dem Gateway kann ein Sequenznummernüberlauf auftreten, der eine Löschung aller IPsec-SAs (Security Associations, Sicherheitsverbindungen) auslöst. Beim Versuch, alle SAs zu löschen, sucht der Gateway-Prozess auf Basis einer Tunnel-ID nach einem Tunnel. Da dieser Tunnel aber nicht vorhanden ist, kommt es zu einem Ausfall des Gateway-Diensts.

  • Behobenes Problem 111646: Bei einem VMware SD-WAN Gateway mit hoher CPU-Auslastung kann es zu einem Ausfall und Neustart des Datenebene-Diensts zu Wiederherstellungszwecken kommen.

    Einem Benutzer, der den vom Gateway erzeugten Kern überprüft, werden eine Mutex-Überwachungsausnahme und die Meldung Program terminated with signal SIGXCPU, CPU time limit exceeded message angezeigt. Das Problem steht im Zusammenhang mit einem Gateway-Prozess, der eine Thread-Sperre mit niedrigerer Priorität freigibt.

  • Behobenes Problem 111888: Ein mit 4 Kernen bereitgestelltes VMware SD-WAN Gateway, das mit mehr als 2000 Tunneln verbunden ist, kann eine hohe CPU-Auslastung aufweisen. Mit dem Gateway verbundene Tunnel sind unter Umständen instabil.

    Einer der Gateway-Threads nutzt zu viel CPU-Kapazität in einem Gateway mit 4 Kernen, wodurch das Gateway daran gehindert wird, stabile Tunnel aufrechtzuerhalten.

  • Behobenes Problem 111924: Ein Kunde stellt unter Umständen fest, dass der Mehrfachpfad-Datenverkehr (d. h. Datenverkehr, der das VMware SD-WAN Gateway durchläuft) siteübergreifend verworfen wird, obwohl die entsprechenden VMware SD-WAN Edge-Tunnel zum Gateway aktiv und stabil sind.

    Da es keinen Grenzwert für die maximale Anzahl an Malen gibt, die ein Gateway ein VCMP-Paket erneut übertragen kann (SD-WAN-Verwaltungsprotokoll), können solche Neuübertragungen Verbindungen mit niedriger Bandbreite überlasten. Diese Neuübertragungen führen auch zu einem Paketstau im Scheduler, wenn der Edge eine Verbindung mit geringer Bandbreite aufweist, da die Neuübertragungen nicht schnell genug verarbeitet werden können. Schließlich laufen die Scheduler-Warteschlangen über, was dazu führt, dass der Scheduler Pakete von allen Edges verwirft. Direkter Datenverkehr, der das Gateway nicht verwendet, ist von diesem Problem nicht betroffen.

    Wenn dieses Problem auftritt und ein Gateway ohne Fix für dieses Problem ausgegeben wird, besteht die einzige Möglichkeit zur Fehlerbehebung darin, dass ein Operator-Benutzer die Edges, die den Paketstau im Scheduler verursachen, mit dem Befehl debug.py --qos_dump_net ermittelt und im betroffenen Gateway blockiert.

  • Behobenes Problem 112016: Bei einem VMware SD-WAN Gateway können mehrere Ausfälle des Datenebene-Diensts mit generierten Core-Fehlern auftreten, nachdem ein Gateway-Neustart initiiert wurde.

    Bei der Untersuchung der Core-Fehler stellt ein Operator unter Umständen fest, dass jeder Fehler durch ein Problem bei der Mutex-Überwachung ausgelöst wird. Der Zeitaufwand zur VCMP-Verarbeitung (SD-WAN-Verwaltungsprotokoll) für den Thread, der die Verwaltung übernimmt, erhöht sich deutlich. Während des Starts eines Gateways führt dies dazu, dass der VCMP-Thread über längere Zeit (mehr als 60 Sekunden) kontinuierlich mit 100 % ausgeführt wird, was wiederum Ausfälle des Gateway-Diensts zur Folge hat, die auf die Mutex-Überwachung zurückzuführen sind.

  • Behobenes Problem 112017: Ein Operator stellt unter Umständen fest, dass ein mit 4 Kernen bereitgestelltes VMware SD-WAN Gateway eine hohe Last aufweist, was zu einem oder mehreren Ausfällen des Datenebene-Diensts führt.

    Die Gateway-Kernprotokolle verweisen auf die Mutex-Überwachung, die den Dienstausfall auslöst. Es gibt mehrere Tickets, die sich mit dem oben genannten Symptom befassen. In diesem Fall besteht die Ursache darin, dass VCMP-Threads (Verwaltungsprotokoll) die CPU-Prozesse eines Gateways mit 4 Kernen auslasten, wodurch die Mutex-Überwachung ausgelöst wird. Dieses Ticket ermöglicht einem Operator-Benutzer, einen Grenzwert von 20 für halb offene VCMP-Verbindungen zu konfigurieren. Dies kann entweder über die CLI (Command Line Interface, Befehlszeilenschnittstelle) des Gateways mithilfe von debug.py oder über eine statische Konfigurationsdatei erfolgen.

  • Behobenes Problem 112019: Bei einem VMware SD-WAN Gateway kann es zu einem Ausfall des Datenebene-Diensts und einem Neustart zur Wiederherstellung unter hoher CPU-Last kommen.

    Wie bei anderen Tickets wegen eines Gateway-Dienstausfalls im 5.1.0.3-Rollup-Build beobachtet der Operator oder Partner einen Mutex-Überwachungsauslöser in der Core-Datei. Bei diesem Ticket besteht die Standardisierung darin, die NAT-Debug-Protokolle außerhalb des Geltungsbereichs für die NAT-Tabellensperre zu verschieben, um eine der Ursachen für dieses Problem zu vermeiden.

  • Behobenes Problem 112020: Bei einem mit 4 Kernen bereitgestellten VMware SD-WAN Gateway mit hoher CPU-Auslastung kann es zu einem Ausfall und anschließendem Neustart des Datenebene-Diensts kommen.

    Beim Überprüfen der Hauptdatei des Gateways stellt ein Benutzer einen Mutex-Überwachungsfehler fest, der dadurch verursacht wird, dass ein Gateway-Prozess nicht ausgeführt werden kann, weil die CPU aufgrund einer hohen Tunnelanzahl mit maximaler Kapazität ausgeführt wird.

  • Behobenes Problem 112800: Kunden, die ein VMware SD-WAN Gateway verwenden, sehen sich mit einer schlechten Leistung konfrontiert, einschließlich Tunnel und Routen, die viel mehr Zeit zum Konvergieren benötigen.

    Bei der Überwachung eines Gateways stellt ein Benutzer fest, dass die Kerne der Datenebene (dp-cores) zu 100 % ausgelastet sind, weil veraltete Flow-Dispatcher-Flows nicht vom Gateway bereinigt werden.

  • Behobenes Problem 114052: Bei einem VMware SD-WAN Gateway kann es zu einem Ausfall des Datenebene-Diensts kommen, wodurch ein Kern erzeugt und ein Neustart ausgelöst wird.

    Das Problem wird durch die Zeitüberschreitung eines Threads im IPsec-Prozess des Gateways verursacht, was zu einem Ausfall des Gateway-Diensts führt.

  • Behobenes Problem 114084: Für einen Kunden, der einen Cloud-Security-Service (CSS) vom Typ „Zscaler“ mit L7-Integritätsprüfung für einen VMware SD-WAN Edge konfiguriert hat, werden die aktualisierten Details beim Aktualisieren des Zscaler-Cloud-Servers auf dem VMware SASE Orchestrator nicht auf den Edge angewendet.

    Obwohl der Orchestrator die neue Zscaler-Cloud-Serverkonfiguration anzeigt, senden Edge und Gateway den Datenverkehr und die L7-Tests über den alten Zscaler-Server statt über diesen neuen Server.

  • Behobenes Problem 114282: Wenn ein mit 4 Kernen bereitgestelltes VMware SD-WAN Gateway neu gestartet wird, kann es bis zu zwanzig Minuten dauern, um ca. 3000 Tunnel für die verbundenen Kundenunternehmen zu konvergieren.

    Es wird erwartet, dass ein Gateway ca. 3000 Tunnel in etwa 5 Minuten konvergiert. Dies steht im Widerspruch zu den bei diesem Problem beobachteten 20 Minuten. Die langsamere Rate führt bis zur vollständigen Wiederherstellung der Tunnel zu einer Unterbrechung des Kundendatenverkehrs. Die Ursache der langsameren Konvergenz wird auf eine Konfiguration im IPsec-Prozess des Gateways zurückgeführt, der Sicherheitsverbindungen und Schlüssel verwaltet und mit diesem Ticket korrigiert wird.

  • Behobenes Problem 114932: Bei VMware SD-WAN Edge-Client-Benutzern kann die Leistung des Datenverkehrs, der über das primäre VMware SD-WAN-Gateway des Edge läuft, beeinträchtigt sein.

    Operator-Benutzer können eine hohe CPU-Nutzung für das Gateway feststellen, obwohl die Tunnelanzahl innerhalb der unterstützten Grenzwerte liegt. Die hohe CPU-Nutzung ergibt sich aus einer veralteten IKE-SA (Security Association, Sicherheitsverbindung), die für einen längeren Zeitraum in der IKE-Tabelle verbleibt, und führt dazu, dass die Konvergenz von Tunneln länger dauert. Hierdurch kommt es zu einem starken Rückgang des Datenverkehrs sowie zu instabilen Pfaden für den Kundendatenverkehr, der das Gateway durchläuft.

  • Behobenes Problem 115604: Bei einem VMware SD-WAN Edge oder Gateway kann es zu einem Ausfall des Datenebene-Diensts kommen, wodurch ein Speicherauszug mit einem Assert in der Protokollierung erzeugt wird.

    Wenn ein Edge oder Gateway ein beschädigtes Paket verarbeitet, kann die Software auf ein Problem stoßen, bei dem die tatsächliche Länge des Benutzerpakets größer ist als der interne Paketpuffer. Es wird erwartet, dass das Gateway diese Art von Paketen verwirft und verhindert, dass sie an den Edge gesendet werden, aber stattdessen werden sie verarbeitet, was zu einem Dienstfehler und Neustart führt.

  • Behobenes Problem 115692: Ein Operator beobachtet unter Umständen eine stark steigende Arbeitsspeichernutzung in einem VMware SD-WAN Gateway, was zu einer Auslastung des Arbeitsspeichers und einem defensiven Neustart des Diensts zum Bereinigen des Arbeitsspeichers führen kann.

    In diesem Fall kommt es beim Gateway zu einem IKE-Arbeitsspeicherverlust, weil das Gateway Zertifikate mit Peer-Sites verlängert.

    Ohne einen Fix für dieses Problem kann der Operator die Arbeitsspeichernutzung auf dem Gateway lediglich überwachen und das Gateway proaktiv in einem Wartungsfenster neu starten. Hierdurch wird gewährleistet, dass bei Kundenstandorten, die dieses Gateway verwenden, nur geringfügige Störungen auftreten.

  • Behobenes Problem 116182: Bei einem VMware SD-WAN Gateway kann es zu einem Ausfall des Datenebene-Diensts kommen, wodurch ein Core-Fehler generiert und ein Neustart ausgelöst wird.

    Das Problem tritt bei Gateways auf, bei denen die verbundenen SD-WAN-Edges mit einer Internet-Backhaul-Richtlinie konfiguriert sind, die entweder IPv6 oder IPv4/IPv6 im gemischten Modus für ein Nicht-SD-WAN-Ziel (NSD) über Gateway verwendet. Wenn das Gateway in diesem Szenario IPv6-Pakete empfängt, die für ein NSD mit IPv4 bestimmt sind, hat dies ein Fehlschlagen des Gateway-Diensts zur Folge.

Behoben in der Edge- und Gateway-Version R5102-20230310-GA

Edge- und Gateway-Build R5102-20230310-GA wurde am 14. März 2023 veröffentlicht und ist der zweite Edge- und Gateway-Rollup für Version 5.1.0.

Dieser Gateway-Rollup-Build behebt die folgenden kritischen Probleme ab dem ersten Edge- und Gateway-Rollup R5101-20230112-GA.

  • Behobenes Problem 98782: Bei einem VMware SD-WAN Gateway kann es während des IPsec-Tunnelaufbaus zu einem Ausfall des Datenebene-Diensts kommen. Infolgedessen wird ein Core generiert und ein Neustart durchgeführt.

    Wenn dieses Problem bei einem Gateway auftritt, kann der Neustart zu einer kurzen Unterbrechung des Kundendatenverkehrs führen, und zwar sowohl für die mit diesem Gateway verbundenen Edges als auch für Nicht-SD-WAN-Ziele, die das Gateway für IPsec-Tunnel verwenden. Dies wird durch eine Race-Bedingung verursacht, wenn das Gateway einen IPsec-Tunnel aufbaut und dadurch den Ausfall des Datenebene-Diensts auslöst.

  • Behobenes Problem 103708: Wenn neue Regeln in einer BGP-Filterkonfiguration hinzugefügt werden, kann es zu unerwarteten BGP-Routen kommen, die vom VMware SD-WAN Edge empfangen und gesendet werden.

    Beim Hinzufügen neuer Regeln zu BGP-Filtern über den Orchestrator werden die Präfixlisten zur Routing-Konfiguration des Edge hinzugefügt, ohne dass die alten Einträge entfernt werden. Dies hat veraltete Routenpräfixlisten und unerwartetes Filterverhalten zur Folge.

  • Behobenes Problem 104141: Bei Benutzern hinter einem VMware SD-WAN Edge oder Kunden, die mit einem VMware SD-WAN Gateway verbunden sind, kann es zu erheblichen Problemen bei jeglichem Datenverkehr, der diesen Edge nutzt oder dieses Gateway durchläuft, mit dem Ergebnis kommen, dass kein Datenverkehr mehr weitergeleitet werden kann.

    Wenn das Problem auftritt, verfügt der Edge oder das Gateway über eine unbegrenzte Anzahl an Arbeitsspeicherpuffern (mbufs), die von der Jitter-Pufferwarteschlange verbraucht werden, weil immer mehr Verwaltungstunnel-Zeitstempel von einem Peer empfangen werden. Dies löst einen Ganzzahlunterlauf in der Jitter-Berechnung aus, wodurch Pakete praktisch unbegrenzt gepuffert werden. Dies betrifft zunächst nur gepufferte Flows. Nach Ablauf eines bestimmten Zeitraums nähert sich die Anzahl der für die Jitter-Pufferwarteschlange verbrauchten mbufs jedoch der Summe der verfügbaren mbufs, und das SD-WAN-Gerät (Edge oder Gateway) kann den gesamten Datenverkehr nicht vollständig weiterleiten. Wenn ein Gateway betroffen ist, wirkt sich dies nur auf Datenverkehr mit mehreren Pfaden aus, der das Gateway durchläuft. Direkt verlaufender Kundendatenverkehr ist davon nicht betroffen.

    Das Ticket #105744 beschäftigt sich ebenfalls mit den hier aufgetretenen Symptomen, behebt aber eine andere Ursache. Der Unterschied zwischen den beiden Tickets: Der in #104141 enthaltene Fix bezieht sich auf die Arbeitsspeicherpuffer, die von der Jitter-Pufferwarteschlange aufgrund der zunehmenden vom Peer empfangenen Verwaltungszeitstempel verbraucht werden. Der in #105744 enthaltene Fix beschränkt den Jitter-Puffer auf 25 % des gesamten Arbeitsspeicherpuffers, um sicherzustellen, dass dieses Problem nicht erneut auftritt.

    Ohne einen Fix für dieses Problem auf dem Edge oder Gateway kann ein Benutzer die Nutzung des Arbeitsspeicherpuffers (mbuf) auf dem Orchestrator überwachen und nach einer erhöhten mbuf-Nutzung aufgrund von Paketen in der Jitter-Pufferwarteschlange suchen. Wenn der Benutzer dieses Problem beobachtet, kann er Flows für den Edge (über die Remote-Diagnose) oder das Gateway leeren, um das Problem vorübergehend zu beheben. Das Problem tritt jedoch solange auf, bis der Fix angewendet wurde.

  • Behobenes Problem 105744: Bei Benutzern hinter einem VMware SD-WAN Edge oder Kunden, die mit einem VMware SD-WAN Gateway verbunden sind, kann es zu erheblichen Problemen bei jeglichem Datenverkehr, der diesen Edge nutzt oder dieses Gateway durchläuft, mit dem Ergebnis kommen, dass kein Datenverkehr mehr weitergeleitet werden kann.

    Dieses Ticket und Problem #104141 stehen in direktem Zusammenhang und haben dieselben Symptome und Ursachen, die hier wiederholt werden: Wenn das Problem auftritt, verfügt der Edge oder das Gateway über eine unbegrenzte Anzahl an Arbeitsspeicherpuffern (mbufs), die von der Jitter-Pufferwarteschlange verbraucht werden, weil immer mehr Verwaltungstunnel-Zeitstempel von einem Peer empfangen werden. Dies löst einen Ganzzahlunterlauf in der Jitter-Berechnung aus, wodurch Pakete praktisch unbegrenzt gepuffert werden. Dies betrifft zunächst nur gepufferte Flows. Nach Ablauf eines bestimmten Zeitraums nähert sich die Anzahl der für die Jitter-Pufferwarteschlange verbrauchten mbufs jedoch der Summe der verfügbaren mbufs, und das SD-WAN-Gerät (Edge oder Gateway) kann den gesamten Datenverkehr nicht vollständig weiterleiten. Wenn ein Gateway betroffen ist, wirkt sich dies nur auf Datenverkehr mit mehreren Pfaden aus, der das Gateway durchläuft. Direkt verlaufender Kundendatenverkehr ist davon nicht betroffen.

    Der Unterschied zwischen den beiden Tickets: Der in #104141 enthaltene Fix bezieht sich auf die Arbeitsspeicherpuffer, die von der Jitter-Pufferwarteschlange aufgrund der zunehmenden vom Peer empfangenen Verwaltungszeitstempel verbraucht werden. Der in #105744 enthaltene Fix beschränkt den Jitter-Puffer auf 25 % des gesamten Arbeitsspeicherpuffers, um sicherzustellen, dass dieses Problem nicht erneut auftreten kann.

    Ohne einen Fix für dieses Problem kann entweder der Edge oder das Gateway auf dem Orchestrator überwacht werden, auf dem ein Benutzer aufgrund von Paketen in der Jitter-Pufferwarteschlange nach einer erhöhten mbuf-Nutzung sucht. Der Benutzer kann Flows für den Edge oder das Gateway leeren, um das Problem vorübergehend zu beheben. Das Problem tritt jedoch solange auf, bis der Fix angewendet wurde.

  • Behobenes Problem 106587: Ein Kunde beobachtet möglicherweise, dass der gesamte Datenverkehr nach dem Zufallsprinzip verworfen und der Status beibehalten wird.

    Das Problem steht im Zusammenhang mit der Installation der IPsec-Sicherheitsverbindung (SA) auf Seiten des Antwortdiensts. Wenn der Edge eine neue SA initiiert oder eine erneute Schlüsselerstellung durchführt, besteht die Möglichkeit, dass das SPI-Paket (Sicherheitsparameter-Index) der alten SA vor der neuen SA (SPI) eintrifft. In diesem Fall löscht das VMware SD-WAN Gateway die neu erstellte SA (SPI). Der hinzugefügte Fix verhindert das Löschen der neu erstellten SA (SPI).

    Ohne einen Fix für dieses Problem müsste ein Partner- oder Operator-Benutzer das Gateway neu starten, um alle betroffenen IPsec-Tunnel neu zu starten.

Behoben in Gateway-Version R5101-20230112-GA

Gateway-Build R5101-20230112-GA wurde am 19.01.2023 veröffentlicht und ist der erste Gateway-Rollup für Version 5.1.0.

Dieser Gateway-Rollup-Build behebt die folgenden kritischen Probleme seit dem ursprünglichen Gateway-Build R5100-20221204-GA.

  • Behobenes Problem 97272: Wenn an einer Site mit einer Hochverfügbarkeitstopologie, in der OSPF verwendet wird, eine Split-Brain-Bedingung auftritt (beide SD-WAN-Edges sind aktiv), wird die Standardroute zum Core-Router entfernt und die HA-Site kann keine Peer-Sites im Netzwerk erreichen.

    Das Alter der Verbindungsstatusankündigung (Link-State Advertisement, LSA) des Core-Routers wird mit dem des aktiven Edge synchronisiert. Wenn eine HA-Split-Brain-Bedingung auftritt, schaltet der Standby-Edge auf aktiv und sendet ein neues LSA-Alter an den Core-Router. Da sowohl der aktive als auch der Standby-Edge dieselbe Router-ID haben, wird vom neuen aktiven Edge ein anderes LSA-Alter gesendet. Diese Nichtübereinstimmung führt dazu, dass das LSA-Alter im Core-Router auf einen Höchstwert von 3600 gesetzt wird, wodurch auch die Core-Route zur HA-Site entfernt wird, was zu einem vollständigen Ausfall an der Site führt.

  • Behobenes Problem 104487: Aufgrund der Verlangsamung des Datenbankdienstes kann es bei VMware SASE Orchestrator-Benutzern zu einer allgemeinen Verlangsamung und einigen API-Ausfällen kommen. Weitere Nebeneffekte sind: SD-WAN-Gateways/-Edges werden in der Benutzeroberfläche als offline angezeigt, Konfigurationsänderungen, die über die Orchestrator-Benutzeroberfläche vorgenommen werden, werden nicht an die SD-WAN-Edges weitergegeben, und es kommt zum Verlust von Berichtsfunktionen.

    Die Probleme werden alle dadurch verursacht, dass der Orchestrator-Datenbankdienst mit dem Fehler: zu viele offene Dateien (too many open files) fehlschlägt. Dieser Fehler wird vom VMware SASE Orchestrator-Operator über die Protokolle beobachtet. Bei einem Endbenutzer, der über die Benutzeroberfläche auf VMware SASE Orchestrator zugreift, kommt es zu einer Verlangsamung und zeitweiligen API-Fehlern, die Fehlermeldungen auf der Benutzeroberfläche verursachen.

Behoben in der Edge- und Gateway-Version R5100-20221204-GA

Edge- und Gateway-Build R5100-20221204-GA wurde am 08.12.2022 veröffentlicht und behebt die folgenden Probleme seit Edge-Build R5012-20221107-GA und Gateway-Build R5011-20221007-GA.

Hinweis:

Version 5.1.0 enthält alle Edge- und Gateway-Fixes, die in den Versionshinweisen zu 5.0.0 aufgeführt sind, sowie alle Edge- und Gateway-Fixes in den 5.0.1-Versionshinweisen bis zu den oben aufgeführten Builds.

  • Behobenes Problem 26085: Ein Kunde, der eine Hub/Spoke-Topologie und Partner-Gateways verwendet, kann beobachten, dass der Datenverkehr an einem VMware SD-WAN Spoke-Edge unterbrochen wird, wenn eines der Gateways von einem Hub-Edge aus nicht konfiguriert ist.

    Der verworfene Datenverkehr verwendet eine veraltete Route für ein Gateway, das nicht mehr zugewiesen ist. Bei Aufhebung der Konfiguration zwischen einem Gateway und einem Hub-Edge erhält das Gateway keine diesbezügliche Benachrichtigung und behandelt das Ereignis wie einen einfachen Tunnelausfall. Infolgedessen stellt das Gateway dem Spoke-Edge weiterhin seine Route zur Verfügung, und der Spoke-Edge entfernt die Remote-Route (die über den Hub-Edge erreichbar ist) nicht, da der Hub-Edge weiterhin für den Spoke-Edge erreichbar ist.

    Wenn dieses Problem mangels eines festen Builds auftritt, kann es nur durch eine Unterbrechung der Verbindung zwischen dem Spoke-Edge und dem Gateway behoben werden.

  • Behobenes Problem 29929: Bei einer Site, die mit einer Hochverfügbarkeitstopologie bereitgestellt wird, kann sich ein Benutzer bei einem HA-Failover möglicherweise nicht bei der lokalen Benutzeroberfläche für die HA-Edges anmelden.

    Wenn die lokalen Anmeldedaten für die HA-Edges im Orchestrator geändert werden, wendet der richtige aktive Edge die Änderung an, aber die neuen Anmeldedaten werden nicht mit dem Standby-Edge synchronisiert. Dies hat zur Folge, dass bei einem HA-Failover und der Heraufstufung des Standby-Edge zum aktiven Edge die standardmäßigen Benutzer-/Kennwortanmeldedaten verwendet werden. Wenn sich ein Benutzer dann mit den neueren Anmeldedaten bei der lokalen Benutzeroberfläche anmeldet, schlägt die Anmeldung fehl.

  • Behobenes Problem 32413: Die Temperatur ist nicht in der Integritätsstatistik oder in der MIB enthalten.

    Der Fix fügt die CPU-Temperatur zu der MIB hinzu, die für SNMP und die in Überwachen (Monitor) > Edge > System gemessenen Metriken verwendet wird (auch bekannt als „Edge-Integritätsstatistik“ (Edge Health Stats)).

  • Behobenes Problem 32654: Benutzer auf einer VMware SD-WAN Edge-Site, auf der eine WAN-Schnittstelle ausgefallen ist, können möglicherweise einen Rückgang des Datenverkehrs beobachten.

    Der Datenverkehr sinkt aufgrund verbundener Routen, die weiterhin für ein VMware SD-WAN Gateway annonciert werden, obwohl der VMware SD-WAN Edge bei einem Ausfall der verbundenen Schnittstelle nicht erreichbar ist.

  • Behobenes Problem 39134: Auf der Seite „Überwachen (Monitor) > Edge > System“ wird der CPU-Prozentsatz nicht korrekt angezeigt.

    Der auch als „Edge-Integritätsstatistik“ bezeichnete VMware SASE Orchestrator erhält keine genauen Informationen über die Edge-CPU-Auslastung und gibt diese in Diagrammen auf der Seite „System“ aus. Für Kunden, die ein Edge-Problem beheben möchten, erweisen sich dies Informationen als ungenau und irreführend.

  • Behobenes Problem 45453: Ein Kunde kann einen VMware SD-WAN Edge nicht so konfigurieren, dass 2 WAN-Schnittstellen das gleiche VLAN verwenden.

    Das Problem tritt in einem Szenario auf, in dem an einer Site mehrere Edge-WAN-Ports mit demselben L2-Switch und demselben VLAN verbunden sind. Das Problem bei dieser Konfiguration besteht darin, dass der Edge beim Senden von Verwaltungsdatenverkehr manchmal die falsche Quell-MAC-Adresse verwenden kann.

  • Behobenes Problem 50920: VMware SD-WAN Edge sendet keine Warnung, wenn die Anzahl verbundener Tunnel 60 % des hardwaredefinierten Grenzwerts für dieses Edge-Modell erreicht.

    Wenn die Anzahl verbundener Tunnel seine Hardwaregrenze erreicht, sendet der Edge eine Warnung mit dem Wortlaut „Anzahl eingerichteter Tunnel überschreitet die Gerätekapazität“. Sobald dieser Grenzwert erreicht ist, lässt der Edge zusätzliche dynamische Tunnel erst wieder zu, wenn vorhandene Tunnel entfernt werden. Es wird jedoch keine Zwischenwarnung gesendet, um den Kunden darauf hinzuweisen, dass dieser Tunnelgrenzwert potenziell erreicht werden kann, sodass der Kunde keine angemessene Vorlaufzeit hat, um sein Netzwerk zu verwalten.

  • Behobenes Problem 53337: Paketlöschungen können mit einer AWS-Instanz eines VMware SD-WAN Gateways beobachtet werden, wenn der Durchsatz über 3200 MBit/s liegt.

    Wenn der Datenverkehr einen Durchsatz von über 3200 MBit/s und eine Paketgröße von 1300 Byte überschreitet, werden Paketverwerfungen bei RX und bei IPv4 BH-Übergabe beobachtet.

  • Behobenes Problem 54846: VMware SD-WAN SNMP-MIBs verwenden Indikatoren für Jitter, Latenz und Paketverlust.

    In den SNMP-MIBs von VMware sind Latenz, Jitter und Paketverlust als Counter64 definiert, was für diese Typen nicht angemessen ist. Indikatoren sollten für Datentypen verwendet werden, die immer höhere Werte aufweisen und die in SNMP nie zurückgesetzt werden, wie z. B. Byte Tx/Rx. Im Gegensatz dazu weisen Latenz-, Jitter- und Paketverlust keine steigenden, sondern dynamisch angepasste Werte auf und sollten keine Indikatoren verwenden.

  • Behobenes Problem 55327: Die SSH-Verbindung von einem VMware SD-WAN Gateway zu einem VMware SD-WAN Edge funktioniert möglicherweise nicht, wenn der Tunnel vom Edge zum Gateway kontinuierlich flappt.

    Bei kontinuierlichem Tunnel-Flapping zwischen Edge und Gateway kann der im Edge installierte Routeneintrag, der die SSH-Verbindung vom Gateway erlaubt, gelöscht werden, wodurch die SSH-Verbindung fehlschlägt.

  • Behobenes Problem 56153: Wenn die Zuweisung eines eingehenden BGP-Filters in einem Kundenunternehmen, in dem ein Nicht-SD-WAN-Ziel über Gateway bereitgestellt und BGP über IPsec verwendet wird, vom Kunden aufgehoben wird, wird der Filter auf dem VMware SD-WAN Gateway nicht entfernt und die Routenzuordnung wird mit ihm angewendet.

    Dieses Problem kann zu unerwartetem Routing für den Kunden führen, da er erwartet, dass der BGP-Filter für eingehende Verbindungen inaktiv ist, obwohl er noch vom Gateway und Edge verwendet wird.

  • Behobenes Problem 60844: Eine Business Policy, die darauf ausgelegt ist, den gesamten Datenverkehr, der den Policy-Kriterien entspricht, zu verwerfen, indem ein Ratengrenzwert von 0 % konfiguriert wird, funktioniert nicht.

    Die Konfiguration des Ratengrenzwerts von 0 % ist zwar zulässig, wird vom Edge jedoch nicht als 0 %, sondern als 100 % angesehen, wodurch der Zweck der Business Policy vollständig verfehlt wird.

    Auf einem Edge ohne diesen Fix besteht die Problemumgehung darin, eine Firewallregel zu verwenden, um den Datenverkehr für eine Business Policy anzupassen und zu verwerfen.

  • Behobenes Problem 61804: In einem Kundenunternehmen mit BGP ist unter Umständen zu beobachten, dass von einem Peer erlernte VMware SD-WAN Edge-Routen an den Peer selbst zurück annonciert werden.

    Der Edge sollte die vom Peer erlernten Routen nicht an den Peer selbst annoncieren. Dies führt zu einem ungünstigen Routing-Verhalten und zum Verlust von Datenverkehr.

  • Behobenes Problem 62701: Wenn bei einem VMware SD-WAN Edge, der als Teil eines Edge-Hub-Clusters bereitgestellt wird, Cloud-VPN nicht unter dem globalen Segment, sondern unter einem nicht-globalen Segment aktiviert ist, kann ein vom Orchestrator gesendetes Update der Control Plane dazu führen, dass alle WAN-Links auf dem Hub-Edge flappen.

    Wenn die WAN-Links des Hub-Edge in schneller Abfolge unterbrochen und wieder aufgebaut werden (Flap), hat dies Auswirkungen auf den Echtzeit-Datenverkehr wie z. B. Sprachanrufe. Dieses Problem wurde bei einer Kundenbereitstellung beobachtet, bei der Cloud-VPN auf dem globalen Segment des Hub-Edge nicht aktiviert war. Die Clusterkonfiguration war jedoch als eingeschaltet konfiguriert, was bedeutet, dass dieser Hub-Edge Teil eines Clusters war (und eine Clusterkonfiguration gilt für alle Segmente). Wenn eine Konfigurationsänderung an den Hub-Edge übertragen wird, beginnt die Datenebene des Hub-Edge mit der Analyse der Daten, ausgehend vom globalen Segment. Dort wird angezeigt, dass Cloud-VPN nicht aktiviert ist, und der Hub-Edge nimmt fälschlicherweise an, dass Clustering in diesem globalen Segment deaktiviert wurde. Infolgedessen baut der Hub-Edge alle Tunnel von den WAN-Links des Hubs ab, was zu Link-Flaps auf allen WAN-Links des Hubs führt. Bei einem solchen Vorfall werden die WAN-Links nur ein einziges Mal pro Aktualisierung des Steuerungsbereichs unterbrochen und wiederhergestellt.

    In einem Unternehmen, in dem die Edges keine Version mit einem Fix für dieses Problem verwenden, besteht die Problemumgehung darin, Cloud-VPN auf allen Segmenten zu aktivieren, d. h. auf dem globalen Segment und allen nicht-globalen Segmenten.

  • Behobenes Problem 64526: Wenn ein Benutzer die GE2-Schnittstelle auf einem VMware SD-WAN Edge von geswitcht in geroutet ändert und dann eine Teilschnittstelle auf dieser Schnittstelle konfiguriert und die Änderungen speichert, gibt der Orchestrator einen Fehler aus.

    Dieser Fehler wird nur ausgelöst, wenn die Edge-Schnittstellenkonfiguration auf Profilebene (und nicht auf Edge-Ebene) geändert wird. Die Fehlermeldung, die dem Benutzer angezeigt wird, lautet „Unbekannter Adresstyp DHCP_STATELESS für Teilschnittstelle GE2 - ignoriert“ (Unknown addressing type DHCP_STATELESS for subinterface GE2 - ignored) und wird auf der Ereignisseite des Orchestrators für diesen Kunden angezeigt.

  • Behobenes Problem 65530: Ein Kunde, der Metanoia SFPs auf einem VMware SD-WAN Edge bereitstellt, kann Probleme mit dem Modul beobachten.

    Die Probleme können dadurch entstehen, dass keine neuere Firmwareversion verwendet wird, die mit Version 5.1.0 aktualisiert wurde. Die Änderungen an der CSP-Version und der SFP UPG-Firmwareversion sind in der folgenden Tabelle aufgeführt:

    Edge-Version

    CSP-Version

    SFP-UPG-Firmwareversion

    5.1.0

    3.2.9.13

    1_62_8559

    4.0.0 - 5.0.x

    3.2.8.11

    1_62_8431

    Diese Updates sorgen für eine größere Stabilität der Metanoia SFPs auf dem Edge.

  • Behobenes Problem 65919: Bei einem Kunden, der einen Zscaler Cloud Security Service (CSS) konfiguriert hat, kann der Zscaler-Tunnel fehlschlagen, wenn der Edge-Dienst neu gestartet oder DNS gelöscht wird.

    Auch wenn DNS-Abfragen erfolgreich sind, zeigt DNS den Zscaler-FQDN nicht an, sodass der Tunnel nicht aufgebaut werden kann. Bei der Überprüfung der Edge-Protokolle für DNS werden keine Zscaler-Einträge im DNS-Cache gefunden.

    Um das Problem zu beheben, muss ein Benutzer einen nslookup- oder Ping-Befehl ausführen, woraufhin der DNS-Eintrag erstellt und der Zscaler-Tunnel aktiviert wird. 

  • Behobenes Problem 67900: Wenn ein WAN-Link auf dem VMware SASE Orchestrator als „Automatisch erkannt“ konfiguriert ist, kann der Orchestrator ihn als privaten Link markieren, obwohl er als öffentlicher Link festgelegt sein sollte.

    Der Orchestrator fordert, dass der Link als privat festgelegt wird, obwohl der Kunde die Konfiguration für diesen Link als öffentlich festgelegt hat. Dies kann zu erheblichen Vebindungsproblemen bei einem Gateway führen, da der Link versuchsweise eine Verbindung zu einer privaten IP herstellt und dieser Vorgang fehlschlägt.

  • Behobenes Problem 68335: Für ein Kundenunternehmen, das eine Hub/Spoke-Topologie verwendet, bei der es sich bei den Hubs um Cluster handelt, können VMware SD-WAN Spoke Edges, die keine Verbindung mit einem Hub-Cluster herstellen können, möglicherweise eine hohe Bandbreite verbrauchen, die als SD-WAN-Steuerungsdatenverkehr klassifiziert ist.

    Wenn ein Spoke Edge keine Overlays mit seinen Datencenter-Hub-Clustern herstellen kann, fordert der Edge Controller auf, ein anderes Clustermitglied neu zuzuweisen, was dazu führt, dass Controller kontinuierliche Steuerungsereignisse senden und Verbindungsbandbreite verbrauchen.

    Auf einem Edge ohne den Fix besteht die Problemumgehung darin, ein temporäres Profil zu erstellen und zuzuweisen, ohne den unerreichbaren Hub-Cluster in seinem Profil zuzuweisen.

  • Behobenes Problem 70248: Wenn eine CRL auf der Edge-Seite ausgegeben wird, fällt der Tunnel aus und wird wiederhergestellt.

    Wenn der Orchestrator ein Zertifikat widerruft, z. B. ein Gateway-Zertifikat, bricht der Edge den Tunnel ab, stellt ihn aber wieder her.

    Das Problem hängt mit der CRL-Gültigkeitsdauer zusammen. Wenn die Aktualisierungszeit der CRL vor der Edge-Zeit liegt, wird der Tunnel wiederhergestellt.

    Solange es keinen Fix gibt, besteht die einzige Problemumgehung darin, sicherzustellen, dass Edge und Orchestrator in Bezug auf Datum und Uhrzeit übereinstimmen.

  • Behobenes Problem 70311: Bei einem VMware SD-WAN Edge kann es zu einem Ausfall des Datenebene-Diensts und infolgedessen zu einem Neustart kommen.

    Während des Neustarts des Edge-Diensts wird der Kundendatenverkehr für ca. 15 bis 30 Sekunden unterbrochen. Dieses Problem tritt unregelmäßig auf, aber wenn es auftritt, bricht der Edge eine IKE-Sicherheitsverbindung (security association, SA) ab. Dies geschieht in der Regel nur, wenn: der SA-Timer (wie auf dem VMware SD-WAN Orchestrator konfiguriert) abläuft oder der Benutzer die IPSec-Konfiguration im Orchestrator ändert.

  • Behobenes Problem 71302: Bei einem Kundenunternehmen, das ein Nicht-SD-WAN-Ziel über Edge verwendet, wird Port 500 anstelle von Port 4500 verwendet.

    Dies entspricht nicht dem erwarteten Verhalten und kann zu Problemen mit dem Datenverkehr führen, der dieses NSD über Edge nutzt, wenn ein anderes Gerät den Port 500 blockiert.

  • Behobenes Problem 71719: PPTP-Verbindung wird entlang des Pfads vom Edge zur Cloud nicht hergestellt.

    Die Verbindung zum PPTP-Server hinter dem VMware SD-WAN Edge wird nicht hergestellt.

  • Behobenes Problem 75553: Ein Kunde, der ein Nicht-SD-WAN-Ziel (NSD) über Gateway bereitstellt, das einen richtlinienbasierten Typ verwendet, kann keine redundanten VMware SD-WAN Gateways konfigurieren.

    In früheren Builds markierte VMware eine richtlinienbasierte NSD-Route unabhängig vom Status immer als „erreichbar“, was zur Folge hatte, dass die primäre Gateway-Route des NSD nie als unerreichbar markiert wurde und ein Failover auf ein redundantes Gateway auslöste.

    In Version 5.1.0 und höher wird der Gateway-Pfad als erreichbar markiert, es sei denn, die IKE/IPsec-Aushandlung schlägt fehl. In diesem Fall wird er als „unerreichbar“ markiert, und der NSD-Datenverkehr wird wie bei einem routenbasierten NSD über den redundanten Gateway geleitet.

  • Behobenes Problem 75668: Das DSCP-Tag wird für LAN-seitigen Datenverkehr zurückgesetzt, wenn es an ein internes LAN-Ziel weitergeleitet wird.

    Für den gerouteten/direkten Benutzerdatenverkehr setzt der Edge das DSCP-Tag auf 0 zurück, und bei Datenverkehr, der auf demselben Edge ein- und ausgeht (d. h. lokal auf dem Edge bleibt), wird das DSCP-Tag in eine CSP=0DSCP-Markierung geändert und auf CS0 für Underlay-Datenverkehr zurückgesetzt, wenn er den Edge durchläuft.

  • Behobenes Problem 76881: Bei einem VMware SD-WAN Edge kann es zu einer kritischen Speicherauslastung kommen, wenn mehr als 10.000 DHCPv6-Leases verwendet werden, was einen Neustart des Edge-Diensts auslösen kann.

    Wenn eine große Anzahl von DHCPv6-Clients mit dem DHCPv6-Server verbunden ist, würde jeder Client einen Lease erhalten und der Speicher des DHCPv6-Servers würde weiter wachsen. Der Edge begrenzt die Anzahl der zuweisbaren DHCPv6-Leases nicht, verglichen mit dem festen Grenzwert von 5.000 IPv4-Adressen. Daher besteht die Möglichkeit, dass der Edge so viele Leases zuweist, dass ein kritisches Niveau des Edge-Speicherstatus erreicht und ein Dienstneustart ausgelöst wird.

    Der Fix für das Problem beschränkt die maximale Anzahl von Clients auf 10.000.

  • Behobenes Problem 77066: Bei einem VMware SD-WAN Gateway kann es zu einem Ausfall des Datenebenendiensts kommen, der einen Core-Speicherauszug und einen Neustart des Diensts zur Wiederherstellung auslöst.

    Das Problem wird durch eine Beschädigung des Speichers des Gateways ausgelöst, die dadurch entsteht, dass zwei Gateway-Prozesse, die jeweils gleichzeitig Sende- und Empfangspakete verarbeiten, versuchen, auf denselben Knoten in einer Suchstruktur zuzugreifen.

  • Behobenes Problem 77457: Wenn ein Benutzer versucht, eine Paketerfassung (Packet Capture, PCAP) für eine Schnittstelle auf einem Standby-VMware SD-WAN Edge zu erstellen, meldet der VMware SASE Orchestrator, dass die PCAP fehlgeschlagen ist.

    Wenn ein Benutzer versucht, ein PCAP für den Standby-Edge in einer Bereitstellung mit erweiterter Hochverfügbarkeit zu generieren, zeichnet die Orchestrator-Benutzeroberfläche den Anforderungsstatus (Request Status) als Fehlgeschlagen (Failed) auf und gibt die folgende Fehlermeldung zurück: „Diagnosepaket konnte nicht hochgeladen werden: 'unicode' verfügt nicht über die Pufferschnittstelle“ (Failed to upload diagnostic bundle: 'unicode' does not have the buffer interface).


  • Behobenes Problem 77611: Wenn auf einer Kundensite, die eine Hochverfügbarkeitstopologie verwendet, der HA-Edge auf ein anderes Konfigurationsprofil migriert wird, können beide Edges in einen Zustand „Aktiv-Aktiv“ (Split Brain) übergehen und gleichzeitig zur Wiederherstellung neu gestartet werden.

    Während dieses Aktiv-Aktiv-Zustands würden die Client-Benutzer aufgrund von Paketverlusten erhebliche Probleme mit der Verkehrsqualität feststellen.

    Dies liegt daran, dass HA-Edges bei der Umstellung auf ein neues Profil nicht dem Prozess folgen, bei dem der Standby-Edge zunächst neu gestartet werden sollte, um die Änderungen zu übernehmen und „Standby“ zu bleiben. Dann würde der aktive Edge die Konfigurationsänderungen anwenden und neu starten, und erst dann würde der Standby Edge auf „Aktiv“ heraufgestuft und der aktive auf „Standby“ herabgestuft werden. Stattdessen wird der Standby-Edge sofort nach dem Neustart auf „Aktiv“ heraufgestuft, was zu einem Aktiv-Aktiv-Zustand führt.

  • Behobenes Problem 78037: Bei einem VMware SD-WAN Edge kann es zu einem Anstieg der Arbeitsspeichernutzung kommen, gefolgt von einem Ausfall des Datenebene-Diensts, wenn ein DHCPv6-Server mit mehr als 1.000 Adressen konfiguriert ist.

    Das Problem tritt sowohl bei Routing- als auch bei geswitchten Schnittstellen auf. Das Problem kann auftreten, wenn mehr als 1.000 Adressen für Clients auf einem DHCPv6-Server konfiguriert sind. Wenn mehr als 1.000 Clients Adressen erhalten, führt die Menge der erzeugten DHCPv6-Anforderungspakete zur Auslastung des Edge-Arbeitsspeichers und zum Ausfall des Edge-Diensts.

  • Behobenes Problem 78050: Auf einem VMware SD-WAN Edge kann es zu einem Ausfall des Datenebenendiensts kommen, wenn ein PPTP-Server auf der LAN-Seite vorhanden ist.

    Wenn ein PPTP-Server im LAN vorhanden ist und ein PPTP-Client aus dem Internet über eine eingehende Firewall-Regel eine Verbindung zu ihm herstellt, kann der Edge-Dienst aufgrund eines Fehlers bei der Suche nach dem PPTP-Steuerungskanal fehlschlagen. Diese Suche nach dem Steuerungskanal ist erforderlich, um sicherzustellen, dass der GRE-Datenkanal über denselben Link zurück an einen PPTP-Client gesendet wird.

    Auf einem Edge mit einem Build ohne Behebung dieses Problems besteht die einzige Alternative des Kunden darin, keine PPTP-Sitzungen zu verwenden.

  • Behobenes Problem 78435: Ein VMware SD-WAN Edge, der mit einer URL über die lokale Benutzeroberfläche aktiviert wird, kann einen Fehler ausgeben, dass die Edge-Aktivierung fehlgeschlagen ist, obwohl sie eigentlich erfolgreich war.

    Die URL-Aktivierung von Edge über die lokale Benutzeroberfläche löst die folgende Fehlermeldung aus: „Edge-Aktivierung konnte nicht abgeschlossen werden“ (edge activation could not be completed).


    Dies liegt daran, dass Edge bei der Beantwortung der Aktivierungsstatusanforderung auf eine ältere Aktivierungsanforderung mit falschen Parametern verweist. In der Zwischenzeit wird die aktuelle Aktivierungsanforderung mit den richtigen Parametern verarbeitet. Infolgedessen gibt die lokale Benutzeroberfläche einen Fehler aus, obwohl die Edge-Aktivierung korrekt verarbeitet wurde.

  • Behobenes Problem 79437: Ein VMware SD-WAN Gateway, das auf einem Server mit einer Intel X710-Netzwerkkarte mit aktiviertem SR-IOV für Schnittstellen bereitgestellt wird, kann möglicherweise nicht bereitgestellt werden.

    Wenn dieser Fehler auftritt, sieht der Operator, dass die X710 SR-IOV-Schnittstellen aus DPDK entfernt wurden und bei der Ausführung von debug.py --dpdk_ports_d nicht angezeigt werden. Darüber hinaus zeigt /opt/vc/etc/dpdk.json die SR-IOV-Schnittstellen nicht an. Durch die Bereitstellung eines Gateways mit der Version 5.1.0 wird sichergestellt, dass dieses Problem nicht mehr auftritt.

  • Behobenes Problem 79338: Wenn eine große Anzahl von DHCPv6-Clients versucht, eine neue IPv6-Adresse abzurufen, können einige Clients möglicherweise keine Adresse erhalten.

    Wenn mehr als 1024 Clients gleichzeitig versuchen, eine IPv6-Adresse abzurufen, erhalten einige der Clients möglicherweise keine gültige IPv6-Adresse. Dies liegt daran, dass der Nachbar-Cache vorgegeben ist und die Nachbareinträge einiger Clients nicht erstellt werden. Da die Nachbareinträge nicht vorhanden sind, schlagen die Erneuerungsmeldungen fehl.

    Clients, die keinen Build mit dem Fix verwenden, können nach ein paar Minuten erneut versuchen, IPv6-Adressen von den Clients zu erhalten.

  • Behobenes Problem 79550: Bei einem VMware SD-WAN Gateway oder SD-WAN Edge kann es zu einem Ausfall des Datenebene-Diensts und einem Neustart kommen.

    Dieses Problem kann auftreten, wenn ein wiederholtes Fragment des Verwaltungsdatenverkehrs (Management Traffic, VCMP) empfangen wird, was dazu führt, dass der Prozess über den zugewiesenen Puffer für dieses Paket hinaus schreibt und den Fehler auslöst.

  • Behobenes Problem 81881: Eine auf dem VMware SASE Orchestrator vorgenommene Änderung der Konfiguration unter „Konfigurieren > Gerät (Configure > Device)“ wird möglicherweise nicht auf den gewünschten VMware SD-WAN Edge angewendet, obwohl der Edge mit dem Orchestrator verbunden ist.

    Dieses Problem kann bei Edge unter hoher Last auftreten, wenn häufige, schnelle Konfigurationsänderungen vorgenommen werden. In diesem Szenario bleibt der für die Konfigurationsanwendung zuständige Verwaltungs-Thread des Edge hängen und wendet keine weiteren Änderungen an.

  • Behobenes Problem 81353: Bei einem VMware SD-WAN Gateway, das über eine Azure-Plattform bereitgestellt wird, kann beobachtet werden, dass Pakete an Rx-Schnittstellen verworfen werden.

    Die Pakete werden aufgrund eines geringen Puffers verworfen. Die Ringpuffer-Einstellung war nicht Teil der von Azure-Plattformen verwendeten nicht-DPDK-verwalteten Schnittstellen und die NIC-Rx-Ringpuffer-Warteschlangen sind als niedrige Zahlen festgelegt.

  • Behobenes Problem 81355: Bei VMware SD-WAN Gateways, die über die Azure-Plattform bereitgestellt werden, können Probleme mit Paketen auftreten, die größer als 1500 Byte sind.

    Die Pakete mit mehr als 1500 Bytes werden mit einer Fehlermeldung verworfen: pkt_too_big_drop. Pakete mit viel mehr als 1500 Byte werden mit folgender Fehlermeldung verworfen: sock_too_big_dropp.

    Das Problem ist darauf zurückzuführen, dass die Azure-Plattform keine DPDK-gebundenen Schnittstellen verwendet, wodurch die DPDK.json-Liste des Gateways leer bleibt und die DPDK-Netzwerkkonfigurationen die TSO/GSO-Einstellungen der Linux-Schnittstelle nicht initialisieren.

  • Behobenes Problem 81377: Wenn die Secure Access-Subnetze aktualisiert werden, werden die alten Subnetze nicht aus BGP entfernt.

    Wenn eine Secure Access-Subnetzkonfiguration geändert wird, löscht SD-WAN nur die alten Subnetze aus der Forwarding Information Base (FIB) und anderen lokalen Routentabellen. Das Problem besteht darin, dass SD-WAN die Route nicht aus der BGP-Tabelle entfernt, die für die Weiterverteilung verwendet wird, was dazu führt, dass diese veralteten Routen in BGP verbleiben.

  • Behobenes Problem 81483: Wenn ein Kunde mit einer Hub-Spoke-Topologie die IKE- und/oder IPsec-Lebensdauer über VMware SASE Orchestrator erhöht, stellt er möglicherweise fest, dass einige Tunnel die alte Lebensdauer beibehalten. Aus diesem Grund führen einige Tunnel häufiger als erwartet Rekeys durch, da sie die vorherigen Lebensdauern beibehalten haben.

    Wenn der Kunde die Lebensdauer verringert, ist er technisch gesehen von diesem Fehler betroffen (ein Ende der Hub-Spoke-Technologie kann die ältere, längere Lebensdauer beibehalten), aber er wird keinen Unterschied in der Funktionalität bemerken, da der Edge, der die niedrigere Lebensdauer korrekt erhalten hat, die Rekeys zuerst ausführt und das Problem damit verdeckt.

    Die einzige Möglichkeit, dieses Problem zu umgehen, besteht darin, die Lebensdauerwerte zu ändern, bis alle Tunnel den korrekten Zustand aufweisen, und dann den Edge neu zu starten.

  • Behobenes Problem 82104: In seltenen Fällen können VMware SD-WAN Edges, die in einer Hochverfügbarkeitstopologie aktiviert sind, nicht mit einem VMware SASE Orchestrator kommunizieren, der die Site als inaktiv markiert und jeglichen Eingriff durch den Orchestrator auf die Site ausschließt.

    Das Problem tritt nur auf, wenn eine ungewöhnliche und ungültige Konfiguration auf die HA-Edges angewendet wird. Die Konfiguration gibt an, dass der HA-Port als „Trunk“ (was nicht zulässig sein sollte) mit null VLANs (auch nicht zulässig) konfiguriert ist, wobei aber „alle VLANs“ festgelegt sind. Anstatt bei dieser Konfiguration einen Fehler auszulösen und den Benutzer daran zu hindern, HA für die Edges zu aktivieren, lässt der Orchestrator dies zu. Diese erlaubte Konfiguration löst einen Ausfall der Verwaltungsebene auf den HA-Edges aus, die kein Taktsignal mehr an den Orchestrator senden. Dieser Fix hier ermöglicht, dass diese ungültige Konfiguration auf einem HA-Edge-Paar funktioniert, ohne den Verwaltungsdatenverkehr zum Orchestrator zu unterbrechen.

  • Behobenes Problem 82188: Bei VMware SD-WAN LTE-Modellen (Edge 510-LTE, 610-LTE) können die Tunnel über die CELL-Schnittstelle fehlschlagen, wenn die IPv6-Einstellung deaktiviert ist.

    Wenn das IPv6-Kontrollkästchen in „Geräteeinstellungen (Device Settings)“ deaktiviert ist, wechselt der interne Status der CELL-Schnittstelle zu UNBEKANNT (UNKNOWN). Dieser wird auch dann nicht aktualisiert, wenn die IPv6-Einstellung für die CELL-Schnittstelle auf „Ein (On)“ umgeschaltet wird. Aus diesem Grund schlagen die Tunnel über die CELL-Schnittstelle fehl. Wenn der LTE-Edge nur CELL-Schnittstellen für den Datenverkehr verwendet, führt dies dazu, dass der Edge offline geht und der gesamte Edge-Datenverkehr verworfen wird, was für den Kunden sehr störend wäre.

    Ohne den Fix müsste ein Benutzer den Edge-Dienst neu starten, nachdem die IPv6-Einstellung deaktiviert wurde. Wenn der Edge offline ist, weil er nur die CELL-Schnittstelle für die Bandbreite verwendet, müsste ein lokaler Benutzer einen Warmstart des Edge durchführen, um ihn wiederherzustellen.

  • Behobenes Problem 83040: Ein Kundenunternehmen mit einer Hub/Spoke-Topologie, die sowohl Partner-Gateways als auch Nicht-SD-WAN-Ziele (NSD) verwendet, kann beobachten, dass Datenverkehr, der ein NSD verwenden sollte, stattdessen einen Hub verwendet.

    Der Spoke Edge verfügt über eine Business Policy, die für den Datenverkehr zum NSD einen Backhaul durchführt. Wenn auch eine Partner-Gateway-Übergabe dafür konfiguriert ist, sendet der Spoke Datenverkehr, der stattdessen einen NSD verwenden sollte, an den Hub Edge. Der Hub sendet seinerseits den Datenverkehr direkt an das Internet. Wenn die Partner-Gateway-Übergabe deaktiviert ist, wird dieser NSD-Datenverkehr ordnungsgemäß weitergeleitet.

  • Behobenes Problem 83227: Bei einem VMware SD-WAN Edge mit Version 5.0.0, der mit 128 Segmenten konfiguriert ist, wird der dnsmasq-Prozess des Edge angehalten und beendet.

    Wenn IPv6 auf 128 Segmenten aktiviert ist und DCPv6-Server im LAN jedes Segments konfiguriert sind, wird der dnsmasq-Prozess angehalten, wenn die Gesamtzahl der geöffneten Dateideskriptoren überschritten wird. Der dnsmasq-Prozess wird ca. 30 Minuten lang fortgesetzt, bevor er beendet wird. Zu diesem Zeitpunkt schlägt die DHCP-Zuweisung von IP-Adressen durch den Edge fehl.

    Durch den Neustart des Edge wird der dnsmasq-Prozess ca. 30 Minuten lang wiederhergestellt, aber er schlägt erneut fehl. Die einzige echte Problemumgehung besteht darin, die Anzahl der Segmente auf weniger als 128 zu reduzieren.

  • Behobenes Problem 83821: Bei Kunden, die NetFlow verwenden, werden die Tx- und Rx-Pakete/Bytes für den SD-WAN-Steuerungsdatenverkehr in den NetFlow-Datensätzen nicht richtig aktualisiert.

    Die SDWAN-Steuerungsdaten (Tx/Rx-Pakete/Bytes), die an einen NetFlow-Collector exportiert werden, sind immer Null. Da die Einträge in den chat_stats des Flow-Containers nicht aufgefüllt werden, exportiert der NetFlow die Daten auch nicht.

  • Behobenes Problem 84000: Bei einem VMware SD-WAN-Gateway, das mit Edge-Geräten verbunden ist, die in einer Dual-Stack-Konfiguration (IPv4/IPv6) bereitgestellt werden und bei denen es häufig zu Tunnel-Teardowns und -Erstellungen an den Edges kommt, kann ein Speicherleck auftreten, das, wenn es groß genug ist, einen Dienstneustart auslöst.

    Wenn ein VCMP-Tunnel (Encrypted Management) für einen Edge mit einer Dual-Stack-Konfiguration mehrfach erstellt und gelöscht wird, kann es im Gateway für diesen Edge zu einem Pi-Leck kommen, wenn der Gateway in großem Umfang betrieben wird. Es gibt kein wirkliches Pi-Leck, aber die Pi-Löschung erfolgt langsam, und diese langsame Löschrate kann zu Problemen mit dem gemeinsamen Arbeitsspeicher führen, die letztendlich kritisch werden können.

    Bei einem Gateway ohne Fix wird der Arbeitsspeicher durch einen Neustart des Diensts vorübergehend gelöscht.

  • Behobenes Problem 84136: Kunden beobachten möglicherweise eine hohe CPU-Auslastung und eine schlechte Datenverkehrsleistung auf einem VMware SD-WAN Edge, der auf einige Edge-Versionen aktualisiert wurde.

    Dieses Problem tritt auf einem Edge auf, bei dem mehr als 400 IP-Regeln unter dem Abschnitt Konfigurieren (Configure) > Firewall > Edge-Zugriff (Edge Access) konfiguriert sind (für Support- oder SNMP-Zugriff zulässige IP-Adressen). Wenn der Edge in diesem Szenario versucht, die Firewall-Konfiguration zu senden, lastet der Verwaltungsprozess die CPU voll aus und führt zu einer Zeitüberschreitung, woraufhin dieser Prozess wiederholt wird.

    An Kundensites, die auch eine Hochverfügbarkeitstopologie verwenden, würden die Symptome „Unbekannte HA-Ereignisse (HA unknown events)“ umfassen, da der aktive Edge keine Taktsignale innerhalb des erwarteten Zeitfensters sendet.

  • Behobenes Problem 84225: Wenn eine verbundene VMware SD-WAN Edge-Schnittstelle ausfällt, wird das konfigurierte Subnetz weiterhin auf OSPF oder BGP umverteilt.

    Der Edge zieht den Datenverkehr vom Peer für das Subnetz an, wenn es ausgefallen ist, und kann Datenverkehrsausfälle verursachen, da der Peer diesen Pfad gegenüber anderen Alternativen zum Subnetz bevorzugt.

    Bei einem Edge ohne Fix für dieses Problem muss der Benutzer den Edge in einem geplanten Dienstfenster neu starten, um das Problem zu beheben.

  • Behobenes Problem 84313: Bei einem Kundenunternehmen mit einer Hub/Spoke-Topologie kann ein IPv6-Overlay-Link für die Underlay-Peers von VMware SD-WAN Spoke Edges annonciert werden.

    Wenn Sie eine IPv6-Adresse auf dem Overlay konfigurieren und die Annoncierung aktivieren, wird dieselbe Adresse auch über das Underlay annonciert.

  • Behobenes Problem 84741: Ein Benutzer beobachtet ungenaue Durchsatzstatistiken auf den „Überwachen (Monitor) > Transport“-Bildschirmen.

    RX-Pakete (eingehende Pakete) und Verbindungsstatistiken werden nicht an den Orchestrator für den Datenverkehr erhöht, der direkt an eine Schnittstelle gesendet wird, bei der die umgekehrte Pfadweiterleitung (Reverse Path Forwarding, RPF) auf dem WAN-Overlay deaktiviert ist.

  • Behobenes Problem 84790: Wenn ein VMware SD-WAN Edge mit einem anderen Modelltyp als 510/510-LTE neu gestartet wird, meldet der Edge möglicherweise fälschlicherweise das kritische Ereignis „Der Dienst kann nicht gestartet werden, da das WLAN hängen bleibt (Unable to launch service wifihang)“ an den VMware SASE Orchestrator.

    Die Ereignismeldung wifihang ist nur für die Edge-Modelle 510/510-LTE vorgesehen und warnt den Kunden vor einem Problem mit dem WLAN-Prozess des jeweiligen Edge-Modells. Wenn diese Ereignismeldung bei einem anderen Edge-Modell beobachtet wird, unabhängig davon, ob dieses Modell WLAN verwendet oder nicht (z. B. Edge 3400), handelt es sich um eine falsche Ereignismeldung, die bedenkenlos ignoriert werden kann.

  • Behobenes Problem 85154: Wenn ein VMware SD-WAN Virtual Edge auf AWS mit dem Instanztyp C4.xlarge von einer älteren Edge-Version auf eine neuere Version (einschließlich Version 4.3.1) aktualisiert und dann wieder auf eine ältere Edge-Version zurückgesetzt wird, geht der Edge in einen deaktivierten Zustand über, d. h., der Edge bildet keine Verwaltungstunnel mit dem Gateway und Orchestrator.

    Die Ursache des Problems liegt darin, dass der Orchestrator den Edge fälschlicherweise deaktiviert, weil er eine nicht übereinstimmende Seriennummer feststellt.

    Für dieses Problem gibt es keine Umgehung, abgesehen von der Entscheidung, KEIN Downgrade von der neueren Edge-Version vorzunehmen, nachdem AWS Edge auf diese Version umgestellt wurde.

  • Behobenes Problem 85156: Bei einer mit einer Hochverfügbarkeitstopologie bereitgestellten Site kann der Kunde mehrere Neustarts des VMware SD-WAN Standby-Edge mit einer potenziellen Unterbrechung des Kundendatenverkehrs beobachten.

    Die Verarbeitungslogik zur Synchronisierung von HA-Steuerdaten auf dem Standby-Edge für über TCP empfangene Daten kann dazu führen, dass die Daten nur teilweise gelesen werden. Dies kann dazu führen, dass mehrere so kurze Meldungen auf dem Standby-Knoten verarbeitet werden, wodurch der Standby-Knoten verlangsamt werden kann. In Low-End-Edge-Plattformen (z. B. bei den Edge-Modellen 510, 520, 610, 620) kann sich diese Verlangsamung erheblich auf die Taktsignalverarbeitung zwischen dem aktiven und dem Standby-Edge auswirken, was dazu führt, dass der Standby-Edge fälschlicherweise auf „Aktiv“ (Active) heraufgestuft wird. In einem Aktiv/Aktiv-Zustand wechselt der Tie-Break zum aktiven Edge und der Standby-Edge wird neu gestartet, um ihn wieder in den richtigen Standby-Status zu versetzen.

    Wenn dieses Problem bei einer konventionellen HA-Topologie auftritt, sind die Auswirkungen auf den Kunden minimal, da der Standby-Edge den Kundendatenverkehr nicht weiterleitet. In einem Bereitstellungsmodell mit erweiterter HA, bei dem der Standby-Edge auch Datenverkehr weiterleitet, würde(n) der/die Neustart(s) einen Teil des Kundendatenverkehrs unterbrechen. 

    Der Fix für dieses Problem fügt Verbesserungen in der Edge-TCP-Meldungsverarbeitungslogik hinzu, um die Leistung auf dem Standby-Edge zu verbessern und eine Systemverlangsamung zu verhindern.

  • Behobenes Problem 85269: Bei Kundenunternehmen mit einer Hub/Spoke-Topologie, in der Multicast konfiguriert ist, kann ein Multicast-Empfänger die Datenverkehrsquelle hinter einem Hub-Edge nicht empfangen, wenn die Quell-IP-Adresse manuell entweder am Hub-Edge oder an einem Spoke-Edge, aber nicht an beiden, festgelegt wurde.

    Pimd-Protokolle und Debugging-Befehle würden Benutzern die Bestätigung liefern, wenn das Senden eines PIM-Beitritts aufgrund einer Fehlanpassung zwischen einer PIM-Nachbar-IP-Adresse und einer IP-Adresse für den nächsten Hop fehlschlägt, wodurch verhindert wird, dass LHR den RP erreicht und sich registriert (*,G).

  • Behobenes Problem 86098: Bei einer Site mit einer erweiterten Hochverfügbarkeitstopologie, bei der ein PPPoE-WAN-Link auf dem Standby-Edge verwendet wird, kann ein Benutzer feststellen, dass die Standard-Proxy-Route nicht im aktiven Edge installiert ist und der Datenverkehr, der diesen Link verwendet, fehlschlägt.

    Wenn ein eHA-Edge-Paar aktiviert wird, wird der PPPoE-Link mit dem Standby-Edge synchronisiert und stellt eine Standardroute mit dem nächsten Hop 0.0.0.0 bereit. Dies führt dazu, dass diese Route nicht auf dem aktiven Edge installiert wird und der Datenverkehr, der diesen Link verwendet, verworfen wird.

  • Behobenes Problem 86994: In einem Kundenunternehmen, in dem dynamische Zweigstelle-zu-Zweigstelle aktiviert ist, funktioniert der Debugging-Befehl dispcnt nicht, nicht, wenn versucht wird, einen VMware SD-WAN-Edge in diesem Unternehmen zu beheben.

    Der Debugging-Befehl dispcnt gibt nicht alle Indikatorwerte zurück und schlägt mit der Meldung Domain (null) does not exist fehl. Dieser Fehler tritt auch auf, wenn die entsprechenden Protokolle in einem Edge-Diagnosepaket referenziert werden. Dies erschwert die Fehlerbehebung in einem Kundennetzwerk erheblich.

    Dieses Problem tritt in Unternehmen auf, in denen dynamisches Zweigstelle-zu-Zweigstelle aktiviert ist, und zwar aufgrund der großen Anzahl von Tunneln, die für jeden Peer auf- und abgebaut werden. Die Indikatoren zur Speicherung verschiedener Metriken der Peers werden in einem gemeinsamen Speicher abgelegt, dessen Segmente aufgrund einer Kollision mit der Zeit in einen schlechten Zustand geraten, und die Indikatoren werden nicht durch den Befehl dispcnt abgerufen.

    Dieses Problem kann nur durch einen Dienstneustart des Edge behoben werden.

  • Behobenes Problem 87205: Wenn bei einem Kunden, der einen VMware SD-WAN Edge mit einem Partner-Gateway bereitstellt, ein Edge neue Routen vom Partner-Gateway erlernt, wird der Kundendatenverkehr unter Umständen unterbrochen.

    Dieses Problem wird durch Datenverkehr verursacht, der mit der falschen Business Policy übereinstimmt. Beispiel: Der für das Partner-Gateway bestimmte DHCP-Datenverkehr könnte stattdessen mit der Internet-Backhaul-Regel abgeglichen werden, was zu einer Unterbrechung des Kundendatenverkehrs führt.

    Ohne den Fix wird das Problem behoben, indem die Flows des Edge mithilfe von „Remote-Diagnose (Remote Diagnostic) > Flows leeren (Flush Flows)“ geleert werden. Mit dieser Problembehebung wird nicht verhindert, dass in Zukunft möglicherweise neue Routen vom Edge zum Partner-Gateway erlernt werden.

  • Behobenes Problem 87552: Wenn ein VMware SD-WAN Edge für die Verwendung eines Nicht-SD-WAN-Ziels (NSD) über Edge oder einen Cloud-Security-Service (CSS) konfiguriert ist, kann es auf dem VMware SD-WAN Edge in regelmäßigen Abständen zu einem Ausfall des Datenebene-Diensts und einem Neustart kommen, wenn NSD- oder CSS-Tunnel instabil sind.

    Wenn der Edge einen Tunnel zu einem NSD oder einem CSS (IPsec oder GRE) abreißt, wird die falsche Freigabe eines zuvor gewählten Tunnels durchgeführt, was eine Ausnahme im Edge-Datenebene-Dienst und einen Neustart des Edge-Diensts auslöst, um den Dienst wiederherzustellen. Der Neustart des Edge-Diensts führt zu einer Unterbrechung des Kundendatenverkehrs von 10 bis 15 Sekunden.

    Bei einem Edge ohne Fix für dieses Problem verringert sich die Wahrscheinlichkeit des Auftretens dieses Problems, wenn ein NSD über Edge oder CSS mit einem WAN-Link verbunden ist. Mit anderen Worten, anstatt einen NSD oder CSS für mehrere WAN Links zu konfigurieren, wählen Sie nur einen WAN-Link. Dadurch geht zwar Redundanz verloren, aber die Auswirkungen dieses Problems werden gemildert.

  • Behobenes Problem 88055: Bei den VMware SD-WAN Edge-Modellen 3x00 kann ein Kunde feststellen, dass bei einem Durchsatz von 10 Gbit/s oder mehr die WAN-Pfadlatenz hängen bleibt und die Stabilität und den Durchsatz des Edge beeinträchtigt.

    In 10G-Umgebungen mit schneller Taktdrift zwischen VCMP-Endpoints können WAN-Pfad-Latenzmessungen stecken bleiben, was die Effektivität der Dynamic Mutlipath Omptization (DMPO) beeinträchtigt. Dies führt zu einer falschen Pfadauswahl und einer Verschlechterung des Durchsatzes.

  • Behobenes Problem 88152: SNMP-Anforderungen an die Teilschnittstelle eines VMware SD-WAN Edge funktionieren nicht.

    Dies ist ein Tag-1-Verhalten, und bei allen SNMP-Anforderungen an eine Teilschnittstelle des Edge tritt eine Zeitüberschreitung auf. Mit dem Fix für dieses Problem wird Unterstützung für diese SNMP-Anforderungen zur Teilschnittstelle eines Edge hinzugefügt.

  • Behobenes Problem 88317: Auf einem VMware SD-WAN Edge, der sowohl öffentliche als auch private Links verwendet und SD-WAN-Erreichbarkeit (SD-WAN Reachable) konfiguriert ist, verwendet der direkte Datenverkehr den privaten Link nicht wie erwartet, wenn ein öffentlicher Link ausfällt.

    Wenn eine Business Policy so festgelegt ist, dass sie den öffentlichen Link bevorzugt, verwendet der Datenfluss nicht der über SD-WAN erreichbare private Link, wenn der bevorzugte öffentliche Link nicht verfügbar ist. Mit dem Fix wird die Logik hinzugefügt, über SD-WAN erreichbare Links zuzulassen, wenn bei der Auswahl von direkten Links versucht wird, private Links als letztes Mittel zu ermitteln.

  • Behobenes Problem 88550: Für Kunden, die Edge Network Intelligence verwenden, kann ein VMware SD-WAN Edge nicht mit dem Edge Network Intelligence-Dienst kommunizieren, wenn ein DNS nicht explizit konfiguriert ist.

    Wenn DNS nicht explizit konfiguriert ist, verwendet der Edge Network Intelligence-Dienst standardmäßig Google DNS. Wenn DNS eine Loopback-Schnittstelle als Quellschnittstelle wählt, wird die Erreichbarkeit des Diensts aufgrund eines DNS-Suchfehlers unterbrochen.

    Für ein Kundenunternehmen, das keinen Edge-Build mit dem Fix verwendet, besteht die Problemumgehung darin, DNS explizit auf dem Orchestrator zu konfigurieren und eine echte Schnittstelle als Quellschnittstelle im Vergleich zu einer virtuellen Loopback-Schnittstelle auszuwählen.

  • Behobenes Problem 89364: Wenn ein Benutzer an einer Site, die eine Topologie mit erweiterter Hochverfügbarkeit verwendet, die Option „Remote-Diagnose (Remote Diagnostics) > Schnittstellenstatus (Interface Status)“ ausführt, wird die Verbindungsgeschwindigkeit der Standby-Edge-Schnittstelle als „0 Mbit/s/Halbduplex (0 Mbps / Half-Duplex)“ angezeigt.

    Details zur Geschwindigkeit und zur automatischen Aushandlung werden nicht vom Standby-Edge abgerufen, auf dem die Schnittstelle aktiv ist, und die Details werden nicht korrekt angezeigt.

  • Behobenes Problem 89596: Bei einem VMware SD-WAN Edge kann es zu einem Ausfall des Datenebenendiensts kommen, der einen Neustart zur Folge hat und den Kundendatenverkehr unterbricht.

    Dieses Problem kann auftreten, wenn ein Kunde NAT konfiguriert hat. Wenn ein neuer Flow mit NAT eingerichtet wird, gibt es eine sehr seltene Race-Bedingung, die eine Ausnahme im Edge-Dienst auslösen kann, die einen Fehler und einen Neustart verursacht.

    Ohne einen Fix für dieses Problem besteht die einzige Möglichkeit, das Problem zu verhindern, darin, NAT zu deaktivieren.

  • Behobenes Problem 89725: Bei VMware SD-WAN Edges mit Edge-Softwareversion vor 5.1.0 funktionieren die Remote-Diagnose-Dienstprogramme „Bandbreitentest für WAN-Link (WAN Link Bandwidth Test)“ und „Traceroute“ möglicherweise nicht.

    Die Dienstprogramme „Bandbreitentest für WAN-Link (WAN Link Bandwidth Test)“ und „Traceroute“ erfordern zusätzliche Eingaben für die Schnittstelle (für BW-Test) oder die IP-Adresse (für Traceroute). Bei diesem Problem kann der Benutzer diese Eingaben nicht konfigurieren, da die Dropdown-Menüoption nicht angezeigt wird, und daher führt der Test in beiden Instanzen zu einem Fehler.

  • Behobenes Problem 90044: Wenn ein VMware SD-WAN Gateway mit einem ICMP-Test konfiguriert ist und das Gateway neu gestartet wird, wird der ICMP-Test nicht wiederhergestellt und bleibt inaktiv.

    Der ICMP-Teststatus in debug.py --icmp wird nach einem Neustart des Gateways als INAKTIV (Down) angezeigt.

    Auf einem Gateway ohne Fix für dieses Problem besteht die Problemumgehung darin, den ICMP-Test zu deaktivieren und ihn dann erneut zu aktivieren.

  • Behobenes Problem 90098: Bei einem Kundenunternehmen, in dem Zweigstellen-zu-Zweigstellen-VPN konfiguriert ist, kann in einigen Szenarien der Aufbau eines Tunnels endlos versucht werden, obwohl er aufgrund einer Konfigurationsänderung nie zustande kommen kann.

    In diesem Szenario versucht ein Edge, einen Tunnel mit einem Peer Edge zu erstellen, der entweder offline ist oder dessen IP-Adresse geändert wurde. Der Edge erkennt nicht, dass der Peer unerreichbar ist, und versucht endlos, einen Tunnel zu dem nicht existierenden Ziel aufzubauen. Dies beeinträchtigt die Gesamtleistung und kann vom Kunden nicht gestoppt werden.

    Das Problem wird durch das Fehlen einer Ablaufzeitbegrenzung für nicht funktionierende Zweigstelle-zu-Zweigstelle-Tunnel verursacht. Darüber hinaus ist das Problem schwer zu beheben, da keine Meldung darüber generiert wird, woher der Edge die Zweigstelle-zu-Zweigstelle-Nachrichtenantwort erhält, und es gibt keinen Debugging-Befehl auf dem verbundenen Gateway, um die gültigen Zweigstelle-zu-Zweigstelle-Informationen für einen Peer anzuzeigen.

  • Behobenes Problem 90216: Traceroute zeigt möglicherweise nicht die korrekte IP-Adresse eines VMware SD-WAN Hub Edge an, wenn der Datenverkehr über „Client > Spoke Edge > Hub > Server“ verläuft.

    Wenn ein Spoke Edge über eine konfigurierte Business Policy verfügt, um seinen Datenverkehr per Backhaul zu einem Hub Edge zu leiten, dessen Transportgruppe (Transport Group) für die Verwendung von Privat verkabelt (Private Wired) und Obligatorisch (Mandatory) konfiguriert ist, antwortet der Hub Edge mit der falschen IP-Adresse (in diesem Fall die öffentliche IP-Adresse, anstelle der privaten IP-Adresse) zur Traceroute.

  • Behobenes Problem 90884: Wenn in einem Kundenunternehmen, das eine Hub-Cluster/Spoke-Topologie verwendet, ein Hub-Edge im Cluster einem oder mehreren Spoke-Edges neu zugewiesen wird, kann es bei den Benutzern an diesen Spoke-Edge-Standorten zu einem Ausfall des Datenverkehrs kommen.

    Hub-Edges in einem Cluster können als Teil einer Cluster-Neuverteilung neu zugewiesen werden, wenn ein Unternehmen seine Edge-Software aktualisiert, sodass dieses Problem nach dem Upgrade beobachtet werden kann. Wenn dieses Problem auftritt, sendet das VMware SD-WAN Gateway die neuen Spoke-Edge-Routen nicht an den Hub-Edge, da das Gateway erwartet, dass alle Hub-Edges über alle Spoke-Edge-Routen verfügen. Daher befinden sich diese Routen nicht in der Routing-Tabelle des Hub-Edge. Infolgedessen wird der Datenverkehr zwischen den Spoke-Edges und dem Hub-Edge im Cluster beeinträchtigt, da der Weiterleitungspfad unterbrochen ist.

    Wenn das Problem in einem Unternehmen auftritt, das keine Gateways mit Fix für dieses Problem verwendet, kann es vorübergehend behoben werden, indem eine erneute Initialisierung der Route (route reinit) am Hub-Edge durchgeführt wird. Das Problem kann jedoch bei einer erneuten Hub-Edge-Zuweisung erneut auftreten.

  • Behobenes Problem 91164: Bei einem Kundenunternehmen mit einer Hub/Spoke-Topologie, bei der der VMware SD-WAN Hub Edge für Hochverfügbarkeit konfiguriert ist, leitet der HA Hub Edge nach einem HA-Failover möglicherweise keinen Internet-Backhaul-Datenverkehr weiter.

    Das Problem beschränkt sich auf ein Szenario, in dem der Standby-Edge die Zielroute für Internet-Backhaul-Flows nicht festlegt, wenn der Backhaul-Flow so konfiguriert ist, dass er über eine statische Route mit einer Nicht-WAN-Overlay-Schnittstelle geleitet wird. Wenn der Standby-Edge dann bei einem HA-Failover auf die aktive Rolle heraufgestuft wird, führen diese Faktoren zu einem Ausfall des Internet-Backhaul-Datenverkehrs.

  • Behobenes Problem 91188: Ein IPv6-Ping an einen Host, der mit einem VLAN an einer geswitchten Schnittstelle verbunden ist, schlägt fehl, wenn er mit Remote-Diagnose (Remote Diagnostics) > Ping durchgeführt wird und die VLAN-Schnittstelle als Quellschnittstelle ausgewählt wird.

    Der Name der Quellschnittstelle „VLAN-x“ ist nur dem VMware SD-WAN Edge bekannt, und das Edge-Betriebssystem benötigt die Quellschnittstelle in der Form „br-networkx“, da die VLAN-Schnittstelle mit diesem Namen im Edge-Betriebssystem erstellt wird.

  • Behobenes Problem 91203: Ein Kundenunternehmen, das mit einer Hub-/Spoke-Topologie konfiguriert ist, in der der VMware SD-WAN Spoke Edge für den Backhaul-Datenverkehr über einen Hub Edge konfiguriert ist, beobachtet ein Benutzer möglicherweise eine schlechte Datenverkehrsleistung für Backhaul-Flows.

    Der Backhaul-Abschnitt auf dem Hub Edge wird durch die Routentypen „Quelle (Source)“ und „Ziel (Destination)“ bestimmt (mit anderen Worten: Quelle = Unternehmen, Ziel = Cloud). Dieser Ansatz kann zu einem inkonsistenten Verhalten führen, da er von Ereignissen abhängt, die auf Routenänderungen beruhen. Er kann zudem dazu führen, dass Pakete für Backhaul-Flows verloren gehen. Der Fix für dieses Problem besteht darin, den Backhaul-Abschnitt basierend auf dem Messaging des Spoke Edge zu bestimmen.

  • Behobenes Problem 92454: Das Remote-Diagnoseprogramm „Traceroute“ funktioniert nicht, wenn ein Domänenname, der nur in eine IPv4-Adresse aufgelöst wird, in das Feld „Ziel (Destination)“ eingegeben wird.

    Wenn ein Domänenname nur in eine IPv4-Adresse aufgelöst wird, funktioniert der Befehl Traceroute, der über Remote-Diagnose ausgeführt wird, nicht. Dies liegt daran, dass der VMware SD-WAN Edge immer versucht, den Domänennamen für den IPv6-Datensatz aufzulösen, und die IPv4-Adresse kann nicht gefunden werden.

    Auf einem Edge ohne diesen Fix besteht die Problemumgehung darin, die dem Domänennamen entsprechende IPv4-Adresse direkt im Befehl Traceroute zu verwenden. Die IPv4-Adresse kann abgerufen werden, indem der Domänenname unter Remote-Diagnose (Remote Diagnostic) > DNS-Test (DNS Test) angegeben wird.

  • Behobenes Problem 92758: Auf einer Site mit einer Hochverfügbarkeitstopologie können verschiedene Probleme bei den VMware SD-WAN HA-Edges auftreten, darunter ein falscher LED-Status oder ein HA-Ausfall.

    Der falsche LED-Status auf dem aktiven Edge wird als gelb statt grün angezeigt, obwohl der Edge in Betrieb ist und die WAN-Links funktionieren und stabil sind.

    Dieses Problem wird auf eine Beschädigung des gemeinsam genutzten Speichers auf dem Edge zurückgeführt, die sich in verschiedenen Formen manifestiert. Dies kann durch Abrufen der Indikatoren mit dem Tool getcntr für eine bestimmte Domäne wie vcedge.com bestätigt werden. Die Ausgabe des Tools zeigt „Domäne nicht vorhanden (Domain does not exist)“, und der Name des Indikators wird nicht gefunden.

    VMware SD-WAN verwendet den Systemaufruf ftok(), um die Schlüssel des gemeinsam genutzten SYSV-Speichers abzuleiten. ftok() verwendet die letzten 16 Bit des Inode zur Berechnung des Schlüssels. Dies kann zu einer Schlüsselkollision führen, wenn sich die Inode-Nummern um mindestens 64K unterscheiden. Bei Auftreten eines solchen Konflikts können die dynamischen Indikatoren des gemeinsam genutzten Tunnelspeichers die Variablen des gemeinsam genutzten globalen Speichers beschädigen, was zu verschiedenen möglichen Problemen führen kann, einschließlich eines falschen LED-Status, ungültiger Indikatoren oder eines HA-Ausfalls.

  • Behobenes Problem 93062: Wenn ein Benutzer die Remote-Diagnose „Status der Schnittstelle“ (Interface Status) auf dem VMware Orchestrator ausführt, gibt der Orchestrator entweder einen Fehler für diesen Test zurück und schließt ihn nicht ab oder der Test liefert keine Ergebnisse für geroutete Schnittstellen.

    Die angezeigte Fehlermeldung lautet „Fehler beim Lesen der Daten für den Test“ (Error reading data for test). Wenn der Test abgeschlossen ist, sind die Ergebnisse für geroutete Schnittstellen leer und enthalten keine Informationen über Geschwindigkeit oder Duplex. In jedem Fall ist der Schnittstellenstatus fehlerhaft. Das Problem hängt mit dem Debugging-Befehl zusammen, der dem Schnittstellenstatus zugrunde liegt und DPKD-aktivierte Ports auslässt.

    Bei einem Edge ohne diesen Fix müsste der Benutzer ein Diagnosepaket für den Edge erstellen, um den Status der gerouteten Schnittstelle anzuzeigen

  • Behobenes Problem 93853: Bei einem stark ausgelasteten VMware SD-WAN-Gateway kann es zu einem Ausfall des Datenebenendensts mit einem SIGXCPU-Code kommen, sodass der Dienst zur Wiederherstellung neu gestartet werden muss.

    Bei hoher Auslastung verfügen mehrere Gateway-Threads, die verschiedene Aktivitäten wie Routing und Protokollierung ausführen, nicht über CPU-Ressourcen und können die Aufgabe nicht innerhalb des festgelegten Zeitraums abschließen. Der Gateway-Dienst interpretiert diese verzögerten Threads als Deadlock und löst das SIGXCPU-Signal mit einer nachfolgenden Beendigung des Gateway-Datenebenenprozesses aus.

  • Behobenes Problem 94204: Der Benutzer stellt möglicherweise fest, dass Versuche, ein Diagnosepaket für einen VNF-fähigen VMware SD-WAN Edge zu generieren, fehlschlagen.

    Ein Diagnosepaket kann auf einem VNF-fähigen Edge nicht abgeschlossen werden, da der Edge über keinen Festplattenspeicher mehr verfügt. Dies kann passieren, wenn der Edge einen oder mehrere Kerne generiert hat und dadurch verursacht wird, dass der Edge diese Kerne an den Ordner /vnf/tmp sendet. Jeder Kern wird im Ordner /vnf/tmp entpackt und füllt diesen Ordner aufgrund der entpackten Größe eines Kerns schnell aus, was dazu führt, dass das Diagnosepaket fehlschlägt. 

    VNF-fähige Edges (Virtual Network Function) enthalten die folgenden Modelle: 520v, 620, 640, 680 und 840.

  • Behobenes Problem 94401: Auf einem VMware SD-WAN Edge, auf dem die statusbehaftete Firewall aktiviert ist, kann es vorkommen, dass ein über TCP eingerichteter Flow zu schnell abläuft und geleert wird.

    Der über TCP eingerichtete Flow wird als nicht eingerichteter TCP-Flow behandelt und unterliegt einer kürzeren Zeitüberschreitung. Wenn in einem TCP-Flow ein TCP-Reset (RST) angezeigt wird, gefolgt von einem TCP 3-Wege-Handshake, wird der Flow geleert, obwohl der TCP-Status als „Eingerichtet“ angezeigt wird, nachdem eine Zeitüberschreitung für einen nicht eingerichteten TCP-Flow aufgetreten ist.

  • Behobenes Problem 94612: Der Datenverkehr zum BGP-Netzwerkpräfix ist nicht erreichbar.

    Wenn dieses Problem auftritt, wird das BGP-Netzwerkpräfix nicht unter BGP konfiguriert und nicht für Peer-Knoten angekündigt.

    Auf einem Edge ohne eine Lösung für dieses Problem besteht die einzige Problemumgehung darin, die BGP-Netzwerke zu löschen und sie neu zu konfigurieren.

  • Behobenes Problem 94775: In einem Kundenunternehmen, das eine Hub/Spoke-Topologie verwendet, bei der der VMware SD-WAN Spoke Edge den Datenverkehr über einen Hub Edge zurückgibt, können Clientbenutzer Leistungsprobleme beim Datenverkehr beobachten.

    Dies wird dadurch verursacht, dass das falsche Flag für Backhaul-Datenverkehr festgelegt wird. Die Backhaul-Pakete werden auf dem Spoke Edge so behandelt, als ob sie sich auf einem Hub Edge befinden würden. Dies führt zu Problemen bei der Routensuche auf dem Hub, und die Backhaul-Pakete werden verworfen.

  • Behobenes Problem 94980: Bei einer Site, die mit einer Hochverfügbarkeitstopologie bereitgestellt wird, kann es beim VMware SD-WAN Standby-Edge zu einem Fehler des Datenebene-Diensts und einem Neustart kommen, nachdem ein PPPoE-WAN-Link für die HA-Edges konfiguriert wurde.

    Bei der Untersuchung des vom Standby-Edge generierten Kerns wird einem Benutzer die Meldung vc_is_use_cloud_gateway_set angezeigt, nachdem der PPPoE-Link konfiguriert wurde.

    Auf einer HA-Site ohne einen Fix für dieses Problem müsste der Kunde sicherstellen, dass ein PPPoE-Link nur in einem Wartungsfenster konfiguriert wurde, um das Risiko dieses Problems zu verwalten.

  • Behobenes Problem 95047: Wenn ein Dienstprogramm zum Prüfen von Sicherheitsports einen VMware SD-WAN Edge prüft, auf dem Edge Network Intelligence (Analyse) nicht aktiviert ist, meldet die Prüfung, dass der Syslog-Port 514 geschlossen ist, was bedeutet, dass möglicherweise darauf zugegriffen werden kann.

    Edge Network Intelligence überwacht Port 514 (Syslog). Wenn die Option Analyse (Analytics) nicht aktiviert ist, kann auf Port 514 weiterhin zugegriffen werden, er reagiert jedoch nicht auf Anforderungen. Aus diesem Grund meldet ein Portscanner den Port als „geschlossen“ (d. h., auf den Port kann zugegriffen werden, aber es wird keine Anwendung überwacht).

  • Behobenes Problem 95121: Wenn eine „gesperrte SIM-Karte“ (eine SIM-Karte, die mit einem Kennwort gesperrt ist) in einem VMware SD-WAN Edge-Modell 510-LTE oder 610-LTE verwendet wird, kommt es beim Kunden zu Problemen beim Verbindungsaufbau im Netzwerk.

    Benutzer stoßen bei der Verwendung gesperrter LTE-SIM-Karten mit den SIM-Steckplätzen der Edge 510-LTE- und 610-LTE-Modelle auf Fehler beim Pfadaufbau, da die SIM-Entsperrung im Orchestrator nicht funktioniert. Dies ist auf die fehlende Unterstützung für gesperrte SIMs in den ModemManager-Skripten des Edge zurückzuführen.

  • Behobenes Problem 95501: Für ein Kundenunternehmen, das eine Hub/Spoke-Topologie und BGP für das Routing verwendet, können Clientbenutzer auf VMware SD-WAN Spoke Edges eine schlechte Datenverkehrsleistung feststellen.

    Ein Administrator würde feststellen, dass der Spoke Edge mit Uplink-Community markierte Routen von einem Hub, der nicht in seinem Profil enthalten ist, gegenüber dem Hub Edge bevorzugt, der für diesen Spoke Edge konfiguriert ist. Dies liegt daran, dass der Spoke Edge-Datenverkehr einen dynamischen Zweigstelle-zu-Zweigstelle-Pfad für Uplink-Präfixe verwendet.

    Das Problem wird dadurch verursacht, dass SD-WAN das Uplink-Flag für die von einem Hub Edge empfangenen Routing-Nachrichten zurücksetzt. Wenn also ein dynamischer Zweigstelle-zu-Zweigstelle-Tunnel gebildet wird, werden direkte Routen für diese Uplink-Präfixe installiert, was zu suboptimalem Routing und verminderter Datenverkehrsleistung führt.

  • Behobenes Problem 95565: Auf einer Site, die eine Hochverfügbarkeitstopologie verwendet, kann auf dem VMware SD-WAN Active Edge ein Ausfall des Datenebenendiensts auftreten, wobei ein Kern generiert und ein Hochverfügbarkeits-Failover ausgelöst wird.

    Das Problem wird ausgelöst, wenn die WAN-Links des aktiven Edge ein oder mehrere Male ausfallen (inaktiv und dann schnell verfügbar) und gleichzeitig SNMP verwenden, wenn häufige SNMP-Abfragen vorhanden sind. Es gibt ein Zeitproblem, bei dem die Schnittstelle wieder aktiv wird und zusammen mit der SNMP-Abfrage einen Deadlock auslösen kann, der dazu führt, dass der Datenebenendienst fehlschlägt und einen Speicherabzug erzeugt. Dieses Problem kann zwar nur durch einen einzigen WAN-Link-Flap verursacht werden, aber je mehr WAN-Link-Flaps auftreten, desto größer ist das Potenzial für dieses Problem.

    Bei einem HA-Edge-Paar, bei dem dieses Problem auftritt und das nicht über den Fix verfügt, besteht die Problemumgehung darin, SNMP zu deaktivieren. Da es sich um ein Zeitproblem handelt, wird dadurch das Risiko gemindert, aber nicht ausgeschlossen.

  • Behobenes Problem 96626: Wenn einer VMware SD-WAN Edge-Schnittstelle eine sekundäre IP-Adresse zugewiesen ist, schlagen Verbindungen über die sekundäre IP-Adresse fehl.

    Jede Anfrage, die von einer anderen Zweigstelle an eine IP im sekundären Netz gerichtet wird, erzeugt ein ARP von der primären IP-Adresse und nicht von der sekundären IP-Adresse. Dies führt dazu, dass das ARP unaufgelöst bleibt, was zu einem Fehler beim Datenverkehr führt, der über die sekundäre IP-Adresse läuft.

  • Behobenes Problem 96739: Wenn ein Benutzer auf der Registerkarte „Überwachen (Monitor) > Anwendung (Application)“ nach einem VMware SD-WAN Edge auf einem VMware SASE Orchestrator sucht, werden auf dem Bildschirm möglicherweise Ziel-FQDNs mit den falschen Domänennamen angezeigt.

    Dieses Problem kann auftreten, wenn die Edge-Statistiken ihren Grenzwert erreichen (als Überlaufbedingung bezeichnet). Anstatt diese Statistiken als Überlauf anzuzeigen, zeigt der Orchestrator zufällige Domänennamen auf dem Ziel-FQDN der Registerkarte „Anwendung (Application)“ an.

  • Behobenes Problem 96994: Wenn Sie einen SNMP-Schritt auf einem VMware SD-WAN Edge durchführen, sind einige der Schnittstellen möglicherweise nicht sichtbar.

    Fehlende Schnittstellen können gültige Schnittstellen sein, die auf snmpwalk sichtbar sein sollten. Da jedoch eine ungültige Schnittstelle in der Hardwareliste des Edge enthalten ist, werden die gültigen Schnittstellen, die in der Liste nach der ungültigen Schnittstelle angezeigt werden, von snmpwalk nicht angezeigt oder zurückgegeben. Eine Schnittstelle hier ist ungültig, wenn sie in der Hardwareliste angezeigt wird, aber nicht angezeigt wird, wenn der Befehl ifconfig auf dem Edge ausgeführt wird.

    Obwohl dieses Problem potenziell jeden Edge betreffen kann, ist die Wahrscheinlichkeit größer, dass es auf einem mit Azure bereitgestellten Virtual Edge auftritt. Dies ist darauf zurückzuführen, dass der Azure Edge eine höhere Anzahl von Schnittstellen in seiner Hardwareliste auflistet als die Anzahl der Schnittstellen, die im Edge selbst mithilfe ifconfig identifiziert wurden.

  • Behobenes Problem 97152: Wenn in einem Kundenunternehmen eine Business Policy-Regel mit einer als drahtgebunden konfigurierten Dienstgruppe und dem Linkmodus „Verfügbar“ konfiguriert ist, wird der Datenverkehr nicht auf einen drahtlosen Link umgeleitet, wenn einer oder mehrere drahtgebundene Links ausfallen und die Clientbenutzer an der Site feststellen, dass ihr Datenverkehr, der dieser Regel entspricht, nicht funktioniert.

    Wenn eine Business Policy-Regel eine explizite Dienstgruppe mit drahtgebundenen WAN-Links mit dem Linkmodus „Verfügbar“ hat und an der Site drahtlose Links verfügbar sind, wird erwartet, dass der Datenverkehr, der diese Regel verwendet, auf den/die drahtgebundene(n) WAN-Link(s) umleitet, wenn die drahtgebundenen Links in der Dienstgruppe ausfallen (mit anderen Worten: nicht verfügbar sind), um den nahtlosen Fluss des Datenverkehrs, der dieser Regel entspricht, sicherzustellen. Bei diesem Problem findet keine Steuerung des Datenverkehrs zu den drahtlosen Links statt.

  • Behobenes Problem 97321: Ab dem Zeitpunkt, an dem ein Benutzer Edge Network Intelligence (Analyse) auf einem VMware SD-WAN Edge aktiviert, kann der Edge potenziell einen Neustart des Edge-Diensts auslösen, der jeweils 10-15 Sekunden Unterbrechung des Kundendatenverkehrs verursacht.

    Wenn die Analysefunktion auf dem Edge aktiviert ist, kann es vorkommen, dass der Edge nicht mehr genügend Arbeitsspeicher hat und einen „doppelt freien“ Arbeitsspeicherstatus aufweist. Der Edge startet seinen Dienst neu, um den Arbeitsspeicher wiederherzustellen.

    Die Symptome für dieses Problem können mehrere Male auftreten, während die Analyse aktiviert ist.

  • Behobenes Problem 99718: Der BGP-Nachbar wird nicht eingerichtet, wenn die sekundäre IP-Adresse auf einer SVI (Switch Virtual Interface) verwendet wird.

    Wenn der Edge Ingress-Pakete verarbeitet, überprüft er, ob die Zieladresse des Ingress-Pakets mit der IP-Adresse der Ingress-Schnittstelle übereinstimmt. Da nur primäre IP-Adressen verglichen werden, werden Pakete mit einer Ziel-IP-Adresse als sekundäre IP-Adresse verworfen. Dies führt dazu, dass die BGP-Sitzung nicht auf dieser sekundären IP-Adresse aufgebaut wird.

  • Behobenes Problem 100363: Auf einem VMware SD-WAN Gateway kann es zu einem Ausfall des Datenebenendiensts und zum Auslösen eines Neustarts des Diensts führen. Dies führt zu einer Unterbrechung des Datenverkehrs von 1 bis 5 Sekunden.

    Dieses Problem trat bei Stresstests auf, wobei der Fehler bei futex_abstimed_wait auftrat und das Ergebnis eines Threads mit Deadlock war, der den Dienstausfall und Neustart ausgelöst hat.

Behobene Probleme bei Orchestrator

Behoben in Orchestrator-Version R51010-20231215-GA

Orchestrator-Build R51010-20231215-GA wurde am 18. Dezember 2023 veröffentlicht und ist der zehnte Orchestrator-Rollup für Version 5.1.0.

Dieser Orchestrator-Rollup-Build behebt das folgende Problem seit dem neunten Orchestrator-Rollup-Build, R5109-20231003-GA.

  • Behobenes Problem 117941: Das Kontrollkästchen „VLAN annoncieren (VLAN Advertise)“ wird auf der Orchestrator-Benutzeroberfläche immer als deaktiviert angezeigt.

    Selbst wenn ein Benutzer das Kontrollkästchen VLAN annoncieren (VLAN Advertise) aktiviert und die Option Änderungen speichern (Save Changes) auswählt, wird das Kontrollkästchen VLAN annoncieren (VLAN Advertise) auf der Orchestrator-Benutzeroberfläche wieder deaktiviert.

  • Behobenes Problem 125006: Bei einem VMware SASE Orchestrator, der mit einer Notfallwiederherstellungstopologie (Disaster Recovery, DR) konfiguriert ist, kann die Datenbank des Orchestrators ausfallen, was dazu führt, dass die Standby-Instanz des Orchestrators in einen Fehlerzustand gerät. In seltenen Fällen kann dies dazu führen, dass Edges und Gateways auf der Orchestrator-Benutzeroberfläche als offline angezeigt werden und Ereignisse und Alarme auslösen.

    Es wird erwartet, dass der Datenbankstatus innerhalb weniger Minuten automatisch wiederhergestellt wird und die DR-Orchestrator-Instanzen sich erneut synchronisieren. Manchmal kann dieser Zustand jedoch den Toleranzzeitraum überschreiten, und sowohl Edges als auch Gateways beginnen, ihre Taktsignale an die Standby-Orchestrator-Instanz statt an die aktive Orchestrator-Instanz zu senden. Infolgedessen markiert die aktive Orchestrator-Instanz beide Edges und Gateways, die ihr kein Taktsignal senden, als inaktiv und löst Ereignisse und Alarme aus. Dieses Problem betrifft ausschließlich die Verwaltung und hat keine Auswirkungen auf den Netzwerkdatenverkehr.

    Bei einem Orchestrator ohne Fix kann dieses Problem vermieden werden, indem die Orchestrator-Systemeigenschaft, die die Toleranz für eine fehlgeschlagene Synchronisierung vco.disasterRecovery.transientErrorToleranceSecs regelt, um einen angemessenen Betrag erhöht wird, um ein längeres Fenster für die automatische Wiederherstellung bereitzustellen.

  • Behobenes Problem 128310: VMware SASE Orchestrator-Benutzer können eine allgemeine Verlangsamung und einige API-Fehler aufgrund von Problemen mit dem Orchestrator-Datenbankdienst feststellen. Weitere Nebeneffekte sind: SD-WAN Gateways/Edges werden in der Benutzeroberfläche offline angezeigt, über die Orchestrator-Benutzeroberfläche vorgenommene Änderungen werden nicht an die zielseitigen SD-WAN Edges übertragen und Berichtsfunktionen gehen verloren.

    Die Probleme werden alle dadurch verursacht, dass der Orchestrator-Datenbankdienst mit folgendem Fehler fehlschlägt: zu viele geöffnete Dateien (too many open files). Dieser Fehler kann von einem Operator-Benutzer auf dem VMware SASE Orchestrator über Protokolle beobachtet werden. Bei einem Unternehmens- oder Partnerbenutzer, der über die Benutzeroberfläche auf VMware SASE Orchestrator zugreift, kommt es zu Verlangsamung und zeitweiligen API-Fehlern, die zu Fehlermeldungen auf der Benutzeroberfläche führen.

  • Behobenes Problem 129239: Wenn ein Benutzer auf der Seite „Konfigurieren (Configure) > Profil (Profile)“ der Orchestrator-Benutzeroberfläche eine Einstellung auf Profilebene bearbeitet und dann versucht zu speichern, stellt er möglicherweise fest, dass beim API-Aufruf eine Zeitüberschreitung auftritt und der Vorgang nicht erfolgreich ist.

    Wenn dieses Problem auftritt, wird auf der Orchestrator-Benutzeroberfläche ein rotes Fehlerbanner auf der Browserseite mit dem Text „configuration/updateConfigurationModule time out“ angezeigt. Das Problem ist darauf zurückzuführen, dass andere Orchestrator-Datenbankabfragen zu lange dauern und der Versuch, die neuen Profileinstellungen zu speichern, zu einer Zeitüberschreitung führt.

  • Behobenes Problem 131789: Wenn Sie Single Sign-On (SSO) für eine Organisation konfigurieren, können sich die Benutzer nicht beim Orchestrator anmelden, obwohl die Rolleninformationen in der Antwort des Identitätsanbieters (IdP) enthalten sind.

    Der Orchestrator kann die Rolle eines Benutzers, der sich über Single Sign-On (SSO) anmeldet, nicht zuordnen, wenn der Identitätsanbieter Rolleninformationen in einer geschachtelten JSON-Struktur sendet. Ab Version 5.0.1.7 kann der Orchestrator auf die Rolle eines SSO-Benutzers verweisen und diese abgleichen, selbst wenn er in einer verschachtelten JSON-Struktur vorhanden ist. Wenn dieses Problem bei einem Orchestrator auftritt, für den es noch keinen Fix gibt, kann es umgangen werden, indem der Identitätsanbieter so konfiguriert wird, dass er die Rollendetails auf der direkten Ebene und nicht in der verschachtelten Struktur sendet.

Behoben in Orchestrator-Version R5109-20231003-GA

Orchestrator-Build R5109-20231003-GA wurde am 05.10.2023 veröffentlicht und ist der 9. Orchestrator-Rollup für Version 5.1.0.

Dieser Orchestrator Rollup-Build behebt das folgende wichtige Problem seit dem 8. Orchestrator Rollup-Build R5108-20230916-GA.

  • Behobenes Problem 119938: Für einen Kunden, der Automatisierung für Zscaler-Tunnel verwendet, kann es lange dauern, einen automatisierten IPsec-Tunnel von einem VMware SD-WAN Edge zu Zscaler zu erstellen.

    Wenn Kunden Zscaler-Unterspeicherorte unter Edge > Geräteeinstellungen (Device Settings) konfigurieren, kann es lange dauern, bis diese Konfigurationen mit der Zscaler-Cloud synchronisiert sind. Dies liegt daran, dass die Zscaler-Cloud ihre Datensätze für jeden Unterspeicherort aktualisieren muss, was ein zeitaufwändiger Prozess sein kann.

    Dieses Problem wird durch das Automatisierungsframework auf dem Orchestrator verursacht, das Aktionen zum Erstellen von IPsec-Tunneln und Unterspeicherorten in die Automatisierungswarteschlange stellt. Außerdem werden Aktualisierungsaktionen in die Automatisierungswarteschlange gestellt, wenn sich die Edge-WAN-IP ändert. Die Wartezeit für Elemente in der Warteschlange erhöht sich jedoch aufgrund der großen Anzahl von Aktualisierungsaktionen. In einigen Kundenumgebungen kann sich die Edge-WAN-IP an einem Tag bis zu 4000 Mal ändern (z. B. bei mobilen WAN-Links).

  • Behobenes Problem 128310: Bei VMware SASE Orchestrator-Benutzern kann es aufgrund von Problemen mit dem Orchestrator-Datenbankdienst zu einer allgemeinen Verlangsamung und einigen API-Fehlern kommen. Weitere Nebeneffekte sind: SD-WAN-Gateways/-Edges werden in der Benutzeroberfläche als offline angezeigt, Konfigurationsänderungen, die über die Orchestrator-Benutzeroberfläche vorgenommen werden, werden nicht an die SD-WAN-Edges weitergegeben, und es kommt zum Verlust von Berichtsfunktionen.

    Die Probleme werden alle dadurch verursacht, dass der Orchestrator-Datenbankdienst mit dem Fehler: zu viele offene Dateien (too many open files) fehlschlägt. Dieser Fehler kann von einem Operator-Benutzer auf dem VMware SASE Orchestrator über Protokolle beobachtet werden. Bei einem Unternehmens- oder Partnerbenutzer, der über die Benutzeroberfläche auf VMware SASE Orchestrator zugreift, kommt es zu einer Verlangsamung und zeitweiligen API-Fehlern, die Fehlermeldungen auf der Benutzeroberfläche verursachen.

Behoben in Orchestrator-Version R5108-20230916-GA

Orchestrator-Build R5108-20230916-GA wurde am 20.09.2023 veröffentlicht und ist der 8. Orchestrator-Rollup für Version 5.1.0.

Dieser Orchestrator-Rollup-Build behebt das folgende wichtige Problem seit dem 7. Orchestrator-Rollup-Build R5107-20230722-GA.

  • Behobenes Problem 94610: Wenn ein Benutzer ein erzwungenes HA-Failover über „Remote-Aktionen (Remote Actions)“ > „HA-Failover erzwingen (Force HA Failover)“ initiiert, erzeugt und sendet der VMware SASE Orchestrator unter Umständen keine Warnung für das HA-Failover.

    Da das HA-Failover vom Orchestrator erzwungen wird, erwarten sowohl der Active- als auch der Standby-Edge das Failover, was dazu führen kann, dass sowohl die HA_GOING_ACTIVE- als auch die HA_READY-Nachrichten im selben Taktsignal vom HA-Edge gesendet werden. Wenn der im Taktsignal gesendete „HA-Status“ als „Ready (Bereit)“ angezeigt wird, täuscht dies den Orchestrator dazu, keine Warnung für das Failover zu generieren, da er nur die Meldung „Ready“ (Bereit) und nicht die Meldung „Going Active (Wird aktiviert)“ sieht.

  • Behobenes Problem 104775: Wenn ein Benutzer einen zuvor aktiven WAN-Link auf einem VMware SD-WAN Edge als Sicherung konfiguriert, zeigt die VMware SASE Orchestrator-Benutzeroberfläche den Status unter „Überwachen (Monitor) > Edges > Übersicht (Overview)“ nicht korrekt an.

    Der Status sollte als „Standby-Leerlauf (Standby Idle)“ mit einem grauen Statuspunkt angezeigt werden, aber stattdessen wird weder der Linktyp noch der Sicherungsstatus angezeigt. Es handelt sich um einen kosmetischen Fehler, da der WAN-Link seine Funktion als Sicherung erfüllt.

  • Behobenes Problem 105580: Bei einem VMware SASE Orchestrator mit konfiguriertem FIPS-Modus schlägt die Einrichtung der Notfallwiederherstellung (Disaster Recovery, DR) für den Orchestrator unter Umständen fehl.

    SSL_CTX_new schlägt beim Versuch, eine Verbindung herzustellen, fehl. Das DR-Setup mit FIPS-Konfiguration umfasst einen Orchestrator-Build mit MySQL-Version 8.0.28 oder höher und schlägt während der DR COPYING_DP-Phase mit folgender Fehlermeldung fehl: SSL_CTX_new failed when trying to connect.

  • Behobenes Problem 106191: Ein Benutzer kann keine Änderungen an einer VMware SD-WAN Edge-Konfiguration vornehmen, wenn der Edge ein Profil verwendet, bei dem eine Schnittstelle mit einer statischen IP-Adresse konfiguriert ist.

    Wenn eine Edge-Konfigurationsänderung versucht wird, zeigt die VMware SASE Orchestrator-Benutzeroberfläche die Fehlermeldung: „Ungültiges Testintervall für die Schnittstelle (invalid probe interval for interface)“ an und verhindert das Speichern der Änderungen.

    Auf einer Orchestrator-Instanz ohne Fix für dieses Problem besteht die einzige Problemumgehung darin, ein neues Profil ohne statische Schnittstellenzuweisungen zu erstellen und dieses auf den Edge anzuwenden.

  • Behobenes Problem 115981: Bei einem Kundenunternehmen, das die APIv2 von VMware SASE Orchestrator verwendet, gibt der Orchestrator bei der Ausführung der API zum Abrufen von Unternehmensereignissen nur einen begrenzten Satz zurück.

    Der spezifische Aufruf lautet https://\{api_host}//api/sdwan/v2/enterprises/{enterpriseLogicalId}/events. Beim Aufruf wird nur die oberste Hierarchiestufe zurückgegeben, und es werden keine Details wie enterpriseName, EdgeName, segmentName oder edgeID angezeigt. Darüber hinaus unterstützt APIv2 keine Graphentraversierung.

    Auf einer Orchestrator-Instanz ohne Fix für dieses Problem besteht die einzige Problemumgehung in der Verwendung von APIv1, wodurch ein Kunde gezwungen ist, zwei Sätze von API-Familien zu pflegen. Darüber hinaus bietet APIv1 keine Unterstützung für Cloud Web Security.

  • Behobenes Problem 116531: Wenn ein Benutzer versucht, einen Bericht auf dem VMware SASE Orchestrator zu erstellen, bei dem mindestens eine Edge-Beschreibung ein Komma (,) enthält, wird der Bericht möglicherweise nicht ordnungsgemäß formatiert.

    Wenn eine Edge-Beschreibung ein Komma enthält (wie im Screenshot unten gezeigt), verwirrt der Orchestrator-Berichtsdienst dies und bricht den Text nach jedem Komma in die nächste Spalte des Berichts um, anstatt wie erwartet die gesamte Textzeichenfolge in der Spalte Edge-Beschreibung zu enthalten.

    Anstelle von Übertragene Bytes (Bytes Transmitted) mit den zugehörigen Werten wird also der Text nach dem ersten Komma angezeigt, bei Empfangene Byte (Bytes Received) der Text nach dem zweiten Komma (falls es eines gab) und so weiter. Der Bericht würde immer noch die Daten für „Übertragene Bytes“ und „Empfangene Byte“ enthalten. Sie werden lediglich weiter nach rechts verschoben und nicht an den richtigen Spalten ausgerichtet.

    Auf einer Orchestrator-Instanz ohne Fix für dieses Problem müsste der Benutzer sicherstellen, dass die Edge-Beschreibung keine Kommas enthält.

  • Behobenes Problem 117822: Wenn ein Kunde „Überwachen (Monitor) > Edges > Quality of Experience (QoE)“ betrachtet, kann er Lücken in den QoE-Diagrammen feststellen, die sich nicht durch Probleme mit den WAN-Links des Edge erklären lassen.

    Die Lücken sind das Ergebnis eines Problems mit der Orchestrator-Datenbank, bei dem die interne Auftragswarteschlange für Link-Daten übersehen wird und die Link-Daten nicht wieder aufgefüllt werden.

  • Behobenes Problem 118728: Auf einem Partnerportal oder in einem Kundenunternehmen können sich einige Benutzer möglicherweise nicht beim VMware SASE Orchestrator anmelden.

    Der Benutzer sieht möglicherweise die Fehlermeldung „Benutzer verfügt nicht über die Berechtigung [READ:PROXY], die für den Zugriff auf [enterpriseProxy/getEnterpriseProxy] erforderlich ist“ (user does not have privilege [READ:PROXY] required to access [enterpriseProxy/getEnterpriseProxy]), obwohl der Benutzer über die richtigen Berechtigungen für die Anmeldung verfügt. Dies gilt für die native Authentifizierung und die Zwei-Faktor-Authentifizierung. Dieser Fehler spiegelt ein abgelaufenes Kennwort wider, auch wenn der Orchestrator den Benutzer nicht darauf hinweist, dass dies der eigentliche Grund ist, warum er sich nicht anmelden kann. Da sich der Benutzer nicht anmelden kann, kann er auch sein Kennwort nicht zurücksetzen.

    Bei einer Orchestrator-Instanz ohne Fix für dieses Problem kann ein Partner- oder Kundenadministrator mit einer entsprechenden Rolle die E-Mail zum Zurücksetzen des Kennworts an einen betroffenen Benutzer senden, um sein Kennwort zurückzusetzen.

  • Behobenes Problem 121085: Wenn sich ein Partneradministrator auf der Seite „Globale Einstellungen (Global Settings) > Benutzerverwaltung (User Management) > Dienstberechtigungen (Service Permissions)“ befindet, funktioniert die Option „Auf Systemstandardeinstellung zurücksetzen (Reset to System Default)“ nicht wie erwartet.

    Das erwartete Verhalten, wenn Auf Systemstandardeinstellung zurücksetzen (Reset to System Default) ausgewählt wird, ist, dass alle benutzerdefinierten Rollenberechtigungspakete in den Status Unveröffentlicht (Unpublished) zurückkehren, da die Standardeinstellungen für Benutzerrollenberechtigungen wiederhergestellt werden. Der Partnerbenutzer würde jedoch feststellen, dass ein oder mehrere benutzerdefinierte Pakete im Status Veröffentlicht (Published) verbleiben und dass die Pakete, die weiterhin Veröffentlicht (Published) sind, nicht geändert oder gelöscht werden können.

  • Behobenes Problem 121441: Wenn ein Kunde die VNF-Einfügung auf dem VLAN eines VMware SD-WAN Edge aktiviert, löscht der Edge die VNF und setzt sie anschließend neu ein, wodurch sie für diesen Edge unbrauchbar wird.

    Nachdem die VNF-Einfügung auf dem VLAN aktiviert wurde, würde der Kunde auf der Seite Überwachen (Monitor) > Ereignisse (Events) die VNF-Löschung und -Einfügung beobachten und außerdem eine E-Mail mit der Meldung (VNF_VM_DELETED) / VNF eines unbekannten Herstellers wurde am Edge <Edge Name> gelöscht (Unknown vendor VNF was deleted on the edge <Edge Name> erhalten. Das Problem wird darauf zurückgeführt, dass der Orchestrator eine neue UUID (Universally Unique IDentifier) sendet, nachdem die VNF-Einfügung in einem VLAN aktiviert wurde. Der Edge interpretiert diese UUID-Änderung als Auslöser, um die VNF zu löschen und erneut bereitzustellen, wodurch sie für diesen Edge unbrauchbar wird.

    Dieses Problem tritt nur auf der neuen Benutzeroberfläche auf. Wenn dieses Problem auf einer Orchestrator 5.1.x-Instanz ohne Fix für dieses Problem auftritt, wechseln Sie zur klassischen Benutzeroberfläche, um den VNF zu konfigurieren.

  • Behobenes Problem 121469: Wenn ein Benutzer zur Seite „Globale Einstellungen (Global Settings)“ > „Benutzerverwaltung (User Management)“ navigiert, stellt er möglicherweise fest, dass alle Benutzerkonten gemäß einem Banner auf der Benutzeroberfläche als gesperrt angezeigt werden, obwohl die meisten oder möglicherweise alle Konten tatsächlich nicht gesperrt sind.

    Das Fehlermeldungsbanner für jedes Benutzerkonto würde die Meldung „Dieses Konto wurde aufgrund zu vieler fehlgeschlagener Anmeldeversuche gesperrt (This account has been locked due to too many failed login attempts)“ anzeigen, obwohl auf der Seite mit der Benutzerliste der Status Entsperrt (Unlocked) angezeigt wird und die Anmeldung über die lokale Benutzeroberfläche weiterhin möglich ist.

  • Behobenes Problem 124778: Wenn ein Kunde bei Verwendung der neuen Benutzeroberfläche von VMware SASE Orchestrator zu „Globale Einstellungen (Global Settings) > Kundenkonfiguration (Customer Configuration)“ navigiert, wird ihm die Option zur Konfiguration seiner Sicherheitsrichtlinie nicht angezeigt.

    Im Abschnitt Sicherheitsrichtlinie (Security Policy) kann ein Kunde seinen Edge-IPsec-Vorschlag (Edge IPsec Proposal) einschließlich Verschlüsselung, DH-Gruppe usw. konfigurieren. Diese Option ist in der klassischen Benutzeroberfläche vorhanden, fehlt aber in der neuen Benutzeroberfläche.

Behoben in Orchestrator-Version R5107-20230722-GA

Orchestrator-Build R5107-20230722-GA wurde am 22.07.2023 veröffentlicht und ist das 7. Orchestrator-Rollup für Version 5.1.0.

Dieser Orchestrator-Rollup-Build behebt das folgende wichtige Problem seit dem 6. Orchestrator-Rollup-Build R5106-20230705-GA.

  • Behobenes Problem 122271: Wenn ein Kunde mithilfe der neuen Benutzeroberfläche von VMware SASE Orchestrator zusätzliche LAN-seitige NAT-Regeln zu einem Profil hinzufügt, kann er feststellen, dass der gesamte Datenverkehr, der diesen Regeln entspricht, fehlschlägt.

    Die neue Benutzeroberfläche berechnet die LAN-seitige NAT-Außenmaske fälschlicherweise aus dem Präfix der Innenadresse. Wenn die Regeln nicht so geschrieben sind, dass das innere und das äußere Präfix identisch sind (mit anderen Worten: 1:1) ändert sich das Verhalten der Regeln und kann funktionsunfähig werden, wenn ein Benutzer eine LAN-seitige NAT-Regel über die neue Benutzeroberfläche ändert.

    Bei einem Orchestrator ohne eine Lösung für dieses Problem sollte der Kunde nur die klassische Benutzeroberfläche des Orchestrators für die Konfiguration von LAN-seitigen NAT-Regeln verwenden.

Behoben in Orchestrator-Version R5106-20230705-GA

Orchestrator-Build R5106-20230705-GA wurde am 06.07.2023 veröffentlicht und ist das sechste Orchestrator-Rollup für Version 5.1.0.

Dieser Orchestrator Rollup-Build behebt die folgenden wichtigen Probleme seit dem fünften Orchestrator-Rollup-Build R5105-20230611-GA.

  • Behobenes Problem 84772: Wenn der IPv6-DHCP-Server eines VLANs auf Profilebene als Relay-Typ konfiguriert ist, ein Benutzer den Typ auf Edge-Ebene mithilfe von Edge-Überschreiben in Aktiviert (Activated) ändert und dann später Edge-Überschreiben ausschaltet, verwendet der Edge weiterhin den Typ Aktiviert (Activated), anstatt auf den vom Profil bereitgestellten Relay-Typ zurückzugreifen.

    VMware SASE Orchestrator kann die Profilkonfiguration nicht durchsetzen, wenn Edge-Überschreiben ausgeschaltet wurde, was zu falschen IPv6-Servereinstellungen für den betroffenen Edge führt.

  • Behobenes Problem 115411: Bei einem VMware SASE Orchestrator, der Version 5.1.0 oder höher verwendet und mit einer Notfallwiederherstellungs-Topologie bereitgestellt wird, kann die Synchronisierung aufgrund eines Datenbankproblems fehlschlagen.

    Der spezifische Prozess, der fehlschlägt, ist dr_utils.js und ist ein Ergebnis davon, dass dieser Prozess in der neuesten Version der Orchestrator-Datenbanksoftware aus Version 5.1.0 und höher veraltet ist.

  • Behobenes Problem 115433: Ein Benutzer mit der Rolle „Enterprise Support“ kann keine DHCP-Konfigurationsdetails sehen, wenn er die neue Benutzeroberfläche von VMware SASE Orchestrator betrachtet.

    Derselbe Enterprise Support-Benutzer kann die DHCP-Konfigurationsdetails sehen, wenn er die klassische Benutzeroberfläche verwendet.

  • Behobenes Problem 116633: Wenn sich ein Benutzer bei VMware SASE Orchestrator mit Safari oder Firefox anmeldet und ein ungültiges VLAN auf Profilebene konfiguriert (z. B. "") und dann einen gültigen VLAN-Wert am VMware SD-WAN Edge konfiguriert, wird der Anruf trotzdem durchgeführt, aber ein Fehler angezeigt.

    Der Schnittstellenwert, für den kein Wert festgelegt ist, müsste null sein, lautet aber stattdessen vlanID = "". Wenn sich ein Benutzer mit einem Chromium-basierten Browser beim Orchestrator anmeldet, tritt dieses Problem nicht auf.

  • Behobenes Problem 117772: Auf der Seite „Überwachen (Monitor) > Netzwerkübersicht (Network Overview)“ für einen VMware SASE Orchestrator für einen Unternehmenskunden werden WAN-Links mit dem Status „Beeinträchtigt“ (Degraded) oder „Inaktiv“ (Down) möglicherweise nicht im Bildschirm „Verbindungsstatus“ (Link Status) angezeigt, wenn mehr als 10 WAN-Links überwacht werden.

    Dieses Problem tritt ausschließlich in der neuen Orchestrator-Benutzeroberfläche aufgrund eines Problems im Front-End auf, bei dem beeinträchtigte oder ausgefallene WAN-Links nicht berücksichtigt werden. Die Überwachung funktioniert auf der klassischen Benutzeroberfläche wie erwartet.

  • Behobenes Problem 117988: Das „Erlernen eingehender Routen (Inbound Route Learning)“ mit dem Kontrollkästchen „Genaue Übereinstimmung (Exact Match)“, das für OSPF unter einer VMware SD-WAN-Schnittstelle konfiguriert ist, stimmt nicht mit den Werten überein, die auf dem Edge konfiguriert sind, wenn die Werte auf der klassischen Benutzeroberfläche (Classic UI) und der neuen Benutzeroberfläche (New UI) des VMware SASE Orchestrator verglichen werden.

    Bei aktivierter Option „Genaue Übereinstimmung“ (Exact Match) wird nicht der richtige Wert angezeigt, obwohl er in der Datenbank des Edge korrekt gespeichert ist, wenn die neue Benutzeroberfläche angezeigt wird. Die richtigen Werte werden auf der klassischen Benutzeroberfläche angezeigt.

  • Behobenes Problem 117993: Wenn ein Partnerbenutzer, der Kundenunternehmen mit nativer Authentifizierung (d. h. Benutzername/Kennwort) verwaltet, oder ein Unternehmensbenutzer versucht, ein Kennwort für einen Unternehmensbenutzer zurückzusetzen, schlägt der Versuch fehl.

    Der Benutzer würde die folgende Fehlermeldung erhalten: „Der Benutzer verfügt nicht über die für den Zugriff auf [enterpriseUser/sendEnterpriseUserPasswordResetEMail] erforderlichen Rechte“. Dieses Problem tritt nur auf der neuen Benutzeroberfläche auf und ist auf fehlende Anforderungsparameter zurückzuführen. Wenn dieses Problem auftritt, kann der Benutzer zur klassischen Benutzeroberfläche wechseln und das Zurücksetzen des Kennworts funktioniert wie erwartet.

  • Behobenes Problem 118074: Ein Benutzer kann möglicherweise einige Geräteeinstellungen auf der Seite Configure (Konfigurieren) > Edge > Device (Gerät) der neuen Benutzeroberfläche von VMware SASE Orchestrator nicht öffnen.

    Zu den Einstellungen, die möglicherweise nicht zugänglich sind, gehören Schnittstellen, IPv6, Cloud VPN, Nicht-SD-WAN-Ziel (NSD) und Cloud-Service-Service (CSS). Das Problem wird auf die WAN-Einstellungen zurückgeführt, die eine öffentliche IP-Adresse erfordern, und wenn diese Adresse nicht vorhanden ist, wird auf der neuen Benutzeroberfläche ein Fehler ausgegeben, und der Zugriff auf diese Einstellungen wird blockiert. Die Geräteeinstellungen funktionieren auf der klassischen Benutzeroberfläche wie erwartet.

  • Behobenes Problem 118544: Es kann vorkommen, dass ein Benutzer feststellt, dass ein Operator-Profil nicht geladen wird und nicht zugreifbar ist und somit nicht einem Kundenunternehmen zugeordnet werden kann.

    Es gibt ein Problem mit der Orchestrator-Datenbank, bei dem das Operator-Profil zwar vorhanden ist, aber eine falsche logische ID zu einem Konfigurationsmodul hinzugefügt wird, wenn ein Kundenunternehmen gelöscht wird, wodurch es nicht geladen werden kann.

  • Behobenes Problem 118733: Wenn die neue Benutzeroberfläche von VMware SASE Orchestrator verwendet wird und entweder eine Business Policy oder eine Firewallregel auf Profilebene konfiguriert und dann auf Edge-Ebene außer Kraft gesetzt wird, werden auf dem Bildschirm Konfigurieren (Configure) > Edges > Edges auflisten (List Edges) die Symbole für den außer Kraft gesetzten Edge nicht korrekt für Gerät, Unternehmen und Firewall dargestellt.

    Die Symbole, bei denen Edge-Überschreiben (Edge Override) aktiviert ist, sollten als Volltonfarbe angezeigt werden und sind stattdessen leer. Der Classic Orchestrator zeigt die Symbole korrekt als ausgefüllt an, wenn ein Edge-Überschreiben für eine bestimmte Kategorie konfiguriert wurde.

  • Behobenes Problem 119733: Die Datenbank von VMware SASE Orchestrator kann einen Fehler aufweisen und nicht mehr funktionieren.

    Das Problem ist darauf zurückzuführen, dass die Datenbank nicht auf der neuesten stabilen Version von MySQL läuft. Orchestrator Release 5.1.0.6 behebt diesen Mangel mit einer aktualisierten MySQL-Version.

  • Behobenes Problem 120606: Beim Versuch, eine neue Rolle auf Customer (Kunde) > Globale Einstellungen (Global Settings) > Benutzerverwaltung (User Management) > Neue Rolle (New Role) zu erstellen, wird ein Fehler angezeigt und die Berechtigungen werden nicht geladen.

    Wenn dieses Problem auftritt, sieht der Benutzer beim Erstellen einer neuen Rolle einen „Methodenfehler“ auf der UI-Seite, der auch das Laden von Berechtigungen verhindert.

     

Behoben in Orchestrator-Version R5105-20230611-GA

Orchestrator-Build R5105-20230611-GA wurde am 13. Juni 2023 veröffentlicht und ist der fünfte Orchestrator-Rollup für Version 5.1.0.

Dieser Orchestrator Rollup-Build behebt die folgenden wichtigen Probleme seit dem vierten Orchestrator-Rollup-Build R5104-20230426-GA.

  • Probleme treten nur auf der neuen Orchestrator-Benutzeroberfläche und nicht auf der klassischen Orchestrator-Benutzeroberfläche auf

    Die Orchestrator-Version 5.1.0.5 enthält eine große Anzahl von Fixes bei Problemen, die nur bei der Verwendung der neuen Benutzeroberfläche auftreten können und die bei der Verwendung der klassischen Benutzeroberfläche nicht auftreten. In der folgenden Tabelle sind alle derartigen Fixes mit Beschreibungen der Symptome für jedes Problem aufgelistet.

    Nur auf der neuen Benutzeroberfläche behobenen Probleme

    Ticket

    Symptom/Beschreibung

    Behobenes Problem #87089

    Der Benutzer hat keine Möglichkeit, die Clientadresse auf der Seite Überwachen (Monitor) > Edges > Quellen (Sources) zu bearbeiten. Der Fix fügt ein blaues Bleistiftsymbol hinzu, auf das zum Bearbeiten eines Eintrags geklickt werden kann.

    Behobenes Problem #112044

    Für eine Site, auf der ein Nicht-SD-WAN-Ziel über Edge des Typs Zscaler bereitgestellt wird, zeigt die neue Benutzeroberfläche bei Auswahl von Überwachen (Monitor) > Netzwerkdienste (Network Services) die Spalte „IaaS-Abonnements (IaaS Subscriptions)“ auf der Seite Bereitstellungsstatus (Deployment Status) nicht an.

    Behobenes Problem #112451

    Wenn ein Benutzer ein Konfigurationsprofil bearbeitet und unter Gerät (Device) > Interfaces (Schnittstellen) > Ihre Edge-Modelle (Your Edge Models) den Edge 3810 auswählt, reagiert die Webbrowserseite nicht mehr und kann nicht gespeichert werden. Der Benutzer muss die Seite aktualisieren, um sie wiederherzustellen. Der Kunde kann den Edge 3810 für dieses Profil nicht verwenden.

    Behobenes Problem #112500

    Für eine Site, auf der ein Cloud-Security-Service (CSS) mit dem Typ Zscaler bereitgestellt wird, zeigt die Benutzeroberfläche bei Auswahl von Überwachen (Monitor) > Edges und beim Bewegen des Mauszeigers über die Edge-Tunnel für einen Edge nicht die Zscaler-CSS-Stadt und den -Status an.

    Behobenes Problem #112809

    Ein Kundenadministrator mit der Rolle „Enterprise: Read Only (Enterprise Read Only)“ kann die Seite Überwachung (Monitoring) > Routing auf der Benutzeroberfläche anzeigen.

    Behobenes Problem #112906

    Ein Benutzer stellt möglicherweise fest, dass Benutzeroberflächenseiten mit einer seltsamen Formatierung geladen werden, wenn die Seite große Abschnitte mit Leerraum enthält.

    Behobenes Problem #112912

    Ein Kundenadministrator mit der Rolle „Enterprise-Support (Enterprise Support)“ kann Remote-Aktionen (Remote Actions) > Neu starten (Reboot) nicht für einen Edge auswählen.

    Behobenes Problem #113254

    Ein Partner-Administrator mit einer Superuser- oder Standardrolle kann das Standardoperatorprofil für einen von ihm verwalteten Kunden nicht ändern.

    Behobenes Problem #113366

    Ein Benutzer kann keine statische Route konfigurieren, bei der eine sekundäre VLAN-IP-Adresse der nächste Hop ist.

    Behobenes Problem #113963

    Wenn ein Benutzer eine Firewallregel erstellt und eine Anwendung für diese Regel festlegt und dann später dieselbe Regel bearbeitet und die Anwendung ändert, wird die Änderung nicht übernommen, und die Regel behält die vorherige Anwendung bei.

    Behobenes Problem #114291

    Wenn ein Cloud-Security-Service (CSS) in einem Profil konfiguriert ist, kann der Benutzer weder zwischen Segmenten wechseln noch Geräteeinstellungen (Device Settings) speichern, nachdem ein CSS in mehreren verschiedenen Segmenten geändert wurde.

    Behobenes Problem #114564

    Der Benutzer kann die 802.1P-Einstellung (802.1P Setting) unter der optionalen Konfiguration für eine Edge-Schnittstelle nicht konfigurieren.

    Behobenes Problem #114602

    Der Benutzer kann Operator-Alarme oder Enterprise-Alarme unter Diensteinstellungen (Service Settings) > Alarme und Benachrichtigungen (Alerts & Notifications) nicht konfigurieren.

    Behobenes Problem #114912

    Die Seite Partnerübersicht (Partner Overview) enthält keine Einstellungen für die Benutzervereinbarung (User Agreement).

    Behobenes Problem #115307

    Wenn eine Benutzersitzung lange genug im Leerlauf bleibt, um eine Zeitüberschreitung auszulösen, wird auf der Benutzeroberfläche keine Abmeldemeldung angezeigt, und sie wechselt stattdessen in den Ruhemodus. Wenn der Benutzer auf die Benutzeroberfläche zugreift, wird der Orchestrator aktiviert, und der Benutzer kann auf den Orchestrator zugreifen, statt an die Anmeldeseite weitergeleitet zu werden.

    Behobenes Problem #115439

    Wenn ein Benutzer zu Konfigurieren (Configure) > Profil (Profile) > Geräteeinstellungen (Device Settings) > BGP navigiert, erkennt er BGP als vorhanden. Erfolgt jedoch eine Sortierung nach Segmentierfähig (Segment Aware), fehlt nun die Option zum Konfigurieren von BGP.

    Behobenes Problem #115653

    Wenn ein Partner-Administrator die Seite Kunden verwalten (Manage Customers) anzeigt, wird auf der Benutzeroberfläche nicht mitgeteilt, ob der Kunde Gateways nutzt, die sich im Dienststatus „Stillgelegt (Quiesced)“ befinden. Dadurch wird verhindert, dass der Partner rechtzeitig Maßnahmen ergreift, um sicherzustellen, dass der Kunde nur aktive Gateways verwendet.

    Behobenes Problem #115719

    Eine Backhaul-Regel wird auf der Seite Konfigurieren (Configure) > Business Policy nicht mehr angezeigt, wenn Änderungen an den Geräteeinstellungen (Device Settings) auf Profilebene vorgenommen werden.

    Behobenes Problem #116523

    Wenn ein Benutzer eine VNF-Einfügekonfiguration konfiguriert und versucht, VNF-Hochverfügbarkeit im Edge festzulegen, speichert der Orchestrator die VNF-Änderung nicht, sobald HA konfiguriert ist.

    Behobenes Problem #117527

    Wenn ein Benutzer BGP auf der Profilebene konfiguriert, reagiert der Browser möglicherweise nicht mehr, wenn eine große Anzahl von Regeln konfiguriert ist.

  • Behobenes Problem 105861: Wenn ein WAN-Link für mehrere Minuten ausfällt und dann wiederhergestellt wird, gibt das Diagramm „Überwachen (Monitor) > Quality of Experience“ nicht den tatsächlichen Verbindungszustand wieder.

     Die Quality of Experience-Anzeige sollte rot sein, während die Verbindung inaktiv ist, und dann wieder die entsprechende Farbe annehmen (grün, wenn die Qualität gut ist), wenn die Verbindung wiederhergestellt wurde. Dies geschieht nicht, was zur Folge hat, dass die Benutzer verwirrt sind. Das Problem wird dadurch verursacht, dass die Datenbank von VMware SASE Orchestrator das Ereignis „Verbindung inaktiv (Link down)“ nicht korrekt erfasst.

  • Behobenes Problem 106295: Wenn bei einem Nicht-SD-WAN-Ziel mit einem AWS-Typ primäre und sekundäre Gateways mit jeweils konfiguriertem BGP eingerichtet sind, zeigt der VMware SASE Orchestrator die redundanten sekundären Tunnel unter Umständen als inaktiv an, obwohl sie aktiv sind.

    Die AWS-Seite meldet sowohl den primären als auch den sekundären Tunnel als aktiv, aber auf der Seite Überwachen (Monitor) > Netzwerkdienste (Network Services) des Orchestrators wird der sekundäre Tunnel als inaktiv angezeigt. Hierbei handelt es sich um ein rein kosmetisches Problem.

  • Behobenes Problem 107180: Wenn ein Benutzer eine VNF mit einem Fortinet-Typ konfiguriert, wird die Fortinet-Image-Version 6.49 oder 7.2.0 im Dropdown-Menü nicht angezeigt.

    Diese Images werden in Version 5.1.0 unterstützt, sind aber für einen Kunden nicht zugänglich.

  • Behobenes Problem 107766: Wenn ein Kunde entweder ein Nicht-SD-WAN-Ziel über Edge oder einen Cloud-Security-Service (CSS) konfiguriert und auch die Option „L7-Integritätsprüfung (Level 7 Health Check)“ konfiguriert, kann der Kunde beobachten, dass die Tunnel unerwartet als „inaktiv“ oder „aktiv“ markiert werden, was auf der Grundlage des Konfigurationswerts für die L7-Integritätsprüfung nicht der Fall sein sollte.

    Das Problem besteht darin, dass der Orchestrator die Standardparameter der L7-Integritätsprüfung an den VMware SD-WAN Edge weiterleitet, unabhängig davon, was der Kunde konfiguriert hat. Selbst wenn die Bedingungen des Tunnels mit den vom Kunden konfigurierten Werten übereinstimmen, kann der Status des Tunnels unverändert bleiben, da er sich an den Standardwert der L7-Integritätsprüfung hält.

  • Behobenes Problem 110826: Wenn ein VMware SD-WAN Edge einem Kundenunternehmen zugewiesen wird, verschiebt der VMware SASE Orchestrator den Edge nicht automatisch auf die Registerkarte „Zugewiesene Bestandsliste (Assigned Inventory)“ in der Maestro-Bestandsverwaltungsanwendung.

    Wenn nicht zugewiesene Edges von Maestro angefordert werden und der Orchestrator nach bereits zugewiesenen Seriennummern sucht, wird die Edge-Modellnummer nicht verglichen, was zu Problemen mit doppelt zugewiesenen Edges führt.

  • Behobenes Problem 111957: Nachdem ein Operator ein Upgrade eines VMware SASE Orchestrator durchgeführt hat, können Benutzer Fehler im Zusammenhang mit fehlgeschlagenen Schema-Updates mit langer Ausführungsdauer feststellen. Zum Beispiel können neu erlernte Routen (BGP oder OSPF) auf der OFC-Seite fehlen. Fehler im Zusammenhang mit erlernten Routen werden auch in den Upload-Protokollen auf einem Orchestrator beobachtet.

    Ein Fremdschlüssel auf VELOCLOUD_LEARNED_PARTNER_ROUTE_ASSOC wird verworfen und als Schema-Update mit langer Ausführungszeit während eines Orchestrator-Upgrades von Version 4.2.x auf Version 4.3.x oder höher neu hinzugefügt. Dieser Fremdschlüssel existiert noch nicht in Orchestrator-Instanzen, deren Upgrade-Pfad über einen 2.1.x-Build mit einem Upgrade-Fehler führte, UND ein Gateway, das BGP-Routen erlernte, wurde aus dem Orchestrator gelöscht. In solchen Orchestrator-Instanzen schlägt die Hinzufügung des Fremdschlüssels beim Upgrade 4.2.x > 4.3.x+ fehl, wenn ein Fremdschlüssel, der gegen Datensätze verstößt, bereits in der Tabelle vorhanden ist.

    Der Fix für dieses Problem behebt die Hauptursache, indem der Fremdschlüssel, der gegen die Datensätze verstößt, gelöscht und der Fremdschlüssel anschließend neu hinzugefügt wird.

    Wenn Sie ein Upgrade auf einen Orchestrator ohne einen Fix für dieses Problem durchführen, besteht die Problemumgehung darin, die folgende Abfrage im VeloCloud-Schema von MySQL: DELETE FROM VELOCLOUD_LEARNED_PARTNER_ROUTE_ASSOC WHERE gatewayId not in auszuführen (ID aus VELOCLOUD_GATEWAY wählen) und dann die Schemaaktualisierungen mit langer Ausführungsdauer erneut auszuwählen.

  • Behobenes Problem 112333: Ein VMware SASE Orchestrator, der ca. 4K VMware SD-WAN Edges mit ca. 6K Tunneln und kontinuierlichem Datenverkehr handhabt, kann über einen Zeitraum von ca. 4 Tagen instabil werden und damit beginnen, Benutzer nach dem Zufallsprinzip abzumelden.

    Die Belastung führt dazu, dass die Datenbank des Orchestrators ausfällt und der Fehler „connect ECONNREFUSED“ gefolgt von der IP-Adresse des Orchestrators ausgelöst wird. Dieses Problem wurde nur in einer Skalierungstestumgebung und nicht in einer Feldbereitstellung beobachtet.

  • Behobenes Problem 112605: Ein Kunde stellt möglicherweise fest, dass das Profil beim Versuch, einen Hub-Cluster über „Konfigurieren (Configure) > Gerät (Device) > Cloud-VPN (Cloud VPN) > Edge zu SD-WAN-Sites (Edge to SD-WAN Sites)“ zuzuweisen, nicht reagiert und die Konfiguration nicht gespeichert werden kann.

    Der Orchestrator erstellt doppelte Konfigurationszuordnungen, wenn mehrere Backhaul-Business Policies vorhanden sind, und die doppelten Verweise lösen den Fehler beim Konfigurieren und Zuweisen von Hub-Clustern aus.

  • Behobenes Problem 112992: Wenn ein Kundenunternehmen von einem VMware SASE Orchestrator zu einem anderen migriert wird, fügt der Orchestrator UUID-Einträge hinzu.

    Der UUID-Eintrag wird den VELOCLOUD_ENTERPRISE_OBJECT-Einträgen hinzugefügt, was jedoch nicht der Fall sein sollte.

  • Behobenes Problem 113209: Ein Benutzer kann einen VMware SD-WAN Edge nicht aus dem SASE Orchestrator löschen, wenn sich der Edge im Zustand „Beeinträchtigt (Degraded)“ befindet.

    Der Orchestrator gibt die Fehlermeldung „Beeinträchtigte und verbundene Edges können nicht gelöscht werden (Degraded edges and connected edges cannot be deleted)“ aus. Verbundenen Edges können vom Benutzer nicht gelöscht werden, beeinträchtigte Edges hingegen schon. 

  • Behobenes Problem 113375: Bei einem VMware SASE Orchestrator, der mit einer Notfallwiederherstellungstopologie (Disaster Recovery, DR) bereitgestellt wird, kann das Upgrade fehlschlagen, wenn ein Upgrade des Orchestrators von Version 4.5.x auf Version 5.1.x durchgeführt wird.

    Das Upgrade-Skript und die iptables schlagen beide mit dem Rückgabecode 1 fehl. Das Problem kann während des Zeitraums ausgelöst werden, in dem der aktive und der Standby-Orchestrator unterschiedliche Softwareversionen ausführen und die iptables nicht ordnungsgemäß geladen werden, wenn der Standby-Orchestrator versucht, ein Upgrade durchzuführen (was erwartet wird und vorübergehend ist), und das gesamte Upgrade mit einem Fehler fehlschlägt. Mit dem Fix wird der iptables-Fehler in eine Warnung umgewandelt, und das Upgrade kann fortgesetzt werden.

  • Behobenes Problem 114240: Wenn ein Benutzer unter „Edge-IPsec-Vorschlag (Edge IPsec Proposal)“ die Verschlüsselung in AES-128-GCM oder AES-256-GCM ändert und die Konfiguration speichert, löst die Orchestrator-Benutzeroberfläche einen Fehler aus.

    Der Fehler lautet: „instance.ipsec.encryption ist keiner der enum-Werte: AES_128_CBC, AES_256_CBC, DES_CBC“. Das Problem tritt auf, wenn die beiden Verschlüsselungen vom Typ GCM versehentlich zum Menü Verschlüsselung (Encryption) hinzugefügt wurden, wenn sie keine gültigen Optionen sind. Diese Optionen werden auf dem aktualisierten Orchestrator entfernt.

  • Behobenes Problem 115624: Bei einem VMware SASE Orchestrator kann es zu einer hohen CPU-Nutzung und Instabilität sowie langsamem Laden der Benutzeroberflächenseiten „Geräteeinstellungen (Device Settings)“ und „Netzwerkeinstellungen (Network Settings)“ kommen, wenn der Portaldienst neu gestartet wird.

    Das Problem wurde bei einem Orchestrator mit ca. 2K verbundenen Edges bei gleichzeitiger Verwendung von Cloud-Security-Services (CSS) gefunden und kann bei dieser Anzahl verbundener Edges oder mehr auftreten. Das Problem wird durch mehrere Orchestrator-Prozesse im Zusammenhang mit Edge-, Profil- und Netzwerkkonfigurationen verursacht, die von den Edges auf den Orchestrator hochgeladen werden und viel länger als erwartet dauern (ca. 60 Sekunden oder länger).

  • Behobenes Problem 116141: Wenn ein Benutzer Änderungen an den Geräteeinstellungen in einem Konfigurationsprofil vornimmt, benötigt der VMware SASE Orchestrator viel Zeit, um die Änderungen zu validieren.

    Die Validierung und Anwendung jeder Änderung kann bis zu einer Minute dauern, obwohl sie nur Sekunden dauern sollte. Das Problem wird auf einen Orchestrator-Prozess zurückgeführt, der nicht nur die Anzahl aller diesem Profil zugeordneten Edge-Konfigurationsdatensätze abruft, sondern auch jeden Datensatz dekodiert und analysiert, was unnötig ist und die Orchestrator-CPU belastet. Der Fix stellt sicher, dass der Prozess nur die Anzahl der Datensätze abruft.

  • Behobenes Problem 116770: Wenn ein Operator-Benutzer eine externe Zertifizierungsstelle (CA) mit einer Kettenlänge von 2 oder mehr im Stamm der Vertrauensstellung erstellt, lässt der VMware SASE Orchestrator einen pathLengthConstraint-Wert von 0 in einer untergeordneten Zertifizierungsstelle nicht zu.

    Eine untergeordnete Zertifizierungsstelle, der es nicht gestattet ist, ein untergeordnetes Zertifikat zu signieren, ist eine gültige Konfiguration und sollte vom Orchestrator zugelassen werden. Ein Prozess verhindert jedoch, dass die Konfiguration gespeichert wird.

  • Behobenes Problem 116790: Wenn ein Upgrade von VMware SASE Orchestrator auf Version 5.1.x oder höher durchgeführt wird, werden VMware SD-WAN Edges von Kunden möglicherweise versehentlich auf eine ältere Edge-Version herabgestuft, als für den Edge konfiguriert ist.

    Das Problem wird ausgelöst, wenn ein Kundenunternehmen aus dem Orchestrator gelöscht wird, wobei das gelöschte Unternehmen über seine logische ID in der Orchestrator-Datenbank mit einem Operator-Profil verknüpft war. Wenn das Unternehmen gelöscht wird, wird auch das Operator-Profil gelöscht. Kunden, bei denen die Edge-Image-Verwaltung (Edge Image Management) konfiguriert ist, denen mehrere Operator-Profile zur Verfügung stehen und denen dieses gelöschte Operator-Profil als Standard zugewiesen wurde, wird ein Operator-Profil zugewiesen, das weiterhin in ihrem Menü Edge-Image-Verwaltung (Edge Image Management) verfügbar bleibt. Dies führt dazu, dass dem Kunden ein Operator-Profil zugewiesen werden könnte, das eine wesentlich ältere Edge-Version enthält. Für die Edges, denen dieses Operator-Profil zugewiesen ist, kann die Software geändert und möglicherweise herabgestuft werden, was sich möglicherweise störend auswirkt, z. B. durch Netzwerkfehler, wenn auf dem Edge eine ältere Version ausgeführt wird, die vom Kunden verwendete Funktionen nicht unterstützt.

  • Behobenes Problem 116976: Wenn sich ein Partner-Administrator bei einem VMware SASE Orchestrator anmeldet, stellt der Partner möglicherweise fest, dass der Orchestrator nicht die richtigen Status-WAN-Links anzeigt, die länger als 24 Stunden auf den von ihnen verwalteten VMware SD-WAN Edges inaktiv sind.

    Die Orchestrator-API gibt nur aktuelle Verbindungen für Partner/MSPs zurück, während reguläre Kundenunternehmensbenutzer die korrekten Verbindungsstatusinformationen erhalten, was sich auf die Fähigkeit eines Partners auswirkt, seine Kunden bei Verbindungsproblemen angemessen zu unterstützen.

  • Behobenes Problem 117800: Wenn ein Upgrade von VMware SASE Orchestrator von Version 4.x auf 5.1.x oder höher durchgeführt wird, stellt der Operator möglicherweise fest, dass nach dem Neustart des Backend-Prozesses dieselbe Datei upgradeSchema.sql erstellt wird, obwohl sie erfolgreich ausgeführt wurde.

    Dieses Problem tritt bei der Schemaaktualisierung nach dem Upgrade auf. Sobald das Post-Schema-Skript ausgeführt wurde, sollte die Datei upgradeSchema.sql nicht erneut generiert werden.

  • Behobenes Problem 118071: Der Versuch des Benutzers, die VPN-Einstellungen unter „Konfigurieren (Configure) > Profil (Profile) > Gerät (Device)“ zu ändern, schlägt möglicherweise mit einem Fehler fehlt, wenn dem Kunden mehrere VMware SD-WAN Gateways zugewiesen sind, wobei allen ca. 2K+ Edges zugewiesen sind.

    Der Orchestrator-Fehler lautet „Fehler beim Validieren von Änderungen“. Der VMware SASE Orchestrator kann die VPN-Einstellungen nicht aktualisieren, da die API auf eine Datenbankabfrage wartet, die mehr als 10.000 Zeilen zurückgibt. Dies kann bei einem Orchestrator mit hohem Ressourcenbedarf vorkommen. Das Problem wird dadurch verursacht, dass der Orchestrator alle Gateways unabhängig vom Typ (primär und sekundär) erhält, obwohl der Edge lediglich sein primäres Gateway melden sollte. Dadurch erhöht sich die Anzahl der zurückgegebenen Datensätze erheblich, und eine Abfrage kann in großem Umfang überfüllt werden.

Behoben in Orchestrator-Version R5104-20230426-GA

Orchestrator-Build R5104-20230426-GA wurde am 27. April 2023 veröffentlicht und ist der vierte Orchestrator-Rollup für Version 5.1.0.

Dieser Orchestrator Rollup-Build behebt die folgenden wichtigen Probleme seit dem dritten Orchestrator-Rollup-Build R5103-20230315-GA.

  • Probleme treten nur auf der neuen Orchestrator-Benutzeroberfläche und nicht auf der klassischen Orchestrator-Benutzeroberfläche auf

    Die Orchestrator-Version 5.1.0.4 enthält eine große Anzahl von Fixes bei Problemen, die nur bei der Verwendung der neuen Benutzeroberfläche auftreten können und die bei der Verwendung der klassischen Benutzeroberfläche nicht auftreten. In der folgenden Tabelle sind alle derartigen Fixes mit Beschreibungen der Symptome für jedes Problem aufgelistet.

    Nur auf der neuen Benutzeroberfläche behobenen Probleme

    Ticket

    Symptom/Beschreibung

    Behobenes Problem #104785

    Wenn sich ein Benutzer auf der Seite Überwachen (Monitor) > Ereignisse (Events) befindet und auf die Schaltfläche zum Aktualisieren der Ereignisse klickt, wird der Zeitstempel der Ereignistabelle nicht aktualisiert und die neuesten Ereignisse werden erst in der Tabelle angezeigt, wenn die Webbrowserseite neu geladen wird.

    Behobenes Problem #106327

    Wenn sich ein Benutzer auf der Seite Überwachen (Monitor) > Ereignisse (Events) befindet und einen Filter für Ereignisse konfiguriert, fehlen einige Filteroptionen und schränken ein, wie Edge-Ereignisse gefiltert werden können.

    Behobenes Problem #107071

    Wenn sich ein Benutzer auf der Seite Überwachen (Monitor) > Ereignisse (Events) befindet und ein Zeitfenster auswählt, das so groß ist, dass mehr als 5 Mio. Ereignisse zurückgegeben werden, kommt es zu einer Zeitüberschreitung und das Laden der Seite schlägt fehl.

    Behobenes Problem #107980

    Wenn sich ein Benutzer auf der Seite Konfigurieren (Configure) > Edge > Übersicht (Overview) befindet, kann er den Namen eines Edge nur ändern, wenn er auch das Feld Kontakt und Standort (Contact & Location) ausfüllt, falls die lokalen Kontaktdaten leer sind.

    Behobenes Problem #108072

    Wenn ein Benutzer versucht, eine Loopback-Schnittstelle mit derselben IP-Adresse in verschiedenen Segmenten zu konfigurieren, verhindert der Orchestrator dies und zeigt die Warnmeldung „Muss eindeutig sein“ an.

    Behobenes Problem #109284

    Wenn ein Benutzer einen Tunnel für ein Nicht-SD-WAN-Ziel (NSD) vom Typ Azure oder Zscaler über den Edge hinzufügt, können die Felder Typ der lokalen Kennung (Local Identification Type), Lokale Kennung (Local Identification) und PSK bearbeitet werden.

    Behobenes Problem #109300

    Wenn ein Benutzer einen Bereich des Orchestrators betrachtet, in dem eine Lizenz konfiguriert werden soll, kann der Benutzer nur die ausgewählte Lizenz und keine anderen Lizenzen sehen. Der Orchestrator filtert alle anderen Lizenzoptionen heraus, wenn eine Lizenz ausgewählt ist, und der Fix für dieses Problem enthält eine neue Schaltfläche Löschen (Clear) rechts neben dem Dropdown-Menü für die Lizenz, um die Auswahl einer anderen Lizenzoption zu ermöglichen.

    Behobenes Problem #109532

    Wenn Sie die Seite Konfigurieren (Configure )> Netzwerkdienste (Network Services) anzeigen, unterscheiden sich die DNS-IP-Adressen auf der neuen Benutzeroberfläche von der klassischen Benutzeroberfläche, da die neue Benutzeroberfläche unterschiedliche Felder anzeigt.

    Behobenes Problem #109533

    Auf der Seite Konfigurieren (Configure) > Edge > Gerät (Device) > Konnektivität (Connectivity) > VLAN wird der DHCP-Server als Aktiviert (Enabled) angezeigt, wenn ein genauerer Status von Relay angezeigt werden sollte.

    Behobenes Problem #109715

    Ein inaktiver WAN-Link wird nach 24 Stunden auf der Seite Überwachen (Monitor) > Netzwerkübersicht (Network Overview) nicht mehr angezeigt, obwohl der Grenzwert für Edge-Downlink (Edge Down Link Limit) auf einen Wert von mehr als 24 Stunden festgelegt ist.

    Behobenes Problem #109788

    Beim Konfigurieren eines Nicht-SD-WAN-Ziels kann ein Benutzer kein Site-Subnetz (Site Subnet) mit einem 0.0.0.0/0-Wert konfigurieren, und der Orchestrator deklariert es als „Ungültiges CIDR-Präfix“.

    Behobenes Problem #109836

    Die statischen Routen des Partner-Gateways werden beim Konfigurieren dieser Routen auf der neuen Benutzeroberfläche nicht an die Edges verteilt. Diese Routen sollten an die verbundenen Edges als Cloud-Routen (Typ = Cloud) verteilt und in einem Routentabellenauszug angezeigt werden.

    Behobenes Problem #109911

    Wenn beim Konfigurieren einer Business Policy im Abschnitt Link-Steuerung (Link Steering) >-Schnittstellen (Interfaces) der WAN-Overlay-Typ „Deaktiviert (Disabled)“ lautet, kann diese Schnittstelle nicht ausgewählt werden. Die neue Benutzeroberfläche lässt Schnittstellen zu, die sich auf WAN-Overlay beziehen und nur automatisch erkannt oder benutzerdefiniert sind.

    Behobenes Problem #110094

    Wenn Sie eine Edge-Schnittstelle bearbeiten und viele Filter gleichzeitig zu OSPF hinzufügen, wird das Filterraster nicht mehr angezeigt. Wenn genügend OSPF-Filter hinzugefügt werden, sodass die Paginierung im Raster der OSPF-Filter angezeigt wird, wird die Rasterhöhe auf 0 festgelegt, und ein Benutzer kann das Filterraster nicht mehr bearbeiten oder anzeigen.

    Behobenes Problem #110330

    Sowohl Partner- als auch Kundenadministratoren können die Registerkarte Globale Einstellungen (Global Settings) > Dienstberechtigungen (Service Permissions) möglicherweise nicht sehen. Unter Dienstberechtigungen (Service Permissions) wird die Anpassung der Benutzerrollen dokumentiert.

    Behobenes Problem #111104

    Wenn Sie sich die Seite „Diensteinstellungen (Service Settings)“ > „Edge-Verwaltung (Edge Management) > Software-/Firmware-Images (Software & Firmware Images)“ ansehen, werden nicht alle Details angezeigt, falls ein Benutzer eine Zeile am Ende der Tabelle erweitert.

    Behobenes Problem #111407

    Wenn sich ein Benutzer auf der Seite Konfigurieren (Configure) > Edge > Gerät (Device) > Konnektivität (Connectivity) > Schnittstellen (Interfaces) befindet, ist er nicht berechtigt, eine benutzerdefinierte Schnittstelle zu konfigurieren, ohne ebenfalls einen WAN-Link hinzuzufügen.

    Behobenes Problem #111444

    Bei der Konfiguration eines Cloud-Security-Service (CSS) mit einem Zscaler-Typ darf der Benutzer die Zscaler-Anmelde-URL (Zscaler Login URL) nicht mit einer URL konfigurieren und erhält die Meldung FQDN ist ungültig (FQDN is invalid). Außerdem wird der Wert der Anmelde-URL nicht an einen Server gesendet und gespeichert.

    Behobenes Problem #111934

    Wenn ein Feld eines Nicht-SD-WAN-Ziel über Edge vom Typ Zscaler aktualisiert wird, entfernt der Orchestrator das Feld DH-Gruppe (DH Group).

    Behobenes Problem #111944

    Ein Operator-Superuser kann eine Systemeigenschaft (System Property) nicht ändern oder löschen.

    Behobenes Problem #112094

    Wenn ein Benutzer die Anmeldedaten für einen Cloud-Security-Service (CSS) in einem nicht globalen Segment ändert und in derselben Sitzung zu einem globalen Segment wechselt, werden die CSS-Anmeldedaten entfernt.

    Behobenes Problem #112201

    Wenn ein Benutzer einen Cloud-Security-Service (CSS) über eine API konfiguriert und den CSS auf „Keine (Leer) (None (Empty))“ festlegt, zeigt der Orchestrator in der CSS-Konfiguration des VMware Edge keine Konfiguration an, aber für die Datenbank- und API-Antworten des Edge ist der CSS aktiv und funktioniert. Ein CSS in diesem Zustand kann nicht als Teil einer Business Policy verwendet werden.

    Behobenes Problem #112224

    Wenn ein Kundenadministrator mit der Rolle „Superuser“, „Standard“ oder „Support“ zu Diagnose (Diagnostics) navigiert, ist der Link Diagnosepakete (Diagnostic Bundles) nicht vorhanden, obwohl seine Rolle den Zugriff auf diesen Abschnitt zulässt. Infolgedessen kann ein Kundenadministrator kein Diagnosepaket erstellen (aber auch nicht herunterladen) und keine Packet Capture erstellen und herunterladen.

    Behobenes Problem #112437

    Wenn ein Benutzer mehrere Remote-Diagnose (Remote Diagnostics)-Sitzungen für denselben Edge öffnet, kann die Seite möglicherweise nicht geladen werden, nachdem genügend Sitzungen geöffnet wurden.

  • Behobenes Problem 95631: Wenn ein Benutzer zu „Überwachen (Monitor) > Netzwerkdienste (Network Services) > Cloud-Security-Service Sites (Cloud Security Service Sites)“ navigiert und versucht, die Ereignisse nach dem Zeitpunkt der Zustandsänderung zu sortieren, ist die Sortierreihenfolge falsch.

    Wenn ein Benutzer versucht, nach der Spalte Zeitpunkt der Zustandsänderung (State Change Time) der CSS-Tabelle zu sortieren, ist die Sortierung falsch, da die Datumsangaben nicht nach ihrem Zeitstempel, sondern nach dem analysierten Datum sortiert werden. Dieses Problem tritt sowohl auf der klassischen als auch auf der neuen Benutzeroberfläche auf.

  • Behobenes Problem 106907: Wenn ein Kunde ein Nicht-SD-WAN-Ziel (NSD) über einen mit einer Business Policy verknüpften Edge konfiguriert hat und ein Benutzer NSD über Edge zu einem späteren Zeitpunkt mithilfe von Edge-Außerkraftsetzungen deaktiviert, wird die Business Policy auf einem VMware SASE Orchestrator mit Version 5.1.0 nicht entfernt.

    Der Orchestrator sollte die Business Policy entfernen, sobald NSD über Edge deaktiviert ist. Sollte die Regel weiterhin bestehen, wird der Datenverkehr, der dieser Business Policy entspricht, an ein nicht vorhandenes Ziel mit dem Ergebnis weitergeleitet, dass dieser Datenverkehr verworfen wird.

  • Behobenes Problem 106929: Ein Operator kann einem Operator-Profil auf dem VMware SASE Orchestrator mit Version 5.1.0 möglicherweise keine Softwareversion zuweisen.

    Der Orchestrator gibt eine Fehlermeldung ähnlich der folgenden aus:

    Fehlermeldung.

    Dieses Problem ist darauf zurückzuführen, dass der Orchestrator beim Versuch, das Software-Image hinzuzufügen, aufgrund von konkurrierenden Datenbank-API-Abfragen eine Zeitüberschreitung verursacht. Dieses Problem tritt eher bei einem Orchestrator auf, der eine große Anzahl von Edges hostet, wie es bei von VMware gehosteten Orchestrator-Instanzen der Fall ist, und kann sowohl bei Verwendung der neuen als auch der klassischen Benutzeroberfläche auftreten.

    Bei einem Orchestrator ohne Fix für dieses Problem besteht die einzige Problemumgehung darin, den Zeitüberschreitungswert für Datenbankverbindungen zu erhöhen.

  • Behobenes Problem 107349: Unter „Überwachen (Monitor) > Edge > Quellen (Source)“ auf dem VMware SASE Orchestrator können einige oder sogar alle Quellen nicht aufgelöst werden und zeigen „Kann nicht aufgelöst werden“ an.

    Dieses Problem ist inkonsistent. Einige Sites in einem Kundenunternehmen zeigen die IPs und MAC-Adressen für Quellen wie erwartet an. Das Problem wird dadurch verursacht, dass eine Orchestrator-Datenbanktabelle für Edge-Namen nicht aktualisiert wird.

    Wenn ein Kunde dieses Problem auf einem Orchestrator ohne einen Fix für dieses Problem feststellt, kann er „Cloud-VPN“ in einem Wartungsfenster deaktivieren und anschließend erneut aktivieren, um den Orchestrator zu zwingen, die richtigen Edge-Namen abzurufen.

  • Behobenes Problem 108363: Nach dem Upgrade eines VMware SASE Orchestrator auf Version 5.x kann es an VMware SD-WAN Edges, die Cloud-Security-Services (CSS) wie Zscaler bereitstellen und ebenfalls eine L7-Integritätsprüfung konfiguriert haben, für etwa 30 Sekunden zu einem Verlust des Datenverkehrs über diesen CSS kommen.

    Nach dem Upgrade der Orchestrator-Instanz wird eine Konfigurationsaktualisierung für alle Edges ausgelöst. Dies kann dazu führen, dass einige CSS-Sites mit konfigurierter L7-Integritätsprüfung ausfallen, bis die Konfiguration korrigiert wurde. Das Problem ist mit den Ausführungen unter Behobenes Problem #107302 verknüpft, das das Problem auf dem Edge behebt. Der Fix hier verhindert, dass der Orchestrator bei einem Upgrade Konfigurationsaktualisierungen für Edges auslöst und schützt somit Edges, die nicht über den Fix für Problem #107302 verfügen.

  • Behobenes Problem 110946: Ein VMware SD-WAN Orchestrator mit Version 4.2.x oder früher schlägt möglicherweise fehl, wenn er auf einer SASE Orchestrator-Instanz mit Version 4.3.x oder höher aktualisiert wird.

    Ein Orchestrator der Version 4.2.x oder früher bereinigt den apt-Cache nicht, bevor die apt-Update-Dienstroutine ausgeführt wird, wenn ein Upgrade des Orchestrators auf Version 4.3.x oder höher durchgeführt wird. Dies führt dazu, dass die MySQL-Datenbank während des Upgrades neu gestartet wird und das Upgrade fehlschlägt.

    Beim Upgrade auf eine Orchestrator-Version ohne Fix für dieses Problem kann der Operator vor dem Upgrade den Befehl rm -rf /var/lib/apt/lists/ ausführen.

  • Behobenes Problem 111665: Beim Aktualisieren einer VMware SASE Orchestrator-Instanz von einer früheren Orchestrator-Version auf Version 5.1.0 wird die Migration des Clientgeräts möglicherweise nicht abgeschlossen.

    Das Problem betrifft die Migration von Clientgerätedaten von einem Orchestrator mit MySQL auf einen Orchestrator mit ClickHouse. Nachdem eine bestimmte Anzahl von Datensätzen migriert wurde, wird der Migrationsvorgang vorzeitig beendet.

  • Behobenes Problem 111946: Ein Benutzer kann die Pfade auf der Registerkarte „Edge > Überwachen (Monitor) > Pfade (Paths)“ auf einem VMware SASE Orchestrator nicht sehen, wenn die Peer-Liste größer als 100 ist.

    Wenn ein Benutzer zur Registerkarte Edge > Überwachen (Monitor) > Pfade (Paths) navigiert, gibt das Back-End des Orchestrators alle Datensätze zurück, auch wenn es mehr als 100 gibt. Der Grund dafür ist, dass das Back-End die Beschränkung für den Grenzwert auslässt, die die maximale Anzahl von Datensätzen angibt, die zurückgegeben werden sollen. Die Datensätze, die nach dem Grenzwert zurückgegeben werden, sind nicht normalisiert, d. h. sie sind nicht in einer Weise formatiert, die mit der Benutzeroberfläche kompatibel ist. Dies führt zu einem Fehler in der Benutzeroberfläche. Der Orchestrator sollte nur die Datensätze zurückgeben, die innerhalb des angegebenen Grenzwerts liegen.

  • Behobenes Problem 112458: Wenn ein neues VMware SD-WAN Gateway einem Gateway-Pool hinzugefügt und eine Gateway-Neuverteilung initiiert wird, wird das neue Gateway nicht an VMware SD-WAN Edges neu verteilt, obwohl die vorhandenen Gateways überlastet sind.

    Der VMware SASE Orchestrator sollte mehrere Edges dem am wenigsten ausgelasteten Gateway in derselben geografischen Region neu zuweisen, wenn eine Gateway-Neuverteilung durchgeführt wird. Mit diesem Problem behalten die Edges ihre vorhandene Gateway-Zuweisung bei, obwohl dieses zugewiesene Gateway überlastet ist.

  • Behobenes Problem 112885: Eine Gateway-Neuverteilung kann für Workflows ausgelöst werden, die nicht direkt mit dem Auslösen eines solchen über die VMware SASE Orchestrator-Benutzeroberfläche verbunden werden.

    Der Fix behebt das Problem, dass Gateway-Neuverteilungen für Workflows auftreten können, die nicht für ein dediziertes Unternehmen vorgesehen sind. Eine Gateway-Neuverteilung sollte nur über die Orchestrator-Benutzeroberfläche auf der Operator-Ebene und ohne andere Mittel ausgelöst werden.

  • Behobenes Problem 114475: Wenn ein Operator versucht, eine VMware SASE Orchestrator-Instanz der Version 4.2.0 auf 5.1.0 zu aktualisieren, meldet der Orchestrator möglicherweise, dass das Upgrade fehlgeschlagen ist.

    In den Protokollen beobachtet der Operator diesen Eintrag: Error while initializing CWS Server service Error: Too many connections. Dieses Problem wird durch einen Neustart von MySQL ausgelöst, bevor vco-db-schema installiert wird. Dies wird dadurch verursacht, dass MySQL die maximale Anzahl an Verbindungen nicht festlegt. Während der Orchestrator darüber hinaus meldet, dass die Installation fehlgeschlagen ist, wurde die Installation in Wirklichkeit abgeschlossen. Der Orchestrator kann neu gestartet werden, und alle Dienste funktionieren wie erwartet.

Behoben in Orchestrator-Version R5103-20230315-GA

Orchestrator-Build R5103-20230315-GA wurde am 15. März 2023 veröffentlicht und ist der dritte Orchestrator-Rollup für Version 5.1.0.

Dieser Orchestrator-Rollup-Build behebt die folgenden kritischen Probleme ab der zweiten Orchestrator-Rollup-Version R5102-20230222-GA.

  • Behobenes Problem 107587: Ein Operator kann die Benutzerdetails für andere Operatoren oder Kundenadministratoren auf dem VMware SASE Orchestrator nicht bearbeiten.

    Operatoren sollten über das Recht verfügen, unter Verwaltung (Administration) > Benutzerverwaltung (User Management) Benutzerdetails für einen anderen Operator (sofern ihre Rolle dies zulässt) zu ändern und einen Kundenadministrator bei aktivierter Verwaltungsdelegierung zu bearbeiten. Bei diesem Problem sieht sich der Operator mit schreibgeschützten Benutzerdetails konfrontiert, die nicht von ihm bearbeitet werden können.

  • Behobenes Problem 107725: Wenn ein Benutzer mithilfe der neuen Benutzeroberfläche des VMware SASE Orchestrators zu „Überwachen (Monitor)“ > „Edges“ > „Zuordnungsverteilung (Map Distribution)“ navigiert, werden in der Verteilung maximal 20 VMware SD-WAN Edges gleichzeitig angezeigt und nicht alle Edges, die von einem Kunden bereitgestellt wurden.

    Dieses Problem betrifft Kunden, die mehr als 20 Edges bereitstellen, da in der Zuordnungsverteilung (Map Distribution) der neuen Benutzeroberfläche nur 20 Edges gleichzeitig in der Edge-Liste des Kunden angezeigt werden. Wenn der Benutzer auf die nächste Seite der Liste klickt, werden in der Verteilung nur die Edges auf dieser Seite angezeigt. Es ist nicht möglich, alle Edges für ein Kundenunternehmen aufzulisten.

  • Behobenes Problem 108533: Wenn ein Benutzer zu „Diensteinstellungen (Service Settings)“ > „Edge-Verwaltung (Edge Management)“ > „Updates konfigurieren (Configure Updates)“ navigiert, ist der Erläuterungstext für die Einstellungen auf der neuen Benutzeroberfläche des VMware SASE Orchestrators nicht eindeutig.

    Der Einstellungsname Edge-Konfigurationsaktualisierungen deaktivieren (Disable Edge Configuration Updates) steht im Widerspruch zur tatsächlichen Funktion der Einstellung. Mit diesem Fix wird die Einstellung in Aktualisierungen der Edge-Konfiguration aktivieren (Enable Edge Configuration Updates) geändert und somit in Übereinstimmung mit der Funktion und dem Erläuterungstext gebracht.

  • Behobenes Problem 108833: Wenn ein Benutzer einen BGP-Filter für ein nicht globales Segment auf der neuen Benutzeroberfläche des VMware SASE Orchestrators ändert, überschreibt der Orchestrator die Änderung dieses BGP-Filters im globalen Segment mit dieser neuen Einstellung.

     Bei einem Kunden, der BGP in mehreren Segmenten mit jeweils eindeutigen Einstellungen verwendet, kann dieses Problem zu einem Netzwerkausfall für die Benutzer führen, die das globale Segment verwenden, in dem die BGP-Einstellungen überschrieben werden. Das Problem wird bei Verwendung der klassischen Benutzeroberfläche nicht beobachtet.

  • Behobenes Problem 109064: Ein Benutzer kann dieselbe SSID (Service Set Identifier) auf zwei verschiedenen WLAN-Schnittstellen für einen VMware SD-WAN Edge konfigurieren, wenn der Benutzer den MAC-Filter auf einer und nicht auf der anderen WLAN-Schnittstelle konfiguriert.

    Das Konfigurieren derselben SSID auf WLAN1 und WLAN2, eines mit aktiviertem und ein anderes mit deaktiviertem MAC-Filter oder mit verschiedenen MAC-Positivlisten auf jeder Schnittstelle, sollte vom VMware SASE Orchestrator nicht zugelassen werden, da auf diese Weise nicht genehmigte MAC-Adressen verbunden werden können.

Behoben in Orchestrator-Version R5102-20230222-GA

Orchestrator-Build R5102-20230222-GA wurde am 24. Februar 2023 veröffentlicht und ist der zweite Orchestrator-Rollup für Version 5.1.0.

Dieser Orchestrator-Rollup-Build behebt die folgenden kritischen Probleme seit dem ersten Orchestrator-Rollup, Version R5101-20221220-GA.

  • Behobenes Problem 40584: Wenn ein Benutzer „Überwachen > Edge > Quellen (Monitor > Edge > Sources)“ auf dem VMware SASE Orchestrator aufruft, kann er feststellen, dass der Orchestrator bei Verwendung des IP-Sichtbarkeitsmodus nicht das neueste Clientgerät anzeigt, obwohl neue Clientgeräte zu einem VMware SD-WAN Edge hinzugefügt wurden.

    Dieses Problem kann auftreten, wenn der Sichtbarkeitsmodus des Edge als Sichtbarkeit nach IP-Adresse (Visibility by IP Address) konfiguriert ist. Dieses Problem wird dadurch verursacht, dass der Orchestrator bei Verwendung des IP-Adressmodus die neuesten Clientinformationen für den Edge nicht korrekt verarbeitet und daher nur den älteren Client und dessen IP-Adresse anzeigt.

  • Behobenes Problem 105610: Wenn ein Benutzer versucht, eine neue IPv4-Objektgruppe zu erstellen oder eine bereits vorhandene IPv4-Objektgruppe zu aktualisieren, die eine Platzhaltermaske enthält, die mit „255“ beginnt und mit „0“ endet (z. B. 255.0.1.0), lässt VMware SASE Orchestrator diese Platzhaltermaske nicht zu und gibt eine Fehlermeldung aus, obwohl es sich um einen gültigen Platzhalterausdruck handelt und dieser zulässig sein sollte.

    Ab Version 5.0.x fehlt den Orchestrator-Instanzen die Validierung für Platzhaltermasken in Objektgruppen. Dies führt zu einem Fehler, wenn ein Benutzer eine Platzhaltermaske für eine Gruppe konfiguriert.

  • Behobenes Problem 106159: Ein VMware SASE Orchestrator mit Version 5.1.0.0 und 5.1.0.1 erlaubt es nativen Benutzern nicht, API-Token zu erstellen, wenn die Authentifizierung als Single Sign-On (SSO) konfiguriert ist und der entsprechende Identitätsanbieter (IdP) keinen Introspektionsendpoint unterstützt.

    Version 5.1.0.0 führt eine Prüfung des IdP-Introspektionsendpoints während der Validierung der API-Token-Erstellung ein. Bei dieser Prüfung wird nicht zwischen nativen und nicht-nativen Benutzern unterschieden. Solange SSO für die Authentifizierung konfiguriert ist, validiert der Orchestrator, ob der IdP den Introspektionsendpoint unterstützt. Wenn der IdP den Introspektionsendpoint nicht unterstützt, verhindert die Validierung, dass sowohl native als auch nicht-native Benutzer API-Token erstellen können. Diese Bedingung gilt sowohl für Operator-Benutzer als auch für Partner-Administratoren.

  • Behobenes Problem 106242: Ein Benutzer, der auf die Seite „Diagnose > Remote-Diagnose (Diagnostics > Remote Diagnostics)“ auf dem VMware SASE Orchestrator zugreift, wird möglicherweise unerwartet von der Seite „Remote-Diagnose (Remote Diagnostics)“ abgemeldet, während er eine Edge-Diagnose durchführt.

    Wenn dieses Problem bei einem Benutzer auftritt, liegt es daran, dass der Orchestrator ein Limit für die Anzahl der möglichen Verbindungen erreicht hat und Remote-Diagnose-Benutzer abmeldet, um den normalen Betrieb sicherzustellen. Das Problem wird dadurch verursacht, dass der Orchestrator Datenbankverbindungen fälschlicherweise nicht freigibt, sobald sie nicht mehr benötigt werden, was dazu führt, dass der Orchestrator Verhaltensweisen zur Begrenzung von Verbindungen auslöst.

  • Behobenes Problem 106592: Auf einem VMware SASE Orchestrator mit Version 5.1.0.0 und 5.1.0.1 stellt ein Kunde, der APIs verwendet, möglicherweise die folgenden Symptome fest: a) Aktive API-Token werden vom Orchestrator widerrufen und b) Dienste wie APIv2 funktionieren nicht mehr.

    Version 5.1.0.0 führt einen neuen Back-End-Auftrag namens batchRevokeApiTokenForInactiveSsoUsers ein, der alle 6 Stunden ausgeführt wird, um zuvor ausgegebene API-Token für inaktive SSO-Benutzer (Single-Sign On) zu widerrufen. Fehler im Back-End-Auftrag führen dazu, dass er fälschlicherweise alle API-Token auf dem Orchestrator widerruft, unabhängig davon, für wen die Token erstellt wurden.

    Mit dem Fix sollte ein Kundenadministrator mit einem Superuser oder ein Partneradministrator inaktive Identitätsanbieter (IdP)-Benutzer manuell aus dem Orchestrator löschen, um einen unberechtigten Zugriff über API-Token zu verhindern.

  • Behobenes Problem 106806: Wenn ein VMware SASE Orchestrator auf Version 5.1.0 aktualisiert wird, können Kunden, die mit dem Orchestrator verbunden sind, Unterbrechungen im Kundendatenverkehr feststellen.

    Der Orchestrator erstellt im Rahmen des Upgrades auf 5.1.0 eine neue Version des Geräteeinstellungsmoduls. Der Orchestrator überträgt dann diese neue Version der Geräteeinstellungen an alle verbundenen Edges. Dies kann zu Unterbrechungen führen, da bestimmte Änderungen der Geräteeinstellungen einen Neustart des Edge-Diensts auslösen können, was zu einer Unterbrechung des Kundendatenverkehrs von 10-15 Sekunden führt. Der Fix für dieses Problem stellt sicher, dass der Orchestrator beim Upgrade auf Version 5.1.0 keine aktualisierte Version der Geräteeinstellungen an alle verbundenen Edges sendet.

  • Behobenes Problem 107410: Wenn ein Partneradministrator die neue Benutzeroberfläche in VMware SASE Orchestrator verwendet und versucht, einem Partnerkunden ein Software-Image zuzuweisen, stellt er fest, dass er nicht durch das Dropdown-Menü mit der Liste der Software-Images scrollen kann.

    Wenn der Partner beim Öffnen des Dropdown-Menüs das gewünschte Software-Image nicht in der ersten Anzeige der Images sieht, kann er nicht nach unten scrollen, um das gewünschte Image zu finden, falls es weiter unten steht. Für Operator-Benutzer ist dies kein Problem, und der Partneradministrator kann auch in der klassischen Benutzeroberfläche scrollen, wenn er einem Kunden ein Software-Image zuweist.

  • Behobenes Problem 107637: Ein Kunde mit einer großen Anzahl von VMware Edges kann feststellen, dass die Seite nicht geladen wird, wenn er in der klassischen Benutzeroberfläche von VMware SASE Orchestrator zu „Konfigurieren (Configure) > Edges“ navigiert.

    Dieses Problem tritt auf der klassischen Benutzeroberfläche auf und die Seite wird mit der Meldung Ein unerwarteter Fehler ist aufgetreten abgebrochen. Bei einem Benutzer, der die neue Benutzeroberfläche verwendet, tritt dieses Problem nicht auf.

    Fehlerbildschirm.

    Bei der Behebung des Problems stellt ein Operator in den Orchestrator-Protokollen fest, dass die Methode enterprise/getEnterpriseEdgeList mit dem folgenden Fehler fehlschlägt:

    2023-02-06T17:21:05.412Z - error: [[email protected]] [24775] API Invocation error for enterprise/getEnterpriseEdgeList: { code: undefined, message: 'Internal error' }

    Dieses Problem wird durch eine Orchestrator-API verursacht, die die Edge-Liste für einen Kunden in Szenarien wie Konfigurieren (Configure) > Edges abruft. Auf der klassischen Benutzeroberfläche wird diese API in einer Weise verwendet, die zu einer Zeitüberschreitung führen kann, insbesondere wenn eine große Anzahl von Edges abgerufen werden muss (z. B. 500 Edges oder mehr).

  • Behobenes Problem 107885: Die Seite „Konfigurieren > Übersicht (Configure > Overview)“ wird für einige VMware SD-WAN Edges möglicherweise nicht geladen, wenn ein Benutzer die neue Benutzeroberfläche von VMware SASE Orchestrator aufruft.

    Dieses Problem ist inkonsistent und die Seite Konfigurieren > Übersicht (Configure > Overview) kann für einige Edges geladen werden. Das Problem wird ausgelöst, wenn das QoS-Modul des Edge nicht mit Segmentinformationen gefüllt ist.

    Auf einem Orchestrator ohne Fix für dieses Problem kann ein Benutzer eine Test-Business Policy konfigurieren, die sich nicht auf den Benutzerverkehr auswirkt, und diese speichern, woraufhin die Seite „Übersicht (Overview)“ erfolgreich geladen wird.

  • Behobenes Problem 108074: Wenn ein Benutzer das Edge-Informationsfeld auf dem Bildschirm „Überwachen“ (Monitor) > „Edge“ öffnet, fehlt die Beschreibung bei Anzeige dieser Informationen auf der neuen Benutzeroberfläche eines VMware SASE Orchestrators.

    Auf dem Bildschirm der klassischen Benutzeroberfläche wird für Überwachen (Monitor) > Edge im Dropdown-Informationsbildschirm des Edge die konfigurierte Beschreibung angezeigt:


    Auf dem Bildschirm der neuen Benutzeroberfläche wird für Überwachen (Monitor) > Edge im Dropdown-Informationsbildschirm des Edge keine konfigurierte Beschreibung angezeigt:


    Ein Benutzer kann die Beschreibung (Description) des Edge auf der Seite Konfigurieren (Configure) > Edge > Übersicht (Overview) konfigurieren.

  • Behobenes Problem 108309: Wenn ein Benutzer auf der neuen Benutzeroberfläche eines VMware SASE Orchestrators mit Version 5.1.0 versucht, einen VMware SD-WAN Edge unter Verwendung von Edge-Überschreibung mit einem Nicht-SD-WAN-Ziel (NSD) zu verknüpfen, wird die Option für die Tunnelkonfiguration nicht angezeigt.

    Die Option für die Tunnelkonfiguration sollte als letzte Spalte auf dem Bildschirm als Aktion (Action) mit einem +-Symbol angezeigt werden. Bei diesem Problem fehlt das +-Symbol.


    Dieses Problem ist auf Edge-spezifische Aktionen beschränkt. Wenn ein Kunde ein NSD über ein vom Edge verwendetes Profil hinzufügt (im Gegensatz zur Edge-Überschreibung), wird die Option Aktion (Action) + korrekt angezeigt.


Behoben in Orchestrator-Version R5101-20221220-GA

Die Orchestrator-Version R5101-20221220-GA wurde am 20.12.2022 veröffentlicht und ist der erste Orchestrator-Rollup für Version 5.1.0.

Dieser Orchestrator Rollup-Build behebt die folgenden kritischen Probleme seit dem Orchestrator-Build R5100-20221202-GA.

  • Behobenes Problem 100133: Bei einem VMware SASE Orchestrator können Leistungsprobleme auftreten.

    Wenn ein Kunde eine große Anzahl von Business Policy-Regeln konfiguriert, indem er sie mit einem Edge-Hub-Cluster verknüpft, treten auf dem Orchestrator Leistungsprobleme auf, sobald diese Konfigurationen an die Edges in diesem Unternehmen übertragen werden müssen.

  • Behobenes Problem 101835: Der Abschnitt „Cloud-VPN (Cloud VPN)“ steht auf der neuen Orchestrator-Benutzeroberfläche nicht zur Verfügung, wenn der Benutzer ein nicht globales Segment auswählt, in dem Cloud-VPN konfiguriert ist.

    Auf der Seite mit den Einstellungen Konfigurieren (Configure) > Edge > Gerät (Device) der neuen Orchestrator-Benutzeroberfläche steht der Abschnitt Cloud-VPN (Cloud VPN) nicht zur Verfügung, wenn der Benutzer ein nicht globales Segment auswählt, in dem Cloud-VPN konfiguriert ist.

  • Behobenes Problem 102806: Ein Kunde kann die Übergabekonfiguration des Partner-Gateways nicht auf Gateway-Ebene bearbeiten.

    Dieses Problem tritt auf, wenn ein Kunde die Übergabe des Partner-Gateways während eines Upgrades konfiguriert.

  • Behobenes Problem 103622: Der Operator-Benutzer erhält unter Umständen die Fehlermeldung „Sie sind nicht berechtigt, auf diese Daten zuzugreifen (You don’t have permission to access this data)“ beim Versuch, auf bestimmte Seiten im VMware SASE Orchestrator zuzugreifen.

    Dieses Problem tritt auf der neuen Orchestrator-Benutzeroberfläche auf, wenn ein Operator-Benutzer auf die Seite „Operator- oder Partnerbenutzerverwaltung (Operator or Partner User Management)“ zugreift, nachdem er die Seiten „Globale Einstellungen (Global Settings)“, „Cloud Web Security“ oder „Sicherer Zugriff (Secure Access)“ für einen Kunden aufgerufen hat.

Behoben in Orchestrator-Version R5100-20221202-GA

Orchestrator Version R5100-20221202-GA wurde am 12-08-2022 veröffentlicht und behebt die folgenden Probleme seit Orchestrator Version R5011-20221129-GA.

Hinweis:

Version 5.1.0 enthält alle Orchestrator-Fixes, die in den Versionshinweisen zu 5.0.0 oder 5.0.1 aufgelistet sind.

  • Behobenes Problem 91407: Wenn ein benutzerdefiniertes WAN-Overlay als Sicherungslink konfiguriert ist, zeigt VMware SASE Orchestrator mit Version 5.0.x den Link unter „Überwachen (Monitor) > Edge“ als aktiv an, obwohl sich der Link tatsächlich im Sicherungsmodus befindet.

    Es handelt sich hierbei nur um ein Anzeigeproblem, und die Funktion „Backup-WAN-Link“ funktioniert ordnungsgemäß. Das Problem wird dadurch verursacht, dass der Orchestrator die Linkmodus-Werte für den Edge nicht ordnungsgemäß speichert, was dazu führt, dass der falsche Status angezeigt wird.

  • Behobenes Problem 91393: Bei Kunden, die mit syslong oder telnet Daten vom Edge erfassen, beobachtet der Benutzer möglicherweise zwei Namen für dieselbe Anwendung in den NetFlow-Daten vom VMware SD-WAN Edge.

    Dieses Problem tritt auf, wenn es Anwendungen gibt, für die sich der displayName in der Sprachdatei (appids_en_us.json) von dem displayName in der Anwendungsdatei (applications.json) unterscheidet. Da der displayName der Datei applications.json auf der Edge-Seite verwendet wird, sollte sich dieser nicht ändern.

    Das Problem tritt auf, weil der displayName der Datei applications.json als Teil einer API-Antwort in den displayName aus der Datei appids_en_us.json geändert wurde und bei jeder Aktualisierung von Anwendungszuordnungsdaten jeder displayName der Anwendungs-Map aktualisiert wird, selbst wenn der Benutzer ihn nicht geändert hat, und derselbe an den Edge übertragen wird.

  • Behobenes Problem 12132: Beim Konfigurieren einer statischen Route in VMware SASE Orchestrator warnt die Benutzeroberfläche vor einem Neustart des Edge-Diensts, der in Wirklichkeit nicht stattfindet.

    Wenn die Konfiguration einer beliebigen statischen Route geändert und die Änderungen gespeichert werden, warnt die Orchestrator-Benutzeroberfläche vor einem Edge-Neustart und einer Unterbrechung des Diensts. Diese Meldung ist ungültig, und es gibt keinen Neustart des Edge-Diensts in Verbindung mit der Änderung der Konfiguration einer statischen Route. Mit dem Fix wird die falsche Warnung entfernt.

  • Behobenes Problem 36058: Ein WAN-Link, der als Sicherungslink konfiguriert ist, kann auf der Seite „Überwachen (Monitor) > Übersicht (Overview)“ der VMware SASE Orchestrator-Benutzeroberfläche als grau angezeigt werden, wenn der Link tatsächlich ausgefallen ist.

    Der Bildschirm würde wie folgt aussehen:


    Auf der Seite Überwachen (Monitor) > Edge > Overview (Übersicht) wird der Status des Sicherungslinks korrekt angezeigt.

  • Behobenes Problem 52952: Die VMware SASE Orchestrator-Benutzeroberfläche ermöglicht es einem Benutzer, ungültige Eingaben für „AS für Pfad voranstellen (AS-Path-Prepend)“ zu konfigurieren.

    Die Orchestrator-Benutzeroberfläche überprüft keinen ungültigen AS-Path-Prepend-Wert. Ein Benutzer kann AS PATH Prepend mit Werten eingeben, die ein Komma enthalten, und die Benutzeroberfläche akzeptiert dies, obwohl es sich um eine ungültige Konfiguration für den Edge-Routing-Prozess handelt. Die ungültige Konfiguration wird nicht angewendet, und der Benutzer erhält keine Rückmeldung, z. B. eine Warnung, eine Fehlermeldung oder einen Hinweis auf die ungültige Konfiguration.

  • Behobenes Problem 53740: Beim Konfigurieren einer Firewallregel auf der VMware SASE Orchestrator-Benutzeroberfläche kann ein Benutzer keinen Protokollwert für ein Protokoll konfigurieren, das er abgleichen möchte.

    Der Orchestrator erlaubt nur TCP/UDP/ICMP/GRE in den Protokollübereinstimmungskriterien und lässt keine Protokollwerte von 0-255 zu. Die Änderung ermöglicht es einem Benutzer, eine passende Firewallregel zu konfigurieren, und unter Ziel (Destination) wählt der Benutzer „Andere (Other)“ im Menü Protokoll (Protocol) aus und gibt dann einen Wert von 0-255 ein.

    Hinweis:

    Während ein Benutzer einen Wert von 0-255 eingeben kann, gelten die Protokollwerte 144-255 als reserviert oder nicht zugewiesen gemäß der IANA Assigned Internet Protocol Numbers-Dokumentation.

  • Behobenes Problem 68347: Der VMware SASE Orchestrator zeigt fälschlicherweise ein Zscaler IPsec für GRE-Tunnel-Ereignis als Edge IPsec-Tunnel-Ereignis auf der Seite „Warnungen (Alerts)“ an.

    Es wird nicht erwartet, dass Warnungen für GRE-Tunnel-Ereignisse generiert werden.

  • Behobenes Problem 70987: Ein Benutzer kann einen VMware SD-WAN Edge möglicherweise nicht aus dem VMware SASE Orchestrator löschen.

    Die Edges sind offline, werden aber nicht auf „Getrennt (Disconnected)“ aktualisiert, sondern verbleiben in einem herabgestuften Status und können daher nicht gelöscht werden.

  • Behobenes Problem 72444: Wenn ein Benutzer IPv4- und IPv6-BGP-Nachbarn für einen VMware SD-WAN Edge konfiguriert und dann versucht, die BGP-Einstellungen mit der Ein/Aus-Schaltfläche auszuschalten, wird die Konfiguration nicht gespeichert und auf der VMware SASE Orchestrator-Benutzeroberfläche wird „Keine Änderungen“ (No Changes) angezeigt.

    In diesem seltenen Fall, in dem ein Benutzer die BGP-Einstellungen konfiguriert und BGP ausschaltet, werden die Aktionen des Benutzers für die BGP-Einstellungen nicht ordnungsgemäß gespeichert.

  • Behobenes Problem 73481: Wenn zwei oder mehr VMware SD-WAN Gateways am gleichen Standort bereitgestellt werden, kann ein Operator beobachten, dass ein Gateway von den meisten VMware SD-WAN Edges verwendet wird, während das andere Gateways nicht voll ausgelastet ist, was zu Leistungsproblemen bei dem voll ausgelasteten Gateway führen kann.

    In diesem Fall ist ein Gateway zu 90 % ausgelastet, während ein anderes Gateway am selben Standort nur zu 10 % ausgelastet ist und noch Ressourcen übrig hat. Bei der Zuweisung von primären und sekundären Gateways für Edges muss die bestehende Auslastung der Gateways berücksichtigt werden. Ist dies nicht der Fall, wird ein einzelnes Gateway als primäres Gateway überlastet, während auf einem sekundären Gateway viel Kapazität ungenutzt bleibt.

  • Behobenes Problem 75175: Wenn ein Kundenadministrator versucht, auf die Gateway-Informationsseite in VMware SASE Orchestrator zuzugreifen, schlägt die Seite mit einem Fehler fehl.

    Nach einer Gateway-Migration wird unter Überwachen (Monitor) > Edge > Ansicht (View)(unter Gateway) die folgende Fehlermeldung angezeigt: Fehler beim Laden der Gateway-Informationen (Error Loading Gateway info)


    Es wird nicht erwartet, dass Kundenadministratoren auf die Gateway-Informationsseite zugreifen können. Wenn sie jedoch versuchen, auf die Seite zuzugreifen, wird aufgrund ihrer Rechtestufe ein Fehler in den Abschnitten angezeigt.

  • Behobenes Problem 76091: Beim Bearbeiten eines Subnetzes auf dem Bildschirm „Konfigurieren > Gerät (Configure > Device)“ beobachtet ein Benutzer möglicherweise, dass der Bildschirm einfriert.

    Wenn entweder die Schaltfläche „Zurücksetzen (Reset)“ angeklickt oder der Edge auf „Geeignete VPN-Beendigungen (Eligible VPN Exits)“ verschoben wird und der Benutzer dann auf Speichern (Save) für ein Subnetz klickt, das keine erlernten Routen aufweist, friert die Benutzeroberfläche ein und das Ladesymbol dreht sich ewig.


     

    Das Problem wird dadurch verursacht, dass das learnedRoute-Array in diesen Subnetzen fehlt, was einen Fehler in der Benutzeroberfläche auslöst.

  • Behobenes Problem 76182: Bei der Auswahl bestimmter Zeitintervalle auf der Seite „Überwachen (Monitor) > Edge“ der VMware SASE Orchestrator-Benutzeroberfläche gibt der Orchestrator möglicherweise unvollständige Daten zurück.

    Bei einer Benutzerabfrage mit Intervallen, die ein Vielfaches von 5 sind, z. B. 12:00:00 - 13:00:00, sendet das Backend aufgrund eines Problems mit der Edge Link-Statistik-API nur 11 Stichproben von 5 Minuten anstelle der korrekten 12 Stichproben.

  • Behobenes Problem 77538: Wenn ein Kundenunternehmen von einem VMware SASE Orchestrator zu einem anderen Orchestrator migriert wird, kann der Kunde doppelte Operator-Profile und Edge-Software-Images feststellen.

    Die doppelten Operator-Profile sind nicht nur verwirrend für den Kunden, sie verweisen auch immer noch auf den alten Orchestrator, sodass ein Edge, der eines dieser Profile verwendet, einen Heartbeat an den falschen Orchestrator sendet. Dies führt dazu, dass der Edge als inaktiv markiert wird und keine Konfigurationsaktualisierungen erhält.

  • Behobenes Problem 79383: Wenn Benutzer eine Konfigurationsänderung in „Konfigurieren > Gerät (Configure > Device)“ vornehmen, wird ihnen möglicherweise eine Fehlermeldung angezeigt, aber nicht der Segmentname, bei dem der Fehler aufgetreten ist.

    Wenn beispielsweise eine Edge-Schnittstelle auf Profilebene von Geroutet auf Geswitcht umgestellt wird, wird dem Benutzer die Zeichenfolge „object.segment.name“ anstelle des Segmentnamens angezeigt, wenn ein Fehler in den Geräteeinstellungen vorliegt.


    Bei Kundenunternehmen mit mehreren Segmenten wird die Fehlerbehebung schwierig, wenn nicht klar ist, in welchem Segment der Fehler aufgetreten ist.

  • Behobenes Problem 80445: Beim Konfigurieren von OSPF auf dem VMware SASE Orchestrator kann ein Benutzer feststellen, dass die OSPF-Bereichs-ID doppelte Einträge zwischen IP und Nummer zulässt und der OSPF-Bereichs-ID-Wert „0“ als gültige ID zugelassen ist.

    Der Orchestrator prüft nicht auf doppelte Einträge zwischen den Formattypen IP und Nummer für Bereichs-IDs. Darüber hinaus lässt er den Wert „0“ als gültige OSPF-Bereichs-ID zu. Infolgedessen kann der Benutzer fälschlicherweise eine ungültige OSPF-Konfiguration konfigurieren und veröffentlichen, was negative Auswirkungen nach sich zieht.

  • Behobenes Problem 81364: Wenn Sie die neue Orchestrator-Benutzeroberfläche zur Konfiguration von VMware SD-WAN Edge-Schnittstellen verwenden, werden die Geschwindigkeits- und Duplex-Einstellungen für geroutete Schnittstellen nicht aktualisiert.

    Bei einem Orchestrator ohne Fix für dieses Problem muss der Benutzer den klassischen Orchestrator verwenden, um Geschwindigkeits- und Duplex-Einstellungen für die geroutete Schnittstelle eines Edge zu konfigurieren.

  • Behobenes Problem 81366: Wenn die neue Orchestrator-Benutzeroberfläche verwendet wird, um eine Kunden-Site mithilfe von Hochverfügbarkeit zu konfigurieren, werden die Änderungen für das APR-Prüfintervall nicht unter den LOS-Werten gespeichert.

    Das überarbeitete APR-Prüfintervall unter LOS-Erkennung zeigt nicht die konfigurierten Werte für den HA Edge an. Bei einem Orchestrator ohne Fix für dieses Problem müssen die APR-Prüfwerte auf dem klassischen Orchestrator konfiguriert werden.

  • Behobenes Problem 83342: Beim Versuch, einen Bericht mit zu vielen Edges zu erstellen, gibt der VMware SASE Orchestrator eine vage Fehlermeldung aus, ohne eine Erklärung, warum der Bericht fehlgeschlagen ist.

    Beim Erstellen eines fehlgeschlagenen Berichts werden die Fehlerdetails nicht in der Benutzeroberfläche angezeigt, sodass der Benutzer die Fehlerursache nicht beheben kann.


    Die Dienstprotokolldaten enthalten die fehlenden Details, wenn sie auf einem Orchestrator ohne den Fix benötigt werden.

    Nicht verfügbar

  • Behobenes Problem 83345: Wenn der Versuch, einen Bericht auf dem VMware SASE Orchestrator zu erstellen, aufgrund einer Zeitüberschreitung fehlschlägt, wird auf der Benutzeroberfläche kein Validierungsfehler angezeigt.

    Dieses Ticket steht im Zusammenhang mit 83342 und in beiden Fällen sind die Protokolle nicht detailliert genug, um das Problem zu beheben. Der Unterschied besteht darin, dass die Ursache des Problems darin liegen kann, dass ein Bericht ohne Edges generiert wird, was ebenfalls zu einer Zeitüberschreitung des Berichts ohne Fehlererklärung führen kann.

  • Behobenes Problem 83694: Wenn sich ein Benutzer bei der lokalen Benutzeroberfläche eines VMware SD-WAN Edge anmeldet, erfasst der VMware SASE Orchestrator diese Aktion nicht und zeigt diese Aktion nicht unter „Überwachen (Monitor) > Ereignisse (Events)“ an.

    Die Kundenadministratoren hätten keine Kenntnis von lokalen Benutzeranmeldungen bei der lokalen Benutzeroberfläche eines Edge.

  • Behobenes Problem 84064: Kunden, die einen Microsoft Azure Virtual Hub bereitstellen, haben die Möglichkeit, BGP auf dem VMware SASE Orchestrator zu konfigurieren.

    BGP wird auf „Microsoft Azure Virtual Hub“ nicht offiziell unterstützt, da es automatisiert ist. Sollte ein Benutzer die Azure-Automatisierung mit BGP konfigurieren, gehen die Tunnel zum Gateway hinunter und die Azure-Site leitet den Datenverkehr nicht weiter.


  • Behobenes Problem 88811: Auf einem VMware SASE Orchestrator mit Version 5.0.x kann ein Operator-Superuser keine API-Tokens für Kundenbenutzer erstellen, obwohl er über delegierte Berechtigungen verfügt.

    Dieses Problem wird dadurch verursacht, dass die Operator-Superuse nicht über das Recht „CREATE ENTERPRISE_API_TOKEN“ verfügt. Infolgedessen kann der Operator keine API-Token für andere Benutzer erstellen, lesen oder widerrufen.

  • Behobenes Problem 88845: Wenn ein Benutzer versucht, Schnittstellen aus einer Unternehmens-VLAN-Liste zu entfernen und Änderungen auf einem VMware SASE Orchestrator mit der klassischen Benutzeroberfläche speichert, werden die Schnittstellen vom Orchestrator nicht entfernt.

    Während des Speicherns der Änderungen dieser Aktion ignoriert der Orchestrator die Konfigurationsänderung, da das json-Datenformat nicht mit dem Datenformat der klassischen Benutzeroberfläche übereinstimmt.

  • Behobenes Problem 88910: Auf einem VMware SASE Orchestrator mit Version 4.5.1 oder 5.0.x kann ein Benutzer keinen WAN-Link-Geschwindigkeitstest für einen VMware SD-WAN Edge über „Remote-Diagnose (Remote Diagnostics) > WAN-Link-Geschwindigkeitstest (WAN Link Speed Test)“ durchführen.

    Beim Versuch, die Diagnose „WAN-Link- Geschwindigkeitstest (WAN Link Speed Test)“ zu verwenden, kann der Benutzer keine Schnittstelle für den Geschwindigkeitstest auswählen, da kein Dropdown-Menü für die Schnittstellen vorhanden ist.

    Wenn ein Benutzer bei einem Orchestrator ohne Fix für dieses Problem einen Bandbreitentest für einen WAN-Link erzwingen möchte, kann der Benutzer als Problemumgehung die Bandbreitenmessmethode für diesen WAN-Link ändern, was automatisch einen erneuten Test auslöst. Dazu kann folgendermaßen vorgegangen werden:

    1. Gehen Sie auf der Orchestrator-Benutzeroberfläche für einen bestimmten Edge zu Konfigurieren (Configure) > Gerät (Device) und scrollen Sie nach unten zu WAN-Einstellungen (WAN Settings).

    2. Zum erneuten Testen des WAN-Links wählen Sie Bearbeiten (Edit) für den neu zu überarbeitenden Link aus, und wählen Sie dann Erweitert (Advanced) aus, um zusätzliche Einstellungen anzuzeigen.

    3. Ändern Sie im Menü Bandbreitenmessung (Bandwidth Measurement) die Methode zur Bandbreitenmessung von der aktuellen in eine andere Methode (wenn der Link z. B. den Burst-Modus verwendet, wechseln Sie zu „Langsamer Start (Slow Start)“ oder umgekehrt), und klicken Sie oben auf der Seite „Gerät (Device)“ auf Link aktualisieren (Update Link) und dann auf Änderungen speichern (Save Changes).

    4. Sobald eine Messung auf dem WAN-Link durchgeführt wurde, ändern Sie die Messmethode zurück in die ursprüngliche Methode, um die genaueste Messung für den jeweiligen WAN-Link sicherzustellen. Dadurch wird ein zusätzlicher Bandbreitentest ausgelöst.

  • Behobenes Problem 88998: Ein Benutzer kann auf einem VMware SASE Orchestrator der Version 5.0.x mit der klassischen Benutzeroberfläche keine Business Policy oder Firewallregel klonen.

    In der Version 5.0.x der klassischen Benutzeroberfläche des Orchestrators wurden die Optionen IPv6 und Gemischt (IPv4 und IPv6) für die Edge-Business-Policy-Regel deaktiviert. Die Benutzer konnten sie jedoch beim Klonen bereits vorhandener Regeln verwenden, was aber zu einer Fehlermeldung führte.

    Dieses Problem tritt in der neuen Benutzeroberfläche des Orchestrators nicht auf, und ein Benutzer kann dieses Problem mit der neuen Benutzeroberfläche umgehen.

  • Behobenes Problem 91231: Bei einem VMware SASE Orchestrator, der mit einer Notfallwiederherstellungstopologie (Disaster Recovery) bereitgestellt wird, kann die anfängliche Einrichtung der Notfallwiederherstellung fehlschlagen, wenn während der Importphase der großen Tabelle des Notfallwiederherstellungsprozesses ein Auftrag zur Kürzung der großen Tabelle ausgelöst wird.

    Wenn der Hintergrundimport von Statistiken mehr als 24 Stunden dauert, kollidiert er mit den automatischen Kürzungsaufträgen, die täglich ausgeführt werden. Der Auftrag schneidet die alten Partitionen von großen Tabellen ab, die auch auf dem MySQL-Standby-Server repliziert werden.

    Zwischen diesen Prozessen kann es jedoch vorkommen, dass MySQL einen Datenimport für dieselbe Tabelle durchführt, was dazu führt, dass die Replizierung fehlschlägt und damit auch der gesamte DR-Prozess.

    Sollte dieses Problem bei einem Orchestrator ohne den Fix auftreten, kann der DR-Prozess erst dann gestartet werden, wenn in UTC der Tag gewechselt hat. Dies ist jedoch keine Garantie für die Vermeidung von Fehlern, wenn der Orchestrator groß ist und der DR-Prozess über 24 Stunden in Anspruch nehmen kann.

  • Behobenes Problem 93846: Wenn ein Benutzer für Partner und Operatoren, die die Edge-Bestandsliste mithilfe von ZTP verwalten, versucht, einen VMware SD-WAN Edge einem anderen Kunden neu zuzuweisen, der zuvor einem Kunden zugewiesen und dann gelöscht wurde, gibt der VMware SASE Orchestrator den Fehler „Edge wurde nicht gefunden (Edge is not found)“ zurück.

    Der Orchestrator stellt fest, dass der Edge nicht vorhanden ist, da der logische Edge nicht angezeigt wird, nachdem er aus einem Kundenunternehmen gelöscht wurde und ein Benutzer ihn nicht einem anderen Kunden neu zuweisen kann.

Bekannte Probleme

Bekannte Probleme bei Edge/Gateway

Bestehende Probleme in Version 5.1.0.

  • Problem 105933: Ein Benutzer kann keine SSH-Verbindung zu den VMware SD-WAN Edge-Modellen 610/610-LTE oder 520/540 über eine geroutete Schnittstelle herstellen.

    Es gibt keine Verwerfungsregel für doppelte SSH-Pakete, die über einen vom Betriebssystem des betroffenen Edge verwendeten af-pkt-Treiber stammen. Aus diesem Grund empfängt der Edge-Kernel zwei SSH-Pakete: eines über die vce1-Schnittstelle und ein weiteres direktes SSH-Paket aufgrund der Art des Treibers. Der Edge-Kernel wird veranlasst, auf zwei SSH-Anfragen zu antworten, wodurch der SSH-Client verwirrt wird und es zum Scheitern von SSH kommt.

    Problemumgehung: Bei einem Edge, bei dem dieses Problem nicht behoben wurde, kann der Benutzer eine IP-Tabellenregel hinzufügen, um die von anderen Schnittstellen als vce1 empfangenen SSH-Pakete zu verwerfen.

  • Problem 115136: Ein Kunde kann einen allmählichen Anstieg der Arbeitsspeichernutzung auf einem VMware SD-WAN Edge in einem Kundenunternehmen beobachten, das BGP für das Routing verwendet.

    Der BGP-Daemon des Edge verursacht über mehrere Tage hinweg einen allmählichen Speicherverlust auf dem Edge und kann dies auch dann tun, wenn BGP für diesen Edge nicht konfiguriert ist. Wenn der Speicherverlust so lange anhält, dass die Speichernutzung des Edge den kritischen Schwellenwert von 60 % des verfügbaren Arbeitsspeichers länger als 90 Sekunden überschreitet, startet der Edge seinen Dienst defensiv neu, um den Speicherverlust zu beseitigen, was zu einer Unterbrechung des Kundendatenverkehrs für 10-15 Sekunden führen kann.

    Problemumgehung: Die einzige Möglichkeit zur Behebung des Problems ohne Edge-Fix besteht darin, den BGP-Prozess neu zu starten, indem er beendet wird, oder präventiv ein HA-Failover/einen Neustart des Edge-Diensts in einem geeigneten Dienstfenster durchzuführen.

  • Problem 117037: Bei Kunden, die eine Hub/Spoke-Topologie verwenden, bei der mehrere WAN-Links zum Senden und Empfangen von Datenverkehr vom Spoke Edge zum Hub Edge verwendet werden, kann die Leistung für Datenverkehr, der durch Business Policies gesteuert wird, geringer als erwartet ausfallen, da die WAN-Links die Bandbreite der WAN-Links nicht aggregieren.

    SD-WAN verwendet einen Zähler für die Anzahl der Pakete, die in einer Warteschlange für die erneute Sequenzierung zwischengespeichert werden. Dieser Zähler wird pro Peer verwaltet und dient dazu, sicherzustellen, dass nur 4K-Pakete pro Peer gepuffert werden. Unter bestimmten Bedingungen kann dieser Indikator negativ werden. Vor Version 4.2.x wurde, wenn dieser Zähler negativ wurde, der entsprechende Zähler sofort wieder auf 0 zurückgesetzt, nachdem die Pakete in der Warteschlange für die erneute Sequenzierung geleert wurden. Ab Version 4.3.x wird dieser Zähler jedoch automatisch aktualisiert, um sicherzustellen, dass der Zähler innerhalb der erwarteten Grenzen bleibt.

    Das Ergebnis dieser Verhaltensänderung kann dazu führen, dass die Zählerabrechnung nicht korrekt ist und die Warteschlange für die erneute Sequenzierung auf einer sehr hohen Zahl verbleibt, worauf SD-WAN mit dem Leeren jedes einzelnen Pakets reagiert. Diese Maßnahme verhindert nicht nur die Bandbreitenaggregation, sondern kann auch die Effektivität von Datenströmen verringern, die sonst über eine einzige Verbindung laufen würden.

    Problemumgehung: Bei Edges ohne Fix für dieses Problem besteht die Abhilfe darin, Business Policies zu konfigurieren, die übereinstimmenden Datenverkehr auf einen einzigen obligatorischen Link lenken.

Bekannte Probleme bei Orchestrator

check-circle-line exclamation-circle-line close-line
Scroll to top icon