Versionshinweise zu VMware SASE 5.2.0

VMware SASE 5.2.0 | 23. Dezember 2023 VMware SASE™ Orchestrator Version R5204-20230831-GA VMware SD-WAN™ Gateway-Version R5202-20230725-GA VMware SD-WAN™ Edge-Version R5202-20231107-GA-125647 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
• Kompatibilität
• Upgrade-Pfade für Orchestrator, Gateway und Edge
• Neue SD-WAN-Funktionen
• Neue SD-WAN-Verbesserungen
• Wichtige Hinweise
• Verfügbare Sprachen
• Änderungen an der Orchestrator-API
• Dokumentierter Revisionsverlauf

Empfohlene Verwendung

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

Kompatibilität

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

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

Orchestrator	Gateway	Edge
		Hub	Zweigstelle/Spoke
5.2.0	4.2.1	4.2.2	4.2.2
5.2.0	5.2.0	4.2.2	4.2.2
5.2.0	5.2.0	5.2.0	4.2.2
5.2.0	5.2.0	4.2.2	5.2.0
5.2.0	4.3.1	4.3.1	4.3.1
5.2.0	5.2.0	4.3.1	4.3.1
5.2.0	5.2.0	5.2.0	4.3.1
5.2.0	5.2.0	4.3.1	5.2.0
5.2.0	4.3.2	4.3.2	4.3.2
5.2.0	5.2.0	4.3.2	4.3.2
5.2.0	5.2.0	5.2.0	4.3.2
5.2.0	5.2.0	4.3.2	5.2.0
5.2.0	4.5.1	4.5.1	4.5.1
5.2.0	5.2.0	4.5.1	4.5.1
5.2.0	5.2.0	5.2.0	4.5.1
5.2.0	5.2.0	4.5.1	5.2.0
5.2.0	5.0.1.2	5.0.1.2	5.0.1.2
5.2.0	5.2.0	5.0.1.2	5.0.1.2
5.2.0	5.2.0	5.2.0	5.0.1.2
5.2.0	5.2.0	5.0.1.2	5.2.0
5.2.0	5.1.0	5.1.0	5.1.0
5.2.0	5.2.0	5.1.0	5.1.0
5.2.0	5.2.0	5.2.0	5.1.0
5.2.0	5.2.0	5.1.0	5.2.0
5.2.0	5.2.0	5.2.0	5.2.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.

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

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.2.0 durchführen möchten.

Orchestrator

Orchestrator-Instanzen mit Version 4.2.0 oder höher können auf Version 5.2.0 aktualisiert werden. 

Gateway

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

Wichtig:

Wenn Sie ein neues Gateway mit Version 5.2.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.2.0 oder höher auszuführen, fehlschlägt.

Wichtig:

Vor dem Upgrade eines Gateways auf Version 5.2.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.2.0 oder höher auszuführen, fehlschlägt.

Edge

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

Neue SD-WAN-Funktionen

Anpassbare QoE (Quality of Experience) für Latenz

Bisher waren die Latenzwerte für Verbindungen mit hoher Latenz (z. B. Satelliten- oder LTE-Verbindungen) statisch. Aus diesem Grund wurde auf der QoE-Seite ein rotes Diagramm für die Latenz und die Gesamtqualität angezeigt, was bedeutete, dass diese Verbindung vom SD-WAN-Dienst aus der Verbindungsauswahl ausgeschlossen wurde, obwohl Partner und Kunden die Verbindung mit hoher Latenz berücksichtigen wollten.

In Version 5.2.0 können Benutzer die Schwellenwerte für die Latenz für Video-, Sprach- und Transaktionsdatenverkehr über die Funktion Anpassbare QoE (Customizable QoE) ändern. Dies bedeutet, dass Kunden Verbindungen mit hoher Latenz im Rahmen des Auswahlvorgangs einbeziehen können und der Orchestrator die neuen Werte auf die Seite „QoE-Überwachung (QoE Monitoring)“ anwendet.

Unternehmenssteuerung für die Sichtbarkeit getrennter Verbindungen (Link Down Visibility) auf der Seite „Überwachen (Monitor)“ > „Netzwerkübersicht (Network Overview)“

Bisher hatte ein Kunde keine Kontrolle darüber, wie lange eine getrennte WAN-Verbindung vom Orchestrator auf der Seite Überwachen (Monitor) > Netzwerkübersicht (Network Overview) angezeigt wird. Wenn eine WAN-Verbindung 24 Stunden oder länger ausfiel, zeigte der Orchestrator diese WAN-Verbindung nicht mehr an, d. h., die Verbindung war über die Dauer des Ausfalls nicht sichtbar. Mit Version 5.2.0 kann ein Kunde eine angepasste Zeiteinstellung von bis zu 365 aufeinanderfolgenden Tagen konfigurieren, bevor der Orchestrator eine getrennte WAN-Verbindung nicht mehr anzeigt. Ein Kunde konfiguriert diese Einstellung mit Diensteinstellungen (Service Settings) > Edge-Verwaltung (Edge Management) > Grenzwert für Edge-Downlink (Edge Link Down Limit).

GRE-/BGP-Unterstützung für die LAN-Schnittstelle

Edges in einer Transit-VPC (Virtual Private Cloud) können GRE (Generic Routing Encapsulation)-/BGP- und Connect-Anhänge verwenden, um eine Verbindung mit einem AWS Transit Gateway (TGW) herzustellen. Der Connect-Anhang und der Connect-Peer werden beide über einen VPC-Anhang an ein TGW eingerichtet. GRE verwendet eine private IP, die auf einer gerouteten LAN-Schnittstelle (nicht WAN) zugewiesen wird, und zwei BGP-Nachbarn, die über den GRE-Tunnel eingerichtet werden.

Routen-Aggregierung

Die Routen-Aggregierung (auch Supernetting genannt) berücksichtigt die Skalierungseinschränkungen von SD-WAN-Geräten durch Minimieren der Anzahl an Routen, die ein Router für einen Nachbarn ankündigt, indem die ausgewählten Routenpräfixe zu einer einzelnen Routenankündigung zusammengefasst werden.

Bei Verwendung von BGP konfiguriert der Kunde diese Funktion unter Erweiterte Einstellungen (Advanced Settings). Bei Verwendung von OSPF konfiguriert der Kunde die Routen-Aggregierung auf der Hauptkonfigurationsseite.

Hinweis:

Der Orchestrator sowie die Gateways und Edges müssen alle auf Version 5.2.0 oder höher aktualisiert werden, um die Funktion Routen-Aggregierung (Route Summarization) verwenden zu können.

Selbstreparierendes Routing

In großen datencenter-basierten Bereitstellungen mit Hubs und Clustern besteht die Möglichkeit von Datenverkehrsausfällen wegen fehlender Routen. Vor Version 5.2.0 hätte VMware Engineering oder der Support diese fehlenden Routen durch eine störende Aktion wiederherstellen müssen. In VMware SD-WAN wird die Funktion „Selbstreparierendes Routing (Self Healing Routing)“ eingeführt, um das Risiko fehlender Routen in Datencenter-Bereitstellungen aufgrund von Synchronisierungsproblemen zu reduzieren.

Selbstreparierendes Routing wird als Überwachungsmechanismus implementiert, bei dem das Gateway die Routenanzahl auf Spoke-Edges mit den Edges im Hub-/Cluster-Datencenter vergleicht und automatisch eine Neusynchronisierung von Routen auslöst, wenn der Unterschied zwischen den Spokes und den Datencenter-Sites einen Standardschwellenwert überschreitet. Diese Funktion wird für alle 5.2.0-Implementierungen (Orchestrator, Gateway und Edge mit 5.2.0) automatisch implementiert, und es ist keine Konfiguration erforderlich.

Automatischer SIM-Switchover

Trotz der DSSS-Unterstützung (Dual SIM Single Standby) durch den Edge 610-LTE musste der Kunde mithilfe des Orchestrator manuell von der aktiven SIM zur Standby-SIM wechseln. In Version 5.2.0 kann der Kunde Automatischer Switchover (Automatic Switchover) für einen Edge 610-LTE benutzen.

Wenn ein Kunde automatisches Switchover konfiguriert, erkennt der Edge 610-LTE automatisch, ob die primäre LTE-Verbindung ausgefallen ist, und initiiert eine Verbindung mit der Standby-SIM. Die Funktion enthält einen konfigurierbaren Switchover-Timer, mit dem ein Kunde angeben kann, wie lange der Edge warten soll, bevor ein Failover an die Standby-SIM erfolgt. Auf der Seite Überwachen (Monitor) > Edges > Übersicht (Overview) > Verbindungsstatus (Link Status) wird eine neue Spalte vom Typ Automatische Dualmodus-SIM (Auto Dual-Mode SIM) mit Details zum SIM-Switchover hinzugefügt.

Hinweis:

Automatischer Switchover ist nur für Edge 610-LTE-Modelle verfügbar. Für Edge 510-LTE-Modelle steht diese Funktion nicht zur Verfügung.

Trusted Platform Module (TPM)

Beim Trusted Platform Module (TPM) handelt es sich um eine hardwarebasierte Sicherheitsfunktion. die einen sicheren Speicherbereich für vertrauliche Informationen wie Verschlüsselungsschlüssel, Passwörter und Zertifikate mit einer physischen Schutzebene über einen unidirektionalen „Hardware-Tresor“ bereitstellt.

VMware enthält das TPM für alle Varianten (LTE, -N usw.) der SD-WAN-Hardware-Edges (510, 520, 540, 610, 620, 640, 680, 3000, 3100, 3400 und 3800). Ein Kunde aktiviert die Funktion über die Orchestrator-Benutzeroberfläche, indem er zu Konfigurieren (Configure) > Edges > Übersicht (Overview) navigiert und das Kontrollkästchen für Geheime Geräteschlüssel verschlüsseln (Encrypt Device Secrets) aktiviert.

Hinweis:

Virtuelle Edges werden von TPM derzeit nicht unterstützt.

WLAN-Zugriffssteuerung mithilfe von MAC-Filterung

Ein Kunde kann die WLAN-Zugriffssteuerung als zusätzliche Sicherheitsschicht für drahtlose Netzwerke verwenden. Wenn diese Option aktiviert ist, lässt SD-WAN nur bekannte und genehmigte MAC-Adressen für die Verknüpfung mit der Basisstation zu.

Neue SD-WAN-Verbesserungen

BGP-Gateway-Nachbar-Status

Bisher hat der Orchestrator den Status der BGP-Nachbarschaft nicht genau gekennzeichnet, wenn der Edge aufgrund eines Stromausfalls offline geschaltet wurde, da weiterhin der ältere Status verwendet wurde. In Version 5.2.0 kennzeichnet der Orchestrator den Status der BGP-Nachbarschaft in diesem Szenario korrekt als „NICHT VERFÜGBAR (UNAVAILABLE)“.

Erweiterte Firewalldienste

Bei dem neuen erweiterten Firewalldienst handelt es sich um eine erweiterte Firewallfunktion, die in den SD-WAN Edge integriert ist. VMware wurde entwickelt, um die Zweigstellennetzwerke einer Organisation vor modernen und komplexen Cyberbedrohungen zu schützen und somit die Sicherheit zu erhöhen. Ein Kunde kann den erweiterten Firewalldienst über eine Add-On-Lizenz für VMware SD-WAN abrufen und wird auf allen SD-WAN-Edge-Modellen (Hardware und virtuell) unterstützt.

Die erste Version des erweiterten Firewalldiensts in Version 5.2.0 bietet folgende Funktionen:

• Das System zur Erkennung von Eindringversuchen/System zur Abwehr von Eindringversuchen basiert auf den preisgekrönten VMware NSX Security-Komponenten und bietet Unterstützung für verschlüsselten und unverschlüsselten Datenverkehr. Durch die Kombination der Leistungsfähigkeit von NSX Security mit den VMware SD-WAN Edge-Plattformen können Kunden Legacy-Firewalls in den Zweigstellen ohne Sicherheitseinbußen entfernen und von vereinfachten Netzwerk- und Sicherheitsabläufen profitieren, während sie gleichzeitig die Vorteile der VMware-Aktivitäten im Rahmen der Threat Intelligence nutzen.

• Protokollierung der gehosteten VMware Edge-Firewall bietet einen gehosteten Protokollspeicher zum Erfassen von Firewall- und Bedrohungsprotokollen (Zulassungs- und Ablehnungsregeln) aus Edges. In der ersten Orchestrator-Version in 5.2.0 werden Protokolle in einem Umfang von 15 GB oder Protokolle in einem Zeitraum von sieben Tagen (je nachdem, welcher Fall zuerst eintritt) pro Kundenmandant standardmäßig beibehalten. Nach Überschreitung von 15 GB oder Ablauf von sieben Tagen werden die Protokolle gelöscht. Dieser Dienst befindet sich im Lieferumfang einer gültigen VMware SD-WAN-Lizenz. In einer künftigen Version wird die Option zum Kauf einer verlängerten Protokollaufbewahrung hinzugefügt.

Externe Zertifizierungsstelle

In Phase 3 der Implementierung der externen Zertifizierungsstelle bietet die Orchestrator-Benutzeroberfläche von Version 5.2.0 Unterstützung für die Konfiguration einer Zwischenzertifizierungsstelle.

Firewallprotokolle auf dem Orchestrator

Bisher konnte ein Kunde Firewallprotokolle nur speichern und anzeigen, indem er sie an einen Syslog-Server weiterleitete. Mit Version 5.2.0 hat der Kunde die Möglichkeit, Firewallprotokolle auf dem Orchestrator zu speichern, wo sie auf der Orchestrator-Benutzeroberfläche angezeigt, sortiert und durchsucht werden können. Weitere Informationen finden Sie unter Konfigurieren einer Profilfirewall, Konfigurieren der Edge-Firewall und Überwachen von Firewallprotokollen.

Verbesserungen bei der Hochverfügbarkeit

Version 5.2.0 enthält mehrere Verbesserungen für eine Site, die unter Verwendung einer Hochverfügbarkeitstopologie mit einem Edge-Paar bereitgestellt wird. Dazu gehören:

• Verbesserte HA-Stabilität, um sicherzustellen, dass auf einer HA-Site weniger unnötige Failover oder Aktiv/Aktiv-Split-Brain-Zustände vorkommen.

• Ereignisse

  • Neue Ereignisse, die für Änderungen am WAN-, LAN- und HA-Verbindungsstatus erzeugt werden.

  • Der Nutzen von Ereignissen wird durch zusätzliche Metadaten wie Seriennummer und HA-Modus erhöht.

• Überwachung

  • Die Registerkarte HA-Standby (HA Standby) fungiert als neues Dashboard für den Standby-Edge zum Melden der CPU- und Arbeitsspeichernutzung und befindet sich auf der Seite Überwachen (Monitor) > Edges.

  • Für alle Dashboards auf der Seite Überwachen (Monitor) > Edges stehen jetzt „Failover-Balken“ zur Verfügung. Hierbei handelt es sich um vertikale Marker in Diagrammen, die angeben, wo und wann ein HA-Failover aufgetreten ist.

  • Alle Diagramme auf der Seite Überwachen (Monitor) > Edges enthalten ein Feld mit der Seriennummer des HA-Edge. Auf diese Weise kann ein Kunde auf einen Blick feststellen, welcher HA-Edge während eines bestimmten Zeitraums in einem Überwachungsdiagramm aktiv war.

• Neue Konfigurationsoptionen für Hochverfügbarkeit

  • Multiplikator der HA-Failover-Erkennungszeit wird verwendet, um einen höheren Hochverfügbarkeitsschwellenwert festzulegen. Mit dem Timer wird angegeben, wie lange ein Standby-Edge auf ein Taktsignalpaket vom aktiven Edge wartet, bis er aktiv wird. In bestimmten Szenarien kann somit ein Aktiv/Aktiv-Split-Brain-Zustand für einen HA-Edge unter hoher Datenverkehrslast verhindert werden.

  • Konfigurierbare HA-Schnittstelle ermöglicht dem Kunden, jeden Edge-Switch-Port für die Verwendung als HA-Schnittstelle zu konfigurieren (die Schnittstelle, die die aktiven und Standby-Edges für die Synchronisierung verbindet). Bisher beschränkte SD-WAN die HA-Schnittstelle auf eine Standardschnittstelle für dieses Edge-Modell (d. h. LAN1 oder GE1).

  • Eine zusätzliche Verbesserung der konfigurierbaren HA-Schnittstelle besteht darin, dass der Kunde einen 1G/10G-SFP-Port als HA-Schnittstelle auswählen kann.

• Paketerfassung für die HA-Schnittstelle des Standby-Edge: Ein Administrator verfügt jetzt über ein zusätzliches Tool zur HA-Fehlerbehebung mit der Option, eine Paketerfassung für die HA-Schnittstelle des Standby-Edge anzufordern.

Unterstützung des HA-Upgrades für Plattform-Firmware oder Factory-Image

Bisher war das Upgrade der Plattform-Firmware oder des Factory-Images für eine HA-Site eine zeitaufwändige und störende Aufgabe, die vom Benutzer manuell durchgeführt werden musste. Wenn ein Operator-Profil auf eine HA-Site mit einer neuen Plattform-Firmware oder einem neuen Factory-Image angewendet wird, kann ein Orchestrator der Version 5.2.0 das Factory-Image und die Plattform-Firmware automatisch auf Hochverfügbarkeit für SD-WAN Edges aktualisieren, so wie es zuvor für die HA-Edge-Software der Fall war.

IPv6 – Verbesserungen

Version 5.2.0 enthält die folgenden Verbesserungen für IPv6:

• OSPFv3

  • Routenlernen für Underlay-IPv6.

  • Neuverteilung von OSPFv3-Routen in Overlay/BGP und umgekehrt.

  • Unterstützung für Overlay-Flow-Steuerung (Overlay Flow Control, OFC).

  • Eine vollständige Suite von OSPFv3-Remote-Diagnosen.

• Unterstützung für DHCPv6-Relay-Agent auf Edge

  • Anwendungsfälle für lokale/Remote-/Cloud-DHCP-Server

  • Fungiert als mehrere Relay-Agenten

• Nicht-SD-WAN-IPv6-Ziele über Edge

  • Unterstützte Szenarien bei Tunnel-Failover:

    • Aktiv/Aktiv

    • Aktiv/Standby

    • Aktiv/Hot-Standby

  • Flow-basierte Linkauswahl.

  • Die Orchestrator-Benutzeroberfläche umfasst Tunnelüberwachung, Ereignisse und Warnungen.

RADIUS-MAC-Adressen-Umgehung (MAC Address Bypass, MAB) für 802.1x in VLANs

In Version 5.1.0 wurde die RADIUS-MAB für 802.1x eingeführt, jedoch nur für geroutete Schnittstellen. In Version 5.2.0 können Kunden diese Funktion auch für VLANs verwenden, die dem geswitchten Port eines Edge zugewiesen werden können.

Hinweis:

Die MAB-Funktion weist die folgenden Einschränkungen auf, wenn sie für ein VLAN zur Verwendung auf einem geswitchten Port konfiguriert ist:

• L2-Datenverkehr löst keine RADIUS-MAB aus.

• L2-Datenverkehr wird auf Linux-basierten Switches erst weitergeleitet, wenn gerouteter Datenverkehr erkannt wird. Hardware-Switches filtern bereits keinen reinen L2-Datenverkehr. Diese Einschränkung bleibt unverändert.

• Wenn kein gerouteter Datenverkehr beobachtet wird und bei der RADIUS-MAB eine Zeitüberschreitung auftritt (Standardwert ist 30 Minuten), wird der L2-Datenverkehr erneut blockiert.

• Zusätzliche Hooks zum Überprüfen des 802.1x-Status für selbstbestimmte Pakete können zu Leistungsbeeinträchtigungen führen, wenn 802.1x aktiviert ist.

• Selbstbestimmter, vollständig von Linux verwalteter Datenverkehr wird vor der 802.1x-Authentifizierung (DHCP, DNS, SSH usw.) nicht mehr gefiltert.

Verbesserungen der Routensichtbarkeit für die Gateways

Diese Verbesserungen berücksichtigen das Bedürfnis von Kunden und Partnern nach größerem Einblick in die Routing-Tabelle eines Gateways und umfassen Folgendes:

• Die Registerkarte Gateway-Routentabelle (Gateway Route Table) auf der Seite Überwachen (Monitor) > Routing des Orchestrators.

• Die Registerkarte BGP-Gateway-Nachbar-Status (BGP Gateway Neighbor State) auf der Seite Überwachen (Monitor) > Routing zur Anzeige angekündigter BGP-Routen und empfangener Routen pro Nachbar.

• Vollständige Informationen für ein bestimmtes Routenpräfix.

• Filter auf Basis eines Routenpräfixes.

• Die Option zum Exportieren der Gateway-Routentabelle.

Trusted Platform Module (TPM)

Beim Trusted Platform Module (TPM) handelt es sich um eine hardwarebasierte Sicherheitsfunktion. die einen sicheren Speicherbereich für vertrauliche Informationen wie Verschlüsselungsschlüssel, Passwörter und Zertifikate mit einer physischen Schutzebene über einen unidirektionalen „Hardware-Tresor“ bereitstellt.

VMware SD-WAN enthält das TPM für alle Varianten (LTE, -N usw.) der SD-WAN-Hardware-Edges (510, 520, 540, 610, 620, 640, 680, 3000, 3100, 3400 und 3800). Ein Kunde aktiviert die Funktion über die Orchestrator-Benutzeroberfläche, indem er zu Konfigurieren (Configure) > Edges > Übersicht (Overview) navigiert und das Kontrollkästchen für Geheime Geräteschlüssel verschlüsseln (Encrypt Device Secrets) aktiviert.

Hinweis:

Virtuelle Edges werden in dieser Version von TPM nicht unterstützt.

Wichtige Hinweise

UI-Build

Ab Version 5.2.0.4 führt VMware den Orchestrator-UI-Build ein. Ein UI-Build enthält nur Fixes für Benutzeroberflächenprobleme, d. h. Probleme, die sich auf die Verwendung der Benutzeroberfläche von Orchestrator auswirken. Ein UI-Build enthält keine Fixes für Probleme mit der Verwaltungs-/Steuerungsebene, die sich auf die zugrunde liegende Funktionalität des Orchestrators auswirken, wie dies bei einem Standard-Orchestrator-Build der Fall wäre.

Ein UI-Build wird zu einer vorhandenen Orchestrator-Version hinzugefügt und zeichnet sich durch eine eindeutige Build-Version aus, die unter dem Namen des Orchestrator-Builds aufgeführt ist. Der UI-Build kann auf die gleiche Weise gefunden werden, wie ein Benutzer die Orchestrator-Version identifiziert, d. h. durch Klicken auf das Symbol ? in der oberen rechten Ecke des Bildschirms der Orchestrator-Benutzeroberfläche. Wenn beispielsweise eine Orchestrator-Instanz, auf der die Version 5.2.0.4 mit dem Build R5204-20230831-GA ausgeführt wird, mit der UI-Build-Version R5204-20230914-GA aktualisiert wird, wird diese direkt unter dem Orchestrator-Build mit dem Namen „UI Build“ angezeigt. Wenn eine Orchestrator-Instanz über keinen UI-Build verfügt, sieht ein Benutzer nur einen Orchestrator-Build.

Das Upgrade von Orchestrator-Instanzen auf einen UI-Build wird wie folgt durchgeführt:

• Das VMware Operations-Team führt sowohl für gehostete gemeinsam genutzte Orchestrator-Instanzen als auch für gehostete private Orchestrator-Instanzen innerhalb einer Woche nach Veröffentlichung des Builds ein Upgrade auf den neuesten UI-Build durch, wenn der Orchestrator bereits die neueste Orchestrator-Version verwendet.

• Ein Partner, der eine dedizierte Orchestrator-Instanz verwendet, muss ein Ticket beim Support eröffnen, damit das Operations Team seine Orchestrator-Instanz mit einem UI-Build aktualisiert, vorausgesetzt, er verwendet die neueste Orchestrator-Version.

Hinweis:

Für Kunden, die eine lokale Orchestrator-Instanz verwenden, sind UI-Builds nicht verfügbar.

Weitere Informationen zum UI-Build finden Sie in den KB-Artikeln VMware SD-WAN Software Upgrade FAQs (67152) und VMware SD-WAN Software Release Types and Software Upgrade Strategy for Orchestrators and Gateways (89609).

Änderung des LAN-seitigen NAT-Verhaltens

Wenn eine LAN-seitige NAT für Viele-zu-eins-Übersetzungen mithilfe von Port Address Translation (PAT) konfiguriert ist, kann der von der entgegengesetzten Richtung initiierte Datenverkehr einen unerwarteten Zugriff auf feste Adressen ermöglichen, die auf der äußeren Maske und der ursprünglichen IP-Adresse basieren. Dieses neue Verhalten gilt für Ziel-NAT (DNAT), Quell-NAT (SNAT) und Quell- und Ziel-NAT (S+D-NAT).

Eine SNAT-Regel mit einem inneren Netzwerk von 192.168.1.0/24 und einer äußeren Adresse von 10.1.1.100/32 lässt zum Beispiel die Übersetzung von außen nach innen zu 192.168.1.100 zu.

Um diesem neuen Verhalten entgegenzuwirken, blockiert SD-WAN jetzt den Datenverkehr, wenn eine Verbindung in umgekehrter PAT-Richtung initiiert wird.

Um das ursprüngliche Verhalten wiederherzustellen, muss ein Benutzer zwei Regeln des gleichen Typs wie die ursprüngliche Regel (SNAT, DNAT, S+D NAT) in einer bestimmten Reihenfolge konfigurieren. Wenn ein Benutzer beispielsweise das frühere SNAT-Szenario verwendet, muss er Folgendes konfigurieren:

1. SNAT-Regel mit einem inneren Netzwerk von 192.168.1.100/32 und einer äußeren Adresse von 10.1.1.100/32

2. SNAT-Regel mit einem inneren Netzwerk von 192.168.1.0/24 und einer äußeren Adresse von 10.1.1.100/32

Wenn es sich bei der ursprünglichen Regel um eine DNAT- oder S+D-NAT handelt, benötigt der Benutzer zwei DNAT- oder S+D-NAT-Regeln mit derselben Struktur und Reihenfolge.

Ab Version 4.5.0 kann ein Benutzer in den dispcnt-Protokollen eines Diagnosepakets nach dem Zähler lan_side_nat_reverse_pat_drop suchen, um festzustellen, ob Flows für diese Art von Datenverkehr verworfen werden.

Die klassische Benutzeroberfläche ist auf dem SASE Orchestrator veraltet

In Version 5.2.0 ist die neue Benutzeroberfläche jetzt für alle Konfigurations- und Überwachungsaufgaben abgeschlossen. Folglich wird die klassische Benutzeroberfläche standardmäßig ausgeblendet und kann nicht mehr verwendet werden. Darüber hinaus werden vom SASE Engineering keine Probleme mehr behoben, die für die klassische Benutzeroberfläche spezifisch sind.

Greenfield-Direktkunden auf einem gehosteten Orchestrator werden der Cloud Services Platform (CSP) automatisch als Identitätsanbieter zugewiesen

Greenfield-Direktkunden, die keinem Partner zugewiesen sind und auf einem gehosteten Orchestrator der Version 5.2.0 erstellt wurden, werden automatisch für SSO mit CSP als Identitätsanbieter konfiguriert. Ergebnis:

• Neue Administratoren werden von einem Administrator mit einer Superuser-Rolle über das CSP-Portal erstellt.

• Bei einem CSP-Ausfall wird dem Kunden ein Administratorkonto für den Notfallzugriff (Break Glass Account) mit lokaler Authentifizierung (Benutzername/Kennwort) gewährt, damit er auf sein Portal zugreifen kann.

• Neue Direktkunden müssen tokenbasierte Authentifizierung für den API-Zugriff verwenden. Cookiebasierte Authentifizierung kann nicht verwendet werden, da die Benutzererstellung an CSP übergeben wird.

Hinweis:

Lokale Orchestrator-Instanzen unterliegen nicht den CSP-Anforderungen, und ihre Kunden verwenden weiterhin Orchestrator-basierte Authentifizierung.

Früher Zugriff bleibt für Hub- oder Cluster-Interconnect erhalten

Hub- oder Cluster-Interconnect wurde in Version 5.1.0 mit folgender Einschränkung eingeführt:

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 Früher Zugriff (Early Access) frei und wird Bereitstellungen, in denen sie aktiviert ist, genau auf unerwartetes Routing-Verhalten überwachen.

Die Einschränkung bleibt für diese Funktion in Version 5.2.0 bestehen.

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.2.0 ist in den folgenden 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.1.0

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

In der API v1 wurden ab 5.1.0 bis 5.2.0 keine Änderungen vorgenommen. Zu Referenzzwecken steht das vollständige API-Änderungsprotokoll unter developer.vmware.com zum Download zur Verfügung (siehe „VMware SD-WAN Orchestrator API v1“).

Änderungen an der VMware SASE Orchestrator-API v2

Diese Version bietet Unterstützung für die Konfiguration von QoS-Modulen (Quality of Service) auf Profil- und Edge-Ebene. APIs für die Rückgabe der Firewallstatistiken und NNI-Metriken werden für diese Version ebenfalls hinzugefügt.

Version 5.2.0 enthält die folgenden neuen API-Vorgänge:

• QOS-Modul auf Profil- und Edge-Ebene

  • GET /api/sdwan/v2/enterprises/{enterpriseLogicalId}/profiles/{profileLogicalId}/qos

  • PUT /api/sdwan/v2/enterprises/{enterpriseLogicalId}/profiles/{profileLogicalId}/qos

  • PATCH /api/sdwan/v2/enterprises/{enterpriseLogicalId}/profiles/{profileLogicalId}/qos

  • GET /api/sdwan/v2/enterprises/{enterpriseLogicalId}/edges/{edgeLogicalId}/qos

  • POST /api/sdwan/v2/enterprises/{enterpriseLogicalId}/edges/{edgeLogicalId}/qos

  • PUT /api/sdwan/v2/enterprises/{enterpriseLogicalId}/edges/{edgeLogicalId}/qos

  • PATCH /api/sdwan/v2/enterprises/{enterpriseLogicalId}/edges/{edgeLogicalId}/qos

• Erweiterte Firewallstatistiken auf Enterprise- und Edge-Ebene

  • GET /api/sdwan/v2/enterprises/{enterpriseLogicalId}/firewallIdpsStats

  • GET /api/sdwan/v2/enterprises/{enterpriseLogicalId}/edges/{edgeLogicalId}/firewallIdpsStats

  • GET /api/sdwan/v2/enterprises/{enterpriseLogicalId}/edges/{edgeLogicalId}/firewallIdpsStats/timeSeries

• NNI-Metriken des Gateways auf Unternehmensebene

  • GET /api/sdwan/v2/enterprises/{enterpriseLogicalId}/nniStats

  • GET /api/sdwan/v2/enterprises/{enterpriseLogicalId}/nniStats/timeSeries

Entwicklerdokumentation

Die gesamte VMware SASE-/SD-WAN-API-Dokumentation befindet sich im Dokumentationsportal für Entwickler unter https://developer.vmware.com/apis.

Dokumentierter Revisionsverlauf

22. Dezember 2023. 26. Auflage.

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

18. Dezember 2023. 25. Auflage.

• Die behobenen Probleme #93141 und #95565 wurden zum Abschnitt Behobene Probleme bei Edge/Gateway für den ursprünglichen Edge/Gateway-Build, R5200-20230530-GA, hinzugefügt. Diese Probleme wurden in den Versionshinweisen in der ersten Auflage versehentlich ausgelassen.

• Offene Probleme #118501, #122193, #129232, #129412, #129662, #129958, #131299, #133201, und #133642 wurden zum Abschnitt Bekannte Probleme bei Orchestrator hinzugefügt.

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

4. Dezember 2023. 24. Auflage.

• Der neue Orchestrator-Benutzeroberflächen-Build R5204-20231201-GA wurde zum Abschnitt Behobene Probleme bei Orchestrator für R5204-20230831-GA hinzugefügt. Dies ist der zwölfte UI-Build für Orchestrator-Rollup-Build R5204-20230831-GA.

• UI-Build R5204-20231201-GA enthält Fixes für die Benutzeroberflächenprobleme #126695, #128921, #129662, #131224, #131631, #132047, #132384 und #133008, die jeweils in einer separaten Tabelle im Abschnitt R5204-20230831-GA dokumentiert sind.

• Behobenes Problem 83166 wurde entfernt. Dieses lautete wie folgt: „Wenn ein VMware SD-WAN Gateway mit einem AWS c5.4xlarge-Instanztyp aus dem AWS-Portal mit ausgewählter IPv6-Option neu bereitgestellt wird, sind weder IPv6 noch die Standardrouten konfiguriert, und die AWS-Gateway-IPv6-Verwaltungstunnel werden nicht gebildet.“ Dieses Problem wird nicht behoben. Stattdessen wird in der Benutzerdokumentation die Anforderung hinzugefügt, nur den statischen Modus der IPv4/IPv6-Adresszuweisung auf Schnittstellen für ein Gateway zu verwenden, da VMware SD-WAN DHCP auf der Gateway-Seite nicht unterstützt.

22. November 2023. 23. Auflage. R5204-20231201-GA

• Der neue Orchestrator-Benutzeroberflächen-Build R5204-20231121-GA wurde zum Abschnitt Behobene Probleme bei Orchestrator (Orchestrator Resolved Issues) für R5204-20230831-GA hinzugefügt. Dies ist der elfte UI-Build für Orchestrator-Rollup-Build R5204-20230831-GA.

• UI-Build R5204-20231121-GA enthält Fixes für die Benutzeroberflächenprobleme #128017, #129695, #130810, #131138 und #132524 die jeweils in einer separaten Tabelle im Abschnitt R5204-20230831-GA dokumentiert sind.

Hinweis:

Problem #131118 wurde zuvor als behobener UI-Build R5204-20231109-GA aufgelistet. Das Problem wurde dort jedoch nicht vollständig behoben und wurde nur mit diesem Build vollständig behoben.

• Die behobenen Probleme #104513 und #106331 wurden zum Abschnitt Behobene Probleme bei Edge/Gateway für den ursprünglichen Edge/Gateway-Build, R5200-20230530-GA, hinzugefügt. Diese Probleme wurden in den Versionshinweisen in der ersten Auflage versehentlich ausgelassen.

16. November 2023. 22. Auflage.

• Der neue Orchestrator-UI-Build R5204-20231115-GA wurde zum Abschnitt Behobene Probleme bei Orchestrator (Orchestrator Resolved Issues) für R5204-20230831-GA hinzugefügt. Dies ist der zehnte UI-Build für Orchestrator-Rollup-Build R5204-20230831-GA.

• UI-Build R5204-20231115-GA enthält Fixes für die Benutzeroberflächenprobleme #123078, #123718, #128330, #128765 und #130877, die jeweils in einer separaten Tabelle im Abschnitt R5204-20230831-GA dokumentiert sind.

14. November 2023. 21. Auflage.

• Ein aktualisierter Edge-Rollup-Build R5202-20231107-GA-125647 wurde zum Abschnitt „Behobene Probleme bei Edge/Gateway“ hinzugefügt. Dies ist eine Aktualisierung des zweiten Edge-Rollup-Builds R5202-20230725-GA und ist der neue Standard Edge-/Gateway-GA-Build für Version 5.2.0.

• Edge-Build R5202-20231107-GA-125647 enthält den Fix für Problem #125647, der in diesem Abschnitt dokumentiert ist.

Wichtig:

• Alle früheren Edge-Builds der Version 5.2.0 sind zugunsten von R5202-20231107-GA-125647 veraltet.

• Kunden, die ein Upgrade auf Version 5.2.0 durchführen, sollten nur ein Upgrade auf R5202-20231107-GA-125647 durchführen.

• Kunden, die bereits erfolgreich einen 5.2.0.x-Edge-Build verwenden, müssen ihre Edges nicht auf R5202-20231107-GA-125647 aktualisieren.

10. November 2023. Zwanzigste Auflage.

• Der neue Orchestrator-UI-Build R5204-20231109-GA wurde zum Abschnitt Behobene Probleme bei Orchestrator (Orchestrator Resolved Issues) für R5204-20230831-GA hinzugefügt. Dies ist der neunte UI-Build für Orchestrator Rollup-Build R5204-20230831-GA.

• UI-Build R5204-20231109-GA enthält Fixes für die Benutzeroberflächenprobleme #123387, #123640, #127727, #129584, #130153 und #131138, die jeweils in einer separaten Tabelle im Abschnitt R5204-20230831-GA dokumentiert sind.

2. November 2023. 19. Auflage.

• Der neue Orchestrator-UI-Build R5204-20231101-GA wurde zum Abschnitt Behobene Probleme bei Orchestrator (Orchestrator Resolved Issues) für R5204-20230831-GA hinzugefügt. Dies ist der achte UI-Build für Orchestrator-Rollup-Build R5204-20230831-GA.

• UI-Build R5204-20231101-GA enthält Fixes für die Benutzeroberflächenprobleme 123001, 127904, 128753, 129061, 129494, 129662, 129765, und 129894, die jeweils in einer separaten Tabelle im Abschnitt R5204-20230831-GA dokumentiert sind.

31. Oktober 2023. Achtzehnte Auflage.

• Der Wortlaut für Behobenes Problem 110484 im Abschnitt „Behobene Probleme bei Edge/Gateway (Edge/Gateway Resolved Issues)“ wurde überarbeitet, um deutlich zu machen, dass die für das Ticket aufgelisteten Symptome durch dieses Ticket nicht behoben werden. Stattdessen enthält die Edge-Software eine verbesserte Protokollierung, um die Techniker bei der Bereitstellung eines tatsächlichen Fixes für die aufgelisteten Symptome zu unterstützen.

27. Oktober 2023. Siebzehnte Auflage.

• Der neue Orchestrator-UI-Build R5204-20231027-GA wurde zum Abschnitt Behobene Probleme bei Orchestrator (Orchestrator Resolved Issues) für R5204-20230831-GA hinzugefügt. Dies ist der siebte UI-Build für Orchestrator-Rollup-Build R5204-20230831-GA.

• UI-Build R5204-20231027-GA enthält Fixes für die Benutzeroberflächenprobleme 125964, 126602, 127904, 128279, 128357, 129413, und 129926, die jeweils in einer separaten Tabelle im Abschnitt R5204-20230831-GA dokumentiert sind.

20. Oktober 2023. Sechzehnte Auflage.

• Der neue Orchestrator-UI-Build R5204-20231019-GA wurde zum Abschnitt Behobene Probleme bei Orchestrator für R5204-20230831-GA hinzugefügt. Dies ist der sechste UI-Build für Orchestrator-Rollup-Build R5204-20230831-GA.

• UI-Build R5204-20231019-GA enthält Fixes für die Benutzeroberflächenprobleme 127021, 128706, 129049, 129271, und 129560, die jeweils in einer separaten Tabelle im Abschnitt R5204-20230831-GA dokumentiert sind.

• Das offene Problem 125421 wurde zum Abschnitt Bekannte Probleme bei Edge/Gateway (Edge/Gateway Known Issues) hinzugefügt.

• Das behobene Problem 110406 wurde zum Abschnitt Behobene Probleme bei Edge/Gateway (Edge/Gateway Resolved Issues) für den ursprünglichen Edge/Gateway-Build R5200-20230530-GA hinzugefügt. Dieses Problem wurde in der ersten Auflage der Versionshinweise versehentlich ausgelassen.

• Ein neuer Hinweis wurde zu Änderung des LAN-seitigen NAT-Verhaltens (LAN-Side NAT Behavioral Change) im Abschnitt Wichtige Hinweise (Important Notes) hinzugefügt.

13. Oktober 2023. Fünfzehnte Auflage.

• Der neue Orchestrator-UI-Build R5204-20231013-0631-GA wurde zum Abschnitt Behobene Probleme bei Orchestrator für R5204-20230831-GA hinzugefügt. Dies ist der fünfte UI-Build für Orchestrator-Rollup-Build R5204-20230831-GA.

• UI-Build R5204-20231013-0631-GA enthält Fixes für die Benutzeroberflächenprobleme #120419, #127035, #127636, #127774, #128371, #128620 und #129253, die jeweils in einer separaten Tabelle im Abschnitt R5204-20230831-GA dokumentiert sind.

• Die offenen Probleme aus #125647 wurden zum Abschnitt Bekannte Probleme bei Edge/Gateway hinzugefügt.

4. Oktober 2023. Vierzehnte Auflage.

• Der neue Orchestrator-UI-Build R5204-20231003-GA wurde zum Abschnitt Behobene Probleme bei Orchestrator für R5204-20230831-GA hinzugefügt. Dies ist der vierte UI-Build für Orchestrator-Rollup-Build R5204-20230831-GA.

• UI-Build R5204-20231003-GA enthält Fixes für die Benutzeroberflächenprobleme #117923, #123070, #127037, #128628 und #128667, die jeweils in einer separaten Tabelle im Abschnitt R5204-20230831-GA dokumentiert sind.

28. September 2023. Dreizehnte Auflage.

• Der neue Orchestrator-UI-Build R5204-20230927-GA wurde zum Abschnitt Behobene Probleme bei Orchestrator für R5204-20230831-GA hinzugefügt. Dies ist der dritte UI-Build für Orchestrator-Rollup-Build R5204-20230831-GA.

• UI-Build R5204-20230927-GA enthält Fixes für die Benutzeroberflächenprobleme #126967, #127006, #127843, #127849, #127871 und #128277, die jeweils in einer separaten Tabelle im Abschnitt R5204-20230831-GA dokumentiert sind.

• Die folgenden Tickets wurden zum Abschnitt „Bekannte Probleme bei Orchestrator“ hinzugefügt: #125082, #125504, #125663, #126257, #126421, #126425, #126465, #126695, #127037, #127152, #127636 und #128070.

• Das behobene Problem #110484 wurde zum Abschnitt Behobene Probleme bei Edge/Gateway für den ursprünglichen Edge/Gateway-Build, R5200-20230530-GA, hinzugefügt. Dieses Problem wurde in der ersten Auflage der Versionshinweise versehentlich ausgelassen.

21. September 2023. Zwölfte Auflage.

• Der neue Orchestrator-UI-Build R5204-20230920-GA wurde zum Abschnitt Behobene Probleme bei Orchestrator für R5204-20230831-GA hinzugefügt. Dies ist der zweite UI-Build für Orchestrator-Rollup-Build R5204-20230831-GA.

• UI-Build R5204-20230920-GA enthält Fixes für die Benutzeroberflächenprobleme #106191, #113254, #117941, #117993, #121469, #126503 und #126257, die jeweils in einer separaten Tabelle im Abschnitt R5204-20230831-GA dokumentiert sind.

• Der Eintrag Wichtige Hinweise, UI-Build wurde überarbeitet, um Informationen darüber hinzuzufügen, wie ein UI-Build zu den vier jeweiligen Orchestrator-Typen hinzugefügt wird: Gehostet gemeinsam genutzt, Privat gemeinsam genutzt, Dediziert und Lokal. Dieser Eintrag enthält den Hinweis, dass UI-Builds für Kunden, die lokale Orchestrator-Instanzen verwenden, nicht verfügbar sind.

15. September 2023. Elfte Auflage.

• Neue Wichtige Hinweise mit dem Titel UI-Build wurden hinzugefügt. Der UI-Build ist eine neue Art von Orchestrator-Softwareversion, die nur Fixes für Probleme mit der Benutzeroberfläche enthält und zu einer vorhandenen Orchestrator-Version hinzugefügt wird.

• Der neue Orchestrator-UI-Build R5204-20230914-GA wurde zum Abschnitt Behobene Probleme bei Orchestrator für R5204-20230831-GA hinzugefügt. Dies ist der erste UI-Build für Orchestrator-Rollup-Build R5204-20230831-GA.

• UI-Build R5204-20230914-GA enthält Fixes für die Benutzeroberflächenprobleme #108125, #122918, #123619, #123927, #124801, #125309, #125393, #125710, #126403 und #127007, die jeweils in einer separaten Tabelle im Abschnitt R5204-20230831-GA dokumentiert sind.

1. September 2023. Zehnte Auflage.

• Der neue Orchestrator-Rollup-Build R5204-20230831-GA wurde zum Abschnitt Behobene Probleme bei Orchestrator hinzugefügt. Dies ist der dritte Orchestrator-Rollup-Build und der neue Standard-Orchestrator-GA-Build für Version 5.2.0.

• Orchestrator-Build R5204-20230831-GA enthält Fixes für die Probleme #65668, #104775, #118728, #120398, #121118, #121526, #122113, #123002, #123053, #123150, #123346, #123551, #123749, #124073, #124129, #124273, #124315, #124778, #124798, und #125456, die jeweils in diesem Abschnitt dokumentiert sind.

• Die offenen Probleme#117037 und #121606 wurden zum Abschnitt Bekannte Probleme bei Edge/Gateway hinzugefügt.

• Das offene Problem #62701 wurde aus dem Abschnitt Bekannte Probleme bei Edge/Gateway entfernt, da es in Version 5.1.0 behoben wurde.

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

9. August 2023. Neunte Auflage.

• Der neue Orchestrator-Rollup-Build R5203-20230809-GA wurde zum Abschnitt Behobene Probleme bei Orchestrator hinzugefügt. Dies ist der dritte Orchestrator-Rollup-Build und der neue Standard-Orchestrator-GA-Build für Version 5.2.0.

• Orchestrator-Build R5203-20230809-GA enthält Fixes für die Probleme #121118, #121884, #122132, #122797, #123384 und #123609, die jeweils in diesem Abschnitt dokumentiert sind.

• Das behobene Problem #105861 wurde zum Abschnitt Behobene Probleme bei Orchestrator für den ursprünglichen Orchestrator-BuildR5200-20230530-GA hinzugefügt. Dieses Problem wurde in der ersten Auflage der Versionshinweise versehentlich ausgelassen.

• Es wurde ein Abschnitt Verfügbare Sprachen hinzugefügt, um zu verdeutlichen, in welchen Sprachen VMware SASE 5.2.0 Orchestrator lokalisiert ist.

2. August 2023. Achte Auflage.

• Der neue Orchestrator-Rollup-Build R5202-20230729-GA wurde zum Abschnitt Behobene Probleme bei Orchestrator hinzugefügt. Dies ist der zweite Orchestrator-Rollup-Build und der neue Standard-Orchestrator-GA-Build für Version 5.2.0.

• Orchestrator-Build R5202-20230729-GA enthält Fixes für die Probleme #116666, #117772, #117822, #118544, #118733, #120070, #120606, #120774, #121441, #121472, #121751, #121835, #121858, #121993, #122010, #122271, #122520, #122866 und #122977, die jeweils in diesem Abschnitt dokumentiert sind.

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

31. Juli 2023. Siebte Auflage.

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

  Edge/Gateway-Build R5202-20230725-GA enthält Fixes für die Probleme #106865, #117775 und #121368, die jeweils in diesem Abschnitt dokumentiert sind.

• Das behobene Problem #82095 wurde als offenes Problem eingestuft und in den Abschnitt Bekannte Probleme bei Orchestrator verschoben.

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

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

12. Juli 2023. Sechste Auflage.

• Die behobenen Probleme #86994, #90044, #98223, #101753, #105433, #110456, #106123 und #116086 wurden dem Abschnitt Behobene Probleme bei Edge und GatewayR5200-20230530-GA hinzugefügt. Diese Probleme wurden in den Versionshinweisen in der ersten Auflage versehentlich ausgelassen.

• Das behobene Problem #114546 wurde zum Abschnitt Behobene Probleme bei Orchestrator für den ursprünglichen Orchestrator-BuildR5200-20230530-GA hinzugefügt. Dieses Problem wurde in der ersten Auflage der Versionshinweise versehentlich ausgelassen.

5. Juli 2023. Fünfte Auflage.

• Firewallprotokolle wurden auf dem Orchestrator zur Liste der neuen SD-WAN-Verbesserungen hinzugefügt. Diese Erweiterung wurde in der ersten Ausgabe der Versionshinweise irrtümlich ausgelassen.

• Behobenes Problem #107317 wurde zum Abschnitt „Behobene Probleme bei Edge/Gateway“ für den ursprünglichen GA-Build hinzugefügt.

26. Juni 2023. Vierte Auflage.

• Der neue Orchestrator-Rollup-Build R5201-20230623-GA wurde zum Abschnitt „Behobene Probleme bei Orchestrator“ hinzugefügt. Dies ist der erste Orchestrator-Rollup-Build und der neue Standard-Orchestrator-GA-Build für Version 5.2.0.

• Der Orchestrator-Build R5201-20230623-GA enthält Fixes für die Probleme #112333, #113254, #115411, #115624, #116141, #116790, #117527, #117800, #117993, #118071, #118574, #118673, #119551 und #119733, die jeweils in diesem Abschnitt dokumentiert sind.

Wichtig:

Denjenigen, die einen 5.2.0.0-Build für ihren lokalen Orchestrator verwenden, wird dringend empfohlen, ihren Orchestrator auf 5.2.0.1 zu aktualisieren.

22. Juni 2023. Dritte Auflage.

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

• Edge-/Gateway-Build R5201-20230619-GA enthält Fixes für die Probleme #115150 und #117638, die jeweils in diesem Abschnitt dokumentiert sind.

Wichtig:

Denjenigen, die einen 5.2.0.0-Build für den Edge oder das Gateway verwenden, wird dringend empfohlen, ihre Edges und/oder Gateways auf 5.2.0.1 zu aktualisieren.

7. Juni 2023. Zweite Auflage.

• Die behobenen Probleme #105933 und #109963 wurden dem Abschnitt Behobene Probleme bei Edge und Gateway für den ursprünglichen Edge-Build, R5200-20230530-GA, hinzugefügt. Diese Probleme wurden in den Versionshinweisen in der ersten Auflage versehentlich ausgelassen.

31. Mai 2023. Erste Auflage.

Behobene Probleme bei Edge und Gateway

• Behoben in Edge-Version R5202-20231107-GA-125647
• Behoben in Edge-/Gateway-Version R5202-20230725-GA
• Behoben in Edge-/Gateway-Version R5201-20230619-GA
• Behoben in Edge-/Gateway-Version R5200-20230530-GA

Behoben in Edge-Version R5202-20231107-GA-125647

Edge-Build R5202-20231107-GA-125647 wurde am 13.11.2023 veröffentlicht und ist ein Update des zweiten Edge-Rollups für Version 5.2.0.

Dieser aktualisierte Edge-Build behebt ein kritisches Problem seit dem ursprünglichen zweiten Edge-Rollup, R5202-20230725-GA.

Wichtig:

• Alle früheren Edge-Builds der Version 5.2.0 sind zugunsten von R5202-20231107-GA-125647 veraltet.

• Kunden, die ein Upgrade auf Version 5.2.0 durchführen, sollten nur ein Upgrade auf R5202-20231107-GA-125647 durchführen.

• Kunden, die bereits erfolgreich einen 5.2.0.x-Edge-Build verwenden, müssen ihre Edges nicht auf R5202-20231107-GA-125647 aktualisieren.

• Behobenes Problem 125647: Wenn bei einer Site, die mit einem Edge-Modell 520 oder 540 bereitgestellt wird, ein Edge auf eine 5.2.0-Version aktualisiert wird, kann bei Clientbenutzern, die über einen LAN-Port mit dem Edge verbunden sind, ein vollständiger Verlust der Konnektivität auftreten.

  Durch einen Neustart des Edge 520/540 wird das Problem nicht behoben und es wird auch kein Downgrade des Edge auf eine ältere Softwareversion durchgeführt, nachdem er auf Version 5.2.0 aktualisiert wurde. Wenn die Konsole des Edge in den Einstellungen Edge-Sicherheit (Edge Security) > Konsolenzugriff (Console Access) auf der Konfigurationsseite Firewall des Orchestrators deaktiviert ist (dies ist die Standardkonfiguration für jeden Edge), wird der Treiber, der LAN1 bis LAN8-Ports des Edge 520 oder 540 verwaltet, nicht ordnungsgemäß konfiguriert. Dies führt dazu, dass diese Ports überhaupt nicht erstellt werden.

  Auf einem Edge ohne Fix für dieses Problem können Sie das Auftreten dieses Problems verhindern und/oder die Konnektivität der LAN-Ports auf einem betroffenen Edge wiederherstellen, indem Sie wie folgt vorgehen: Navigieren Sie zu Konfigurieren (Configure) > Edge/Profil (Edge/Profil) > Firewall > Edge-Sicherheit (Edge Security) und klicken Sie unter Konsolenzugriff (Console Access) auf Aktivieren (Enable) und Änderungen speichern (Save Changes).

  

  Hinweis:

  Das Ändern dieser Konfiguration erfordert einen Edge-Neustart, der ca. 2–3 Minuten in Anspruch nimmt. Führen Sie diese Änderung nach Möglichkeit in einem Wartungsfenster durch.

Behoben in Edge-/Gateway-Version R5202-20230725-GA

Edge- und Gateway-Build R5202-20230725-GA wurde am 31.7.2023 veröffentlicht und ist der zweite Edge-/Gateway-Rollup für Version 5.2.0.

Dieser Edge-/Gateway-Rollup-Build behebt die folgenden kritischen Probleme ab dem ersten Edge-/Gateway-Rollup-Build (R5201-20230619-GA).

• Behobenes Problem 106865: Kunden, die den Edge Network Intelligence-Dienst nutzen und die Analyse für ihr Unternehmen aktiviert haben, stellen möglicherweise fest, dass Nicht-IP-Datenverkehr (z. B. RADIUS-Authentifizierung) unterbrochen wird.

  Wenn die Analyse aktiviert ist und Nicht-IP-Frames auf einer SD-WAN-Edge-Schnittstelle empfangen werden, kann der Edge diese fälschlicherweise als IPv4-Fragmente verarbeiten und ein Fragment-Datensatzleck verursachen. Im Laufe der Zeit kann dies dazu führen, dass die Verarbeitung von Fragmenten gestoppt wird und alle derartigen Pakete verworfen werden. Für Kunde, die RADIUS-Authentifizierung verwenden, kann dies dazu führen, dass die Authentifizierung für alle Edges gleichzeitig unterbrochen wird.

  In einem Unternehmen, das keinen festen Build verwendet, besteht die einzige Abhilfe darin, alle Edges neu zu starten.

• Behobenes Problem 117775: Ein Nicht-SD-WAN-Ziel über Gateway (NSD) kann zeitweise in einen Zustand geraten, in dem die IPsec-Tunnel ständig flattern (abgebaut und wieder aufgebaut werden).

  Der Kunde konnte beobachten, dass die Tunnel einige Sekunden lang hoch und dann einige Sekunden lang herunterfuhren und dann wieder hochfuhren, wobei sich dieser Zyklus wiederholte, bevor er von selbst aufhörte. Da es sich um ein zeitabhängiges Problem handelt, kann sich der Zyklus über Tage und möglicherweise unendlich wiederholen. Das Problem tritt aufgrund einer Wettlaufbedingung auf, wenn ein NSD-Tunnel mit einer großen Anzahl von IKE-Phase-2-Verbindungen aufgebaut wird und das Gateway versucht, Datenverkehr über eine dieser IKE-Phase-2-Verbindungen weiterzuleiten, bevor diese vollständig aufgebaut ist, was dazu führt, dass der gesamte Tunnel abgebaut und neu aufgebaut wird und sich der Zyklus wiederholt.

  Bei einer Site, die keine Gateways mit einer Lösung für dieses Problem verwendet: Da es sich um ein zeitabhängiges Problem handelt, sind die Möglichkeiten zur Umgehung begrenzt. Eine mögliche Umgehung besteht darin, die NSD-Tunnel in kleinen Stapeln zu konfigurieren, sodass sie schneller ausgehandelt werden und somit das Zeitfenster vermieden wird, in dem der Verkehr ankommt, bevor der Tunnel fertig ist.

• Behobenes Problem 121368: 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 wird durch Remotezugriffsbenutzer ausgelöst, die über das Gateway auf das Internet/die Cloud zugreifen. Wenn der Internet-/Cloud-Endpoint mit einem großen Paket antwortet, das eine Fragmentierung erfordert, schlägt der Gateway-Dienst beim Versuch, das Paket zu fragmentieren, fehl.

Behoben in Edge-/Gateway-Version R5201-20230619-GA

Edge-Build R5201-20230619-GA wurde am 22.06.2023 veröffentlicht und ist das erste Edge-Rollup für Version 5.2.0.

Dieser Edge-/Gateway-Rollup-Build behebt die folgenden kritischen Probleme seit dem ursprünglichen GA-Build R5200-20230530-GA.

Wichtig:

Denjenigen, die einen 5.2.0.0-Build für den Edge oder das Gateway verwenden, wird dringend empfohlen, ihre Edges und/oder Gateways auf 5.2.0.1 zu aktualisieren.

• Behobenes Problem 115150: Wenn ein Kunde entweder ein Nicht-SD-WAN-Ziel (NSD) oder einen Cloud-Security-Service (CSS) mit einem Zscaler-Typ einsetzt und die L7-Integritätsprüfung aktiviert ist, kann der Kunde feststellen, dass ein oder mehrere Tunnel aufgrund eines Fehlers bei der L7-Integritätsprüfung ausfallen.

  Dieses Problem kann sowohl bei den primären als auch bei den sekundären Tunneln auftreten. Wenn ein VMware SD-WAN Gateway mehrere L7-Integritätsprüfungen verwaltet, führt ein NAT-Leck, das durch die L7-Integritätsprüfungssonden verursacht wird, zu einem Ausfall des NSD/CSS-Tunnels, der ohne Neustart des Gateways nicht wiederhergestellt werden kann.

• Behobenes Problem 117638: Wenn ein Benutzer zu Monitor > Edge > Links navigiert und den Live-Modus für einen VMware SD-WAN Edge mit Version 5.2.0 aktiviert, liefert der SASE Orchestrator keine Echtzeitstatistiken.

  Außerdem sieht der Benutzer die Anzeige Waiting for Edge ... (Warten auf Edge), die schließlich abläuft. Das Problem wird auf dem Edge durch die Art und Weise verursacht, wie ein 5.2.0 Edge-Build LTE/USB-Verbindungsstatistiken beim Hochladen in den Orchestrator behandelt.

Behoben in Edge-/Gateway-Version R5200-20230530-GA

Edge- und Gateway-Build R5200-20230530-GA wurde am 31.05.2023 veröffentlicht und behebt die folgenden Probleme ab Edge- und Gateway-Build R5102-20230310-GA.

Hinweis:

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

• Behobenes Problem 48032: Die Lese- und Schreibstatistiken eines VMware SD-WAN Edge können bei einem Festplattenausfall nicht zu Analysezwecken nachverfolgt werden.

  Mithilfe einer aktuellen Methode kann die Menge an Schreibvorgängen nachverfolgt werden, die auf eine Festplatte in /velocloud/log geschrieben wird. Den Daten fehlt es jedoch an Granularität, da nur die Gesamtzahl der Daten und nicht die Anzahl der Schreibvorgänge nachverfolgt wird. Dieses Ticket fügt „Festplattenstatistiken (Disk Stats)“ unter der Remote-Diagnose „Systeminformationen (System Information)“ hinzu, sodass VMware Engineering im Fall eines festplattenbasierten Edge-RMA auf diese Statistiken zurückgreifen kann.

• Behobenes Problem 54573: Beim Ausführen eines Auszugs der Routentabelle wird in der Ausgabe unter Umständen ein falscher Metrikwert für bestimmte verbundene Routen angezeigt.

  Dieses Problem entsteht, weil der Edge-Dienst nicht die richtige Benachrichtigung für das Hinzufügen von Schnittstellenrouten vom Edge-Kernel erhält.

• Behobenes Problem 57170: In einem Kundenunternehmen, in dem BGP, private Links und ein Partner-Gateway verwendet werden, kann es zu einem Verbindungsausfall zwischen Clients hinter dem Partner-Gateway und dem Server hinter einem VMware SD-WAN Edge kommen.

  Der Internetdatenverkehr verwendet das MPLS-Netzwerk anstelle des NAT-Übergabevorgangs.

• Behobenes Problem 58244: Ein Kunde, der BGP und ein Partner-Gateway verwendet, beobachtet unter Umständen Verbindungsprobleme bei Datenverkehr über das PG.

  Das Problem entsteht dadurch, dass die PSBR-Route nicht installiert wurde. Dies kann beim Betrachten eines Auszugs der Routentabelle festgestellt werden. Die Ursache besteht darin, dass das Gateway entfernt und erneut hinzugefügt wurde. Routenereignisse wurden mit dem Fehler „Routenwarteschlange für Segment 1 nicht gefunden (Route queue not found for segment 1)“ verworfen.

• Behobenes Problem 68748: Wenn ein Clientgerät unter Windows mit einem VMware SD-WAN Edge verbunden ist, weist der Ereignisbericht für „Neues Clientgerät erkannt (New Device Seen)“ die falsche Betriebssystemversion auf.

  Da der Edge die Beschreibung in der Datei „dhcp_fingerprints.json“ kürzt, erhält der Kunde nicht das richtige Betriebssystem für das verbundene Clientgerät.

• 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 84235: Bei einem VMware SD-WAN Edge kann es zu einem Ausfall des Datenebene-Diensts und einem Neustart zur Wiederherstellung kommen.

  Wenn der Edge fragmentierte IKEv2-Pakete freigibt (im aktivierten PKI-Modus) und gleichzeitig ein Tunnel-Flap stattfindet, ist es in seltenen Fällen möglich, dass ein doppelt freier Zustand eintritt und eine Ausnahme beim Edge-Dienst auslöst, die den Ausfall und Neustart verursacht.

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

  Der Debugging-Befehl dispcnt liefert nicht alle Indikatorwerte und schlägt mit 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 dynamische 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.

  Ohne Fix für dieses Problem kann der Benutzer den Status nur löschen, indem er einen Dienstneustart des betroffenen Edge durchführt.

• Behobenes Problem 89332: Wenn das Verzeichnis /velocloud des VMware SD-WAN Edge voll oder nicht beschreibbar ist, wird der Kunde unter „Ereignisse (Events)“ nicht über diesen Zustand informiert.

  Der Kunde würde erst nach Tagen bemerken, dass der Edge keine weiteren Ereignisse gesendet hat. Ereignisse werden an den Orchestrator gemeldet, indem eine Datei in das Verzeichnis /velocloud geschrieben wird. Wenn das Verzeichnis voll ist oder ein Problem vorliegt, bei dem die Festplatte in den schreibgeschützten Modus wechselt, erhält weder der Kunde noch VMware Engineering bzw. der VMware Support Kenntnis darüber, da kein Ereignis oder Protokoll mit entsprechenden Warnungen vorhanden ist.

  Der Fix für dieses Problem fügt einen neuen Protokolleintrag hinzu, der in einen anderen Ordner geschrieben wird, um deutlich zu machen, was vor sich geht, und der in etwa folgendermaßen lautet:

  • edge:b1-edge1:~# cat /var/log/log_eventgen.log

  • 2023-05-19 13:03:46,628 Unable to create event save file: [Errno 30] Read-only file system: '/velocloud/events/client/event.1684501426626.mgp7kfvg'

  • 2023-05-19 13:03:46,634 events.EventPackage failure, queing to MGD

• 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 92142: Wenn ein Gerät hinter einem VMware SD-WAN Edge mit einem Gerät kommuniziert, das über eine geroutete Schnittstelle mit einem konfigurierten VLAN oder einer konfigurierten Teilschnittstelle direkt mit dem Edge verbunden ist, schlägt die Kommunikation unter Umständen fehl.

  Wenn NAT Direct auf einer gerouteten Schnittstelle konfiguriert ist, wird davon ausgegangen, dass der gesamte Datenverkehr, der direkt über diese Schnittstelle (auf dem Underlay) gesendet wird, mithilfe der IP-Adresse der gerouteten Schnittstelle per NAT geroutet wird. NAT wird jedoch nicht auf Datenverkehr zu und von anderen IP-Adressen im selben Subnetz wie die geroutete Schnittstelle angewendet, wenn die geroutete Schnittstelle eine Teilschnittstelle ist oder ein VLAN verwendet. Dieser Fehler tritt nicht auf, wenn das Ziel einen oder mehrere Hops entfernt ist, weil der Edge NAT Direct nicht erzwingt und der Datenverkehr funktioniert (siehe folgenden Hinweis zu den Auswirkungen, wenn ein Edge eine behobene Version verwendet).

  Hinweis:

  Es kann sein, dass NAT Direct in einer älteren Version des SASE Orchestrator versehentlich auf einer Hauptschnittstelle mit konfiguriertem VLAN oder konfigurierter Teilschnittstelle konfiguriert wurde. Wenn diese Schnittstelle einen oder mehrere Hops entfernt direkten Datenverkehr sendet, stellt der Kunde kein Problem fest, da die Einstellung NAT Direct nicht angewendet wurde. Wenn ein Edge jedoch auf Version 5.2.0 und höher mit einem Fix für dieses Problem aktualisiert wird, ändert sich das Routing-Verhalten, da dieser spezifische Anwendungsfall in früheren Versionen nicht implementiert wurde.

  Anders ausgedrückt bedeutet dies: Da ein 5.2.0-Edge NAT Direct jetzt in der erwarteten Weise für alle Anwendungsfälle implementiert, kann zuvor funktionsfähiger Datenverkehr (weil NAT Direct aufgrund des Fehlers nicht angewendet wurde) nun fehlschlagen, weil dem Kunden nicht bekannt war, dass NAT Direct für eine Schnittstelle mit konfiguriertem VLAN oder konfigurierter Teilschnittstelle aktiviert wurde.

  Folglich sollte ein Kunde, der den Edge auf Version 5.2.0 oder höher aktualisiert, zuerst die Schnittstelleneinstellungen für Profile und Edges überprüfen, um sicherzustellen, dass NAT Direct nur dort konfiguriert ist, wo es explizit erforderlich ist, und um diese Einstellung dort zu deaktivieren, wo dies nicht der Fall ist, insbesondere wenn für diese Schnittstelle ein VLAN oder eine Teilschnittstelle konfiguriert ist.

• Behobenes Problem 92927: Eine deaktivierte VMware SD-WAN Edge-Schnittstelle verfügt weiterhin über einen Link zu einem verbundenen Gerät.

  Wenn eine Schnittstelle zur Deaktivierung über den Orchestrator ausgewählt ist, wird sie aus dem DPDK-Steuerelement des Edge entfernt und der Kontrolle des Kernel-Treibers des Edge unterstellt. Das Skript, das diese Konvertierung vornimmt, richtet den Kernel-Administrator auf der Schnittstelle jedoch so ein, dass er bei verbundener Schnittstelle versucht, automatisch mit dem verbundenen Dienst zu verhandeln.

• Behobenes Problem 92400: An einem Kundenstandort mit konfigurierter Hochverfügbarkeitstopologie, auf der Edge-Schnittstellen mit Teilschnittstellen konfiguriert sind, dauert die Konvergierung des Standby-Edge nach einem HA-Failover länger.

  Weder Gratuitous ARP noch Nexthop ARP wird von der Teilschnittstelle gesendet, was zu einer Konvergenzzeit führt, die die erwarteten Subsekunden überschreitet. 

• Behobenes Problem 93141: Auf einer Site mit einer Hochverfügbarkeitstopologie kann ein Kunde, der einen dem HA-Edge-Paar vorgeschalteten L2-Switch verwendet, in den Switch-Protokollen Hinweise auf eine L2-Datenverkehrsschleife feststellen, obwohl es keine tatsächliche Schleife gibt.

  Dies liegt daran, dass der HA-Edge das HA-Schnittstellentaktsignal mit der virtuellen MAC-Adresse an den Orchestrator sendet und nicht mit der tatsächlichen MAC-Adresse der Schnittstellen. Dies wird dadurch verursacht, dass der HA-Edge die virtuelle MAC-Adresse in seiner MAC-Datei speichert. Infolgedessen erkennt der verbundene L2-Switch den Datenverkehr mit derselben MAC-Quelle, der von zwei verschiedenen Edge-Schnittstellen kommt, und protokolliert ihn als L2-Schleife. Dieses Problem ist auf Protokollebene nur kosmetisch, da es keine tatsächliche L2-Schleife gibt und keine Unterbrechung des Kundendatenverkehrs oder ein Verlust des Kontakts mit dem Orchestrator aufgrund dieses Problems auftritt. Daher gibt es keine Auswirkungen auf den Kunden, und der Kunde kann L2-Schleifenerkennungsereignisse von Upstream-Switches ignorieren, die von der HA-Schnittstelle des Edge (normalerweise GE1) ausgehen.

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

  Beim Überprüfen eines Core-Fehlers wird festgestellt, dass der Edge-Dienst mit einem SIGXCPU-Signal beendet wurde. Das Edge-Betriebssystem verfügt über einen Unix-Socket, der als Warteschlange für die Kommunikation von Schnittstellenereignissen zwischen Threads verwendet wird. Das Problem wird dadurch verursacht, dass die Socket-Tiefe zu gering ist, was zu einer Thread-Blockierung und dem Senden des SIGXCPU-Signals führt.

• Behobenes Problem 95399: Wenn die geroutete Schnittstelle eines VMware SD-WAN Edge physisch angeschlossen oder getrennt ist, beobachtet der Benutzer auf dem VMware SASE Orchestrator weder das Ereignis „Edge-Schnittstelle aktiv (Edge Interface Up)“ noch das Ereignis „Edge-Schnittstelle inaktiv (Edge Interface Down)“.

  Das Problem wird auf den dhclient zurückgeführt, der zuerst zur Edge-Version 4.5.1 hinzugefügt wurde und in allen nachfolgenden Builds (5.0.x, 5.1.x) enthalten ist. Dhclient wurde nicht zum Senden von Ereignissen vom Typ „Schnittstelle aktiv (Interface Up)“ oder „Schnittstelle inaktiv (Interface Down)“ an den Orchestrator konfiguriert.

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

• Behobenes Problem 95950: Wenn ein Benutzer die Schnittstelleneinstellungen eines VMware SD-WAN Edge konfiguriert und 128 Segmente konfiguriert sind, kann der Edge einen Fehler beim Datenebene-Dienst aufweisen, einen Core-Fehler generieren und neu starten.

  Wenn der Edge mit 128 Segmenten konfiguriert ist, benötigt die Anwendung der iptable-Regel zu viel Zeit, um abgeschlossen zu werden, was zu einer Mutex-Überwachungsausnahme und einem Ausfall des Edge-Diensts führt.

• Behobenes Problem 95850: Wenn ein Benutzer in einem Kundenunternehmen, in dem OSPF verwendet wird, ein Diagnosepaket für einen VMware SD-WAN Edge erzeugt, können sich die OSPF-Routen während der Paketerstellung zeitweise schließen, was zu einer Unterbrechung des Kundendatenverkehrs führt.

  Im Rahmen der Diagnosepaketerstellung werden die Befehle vcdbgdump -r remote-routes und vcdbgdump -r remote_routes ausgeführt. Da die Ausführung dieser Befehle in einer Kundenumgebung länger als 40 Sekunden dauert, wurden die OSPF-Hellos, die in die Warteschlange für den Ereignis-Dispatcher-Thread gestellt wurden, nicht verarbeitet. Aus diesem Grund wird die OSPF-Nachbarschaft gestört, was zu einem Netzwerkausfall führt.

  Auf einem Edge ohne Fix für dieses Problem sollte ein Kunde ein Diagnosepaket lediglich in einem Wartungsfenster erstellen oder sich zu diesem Zweck an den VMware SD-WAN-Support wenden, da der Support über interne Tools verfügt, mit denen das Auftreten des Problems temporär verhindert werden kann.

• Behobenes Problem 96710: Bei einem Kundenstandort mit konfigurierter Hochverfügbarkeitstopologie und aktivierter LOS-Erkennung (Loss of Signal) für die HA-Edge-Schnittstellen erkennt der Standby-Edge die wiederherstellte Verbindung nicht, wenn die Verbindung auf den Schnittstellen des aktiven Edge unterbrochen, dieser in den Standby-Modus versetzt und die Schnittstellenkonnektivität später wiederhergestellt wird.

  Wenn ein Edge in den Standby-Modus wechselt, weil LOS auf einer aktiven Schnittstelle erkannt wurde, kann SD-WAN, selbst wenn die Verbindung auf dem Edge im Standby-Modus nach einiger Zeit wiederhergestellt wird, die wiederhergestellte Verbindung nicht erkennen, da auf dem Standby-Edge keine LOS-Überwachung durchgeführt werden kann. Die Schnittstelle wird gemäß dem letzten bekannten LOS-Status weiterhin als nicht verfügbar betrachtet.

  Auf einem HA-Edge ohne diesen Fix würde ein erzwungenes HA-Failover dazu führen, dass der Standby-Edge (der jetzt aktiv ist) die zugehörigen Schnittstellen per ARP auf wiederhergestellte Konnektivität überprüft.

• Behobenes Problem 97953: Ein Operator- oder Partnerbenutzer kann den ARP-Cache auf einem VMware SD-WAN Gateway nicht löschen.

  Auf Gateways mit Version 5.2.0 oder höher kann ein Benutzer den ARP-Cache mithilfe des Befehls debug.py --clear_arp_cache löschen.

• Behobenes Problem 98223: Wenn Edge Network Intelligence (Analyse) auf einem VMware SD-WAN Edge aktiviert ist, kann der Edge den Kontakt zum VMware SASE Orchestrator verlieren, was dazu führt, dass der Orchestrator den Edge in der Orchestrator-Benutzeroberfläche als ausgefallen markiert.

  Bei aktivierter Analyse wird die Edge-Kommunikation mit dem Analyse-Back-End manchmal mit der Edge-Kommunikation mit dem Orchestrator vermischt. Dies führt zu einem Verlust der Kommunikation mit dem Orchestrator, was dazu führt, dass der Orchestrator meldet, dass der Edge ausgefallen ist, obwohl dies nicht der Fall ist.

• Behobenes Problem 98359: Wenn ein Kunde die LOS-Erkennung (Loss of Signal) für eine Edge-Schnittstelle aktiviert, die auch eine Teilschnittstelle verwendet, erkennt LOS keine Verbindungsfehler auf der Teilschnittstelle.

  In früheren Versionen wird die LOS-Erkennung für Teilschnittstellen nicht unterstützt. Deshalb werden Verbindungsausfälle auf Teilschnittstellen nicht erkannt.

• Behobenes Problem 98634: Unter „Edge“ > „Überwachen (Monitor)“ > „Transport“ für einen Edge mit mehreren Links kann ein Benutzer eine Diskrepanz in den Link-Metriken zwischen den beiden Links feststellen.

  Dieses Problem ist auf die logische ID eines WAN-Links zurückzuführen, die über mehrere Edges hinweg dupliziert wird, was zu ungenauen Statistiken für diesen Link führt.

• Behobenes Problem 98694: Wenn ein Kundenunternehmen mit redundanten statischen Routen konfiguriert ist und die primäre Route ausfällt, werden die alternativen Routen nicht annonciert und der Datenverkehr wird verworfen.

  Wenn eine Schnittstelle auf einem VMware SD-WAN Edge ausfällt, werden dem VMware SD-WAN Gateway die alternativen Routen nicht angekündigt, obwohl die Routen über die Schnittstelle jetzt unerreichbar sind. Routen für das Präfix sind im Gateway nicht vorhanden, obwohl alternative Routen über andere Schnittstellen für diese Präfixe auf dem Edge vorhanden sind. Das Problem besteht darin, dass der SD-WAN-Dienst eine Routenlöschung sendet, ohne zu überprüfen, ob eine alternative erreichbare statische Route vorhanden ist, während er den Ausfall der Schnittstelle verarbeitet.

• Behobenes Problem 99193: Bei einem VMware SD-WAN Edge, der als Spoke-Edge konfiguriert ist und aktiv IPv6 verwendet, wird der für den Spoke-Edge bestimmte IPv6-Datenverkehr verworfen, wenn dieser Edge mit Version 5.x ausgeführt und auf Version 4.5.x oder früher herabgestuft wird. Wenn alternative IPv6-Routen vorhanden sind, nutzt der Datenverkehr diese nicht, sondern wird weiter zum herabgestuften Spoke-Edge geleitet, wo er verworfen wird. Dies hat Paketverluste zur Folge.

  Wenn ein Spoke-Edge von 5.x auf 4.5.x oder früher herabgestuft wird und ausfällt, entfernt der Hub-Edge die IPv6-Routen mit diesem Spoke-Edge als nächstem Hop aus der FIB (Forwarding Information Base), behält sie aber in der RIB (Routing Information Base) bei. Wenn der herabgestufte Spoke-Edge später aktiv wird, stellt der Hub die IPv6-Routen in der FIB wieder her, sodass der Datenverkehr für diese Präfixe an den Spoke-Edge weitergeleitet und dort verworfen wird. Dieses Problem bleibt bestehen, bis ein veralteter Aktualisierungs-Timer eingeschaltet wird, der die v6-Routen nach 5 Minuten löscht.

• Behobenes Problem 99215: Wenn der Benutzer die SFP1-Schnittstelle auf den VMware SD-WAN Edge-Modellen 610, 620, 640 und 680 deaktiviert oder als geswitchte Schnittstelle konfiguriert, empfängt die SFP2-Schnittstelle unter Umständen keine Pakete mehr.

  Bei diesen Edge-Modellen empfängt die SFP2-Schnittstelle unter Umständen keine Pakete mehr, wenn SFP1 als geroutet konfiguriert ist und der Benutzer SFP1 entweder deaktiviert oder als geswitchte Schnittstelle neu konfiguriert.

• Behobenes Problem 100010: Auf einem VMware SD-WAN Edge, der mit privaten WAN-Links bereitgestellt wird, die sowohl für IPv4 als auch für IPv6 konfiguriert sind, kann es zu einem Arbeitsspeicherverlust kommen, wenn ein Benutzer ein Diagnosepaket erzeugt oder die Remote-Diagnose „Pfade auflisten (List Paths)“ ausführt.

  Wenn der Datenverkehr über private Links ausgeführt wird, überprüft SD-WAN zuerst, ob die IPv4-Adresse konfiguriert ist. Wenn dies der Fall ist, wird der Wert in JSON gespeichert. Anschließend überprüft SD-WAN, ob die IPv6-Adresse konfiguriert ist. Bei vorhandener IPv6-Adresse überschreibt SD-WAN den zuvor gespeicherten Wert, bevor er an das JSON-Array angehängt wird, was zu einem Arbeitsspeicherverlust führt. Je größer die vom Edge verarbeitete Datenverkehrsmenge, desto höher der Arbeitsspeicherverlust, wenn die auslösenden Aktionen ausgeführt werden.

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

  Der Benutzer stößt auf dieses Problem, wenn er über das Gateway mit SSH eine Verbindung zu einem Edge herstellt und diese SSH-Sitzung eine Fehlermeldung vom Typ FRAG_NEEDED ICMP generiert. Da das Gateway das Paket über die lokale gwd1-Schnittstelle empfangen hat, ist pkt_in->skb->vc_sk->raw NULL und löst den Dienstausfall und Core-Fehler aus.

• Behobenes Problem 100237: In einem Kundenunternehmen, in dem ein Partner-Gateway verwendet wird und das PG eine sichere Standardroute zu einem VMware SD-WAN Gateway ankündigt, kann ein Client eine Datei unter Umständen nicht direkt aus dem Internet herunterladen.

  Das vollständige Szenario beinhaltet, dass der Edge mehrere WAN-Verbindungen verwendet, dass „Sicheres Überschreiben der Standardroute (Secure Default Route Override)“ konfiguriert und eine Business Policy erstellt wurde, bei der der Parameter „Netzwerkdienst (Network Service) auf „Direkt (Direct)“ festgelegt ist. In diesem Szenario kann der Datenverkehrsfluss, der diese Business Policy verwendet, jedes Mal eine andere WAN-IP-Adresse auswählen, weshalb ein Download fehlschlägt.

  Ohne einen Fix für dieses Problem muss der Benutzer die Business Policy so konfigurieren, dass der gesamte Datenverkehr auf einen WAN-Link beschränkt wird, indem er ihn als „Obligatorisch (Mandatory)“ markiert.

• Behobenes Problem 100359: Wenn ein ausgehender OSPFv2-Filter so konfiguriert ist, dass eine zusammenfassende Route verworfen wird, kündigt der Edge diese Routen weiterhin an.

  OSPFv2-Routen werden selbst nach der Konfiguration von „Ignorieren (Ignore)“ in „Routenankündigung (Route Advertisement)“ für OSPF unter einer bestimmten Schnittstelle angekündigt.

• Behobenes Problem 101102: Wenn ein VMware SD-WAN Edge, der zunächst einem gehosteten Gateway zugewiesen wurde, einem Partner-Gateway neu zugewiesen wird, funktioniert die SSH-Verbindung zum Edge über das Gateway nicht mehr.

  Wenn der Edge einem Partner-Gateway neu zugewiesen wird, verliert er die vce1-IP-Adresse, weshalb die SSH-Verbindung über das Gateway nicht mehr funktioniert.

  Auf einem Edge ohne einen Fix für dieses Problem kann ein vom Benutzer initiierter Neustart des Edge-Diensts zur Behebung des Fehlers beitragen.

• Behobenes Problem 101144: Auf einem VMware SD-WAN Gateway kann es zu Paketverlusten kommen, wenn beschädigte Pakete vorhanden sind.

  Diese Verluste können beobachtet werden, wenn vcdbgdump -r dpdk-leak-dump ausgeführt wird und sich die Verluste in pkt_path_alloc und pkt_path_ooo befinden. Die Pakete bleiben in der Ringwarteschlange für die VCMP-Resequenzierung hängen und werden nicht verarbeitet.

• Behobenes Problem 101753: Ein VMware SD-WAN Edge kann auf dem VMware SASE Orchestrator als offline angezeigt werden, obwohl er aktiv ist und Datenverkehr durchleitet.

  Das Problem tritt auf, weil der Edge weiterhin Datenverkehr von einer IP-Adresse an den Orchestrator weiterleitet, die nicht mehr verfügbar ist, sodass der zurückkehrende Datenverkehr als Folge davon unterbrochen wird.

• Behobenes Problem 102607: Bei einem VMware SD-WAN Edge kann es zu einem Ausfall des Datenebene-Diensts kommen, wenn ein Nicht-SD-WAN-Ziel über Gateway oder Edge verwendet wird und BGP über NSD ebenfalls konfiguriert ist.

  Ein Problem kann auftreten, wenn eine NSD-Datencenterroute und eine Edge-zu-Edge-Route dasselbe Präfix verwenden. In diesem Szenario können die für das DC bestimmten und verschlüsselten Pakete die SD-WAN-Verwaltungstunnel erreichen, was zu einem Arbeitsspeicherverlust oder sogar zu einem Dienstausfall führen kann.

• Behobenes Problem 102655: In einem Kundenunternehmen, in dem BGP für das Routing verwendet wird, wird BGP auf einem nicht-globalen Segment nicht auf der Subschnittstelle eines Edge angezeigt.

  Das Problem wird ausgelöst, wenn die Hauptschnittstelle des Edge auf dem globalen Segment und eine Subschnittstelle auf einem nicht-globalen Segment dieselbe IP-Adresse haben und auf der Hauptschnittstelle auch ein WAN-Overlay konfiguriert ist. Das Problem, dass BGP nicht angezeigt wird, tritt in den meisten Fällen nach einem Edge- oder Dienstneustart auf.

  Entfernen Sie auf einem Edge ohne einen Fix für dieses Problem die IP-Adresse der Teilschnittstelle sowie die BGP-bezogene Konfiguration und führen Sie eine erneute Konfiguration mit einer eindeutigen IP-Adresse durch.

• Behobenes Problem 102693: Wenn ein Benutzer auf einer mit einer Hochverfügbarkeitstopologie konfigurierten Site versucht, die von den VMware SD-WAN HA-Edges verwendete Softwareversion sowie den verwendeten Factory Build zu ermitteln, werden die entsprechenden Felder im VMware SASE Orchestrator unter Umständen leer angezeigt.

  Wenn HA für ein Edge-Paar aktiviert ist, senden die Edges die Factory-Software- und Build-Versionen möglicherweise nicht beim ersten Taktsignal an den Orchestrator, weshalb sie im Orchestrator nicht angezeigt werden können.

• Behobenes Problem 103558: Wenn die Analyse für einen VMware SD-WAN Edge in einem Kundenunternehmen mit Edge Network Intelligence aktiviert ist, wird im ENI-Dashboard unter Umständen „Keine Verwaltungs-IP zugewiesen (No Management IP Assigned)“ für diesen Edge angezeigt.

  Bei aktivierter Analyse sendet der Edge in seltenen Fällen die Verwaltungs-IP-Adresse nicht an das Edge Network Intelligence-Back-End.

• Behobenes Problem 103700: Anwendungen in einer Anwendungszuordnung, die mit einer mustNotPerformDpi (Deep Packet Inspection (DPI) sollte nicht durchgeführt werden) konfiguriert sind, erhalten ihre Klassifizierung unter Umständen weiterhin über DPI, wenn der Kunde über eine große Bereitstellung verfügt.

  Eine falsch klassifizierte Anwendung kann dazu führen, dass Clientbenutzer nicht auf die Anwendung oder Website zugreifen können.

  In einem großen Kundenunternehmen mit ca. 8.000 Einträgen im schnellen Datenbankcache der Anwendungsklassifizierung können Konflikte beim Suchen einer Anwendung auftreten. Bei einem Konflikt kann eine Anwendung weiterhin über DPI klassifiziert werden, obwohl sie mit mustNotperformDpi konfiguriert ist.

  In einem Unternehmen ohne einen Fix für dieses Problem besteht die Problemumgehung in der Konfiguration einer Business Policy, bei der die Subnetze für die Anwendung oder Domäne verwendet werden, um den Datenverkehr über einen direkten oder Internet-Backhaul zu lenken.

• 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 103962: Die verbundenen IPv6- und IPv4-Routen, die in OSPFv3 oder BGPv6 umverteilt werden, weisen unterschiedliche Metriken auf, wodurch IPv6-Datenverkehr unter Umständen anders geroutet wird als IPv4-Datenverkehr.

  Derzeit werden die verbundenen IPv6-Routen, die einer gerouteten Schnittstelle entsprechen, mit einer anderen Metrik als verbundene IPv4-Routen auf derselben Schnittstelle installiert. Dies liegt an den unterschiedlichen Metriken, die vom Betriebssystem-Kernel des Edge für IPv4- und IPv6-Routen angegeben werden. Wenn die Routen in dynamische Protokolle wie OSPF/BGP umverteilt werden, wird dieser Unterschied in den IPv4-/IPv6-Metriken weitergegeben.

• Behobenes Problem 104046: Für einen mit einer Hochverfügbarkeitstopologie bereitgestellten Kundenstandort zeigt der VMware SASE Orchestrator den Standby-Edge möglicherweise als aktiv an, obwohl er tatsächlich ausgefallen ist.

  Dies geschieht, wenn entweder das HA-Schnittstellenkabel zwischen den HA-Edges getrennt oder der Standby-Edge ausgeschaltet wird. Das Problem wird dadurch verursacht, dass der aktive HA-Edge einen aktiven Status sendet, während der Standby-Edge aufgrund einer Prüfung durch den Verwaltungsprozess des aktiven Edge ausgefallen ist. Dieser Prozess bezieht sich nur darauf, ob HA konfiguriert ist, während der tatsächliche Status des Standby-Edge ignoriert wird.

• Behobenes Problem 104513: Bei einem Unternehmen, das mit einem Partner-Gateway über BGP verbunden ist und ICMP-Tests bereitstellt, stellen Clientbenutzer bei Ausfall eines ICMP-Tests möglicherweise fest, dass der Datenverkehr abbricht und nicht wiederhergestellt wird.

  Wenn ein ICMP-Test ausfällt, wird der Erreichbarkeitsstatus der BGP-Routen des Partner-Gateways auf „False“ festgelegt und der gesamte Datenverkehr, der diese Routen verwendet, schlägt fehl. Das Problem ist darauf zurückzuführen, dass das Gateway alle PG-Übergaberouten im Hinblick auf den ICMP-Teststatus überprüft, einschließlich BGP-Routen. Wenn der Status eines ICMP-Tests inaktiv ist, markiert das PG auch BGP-Routen als ausgefallen.

  Auf einem Gateway ohne einen Fix für dieses Problem besteht die einzige Problemumgehung darin, ICMP-Tests zu deaktivieren. Dies hat jedoch das Potenzial, andere Kunden zu stören, die dasselbe Partner-Gateway verwenden, und sollte nur mit dieser Einschränkung erfolgen.

• Behobenes Problem 105433: An einer Site, die eine Topologie mit erweiterter Hochverfügbarkeit verwendet, können die VMware SD-WAN HA-Edges mit VMware SASE Orchestrator offline gehen, wenn eine WAN-Schnittstelle am Standby-Edge ausfällt.

  Der Standby-Edge synchronisiert die Aktualisierung der dynamischen IP-Adresse nicht mit dem aktiven Edge, wenn der Schnittstellenstatus geändert wird, wodurch die Konnektivität zwischen der HA-Edge-Site und dem Orchestrator ausfällt. Dies wirkt sich nur auf den Verwaltungsdatenverkehr und nicht auf den Kundendatenverkehr aus.

• Behobenes Problem 105440: Wenn der Datentyp für die DHCP-Option 43 auf „Text“ festgelegt ist und „Wert (Value)“ als Textzeichenfolge konfiguriert ist, die mit einer Zahl beginnt, wird die Option ignoriert und ein Fehler gemeldet.

  Ein typisches Beispiel für dieses Problem ist, wenn der Wert der Option 43 als IP-Adresse konfiguriert ist. Dem Benutzer wird ein Ereignis mit der Meldung "messages" : "dhcp.py:527: Invalid value for option 43: <text string configured>, ignored" angezeigt.

• Behobenes Problem 105492: IPv6-basierte L2-Pakete, die nicht für eine L2-MAC-Adresse des VMware SD-WAN Edge bestimmt sind, werden unnötigerweise verarbeitet, anstatt verworfen zu werden.

  Erwartungsgemäß sollten IPv6-Pakete, die per Unicast an eine Ziel-MAC gesendet werden, die nicht mit der Schnittstellen-MAC des Edge übereinstimmt, verworfen werden.

• Behobenes Problem 105686: Beim Upgrade eines VMware SD-WAN Gateways in 82599 SR-IOV auf Gateway-Build 5.0.1.2 werden die SR-IOV-NIC-Schnittstellen nicht aktiviert.

  Der ixgbevf-Treiber stand auf dem Gateway-Build unter dem Kernel 4.15.0-201-generic nicht zur Verfügung. Die Sicherheits-Rollups des Ubuntu-Kernels (ab Version 4.15.0.159) verfügen über Backports aus dem Haupt-Kernel. skb_frag_off steht jetzt im Kernel-Header bereit, d. h., die eigene skb_frag_off-Definition des ixgbevf-Treibers wird nicht benötigt.

  Operatoren sollten kein Upgrade einer Gateway-Version 5.0.1.2 durchführen, wenn 82599 SRIOV-Schnittstellen verwendet werden.

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

  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.

• Behobenes Problem 106017: Bei der Bereitstellung einer VMware SD-WAN Gateway-OVA auf vSphere erhalten Kunden unter Umständen eine Warnung mit dem Hinweis, dass VMware Tools nicht auf der VM installiert ist, obwohl dies der Fall ist.

  Die vollständige Meldung lautet: „Tools ist auf dem Gastbetriebssystem nicht installiert. Installieren Sie die aktuelle Version von open-vm-tools oder VMware Tools, um die Gastanpassung zu aktivieren (Tools is not installed in the GuestOS. Please install the latest version of open-vm-tools or VMware Tools to enable GuestCustomization)“. Die Meldung ist falsch, da die Tools tatsächlich auf dem Gateway-Image installiert sind. Da aber das Versionsattribut fehlt, wird der Fehler ausgelöst. Diese falsche Fehlermeldung wirkt sich nicht auf Konfigurationsfunktionen aus.

• Behobenes Problem 106123: VMware SD-WAN kann Pakete falsch klassifizieren, weil die DPI-Engine (Deep Packet Inspection) nicht der aktuellste Build ist.

  Wenn ein Edge oder Gateway ein Paket falsch klassifiziert, kann dies zu zahlreichen Problemen für SD-WAN-Kunden führen. Der Fix aktualisiert die DPI-Engine des Edge und des Gateways auf den aktuellsten Build, wodurch sichergestellt wird, dass der SD-WAN-Dienst den Datenverkehr des Kunden mit höherer Genauigkeit klassifiziert.

• Behobenes Problem 106225: Verbundene und statische Routen im Zusammenhang mit einer Teilschnittstelle werden von Remote-VMware SD-WAN Edges gelöscht, wenn die WAN-Verbindung ausfällt.

  Bei der Ankündigung verbundener Routen für Teilschnittstellen verwendet SD-WAN die Teilschnittstellen-ID anstelle eines Array-Indexes. Dies führt dazu, dass auf der falschen Schnittstelle nach einem Ankündigungs-Flag gesucht wird. Folglich fehlen Ereignisse vom Typ „Hinzufügen/Löschen“ in Schnittstellen-Flaps für Remote-Knoten.

  Auf einem Edge ohne Fix für dieses Problem sollte der Kunde „Ankündigen (Advertise)“ auf allen Schnittstellen konfigurieren, da auf diese Weise das Problem vermieden werden kann.

• Behobenes Problem 106331: Wenn für ein Unternehmen, das mit einem Partner-Gateway über BGP verbunden ist und ICMP-Tests bereitstellt, ein ICMP-Test auf dem Partner-Gateway ausfällt, stellen Clientbenutzer möglicherweise fest, dass der Datenverkehr abbricht und nicht wiederhergestellt wird.

  Das Problem ist darauf zurückzuführen, dass der VMware SD-WAN Edge nicht nur statische PG-Übergaberouten im Hinblick auf den ICMP-Teststatus überprüft, sondern auch BGP-Routen. Wenn ein Teststatus inaktiv ist, markiert der Edge sowohl die statische Übergaberoute als auch die BGP-Routen als ausgefallen, was zu einer Unterbrechung des Kundendatenverkehrs führt.

• Behobenes Problem 106913: Externe Hub-Routen werden einem Nicht-SD-WAN-Ziel über Gateway nicht über BGP auf einem VMware SD-WAN Gateway angekündigt.

  Dieses Problem ist das Ergebnis geerbten Verhaltens von BGP auf einem Partner-Gateway. Es war beabsichtigt, dass das Übergabe-BGP zur Vermeidung einer Schleife die Umverteilung externer OSPF-HUB-Routen in ein PG-BGP umgeht, und das NSD-BGP hat dieses Verhalten vom PG-BGP geerbt.

• Behobenes Problem 107114: Wenn die serielle Konsole eines VMware SD-WAN Edge in den Firewalleinstellungen auf dem VMware SASE Orchestrator deaktiviert ist, kann ein Benutzer weiterhin Routinemeldungen in der seriellen Konsole anzeigen.

  SD-WAN unterdrückt die Routinemeldungen in der Konsole nicht, auch wenn die serielle Konsole im Orchestrator deaktiviert ist. Mit dem Fix wird sichergestellt, dass der Edge kritische Nachrichten (CRIT, ALERT, EMERG) nur dann in der seriellen Konsole druckt, wenn sie in den Firewalleinstellungen deaktiviert ist.

• Behobenes Problem 107216: Bei der Ausführung der Remote-Diagnose „Status der Schnittstelle (Interface Status)“ wird in der Ausgabe eine ungenaue Verbindungsgeschwindigkeit angezeigt.

  Wenn die automatische Aushandlung für eine Schnittstelle auf „Aus (Off)“ festgelegt ist, wird die Schnittstelle nicht mehr unter DPDK mit einem Silicon-Treiber ausgeführt. Der neue für DPDK verwendete Treiber lautet „af_packet“, der den zugrundeliegenden Kernel-Treiber nutzt. Die neue manuelle Geschwindigkeit wird nicht festgelegt, nachdem die PCI-Bindung von DPDK zum Kernel aufgehoben wurde. Daher ist die Verbindungsgeschwindigkeit beim Ausführen des von „Status der Schnittstelle (Interface Status)“ verwendeten ethtool-Debug-Befehls ungenau.

• 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 107317: Bei einem Kunden, der SNMP verwendet und dessen Server sich im Internet befindet, kann ein SNMP-Walk für einige VMware SD-WAN Edge-Schnittstellen erfolgreich sein und bei anderen Schnittstellen mit einer Zeitüberschreitung fehlschlagen.

  Wenn der SNMP-Walk fehlschlägt, geht die SNMP-Anforderung an einer Schnittstelle ein und an einer anderen aus, und diese Antwortpakete erreichen den SNMP-Server nie. Das Problem wird dadurch verursacht, dass der Edge den SNMP-Datenverkehr falsch klassifiziert, sodass er diese Pakete an eine andere Schnittstelle für Antwortpakete weiterleitet, unabhängig von der Schnittstelle, über die sie empfangen werden. Dies führt dazu, dass SNMP-Walks für die Schnittstelle funktionieren, die der Edge für die SNMP-Antwort bestimmt hat, aber für alle anderen fehlschlagen.

• Behobenes Problem 107708: Auf einem VMware SD-WAN Edge, auf dem der SD-WAN-Overlay-Grenzwert für Raten konfiguriert ist, hält sich das SD-WAN Gateway bei Downstream-Datenverkehr vom Internet zum Edge unter Umständen nicht genau an den Grenzwert.

  Der Datenverkehr vom Internet zum Edge wird vom Gateway nicht konfigurationsgemäß begrenzt. Der SD-WAN-Overlay-Grenzwert wird um einige MBit/s überschritten. Dies geschieht, weil der VCMP-Verwaltungs-Overhead bei der Berechnung des Ratengrenzwerts im Gateway nicht berücksichtigt wird.

• Behobenes Problem 107994: Wenn berechtigte Benutzer mit sicherem Edge-Zugriff bereitgestellt werden, schlagen Hochverfügbarkeitsvorgänge wie das Ausführen der Remote-Diagnose „HA-Info (HA)“ über den Orchestrator und die Anmeldung beim HA-Edge des Peer fehl.

  Wenn berechtigte Benutzer mit sicherem Edge-Zugriff bereitgestellt werden, wird das Root-Konto vollständig blockiert. Das Problem dabei ist, dass HA-Vorgänge von der Kommunikation mit dem Peer-Edge als Root abhängen. Dies führt dazu, dass alle nachträglich durchgeführten HA-Vorgänge nicht funktionieren.

  Auf einem HA-Edge-Paar ohne einen Fix für dieses Problem muss der Kunde zur kennwortbasierten Authentifizierung zurückkehren und alle berechtigten Benutzer mit sicherem Edge-Zugriff löschen ODER in Basisbenutzer ändern.

• Behobenes Problem 108374: Bei einem Kundenunternehmen, in dem dynamische Zweigstelle-zu-Zweigstelle-Tunnel verwendet und LAN-seitige NAT-Regeln konfiguriert werden, kann eine Routenänderung dazu führen, dass der Datenverkehr zu einem Remote-LAN fehlschlägt.

  Bei einer Routenänderung, wie z. B. bei dynamischen Zweigstelle-zu-Zweigstelle-Tunneln, wird das LAN-seitige NAT für bestehende Flows möglicherweise nicht ordnungsgemäß neu berechnet, was dazu führt, dass sie unterbrochen werden und der für das LAN-Subnetz des Peer-Edge bestimmte Datenverkehr beeinträchtigt 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 108610: In einem Kundenunternehmen mit eingeschalteter Firewall blockiert die Firewall beim Upgrade eines Edge von einer 3.x-Version auf eine 4.x-Version Datenverkehr, der zuvor nicht blockiert wurde.

  Beim Upgrade des Orchestrators von 3.4.4 auf 4.0.0 auf 4.0.2 auf 4.2.2 wird die Konfiguration der Adressgruppe nicht auf mit diesem Orchestrator verbundenen Edges unter Edge-Version 3.4.4 bis Edge-Version 4.2.2 widergespiegelt. Dies liegt daran, dass der Edge eine andere Version der JSON-Datei für Adressgruppen in 3.4.4 und 4.2.2 erwartet. Der Orchestrator, der in der oben genannten Reihenfolge aktualisiert wurde, sendet die JSON-Dateien im neuen Format erst dann an die Edges, wenn eine Konfigurationsänderung vorliegt. Dies hat zur Folge, dass Adressgruppenkonfigurationen nicht funktionieren.

• Behobenes Problem 108982: Bei einem VMware SD-WAN Edge mit konfigurierten ICMP-Tests kann der Kunde beobachten, dass die Edge-Tests im INIT-Status nicht mehr funktionieren.

  Der Timer der ICMP-Tests kann beschädigt werden, was dazu führt, dass die Maschine mit dem Teststatus im INIT-Status hängen bleibt. Die Beschädigung des Timers ist auf eine Racebedingung zurückzuführen, bei der mehrere Threads versuchen, den Timer hinzuzufügen, zu entfernen oder ablaufen zu lassen.

• Behobenes Problem 109500: Wenn LAN-seitige NAT dieselbe innere und äußere Definition verwendet, wird das erste Paket eines direkten Flows verworfen.

  Das Problem besteht darin, dass die Übereinstimmungsinformationen in der ursprünglichen NAT-Tabelle für die anfängliche LAN-seitige NAT-Übersetzung und die direkte NAT-Übersetzung identisch sind. Dies führt zu einem Konflikt in den Tabellen, wodurch das erste Paket verworfen wird.

• Behobenes Problem 109511: Wenn ein VMware SD-WAN Edge die maximale Tunnelanzahl erreicht, wird das Ereignis EDGE_TUNNEL_CAP_WARNING unter Umständen nicht im VMware SASE Orchestrator angezeigt.

  Der Edge sendet keine Nachricht mit einer Warnung zur Tunnelbegrenzung an den Orchestrator, wenn das Problem zum ersten Mal innerhalb eines Zeitraums von 24 Stunden auftritt.

• Behobenes Problem 109963: Ein Benutzer kann nicht per SSH auf einen VMware SD-WAN Virtual Edge zugreifen.

  Alle Virtual Edge-Typen (Azure, AWS usw.) sind von diesem Problem betroffen. Bei einem SSH-Versuch empfängt der Virtual Edge zwei SSH-Pakete, was den Edge-Kernel dazu veranlasst, auf zwei SSH-Anfragen zu antworten, wodurch der SSH-Client verwirrt wird und es zum Scheitern von SSH kommt.

• Behobenes Problem 110406: Wenn das HA-Edge-Paar für eine Kunden-Site, die mit einer Hochverfügbarkeitstopologie bereitgestellt wird, auf eine frühere Softwareversion herabgestuft wird, schließt der aktive Edge die Herabstufung möglicherweise nicht ab.

  Wenn dieses Problem auftritt, wird nur der Standby-Edge erfolgreich auf die angegebene Softwareversion herabgestuft, während der aktive Edge nie herabgestuft wird. Dies bedeutet, dass es sich bei der Site um eine eigenständige Site und nicht mehr um eine HA-Site handelt.

  Auf einer HA-Site, auf der dieses Problem auftritt, besteht die Problemumgehung ohne einen Fix darin, HA zu deaktivieren, den vorherigen aktiven Edge als eigenständigen Edge herabzustufen und HA dann erneut zu aktivieren, wobei beide Edges nun die gleiche herabgestufte Version verwenden.

• Behobenes Problem 110456: Bei ICMP-Tests von einem Partner-Gateway oder Cloud-Gateway an ein direkt angeschlossenes Gerät werden möglicherweise Pakete verworfen, wenn das Feld für den ICMP-Anforderungscode nicht 0 ist.

  Manche Anbieter prüfen das Codefeld eines ICMP-Anforderungspakets und stufen es als nicht korrekt ein, wenn das Feld nicht 0 ist.

• Behobenes Problem 110473: In einem Kundenunternehmen, das BGP verwendet, werden unerwartete Routen vorübergehend empfangen/gesendet und Flows können mit falschen Business Policies übereinstimmen, wenn ein BGP-Nachbar entfernt wird.

  Wenn ein BGP-Nachbar aus dem Orchestrator entfernt wird, betrifft dies zuerst die zugehörigen ein-/ausgehenden Routenzuordnungen. Danach wird der Nachbar aus der Routing-Konfiguration des Edge entfernt. Dies führt zu einem vorübergehenden Ausfall von Routen, die von diesen Routenzuordnungen abgelehnt werden. Dies wiederum wirkt sich auf das Verhalten der Business Policy aus, wenn ein Flow mit den ausgefallenen Routen erstellt wird.

  Auf einem Edge ohne einen Fix für dieses Problem kann ein Benutzer die Remote-Diagnose „Flows leeren (Flush Flows)“ ausführen, um das Problem zu beheben.

• Behobenes Problem 110484: Ein Kunde stellt möglicherweise einen falschen Pfadstatus auf der Seite „Edge > Überwachen (Monitor) > Pfade (Paths)“ des Orchestrators fest, wenn der Pfad mit einem WAN-Link verbunden ist, bei dem die Path MTU Discovery deaktiviert wurde.

  Möglicherweise stellt der Kunde auch zwei verschiedene Pfadstatus für denselben Pfad fest, wenn er die Seite Überwachen (Monitor) > Pfade (Paths) für die Edge-Endpoints dieses Pfads überprüft. Dieses Verhalten ist darauf zurückzuführen, dass die Verbindungskonfiguration der MTU-Pfaderkennung (Path MTU Discovery) in Bezug auf automatisch erkannte WAN-Overlays nicht wie erwartet funktioniert. Diese Konfiguration wird in der Regel in der Konfigurationsaktualisierungsfunktion verarbeitet, da der Edge die Verbindungskonfiguration für den Orchestrator mit dieser Art von Links auslöst. Da die Aktualisierung der PMTU-Konfiguration während des Aktualisierungsaufrufs jedoch fehlt, kommt es zu diesem Problem.

  Hinweis:

  Die Symptome dieses Problems werden für dieses Ticket nicht behoben, wodurch Kunden wie oben beschrieben mit ihnen konfrontiert werden. Ein Build mit diesem Ticket fügt Protokollierungsverbesserungen hinzu, um die Techniker bei der Bereitstellung eines tatsächlichen Fixes zu unterstützen.

• Behobenes Problem 110564: Für eine Kunden-Site, die in einer Hochverfügbarkeitstopologie bereitgestellt wird, kann die zum Synchronisieren von Daten zwischen dem aktiven und dem Standby-Edge verwendete TCP-Sitzung ausfallen. In einer Bereitstellung mit erweiterter HA führt dies dazu, dass der WAN-Link-Datenverkehr auf dem Standby-Edge nicht weitergeleitet wird.

  Für Bereitstellungen mit Standard-HA oder erweiterter HA ist ein Szenario möglich, in dem ein untergeordneter Prozess den Port verwendet, der für TCP-Sitzungen zwischen dem aktiven und dem Standby-Edge vorgesehen ist. In diesem Szenario kann der aktive Edge den TCP-Server aufgrund von Bindungsfehlern nicht starten, was dazu führt, dass der Schnittstellenstatus des Standby-Edge nicht ausgetauscht wird. Bei Bereitstellungen mit erweiterter HA hat dies zur Folge, dass WAN-Links nicht für die Weiterleitung von Datenverkehr verwendet werden können.

• Behobenes Problem 111073: Ein VMware SD-WAN Edge mit Version 4.5.1 meldet SNMP unter Umständen die falsche Schnittstellengeschwindigkeit.

  Bei ifSpeed handelt es sich um einen 32-Bit-Wert. Wenn dieser Wert den vom Edge in Bit pro Sekunde (Bit/s) angegebenen Geschwindigkeitswert nicht aufnehmen kann, wird empfohlen, auf den Wert ifHighSpeed zu verweisen, der in MBit/s angegeben wird.

• Behobenes Problem 111162: In einem Kundenunternehmen, das ein Partner-Gateway verwendet und Edges in Hochverfügbarkeit bereitstellt, kann ein HA-Edge suboptimal geroutet werden, wenn eine PG-Route über ein sekundäres Partner-Gateway als beste Route ausgewählt wird.

  Im HA-Edge besteht bei A-A- oder A-S-Übergängen die Möglichkeit, dass die Reihenfolge für eine PG-Route von einem sekundären Partner-Gateway auf 4 festgelegt und somit zur besten Route wird. In der Regel weisen primäre Partner-Gateway-Routen höhere Ordnungswerte auf.

• Behobenes Problem 111314: In einem Kundenunternehmen, in dem dynamische Kostenberechnung aktiviert ist, kann es zu Datenverkehrsausfällen kommen.

  Dieses Problem kann auftreten, wenn einer der Edges spezifischere Routen für alle Edges im Unternehmen ankündigt, bevor er offline geschaltet wird. Sobald dieser Edge offline ist, verbleiben die Routen in der FIB (Forwarding Information Base) aller anderen Edges, wobei „Erreichbarkeit (Reachability)“ auf False festgelegt ist. Dies führt zu Paketverlusten.

  Auf einem Edge ohne einen Fix für dieses Problem kann ein Benutzer das Problem beheben, indem er über das Menü „Remote-Aktionen (Remote Actions)“ im Orchestrator einen manuellen Neustart des Edge-Diensts initiiert.

• 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 111840: In einem Kundenunternehmen mit mehr als 8 VMware SD-WAN Edges, die als Hubs konfiguriert sind, können Benutzer aufgrund von suboptimalem Routing eine schlechte Datenverkehrsleistung beobachten.

  Wenn ein Spoke-Edge mit mehreren Hub-Edges konfiguriert ist, wird die Route über den Hub einer direkten Zweigstelle-zu-Zweigstelle-Route vorgezogen, was zu suboptimalem Routing führt.

  Auf Edges ohne Fix für dieses Problem kann der Kunde zuerst die Hub-Edges und dann die VPN-Hub-Edges in der Liste „Zweigstelle-zu-Hub-Site (Branch to Hub site)“ konfigurieren.

• 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 auf einem Gateway ohne einen Fix für diesen Fehler auftritt, 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 111935: Ein VMware SD-WAN Edge, der als Hub konfiguriert ist, erlernt unter Umständen keine Routen von einer Remote-Site.

  Wenn zwei Edges als Hubs aufeinander zeigen, besteht die Möglichkeit, dass einer von ihnen die Routen des anderen Edge erlernt.

  Auf Edges ohne einen Fix für dieses Problem kann ein Kunde diesen Fehler umgehen, indem er die Mesh-Hub-Konfiguration aufhebt und für alle Hub-Edges in einem Profil nur Cloud-VPN aktiviert.

• 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 112452: Ein Kunde stellt gegebenenfalls fest, dass bei einem für Hochverfügbarkeit konfigurierten VMware SD-WAN L2-Schleifen auf den WAN-Schnittstellen des Edge auftreten.

  Wenn eine Schnittstelle von „Geswitcht (Switched)“ zu „Geroutet (Routed)“ wechselt, tritt ein Problem mit der MAC-Adresse in der Datei origmacs auf. Wenn eine virtuelle MAC-Adresse für eine Schnittstelle gespeichert wird oder keine ursprüngliche MAC-Adresse für die Schnittstelle in der Datei enthalten ist, verwendet der Edge die virtuelle MAC-Adresse zum Senden von WAN-Taktsignalen, was dazu führt, dass eine L2-Schleife erkannt wird.

  Auf einem HA-Edge ohne einen Fix für dieses Problem besteht die Problemumgehung darin, dass der Support die Datei „origmacs“ löscht und dann zuerst den Standby-HA-Edge und dann den aktiven HA-Edge neu startet.

• 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 112882: Wenn ein VMware SD-WAN Edge auf Version 5.1.0.3 aktualisiert wird, funktioniert SNMP auf dem Edge unter Umständen nicht mehr.

  Alle Änderungen an den Einträgen in der SNMP-Segnat-Tabelle hatten keinen entsprechenden Update-API-Aufruf zur Folge. Dies hat dazu geführt, dass eine entsprechende IP-Zieladresse/ein entsprechender Port hängen geblieben ist.

• Behobenes Problem 113153: In einem Kundenunternehmen mit einer Hochverfügbarkeitstopologie kann es beim VMware SD-WAN Edge in der aktiven Rolle zu einem Ausfall des Datenebene-Diensts kommen, der ein HA-Failover auslöst, wenn der Standby-Edge neu gestartet oder rebootet wird.

  Wenn beim aktiven Edge ein Ausfall des Datenebene-Diensts auftritt, wird ebenfalls ein HA-Failover ausgelöst. Dieses Problem kann auftreten, wenn die HA-Site eine große Menge an Datenverkehr weiterleitet.

• Behobenes Problem 114004: Ein Kunde stellt möglicherweise fest, dass bei einem VMware SD-WAN Edge ein Arbeitsspeicherverlust entsteht, wenn SNMP auf dem Edge konfiguriert ist.

  Der Arbeitsspeicherverlust des Edge schreitet langsam voran. Wenn jedoch keine entsprechenden Maßnahmen ergriffen werden, erreicht die Arbeitsspeicherauslastung ein kritisches Niveau. Dies führt dazu, dass der Edge defensiv einen Neustart des Diensts auslöst. Dieser Neustart kann den Kundendatenverkehr für 15 bis 30 Sekunden unterbrechen, während der Edge wiederhergestellt wird. Ohne einen Fix für dieses Problem beginnt der Arbeitsspeicherverlust von vorne.

• 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 114511: Für einen automatisch erkannten WAN-Link funktioniert das Deaktivieren der Option „MTU-Pfaderkennung (Path MTU Discovery)“ nicht. Der Edge implementiert die Funktion weiterhin und ändert die MTU-Größe.

  Die Konfiguration wird während einer Aktualisierung für automatisch erkannte Links verarbeitet. Diese spezifische Konfiguration für Pfad-MTU wurde während der Konfigurationsaktualisierung nicht verarbeitet.

• Behobenes Problem 114932: Benutzer stellen unter Umständen eine beeinträchtigte Datenverkehrsleistung fest, wenn eine Verbindung mit einem VMware SD-WAN Gateway besteht.

  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 115078: In einem großen Kundenunternehmen mit ca. 16.000 Benutzern und einer Flow-Erstellungsrate von etwa 2.000 pro Sekunde auf Hub-Edges sehen sich Benutzer aufgrund einer hohen Latenz mit einer schlechten Datenverkehrsqualität konfrontiert.

  Die DPI-Engine (Deep Packet Inspection) des Gateways kann auf Hub-Edges überlastet sein, wenn zahlreiche vom Peer initiierte Flows erstellt werden. Dies ist darauf zurückzuführen, dass der Port-Cache mit der IP-Quelladresse und der Portnummer anstelle der IP-Zieladresse und Portnummer für diese Peer-Flows befüllt wird.

• Behobenes Problem 115132: Bei einem VMware SD-WAN Edge mit Edge-Version 5.1.0.2 kann das Ergebnis aus leeren Werten bestehen, wenn ein Benutzer die Remote-Diagnose „NAT-Tabellenauszug (NAT Table Dump)“ ausführt.

  Dieses Problem hindert Benutzer daran, eine Fehlerbehebung bei NAT-Problemen auf Edges mit Version 5.1.0.2 durchzuführen. Edges mit früheren Versionen funktionieren wie erwartet.

• 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 116086: Bei einem VMware SD-WAN Edge mit einer Version 5.0.x oder 5.1.x (entweder das Factory-Image vor der Aktivierung oder eine Version nach der Aktivierung) ist bei Verwendung der lokalen Benutzeroberfläche die Option zur Konfiguration einer gerouteten Schnittstelle mit einer VLAN-ID nicht vorhanden.

  Dieses Problem verhindert, dass ein Benutzer ein VLAN auf einer gerouteten Schnittstelle vor der Aktivierung des Edge konfigurieren kann, wenn der Edge ein 5.0.x- oder 5.1.x-Factory-Image verwendet oder wenn der Edge aktiviert wird und ein beliebiges Edge-Release der Versionen 5.0.x oder 5.1.x verwendet. Nur ein Factory-Image der Version 5.2.0 oder höher verfügt über eine Behebung dieses Problems vor der Aktivierung.

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

• Behobenes Problem 116589: Bei der Aktualisierung eines VMware SD-WAN Edge von Version 3.x auf 4.x oder höher kann es vorkommen, dass die konfigurierten Adressgruppen nicht analysiert werden.

  In Version 3.x gibt es keine Konfiguration zum Festlegen von isakmpLifeMins und ipsecLifeMins. Beispiel: Wenn Version 3.x auf einem Orchestrator ausgeführt wird, sendet dieser eine Konfigurationsdatei für die Edge-Eigenschaft ohne isakmpLifeMins und ipsecLifeMins.

  Wenn der Orchestrator auf Version 4.x und höher aktualisiert wird, enthält er die Felder isakmpLifeMins und ipsecLifeMins. Diese Konfiguration wird jedoch nicht an den Edge unter Version 3.x übertragen. Beim Upgrade des Edge von 3.x auf 4.x und höher wird er mit der letzten bekannten fehlerfreien Konfiguration (ohne isakmpLifeMins und ipsecLifeMins) gestartet.

  Beim Start des Edge wird deutlich, dass die Pflichtparameter isakmpLifeMins und ipsecLifeMins nicht vorhanden sind. Folglich stoppt der Edge die Verarbeitung der Konfigurationsdatei für die Edge-Eigenschaft, was bedeutet, dass nach dieser spezifischen Konfiguration keine der anderen Konfigurationen in diesen Dateien (z. B. Adressgruppen) mehr verarbeitet werden. Dies führt dazu, dass keine Konfiguration für die Adressgruppe vorhanden ist.

• Behobenes Problem 116641: VMware SD-WAN Edge-Protokolle enthalten Fehlerprotokolle für die Routensuche mit dem Fehlergrund „Keine (None)“.

  Wenn der Datenverkehr fehlschlägt, werden dem Kunden manchmal Fehlerprotokolle für die Routensuche mit dem Fehlergrund „Keine (None)“ angezeigt, was für die Fehlerbehebung nicht hilfreich ist. Der Fix liefert einen konkreten Grund, der dem Benutzer bei der Fehlerbehebung hilft.

  Früher sah das Fehlerprotokoll zum Beispiel so aus:

  20:40:41.796089,856|7|6825/10072|edged_ipv4_route_lookup_vcmp_transit:6880 Route lookup failure for tuple src_ip=10.0.1.25 dst_ip=169.254.6.18 segment_id=0 lookup failed due to [None]

  In Version 4.5.2 sieht es wie folgt aus (der fettgedruckte Teil ist die Änderung):

  04:07:35.464563,968|7|9720/1917413|edged_ipv4_route_lookup_vcmp_transit:6958 Route lookup failure for tuple src_ip=10.0.1.25 dst_ip=169.254.6.18 segment_id=0 sroute=(nil) droute=(nil) lookup failed due to [No src and dst route]

Behobene Probleme bei Orchestrator

• Behoben in Orchestrator-Version R5204-20230831-GA
• Behoben in Orchestrator-Version R5203-20230809-GA
• Behoben in Orchestrator-Version R5202-20230729-GA
• Behoben in Orchestrator-Version R5201-20230623-GA
• Behoben in Orchestrator-Version R5200-20230529-GA

Behoben in Orchestrator-Version R5204-20230831-GA

Orchestrator-Build R5204-20230831-GA wurde am 01.09.2023 veröffentlicht und ist der vierte Orchestrator-Rollup für Version 5.2.0.

Dieser Orchestrator-Rollup-Build behebt die folgenden kritischen Probleme seit dem 3. Orchestrator-Rollup, R5203-20230809-GA.

• UI-Build R5204-20231201-GA, wurde am 4.12.2023 veröffentlicht und ist der zwölfte UI-Build, der zu Orchestrator 5.2.0.4 hinzugefügt wurde. 

  In der folgenden Tabelle sind alle Fixes für diesen UI-Build mit Beschreibungen der Symptome für jedes Problem aufgeführt.

  Ticket	Symptom/Beschreibung
  Behobenes Problem 126695	Wenn ein Benutzer Webhooks für Warnungen auf der Seite SD-WAN > Einstellungen (Settings) > Warnungen (Alerts) > Webhooks der Benutzeroberfläche konfiguriert, wird das Menü nicht angezeigt, wenn er auf die Schaltfläche „Nutzlastvorlage konfigurieren (Configure Payload Template)“ klickt.
  Behobenes Problem 128921	Ein Partner- oder Enterprise-Superuser, der zur Seite SD-WAN > Unternehmen (Enterprise) > Diensteinstellungen (Service Settings) navigiert, gibt es keine Option zum Anzeigen von Edge-Lizenzen.
  Behobenes Problem 131224	Auf der Seite Konfigurieren (Configure) > Gerät (Device) > VPN-Dienste (VPN Services) der Benutzeroberfläche kann beim Konfigurieren eines Zscaler-Diensts der Name des Unterspeicherorts „Sonstige (Other)“ bearbeitet werden. Dies führt dazu, dass der Orchestrator die Konfiguration als ungültig markiert und die Fehler „Zscaler-Unterstandorte können nicht als 0 benannt werden (Zscaler sublocations cannot be named as 0)“ und „Änderungen können nicht gespeichert werden. Es gibt einen oder mehrere Fehler in Ihrer Konfiguration. (Cannot save changes. There is one or more errors within your configuration)“. Der Unterspeicherort „Sonstige (Other)“ sollte nie bearbeitet werden. Dieses Problem tritt nur auf, wenn der Zscaler-Dienst deaktiviert und dann erneut aktiviert wird.
  Behobenes Problem 131631	Auf der Seite Überwachen (Monitor) > Edge > Ziele (Destinations) kann ein Benutzer nicht nach Anwendungen (Applications) filtern, da die Option auf der Benutzeroberfläche nicht vorhanden ist.
  Behobenes Problem 132047	Wenn der Benutzer auf der Seite Konfigurieren (Configure) > Edge > Gerät (Device) > Konnektivität (Connectivity) > VLAN der Benutzeroberfläche die VLAN-DHCP-Option 2 (Zeitversatz, Time Offset) auswählt, kann kein negativer Wert eingegeben werden, obwohl es sich um eine Ganzzahl handelt. Das erwartete Verhalten besteht darin, dass die Benutzeroberfläche sowohl positive als auch negative Ganzzahlen zulässt.
  Behobenes Problem 132384	Nach einer Konfigurationsänderung an einem VLAN auf Profilebene gehen alle Daten im Zusammenhang mit DHCP oder OSPF auf allen Edges mit diesem Profil verloren, wenn die Konfiguration die Funktion „Edge-Überschreiben“ verwendet.
  Behobenes Problem 133008	Auf der Seite Überwachen (Monitor) > Netzwerkübersicht (Network Overview) der Benutzeroberfläche funktioniert die Option Autom. Aktualisierung (Auto-Refresh) nicht und alle Überwachungsinformationen werden auf der Benutzeroberfläche nicht mehr angezeigt, wenn die Edges nach Verbindungsstatus sortiert sind (z. B. „Inaktive Verbindungen“, „Stabile Verbindungen“ oder „Beeinträchtigte Verbindungen“).

• UI-Build R5204-20231121-GA, wurde am 22.11.2023 veröffentlicht und ist der elfte UI-Build, der zu Orchestrator 5.2.0.4 hinzugefügt wurde.

   In der folgenden Tabelle sind alle Fixes für diesen UI-Build mit Beschreibungen der Symptome für jedes Problem aufgeführt.

  Ticket	Symptom/Beschreibung
  Behobenes Problem 128017	Ein Kunde stellt beim Navigieren zur Seite Konfigurieren (Configure) > Edge > Gerät (Device) möglicherweise fest, dass die Seite nie geladen wird, da die Benutzeroberfläche die Edge-Konfigurationsreferenzen versehentlich aus der Orchestrator-Datenbank gelöscht hat. Sobald diese Referenzen entfernt wurden, können sie nicht wiederhergestellt werden.
  Behobenes Problem 129695	Wenn ein Partnerbenutzer das WLAN-Kennwort eines Edge auf seiner WLAN-Schnittstelle ändert und Änderungen speichert, wird einem Operator-Benutzer das alte WLAN-Kennwort angezeigt, wenn er die WLAN-Schnittstelle desselben Edge aufruft.
  Behobenes Problem 130810	Ein Benutzer kann keine BGP-Filterregel in eine Liste dieser Regeln einfügen, weder über noch zwischen zwei oder mehr Regeln. Eine BGP-Filterregel kann nur am Ende der Liste hinzugefügt werden.
  Behobenes Problem 131138	Auf der Seite Konfigurieren (Configure) > Gerät (Device) > VPN > Cloud-VPN (Cloud VPN) erlaubt die Benutzeroberfläche dem Benutzer, eine Änderung an der Option Zweigstelle-zu-VPN-Hubs (Branch to VPN Hubs) zu speichern, wenn keine Hubs konfiguriert sind. Dies führt dazu, dass die Benutzeroberfläche alle Cloud VPN-Konfigurationen entfernt, weil die Konfigurationsdatei beschädigt ist.
  Behobenes Problem 132524	Wenn ein Benutzer auf der Seite Konfigurieren (Configure) > Edge > Gerät (Device) > Routing und NAT (Routing & NAT) > Statische Routeneinstellungen (Static Route Settings) der Benutzeroberfläche eine statische Route zu einem Edge hinzufügt, bei der die nächste Hop-IP-Adresse der statischen Route im selben Subnetz des VLAN-Netzwerks liegt, zeigt die Benutzeroberfläche Edge-Schnittstellen an, wenn die Schnittstelle (Interface)-Einstellungen für die lokalen Routen zu Nicht verfügbar (N/A) wechseln sollten.

• UI-Build R5204-20231115-GA, wurde am 16.11.2023 veröffentlicht und ist der zehnte UI-Build, der zu Orchestrator 5.2.0.4 hinzugefügt wurde.

  In der folgenden Tabelle sind alle Fixes für diesen UI-Build mit Beschreibungen der Symptome für jedes Problem aufgeführt.

  Ticket	Symptom/Beschreibung
  Behobenes Problem 123078	Wenn Sie zur Seite Überwachen (Monitor) > Edge > Übersicht (Overview) navigieren, sind die Spalten nicht ordnungsgemäß ausgerichtet, da für die Spalte Gerät-Seriennummer (Device Serial Number) keine Informationen eingegeben wurden, was zu Problemen bei der Lesbarkeit führt.
  Behobenes Problem 123718	Wenn ein Benutzer eine Business Policy-Regel in der Orchestrator-Benutzeroberfläche bearbeitet, kann er keine benutzerdefinierte VLAN-ID für die Business Policy eingeben, da es sich bei der VLAN-Option in der Benutzeroberfläche um eine Dropdown-Liste mit VLAN-Schnittstellen handelt und nicht um eine Textfeld-Eingabe.
  Behobenes Problem 128330	Für ein Unternehmen, das einen Netzwerkdienst Nicht-SD-WAN-Ziel (NSD) über Gateway verwendet, erlaubt die Benutzeroberfläche dem Benutzer, ein NSD über Gateway aus einem Profil zu löschen, das eine mit dem globalen Segment verbundene Business Policy-Regel enthält. Dadurch wird die Business Policy-Regel ungültig und jeglicher Datenverkehr, der mit dieser Regel übereinstimmt, wird nicht wie erwartet weitergeleitet.
  Behobenes Problem 128765	Auf der Seite BGP-Filter (BGP Filter) ist die Schaltfläche Übermitteln (Submit) möglicherweise nicht zugänglich, wenn ein Benutzer die Seite wechselt. Wenn ein Benutzer die Tabelle BGP-Filter (BGP Filters) bearbeitet und zu einer anderen Seite navigiert, während auf der aktuellen Seite ein ungültiger Konfigurationsstatus vorliegt, bleiben die Steuerelemente der Benutzeroberfläche nach der Rückkehr abgeblendet und unzugänglich, obwohl der Benutzer jetzt die richtigen Informationen für diese Zeile ausfüllt. Bei einem Orchestrator ohne Fix für dieses Problem muss ein Benutzer auf der Seite der BGP-Filter-Tabelle bleiben und sicherstellen, dass alle Konfigurationen korrekt sind, bevor er von dort weg navigiert, oder die ungültige Zeile entfernen und später wieder hinzufügen.
  Behobenes Problem 130877	Wenn ein Benutzer über die Orchestrator-Benutzeroberfläche eine statische Route zu einem Edge hinzufügt, können Clientbenutzer für diesen Edge feststellen, dass der Datenverkehr für einige lokale Routen fehlschlägt. Wenn sich auf der Benutzeroberfläche unter Konfigurieren (Configure) > Edge > Gerät (Device) > Routing und NAT (Routing & NAT) > Statische Routeneinstellungen (Static Route Settings) die IP-Adresse für nächsten Hop (Next Hop IP) einer statischen Route im selben Subnetz des VLAN-Netzwerks befindet, werden die Schnittstelleneinstellungen für Lokale Routen (Local Routes) in Nicht verfügbar (N/A) geändert und können nicht bearbeitet werden. Ohne eine konfigurierte Schnittstelle werden diese Routen unerreichbar.

• UI-Build R5204-20231109-GA wurde am 10.11.2023 veröffentlicht und ist der neunte UI-Build, der zu Orchestrator-Version 5.2.0.4 hinzugefügt wurde.

  In der folgenden Tabelle sind alle Fixes für diesen UI-Build mit Beschreibungen der Symptome für jedes Problem aufgeführt.

  Ticket	Symptom/Beschreibung
  Behobenes Problem #123387	Ein Benutzer kann kein Zscaler-Nicht-SD-WAN-Ziel (NSD) über Gateway mit einer vorhandenen IP-Adresse hinzufügen. Die Validierung des Orchestrators verhindert, dass Benutzer einen Zscaler mit einer primären oder sekundären IP-Adresse hinzufügen, die bereits in einem anderen NSD über Gateway verwendet wird. Hinweis: Dieses Ticket wurde ursprünglich als im UI-Build R5204-20231013-0631-GA behoben aufgeführt. Dieser Fix war jedoch unvollständig und das Problem ist erst in diesem UI-Build vollständig behoben.
  Behobenes Problem 123640	Wenn ein Benutzer statische Routen für einen Edge konfiguriert und im Abschnitt Statische Routen (Static Routes) auf die Schaltfläche Hinzufügen (Add) klickt, wird der Tabelle eine neue leere Zeile hinzugefügt, aber die Benutzeroberfläche gibt am unteren Rand des Bildschirms die Fehlermeldung „Änderungen können nicht gespeichert werden (Cannot save changes)“ aus.
  Behobenes Problem 127727	Wenn ein Benutzer bei der Erstellung eines neuen Cloud-Security-Service (CSS) das Kontrollkästchen Inländische Voreinstellung (Domestic Preference) aktiviert und die Konfiguration speichert, überprüft der Orchestrator die Anmeldedaten und zeigt eine Meldung an, die besagt: „Änderungen wurden erfolgreich gespeichert (Changes saved successfully!)“. Wenn das CSS-Profil nach dem Speichern jedoch erneut geöffnet wird, stellt der Benutzer fest, dass das Kontrollkästchen Inländische Voreinstellung (Domestic Preference) nicht aktiviert ist.
  Behobenes Problem 129584	Wenn ein Benutzer auf der Seite Konfigurieren (Configure) > Edges > Business Policy eine vorhandene Business Policy-Regel bearbeitet, aktualisiert die Benutzeroberfläche den neu konfigurierten Wert für das Feld Ziel (Destination) nicht, auch nicht nach dem Speichern der Änderungen. Wenn der Benutzer z. B. bei eine bestehende Business Policy-Regel mit dem Ziel (Destination) „IP-Adresse (IP Address)“ den Wert für Ziel (Destination) in „Beliebig (Any)“ ändert und die Änderung speichert, werden die Änderungen am Feld Ziel (Destination) für die Regel nicht in der Benutzeroberfläche angezeigt. Der Benutzer würde in der Regel immer noch das Feld Ziel (Destination) sehen, das auf „IP-Adresse (IP Address)“ statt auf „Beliebig (Any)“ gesetzt ist.
  Behobenes Problem 130153	Für Unternehmensbenutzer mit einer Support-Rolle ist die Option Dienst neu starten (Restart Service) unter Überwachen (Monitor) > Edges > Edge auswählen (Select Edge) > Verknüpfungen (Shortcuts) > Remote-Aktionen (Remote Actions) nicht verfügbar, was den Benutzer daran hindert, den Edge-Dienst über das Menü Verknüpfungen (Shortcuts) auf der Seite Überwachen (Monitor) > Edges neu zu starten.

• UI-Build R5204-20231101-GA wurde am 02.11.2023 veröffentlicht und ist der achte UI-Build, der zu Orchestrator 5.2.0.4 hinzugefügt wurde.

  In der folgenden Tabelle sind alle Fixes für diesen UI-Build mit Beschreibungen der Symptome für jedes Problem aufgeführt.

  Ticket	Symptom/Beschreibung
  Behobenes Problem 123001	Wenn ein Benutzer nach der Aktivierung von Hochverfügbarkeit (HA) und dem Speichern der Konfiguration versucht, VNF-Einstellungen für den VMware SD-WAN Edge zu konfigurieren, werden im Fenster Sicherheits-VNF konfigurieren (Configure Security VNF) nur Felder für die primäre virtuelle Maschine (VM-1) und die sekundäre virtuelle Maschine (VM-2) angezeigt. Folglich müssen Benutzer das Fenster „VNF-Einstellungen (VNF settings)“ manuell aktualisieren, um die sekundäre IP-Adresse zur VNF-Konfiguration hinzuzufügen.
  Behobenes Problem 127904	Wenn ein Benutzer eine statische Route und einen ICMP-Test in derselben Zeile erstellt, installiert der Edge den ICMP-Test nicht und zeigt einen Analysefehler an, da die Benutzeroberfläche die IP des nächsten Hops und den Wert der Quell-IP als Null anstelle einer leeren Zeichenfolge an den Edge sendet.
  Behobenes Problem 128753	Wenn ein Kunde eine Teilschnittstelle konfiguriert, die DHCP für die Adressierung verwendet, und ein benutzerdefiniertes WAN-Overlay erstellt, kann der Benutzer die Konfiguration nicht speichern, ohne die IP-Adressen der Quelle und des nächsten Hop zu konfigurieren.
  Behobenes Problem 129061	Ein Kunde mit der Option Partnerübergabe (Partner Hand off), die auf dem Bildschirm Kunde (Customer) > Globale Einstellungen (Global Settings) > Kundenkonfiguration (Customer Configuration) > Zusätzliche Konfiguration (Additional Configuration) > Gateway-Pool (Gateway Pool) aktiviert wurde, kann die Kontrollkästchen Für private Tunnel verwenden (Use for Private Tunnels) und Lokale IP-Adresse über BGP annoncieren (Advertise Local IP Address via BGP) im Abschnitt IPv6 des Gateways Übergabeschnittstelle (Hand Off Interface) nicht aktivieren. Somit wird verhindert, dass der Benutzer den privaten IPv6-Tunnel für die Übergabeschnittstelle deaktiviert.
  Behobenes Problem 129494	Auf der Seite Kunde (Customer) > Globale Einstellungen (Global Settings) > Kundenkonfiguration (Customer Configuration) > Dienstkonfiguration (Service Configuration) > SD-WAN muss ein Benutzer beim Bearbeiten der Dienstkonfiguration jedes Mal den Domänennamen hinzufügen, auch wenn weder SSO-Authentifizierung (Single Sign-On) noch Edge Network Intelligence (ENI) für den Kunden konfiguriert ist.
  Behobenes Problem 129765	Beim Bearbeiten einer gerouteten Schnittstelle für einen VMware SD-WAN Edge wird auf der Benutzeroberfläche ein falscher Standardwert für dhcpServer.options aufgefüllt. Beispiel: Wenn ein Benutzer die geroutete Schnittstelle „GE3“ bearbeitet und die Konfigurationsdaten der Geräteeinstellungen speichert, wird der Wert von options unter dhcpServer als Null anstelle eines leeren Arrays gesendet.
  Behobenes Problem 129894	Wenn Sie im Operator-Portal den Bildschirm Gateway-Verwaltung (Gateway Management) > Gateways > Übersicht (Overview) > Kundennutzung (Customer Usage) anzeigen, können Sie feststellen, dass bestimmte Details des Edge-Client-Tunnels fehlen. Dieses Problem kann auftreten, wenn der Name des Edge, der Name des Gateway-Pools und der Gateway-Typ identisch sind.

• UI-Build R5204-20231027-GA wurde am 27.10.2023 veröffentlicht und ist der siebte UI-Build, der zu Orchestrator 5.2.0.4 hinzugefügt wurde.

  In der folgenden Tabelle sind alle Fixes für diesen UI-Build mit Beschreibungen der Symptome für jedes Problem aufgeführt.

  Ticket	Symptom/Beschreibung
  Behobenes Problem 125964	Wenn ein Kunde, der Nicht-SD-WAN-Ziele (NSD) über Gateway bereitstellt, zur Seite Konfigurieren (Configure) > Netzwerkdienste (Network Services) > NSD über Gateway (NSD via Gateway) > Generisches IKEv2 (Generic IKEv2) navigiert und nach dem Hinzufügen von benutzerdefinierten Site-Subnetzen auf Speichern (Save) klickt, werden die Änderungen an der NSD-Konfiguration nicht gespeichert. Dieses Problem ist auf ungültige Felder („IKE-SA-Lebensdauer (Min.) (IKE SA Lifetime(min))“ und „IPsec-SA-Lebensdauer(Min.) (IPsec SA Lifetime(min))“) im Abschnitt Primäres VPN-Gateway (Primary VPN Gateway) zurückzuführen.
  Behobenes Problem 126602	Ein Kunde kann keinen Gateway-Pool zum Gateway-Pool der vorhandenen Partnerkonfiguration hinzufügen. Beim Versuch, dies zu tun, wird ein Fehler zurückgegeben, wenn der Gateway-Pool in der Partnerkonfiguration einen verwalteten Pool aufweist, weil die vorhandenen verwalteten Pool-IDs nicht von der Benutzeroberfläche entfernt werden.
  Behobenes Problem 127904	Wenn ein Benutzer eine statische Route erstellt und dieser Route einen ICMP-Test hinzufügt, installiert der Edge den ICMP-Test nicht und zeigt einen Analysefehler an. Dieses Problem ist darauf zurückzuführen, dass die IP des nächsten Hops und der Wert der Quell-IP vom Orchestrator als Null anstelle einer leeren Zeichenfolge an den Edge gesendet werden.
  Behobenes Problem 128279	Auf der Seite Konfigurieren (Configure) > Overlay-Flow-Steuerung (Overlay Flow Control) > Routenliste (Routes List) kann ein Benutzer maximal 256 Routen anzeigen und hat keine Möglichkeit, auf eine weitere Seite mit Routen zu klicken. Der feste Grenzwert von 256 Routen und die fehlende Paginierung wirken sich auf Kunden mit großen Unternehmen und zahlreichen Routen aus, die den festen Grenzwert von 256 Routen deutlich überschreiten.
  Behobenes Problem 128357	In einem Kundenunternehmen, in dem OSPFv2 oder OSPFv3 für das Routing verwendet und OE1 in der Liste Standardroute (Default Route) ausgewählt wird, wird die ungültige Option Keine (None) in der Liste Annoncieren (Advertise) angezeigt. Als gültige Optionen für „Annoncieren (Advertise)“ gelten lediglich Immer (Always) und Bedingt (Conditional).
  Behobenes Problem 129413	Wenn ein Benutzer ein VLAN auf Edge-Ebene konfiguriert und die standardmäßige DHCP-Startadresse ändert und die Änderungen speichert, wird die DHCP-Startadresse nicht überschrieben und die alte Adresse für das VLAN wird auf der Orchestrator-Benutzeroberfläche erneut aufgefüllt.
  Behobenes Problem 129926	Wenn ein Benutzer einen Edge ohne Seriennummer bereitstellt, schlägt die Edge-Aktivierung fehl.

• UI-Build R5204-20231019-GA wurde am 20.10.2023 veröffentlicht und ist der sechste UI-Build, der zu Orchestrator 5.2.0.4 hinzugefügt wurde.

  In der folgenden Tabelle sind alle Fixes für diesen UI-Build mit Beschreibungen der Symptome für jedes Problem aufgeführt.

  Ticket	Symptom/Beschreibung
  Behobenes Problem 127021	Ein mithilfe einer Automatisierungs-API konfiguriertes Nicht-SD-WAN-Ziel über Edge-Konfiguration wird nicht auf der Benutzeroberfläche angezeigt, da es im Automatisierungsskript zu einer Datenbeschädigung gekommen ist.
  Behobenes Problem 128706	Wenn ein Benutzer auf der Seite Monitor (Überwachen) > Edges > System versucht, das Diagramm zu vergrößern, wird nur eine schwarze Linie angezeigt. Das Diagramm reagiert weiterhin auf die Zeitraumauswahl im oberen Bereich der Seite, was als Problemumgehung verwendet werden kann.
  Behobenes Problem 129049	Wenn Edge-Überschreibung (Edge Override) deaktiviert ist, verwendet die Option „VLAN annoncieren (VLAN advertise)“ der Edge-Konfiguration nicht den aus der Profilkonfiguration übertragenen Annoncierungswert. Selbst wenn die Option „VLAN annoncieren (VLAN advertise)“ auf der Profilebene auf „false“ festgelegt ist, verwendet die Option „Edge annoncieren (Edge Advertise)“ bei deaktivierter Option „Überschreiben (Override)“ nicht den Annoncierungswert des Profils.
  Behobenes Problem 129271	Die Systemeigenschaftvco.enterprise.authentication.passwordPolicy mit Parameter disallowUsernameCharacters = 3 verhält sich nicht wie erwartet. Beispiel: Mit dem Benutzernamen „[email protected]“ überprüft die Benutzeroberfläche die Teilzeichenfolgen vis, ish, ..., t.c, .co, com (alle wie erwartet). Das Problem besteht darin, dass die Benutzeroberfläche auch om, m überprüft. Als Ergebnis wird auf der Benutzeroberfläche ein Fehler für ein eigentlich gültiges Kennwort ausgegeben. Die Problemumgehung besteht darin, disallowUsernameCharacters auf den Standardwert (-1) zurückzusetzen.
  Behobenes Problem 129560	Auf der Seite Diensteinstellungen (Service Settings) > Alarme und Benachrichtigung (Alerts & Notifications) können Partner- und Enterprise-Benutzer die Einstellung Enterprise-Alarme aktivieren (Enable Enterprise Alerts) nicht ändern.

• UI-Build R5204-20231013-0631-GA wurde am 13.10.2023 veröffentlicht und ist der fünfte UI-Build, der zu Orchestrator Version 5.2.0.4 hinzugefügt wurde.

  In der folgenden Tabelle sind alle Fixes für diesen UI-Build mit Beschreibungen der Symptome für jedes Problem aufgeführt.

  Ticket	Symptom/Beschreibung
  Behobenes Problem #120419	Ein Benutzer kann keine DHCP-Startadresse für ein VLAN auf Edge-Ebene festlegen, ohne zuerst das Edge-Überschreiben zu überprüfen und dann die Anzahl der vom Profil zugewiesenen Adressen zu ändern.
  Behobenes Problem #127035	Unter Konfigurieren (Configure) > Edge > Gerät (Device) > Hochverfügbarkeit (High Availability) wird nach dem Erstellen eines Clusters und dem Speichern der Änderungen auf der Benutzeroberflächenseite weiterhin der Standardwert Keine (None) angezeigt, obwohl der Cluster erfolgreich erstellt wurde. Dies ist ein kosmetisches Problem, und eine Aktualisierung der Benutzeroberflächenseite zeigt die richtige Konfiguration an.
  Behobenes Problem #127636	Auf der Seite Überwachen (Monitor) > Edge > Quellen (Sources) der Benutzeroberfläche funktioniert die Suche nach einer Quelle nach FQDN nicht wie erwartet, wenn die neue Benutzeroberfläche verwendet wird, weshalb ein Benutzer eine Quelle nicht mit einer Standardmethode finden kann. Dazu gehört auch, dass es nicht möglich ist, nach einer Teilzeichenfolge zu suchen.
  Behobenes Problem #127774	Wenn ein Benutzer unter Konfigurieren (Configure) > Edge > Gerät (Device) > Konnektivität (Connectivity) > Loopback-Schnittstellen (Loopback Interfaces) eine Loopback-Schnittstelle für einen Edge konfiguriert und Änderungen speichert, wird die Konfiguration nicht angewendet und nicht auf der Benutzeroberflächenseite angezeigt. Darüber hinaus zeigt die Benutzeroberfläche keine Fehlermeldung für diesen Fehler an, der den Benutzer über den Erfolg der Konfigurationsänderung in die Irre führt.
  Behobenes Problem #128371	Wenn ein Nicht-SD-WAN-Ziel über Edge oder ein Cloud-Security-Service (wie Zscaler) auf Profilebene deaktiviert ist, sollte der Orchestrator den Benutzer warnen, dass dem NSD bzw. CSS eine Business Policy zugeordnet ist, damit er die Business Policy auf Edge-Ebene überarbeiten kann. Andernfalls ist das Feld „Nicht-SD-WAN-Ziel über Edge/Cloud-Security-Service (Non SD-WAN Destination via Edge/ Cloud Security Service)“ leer, wenn der Benutzer zur Edge-Ebene navigiert und die Regel bearbeitet.
  Behobenes Problem #128620	Wenn Sie sich die Seite Konfigurieren (Configure) > Gerät (Device) > VPN-Dienste (VPN Services) ansehen, zeigen sowohl Profile als auch Edges keine verbundenen Hubs im Cloud-VPN-Konfigurationsbildschirm für die neue Benutzeroberfläche an, obwohl Zweigstellen-Edges eine Verbindung zu Hubs herstellen (was unter Überwachen (Monitor) > Pfade (Paths) bestätigt werden kann).
  Behobenes Problem #129253	Unter Diensteinstellungen (Service Settings) > Alarme und Benachrichtigungen (Alerts & Notifications) > Alarme (Alerts) > Benachrichtigungen (Notifications) kann ein Benutzer „SMS“ nicht als Benachrichtigungsmethode deaktivieren, da die Schiebereglerschaltfläche abgeblendet ist.

• UI-Build R5204-20231003-GA wurde am 04.10.2023 veröffentlicht und ist der vierte UI-Build, der zu Orchestrator Version 5.2.0.4 hinzugefügt wurde.

  In der folgenden Tabelle sind alle Fixes für diesen UI-Build mit Beschreibungen der Symptome für jedes Problem aufgeführt.

  Ticket	Symptom/Beschreibung
  Behobenes Problem #117923	Wenn ein Benutzer einen Edge bereitstellt und Text in das Feld Beschreibung (Description) eingibt, speichert die Orchestrator-Benutzeroberfläche diesen Text im Feld Benutzerdefinierte Info (Custom Info), und das Feld Beschreibung (Description) wird als leer angezeigt, wenn der neu bereitgestellte Edge angezeigt.
  Behobenes Problem #123070	Bei einem Kundenunternehmen mit einer Hub/Spoke-Topologie hat ein Benutzer bei der Konfiguration einer Business Policy, bei der Internet-Backhaul ausgewählt ist, nicht die Möglichkeit, Backhaul-Hubs auszuwählen, sodass Backhaul für diese Regel nicht funktioniert.
  Behobenes Problem #127037	Wenn ein Benutzer zur Registerkarte Überwachen (Monitor) > Edge > Quellen (Sources) navigiert, kann er den Hostnamen für einen Client nicht ändern. Ein Benutzer sollte die Möglichkeit haben, den Hostnamen für einen Client zu ändern, indem er auf das Symbol Bearbeiten (Edit) klickt und das Feld Hostname ändern (Change Hostname) öffnet. Sie können zwar den Text unter dem Feld „Hostname ändern (Change Hostname)“ eingeben, aber wenn sie auf Änderungen speichern (Save Changes) klicken, wird der neue Hostname nicht übernommen.
  Behobenes Problem #128628	Auf der Seite Kunden verwalten (Manage Customers) funktioniert das Herunterladen des CSV-Exports nicht. Die einzige Möglichkeit, wie ein Kunde diese Informationen erhalten kann, ist die Verwendung einer API, um die Informationen herunterzuladen und in ein CSV-Format zu konvertieren.
  Behobenes Problem #128667	Das Laden der Seite Kunden verwalten (Manage Customers) oder Partnerkunden verwalten (Manage Partner Customers) kann bis zu einer Minute dauern, wenn eine große Anzahl von Kunden im Orchestrator oder eine große Anzahl von Kunden unter einem Partner vorhanden ist.

• UI-Build R5204-20230927-GA wurde am 28.09.2023 veröffentlicht und ist der dritte UI-Build, der zu Orchestrator Version 5.2.0.4 hinzugefügt wurde.

  In der folgenden Tabelle sind alle Fixes für diesen UI-Build mit Beschreibungen der Symptome für jedes Problem aufgeführt.

  Ticket	Symptom/Beschreibung
  Behobenes Problem #126967	Nachdem OSPF für ein Profil aktiviert wurde, sind die Funktionen Erweiterte OSPF-Einstellungen (OSPF Advanced Settings)Erlernen eingehender Routen (Inbound Route Learning) und Routenankündigung (Route Advertisement) der Routing-Schnittstelle nicht zugänglich und es werden keine Felder zur Eingabe der erforderlichen Details angezeigt.
  Behobenes Problem #127006	Wenn ein Operator-Benutzer mit der Rolle „Support“ zur Seite SD-WAN > Netzwerkdienste (Network Services) navigiert und auf ein Nicht-SD-WAN-Ziel über Gateway (Non SD-WAN Destination via Gateway) klickt, hat er die Möglichkeit, auf +NEU (+NEW) zu klicken, um ein neues NSD zu erstellen und zu konfigurieren. Ein Operator in einer Support-Rolle sollte auf der Seite Netzwerkdienste (Network Services) nur über Leserechte verfügen und nicht die Möglichkeit haben, ein neues NSD über Gateway zu erstellen.
  Behobenes Problem #127843	Die Benutzeroberfläche wird bei der Lokalisierung in die italienische Sprache nicht korrekt angezeigt, was dazu führt, dass sich einige Navigationsregisterkarten überschneiden.
  Behobenes Problem #127849	Die Schaltfläche Zertifikat anzeigen (View Certificate) ist auf dem Bildschirm Edge > Konfiguration (Configuration) > Übersicht (Overview) ausgegraut und kann nicht angeklickt werden, wodurch Benutzer keine Edge-Zertifikate anzeigen können. Ohne UI-Fix kann ein Benutzer ein Edge-Zertifikat anzeigen, indem er auf der Registerkarte Konfiguration (Configuration) zur Edge-Liste navigiert und nach dem gewünschten Edge sucht.
  Behobenes Problem #127871	Die Seite Netzwerkübersicht (Network Overview) wird nicht automatisch aktualisiert und bietet auch nicht die Option, die automatische Aktualisierung zu aktivieren. Daher müssen die Benutzer die Seite manuell aktualisieren, um die neuesten Daten anzuzeigen.
  Behobenes Problem #128277	Wenn ein nativer Partner- oder Enterprise-Benutzer (ein Benutzer, der sich mit einem Benutzernamen und einem Kennwort beim Orchestrator anmeldet) versucht, sich mit einem abgelaufenen Kennwort anzumelden, tritt die Benutzeroberfläche in eine Schleife ein und zeigt einen leeren Bildschirm an.

• UI-Build R5204-20230920-GA wurde am 21.09.2023 veröffentlicht und ist der zweite UI-Build, der zu Orchestrator Version 5.2.0.4 hinzugefügt wurde.

  In der folgenden Tabelle sind alle Fixes für diesen UI-Build mit Beschreibungen der Symptome für jedes Problem aufgeführt.

  Ticket	Symptom/Beschreibung
  Behobenes Problem #106191	Wenn eine Edge-Schnittstelle mit statischen IP-Adressen auf Profilebene konfiguriert ist, kann ein Benutzer keine zusätzlichen Edge-Änderungen vornehmen.
  Behobenes Problem #113254	Partnerbenutzer können aufgrund von Berechtigungseinschränkungen keine Software-Images für ihre Kunden ändern.
  Behobenes Problem #117941	Das Kontrollkästchen „VLAN annoncieren (VLAN Advertise)“ wird immer als nicht aktiviert angezeigt. Auch nach dem Speichern der Änderungen nach dem Aktivieren des Kontrollkästchens wird das Kontrollkästchen „VLAN annoncieren (VLAN Advertise)“ in der Angular-Benutzeroberfläche wieder als nicht aktiviert angezeigt.
  Behobenes Problem #117993	Wenn ein Administrator versucht, das Kennwort für einen Unternehmens- oder Partnerbenutzer zurückzusetzen, schlägt die Anforderung fehl und es wird die Fehlermeldung Benutzer verfügt nicht über die für den Zugriff erforderlichen Berechtigungen (user does not have privileges required to access) angezeigt.
  Behobenes Problem #121469	Auf der Seite Globale Einstellungen (Global Settings) > Benutzerverwaltung (User Management) sieht ein Benutzer auf der Benutzerübersichtsseite immer ein Banner mit einer Sperrmeldung, obwohl der Benutzer wahrscheinlich entsperrt ist und sich anmelden kann.
  Behobenes Problem #126503	Wenn ein Benutzer in einem Unternehmen, das ein Nicht-SD-WAN-Ziel (NSD) über ein Gateway beliebigen Typs verwendet, eine Änderung des PSK-Werts für ein NSD bearbeitet und speichert, ignoriert die Orchestrator-Benutzeroberfläche die Änderung und setzt auf den ursprünglichen Standardwert zurück.
  Behobenes Problem #126257	Der oberste Wert auf der Seite Überwachen (Monitor) > Edge > Links ist für Benutzer nicht sichtbar, wenn viele extrem hohe Werte vorhanden sind. Dies liegt daran, dass die Höhe des Diagramms zuvor mit niedrigeren Werten summiert wurde, wodurch das Diagramm ungenau wurde und nicht an der Skala ausgerichtet werden konnte.

• UI-Build R5204-20230914-GA wurde am 15.09.2023 veröffentlicht und ist der erste UI-Build, der zu Orchestrator Version 5.2.0.4 hinzugefügt wurde.

  In der folgenden Tabelle sind alle Fixes für diesen UI-Build mit Beschreibungen der Symptome für jedes Problem aufgeführt.

  Ticket	Symptom/Beschreibung
  Behobenes Problem #108125	Wenn ein Benutzer auf der Seite Überwachen (Monitor) > Edge > Anwendung (Application) auf einen Punkt im Diagramm klickt, um weitere Details zu erhalten, und dann ein zweites Mal auf das Diagramm klickt, wird das Detailfenster nicht ordnungsgemäß geöffnet und ist funktionell unbrauchbar.
  Behobenes Problem #122918	Wenn ein Benutzer in einem Unternehmen, das eine Zweigstelle-zu-Hub-Topologie verwendet, den Bereich Konfigurieren (Configure) > Gerät (Device) > VPN-Dienste (VPN Services) > Cloud-VPN (Cloud VPN) der Benutzeroberfläche aufruft und versucht, eine Änderung an der Einstellung Zweigstelle-zu-Hub-Site (Branch to Hub Site) oder Zweigstelle-zu-Zweigstelle-VPN (Branch to Branch VPN) vorzunehmen, wird der Benutzer mit dem Hinweis blockiert, dass Hubs in Gebrauch sind. Dieses Problem kann auftreten, wenn andere Dienste in einer Business Policy verwendet werden und die Benutzeroberfläche diese fälschlicherweise bei der Berechnung der Backhaul-Nutzung berücksichtigt und die Änderung blockiert.
  Behobenes Problem #123619	Wenn eine Orchestrator-Instanz über keinen Internetzugang verfügt (z. B. eine lokal installierte Instanz), ist die Seite Überwachen (Monitor) > Edge > Übersicht (Overview) leer und es werden keine Informationen angezeigt.
  Behobenes Problem #123927	Wenn OSPF für ein VLAN konfiguriert ist, kann ein Benutzer die VLAN-Einstellung Passive Schnittstelle (Passive Interface) für einen Edge deaktivieren, obwohl der passive OSPF-Modus der einzige unterstützte Modus ist.
  Behobenes Problem #124801	Wenn ein Operator-Benutzer die Systemeigenschaft (System Property) 'Session.options.enableEdgeLicensing' auf False setzt, muss ein Benutzer immer noch einen Edge erstellen, indem er zunächst eine Edge-Lizenz auswählt. Wenn diese Systemeigenschaft auf „False“ festgelegt wird, können von Partnern kontrollierte Orchestrator-Instanzen den Edge-Lizenzierungsschritt umgehen, wenn sie keine Edge-Lizenz für ihren Edge-Bereitstellungsprozess benötigen. Bei diesem Fehler muss der Benutzer jedoch weiterhin eine Lizenz auswählen.
  Behobenes Problem #125309	Wenn ein Benutzer IPv6 auf der Edge-Ebene unter Konfigurieren (Configure) > Gerät (Device) > IPv6-Einstellungen (IPv6 Settings) deaktiviert, kann die OSPF-Option für IPv6 weiterhin bearbeitet, aktiviert und gespeichert werden.
  Behobenes Problem #125393	Bei der Betrachtung der Tabelle Konfigurieren (Configure) > Gerät (Device) > VLAN auf der Profilebene fehlt die Spalte OSPF.
  Behobenes Problem #125710	Wenn in einem Unternehmen, das eine Zweigstelle-zu-Hub-Topologie verwendet, ein Edge, der in einem Cloud-VPN verwendet wird, aus dem Unternehmen gelöscht wird, kann der Benutzer später keinen Hub-Edge entfernen, der in einem Zweigstelle-zu-Zweigstelle-VPN (Branch to Branch VPN) verwendet wird, und die Bearbeitung der Geräteeinstellungen ist blockiert.
  Behobenes Problem #126403	Aufgrund eines Problems mit dem Software-Image 5.2.0.4 kann es vorkommen, dass die Benutzeroberfläche die Seite Partnerübersicht (Partner Overview) nicht lädt.
  Behobenes Problem #127007	Wenn ein Benutzer in einem Unternehmen, das eine Hub/Spoke-Topologie verwendet, eine Einstellung auf der Seite Konfigurieren (Configure) > Gerät (Device) eines Profils ändert, wird die Hub-Reihenfolge automatisch auf den Standardwert geändert, was sich auf alle Edges mit diesem Profil auswirkt.

• Behobenes Problem 65668: Ein Kunde, der den Cloud Web Security-Dienst abonniert hat, kann auf der Seite „Gateway-Zuweisung (Gateway Assignment)“ nicht erkennen, welche VMware SD-WAN Gateways für die Verwaltung von Cloud Web Security-Datenverkehr zugewiesen sind.

  Der Kunde sollte sehen, welche primären und sekundären Zuweisungen es für die Gateways gibt (auch als SASE PoPs bekannt), die Cloud Web Security verarbeiten.

• 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 des Sicherungslinks sollte als „Standby“ und „Leerlauf (Idle)“ mit einem grauen Statuspunkt angezeigt werden, aber stattdessen wird im Verbindungsstatus weder der Link-Typ noch der Sicherungsstatus angezeigt. Es handelt sich um einen kosmetischen Fehler, da der WAN-Link seine Funktion als Sicherung erfüllt.

• 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 120398: Ein Partnerbenutzer kann kein neues Konfigurationsprofil für ein von ihm verwaltetes Kundenunternehmen erstellen.

   Wenn der Partnerbenutzer versucht, ein Konfigurationsprofil für seinen Kunden zu erstellen, gibt der Orchestrator die Fehlermeldung „Ungültiger Proxy-Unternehmenskontext für Operator-Profil (invalid proxy enterprise context for operator profile)“ aus. Dieses Problem tritt bei jeder Partnerrolle mit Konfigurationsberechtigungen auf.

  

• Behobenes Problem 121118: Ein Enterprise-Benutzer hat nicht die Möglichkeit, ein Diagnosepaket zu erstellen oder ein Packet Capture auf VMware SASE Orchestrator zu erstellen und herunterzuladen.

  Dies gilt für alle Enterprise-Benutzerrollen (einschließlich Superuser). Die Erwartung ist, dass ein Enterpruse-Benutzer unter SD-WAN > Diagnose (Diagnostics) die Option für folgende Aufgaben sehen sollte:

  1. Generieren (aber nicht herunterladen) eines Diagnosepakets.

  2. Generieren und Herunterladen einer Packet Capture.

  Er sieht jedoch nur die Optionen Remote-Diagnose (Remote Diagnostics) und Remote-Aktionen (Remote Actions).

  

  Wenn dieses Problem bei einem Orchestrator-Build ohne Fix für dieses Problem auftritt, wenden Sie sich an den SD-WAN-Support, der das Diagnosepaket für Sie erstellen kann.

• Behobenes Problem 121526: Ein Benutzer mit einer Rolle „Enterprise: Read Only“ ist nicht berechtigt, die Diagramme „Überwachen (Monitor) > Edges > QoE“ auf der VMware SASE Orchestrator-Benutzeroberfläche anzuzeigen.

  Der Versuch, das QoE-Diagramm anzuzeigen, führt zu einem Fehlerbanner mit der Meldung „Benutzer verfügt nicht über die Berechtigung [READ:ENTERPRISE_EVENT], die für den Zugriff auf [event/getEnterpriseEventsList] erforderlich ist“ (user does not have privilege [READ:ENTERPRISE_EVENT] required to access [event/getEnterpriseEventsList]).

  

• Behobenes Problem 122113: Ein Benutzer kann nicht nach dem Ereignis 'DNS_CACHE_LIMIT_REACHED' auf der Seite „Ereignisse (Events)“ der VMware SASE Orchestrator-Benutzeroberfläche suchen.

  Dieses Ereignis wird veröffentlicht, wenn es auf der Seite Überwachen > Ereignisse (Monitor > Events) für ein Kundenunternehmen ausgelöst wird, aber es wird nicht als suchbarer Wert aufgeführt, wenn versucht wird, die Suchfunktion zu verwenden. Infolgedessen kann der Benutzer nicht sehen, wie oft dieses Ereignis in einem bestimmten Zeitraum veröffentlicht wurde.

• Behobenes Problem 123002: Das Upgrade eines VMware SD-WAN Edge kann fehlschlagen, weil die Software nur teilweise heruntergeladen wird, bevor die Verbindung vorzeitig geschlossen wird.

  Das Problem wird darauf zurückgeführt, dass VMware SASE Orchestrator einen falschen Zeitüberschreitungswert für den Download aufweist, der dazu führt, dass einige Downloadsitzungen geschlossen werden, bevor der Download abgeschlossen ist. Mit dem Fix wird der korrekte Zeitüberschreitungswert wiederhergestellt, um sicherzustellen, dass der Download abgeschlossen wird.

• Behobenes Problem 123053: Wenn ein Benutzer einen SNMP v3-Namen konfiguriert, lehnt die VMware SASE Orchestrator-Benutzeroberfläche jeden Namen mit einem nicht-alphanumerischen Zeichen mit einer Fehlermeldung ab.

  Dies geschieht beim Ausführen von Konfigurieren (Configure) > Gerät (Device) > Telemetrie (Telemetry) > SNMP für SNMP-Namen der Version 3. Der Orchestrator lehnt nicht-alphanumerische Zeichen wie [@\'"/,#%&*(){}_=`:?[]§;|><] ab. Dies bedeutet, dass ein Name wie User_23 mit der Fehlermeldung „Zeichen, die in diesem Feld nicht zulässig sind (Characters not allowed in this field)“ abgelehnt wird. Dadurch ist der Benutzer bei der Verwendung von Zeichen für SNMP v3-Namen eingeschränkt.

  

• Behobenes Problem 123150: Bei einer Unternehmens-Site eines Kunden, die eine Hochverfügbarkeitstopologie verwendet, zeigt VMware SASE Orchestrator bei der Konfiguration einer VNF und der anschließenden Aktivierung der VNF-Einfügung nicht an, dass die VNF-Einfügung erfolgreich war, und der VNF-Status wird nicht auf dem HA-Edge angezeigt.

  Das Problem ist darauf zurückzuführen, dass der Orchestrator eine VNF-Einstellung für die Schnittstelleneinfügung fälschlicherweise als „False“ sendet, selbst wenn es Schnittstellen gibt, bei denen die VNF-Einfügung unter Konfigurieren (Configure) > Edge > Schnittstelleneinstellungen (Interface settings) eingeschaltet ist. Da dieses Feld in der Orchestrator-Konfiguration als „False“ gesendet wird, aktiviert der HA-Edge die VNF-Einfügung auf keiner Schnittstelle.

  Bei einem Orchestrator ohne einen Fix für dieses Problem besteht die Problemumgehung darin, HA für diese Site zu deaktivieren und den HA-Edge in einen eigenständigen Edge umzuwandeln, jeden VNF neu zu konfigurieren und anschließend die VNF-Einfügung zu aktivieren. Nach erfolgreicher Konfiguration können Sie HA für die Site erneut aktivieren.

• Behobenes Problem 123346: Bestehende Kundenunternehmen können die Funktion „Firewallprotokollierung für Orchestrator (Firewall Logging to Orchestrator)“ auf einem VMware SASE Orchestrator 5.2.0 nicht aktivieren.

  Obwohl die Protokollierung der gehosteten VMware Edge-Firewall (VMware Hosted Edge Firewall Logging) als Funktion in Version 5.2.0 hinzugefügt wurde, sahen Kunden, die vor dem Upgrade ihres Orchestrators auf 5.2.0 erstellt wurden, nicht die Option, diese Funktion nach dem Upgrade zu aktivieren.

• Behobenes Problem 123551: Ein Benutzer würde feststellen, dass die Orchestrator-Benutzeroberfläche beim Erstellen oder Bearbeiten eines Kennworts für eine VMware SD-WAN Edge-WLAN-Schnittstelle ein Kennwort mit 10 Zeichen verlangt, obwohl es eigentlich 8 Zeichen lang sein sollte.

  Die 10-Zeichen-Anforderung wurde versehentlich in Orchestrator Version 5.1.0 als Teil einer falschen Klassifizierung des WLAN-Prozesses erstellt und wird in diesem Build wieder auf die korrekten 8 Zeichen zurückgesetzt.

• Behobenes Problem 123749: Ein Enterprise-Administrator oder Enterprise-Support-Benutzer kann die Option „Diagnosepakete (Diagnostic Bundles)“ auf dem Bildschirm „Diagnose (Diagnostics)“ der VMware SASE Orchestrator-Benutzeroberfläche nicht anzeigen, wenn seine Rolle entsprechend angepasst ist.

  Standardmäßig können diese Rollen die Option Diagnose > Diagnosepakete (Diagnostics > Diagnostic Bundles) auf der Benutzeroberfläche nicht sehen, aber die Rollenanpassung kann beiden Rollen Berechtigungen für Diagnosepakete und PCAPs hinzufügen, wodurch der Bildschirm „Diagnosepakete (Diagnostic Bundles)“ hinzugefügt werden sollte.

• Behobenes Problem 124073: Wenn ein Benutzer ein Nicht-SD-WAN-Ziel über Gateway mithilfe redundanter Gateway-Tunnel mit AES-256-Verschlüsselung konfiguriert, verwendet der redundante Standby-Gateway-Tunnel weiterhin die AES-128-Verschlüsselung.

  Ein Benutzer würde auf der Orchestrator-Benutzeroberfläche zu Konfigurieren (Configure) > Netzwerkdienste (Network Services) navigieren und den Verschlüsselungsalgorithmus für ein NSD mit redundanten Tunneln in AES-256 ändern. Basierend auf der API-Antwort würde der Benutzer feststellen, dass der redundante Tunnel weiterhin AES-128 verwendet. Dies ist das Ergebnis eines Fehlers bei der API, die die Änderung der Tunnelverschlüsselung verarbeitet.

• Behobenes Problem 124129: Wenn die Systemeigenschaft, die die Verfügbarkeit des Erweiterten Firewalldiensts (Enhanced Firewall Service, EFS) steuert, auf „True“ festgelegt ist, wird für jedes neue Kundenunternehmen, das dem VMware SASE Orchestrator hinzugefügt wird, EFS standardmäßig aktiviert.

  Die Systemeigenschaft enterprise.capability.enableATP ist für vorherige 5.2.0-Builds standardmäßig auf True festgelegt. Wenn diese Eigenschaft auf True festgelegt ist, würde ein Benutzer bei der Überprüfung der globalen Kundeneinstellungen für ein neues Kundenunternehmen feststellen, dass EFS standardmäßig aktiviert ist. Das erwartete Verhalten besteht darin, dass EFS für neue Kundenunternehmen nicht standardmäßig aktiviert ist, sondern explizit aktiviert werden muss.

  Dies wird im Build 5.2.0.4 behoben, indem die Eigenschaft enterprise.capability.enableATP standardmäßig auf False festgelegt ist.

• Behobenes Problem 124273: Ein Operator-Benutzer stellt möglicherweise fest, dass sein Versuch, ein Upgrade von VMware SASE Orchestrator auf einen 5.1.x oder 5.2.x Build durchzuführen, fehlschlägt.

  Wenn dieses Problem auftritt, werden die Protokolle wie folgt angezeigt:

  • fatal: [vcoxxx]: FAILED! => changed=true
  • ...
  • UPGRADE - DEBUG - Starting VCO software update preinstall
  • UPGRADE - WARNING - E: Unable to locate package linux-image-unsigned-x.x.x
  • UPGRADE - WARNING - E: Couldn't find any package by glob 'linux-image-unsigned-x.x.x-xxx'
  • UPGRADE - WARNING - E: Couldn't find any package by regex 'linux-image-unsigned-x.x.x-xxx'
  • UPGRADE - WARNING - E: No packages found
  • UPGRADE - ERROR - installer failed with return code 100. See /var/log/vco_software_update.log for details
  • UPGRADE - WARNING - Verification key does not exist: xxx

• Behobenes Problem 124315: Ein Benutzer scheint die Möglichkeit zu haben, einen BGP-Filter auf der Edge-Ebene zu bearbeiten, der mithilfe der Orchestrator-Benutzeroberfläche auf der Profilebene erstellt wurde.

  Während ein Benutzer die Profileinstellungen auf einem Edge immer mithilfe der Edge-Überschreibung überschreiben kann, sollte der Benutzer die tatsächlichen Profileinstellungen nie bearbeiten können. In diesem Fall vermittelt die Benutzeroberfläche dem Benutzer den Eindruck, dass er einen BGP-Filter bearbeiten kann, der aus einem Profil nach unten verschoben wurde. Dies ist ein kosmetischer Fehler, und nichts, was der Benutzer am BGP-Filter des Profils ändert, wird auf diesen oder einen anderen Edge angewendet.

• Behobenes Problem 124778: Wenn ein Kunde zu „Globale Einstellungen > Kundenkonfiguration (Global Settings > 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, der Standardschnittstelle von Orchestrator-Instanzen ab Version 5.2.0.

• Behobenes Problem 124798: Ein Benutzer kann die Seriennummer eines VMware SD-WAN Edge auf der VMware SASE Orchestrator-Benutzeroberfläche nicht bearbeiten.

  Bei einem Edge, der zwar bereitgestellt oder per RMA ersetzt, jedoch noch nicht aktiviert wurde, befand sich der Benutzer auf dem Bildschirm SD-WAN > Konfigurieren (Configure) > Edge > Übersicht (Overview), und unter Edge-Status (Edge Status) war die Seriennummer (Serial Number) des Edge zwar vorhanden, aber als schreibgeschützter Text und nicht editierbar. Dies ist ein Problem, da manche Kunden die Seriennummer des zu aktivierenden Edge erst bei der Lieferung vor Ort kennen und die Möglichkeit benötigen, dieses Feld zu bearbeiten, damit es mit dem bereitgestellten Edge übereinstimmt.

• Behobenes Problem 125456: Wenn ein Benutzer in einem Kundenunternehmen, in dem VNFs verwendet werden, versucht, eine Edge-Gerätekonfiguration zu ändern, lehnt VMware SASE Orchestrator die Änderungen beim Versuch, sie zu speichern, ab.

  Die Konfigurationsänderung kann so geringfügig sein wie das Hinzufügen eines Kommentars zu einer vorhandenen statischen Route, und wenn ein VNF aktiviert ist, speichert die Orchestrator-Benutzeroberfläche die Änderung nicht. Der Benutzer sieht möglicherweise ein Banner „Script Injection-Fehler (Script injection error)“ am unteren Rand des Benutzeroberflächenbildschirms.

  Auf einer Orchestrator-Instanz ohne Fix für dieses Problem besteht die Problemumgehung darin, die VNFs vorübergehend zu deaktivieren und dann die Konfigurationsänderungen zu speichern. Sobald diese erfolgreich gespeichert wurden, kann der Benutzer die VNFs erneut aktivieren.

Behoben in Orchestrator-Version R5203-20230809-GA

Orchestrator-Build R5203-20230809-GA wurde am 9. August 2023 veröffentlicht und ist der dritte Orchestrator-Rollup für Version 5.2.0.

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

• Behobenes Problem 121118: Ein Enterprise-Benutzer hat nicht die Möglichkeit, ein Diagnosepaket zu erstellen oder ein Packet Capture auf VMware SASE Orchestrator zu erstellen und herunterzuladen.

  Dies gilt für alle Enterprise-Benutzerrollen (einschließlich Superuser). Die Erwartung ist, dass ein Enterpruse-Benutzer unter SD-WAN > Diagnose (Diagnostics) die Option für folgende Aufgaben sehen sollte:

  1. Generieren (aber nicht herunterladen) eines Diagnosepakets.

  2. Generieren und Herunterladen einer Packet Capture.

  Er sieht jedoch nur die Optionen Remote-Diagnose (Remote Diagnostics) und Remote-Aktionen (Remote Actions).

  

• Behobenes Problem 121884: Ein VMware SASE Orchestrator verarbeitet und speichert möglicherweise weiterhin Firewallprotokolldateien, obwohl die Systemeigenschaft für diese Aktion auf „false“ festgelegt ist.

  Wenn die Systemeigenschaft storage.firewall.logs.file.enable auf „false“ gesetzt ist, besteht das erwartete Verhalten darin, dass der Orchestrator die Verarbeitung und Speicherung von Firewallprotokolldateien auf globaler Ebene einstellt und kein Kundenunternehmen in der Lage sein sollte, neue Firewallprotokolle zu erhalten, unabhängig von den eigenen Einstellungen auf Unternehmensebene. Diese Eigenschaft wird als Hilfsmittel zur Behebung von Leistungsproblemen des Orchestrators verwendet, die möglicherweise mit der Verarbeitung von Firewallprotokollen zusammenhängen. In den Orchestrator-Versionen 5.2.0.1 und 5.2.0.2 wird diese Einstellung nicht befolgt.

• Behobenes Problem 122132: Ein Kunde, der Erweiterte Firewalldienste nutzt, kann möglicherweise keine aktualisierten Definitionen für die Funktionen des Systems zur Erkennung von Eindringversuchen (Intrusion Detection System, IDS) und des Systems zur Abwehr von Eindringversuchen (Intrusion Prevention System, IPS) herunterladen.

  Das Problem wird auf Operator-Profile der Version 5.2.0 zurückgeführt, die das Modul atpMetadata nicht enthalten. Edges, die ein 5.2.0-Operator-Profil verwenden, können keine IDPS-Signaturbündel für die Anwendung von IDS/IPS herunterladen und erhalten daher nicht das erwartete Schutzniveau der Erweiterten Firewalldienste.

• Behobenes Problem 122797: Ein Benutzer kann die Einstellung „Zweigstelle-zu-Zweigstelle-VPN aktivieren (Enable Branch to Branch VPN)“ nicht für ein Profil aktivieren, das von einem Hub Edge verwendet wird.

  Auf dem Bildschirm Konfigurieren > Profil (Profile) > Gerät (Device) > VPN-Dienste (VPN Services) erlaubt die Orchestrator-Benutzeroberfläche dem Benutzer, das Kontrollkästchen für Zweigstelle-zu-Zweigstelle-VPN aktivieren (Enable Branch to Branch VPN) zu aktivieren, aber beim Versuch, die Konfiguration zu speichern, gibt die Orchestrator-Benutzeroberfläche die Fehlermeldung aus: „Änderungen konnten nicht gespeichert werden. Es gibt einen oder mehrere Fehler in Ihrer Konfiguration. (Cannot save changes. There is one or more errors within your configuration).“ Dieser Fehler teilt dem Benutzer nicht mit, was der tatsächliche Fehler ist. Dieses Problem tritt nur auf der neuen Benutzeroberfläche auf, der Standard-Benutzeroberfläche für Release 5.2.x.

• Behobenes Problem 123384: Wenn der Benutzer beim Zugriff auf die Seite „SD-WAN > Konfigurieren (Configure) > Edges“ oder „SD-WAN > Überwachen (Monitor) > Edges“ auf dem VMware SASE Orchestrator einen Filter hinzufügt, um nach Operator-Profil, Konfigurationsprofil oder Analysen zu sortieren, gibt die Seite keine Ergebnisse mit einem Fehler zurück.

  Der Benutzer würde eine Seite mit der Meldung Fehler beim Laden der Daten (Failed to Load Data) sehen, und wenn er die Konsole des Browsers aufruft, würde er auch einen Eintrag „API-Fehler (API Error)“ sehen.

  

• Behobenes Problem 123609: Ein Benutzer kann keine Änderungen an der BGP-Filterliste speichern, wenn es mehr als zehn BGP-Filterregeln gibt.

   Der Benutzer fügt BGP-Filter auf der Seite SD-WAN > Konfigurieren (Configure) > Profil (Profile) / Edges > Geräte (Device) > Routing und NAT (Routing & NAT) > BGP des Orchestrator hinzu. Wenn der Benutzer der Filterliste so viele neue Filterregeln hinzufügt, dass die Gesamtzahl von zehn überschritten wird, schlägt das Speichern dieser Konfiguration fehl und die Orchestrator-Benutzeroberfläche zeigt die Fehlermeldung „Änderungen können nicht gespeichert werden. Es gibt einen oder mehrere Fehler in Ihrer Konfiguration (Cannot save changes. There is one or more errors within your configuration)“.

  Das Problem wird dadurch verursacht, dass die neue Benutzeroberfläche (die Standard-Benutzeroberfläche in Version 5.2.x) eine falsche Indizierung in der Tabelle BGP-Filterregeln verwendet, die dazu führt, dass sie auf der zweiten Seite der Paginierung beginnt (11 Regeln und mehr).

Behoben in Orchestrator-Version R5202-20230729-GA

Orchestrator-Build R5202-20230729-GA wurde am 2. August 2023 veröffentlicht und ist der zweite Orchestrator-Rollup für Version 5.2.0.

Dieser Orchestrator-Rollup-Build behebt die folgenden kritischen Probleme seit dem ersten Orchestrator-Rollup, R5201-20230623-GA.

• Behobenes Problem 116666: Ein Partner mit einer Superuser-Rolle hat nicht die Möglichkeit, erweiterte Firewalldienste für eines der von ihm unterstützten Kundenunternehmen zu aktivieren.

  Diese Option sollte für einen Partner-Superuser verfügbar sein, wenn er auf dem VMware SASE Orchestrator zu Globale Einstellungen (Global Settings) > Kundenkonfiguration (Customer Configuration) navigiert.

• 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 auf, da aufgrund eines Front-End-Problems WAN-Verbindungen im Status Beeinträchtigt (Degraded) oder Ausgefallen (Down) nicht berücksichtigt werden. Die Überwachung funktioniert auf der klassischen Benutzeroberfläche wie erwartet.

• 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 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 ein Benutzer entweder eine Business Policy oder eine Firewallregel auf Profilebene konfiguriert und dann auf Edge-Ebene außer Kraft setzt, 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 die Option „Edge-Überschreiben (Edge Override)“ aktiviert ist, sollten als einfarbige Symbole angezeigt werden und sind stattdessen leer, wenn die neue Benutzeroberfläche verwendet wird, die die Standard-Benutzeroberfläche für Version 5.2.0 ist. Der Classic Orchestrator zeigt die Symbole korrekt als ausgefüllt an, wenn ein Edge-Überschreiben für eine bestimmte Kategorie konfiguriert wurde.

  

• Behobenes Problem 120070: Wenn ein Kunde einen Cloud-Security-Service (CSS) mit einem Zscaler-Typ bereitstellt, bei dem „Bereitstellung von Cloud-Dienst automatisieren (Automate Cloud Service Deployment)“ aktiviert ist, und ein Benutzer zu „Überwachen (Monitor) > Netzwerkdienste (Network Services) > Cloud Security Services > Bereitstellungsstatus (Deployment Status)“ wechselt, sieht der Benutzer keine Option zum Anzeigen des Status für dieses CSS.

  Dieser Überwachungsbildschirm und insbesondere der Bereitstellungsstatus sind wichtig für alle Kunden, die einen automatisierten Zscaler-CSS bereitstellen.

• Behobenes Problem 120606: Beim Versuch, eine neue Rolle auf „Kunde (Customer) > 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.

  

• Behobenes Problem 120774: Wenn ein Kunde Nicht-SD-WAN-Ziele über Gateway (NSD) einsetzt, kann es vorkommen, dass der Benutzer die IKE-Einstellungen für einen NSD-Tunnel nicht sieht, wenn er zu „Überwachen (Monitor) > Netzwerkdienste (Network Services)“ oder „Konfigurieren (Configure) > Netzwerkdienste (Network Services)“ navigiert und auf einen NSD klickt.

  Ein Benutzer beobachtet den folgenden Fehler: Fehler bei Lesen von undefinierten Eigenschaften ('clearDontFragmentBit' gelesen) (Cannot read Properties of undefined (reading 'clearDontFragmentBit')) und es wird nichts angezeigt.

• 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, die die Standard-Benutzeroberfläche für den 5.2.0 Orchestrator ist. Daher gibt es keine Problemumgehung für diese Version, solange es keinen Fix gibt.

• Behobenes Problem 121472: Wenn die Zwei-Faktor-Authentifizierung (2FA) für ein Kundenunternehmen aktiviert ist, hat ein einzelnes Benutzerkonto nicht die Möglichkeit, 2FA für sich zu deaktivieren.

  Wenn 2FA für einen Kunden aktiviert ist, sollte es eine Checkbox geben, um es entweder zu deaktivieren oder es zu verlangen, wenn man auf die Kontodetails eines Benutzers klickt. Mit dem Fix wird eine Umschaltoption für 2FA hinzugefügt, die deutlich macht, welchen 2FA-Status der jeweilige Benutzer hat.

• Behobenes Problem 121751: Ein Operator oder Partner kann das VMware SD-WAN Gateway, das von einem Nicht-SD-WAN-Ziel (NSD) verwendet wird, nicht über ein Gateway einem anderen Gateway zuweisen, wenn er die VMware SASE Orchestrator UI verwendet.

  Wenn ein Operator oder Partner-Superuser zu Gateways > Gateway-Verwaltung (Gateway Management) navigiert, kann er das Gateway, das ein NSD via Gateway verwendet, nicht einem anderen Gateway zuweisen (dies sind Gateways, die mit der Rolle „Sicheres VPN-Gateway (Secure VPN Gateway)“ konfiguriert sind). Der Benutzer kann auf ein anderes Gateway klicken, aber die Orchestrator-Benutzeroberfläche lässt es nicht zu, dass der Benutzer anschließend auf die Schaltfläche Gateway zuweisen (Assign Gateway) klickt, um die Neuzuweisung abzuschließen.

• Behobenes Problem 121835: Wenn ein Benutzer versucht, die Funktion „Annoncieren (Advertise)“ auf einer Loopback-Schnittstelle zu aktivieren, wird das Popup-Fenster „Save (Speichern)“ nicht angezeigt, und der Benutzer hat nicht die Möglichkeit, Konfigurationsdaten für Edge-Geräteeinstellungen zu speichern.

  Wenn ein Benutzer die Bearbeitung einer Loopback-Schnittstelle in Konfigurieren (Configure) > Edge > Gerät (Device) versucht, wird der Dialog Bearbeiten (Edit) nicht richtig geladen. Dies wird dadurch verursacht, dass die Benutzeroberfläche OSPF-Parameter in einem anderen Segment als dem globalen Segment erwartet, während die OSPF-Konfiguration nur im globalen Segment zulässig ist. Dieses Problem tritt nur in Unternehmen mit einem SASE Orchestrator auf, der von einer früheren Version auf 5.2.0 aktualisiert wurde, und nur, wenn das Unternehmen Loopback-Schnittstellen auf mehreren Segmenten enthält.

  Wenn das Kundenunternehmen mit einem Orchestrator arbeitet, der dieses Problem nicht behebt, besteht die einzige Abhilfe darin, die Geräteeinstellungen mithilfe von API-Aufrufen zu ändern.

• Behobenes Problem 121858: Bei einem VMware SASE Orchestrator, der in einer Disaster Recovery (DR)-Topologie eingesetzt wird, kann die DR-Synchronisierung nach einem Upgrade des Orchestrators auf den Rollup-Build 5.2.0.1 fehlschlagen, was zu großen Datenlücken nach einem Orchestrator-Failover führt.

  Als Teil des Orchestrator-Software-Upgrades wird das ClickHouse-Datenbankmanagementsystem (DBMS) von 20.3.19.4 auf 22.3.13.80 aktualisiert. Während des Upgrades löscht der DBMS-Prozess alle Gruppenberechtigungen und schränkt den Zugriff auf das Datenverzeichnis auf das DBMS allein ein. Dieses Verhalten unterbricht den rsync-basierten Replikationsprozess und führt dazu, dass die DBMS-Daten zwischen dem aktiven und dem Standby-Orchestrator nicht synchronisiert werden können.

  Auf einem Orchestrator mit Build 5.2.0.1 kann ein Operator das Berechtigungsproblem auf dem aktiven Orchestrator mit dem folgenden Befehl beheben: chmod g+rx /store3/clickhouse.

• Behobenes Problem 121993: Ein Benutzer hat eventuell nicht die Möglichkeit, die VLAN-Eigenschaften für einen VMware SD-WAN Edge auf der VMware SASE Orchestrator UI zu bearbeiten.

  Das Problem betrifft nicht alle VLANs, die von einem Edge verwendet werden, aber wenn das Problem auftritt, klickt der Benutzer auf ein VLAN in der Benutzeroberfläche und das Ergebnis ist, dass nichts passiert.

  Wenn bei einem Kunden dieses Problem auf einem Orchestrator auftritt, ohne dass eine Lösung für dieses Problem gefunden wurde, wenden Sie sich an den SD-WAN-Support.

• Behobenes Problem 122010: Wenn ein Operator die Systemeigenschaften auf einem VMware SASE Orchestrator mit Orchestrator-Build 5.2.0.1 aufruft und eine Suche durchführt, wird die Seite möglicherweise nicht geladen.

  Dieses Problem wird ausgelöst, wenn eine oder mehrere Systemeigenschaften einen Nullwert haben (mit anderen Worten, der Wert ist nicht definiert).

• 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, für die Edges unter diesem Profil 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. Da die neue Benutzeroberfläche die Standard-Benutzeroberfläche für einen Orchestrator der Version 5.2.0 ist, gibt es für dieses Problem keine Abhilfe.

• Behobenes Problem 122520: In einem Kundenunternehmen, das OSPF für das Routing verwendet und auch Loopback-Schnittstellen einsetzt, kann es vorkommen, dass die Loopback-Schnittstelle überhaupt nicht geöffnet ist.

  Dieses Problem wird darauf zurückgeführt, dass VMware SASE Orchestrator OSPF nicht auf die Loopback-Schnittstelle lädt, wenn OSPF auf einer Schnittstelle konfiguriert ist.

• Behobenes Problem 122866: Wenn ein Benutzer einen BGP-Hand-Off von einem Partner-Gateway löscht, löscht VMware SASE Orchestrator denselben BGP-Hand-Off auch von allen anderen Partner-Gateways im selben Gateway-Pool.

  Dieses Problem tritt unabhängig davon auf, ob es sich bei dem Benutzer um einen Operator oder einen Partner handelt, und tritt nur auf der neuen Benutzeroberfläche auf, die die Standard-Benutzeroberfläche für Release 5.2.0 Orchestrator ist.

  Die Problemumgehung besteht darin, das Partner-Gateway, für das die BGP-Übertragung gelöscht werden muss, zu isolieren, indem es vorübergehend aus dem Gateway-Pool entfernt wird. Dadurch wird verhindert, dass andere Partner-Gateways beeinträchtigt werden. Nachdem die BGP-Weitergabe gelöscht wurde, kann der Benutzer das Partner-Gateway wieder in den ursprünglichen Gateway-Pool aufnehmen.

• Behobenes Problem 122977: Ein Benutzer hat eventuell nicht die Möglichkeit, die erweiterten Firewalldienste auf der VMware SASE Orchestrator UI zu aktivieren.

  Diese Option sollte an drei Stellen angezeigt werden:

  • Globale Einstellungen (Global Settings)> Kundenkonfiguration (Customer Configuration) > SD-WAN-Einstellungen (SD-WAN Settings) > Funktionszugriff (Feature Access) direkt unter der Option Statusbehaftete Firewall (Stateful Firewall).

  • Konfigurieren (Configure) > Profil (Profile) > Firewall als Option, sobald der Firewallstatus auf Ein festgelegt ist.

  • Konfigurieren (Configure) > Edge > Firewall als Option, sobald der Firewallstatus auf Ein festgelegt ist.

  In allen anderen Fällen fehlt sie.

  Das Problem wird dadurch verursacht, dass der Orchestrator fälschlicherweise davon ausgeht, dass das Kundenunternehmen nicht mit der Funktion Erweiterte Firewalldienste (Enhanced Firewall Services) kompatibel ist, obwohl es dies ist.

Behoben in Orchestrator-Version R5201-20230623-GA

Die Orchestrator-Version R5201-20230623-GA wurde am 26.06.2023 veröffentlicht und ist der erste Orchestrator-Rollup für Version 5.2.0.

Dieser Rollup-Build für Orchestrator behebt die folgenden kritischen Probleme seit dem ursprünglichen GA-Build, R5200-20230529-GA.

Wichtig:

Kunden, die einen lokalen Orchestrator mit dem 5.2.0.0-Build verwenden, wird ein Upgrade auf 5.2.0.1 dringend empfohlen.

• 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 113254: Ein Partner-Administrator mit einer Superuser- oder Standardrolle kann das Standardoperatorprofil für einen von ihm verwalteten Kunden nicht ändern.

  Derselbe Partner-Administrator würde feststellen, dass er diese Aktion bei Verwendung der klassischen Benutzeroberfläche durchführen könnte, die in Release 5.2.0 nicht verfügbar ist.

• 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 115624: Bei einem VMware SASE Orchestrator kann es zu einer hohen CPU-Nutzung und Instabilität sowie offensichtlich 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) beobachtet 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 eines Konfigurationsprofils vornimmt, kann es bis zu einer Minute dauern, bis VMware SASE Orchestrator die Änderungen validiert.

  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 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 potenziell herabgestuft werden, wenn auf eine viel niedrigere Edge-Softwareversion gewechselt wird. Dies kann sich möglicherweise störend auswirken, z. B. durch Netzwerkfehler, wenn auf dem Edge eine ältere Version ausgeführt wird, die vom Kunden verwendete Funktionen nicht unterstützt.

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

  Dieses Problem tritt nicht auf, wenn die klassische Benutzeroberfläche verwendet wird, die auf einem Orchestrator 5.2.0 nicht verfügbar ist.

• 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 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, die die Standard-Benutzeroberfläche für 5.2.0 ist, und ist das Ergebnis fehlender Anfrageparameter.

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

• Behobenes Problem 118574: Für ein Kundenunternehmen, das den Enhanced Firewall Service verwendet, kann eine Warnung mit dem Schweregrad „Information“ gesendet werden, obwohl die Auswirkungsbewertung hoch ist.

  Eine ungenaue Beschreibung des Schweregrads kann einen Kundenbenutzer in die Irre führen und seine Fähigkeit beeinträchtigen, auf die Warnung zu reagieren. Das Problem ist darauf zurückzuführen, dass die Signaturen nicht korrekt klassifiziert wurden.

• Behobenes Problem 118673: Wenn ein VMware SD-WAN Edge auf ein anderes Profil umgeschaltet wird, kann es ~60 Sekunden dauern, bis der Vorgang abgeschlossen ist, und es kann sogar zu einem Zeitverlust kommen.

  Der Wechsel von einem Profil zu einem anderen sollte in wenigen Sekunden abgeschlossen sein, aber der Orchestrator benötigt aufgrund nicht ordnungsgemäß optimierter APIs viel länger für diese Aufgabe.

• Behobenes Problem 119551: Für Kunden, die den VMware Cloud Web Security-Dienst verwenden, schlägt der Versuch, eine Cloud Web Security-Einstellung unter Globale Einstellungen > Kundenkonfiguration zu ändern, mit einem Fehler fehl.

  Nachdem der Benutzer auf Aktualisieren geklickt hat, gibt der Orchestrator eine Fehlermeldung aus, die „Ungültige Dienstdetails“ lautet und z. B. beim Versuch auftreten kann, den Cloud Web Security-Lizenztyp zu ändern.

• Behobenes Problem 119733: Die Datenbank von VMware SASE Orchestrator kann ausfallen und einen Neustart des Orchestrators zur Wiederherstellung erfordern.

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

Behoben in Orchestrator-Version R5200-20230529-GA

Orchestrator-Version R5200-20230529-GA wurde am 31.05.2023 veröffentlicht und behebt die folgenden Probleme ab Orchestrator-Version R5104-20230426-GA.

Hinweis:

Version 5.2.0 enthält alle Orchestrator-Fixes, die in den Versionshinweisen zu 5.0.0 oder 5.0.1 aufgeführt sind, sowie alle Orchestrator-Fixes in den Versionshinweisen zu 5.1.0 bis zum oben aufgeführten Build.

• Behobenes Problem 50480: Der Text in den Dropdown-Menüs für ein neues Nicht-SD-WAN-Ziel über Edge ist falsch.

  Das Dropdown-Menü für „Neues Nicht-SD-WAN-Ziel über Edge (New Non SD-WAN Destination via Edge)“ enthält folgende Einträge:

  • Generischer IKEv1-Router (routenbasiertes VPN)

  • Generischer IKEv2-Router (routenbasiertes VPN)

  Der Eintrag sollte jedoch auf „Routenbasiertes VPN (Route based VPN)“ mit korrektem Abstand lauten.

• Behobenes Problem 78572: Ein Operator-Benutzer kann ein Operator-Profil mit einem ungültigen FQDN konfigurieren, ohne dass ein Fehler ausgegeben wird.

  Der Orchestrator sollte eine Validierung des FQDN-Werts durchführen und bei ungültigem FQDN einen Fehler ausgeben, um den Operator zu benachrichtigen. Ohne diese Validierung besteht die Möglichkeit, dass die Verbindung zwischen dem Edge und dem Orchestrator unterbrochen wird, wenn der Edge dem Operator-Profil zugewiesen wird.

• Behobenes Problem 78602: Wenn ein Benutzer Syslog für ein Profil konfiguriert und dann einen VMware SD-WAN Edge überprüft, der dieses Profil verwendet, stellt der Benutzer unter Umständen fest, dass die Syslog-Ebene nicht korrekt angezeigt wird.

  Der Benutzer beobachtet, dass anstelle einer Syslog-Ebene auf der Orchestrator-Benutzeroberfläche lediglich „Fehler (Error)“ angezeigt wird, obwohl die Syslog-Konfiguration für das Profil gültig ist.

• Behobenes Problem 81514: Wenn ein Nicht-SD-WAN-Ziel über Gateway auf einem 4.x-Orchestrator konfiguriert ist, der dann auf 5.x aktualisiert wird, zeigt die neue Benutzeroberfläche das NSD nicht auf der Seite „Konfigurieren (Configure)“ > „Geräteeinstellungen (Device Settings)“ an.

  Dieses Problem ist auf Nicht-SD-WAN-Ziele beschränkt, die auf einem 4.x-Orchestrator und bei Verwendung der neuen Benutzeroberfläche konfiguriert sind. Ein auf einem 5.x-Orchestrator konfiguriertes NSD weist dieses Problem nicht auf.

• Behobenes Problem 83607: Wenn ein Benutzer eine Objektgruppe erstellt, aktualisiert oder löscht, erzeugt der VMware SASE Orchestrator kein Ereignis für eine dieser Aktionen.

  Benutzern müssen Ereignisse angezeigt werden, wenn eine Änderung an einer Objektgruppe vorgenommen wird, damit sie sowohl von dem Benutzer, der die Änderung vorgenommen hat, als auch von anderen Kundenadministratoren überprüft werden können.

• Behobenes Problem 88661: Beim Konfigurieren eines Nicht-SD-WAN-Ziels über Edge kann der Benutzer einen ungültigen PSK-Wert konfigurieren, der zum Aufbau des Tunnels führen kann.

  Der Orchestrator lässt die Eingabe eines beliebigen Werts für PSK zu, unabhängig davon, ob es sich um ein oder 100 Zeichen handelt, ohne dass ein Fehler ausgelöst wird.

• Behobenes Problem 93930: Die neue Benutzeroberfläche von VMware SASE Orchestrator lässt ungültige Werte für AS-Path Prepend zu.

  Beim Konfigurieren einer Partner-Übergabe und anschließender Konfiguration von BGP- und BGP-Filtern mit AS-Path Prepend kann der Benutzer ungültige Werte angeben, die von der neuen Benutzeroberfläche nicht überprüft werden oder keinen Fehler auslösen.

• 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 97014: Wenn Sie die neue Benutzeroberfläche von VMware SASE Orchestrator verwenden und zu „Überwachen (Monitor)“ > „Netzwerkübersicht (Network Overview)“ für ein Kundenunternehmen navigieren, steht die Spalte „Status von Bastion (Bastion State)“ nicht zur Verfügung.

  „Status von Bastion (Bastion State)“ fehlt auch auf der Seite „Gateway-Überwachung (Gateway Monitor)“ und wird in beiden Fällen auf der klassischen Benutzeroberfläche angezeigt.

• Behobenes Problem 98241: Wenn ein Benutzer den Edge Network Intelligence-Dienst auf der Seite „Kundenkonfiguration (Customer Configuration)“ ein- oder ausschaltet, löst der VMware SASE Orchestrator trotz gültiger Aktion einen Fehler aus.

  Der Fehler lautet: „Die Analyse-URL muss in der Systemeigenschaft (service.analytics.apiUrl) für die Analysefunktion festgelegt werden (Analytics Url must be set in system property (service.analytics.apiUrl) for analytics feature)“. Die Fehlermeldung ist falsch, da die Änderungen tatsächlich erfolgreich gespeichert wurden.

• Behobenes Problem 99065: Auf der neuen Benutzeroberfläche von VMware SASE Orchestrator kann ein Benutzer keinen neuen VNF-Dienst auf der VNF-Seite „Edge-Sicherheit (Edge Security)“ erstellen.

  Der Benutzer kann einen neuen VNF-Dienst über die Seite „Netzwerkdienste (Network Services)“ erstellen. Diese Fehlerkorrektur ermöglicht dem Benutzer aber auch, diesen Dienst auf der VNF-Seite „Edge-Sicherheit (Edge Security)“ zu erstellen.

• Behobenes Problem 99080: Für einen Benutzer, der die neue Benutzeroberfläche von VMware SASE Orchestrator mit dem Safari-Browser von Apple anzeigt, enthalten die Dropdown-Optionsmenüs auf der Seite „Sicherheits-VNF konfigurieren (Configure Security VNF)“ leere Optionen.

  Dies gilt nur für Safari-Browser. Chromium-basierte Browser funktionieren wie erwartet.

• Behobenes Problem 99353: Mithilfe des VMware SASE Orchestrator kann ein Benutzer dieselbe Server-IP-Adresse für mehrere NetFlow-Collector-Konfigurationen konfigurieren.

  Der Orchestrator sollte in den NetFlow-Einstellungen eine Überprüfung auf doppelte IP-Adressen durchführen und bereits vorhandene Server-IP-Adressen ablehnen.

• Behobenes Problem 99891: Wenn sich ein Partneradministrator beim VMware SASE Orchestrator anmeldet und die neue Benutzeroberfläche verwendet, wird auf der Seite „Partnerkunden verwalten (Manage Partner Customer)“ nach Auswahl von „Kunde (Customer)“ > „Globale Einstellungen (Global Settings)“ > „Kundenkonfiguration (Customer Configuration)“ ein Fehler angezeigt.

  Die Fehlermeldung lautet „Nicht zulässig für Methode (Not allowed to method)“, wenn der Partneradministrator auf die Kundenkonfiguration zugreift, auch wenn er vollständige Rechte für diese Seite hat.

• Behobenes Problem 100148: Ein Operator-Superuser kann eine Operator-Rolle nicht bearbeiten, ohne zuvor die Beschreibung zu ändern.

  Der Operator-Superuser sollte in der Lage sein, die funktionale Rolle einer Operatorrolle zu ändern, ohne die Beschreibung ändern zu müssen.

• Behobenes Problem 101129: Der Abschnitt „SSH-Schlüssel des Unternehmens (Enterprise SSH keys)“ kann vom Operator-Support, Partner-Superuser und Kunden-Superuser angezeigt werden.

  Die aufgelisteten Benutzerrollen verfügen nicht über die Berechtigungen zum Anzeigen dieser Informationen.

• Behobenes Problem 103066: Wenn eine Business Policy mit einer Anwendung in einer Anwendungszuordnung verknüpft ist und diese Anwendung später aus der Anwendungszuordnung gelöscht wird, kann ein Benutzer keine weiteren Änderungen an der Business Policy vornehmen.

  Ein Benutzer sollte die Business Policy auch dann bearbeiten können, wenn die mit der Business Policy verknüpfte Anwendung aus der Anwendungszuordnung gelöscht wurde.

• Behobenes Problem 103620: Wenn Sie „Schnittstelleneinstellungen (Interface Settings)“ > „OSPF“ > „Erweiterte Einstellungen (Advanced Settings)“ > „Erlernen eingehender Routen (Inbound Route Learning)“ auf der neuen Benutzeroberfläche von VMware SASE Orchestrator konfigurieren, wird die Option „Genaue Übereinstimmung (Exact Match)“ als „True“ angezeigt, obwohl sie tatsächlich auf „False“ festgelegt ist.

  Dies kann zu Verwirrung führen und einen Benutzer dazu verleiten, eine wichtige OSPF-Einstellung für das Gegenteil dessen zu halten, was sie bedeutet. Dies kann Routing-Probleme verursachen.

• Behobenes Problem 104667: Wenn Sie „Überwachen (Monitor)“ > „Edge“ > „Verbindungsstatus (Link Status)“ auf der neuen Benutzeroberfläche von VMware SASE Orchestrator verwenden und der Link als „Instabil (Unstable)“ markiert ist, sind die Datumsinformationen falsch.

  Wenn ein Benutzer auf die Info-Bubble für diese Verbindung klickt, kann in der Übersicht „Verbindung inaktiv: Vor 53 Jahren (Link down: 53 years ago)“ gemeldet werden, obwohl die Verbindung aktiv, aber beeinträchtigt ist.

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

  Das DR-Setup mit konfiguriertem FIPS-Modus enthält einen Orchestrator-Build mit MySQL 8.0.28 oder höher und schlägt während der DR-Phase COPYING_DP mit der Fehlermeldung SSL_CTX_new failed when trying to connect fehl.

• 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 106554: Auf einer neuen Benutzeroberfläche des VMware SASE Orchestrator wird der Edge beim Erstellen eines neuen VMware SD-WAN Edge immer mit der auf „Zertifikat erwerben (Certificate Acquire)“ festgelegten Edge-Standardauthentifizierung erstellt. Dabei spielt es keine Rolle, wie der Benutzer die Einstellung „Standardzertifikat (Default Certificate)“ unter „Diensteinstellungen (Service Settings)“ > „Edge-Verwaltung (Edge Management)“ konfiguriert hat.

  Wenn ein Benutzer das Standardzertifikat entweder als „Zertifikat deaktiviert (Certificate Deactivated)“ oder „Zertifikat erforderlich (Certificate Required)“ festlegt, werden diese globalen Einstellungen auf der neuen Benutzeroberfläche ignoriert und der neue Edge wird als „Zertifikat erwerben (Certificate Acquire)“ konfiguriert. Dieses Problem ist auf der klassischen Benutzeroberfläche nicht aufgetreten.

• Behobenes Problem 107858: Für Kunden, die APIs für die Verwendung auf einem VMware SASE Orchestrator konfigurieren, fehlen in Swagger JSON-Schlüssel für inside ha und device_settings_dhcp_relay.

  Version 5.2.0 und höher enthält die fehlenden JSON-Schlüssel für die Eigenschaften inside ha und device_settings_dhcp_relay.

• Behobenes Problem 109710: Ein Partneradministrator kann möglicherweise keine Partner-Übergabe auf dem VMware SASE Orchestrator konfigurieren.

  Partneradministrator-Benutzer erhalten die Fehlermeldung „Eigenschaft 'v6Detail' kann nicht auf 'Nicht definiert' festgelegt werden (cannot set property v6Detail of undefined)“, wenn sie statische Routen bei einer Partner-Übergabe konfigurieren, die auf Gateway-Ebene konfiguriert ist. Operator-Benutzer können die Änderung problemlos vornehmen.

• Behobenes Problem 112912: Auf einem VMware SASE Orchestrator mit der neuen Benutzeroberfläche wird die Option „Neu starten (Reboot)“ abgeblendet dargestellt, wenn sich ein Benutzer mit der Rolle „Enterprise-Support (Enterprise Support)“ bei „Remote-Aktionen (Remote Actions)“ für einen Edge angemeldet hat.

  Ein Enterprise-Support-Benutzer kann einen Edge remote mithilfe der klassischen Benutzeroberfläche neu starten. Dasselbe sollte auch für die neue Benutzeroberfläche gelten.

• 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 114224: Wenn ein Operator in VMware SASE Orchestrator mit der neuen Benutzeroberfläche die Google Maps-Integration aus den Systemeigenschaften des Orchestrator entfernt, wird auf der neuen Benutzeroberfläche weiterhin Google Maps angezeigt.

  Wenn ein Benutzer die Systemeigenschaft service.client.googleMapsApi.enable in „false“ ändert, um die Google Maps-Integration für einen lokalen Kunden zu entfernen, sollte die Google Maps-Integration aus der neuen Benutzeroberfläche gelöscht werden. Stattdessen wird die Änderung nur auf die klassische Benutzeroberfläche angewendet.

• Behobenes Problem 114564: Der Benutzer kann „802.1P-Einstellung (802.1P Setting)“ unter der optionalen Konfiguration für eine Edge-Schnittstelle in der neuen Benutzeroberfläche von VMware SASE Orchestrator nicht konfigurieren.

  Während diese Einstellung im Classic Orchestrator als optionale Konfiguration angezeigt wird, fehlt dieser Parameter in der neuen Benutzeroberfläche, die die Standard-Benutzeroberfläche für Release 5.2.0 ist.

• Behobenes Problem 114900: Die Registerkarte „Nicht-SD-WAN-Ziele über Edge (Non SD-WAN Destinations via Edge)“ wird Enterprise Read Only-Benutzern nicht angezeigt.

  Das Problem wird durch falsch konfigurierte Berechtigungen für die Rolle „Enterprise: Read Only (Enterprise Read Only)“ verursacht.

• Behobenes Problem 115527: Wenn ein Benutzer ein Nicht-SD-WAN-Ziel über Edge mit einem Zscaler-Typ konfiguriert, wird bei Verwendung von „Überwachen (Monitor)“ > „Edges“ auf der neuen Benutzeroberfläche des VMware SASE Orchestrator kein Tunnelstatus angezeigt.

  Die API, die von der neuen Benutzeroberfläche zum Abrufen von Edge-Tunneldatensätzen verwendet wird, geht fälschlicherweise davon aus, dass die Edge-Softwareversion immer das Format „x.x.x“ aufweist. Auf diese Weise werden Tunnelstatusdaten von Edges ausgeschlossen, deren Version nicht diesem Format entspricht (z. B. 5.1.0.3).

• Behobenes Problem 115719: Eine Internet-Backhaul-Regel wird in der Business Policy-Regel nicht beibehalten, wenn Änderungen an den Geräteeinstellungen auf Profilebene vorgenommen werden.

  Der Orchestrator entfernt fälschlicherweise die Backhaul-Regel für jede Änderung im Abschnitt „Geräteeinstellungen (Device Settings)“ für ein Profil.

• Behobenes Problem 116958: Wenn ein Operator-Benutzer bei Verwendung der neuen Benutzeroberfläche von VMware SASE Orchestrator zur Seite „Operator-Ereignisse (Operator Events)“ navigiert, wird unter Umständen eine API-Fehlermeldung angezeigt.

  Das Problem wird dadurch verursacht, dass der Ereignis-Cache für Filter nicht für alle Ereignisseiten gelöscht und freigegeben wird. Die Seite „Unternehmensereignisse (Enterprise Events)“ sollte unzulässige Werte für die Seiten „Operator“ und „Partner“ aufweisen.

• Behobenes Problem 116976: Für API-Benutzer auf dem VMware SASE Orchestrator antwortet getEnterpriseEdgeLInkStatus möglicherweise nicht mit Links, die vor mehr als 24 Stunden getrennt wurden, wenn die API mit den Parametern {"detailed": true} aufgerufen wird und es sich beim Aufrufer um einen Partneradministrator handelt.

  Die in Version 4.0.0 eingeführte Regression hat das API-Verhalten so verändert, dass NUR aktuelle Links für Anmeldungen von Partneradministratoren zurückgegeben werden. Dieses Problem wirkt sich nicht auf Anmeldungen von Operator- oder Enterprise-Administratoren aus.

Bekannte Probleme

Bestehende Probleme in Version 5.2.0.

• Bekannte Probleme bei Edge/Gateway
• Bekannte Probleme bei Orchestrator

Bekannte Probleme bei Edge/Gateway

• Problem 14655:

  Das Einstecken oder Abziehen eines SFP-Adapters kann zur Folge haben, dass das Gerät beim Edge 540, Edge 840 und Edge 1000 nicht mehr reagiert und ein physischer Neustart erforderlich ist.

  Problemumgehung: Der Edge muss physisch neu gestartet werden. Dies kann entweder auf dem Orchestrator mithilfe von Remote-Aktionen (Remote Actions) > Edge neu starten (Reboot Edge) oder durch das Ausschalten und anschließende erneute Einschalten des Edge vorgenommen werden.

• Problem 25504:

  Kosten für statische Routen von mehr als 255 können zu unvorhersehbaren Routenbestellungen führen.

  Problemumgehung: Verwenden Sie Routenkosten zwischen 0 und 255.

• Problem 25595:

  Ein Neustart kann erforderlich sein, damit Änderungen am statischen SLA auf einem WAN-Overlay ordnungsgemäß funktionieren.

  Problemumgehung: Neustart des Edge nach dem Hinzufügen und Entfernen des statischen SLA aus dem WAN-Overlay.

• Problem 25742:

  Der berücksichtigte Underlay-Datenverkehr wird auf ein Maximum der Kapazität zum VMware SD-WAN Gateway begrenzt, auch wenn diese geringer ist als die Kapazität eines privaten WAN-Links, der nicht mit dem Gateway verbunden ist.

• Problem 25758:

  USB-WAN-Links werden beim Wechsel von einem USB-Port zu einem anderen möglicherweise nicht ordnungsgemäß aktualisiert, bis der VMware SD-WAN Edge neu gestartet wird.

  Problemumgehung: Starten Sie den Edge neu, nachdem Sie USB-WAN-Links von einem Port zu einem anderen verschoben haben.

• Problem 25885:

  Ein großes Konfigurations-Update auf dem Partner-Gateway (z. B. 200 BGP-konfigurierte VRFs) kann zur Folge haben, dass die Latenzzeit für einen Teil des Datenverkehrs über das VMware SD-WAN Gateway für ca. 2‑3 Sekunden ansteigt.

  Problemumgehung: Keine Problemumgehung verfügbar.

• Problem 25921:

  Das VMware SD-WAN Hub-Hochverfügbarkeits-Failover dauert länger als erwartet (bis zu 15 Sekunden), wenn 3000 Zweigstellen-Edges mit dem Hub verbunden sind.

  Problemumgehung: Keine Problemumgehung verfügbar.

• Problem 25997:

  Es ist möglicherweise ein Neustart des VMware SD-WAN Edge erforderlich, um den Datenverkehr in einer gerouteten Schnittstelle, die in einen geswitchten Port umgewandelt wurde, ordnungsgemäß weiterzuleiten.

  Problemumgehung: Starten Sie den Edge neu, nachdem Sie die Konfigurationsänderung durchgeführt haben.

• Problem 26421:

  Das primäre Partner-Gateway für eine Zweigstellen-Site muss auch einem VMware SD-WAN Hub-Cluster für Tunnel zu dem einzurichtenden Cluster zugewiesen werden.

  Problemumgehung: Keine Problemumgehung verfügbar.

• Problem 28175:

  Die Business Policy-NAT schlägt fehl, wenn sich die NAT-IP mit der IP-Adresse der VMware SD-WAN Gateway-Schnittstelle überschneidet.

  Problemumgehung: Keine Problemumgehung verfügbar.

• Problem 31210:

  VRRP: ARP wird im LAN-Client für die virtuelle VRRP-IP-Adresse nicht aufgelöst, wenn der VMware SD-WAN Edge primär ist und ein nicht globales CDE-Segment auf der LAN-Schnittstelle ausgeführt wird.

  Problemumgehung: Keine Problemumgehung verfügbar.

• Problem 32731:

  Über OSPF annoncierte bedingte Standardrouten können nicht ordnungsgemäß zurückgenommen werden, wenn die Route deaktiviert ist.

  Problemumgehung: Wenn Sie die Route erneut aktivieren und anschließend wieder deaktivieren, wird sie erfolgreich zurückgenommen.

• Problem 32960:

  Die Schnittstellenstatus „Autom. Aushandlung (Autonegotiation)“ und „Geschwindigkeit (Speed)“ werden möglicherweise in der lokalen Web-UI für aktivierte VMware SD-WAN Edges möglicherweise nicht korrekt angezeigt.

  Problemumgehung: Weitere Informationen finden Sie in der Orchestrator-Benutzeroberfläche unter Remote-Diagnose (Remote Diagnostics) > Schnittstellenstatus (Interface Status).

• Problem 32981:

  Hartcodierungsgeschwindigkeit und Duplex auf einem DPDK-konfigurierten Port erfordern möglicherweise einen Neustart des VMware SD-WAN Edge, damit die Konfigurationen wirksam werden, da dies das Deaktivieren von DPDK erfordert.

  Problemumgehung: Für dieses Problem gibt es keine Problemumgehung.

• Problem 34254:

  Wenn ein Zscaler CSS erstellt wird und für das globale Segment FQDN/PSK-Einstellungen konfiguriert wurden, werden diese Einstellungen in nicht globale Segmente kopiert, um IPSec-Tunnel zu einer Zscaler-CSS zu bilden.

• Problem 35778:

  Wenn auf einer einzelnen Schnittstelle mehrere benutzerdefinierte WAN-Links vorhanden sind, kann nur einer dieser WAN-Links einen GRE-Tunnel zu Zscaler haben.

  Problemumgehung: Verwenden Sie für jeden WAN-Link, der GRE-Tunnel zu Zscaler aufbauen muss, eine andere Schnittstelle.

• Problem 36923:

  Der Name des Clusters wird möglicherweise in der NetFlow-Schnittstellenbeschreibung für einen VMware SD-WAN Edge, der mit diesem Cluster als Hub verbunden ist, nicht richtig aktualisiert.

• Problem 38682:

  Ein VMware SD-WAN Edge, der als DHCP-Server auf einer DPDK-konfigurierten Schnittstelle fungiert, generiert möglicherweise nicht ordnungsgemäß Ereignisse vom Typ „Neues Clientgerät (New Client Device)“ für alle verbundenen Clients.

• Problem 38767:

  Wenn ein WAN-Overlay, bei dem GRE-Tunnel zu Zscaler konfiguriert sind, von automatischer Erkennung in benutzerdefiniert geändert werden, verbleiben veraltete Tunnel möglicherweise bis zum nächsten Neustart.

  Problemumgehung: Starten Sie den Edge neu, um den veralteten Tunnel zu löschen.

• Problem 39374:

  Wenn die Reihenfolge der VMware SD-WAN-Partner-Gateways geändert wird, die einem VMware SD-WAN Edge zugewiesen sind, wird Gateway 1 möglicherweise nicht ordnungsgemäß als das lokale Gateway festgelegt, das für Bandbreitentests verwendet werden soll.

• Problem 39608:

  Die Ausgabe der Remote-Diagnose „Ping-Test (Ping Test)“ zeigt möglicherweise ungültige Inhalte an, kurz bevor die richtigen Ergebnisse angezeigt werden.

  Problemumgehung: Für dieses Problem gibt es keine Problemumgehung.

• Problem 39624:

  Das Anpingen durch eine Teilschnittstelle schlägt möglicherweise fehl, wenn die übergeordnete Schnittstelle mit PPPoE konfiguriert ist.

  Problemumgehung: Für dieses Problem gibt es keine Problemumgehung.

• Problem 39753:

  Das Ausschalten von dynamischem Zweigstelle-zu-Zweigstelle-VPN kann zur Folge haben, dass vorhandene Flows, die zurzeit mit dynamischem Zweigstelle-zu-Zweigstelle gesendet werden, unterbrochen werden.

  Problemumgehung: Deaktivieren Sie dynamisches Zweigstelle-zu-Zweigstelle-VPN nur in einem Wartungsfenster.

• Problem 40421:

  Traceroute zeigt den Pfad nicht an, wenn er durch einen VMware SD-WAN Edge mit einer als geswitchten Port konfigurierten Schnittstelle verläuft.

• Problem 40096:

  Wenn ein aktivierter VMware SD-WAN Edge 840 neu gestartet wird, besteht die Möglichkeit, dass ein in den Edge eingestecktes SFP-Modul den Datenverkehr nicht mehr weitergibt, obwohl die Link-Leuchten und der VMware SD-WAN Orchestrator den Port als aktiv (UP) anzeigen.

  Problemumgehung: Ziehen Sie das SFP-Modul ab und stecken Sie es dann in den Port wieder ein.

• Problem 42278:

  Bei einem bestimmten Typ von Peer-Fehlkonfiguration kann das VMware SD-WAN Gateway kontinuierlich IKE-Init-Meldungen an einen Nicht-SD-WAN-Peer senden. Dieses Problem stört den Benutzerdatenverkehr zum Gateway nicht. Die Gateway-Protokolle können jedoch mit IKE-Fehlern gefüllt werden, wodurch nützliche Protokolleinträge möglicherweise verdeckt werden.

• Problem 42872:

  Die Aktivierung der Profilisolierung für ein Hub-Profil, dem ein Hub-Cluster zugeordnet ist, hebt die Hub-Routen nicht aus der Routing Information Base (RIB) auf.

• Problem 43373:

  Wenn dieselbe BGP-Route von mehreren VMware SD-WAN Edges gelernt wird und diese Route in der Overlay-Flow-Steuerung vom bevorzugten zum berechtigten Ausgang verschoben wird, wird der Edge nicht aus der Ankündigungsliste entfernt und weiterhin annonciert.

  Problemumgehung: Aktivieren Sie die DCC (Distributed Cost Calculation) auf dem VMware SD-WAN Orchestrator.

• Problem 44995:

  OSPF-Routen werden von VMware SD-WAN Gateways und VMware SD-WAN Spoke Edges nicht widerrufen, wenn die Routen aus dem Hub-Cluster zurückgezogen werden.

• Problem 45189:

  Wenn NAT auf der Quell-LAN-Seite konfiguriert ist, ist der Datenverkehr von einem VMware SD-WAN Spoke Edge zu einem Hub Edge auch ohne die statische Routenkonfiguration für das NAT-Subnetz zulässig.

• Problem 45302:

  Wenn in einem VMware SD-WAN-Hub-Cluster bei einem Hub für mehr als 5 Minuten die Verbindung zu allen VMware SD-WAN-Gateways unterbrochen wird, die ihm und den ihm zugewiesenen Spoke Edges gemeinsam sind, können die Spokes in seltenen Fällen die Hub-Routen nach 5 Minuten nicht mehr beibehalten. Das Problem wird von selbst gelöst, wenn der Hub den Kontakt zu den Gateways wiedererlangt.

• Problem 46053:

  Die BGP-Einstellung wird für Overlay-Routen nicht automatisch korrigiert, wenn der Nachbar in einen Uplink-Nachbarn geändert wird.

  Problemumgehung: Bei einem Neustart des Edge-Diensts wird dieses Problem behoben.

• Problem 46137:

  Ein VMware SD-WAN Edge mit Software der Version 3.4.x initiiert keinen Tunnel mit AES-GCM-Verschlüsselung, selbst wenn der Edge für GCM konfiguriert ist.

  Problemumgehung: Wenn ein Kunde AES-256 verwendet, muss er GCM explizit im Orchestrator deaktivieren bevor er seine Edges auf eine 4.x-Version aktualisiert. Sobald auf allen Edges des Kunden eine 4.x-Version ausgeführt wird, kann der Kunde zwischen AES-256-GCM und AES-256-CBC wählen.

• Problem 46216:

  Bei einem Nicht-SD-WAN-Ziel über Gateway oder Edge, bei dem der Peer eine AWS-Instanz ist, wird das Phase-1-IKE ebenfalls gelöscht und ein Rekey erzwungen, wenn der Peer ein Phase-2-Rekey initiiert. Dies bedeutet, dass der Tunnel entfernt und neu aufgebaut wird, was zu Paketverlusten während der Tunnelneuerstellung führt.

  Problemumgehung: Um die Vernichtung von Tunneln zu vermeiden, konfigurieren Sie den Rekey-Timer für Nicht-SD-WAN-Ziele über Gateway/Edge oder CSS IPSec auf weniger als 60 Minuten. Dadurch wird verhindert, dass AWS ein Rekey initiiert.

• Problem 46391:

  Bei einem VMware SD-WAN Edge 3800 weisen die SFP1- und SFP2-Schnittstellen jeweils Probleme mit Multi-Raten-SFPs (d. h. 1/10G) auf und sollten in diesen Ports nicht verwendet werden.

  Problemumgehung: Verwenden Sie die Einzelraten-SFPs gemäß dem KB-Artikel Liste der unterstützten SFP-Module für VMware SD-WAN (VMware SD-WAN Supported SFP Module List) (79270). Multi-Raten-SFPs können mit SFP3 und SFP4 verwendet werden.

• Problem 47664:

  In einer Hub- und Spoke-Konfiguration, bei der Zweigstelle-zu-Zweigstelle über Hub-VPN nicht konfiguriert ist, führt der Versuch, den Datenverkehr von Zweigstelle-zu-Zweigstelle über eine zusammenfassende Route auf einem L3-Switch/Router zurückzuleiten, zu Routing-Schleifen.

  Problemumgehung: Konfigurieren Sie Cloud-VPN und aktivieren Sie Zweigstelle-zu-Zweigstelle-VPN und wählen Sie „Hubs für VPN verwenden (Use Hubs for VPN)“ aus.

• Problem 47681:

  Wenn ein Host auf der LAN-Seite eines VMware SD-WAN Edge dieselbe IP wie die WAN-Schnittstelle des Edge verwendet, funktioniert die Verbindung vom LAN-Host zum WAN nicht.

• Problem 48530:

  VMware SD-WAN Edge 6x0-Modelle führen keine automatische Aushandlung für Kupfer-SFPs mit dreifacher Geschwindigkeit (10/100/1000 MBit/s) durch.

  Problemumgehung: Edge 520/540 unterstützt Kupfer-SFPs mit dreifacher Geschwindigkeit, doch dieses Modell wird ab Q1 2021 nicht mehr verkauft.

• Problem 48597: Die BGP-Nachbarschaft mit mehreren Hops bleibt nicht aktiv, wenn einer der beiden Pfade zum Peer ausfällt.

  Wenn es eine Multihop-BGP-Nachbarschaft mit einem Peer gibt, zu dem es mehrere Pfade gibt und einer von ihnen ausfällt, wird der Benutzer feststellen, dass die BGP-Nachbarschaft ausfällt und nicht über die anderen verfügbaren Pfade aktiviert wird. Dies gilt einschließlich für den Fall der Loopback-Nachbarschaft einer lokalen IP.

  Problemumgehung: Für dieses Problem gibt es keine Problemumgehung.

• Problem 50518:

  Auf einem VMware SD-WAN Gateway, bei dem PKI konfiguriert ist, werden möglicherweise nicht alle Tunnel aktiviert, wenn mehr als 6000 Tunnel versuchen, eine Verbindung mit dem Gateway herzustellen, da eingehende SAs nicht gelöscht werden.

  Hinweis:

  Bei Tunneln, bei denen die Authentifizierung über vorinstallierte Schlüssel erfolgt (Pre-Shared Key, PSK) tritt dieses Problem nicht auf.

• Problem 51436: Für eine Site, die eine Topologie mit erweiterter Hochverfügbarkeit verwendet, während sie einen VMware SD-WAN Edge mithilfe eines LTE-Modems bereitstellt, dauert das HA-Failover etwa 5–6 Minuten, wenn die Site in einen „Split-Brain“-Zustand eintritt.

  Im Rahmen der Wiederherstellung aus einem Split-Brain-Zustand werden die LAN-Ports auf dem Active Edge heruntergefahren. Dies wirkt sich auf den LAN-Datenverkehr aus, solange die Ports heruntergefahren sind und bis die Site wiederhergestellt werden kann.

  Problemumgehung: Für dieses Problem gibt es keine Problemumgehung.

• Problem 52955: Es wird keine DHCP-Ablehnung vom Edge gesendet, und die DHCP-Neubindung wird nicht neu gestartet, nachdem beim statusbehafteten DHCP ein DAD-Fehler aufgetreten ist.

  Wenn der DHCPv6-Server während einer DAD-Prüfung eine Adresse zuteilt, die vom Kernel während einer DAD-Prüfung als doppelt erkannt wird, sendet der DHCPv6-Client keine Ablehnung. Dies führt zu einem Rückgang des Datenverkehrs, da die Schnittstellenadresse als Adresse gekennzeichnet wird, die die DAD-Prüfung nicht bestanden hat, und nicht verwendet wird. Dies führt nicht zu einer Datenverkehrsschleife im Netzwerk, aber es kommt zu einem Blackholing des Datenverkehrs.

  Problemumgehung: Für dieses Problem gibt es keine Problemumgehung.

• Problem 53219: Nach einer VMware SD-WAN-Hub-Cluster-Neuverteilung ist für einige Spoke-Edges möglicherweise nicht die richtige RPF-Schnittstelle/IIF festgelegt.

  Auf den betroffenen Spoke-Edges wird der Multicast-Datenverkehr beeinträchtigt. Das rührt daher, dass nach einer Cluster-Neuverteilung einige Spoke-Edges keinen PIM-Join senden können.

  Problemumgehung: Dieses Problem bleibt bestehen, bis der betroffene Spoke-Edge dies getan hat und der Edge-Dienst neu gestartet wurde.

• Problem 53934: In einem Unternehmen, in dem ein VMware SD-WAN Hub-Cluster konfiguriert ist und der primäre Hub Multihop-BGP-Nachbarschaften auf der LAN-Seite hat, kann es zu einem Rückgang des Datenverkehrs auf einem Spoke-Edge kommen, wenn ein Ausfall auf der LAN-Seite auftritt oder BGP auf allen Segmenten nicht konfiguriert ist.

  In einem Hub-Cluster hat der primäre Hub eine BGP-Nachbarschaft mit mehreren Hops mit einem Peer-Gerät, um Routen zu lernen. Wenn die physische Schnittstelle am Hub, über die die BGP-Nachbarschaft eingerichtet wird, ausfällt, werden BGP-LAN-Routen möglicherweise nicht null, obwohl die BGP-Ansicht leer ist. Dies kann dazu führen, dass eine Neuausrichtung des Hub-Clusters nicht stattfindet. Das Problem kann auch beobachtet werden, wenn BGP nicht für alle Segmente konfiguriert ist und wenn es eine oder mehrere Multihop-BGP-Nachbarschaften gibt.

  Problemumgehung: Starten Sie den Hub neu, bei dem der LAN-seitige Fehler aufgetreten ist (oder BGP nicht aktiviert ist).

• Problem 57210: Selbst wenn ein VMware SD-WAN Edge normal funktioniert und das Internet erreichen kann, wird die LED auf der Übersichtsseite der lokalen Benutzeroberfläche als „Rot“ (Red) angezeigt.

  Die lokale Edge-Benutzeroberfläche bestimmt die Konnektivität des Edge, indem sie feststellt, ob ein bekannter Name über den DNS-Auflöser von Google (8.8.8.8) aufgelöst werden kann. Wenn sie dies aus irgendeinem Grund nicht tun kann, geht sie davon aus, dass sie offline ist, und zeigt die LED als rot an.

  Problemumgehung: Dieses Problem kann nicht umgangen werden, es muss lediglich sichergestellt werden, dass der DNS-Datenverkehr an 8.8.8.8 das Ziel erreichen und erfolgreich aufgelöst werden kann.

• Problem 61543: Wenn mehrere 1:1-NAT-Regeln auf unterschiedlichen Schnittstellen mit derselben inneren IP konfiguriert sind, kann der eingehende Datenverkehr auf einer Schnittstelle empfangen werden, und die ausgehenden Pakete desselben Flows können über eine andere Schnittstelle geroutet werden.

  Für die NAT-Flows von außen nach innen werden die 1:1-NAT-Regeln mit der externen IP und der Schnittstelle, von der die Pakete empfangen werden, abgeglichen. Für die ausgehenden Pakete desselben Flows versucht der VMware SD-WAN Edge, die NAT-Regeln durch Vergleich mit der inneren IP erneut abzugleichen, und der ausgehende Datenverkehr kann über die Schnittstelle geroutet werden, die in der ersten übereinstimmenden Regel mit der Option „Ausgehender Datenverkehr“ (Outbound Traffic) konfiguriert ist.

  Problemumgehung: Dieses Problem kann nur umgangen werden, indem sichergestellt wird, dass nur eine 1:1-NAT-Regel mit einer bestimmten internen IP-Adresse konfiguriert wird.

• Problem 65560: Der Datenverkehr von einem Kunden zum PE-Gerät (Provider Edge) schlägt fehl.

  Die BGP-Nachbarschaft zwischen einem Partner-Gateway und einem Provider-Edge wird nicht hergestellt, wenn der Tag-Typ in der Übergabekonfiguration auf „none“ eingestellt ist. Dies liegt daran, dass die ctag- und stag-Werte aus der Datei /etc/config/gatewayd und nicht aus der Übergabekonfiguration auf dem Orchestrator übernommen werden, wenn der Tag-Typ „none“ ist.

  Problemumgehung: Aktualisieren Sie die Werte für ctag und stag auf jeweils 0 unter „vrf_vlan->tag_info in /etc/config/gatewayd“. Führen Sie einen Neustart von vc_procmon durch.

• Problem 67879: Ein CSS-Tunnel (Cloud Security Service) wird gelöscht, nachdem ein Benutzer eine WAN-Overlay-Einstellung von automatischer Erkennung auf benutzerdefiniert für eine WAN-Schnittstelle geändert hat.

  Nach dem Speichern der Änderungen werden die CSS-Tunnel erst wieder aktiviert, wenn der Kunde den Tunnel herunterfährt und dann wieder einrichtet. Eine Änderung der WAN-Konfiguration führt zum Herunterfahren des CSS-Tunnels und zum erneuten Parsen der CSS-Konfiguration. In einigen Ausnahmefällen ist die Anzahl der nvs_config>num_gre_links jedoch 0, und der CSS-Tunnel kann nicht hochgefahren werden.

  Problemumgehung: Deaktivieren Sie das CSS-Setup und aktivieren Sie es dann wieder, um den CSS-Tunnel hochzufahren.

• Problem 68057: Das DHCPv6-Freigabepaket wird vom VMware SD-WAN Edge nicht gesendet, wenn der Adressmodus einer WAN-Schnittstelle von einer statusbehafteten DHCP- zu einer statischen IPv6-Adresse geändert wird, und der Lease bleibt bis zum Erreichen seiner Gültigkeitsdauer aktiv.

  Der DHCPv6-Client verfügt über einen Lease, den er bei einer Konfigurationsänderung nicht freigibt. Die Lease bleibt gültig, bis ihre Lebensdauer auf dem DHCPv6-Server abläuft und gelöscht wird.

  Problemumgehung: Es gibt keine Möglichkeit, dieses Problem zu beheben, da der Lease bis zum Ende seiner Gültigkeit aktiv bleibt.

• Problem 68851: Wenn ein VMware SD-WAN Edge und ein VMware SD-WAN Gateway jeweils denselben TCP-Syslog-Server konfiguriert haben, wird die TCP-Verbindung vom Edge zum Syslog-Server nicht hergestellt.

  Wenn der Edge und das Gateway jeweils denselben TCP-Server haben und die Syslog-Pakete vom Edge über das Gateway geleitet werden, sendet der Syslog-Server einen TCP-Reset an den Edge.

  Problemumgehung: Senden Sie die syslog-Pakete direkt vom Edge, anstatt sie über ein Gateway zu leiten, oder konfigurieren Sie einen anderen syslog-Server für den Edge und das Gateway.

• Problem 69284: Für eine Site mit einer Hochverfügbarkeitstopologie, bei der die Edges VNFs in einer HA-Konfiguration bereitstellen und Version 4.x verwenden, gilt: Wenn diese HA-Edges auf eine Version 3.4.x herabgestuft werden, in der HA-VNFs nicht unterstützt werden, und dann auf 4.5.0 aktualisiert werden, wird bei der erneuten Aktivierung der HA-VNFs der Standby-Edge-VNF nicht hochgefahren.

  Der VNF-Status auf dem Standby-Edge wird über SNMP als „inaktiv“ (down) gemeldet. Wenn das HA-VNF-Paar von einer Version, die VNF-HA (Version 4.0+) unterstützt, auf eine Version herabgestuft wird, die es bei konfiguriertem VNF auf dem Orchestrator nicht unterstützt. Dieses Problem tritt auf, wenn der Edge wieder auf eine Version mit Unterstützung für VNF-HA aktualisiert und erneut auf dem Orchestrator konfiguriert wird.

  Problemumgehung: VNF sollte zuerst im Falle einer HA-Konfiguration deaktiviert werden, wenn der Edge auf eine Version herabgestuft wird, die sie nicht unterstützt.

• Problem 72358: Wenn sich die IP-Adresse des DNS-Namens eines VMware SD-WAN-Orchestrators ändert, kann der Vorgang auf der Verwaltungsebene des VMware SD-WAN-Gateways diese nicht ordnungsgemäß auflösen, und das Gateway kann keine Verbindung zum Orchestrator herstellen.

  Der Verwaltungsvorgang des Gateways prüft regelmäßig die DNS-Auflösung

  des DNS-Namens des Orchestrators, um festzustellen, ob er sich kürzlich geändert hat, damit das Gateway eine Verbindung zum richtigen Host herstellen kann. Der DNS-Auflösungscode weist ein Problem auf, sodass alle diese Auflösungsprüfungen fehlschlagen und das Gateway weiterhin die alte Adresse verwendet und somit keine Verbindung mehr zum Orchestrator herstellen kann.

  Problemumgehung: Bis dieses Problem behoben ist, sollte ein Operator-Benutzer die IP-Adresse des Orchestrators nicht ändern. Wenn die IP-Adresse des Orchestrators geändert werden muss, müssen alle Gateways, die eine Verbindung zu diesem Orchestrator herstellen, erneut aktiviert werden.

• Problem 77541: Wenn ein USB-Modem, das IPv6 unterstützt, ausgesteckt und dann wieder in eine VMware SD-WAN Edge-USB-Schnittstelle eingesteckt wird, wird möglicherweise keine IPv6-Adresse für die USB-Schnittstelle bereitgestellt.

  Dies betrifft USB-Modems, die IP-basiert sind und nicht von der ModemManager-Anwendung verwaltet werden. Die meisten Inseego-Modems sind IP-basiert. Dies ist wichtig, da Inseego der Modemhersteller ist, den VMware SASE empfiehlt. USB-Modems mit IPv6-Unterstützung, die ModemManager verwenden und nicht IP-basiert sind, funktionieren in einem Szenario, in dem sie aus- und eingesteckt werden, problemlos.

  Problemumgehung: Der Edge muss neu gestartet (oder die Stromversorgung unterbrochen) werden, nachdem das USB-Modem wieder an den USB-Anschluss des Edge angeschlossen wurde. Nach dem Neustart ruft der Edge die IPv6-Adresse für das Modem ab.

• Problem 81852: Bei einem VMware SD-WAN Edge, der einen Cloud-Security-Service (CSS) vom Typ Zscaler verwendet, der GRE-Tunnel mit aktivierter L7-Integritätsprüfung einsetzt, kann es in einigen Fällen zu Fehlern bei der L7-Integritätsprüfung kommen, wenn dieser Edge auf Version 5.0.0 aktualisiert wird.

  Dies tritt in der Regel während des Software-Upgrades oder während der Startzeit auf. Wenn die L7-Integritätsprüfung für einen CSS mit GRE-Tunneln aktiviert ist, werden möglicherweise Fehlermeldungen im Zusammenhang mit dem Socket-Getaddress-Fehler angezeigt. Der beobachtete Fehler tritt sporadisch auf und ist nicht konsistent. Aus diesem Grund werden keine Testmeldungen zur L7-Integritätsprüfung gesendet.

  Problemumgehung: Ohne den Fix muss ein Benutzer zur Behebung des Problems die L7-Integritätsprüfungskonfiguration deaktivieren und wieder aktivieren, damit diese Funktion wie erwartet funktioniert.

• Problem 82184: Wenn auf einem VMware SD-WAN Edge, auf dem Edge Version 5.0.0 ausgeführt wird, ein traceroute oder traceroute6 zur br-network IPv4/IPv6-Adresse des Edge ausgeführt wird, wird der traceroute nicht ordnungsgemäß beendet, wenn ein UDP-Test verwendet wird.

  Traceroute oder traceroute6 zur br-network-IPv4/IPv6-Adresse des Edge wird nicht ordnungsgemäß ausgeführt, wenn der Standardmodus (d. h. UDP-Test) verwendet wird.

  Problemumgehung: Verwenden Sie die Option -I in traceroute und traceroute6, um ICMP-Test zu verwenden, und dann funktioniert traceroute zu br-network IPv4/IPv6-Adresse wie erwartet.

• Problem 85402: In einem Kundenunternehmen, das BGP mit konfigurierten Partner-Gateways verwendet, kann es vorkommen, dass einige BGP-Nachbarschaften ausfallen, was zu Problemen beim Kundendatenverkehr führt.

  Wenn der Kunde das maximale Präfix auf einem Router konfiguriert hat, der BGP-Peering mit dem Edge und dem Gateway aufweist, wird die BGP-Sitzung möglicherweise vom Router verworfen.

  Beispiel: BGP wurde vom Router so konfiguriert, dass nur die maximale Anzahl n an Präfixen empfangen werden kann. Der Edge und das Gateway weisen jedoch mehr n Präfixe auf, die ohne Filter angekündigt werden müssen. Wenn nun die BGP-Filterkonfiguration auf dem Orchestrator geändert wird, tritt das Problem auf, dass mehr als n Präfixe an den Peer gesendet werden, bevor irgendwelche Filter angewendet werden, selbst wenn die Gesamtzahl der in ausgehender Richtung zulässigen Präfixe kleiner als n ist. Dies führt dazu, dass der Router die Sitzung beendet.

  Problemumgehung: Wenn BGP aufgrund dieses Problems ausfällt (maximale Anzahl an Präfixen erreicht), unterbrechen Sie BGP auf dem Peer mithilfe der CLI („neighbor x shut“ gefolgt von „no neighbor x shut“ für FRR/Cisco). BGP wird dann nur mit der gewünschten Anzahl an Präfixen bereitgestellt, die dem Peer angekündigt werden.

• Problem 92481: Wenn eine WAN-Schnittstelle auf einem VMware SD-WAN Edge auf dem VMware SASE Orchestrator deaktiviert wird, meldet SNMP die Schnittstelle weiterhin als „AKTIV (UP)“.

  Der Haupt-Debugging-Prozess für die Schnittstellenausgabe enthält nicht die Details der physischen Ports für Edge-WAN-Schnittstellen (z. B. GE3 oder GE4 bei einem Edge 6x0- oder 3x00-Modell). Wenn SNMP diese Schnittstellen abfragt, wird daher immer das Ergebnis AKTIV (UP) zurückgegeben, unabhängig davon, wie diese Schnittstellen konfiguriert sind.

  Problemumgehung: Für dieses Problem gibt es keine Problemumgehung.

• Problem 95399: Wenn eine Ethernet-Verbindung physisch von einer VMware SD-WAN Edge-Schnittstelle getrennt oder an diese angeschlossen wird, erhält VMware SASE Orchestrator keine Benachrichtigung über dieses Ereignis vom Edge und zeigt dies auch nicht in den Kundenereignissen an.

  Kunden sind darauf angewiesen, dass Orchestrator diese Ereignisse auf der Ereignisseite meldet, und wenn sie nicht aufgezeichnet werden, wird die Überwachung ihrer verschiedenen Sites weniger zuverlässig.

  Problemumgehung: Für dieses Problem gibt es keine Problemumgehung.

• Problem 97559: An einer Kundensite mit einer Topologie mit erweiterter Hochverfügbarkeit kann ein WAN-Link, der mit dem VMware SD-WAN Edge in einer Standby-Rolle verbunden ist, auf dem VMware SASE Orchestrator als ausgefallen angezeigt werden und keinen Kundendatenverkehr durchlassen, obwohl die WAN-Schnittstelle des Edge, mit der der WAN-Link verbunden ist, aktiviert ist.

  Ein Benutzer, der einen tcpdump-Befehl oder eine Diagnosepaketprotokollierung anzeigt, stellt fest, dass ARP-Anfragen eingehen und der Standby-Edge nicht antwortet, weil der entsprechende Port blockiert ist. Wenn ein Edge in erweiterter HA die Standby-Rolle übernimmt, sollten die folgenden Ereignisse in dieser Reihenfolge auftreten:

  1. Der Standby-Edge blockiert alle Ports.

  2. Der Standby-Edge erkennt dann, dass er mit erweiterter HA bereitgestellt wird, und hebt die Blockierung seiner WAN-Ports auf, um Datenverkehr weiterzuleiten.

  Wenn dieses Problem auftritt, dauert Ereignis 1, die anfängliche Portsperrung, unerwartet lange, und das Folgeereignis 2, die Aufhebung der Sperrung aller WAN-Ports, wird vor dem Abschluss von Ereignis 1 abgeschlossen. Anschließend wird das Ereignis 1 abgeschlossen, und der endgültige Zustand besteht darin, dass alle WAN-Ports am Standby-Edge blockiert sind.

  Problemumgehung: Auf einem HA-Edge ohne einen Fix für dieses Problem besteht die Problemumgehung darin, ein HA-Failover zu erzwingen, das den Standby-Edge in den aktiven Zustand versetzt und die WAN-Verbindung des HA-Edge herstellt.

• Problem 98136: Für Kundenunternehmen, die eine Hub/Spoke-Topologie verwenden, in der dynamisches Zweigstelle-zu-Zweigstelle-VPN konfiguriert ist, stellen Clientbenutzer hinter einem SD-WAN Spoke Edge möglicherweise fest, dass ein Teil des Datenverkehrs unerwartete Latenzzeiten aufweist, die darauf zurückzuführen sind, dass der Datenverkehr einen suboptimalen Pfad verwendet.

  Spoke-Edge-Datenverkehr, bei dem dieses Problem auftritt, verwendet eine Route, die anfänglich eine Nicht-Uplink-Route für einen Hub-Edge war, der nicht in dem Profil enthalten ist, das der Spoke-Edge verwendet hat. Der dynamische Zweigstelle-zu-Zweigstelle-VPN-Tunnel kann vom Spoke-Edge zum Hub-Edge gebildet werden, da der Datenverkehr an ein anderes nicht zusammenhängendes Präfix gesendet wird und in dieser Instanz die Nicht-Uplink-Route im Spoke-Edge installiert ist.

  Infolge dieser Nicht-Uplink-Route wird der gesamte Datenverkehr in Richtung dieses Präfixes über den

  Hub-Edge geleitet, und die Nicht-Uplink-Route wird zu einer Uplink-Route (Community-Änderung zu Uplink-Community). Die zuvor installierte Nicht-Uplink-Route wird jedoch nicht widerrufen, und der Datenverkehr nimmt den Hub-Edge-Pfad, solange der dynamische Zweigstelle-zu-Zweigstelle-VPN-Tunnel aktiv bleibt.

  Problemumgehung: Warten Sie, bis der dynamische Zweigstelle-zu-Zweigstelle-VPN-Tunnel abbricht. Anschließend wird die Uplink-Route nicht im Spoke-Edge installiert, wenn ein neuer dynamischer Zweigstelle-zu-Zweigstelle-VPN-Tunnel zum Hub-Edge gebildet wird.

• Problem 106289: Ein VMware SD-WAN Hub Edge kann Pakete in Flows zu verbundenen Spoke-Edges oder Backhaul-Flows verwerfen.

  Das Flag „Backhaul-Flow (Backhaul Flow)“ wird während der QoS-Synchronisierung gesetzt – es gibt eine Stelle im Code, an der es während der Flow-Erstellung festgelegt wird. Der Edge sollte dieses Flag nur als Ergebnis der Verarbeitung von QoS-Synchronisierungsmeldungen setzen.

  Problemumgehung: Wenn dieses Problem auf einem Hub-Edge ohne einen Fix auftritt, leeren Sie die Flows auf dem Hub-Edge, um das Problem vorübergehend zu beheben.

• Problem 109771: Ein VMware SD-WAN Edge kann möglicherweise keinen Tunnel mit einem Nicht-SD-WAN-Ziel über Edge vom Typ „Cisco CSR/ASE“ einrichten, wenn NAT66 dazwischen angewendet wird.

  Wenn eine IPv6-Quelladresse zwischen zwei Peers NAT verwendet und mit Cisco CSR/ASA verbunden ist, wird kein Tunnel eingerichtet.

  Problemumgehung: Auf einem Edge ohne einen Fix für dieses Problem kann ein Benutzer lediglich ein Upgrade von Cisco CSR/ASA auf eine Version der Cisco-Software durchführen, die NAT66 über IPsec unterstützt.

• Problem 110561: Dynamische Tunnel werden unter Umständen nicht zwischen denselben VMware SD-WAN Edges mit bidirektionalem Datenverkehr aufgebaut, wenn der Datenverkehr angehalten und dann neu gestartet wird.

  Das Problem tritt in einer Testumgebung auf, in der 6000 dynamische Tunnel mit hohem bidirektionalen Datenverkehr zwischen den Edges gesendet werden. Selbst bei Tests in kleinerem Umfang mit 1000 dynamischen Tunneln werden nicht alle Tunnel aufgebaut.

  Problemumgehung: Für dieses Problem gibt es keine Problemumgehung.

• Problem 111085: Wenn der WAN-Link eines VMware SD-WAN Edge mit einer IP-Adresse im selben Netzwerk wie die Loopback-IP des Edge konfiguriert ist, verwendet der Edge die MAC-Adresse der WAN-Schnittstelle, während er auf eine ARP-Anforderung für die Loopback-IP-Adresse des Edge reagiert.

  Dies kann ARP-Manipulationen verursachen und dazu führen, dass die Verwaltungs-IP als veraltet eingestuft wird und es infolgedessen zu Netzwerkunterbrechungen kommt.

  Problemumgehung: Für dieses Problem gibt es keine Problemumgehung.

• Problem 113877: Bei Kunden, die BGP-/GRE-LAN konfigurieren und TGW GRE verwenden, treten BGP-Flaps und eine Unterbrechung des Datenverkehrs auf dem sekundären TGW-Tunnel in allen Segmenten auf, wenn die BGP-Konfiguration für TGW GRE im globalen Segment geändert wird.

  Wenn der Kunde eine BGP-Konfiguration von TGW GRE im globalen Segment ändert, verengt sich der sekundäre Tunnel im globalen und in anderen Segmenten, was zu einem Zurücksetzen der BGP-Verbindung und einer Neukonvertierung sowie einer Unterbrechung des Datenverkehrs führt. Die BGP-Verbindung wird erneut aufgebaut, und der Datenverkehr wird wiederhergestellt.

  Problemumgehung: Für dieses Problem gibt es keine Problemumgehung.

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

• Problem 117314: Wenn bereits ein ICMP-Flow zwischen einem Quell- und Ziel-IP-Adresspaar besteht, funktioniert eine Firewallregel, die eine Objektgruppe/Dienstgruppe (Typ und Code) zum Filtern von ICMP-Paketen verwendet, möglicherweise nicht.

  Im Rahmen einer Revision der Firewallfunktion wurden die für die Zwischenspeicherung des ICMP-Typs und -Codes eingeführten Änderungen zurückgesetzt. Dies wirkte sich auf Firewallregeln aus, die eine Dienstgruppe mit einem ICMP-Typ und -Code verwendeten (z. B. ICMP-Umleitungstyp 5 und Code 0). Wenn bereits ein Flow zwischen einer Quell- und einer Ziel-IP-Adresse besteht, wird ICMP-Verkehr, der den Regeln für diesen Flow entsprechen sollte, nicht berücksichtigt, und nur die ersten Pakete einer Sitzung entsprechen den Firewallregeln. Das Problem wirkt sich entweder auf IPv4- oder IPv6-ICMP-Flows aus.

  Problemumgehung: Das Leeren von Flows zur Erstellung neuer ICMP-Flows wird das Problem vorübergehend beheben.

• Problem 117876: Wenn ein Benutzer an einer Kunden-Site mit einer Hochverfügbarkeitstopologie die erweiterten Firewalldienste aktiviert oder deaktiviert, kann es bei einem VMware SD-WAN HA Edge zu mehreren Neustarts kommen.

  Wenn Erweiterte Firewalldienste (Enhanced Firewall Services) aktiviert oder deaktiviert ist, wird nur die Konfiguration der Geräteeinstellungen des aktiven Edge sofort mit dem Standby-Edge synchronisiert. Die restliche Konfigurationssynchronisierung erfolgt ausschließlich als Reaktion auf ein Taktsignal des Standby-Edge. Wenn der aktive Edge neu gestartet wird, um die aktuelle Konfiguration anzuwenden, bevor ein Taktsignal vom Standby-Edge empfangen wird, führt dies zu einer Nichtübereinstimmung bei der Konfiguration zwischen den beiden HA-Edges und mehreren Neustarts, um die Konfigurationssynchronisierung abzuschließen.

  Problemumgehung: Die einzige Problemumgehung besteht darin, die erweiterten Firewalldienste während eines Wartungsfensters für HA-Edges zu aktivieren oder zu deaktivieren.

• Problem 121606: Kundenunternehmen, die Partner-Gateways verwenden, stellen möglicherweise fest, dass der Datenverkehr für einige Daten, einschließlich Nicht-SD-WAN-Zielen, die dieses Gateway verwenden, unterbrochen wird.

  Ab Version 5.1.0 unterstützen Partner-Gateways ein Maximum von 64 IP-Adressen pro IPsec-Schnittstelle. Bei einem Partner-Gateway werden Übergabe-IPs bedingungslos zu dieser IPsec-Schnittstelle hinzugefügt. Wenn die Anzahl der Übergabe-IP-Adressen den Grenzwert von 64 überschreitet, werden ältere IP-Adressen im IPsec-Prozess überschrieben, was dazu führt, dass die Tunnel, die diese überschriebenen IP-Adressen verwenden, nicht mehr funktionieren.

  Problemumgehung: Wenn alle Übergabe-IP-Adressen des Partner-Gateways wie erwartet konfiguriert sind, besteht die einzige Lösung im Verschieben einiger dieser Adressen zu einem anderen PG (z. B. Verschieben eines NSD über Gateway). Nicht benötigte PG-Übergabe-IP-Adressen sollten jedoch entfernt werden, wenn es dadurch zur Reduzierung der Gesamtzahl der Übergabe-IP-Adressen auf 63 oder weniger kommt. Nach einer Konfigurationsänderung muss der Gateway-Dienst neu gestartet werden.

• Problem 121998: Bei einem Kunden, der die statusbehaftete Firewall in einer Hub/Spoke-Topologie verwendet, kann Datenverkehr, der mit einer Firewallregel übereinstimmt, die für Spoke-zu-Hub-Datenverkehr konfiguriert ist, bei dem die Regel ein Quell-VLAN enthält, verworfen werden.

  Wenn eine Anwendungsklassifizierungs-, Business Policy- oder Firewallrichtlinientabellenversion geändert wird, führt SD-WAN eine Firewall-Suche nach Flows für das nächste Paket durch. Aufgrund eines Zeitproblems könnte es sich bei diesem Paket um ein Paket aus dem Managementverkehr (VCMP) handeln. Infolgedessen vertauscht SD-WAN während der Erstellung eines Firewall-Richtlinien-Lookup-Schlüssels das Spoke-Edge-VLAN mit dem Hub-Edge-VLAN, was dazu führt, dass die Regel nicht erfüllt und der Verkehr verworfen wird.

  Problemumgehung: Ein Kunde kann die Quelle von einem Edge-VLAN in „Beliebig (Any)“ ändern.

• Problem 125274: Wenn ein Kunde einen SNMP-Walk ausführt, wird die Loopback-Schnittstelle des VMware SD-WAN Edge nicht erkannt.

  Die Edge-Loopback-Schnittstelle ist eine eindeutige Schnittstellenkategorie, die der Edge weder als WAN noch als LAN klassifiziert. Infolgedessen befindet sich die Loopback-Schnittstelle nicht in der Positivliste der Schnittstellen, die für snmp-request verarbeitet werden sollen.

  Problemumgehung: Für dieses Problem gibt es keine Problemumgehung. Der Status der Loopback-Schnittstelle muss einzeln über die Orchestrator-Benutzeroberfläche überwacht werden.

• Problem 125421: Ein Kunde stellt möglicherweise fest, dass die WAN-Links auf einem VMware SD-WAN Edge auf der Seite „Überwachung und Ereignisse (Monitoring and Events)“ der VMware SASE Orchestrator-Benutzeroberfläche zeitweise als inaktiv und aktiv angezeigt werden. Dies kann dazu führen, dass der Edge nicht mehr reagiert und den Datenverkehr erst nach einem manuellen Neustart weiterleitet oder dass der Datenebene-Dienst ausfällt und der Edge neu gestartet wird.

  Hierbei handelt es sich um ein wegen Speicherverlust beim Edge verursachtes Problem, das auftritt, wenn der Edge-Datenebene-Dienst den gemeinsam genutzten Arbeitsspeicher nicht öffnen kann und es zu veralteten PIs kommt. Dies wiederum führt zu einer Überlastung der offenen Dateideskriptoren mit anfänglichen Auswirkungen auf die WAN-Links. Wenn dieses Problem jedoch weit genug fortgeschritten ist und zu einer Überlastung des Edge-Arbeitsspeichers führt, sind folgende Szenarien möglich:

  1. Der Edge reagiert nicht mehr und ist nicht mehr über den Orchestrator erreichbar, sodass der Edge vor Ort neu gestartet und/oder ein- und ausgeschaltet werden muss.

  2. Der Edge kann einen Ausfall des Edge-Diensts mit einer erzeugten Kerndatei auslösen, wobei der Edge zur Wiederherstellung neu gestartet wird.

  Problemumgehung: Wenn Sie dieses Problem zum ersten Mal beobachten, planen Sie einen Neustart des Edge-Diensts in einem Wartungsfenster, bevor sich das Problem verschlimmert.

• Problem 134374: Regeln für eingehende Firewall, die einer VMware SD-WAN Edge CELL-Schnittstelle zugeordnet sind, werden nicht wie erwartet nacheinander angewendet.

  Wenn die Edge CELL-Schnittstelle entweder noch nicht erstellt wurde oder nicht verfügbar ist (z. B. keine SIM-Karte eingelegt), wird der Wert der CELL-Schnittstelle beim Analysieren der Firewallkonfiguration nicht korrekt für die Firewallregel aufgefüllt und der Datenverkehr stimmt nicht mit der Regel überein.

  Problemumgehung: Löschen Sie die Regel und erstellen Sie sie neu, nachdem die CELL-Schnittstelle in Betrieb ist.

Bekannte Probleme bei Orchestrator

• Problem 21342:

  Bei der Zuweisung von Partner-Gateways pro Segment wird die richtige Liste der Gateway-Zuweisungen unter der Operator-Option „Gateways anzeigen (View Gateways)“ in der Überwachungsliste des VMware SD-WAN Edge möglicherweise nicht angezeigt.

• Problem 24269:

  Überwachen (Monitor) > Transport > Verlust (Loss) stellt einen erkannten WAN-Link-Verlust nicht dar, die QoE-Diagramme hingegen schon. 

• Problem 25932:

  VMware SD-WAN Orchestrator ermöglicht das Entfernen von VMware SD-WAN Gateways aus dem Gateway-Pool, auch wenn sie verwendet werden.

• Problem 32335:

  Die EUSA-Seite (End User Service Agreement) gibt einen Fehler aus, wenn ein Benutzer versucht, die Vereinbarung zu akzeptieren.

  Problemumgehung: Stellen Sie sicher, dass der Name des Unternehmens keine vorangestellten oder nachfolgenden Leerzeichen enthält.

• Problem 32435:

  Eine VMware SD-WAN Edge-Überschreiben für eine richtlinienbasierte NAT-Konfiguration ist für Tupel zulässig, die bereits auf Profilebene konfiguriert sind und umgekehrt.

• Problem 32856:

  Obwohl eine Business Policy so konfiguriert ist, dass der Hub-Cluster für den Backhaul des Internetdatenverkehrs verwendet wird, kann der Benutzer die Auswahl des Hub-Clusters in einem Profil in einem VMware SD-WAN Orchestrator aufheben, der von Version 3.2.1 auf Version 3.3.x aktualisiert wurde.

• Problem 35658:

  Wenn ein VMware SD-WAN Edge zu einem anderen Profil verschoben wird, das eine andere CSS-Einstellung aufweist (z. B. IPSec in Profil1 zu GRE in Profil2), werden als CSS-Einstellungen auf Edge-Ebene weiterhin die vorherigen CSS-Einstellungen verwendet (z. B. IPSec gegenüber GRE). 

  Problemumgehung: Deaktivieren Sie GRE auf der Edge-Ebene und aktivieren Sie dann GRE wieder, um das Problem zu beheben.

• Problem 35667:

  Wenn ein VMware SD-WAN Edge von einem Profil zu einem anderen verschoben wird, das dieselbe CSS-Einstellung aufweist, aber einen anderen GRE CSS-Namen hat (dieselben Endpoints), werden einige GRE-Tunnel bei der Überwachung nicht angezeigt.

  Problemumgehung: Deaktivieren Sie GRE auf der Edge-Ebene und aktivieren Sie dann GRE wieder, um das Problem zu beheben.

• Problem 36665:

  Wenn der VMware SD-WAN Orchestrator das Internet nicht erreichen kann, werden die Seiten der Benutzeroberfläche, die Zugriff auf die Google Maps-API erfordern, möglicherweise nicht vollständig geladen.

• Problem 32913:

  Nach der Aktivierung der Hochverfügbarkeit werden die Multicast-Details für den VMware SD-WAN Edge nicht auf der Seite „Überwachung“ (Monitoring) angezeigt. Bei einem Failover wird das Problem behoben.

• Problem 33026:

  Die EUSA-Seite (End User Service Agreement) wird nach dem Löschen der Vereinbarung nicht ordnungsgemäß geladen.

• Problem 38056:

  Die Datei „Edge-Licensing export.csv“ enthält keine Regionsdaten.

• Problem 38843:

  Wenn eine Anwendungszuordnung weitergegeben wird, gibt es kein Operator-Ereignis, und das Edge-Ereignis ist von begrenztem Nutzen.

• Problem 39633:

  Der Super-Gateway-Hyperlink funktioniert nicht mehr, nachdem ein Benutzer das alternative Gateway als Super-Gateway zugewiesen hat.

• Problem 39790:

  Mit VMware SD-WAN Orchestrator kann ein Benutzer die geroutete Schnittstelle eines VMware SD-WAN Edge so konfigurieren, dass mehr als die unterstützten 32 Teilschnittstellen vorhanden sind. Dadurch besteht das Risiko, dass ein Benutzer 33 oder mehr Teilschnittstellen für eine Schnittstelle konfigurieren kann, was zu einem Ausfall des Datenebenendiensts für den Edge führen würde.

• Problem 41691:

  Der Benutzer kann das Feld „Anzahl der Adressen (Number of addresses)“ nicht ändern, obwohl der DHCP-Pool auf der Seite Konfigurieren (Configure) > Edge > Gerät (Device) nicht erschöpft ist.

• Problem 43276:

  Der Benutzer kann den Segmenttyp nicht ändern, wenn für einen VMware SD-WAN Edge bzw. ein Profil ein Partner-Gateway konfiguriert ist.

  Problemumgehung: Entfernen Sie die Partner-Gateway-Konfiguration vorübergehend aus dem Profil oder Edge, sodass das Segment zwischen privatem und regulärem geändert werden kann. Alternativ kann der Benutzer das Segment aus dem Profil entfernen und von dort aus die Änderung vornehmen.

• Problem 47713:

   Wenn eine Business Policy-Regel bei ausgeschaltetem Cloud-VPN konfiguriert wird, muss die NAT-Konfiguration beim Einschalten von Cloud-VPN neu konfiguriert werden.

• Problem 47820:

  Wenn ein VLAN mit deaktiviertem DHCP auf Profilebene konfiguriert ist, während gleichzeitig eine Edge-Überschreibung für dieses VLAN auf diesem Edge mit aktiviertem DHCP vorhanden ist, und ein Eintrag für das DNS-Serverfeld auf „Keine (None)“ (keine IP konfiguriert) gesetzt ist, kann der Benutzer auf der Seite Konfigurieren (Configure) > Edge > Gerät (Device) keine Änderungen vornehmen und erhält die Fehlermeldung „Ungültige IP-Adresse (Invalid IP address)“, die das eigentliche Problem weder erklärt noch aufzeigt.

• Problem 48085: VMware SD-WAN Orchestrator ermöglicht es einem Benutzer, ein VLAN zu löschen, das mit einer Schnittstelle verknüpft ist.

  Wenn dieses Problem auftritt, wird dem Benutzer eine Fehlermeldung ähnlich der folgenden angezeigt: „VLAN-ID [xx] kann nicht entfernt werden, wird von Edge [b1-edge1 (GEx-disabled]) verwendet“ (VLAN ID [xx] cannot be removed, in use by edge [b1-edge1 (GEx-disabled]).

• Problem 51722: In VMware SASE Orchestrator kann für eine beliebige Statistik auf den Registerkarten „Überwachen (Monitor) > Edge“ ein Zeitraum von maximal 2 Wochen ausgewählt werden.

  Zur Auswahl des Zeitraums steht auf den Registerkarten Überwachen (Monitor) > Edge nur die Option „Letzte 2 Wochen (Past 2 Weeks)“ bereit, selbst wenn der Aufbewahrungszeitraum für einen Satz von Statistiken wesentlich mehr als 2 Wochen beträgt. Flow- und Link-Statistiken werden standardmäßig 365 Tage (konfigurierbar) beibehalten, während Pfadstatistiken standardmäßig nur 2 Wochen (ebenfalls konfigurierbar) aufbewahrt werden. Dieses Problem führt dazu, dass alle Überwachungsregisterkarten mit dem niedrigsten beibehaltenen Statistiktyp übereinstimmen, während ein Benutzer einen Zeitraum auswählen kann, der dem Aufbewahrungszeitraum für diese Statistik entspricht.

  Problemumgehung: Ein Benutzer kann die Option „Benutzerdefiniert (Custom)“ in der Zeitraumauswahl verwenden, um Daten für mehr als 2 Wochen anzuzeigen.

• Problem 60522: Auf der VMware SD-WAN Orchestrator-Benutzeroberfläche beobachtet der Benutzer eine große Anzahl von Fehlermeldungen, wenn er versucht, ein Segment zu entfernen.

  Dieses Problem kann beobachtet werden, wenn ein Segment zu einem Profil hinzugefügt und das Segment mehreren VMware SD-WAN Edges zugeordnet wird. Wenn der Benutzer versucht, das hinzugefügte Segment aus dem Profil zu entfernen, wird eine große Anzahl von Fehlermeldungen angezeigt.

  Problemumgehung: Für dieses Problem gibt es keine Problemumgehung.

• Problem 82095: Der Benutzer kann ungültige Geräteeinstellungen für Edge-VLANs konfigurieren, was beim Edge zu erheblichen Verbindungsproblemen führt.

  Der Orchestrator versucht nicht, Gerätekonfigurationen zu validieren. Insbesondere eine VLAN-Konfiguration für einen geswitchten Port mit einer leeren Tabelle. Bestimmte Konfigurationen können so fehlerhaft sein, dass der Verwaltungsvorgang des Edge fehlschlägt.

  Problemumgehung: Überprüfen Sie alle VLAN-Geräteeinstellungen und stellen Sie sicher, dass sie gültig sind, da der Orchestrator sie nicht überprüft.

• Problem 82680: Bei Kunden, die MT-GRE-Tunnelautomatisierung verwenden, werden die Zscaler MT-GRE-Einträge möglicherweise nicht konsistent aus dem Zscaler-Portal gelöscht. Dies ist der Fall, wenn ein Benutzer das Cloud-to-Cloud Interconnect (CCI)-Flag auf einem VMware SD-WAN Gateway deaktiviert, das für die Verwendung von CCI konfiguriert ist.

  Nachdem eine CCI-Site aus dem Gateway gelöscht wurde, sollten auch die Einträge für diese Site entfernt werden. Dieses Problem wurde nur während der Testautomatisierung festgestellt und konnte nicht manuell reproduziert werden, bleibt aber ein Risiko.

  Problemumgehung: Löschen Sie die Ressource manuell aus Zscaler, bevor Sie es erneut versuchen.

• Problem 82681: Bei Kunden, die MT-GRE-Tunnelautomatisierung verwenden, werden die Zscaler MT-GRE-Einträge möglicherweise nicht vom Edge oder vom Zscaler-Portal gelöscht, wenn ein Benutzer das Cloud-to-Cloud Interconnect (CCI)-Flag auf einem VMware SD-WAN Gateway deaktiviert, das für die Verwendung von CCI konfiguriert ist, und der Benutzer das CCI-Flag von einem VMware SD-WAN Edge mit konfiguriertem CCI deaktiviert, der einen Zscaler Cloud-Security-Service verwendet.

  Nachdem eine CCI-Site aus dem Gateway gelöscht wurde, sollten auch die Einträge für diese Site entfernt werden. Dieses Problem wurde nur während der Testautomatisierung festgestellt und konnte nicht manuell reproduziert werden, bleibt aber ein Risiko.

  Problemumgehung: Löschen Sie die Ressource manuell aus Zscaler, bevor Sie es erneut versuchen.

• Problem 103769: Ein Operator kann feststellen, dass ein VMware SASE Orchestrator in einer groß angelegten Bereitstellung Leistungsprobleme aufweist, die eine 100%ige Festplattenauslastung und die Tatsache umfassen, dass der Orchestrator keine Protokolle mehr speichert.

  Die Ursache für dieses Problem ist eine Änderung des Protokollierungsverhaltens für den Orchestrator 5.1.0, die dazu führen kann, dass die Ordner, in denen die Protokolle gespeichert werden, voll werden und die CPU des Orchestrators eine Auslastung von 100 % erreicht. Die Ursache für dieses Problem ist eine Änderung des Protokollierungsverhaltens für den Orchestrator 5.1.0, die dazu führen kann, dass die Ordner, in denen die Protokolle gespeichert werden, voll werden und die CPU des Orchestrators eine Auslastung von 100 % erreicht.

  Problemumgehung: Ein Superuser-Operator muss sich beim Orchestrator anmelden und die ausstehenden Protokolle bereinigen.

• Problem 117699: Ein Operator, der ein Upgrade eines VMware SD-WAN Orchestrator der Version 4.2.x auf einen SASE Orchestrator der Version 5.2.0 durchführt, stellt unter Umständen fest, dass das Upgrade fehlschlägt.

  Das Upgrade schlägt fehl und bleibt bei der Meldung „Warten auf den CWS-Dienst... (Waiting for the CWS service up...)“ hängen. Dieses Problem ist auf Orchestrator-Instanzen der Version 4.2.x beschränkt.

  Problemumgehung: Um dieses Problem zu umgehen, führen Sie zunächst ein Upgrade von Orchestrator 4.2.x auf 4.5.1 und dann auf Version 5.2.0.0 durch.

• Problem 118501: Wenn ein Benutzer auf der Seite „Überwachen (Monitor) > Edges“ auf „CSV“ klickt, um seine Liste aller SD-WAN Edges herunterzuladen, lädt der Orchestrator nur maximal 2048 Edges herunter..

  Dies wirkt sich auf Kunden mit mehr als 2048 Edges in ihrem Unternehmen aus, die eine vollständige Liste aller Edges herunterladen müssen.

  Problemumgehung: Die einzige Problemumgehung besteht darin, den Download durch Sortieren der Edges in zwei oder mehr Teile aufzuteilen.

• Problem 122193: Auf der Seite „Konfigurieren (Configure) > Edges > Firewall“ kann ein Benutzer beim Konfigurieren einer Firewall-Regel für einen Edge als Firewall-Aktion nur „Zulassen (Allow)“ auswählen.

  Wenn der Benutzer auf die Firewall-Aktion (Firewall Action) klickt, wird das Dropdown-Menü für den Bruchteil einer Sekunde angezeigt und dann sofort wieder ausgeblendet, und der Benutzer kann nicht von der Standardoption Zulassen (Allow) zu einer anderen Option wechseln.

  Problemumgehung: Für dieses Problem gibt es keine Problemumgehung.

• Problem 125082: Wenn ein Benutzer einen VMware SD-WAN Edge mit einer überschriebenen DNS-Server-IP-Adresse in einem VLAN konfiguriert und dann eine Schnittstelleneinstellung für das vom Edge verwendete Profil ändert, ist die DNS-Server-IP-Adresse nicht mehr für das Edge-VLAN vorhanden.

  Die Benutzeroberfläche sendet das Überschreibungsflag nicht innerhalb des DHCP-Abschnitts. Dies führt dazu, dass alle Profiländerungen eine Überschreibung des DHCP-Abschnitts auslösen.

  Problemumgehung: Nach einer Profiländerung muss der Benutzer die überschriebenen DHCP-Optionen auf einzelnen Edges überprüfen und korrigieren.

• Problem 125504: Wenn eine statische Route mit dem nächsten Hop als VLAN mit IPv4/IPv6-Adresse auf Profilebene konfiguriert und dann auf Edge-Ebene überschrieben wird und dem VLAN eine IPv4/IPv6-Adresse hinzugefügt wird, wird die statische Route nicht als „Nicht verfügbar (N/A)“ markiert und der VMware SASE Orchestrator fragt in einem Dropdown-Menü nach der Schnittstelle.

  Das erwartete Verhalten ist, dass bei einer statischen Route, die mit einem nächsten Hop als VLAN mit IPv4/IPv6-Adresse konfiguriert ist, der Orchestrator nicht nach der Schnittstelle fragt und die Route als „Nicht verfügbar (N/A)“ markiert ist.

  Problemumgehung: Für dieses Problem gibt es keine Problemumgehung.

• Problem 125663: Ein Benutzer kann dieselbe IPv4-/IPv6-IP-Adresse für mehrere Edge-Schnittstellen konfigurieren.

  Der VMware SASE Orchestrator ermöglicht es einem Benutzer, dieselbe IP auf mehreren WAN-, LAN- oder Teilschnittstellen zu konfigurieren.

  Problemumgehung: Es gibt keine Umgehung für dieses Problem, außer Sie stellen sicher, dass Sie nicht dieselbe IP-Adresse für mehrere Schnittstellen konfigurieren.

• Problem 126421: Bei Partnern, die ein Partner-Gateway verwenden, ist bei der Konfiguration der Übergabedetails die Option „Für private Tunnel verwenden (Use for Private Tunnels)“ immer aktiviert, unabhängig davon, was ein Benutzer tut.

  Dies ist kein kosmetisches Problem, da der Orchestrator die Konfiguration Für private Tunnel verwenden (Use for Private Tunnels) auf die Partner-Gateway-Übergabe anwendet und den Kundendatenverkehr über das Partner-Gateway beeinträchtigen kann.

  Problemumgehung: Es gibt keine Umgehung für dieses Problem auf einer Orchestrator-Instanz mit nur einer neuen Benutzeroberfläche.

• Problem 126425: Auf der Seite „Konfigurieren (Configure) > Gerät (Device) > Routing und NAT (Routing & NAT)“ auf der Profilebene fehlt die Umschaltfläche „OSPF Ein/Aus (OSPF On/Off)“.

  Die Umschaltfläche „OSPF Ein/Aus (OSPF On/Off)“ wurde nicht zur neuen Benutzeroberfläche auf Profilebene migriert und wird nur auf der Edge-Ebene angezeigt.

  Problemumgehung: Es gibt keine Umgehung für dieses Problem auf einer Orchestrator-Instanz mit nur einer neuen Benutzeroberfläche.

• Problem 126465: Die VMware SASE Orchestrator-Benutzeroberfläche übernimmt keine Änderungen, die ein Benutzer zur Erstellung eines Edge-Clusters vornimmt.

  Wenn ein Benutzer den Abschnitt Konfigurieren (Configure) > Edge > Hochverfügbarkeit (High Availability) der Benutzeroberfläche aufruft, HA mit einem Clustertyp aktiviert und einen Hub-Cluster mit dem Namen xxxx erstellt und die Änderungen speichert, stellt der Benutzer fest, dass nach dem Speichern die Option „Cluster“ im Abschnitt HA nicht ausgewählt ist und der erstellte Hub-Cluster mit dem Namen xxxx nicht vorhanden ist.

  Problemumgehung: Es gibt keine Umgehung für dieses Problem auf einer Orchestrator-Instanz mit nur einer neuen Benutzeroberfläche.

• Problem 127152: Benutzer können geänderte Schnittstellen mit OSPF-Konfigurationen auf der VMware SASE Orchestrator-Benutzeroberfläche nicht speichern.

  Auf der Profilebene wird bei der Konfiguration von OSPFv2/OSPFv3 das Dialogfeld „Schnittstelle bearbeiten (Edit Interface)“ nach der Änderung von OSPF-Daten ungültig.

  Problemumgehung: Auf einer Orchestrator-Instanz ohne Fix für dieses Problem muss ein Benutzer die MD5-Authentifizierung aktivieren und die Schlüssel-ID auf eine beliebige Zahl zwischen 1 und 255 ändern und anschließend die MD5-Authentifizierung deaktivieren.

• Problem 128070: Wenn ein Benutzer OSPFv3 für ein VLAN auf Edge-Ebene konfiguriert und versucht, dem VLAN IPv6-Einstellungen hinzuzufügen, speichert die VMware SASE Orchestrator-Benutzeroberfläche die Änderungen nicht.

  Die Option zum Speichern ist ausgeblendet und nicht verfügbar, wenn versucht wird, IPv6-Einstellungen (IPv6 Settings) zu einem VLAN mit OSPF3 auf der Edge-Ebene hinzuzufügen.

  Problemumgehung: Es gibt keine Umgehung für dieses Problem auf einer Orchestrator-Instanz mit nur einer neuen Benutzeroberfläche.

• Problem 129232: Ein Benutzer kann auf dem VMware SASE Orchestrator kein Kennwort selbst zurücksetzen.

  Wenn der Benutzer versucht, den Link zum Zurücksetzen des Kennworts direkt im Browser aufzurufen, wird er auf die Anmeldeseite statt auf die Seite zum Zurücksetzen des Kennworts weitergeleitet.

  Problemumgehung: Ein Benutzer, der sein Kennwort zurücksetzen musste, muss sich an einen Enterprise-Superuser in seiner Organisation, einen Partneradministrator (falls zutreffend) oder VMware SD-WAN Support wenden, um sein Kennwort zurückzusetzen.

• Problem 129412: Auf der Seite „Konfigurieren (Configure) > Edge > Gerät (Device) > Konnektivität (Connectivity) > VLAN“ der Benutzeroberfläche im Abschnitt „IPv4-DHCP-Server (IPv4 DHCP Server)“ ist die Anzahl der Adressen möglicherweise ungenau.

  Das Verhalten tritt auf, wenn ein Benutzer später den ursprünglichen DHCP-Wert bearbeitet, um die Anzahl der Adressen zu erhöhen und die Benutzeroberfläche weiterhin die ältere, niedrigere Anzahl von Adressen anzeigt.

  Problemumgehung: Dies ist ein kosmetisches Problem, und der tatsächliche DHCP-Wert wird angewendet.

• Problem 129662: Ein Benutzer kann nicht erkennen, ob eine VMware SD-WAN-Schnittstelle aktiviert oder deaktiviert ist, wenn er die Seite „Konfigurieren (Configure) > Edge > Gerät (Device) > Schnittstellen (Interfaces)“ der Orchestrator-Benutzeroberfläche aufruft.

  Die VMware SASE Orchestrator-Benutzeroberfläche weist keine farbliche Unterscheidung zwischen aktivierten und deaktivierten Schnittstellen auf, weshalb Kunden eine deaktivierte Teilschnittstelle nicht erkennen können.

  Problemumgehung: Für dieses Problem gibt es keine Problemumgehung.

• Problem 129958: Auf der Seite „Konfigurieren (Configure) > Edge > Gerät (Device) > Konnektivität (Connectivity) > VLAN“ der Benutzeroberfläche im Abschnitt „IPv4-DHCP-Server (IPv4 DHCP Server)“ kann der Benutzer die Anzahl der Adressen nur ändern, wenn er zuerst das allgemeine VLAN überschreibt.

  Bisher konnte ein Benutzer einen Teilbereich eines Edge-VLANs wie DHCP oder OSPF überschreiben, während der Rest der Konfiguration aus dem Profil übernommen wurde. In diesem Fall muss der Benutzer das gesamte VLAN überschreiben, damit er den DHCP-Teil davon bearbeiten kann.

  Problemumgehung: Ein Benutzer kann nur das gesamte VLAN überschreiben, um Einstellungen darin zu bearbeiten.

• Problem 131299: Wenn der Benutzer auf der Seite „Konfigurieren (Configure) > Overlay-Flow-Steuerung (Overlay Flow Control)“ der Benutzeroberfläche das Segment für ein Nicht-SD-WAN-Ziel über Gateway ändert, das statische Routen verwendet, zeigt die OFC-Tabelle die aktualisierten statischen Routen nicht an.

  Stattdessen zeigt die OFC-Tabelle die Ergebnisse unter Verwendung des zuvor ausgewählten Segments an, was den Benutzer zu der Annahme verleitet, dass seine Konfigurationsänderung nicht angewendet wurde, obwohl dies tatsächlich der Fall war.

  Problemumgehung: Es gibt keine Problemumgehung, aber dieses Problem ist kosmetischer Natur, und die statischen Routen müssen in der Tat in das neue Segment geändert werden.

• Problem 131997: Ein ICMP-Test wird möglicherweise fälschlicherweise als inaktiv markiert, wenn er für ein Segment konfiguriert ist, aber nicht für ein anderes.

  Der Orchestrator kann die NULL-ICMP-Testkonfiguration nicht senden, wenn sie nicht in einem Segment konfiguriert ist. Dies hat zur Folge, dass die Konfiguration eines anderen Segments wiederverwendet wird, was zu einem Ausfall der Sonden führt.

  Problemumgehung: Konfigurieren Sie auf einem Orchestrator ohne Fix für dieses Problem einen Dummy-ICMP-Test für die anderen Segmente.

• Problem 133201: Wenn ein Benutzer auf der Seite „Globale Einstellungen (Global Settings) > Benutzerverwaltung (User Management)“ der Orchestrator-Benutzeroberfläche eine benutzerdefinierte Rolle erstellt oder bearbeitet und versucht, den Parameter „Löschen (Delete)“ für PCAP-Paketberechtigungen zu ändern, ändert die Benutzeroberfläche auch alle anderen Parameter für das PCAP-Paket.

  Wenn ein Benutzer beispielsweise das PCAP-Paket für Löschung (Deletion) deaktiviert, deaktiviert die Benutzeroberfläche auch die Parameter Lesen (Read), Aktualisieren (Update) und Erstellen (Create), selbst wenn der Benutzer die Aktivierung dieser Parameter beibehalten möchte.

  Problemumgehung: Ein Benutzer muss die vorgenommenen Änderungen beachten und die Parameter Lesen (Read), Aktualisieren (Update) und Erstellen (Create) nach Bedarf wiederherstellen.

• Problem 133642: Auf der Seite „Konfigurieren (Configure) > Edge > Gerät (Device) > Konnektivität (Connectivity) > VLAN“ der Benutzeroberfläche wird das VLAN des Edge standardmäßig automatisch auf Überschreiben festgelegt, und ein Benutzer kann diese Einstellung nicht deaktivieren.

  Wenn ein Benutzer ein VLAN auf Profilebene erstellt, wird erwartet, dass die Einstellung Edge-Überschreiben (Edge Override) standardmäßig deaktiviert ist und der Benutzer sich dafür entscheiden muss, Edge-Überschreiben (Edge Override) pro Edge zu aktivieren.

  Problemumgehung: Es gibt keine andere Problemumgehung als die Überprüfung jedes Edge, die dieses Profil verwendet, und die Deaktivierung der Edge-Überschreiben (Edge Override) nach Bedarf.