Versionshinweise für VMware SASE 5.4.0

VMware SASE 5.4.0 | 16. November 2023 VMware SASE™ Orchestrator Version R5401-20231115-GA VMware SD-WAN™ Gateway-Version R5400-20231009-GA VMware SD-WAN™ Edge-Version R5400-20231108-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 SASE-Funktionen und -Erweiterungen
• Neue SD-WAN-Funktionen und ‑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.4.0 zur Verfügung gestellt wurden.

Wichtig:

Version 5.4.0 enthält alle Fixes für Edge und Gateway, die in den Versionshinweisen zu Version 5.2.0 bis Version 5.2.0.2 aufgeführt sind, sowie alle Fixes für Orchestrator, die in den Versionshinweisen zu Version 5.2.0 bis Version 5.2.0.3 und in den Versionshinweisen zu Version 5.3.0 bis Version 5.3.0.2 aufgeführt sind.

Kompatibilität

Version 5.4.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.4.0	4.2.2	4.2.2	4.2.2
5.4.0	5.4.0	4.2.2	4.2.2
5.4.0	5.4.0	5.4.0	4.2.2
5.4.0	5.4.0	4.2.2	5.4.0
5.4.0	4.3.2	4.3.2	4.3.2
5.4.0	5.4.0	4.3.2	4.3.2
5.4.0	5.4.0	5.4.0	4.3.2
5.4.0	5.4.0	4.3.2	5.4.0
5.4.0	4.5.2	4.5.2	4.5.2
5.4.0	5.4.0	4.5.2	4.5.2
5.4.0	5.4.0	5.4.0	4.5.2
5.4.0	5.4.0	4.5.2	5.4.0
5.4.0	5.0.1.3	5.0.1.3	5.0.1.3
5.4.0	5.4.0	5.0.1.3	5.0.1.3
5.4.0	5.4.0	5.4.0	5.0.1.3
5.4.0	5.4.0	5.0.1.3	5.4.0
5.4.0	5.1.0.3	5.1.0.2	5.1.0.2
5.4.0	5.4.0	5.1.0.2	5.1.0.2
5.4.0	5.4.0	5.4.0	5.1.0.2
5.4.0	5.4.0	5.1.0.2	5.4.0
5.4.0	5.2.0.1	5.2.0.1	5.2.0.1
5.4.0	5.4.0	5.2.0.1	5.2.0.1
5.4.0	5.4.0	5.4.0	5.2.0.1
5.4.0	5.4.0	5.2.0.1	5.4.0
5.4.0	5.4.0	5.4.0	5.4.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.4.0 durchführen möchten.

Orchestrator

Orchestrator-Instanzen mit Version 4.3.0 oder höher können auf Version 5.4.0 aktualisiert werden. 

Gateway

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

Wichtig:

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

Wichtig:

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

Edge

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

Neue SASE-Funktionen und -Erweiterungen

Bastion-Orchestrator, Phase 2

VMware SASE wurde erstmals in Version 4.3.0 eingeführt und bietet in Version 5.4.0 wichtige Verbesserungen für den Bastion-Orchestrator. Zu den Verbesserungen der Phase 2 gehören:

• SD-WAN Edge Software-Update, wenn sich der Edge im aktivierten Zustand befindet.

• Zurücksetzen auf die letzte bekannte gute Konfiguration im Falle eines Edge-Heraufstufungsfehlers.

• Ereignisse von einem nicht heraufgestuften Edge werden an einen privaten VMware SASE Orchestrator gesendet.

• Erstellung eines Diagnosepakets für einen nicht heraufgestuften Edge.

• Enterprise Firmware-Updates auf dem Bastion VMware SASE Orchestrator.

In den VMware SASE Orchestrator integrierter SD-WAN Client

Der VMware SD-WAN Client kann jetzt über den VMware SASE Orchestrator verwaltet werden und bietet damit eine einheitliche Verwaltungskonsole für die Verwaltung von Netzwerk-, Sicherheits- und Remote Access-Lösungen.

Neue SD-WAN-Funktionen und ‑Verbesserungen

Edge-Firewall-Unterstützung für FTPv6

Version 5.4.0 enthält eine verbesserte Anwendungserkennung sowohl für den aktiven als auch den passiven FTPv4/FTPv6-Modus, wenn Sie VMware SD-WAN Deep Packet Inspection (DPI) verwenden. Diese verbesserte DPI ist besonders hilfreich für Kunden, die den passiven FTPv6-Modus verwenden, der zufällige Portnummern für die Datenübertragung zuweist und die Identifizierung des FTP-Datenverkehrs erschwert, da dieser nicht die Standardports 20 und 21 verwendet.

Verbesserter erweiterter Firewalldienst – Verbesserungen bei der Anzeige und Suche

Der Erweiterte Firewalldienst enthält jetzt eine Firewall-Tabellenansicht mit einem Kommentarfeld und einer neuen Suchfunktion für Firewallregeln und ‑objekte, um eine optimale Benutzerfreundlichkeit zu gewährleisten.

Erweiterter Firewalldienst – Signaturansicht (IDS/IPS)

Der erweiterte Firewalldienst enthält eine verbesserte Signaturansicht (IDS/IPS), die eine vereinfachte Ansicht mit Sichtbarkeit der auf einem VMware SD-WAN Edge installierten Signaturen von Eindringungserkennungssystemen (IDS) und Eindringungsverhinderungssystemen (IPS) sowie der installierten Version, Datum und Uhrzeit bietet.

Verbesserungen bei der Hochverfügbarkeit, Phase 2

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

• Alarme: Der Liste auf der Seite Diensteinstellungen (Service Settings) > Alarme und Benachrichtigungen (Alerts & Notifications) wurde ein neuer Alarm hinzugefügt: Edge HA fehlgeschlagen (Edge HA Failed). Der Alarm Edge HA fehlgeschlagen (Edge HA Failed) wird ausgelöst, wenn der Standby-Edge kein Taktsignal an den aktiven Edge senden kann und vom aktiven Edge als inaktiv markiert wird. Dieser Alarm ist besonders nützlich bei erweiterten HA-Bereitstellungen, bei denen der Standby-Edge auch Kundendatenverkehr weiterleitet.

• Kompatibilität zwischen WLAN- und nicht WLAN-fähigen Edges: Vor Edge-Version 5.4.0 konnten Edge-Modelle, die kein WLAN-Modul enthielten (510N, 610N, 620N, 640N und 680N), nicht mit einem WLAN-fähigen Gegenstück in einer HA-Bereitstellung eingesetzt werden. So wurden beispielsweise ein Edge 640 und ein Edge 640N nicht als Hochverfügbarkeitspaar unterstützt. Ab Version 5.4.0 wird diese Kombination nun unterstützt.

Hinweis:

In einem Szenario mit nicht übereinstimmenden WLAN- und Nicht-WLAN-Edges erkennt der Orchestrator die Nichtübereinstimmung der Edges und deaktiviert automatisch die WLAN-Fähigkeit auf dem Edge, der WLAN-fähig ist. Das Protokoll der Nichtübereinstimmung wird in den Ereignissen des Kunden angezeigt:

• Nicht übereinstimmende HA-WLAN-Funktionalität erkannt, WLAN wird deaktiviert (eine nicht übereinstimmende Edge-WLAN-Funktionalität wird erkannt und WLAN wird auf dem WLAN-fähigen Edge deaktiviert).

• Nicht übereinstimmende WLAN-Funktionalität wird nicht mehr erkannt, WLAN wird wiederhergestellt(beide Edges werden als derselbe WLAN-Typ erkannt und die WLAN-Funktionalität wird auf einem WLAN-Edge wiederhergestellt, auf dem sie zuvor deaktiviert war).

Hub- oder Cluster-Interconnect ist allgemein verfügbar (GA)

Hub- oder Cluster-Interconnect wurde zuerst als Early-Access-Feature in SD-WAN-Version 5.1.0 eingeführt und ist nun in Version 5.4.0 vollständig allgemein verfügbar (GA). Mit dieser Lösung können Kunden eine hierarchische und skalierbare Architektur mit vollständiger SD-WAN-Overlay-Konnektivität über Cloud-, regionale und Datacenter-Hubs aufbauen und dabei vollen DMPO-Schutz (Dynamic Multipath Optimization), End-to-End-Transparenz und Zuverlässigkeit bieten.

Zusätzlich zur vollen Unterstützung dieser Funktion wird die bisherige Begrenzung der Anzahl der Hops von zwei auf eine qualifizierte Anzahl von vier Hops erhöht.

IPv6-DHCPv6-Präfixdelegierung

Version 5.4.0 fügt Unterstützung für DHCPv6-Präfixdelegierung für Kunden hinzu, deren delegierender Router entweder Teil des Cloud-Hostings oder an einem Remote-Standort ist, oder in Szenarien, in denen der ISP des Kunden IP-Adressen zuweist. Die DHCPv6-Präfixdelegierung umfasst neue Adresstypen für IPv6 und unterstützt zwei ISP-Präfixdelegierungsserver, um eine primäre und eine Backup-Topologie zu ermöglichen.

Wichtig:

Um die Funktion „Präfixdelegierung“ nutzen zu können, müssen der Orchestrator, das Gateway und der Edge eine Softwareversion von 5.4.0 oder höher verwenden. Die Präfixdelegierung wird für die Verwendung auf einem Edge mit 5.2.0 oder früher nicht unterstützt. Wenn ein Edge mit Version 5.2.0 oder früher für die Präfixdelegierung konfiguriert ist, funktioniert die Funktion nicht wie erwartet.

Darüber hinaus kann ein Edge mit 5.2.0 oder früher, der mit Präfixdelegierung konfiguriert ist, nicht auf 5.4.0 aktualisiert werden. Wenn Sie also ein Upgrade von einem Edge der Version 5.2.0 oder früher auf 5.4.0 oder später durchführen, stellen Sie sicher, dass die Präfixdelegierung auf diesem Edge nicht verwendet wird.

Unterstützung von Mellanox-Bifurcated-Treibern für Microsoft Azure Virtual Edge

VMware SD-WAN bietet Unterstützung für Accelerated Networking (SR-IOV) für Microsoft Azure Virtual Edge und umfasst Unterstützung für Mellanox ConnectX-4- und ConnectX-5-Netzwerkkarten. Beim Aktivieren von SR-IOV auf einer Azure Virtual Edge-Schnittstelle wird die Erweiterung automatisch auf dem Edge aktiviert.

Accelerated Networking kann über das Azure-Portal, die Azure CLI oder die Azure PowerShell aktiviert oder deaktiviert werden.

Hinweis:

Diese Erweiterung umfasst keine Unterstützung für Mellanox ConnectX-3-Netzwerkkarten.

Run-To-Completion FastPath auf dem Edge, Phase 3

Run-to-Completion ist eine Software-Optimierung, die die Leistung von Edges und Gateways steigert, was zu einer Verbesserung der Gesamteffizienz der SD-WAN-Lösung führt.

Wichtige Hinweise

Änderung des LAN-seitigen NAT-Verhaltens

Wenn ab Version 4.5 ein LAN-seitiges NAT für n:1-Übersetzungen mit Port Address Translation (PAT) konfiguriert ist, kann der aus der entgegengesetzten Richtung initiierte Datenverkehr einen unerwarteten Zugriff auf feste Adressen ermöglichen, die auf der Außenmaske 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 bis 5.2.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.

Ab Version 5.4.0 kann ein Benutzer sechs separate Indikatoren in den Protokollen finden:

• lan_side_nat_rev_pat_drop_snat1

• lan_side_nat_rev_pat_drop_snat2

• lan_side_nat_rev_pat_drop_dnat1

• lan_side_nat_rev_pat_drop_dnat2

• lan_side_nat_rev_pat_drop_sdnat1

• lan_side_nat_rev_pat_drop_sdnat2

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.4.0 ist in folgende Sprachen lokalisiert: Tschechisch, Englisch, europäisches Portugiesisch, Französisch, Deutsch, Griechisch, Italienisch, Spanisch, Japanisch, Koreanisch, vereinfachtes Chinesisch und traditionelles Chinesisch.

Änderungen an der Orchestrator-API

Änderungen an der Orchestrator-API ab Version 5.3.0

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

Die folgenden Probleme betreffen Benutzer von API v1:

Ticket	Symptom/Beschreibung
Bekanntes Problem 118684	APIv1 enthält keine inkrementellen IDs in der Nutzlast zur Benutzerreferenz. Im Rahmen der laufenden Migration auf ein neues Datenbankmanagementsystem hat VMware SD-WAN einige inkrementelle IDs, wie z. B. edgeId, durch logische IDs ersetzt. Diese Änderung ist notwendig, weil die meisten Schnittstellen jetzt logische IDs verwenden. Dies ist ein rein kosmetisches Problem, und Sie können die aufrufende edgeId sicher auf die zurückgegebene edgeLogicalId abbilden.
Bekanntes Problem 123867	Die Link-Metriken und Serien-APIs geben einen Fehler zurück, wenn sie ohne eine Liste von Metriken aufgerufen werden. Dieses Problem wird in einer zukünftigen Version behoben werden. Um dieses Problem zu umgehen, können Sie Ihre API-Anforderung mit einer Liste der Metrikfelder übermitteln, die Sie zurückgeben möchten. Damit stellen Sie sicher, dass Sie die benötigten Daten erhalten, auch wenn die API eine Fehlermeldung ausgibt. Dieses Problem hat keinen Einfluss auf die Funktionalität der APIs, Sie können sie also weiterhin zum Abrufen von Daten verwenden.
Bekanntes Problem #127994	Die Swagger-Spezifikation meldet einen Schemafehler aufgrund eines additionalProperty: title im Antwortschema. Dies ist ein rein kosmetisches Problem und hat keinen Einfluss auf die Funktionalität der API. Dieses Problem wird in einer zukünftigen Version behoben und die API kann weiterhin zum Abrufen von Daten verwendet werden, auch wenn der Orchestrator diesen Schemafehler erhält.
Behobenes Problem 127995	Die Swagger-Spezifikation meldet einen Schemafehler aufgrund eines falschen Typs im Elementfeld des Antwortschemas. Dabei handelt es sich um ein kosmetisches Problem, das die Fähigkeit der API, Daten abzurufen, nicht beeinträchtigt. Der Fehler kann daher ignoriert werden. Dieses Problem wurde in Version 5.4.0 behoben.

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

Seit der Version 5.3.0 gibt es keine neuen API v2-APIs.

Im Folgenden finden Sie die Änderungen in der API v2 von 5.3.0 bis 5.4.0.

Ticket	Symptom/Beschreibung
Behobenes Problem 116610	Benutzer können keine neue Loopback-Schnittstelle über APIv2 hinzufügen. Die Schemastruktur für die Loopback-Schnittstelle in APIv2 erlaubte keine Schnittstellen, die nach der Schnittstellen-ID benannt wurden. Daher schlägt die Aktualisierung der Loopback-Schnittstelle fehl.
Behobenes Problem 129679	Kunden können das Geräteeinstellungsmodul des Edge nicht mit APIv2 PATCH Edge-Geräteeinstellungen aktualisieren, wenn das Geräteeinstellungsmodul des Edge über konfigurierte Teilschnittstellen verfügt. Wenn im Geräteeinstellungsmodul des Edge Teilschnittstellen konfiguriert sind, führt ein API-Aufruf der v2 PATCH Edge-Geräteeinstellungen-API dazu, dass die Anfrage ewig im Status „Angenommen (Accepted)“ verharrt und schließlich eine Zeitüberschreitung eintritt. Infolgedessen werden Kunden keine Änderungen im Geräteeinstellungsmodul des Edge auf dem Orchestrator sehen.

Entwicklerdokumentation

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

Dokumentierter Revisionsverlauf

16. November 2023. Zweite Auflage.

• Der neue Orchestrator-Rollup-Build R5401-20231115-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.4.0.

• Orchestrator-Build R5401-20231115-GA enthält Fixes für Probleme #117138, #123078, #123387, #125309, #125964, #126602, #127727, #127774, #127843, #127904, #128017, #128277, #128279, #128357, #128765, #129061#129494, #129584, #129756, #129765, #129894, #130153, #130877 und #131846, die jeweils in diesem Abschnitt dokumentiert sind.

• Der aktualisierte Edge-Build R5400-20231108-GA-125647 wurde zum Abschnitt „Behobene Probleme bei Edge/Gateway“ hinzugefügt. Dies ist ein Update des ursprünglichen Edge GA-Builds R5400-20231009-GA und ist der neue Standard-Edge-/Gateway-GA-Build für Version 5.4.0.

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

  Wichtig:

  • Der Edge-Build der vorherigen Version 5.4.0 wird zugunsten von R5400-20231108-GA-125647 eingestellt.

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

  • Kunden, die bereits erfolgreich den ursprünglichen 5.4.0 Edge-Build verwenden, müssen ihre Edges nicht auf R5400-20231108-GA-125647 aktualisieren.

19. Oktober 2023. Erste Auflage.

Behobene Probleme bei Edge und Gateway

• Behoben in Edge-Version R5400-20231108-GA-125647
• Behoben in der Edge- und Gateway-Version R5400-20231009-GA

Behoben in Edge-Version R5400-20231108-GA-125647

Edge-Build R5400-20231108-GA-125647 wurde am 14.11.2023 veröffentlicht und ist ein Update auf den Edge-GA-Build für Version 5.4.0.

Dieser aktualisierte Edge-Build behebt das folgende kritische Problem seit dem ursprünglichen GA-Build R5400-20231009-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 der Edge- und Gateway-Version R5400-20231009-GA

Edge- und Gateway-Build R5400-20231009-GA wurde am 23.10.2023 veröffentlicht und behebt die folgenden Probleme ab Edge- und Gateway-Build R5202-20230725-GA.

Hinweis:

Version 5.4.0 enthält alle Edge- und Gateway-Fixes, die in den Versionshinweisen zu 5.2.0 bis Version 5.2.0.2 (R5202-20230725-GA) dokumentiert sind.

• Behobenes Problem 69641: Für ein Kundenunternehmen, das eine oder mehrere Business Policies verwendet, die Ratengrenzwerte enthalten, kann der Kunde Paketverluste bei allen Flows beobachten, selbst bei solchen, die nicht mit den ratenbeschränkten Business Policy-Flows und auf anderen Segmenten und Peers zusammenhängen.

  Das Festlegen einer ratenbeschränkten Business Policy und das Senden von Datenverkehr mit höherem Bedarf (über dem Grenzwert) mit einer hohen Anzahl von Flows führen dazu, dass Pakete aus anderen Flows verworfen werden (auch von anderen Segmenten und Peers), da der Net Scheduler-Puffergrenzwert erreicht wird.

  In einem Unternehmen, dessen Edges keinen Fix für dieses Problem aufweisen, besteht die Problemumgehung darin, die Konfiguration des Ratengrenzwerts zu entfernen und stattdessen den der Regel entsprechenden Datenverkehr mit dem niedrigsten möglichen Wert (Niedrig (Low), Massen (Bulk)) neu zu klassifizieren.

• Behobenes Problem 74422: Im Falle von Hochverfügbarkeit wird der Edge möglicherweise offline geschaltet, wenn nur der Standby-Edge über einen verfügbaren WAN-Link und eine gültige IP-Adresse verfügt.

  Dieses Problem tritt auf, wenn DHCP für einen WAN-Link aktiviert ist, wobei nur für den Standby-Edge ein WAN-Link verfügbar ist. Wenn der Standby-WAN-Link eine IP-Adresse vom DHCP-Server empfängt, sendet er die Schnittstellendetails an den aktiven Edge. Der aktive Edge führt einen Aufruf durch, um die IP-Adresse als Route hinzuzufügen, jedoch fügt diese Funktion die Route nicht dem Linux-Kernel hinzu. Die Edge-Funktion fügt die Route nur der FIB (Forwarding Information Base) hinzu. Dies führt dazu, dass der Verwaltungsvorgang des Edge einen Fehler auslöst, da in der Routentabelle des Linux-Kernels keine Route vorhanden ist, damit das Paket beendet werden kann, und die Site ist effektiv offline.

• Behobenes Problem 79598: Bei einem Kundenunternehmen, das Zscaler mit redundanten Tunneln verwendet, wechselt der Datenverkehr bei einem Failover vom primären zum sekundären Tunnel schneller als erwartet zurück zum primären Tunnel.

  Das erwartete Verhalten besteht darin, dass der primäre Zscaler-Tunnel aktiviert wird und der Datenverkehr den sekundären Tunnel weitere 30 Minuten verwendet, bevor der Datenverkehr dann zurück zum primären Tunnel geleitet wird. Dadurch wird sichergestellt, dass der primäre Tunnel stabil ist und weniger wahrscheinlich ist, dass er wieder ausfällt und ein weiteres Datenverkehrs-Failover erzwungen wird. Bei diesem Problem wird der Datenverkehr in weniger als 30 Minuten zum primären Tunnel geleitet.

• Behobenes Problem 91164: Ein Hub Edge-Hub mit konfigurierter Hochverfügbarkeit leitet nach einem HA-Failover möglicherweise keinen Internet-Backhaul-Datenverkehr weiter.

  Der Standby-Edge legt die Zielroute für Internet-Backhaul-Flows nicht fest, wenn der Backhaul-Flow so konfiguriert ist, dass er über eine statische Route über eine geroutete Schnittstelle geleitet wird, bei der das WAN-Overlay deaktiviert ist.

• Behobenes Problem 92421: Wenn ein öffentliches und privates Overlay auf derselben Edge-Schnittstelle mit unterschiedlichen benutzerdefinierten VLAN-Tags konfiguriert sind, besteht die Möglichkeit, dass der geroutete Underlay-Datenverkehr verworfen wird.

  Wenn ein öffentliches und privates Overlay auf derselben Schnittstelle mit unterschiedlichen benutzerdefinierten VLAN-Tags konfiguriert sind, erlernt der Edge möglicherweise die ARP-Einträge mit den falschen VLAN-Tags, was dazu führt, dass der Datenverkehr verworfen wird.

• Behobenes Problem 96334: Auf einem VMware SASE Orchestrator, bei dem sich die IP-Adresse häufig ändert, verlieren die VMware SD-WAN Edges möglicherweise den Kontakt mit dem Orchestrator und werden als offline gemeldet.

  In diesem Szenario, in dem sich die Orchestrator-IP-Adresse häufig ändert, reagieren die Edges auf jede Änderung der Orchestrator-IP-Adresse, indem sie die Quelle des Verwaltungsdatenverkehrs von einer Loopback-Schnittstelle in die IP-Adresse des GE1-Ports ändern, selbst wenn der Orchestrator für die ausschließliche Verwendung der Loopback-Schnittstelle als Quelle konfiguriert ist. Dies führt dazu, dass die Edges den Kontakt mit dem Orchestrator verlieren, und obwohl sich dies nicht auf den Kundendatenverkehr auswirkt, verhindert dieses Problem, dass Konfigurationsaktualisierungen und Überwachung wie erwartet funktionieren.

• Behobenes Problem 99162: Wenn ein VMware SD-WAN Edge häufige Tunnel-Flaps aufweist, kann dies zu einem Anstieg des Arbeitsspeicherverbrauchs führen und möglicherweise dazu führen, dass der Edge defensiv neu gestartet wird, um den Arbeitsspeicher wiederherzustellen.

  Der betroffene Edge-Arbeitsspeicher ist das vc_edge_route-Objekt, das der Edge-Dienst nicht löscht, nachdem jede Instanz eines Tunnels abgebrochen und dann neu erstellt wird. Wie bei einem Arbeitsspeicherverlust löst der Edge einen Neustart des Diensts aus, um den Arbeitsspeicher zu leeren. Dies kann den Benutzerdatenverkehr für 10 bis 15 Sekunden unterbrechen.

• Behobenes Problem 104776: Für einen Kunden, der eine VMware SD-WAN Edge-Schnittstelle für PPPoE konfiguriert, enthält der Edge die 802.1P-PRI-Bits für ausgehenden Datenverkehr, wenn die WAN-Overlay-Einstellungen für diese Schnittstelle die 802.1P-Einstellung enthalten.

  Der Edge enthält nicht die konfigurierbare Option für netifd, um „EGRESS-Prioritätszuordnungen“ für PPPoE-Schnittstellen festzulegen. Dies führt dazu, dass der Edge diese Pakete nicht mit PRI markiert.

• Behobenes Problem 104786: Für ein Kundenunternehmen, das mithilfe einer Hub- oder Cluster-Interconnect-Topologie bereitgestellt wird, funktioniert die automatische Neuverteilung von Tunneln zwischen zwei Verbindungsclustern nicht.

  Die Neuverteilung von miteinander verbundenen Clustern erfolgt nicht bei einem steigenden Cluster Score oder einem BGP-Flap, was auftreten sollte und aufgrund des Ungleichgewichts bei der Tunnelnutzung zu Datenverkehrsproblemen führen kann.

• Behobenes Problem 105034: Die SNMP-Abfrage nach der CPU und dem Arbeitsspeicher eines VMware SD-WAN Edge ergibt immer ein Null als Antwortwert.

  Die SNMP-Abfrage nach CPU und Arbeitsspeicher im Rahmen der Edge-Integritätsstatistik ergibt immer einen Antwortwert von Null. Als Lösung wird CPU-Auslastung (CPU utilization) nun in Durchschnittliche CPU-Last (CPU load average) umbenannt und die Arbeitsspeicherauslastung wird ebenfalls als Antwort angezeigt.

• Behobenes Problem 106160: Wenn ein als Edge konfigurierter DNS-Server und ein Gateway des nächsten Hops für eine Edge-Schnittstelle definiert sind, für die Clients den DNS-Server abfragen, gibt es keine Antwort.

  Das DNS-Anforderungspaket wird vom Edge-DNS-Server erwartungsgemäß empfangen. Das Antwortpaket durchsucht jedoch eine Routentabelle basierend auf einer iptables-Verbindungsverfolgung, findet die Gateway-IP-Adresse des nächsten Hops und löst die MAC-Adresse auf. Das Ergebnis ist, dass das DNS-Antwortpaket die MAC-Adresse des Gateways und nicht den Absender verwendet.

• Behobenes Problem 106992: Für ein Kundenunternehmen, das mithilfe einer Hub- oder Cluster-Interconnect-Topologie bereitgestellt wird, stellt der Kunde möglicherweise fest, dass die Hub-Cluster keine Overlays zwischen ihnen bilden können.

  Hub-Cluster-Mitglieder mit aktivierter Interconnect-Verbindung können aufgrund veralteter Hub-Cluster-Zuordnung möglicherweise keine Overlays einrichten. Die einzige Möglichkeit, dieses Problem zu beheben, besteht darin, die Verbindung auf den Hub-Clustern zu deaktivieren und dann wieder zu aktivieren.

• Behobenes Problem 107550: Bei Kundenunternehmen, in denen Nicht-SD-WAN-Ziele über Gateways bereitgestellt werden, beobachtet ein Benutzer möglicherweise, dass einige IPsec-verschlüsselte Pakete im Pfad verworfen werden.

  Die aktuelle Implementierung verwendet einen TTL-Wert (Time-to-live) für den inneren IP-Header, der nicht mit der RFC-Anforderung übereinstimmt. Dies führt dazu, dass der TTL-Wert erstellt werden muss. Wenn der Absender des Pakets einen niedrigen TTL-Wert verwendet, besteht die Möglichkeit, dass dieses Paket sein Ziel nicht erreicht.

• Behobenes Problem 108111: Wenn ein Operator- oder Partnerbenutzer versucht, ein VMware SD-WAN Gateway mit dem Befehl debug.py --bgp_agg_dump zu debuggen, verfügt der Befehl nicht über eine ordnungsgemäße Hilfezeichenfolge.

  Die Hilfezeichenfolge erläutert, welche Argumente verwendet werden (Beispiel: [[v4 | v6 | all] ...]]), und bei diesem Problem fehlt diese Zeichenfolge für den Debug-Befehl.

• Behobenes Problem 109830: Kombinationen aus bestimmten PPTP-VPN-Clients und ‑Servern (Punkt-zu-Punkt-Tunnelprotokoll) sind möglicherweise nicht in der Lage, eine Verbindung nach einer Unterbrechung sofort wiederherzustellen, wenn 1:1-NAT mit dem PPTP-Server hinter dem Edge verwendet wird und sich der Client im Internet befindet.

  Es wurde bestätigt, dass dieses Problem bei Windows Server 2016 und Windows 10-Client auftritt, aber es kann auch bei anderen Versionen auftreten. Das Problem wird dadurch verursacht, dass der Server dieselbe PPTP-Call-ID für die neue Verbindung verwendet, während der Client eine neue Call-ID verwendet. Wenn die Server-Call-ID für die neue Verbindung wiederverwendet wird, wird sie von der Firewall nicht als solche erkannt.

  Ohne einen Fix für dieses Problem kann ein Benutzer die veraltete PPTP-Verbindung aus der NAT-Tabelle leeren, um die Konnektivität wiederherzustellen.

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

  Unter hohen CPU-Bedingungen können mehrere von einer Mutex-Überwachung ausgelöste Dienstausfälle auftreten, weil ein Thread mit niedrigerer Priorität die Debug-Ringsperre erhält. Die Lösung dieses Problems ist eine Verbesserung der Datenebene, durch die dieser Thread ohne Sperren und ohne Warten auskommt.

• Behobenes Problem 112509: Bei einem VMware SD-WAN Edge, der für die Verwendung einer VNF konfiguriert ist, kann es zu einem Ausfall und Neustart des Datenebene-Diensts kommen.

  Das Problem wird auf die SKB-Verarbeitung (Netzwerkpuffer) zurückgeführt. In einigen Fällen fehlt die SKB-Zuteilungsprüfung, und dies kann den Ausfall des Edge-Diensts auslösen.

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

• Behobenes Problem 114529: Wenn ein Benutzer bei LTE-Edge-Modellen (510-LTE, 610-LTE) die CELL-Konfigurationen im Orchestrator auch nach der Aktivierung von CELL1/CELL2 nicht festgelegt hat und weder ein Standardanbieter noch Standardkonfigurationen ausgewählt sind, löst der Edge einen Konfigurationsfehler aus.

  Wenn ein Benutzer die CELL1/CELL2-Schnittstelle eines LTE-Edge über die Seite Konfigurieren (Configure) > Edge > Gerät (Device) > Schnittstelle (Interface) aktiviert und keinen Betreiber bzw. kein Netzwerk aus der Liste auswählt, wird dieses Feld leer an den Edge übertragen. Nach dem Lesen des Felds gibt der Edge einen Fehler mit dem Hinweis aus, dass ///es nicht zu einem der verfügbaren SPNs gehört. Dieser Fehler kann im Abschnitt Ereignisse (Events) des Orchestrators angezeigt werden.

• Behobenes Problem 114659: Der Debugging-Befehl tcpdump.sh funktioniert nicht für ein VMware SD-WAN Gateway.

  Der AppArmor-Sicherheitsprozess des Gateways blockiert den Zugriff auf /dev/pts/*-Terminals. Dies führt dazu, dass der Prozess vctcpdump beendet wird und tcpdump.sh keine Informationen zu stdout erfasst.

  Auf einem Gateway ohne einen Fix für dieses Problem besteht die Problemumgehung darin, den Befehl tcpdump.sh-w auszuführen, um die Ausgabe in einer Datei zu speichern, da dieses Verfahren weiterhin funktioniert.

• Behobenes Problem 114854: Bei der Fehlersuche an einem VMware SD-WAN-Edge-Modell 610 mit aktiviertem DPDK zeigt eine Packet Capture-Ausführung über den Orchestrator oder mit tcpdump.sh oder vctcpdump, dass das VLAN-Tag für den Rückdatenverkehr fehlt.

  Das Fehlen von VLAN-Tags für Rückdatenverkehr wirkt sich auf die Fähigkeit eines Benutzers aus, ein Netzwerkproblem mit einer beliebigen Version eines Edge 610 erfolgreich zu beheben.

• Behobenes Problem 114938: Bei der Betrachtung von „Überwachen (Monitor) > Edges > Ziele (Destinations)“ für ein Kundenunternehmen kann ein Benutzer einen falschen Domänennamen für eine Destination feststellen.

  Diese ungültigen Hostnamen können den DNS-Cache des Edge vollständig füllen und zu Max DNS reached-Ereignissen führen, sodass die gültigen Hostnamen können danach nicht mehr hinzugefügt werden können. Das Problem wird dadurch verursacht, dass die Deep Packet Inspection (DPI)-Engine des Edge ungültige Hostnamen (z. B. IP-Adresse oder IP-Adresse:Port) in den DNS-Cache des Edge einfügt.

  

• Behobenes Problem 114988: Die ICMPv6-Meldung „Paket zu groß (Packet Too Big)“ wird weder von einem noch über ein VMware SD-WAN Gateway empfangen.

  Der Gateway-Datenpfad verbraucht alle ICMPv6-Meldungen vom Wert „Paket zu groß (Packet Too Big)“ lokal. Der Fix stellt sicher, dass das Gateway das entsprechende Ziel sendet.

• Behobenes Problem 115148: Wenn ein Kunde einen Cloud-Security-Service mit redundanten Tunneln (d. h. aktiven und Standby-Tunneln) einsetzt und die L7-Integritätsprüfung aktiviert ist, kann es vorkommen, dass der Standby-CSS-Tunnel aktiv bleibt, wenn der primäre CSS-Tunnel ausfällt und dann wieder aktiviert wird.

  Wenn der Standby-Tunnel aktiv ist, wenn die L7-Integritätsprüfung aktiviert ist, und diese Funktion dann deaktiviert wird, bevor der primäre CSS-Tunnel wieder aktiviert wird, kann der Standby-Tunnel auf unbestimmte Zeit inaktiv bleiben. Die Ursache des Problems liegt darin, dass das Gateway den Status von L7 für den primären Tunnel überprüft, obwohl die L7-Integritätsprüfung ausgeschaltet ist und der Status als „Inaktiv (down)“ angezeigt wird. Infolgedessen geht das Gateway davon aus, dass der primäre Tunnel deaktiviert ist und hält den Standby-Tunnel aktiv.

  Auf einem Edge ohne Fix für dieses Problem kann ein Benutzer das Problem für diesen Standort beheben, indem er Remote-Aktionen (Remote Actions) > Edge-Dienst neu starten (Edge Service Restart) ausführt.

• Behobenes Problem 115225: Wenn ein VMware SD-WAN Edge eine große Anzahl von Tunnel-Flaps aufweist, kann dies aufgrund eines Arbeitsspeicherverlusts zu einer erhöhten Arbeitsspeichernutzung führen.

  Beim Durchsuchen der Protokolle beobachtet ein Benutzer einen Anstieg des vc_edge_route-Arbeitsspeicherobjekts, bei dem zahlreiche Tunnel-Flaps als Folge von arbeitsspeicherbedingten Arbeitsspeicherverlusten im Zusammenhang mit der Edge-Route auftreten.

• Behobenes Problem 115262: Wenn ein Kundenunternehmen BGP für das Routing verwendet, wird eine BGP-Nachbarschaft mit einer sekundären IP-Adresse auf einem VMware SD-WAN Edge möglicherweise nicht angezeigt.

  Wenn ein Benutzer zuerst den BGP-Nachbarn konfiguriert und dann die entsprechende sekundäre IP-Adresse auf einer VLAN-Schnittstelle konfiguriert, wird die BGP-Sitzung nicht gestartet, da die BGP-Schnittstelle nicht mit dem Entfernen/Hinzufügen der sekundären IP-Adresse auf einer VLAN-Schnittstelle aktualisiert wird.

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

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

• Behobenes Problem 115869: Tunnel werden während des Upgrade-Vorgangs zu einem VMware SD-WAN Gateway neu hergestellt.

  In einer skalierten Umgebung, in der 1000 Tunnel und Peers mit einem Gateway verbunden sind, wechselt der Datenverkehr beim Upgrade eines Gateways standardmäßig zum sekundären Gateway, um eine kurze Ausfallzeit zu gewährleisten und den Datenverkehrsfluss schnell wieder aufzunehmen. Wenn das Upgrade-Skript auf dem zu aktualisierenden Gateway (von 4.5.1 auf 5.2.0 oder von 5.0.1 auf 5.2.0 oder 5.1.0 auf 5.2.0) ausgeführt wird, werden die Tunnel auf dem zu aktualisierenden Gateway wieder aktiviert und der Datenverkehr wechselt erneut vom sekundären Gateway zum Gateway, das aktualisiert wird. Wenn das Skript dann beendet wird, muss das Gateway erneut einen Neustart durchführen und der Datenverkehr wird erneut auf ein sekundäres Gateway umgeschaltet. Dies kann zu erheblichen Unterbrechungen des Kundendatenverkehrs für Datenverkehr vom Typ MultiPath über das Gateway führen.

  Auf einem Gateway ohne einen Fix für dieses Problem besteht die Problemumgehung darin, darin, den Neustart von vc_proc_mon restart aus dem Skript nach der Installation auf einen Zeitpunkt nach Abschluss des Upgrades zu verschieben.

• Behobenes Problem 115904: Wenn ein Benutzer ein Diagnosepaket für einen VMware SD-WAN Edge mithilfe des VMware SASE Orchestrator auslöst, kann es auf dem Edge zu einem Ausfall des Datenebene-Diensts, dem Generieren eines Core-Fehlers und einem Neustart zur Wiederherstellung kommen.

  Ein Benutzer kann ein Edge-Diagnosepaket auf der Seite SD-WAN > Diagnose (Diagnostics) > Diagnosepaket (Diagnostic Bundle) generieren. Wenn diese Aktion durchgeführt wird, kann eine Race-Bedingung zwischen dns_name_cache (Hinzufügen und/oder Löschen) und dem DNS-Namenscache auftreten, was dazu führt, dass der Edge-Dienst versucht, auf ein verwendetes oder gelöschtes Element zuzugreifen, was einen Dienstfehler mit einem SIGSEGV- oder SIGBUS-Grund auslöst.

• Behobenes Problem 116049: Der VPN-Status eines als Sicherung konfigurierten WAN-Links kann in den Status AUSFALL (DEAD) anstatt in den erwarteten STANDBY-Status wechseln.

  Die Auswirkungen auf den Kunden werden verringert, da die Funktion „Backup-WAN-Link“ (Link wird AKTIV, wenn andere Pfade ausfallen) davon unberührt bleibt. Der als AUSFALL (DEAD) angezeigte Benutzeroberfläche-Status des WAN-Links kann jedoch zur Verwirrung beim Kunden führen. Wenn der Backup-WAN-Link tatsächlich ausgefallen ist, kann der Kunde auf der Seite Edge > Überwachen (Monitor) nicht erkennen, wenn dieses Problem aufgetreten ist.

  Dieses Problem kann auftreten, wenn das Unternehmen mit einem Partner-Gateway verbunden ist und die konfigurierte BGP-Übergabe-IP-Adresse keine IP-Adresse einer Edge-Schnittstelle in diesem Segment ist. In diesem Szenario können die Backup-Link-Prüfmeldungen des Edge verworfen werden. Dies führt dazu, dass die als Backups für Edges konfigurierten WAN-Links als AUSFALL (DEAD) anstatt als STANDBY markiert werden können, obwohl der Link aktiv ist.

• Behobenes Problem 116059: Für eine Unternehmens-Site des Kunden, die mit einer Hochverfügbarkeitstopologie bereitgestellt wird, in der VNFs verwendet werden, schlägt die Konnektivität zu einer Standby-Edge-VNF über den im VNF-Verwaltungs-VLAN vorhandenen VNF-Manager fehl.

  Wenn ein VNF-Manager im VNF-Verwaltungs-VLAN bereitgestellt wird, kann ein falscher MAC-Adresseintrag in der Weiterleitungsdatenbank (FDB) der Standby-VNF-Verwaltungs-Bridge erlernt werden. Dieser Eintrag bleibt auch dann bestehen, wenn die Standby-Bridge-Ports auf einen deaktivierten Zustand festgelegt wurden. Dies führt dazu, dass die Standby-Edge-VNF-Konnektivität vom VNF-Manager aus fehlschlägt.

• Behobenes Problem 116199: Wenn in einem Kundenunternehmen, in dem Hub und Cluster Interconnect konfiguriert ist, der Tunnel zwischen einem Spoke-Edge und einem Hub oder Cluster ausfällt, können die Routen von den Remote-Spoke-Edges nicht widerrufen werden.

  Dieses Problem kann sich auf den Kundendatenverkehr auswirken, der diese veralteten Routen verwendet, und kann nur vorübergehend durch erneutes Initiieren der Routen behoben werden.

• Behobenes Problem 116257: Bei einem VMware SD-WAN Edge, der über ein Partner-Gateway verbunden ist, bei dem eine NAT-Übergabe für einen Remoteserver konfiguriert ist, kann der Datenverkehr von diesem Server an den Edge unterbrochen werden.

  Wenn der Datenverkehr anfänglich nicht vom Edge zum Remoteserver verschlüsselt und dann mit einem verschlüsselten Flag aktualisiert wird, wird der umgekehrte Datenverkehr auf dem Edge aufgrund eines Fehlers bei der Routensuche verworfen, sobald die Route aktualisiert wurde.

  Das Problem kann vorübergehend behoben werden, indem Flows auf dem betroffenen Edge geleert werden.

• Behobenes Problem 116368: Die Routing-Protokolle auf einem VMware SD-WAN-Gateway erreichen möglicherweise die Kapazität und sammeln keine zusätzlichen Einträge an.

  Dieses Problem wird dadurch verursacht, dass in der Routing-Software des Gateways die Konfiguration der Protokollrotation fehlt, deren Zweck darin besteht, die Routing-Protokolle zu rotieren, bevor die Kapazität erreicht wird, sodass neue Protokolleinträge hinzugefügt werden können. Ohne diese Konfiguration rotieren die Routing-Protokolle nicht und führen dazu, dass Operatoren und Partner potenziell kritische Protokolleinträge für ein Gateway fehlen.

• Behobenes Problem 116428: In einer Kundenbereitstellung, bei der mehrere Segmente konfiguriert sind und jedes nicht globale Segment einen benutzerdefinierten Namen hat, zeigt das Dropdown-Menü zur Auswahl einer Schnittstelle beim Ausführen von „Remote-Diagnose (Remote Diagnostics) > Ping-Test (Ping Test)“ nicht den benutzerdefinierten Namen für jedes Segment an.

  Anstelle des benutzerdefinierten Namens für jedes nicht globale Segment sieht der Benutzer einen generischen Namen mit einer Zahl: Segment 1, Segment 2 usw. Dies ist das Ergebnis der Hartkodierung des Segmentnamens durch den Edge für jedes nicht globale Segment.

  

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

  Beim Edge kann dieses Problem aufgrund einer Race-Bedingung während des Edge-Starts auftreten, die dazu führt, dass der Edge-Dienst aufgrund nicht initialisierter Daten fehlschlägt.

• Behobenes Problem 116894: 1:1-NAT funktioniert nicht ordnungsgemäß, wenn sich die externe IP-Adresse und die Quell-IP-Adresse im selben Subnetz befinden.

  Mit dieser 1:1-NAT-Konfiguration ändert der Edge den Quellport während der NAT-Übersetzung. Das Ergebnis ist ein Rückgang des Datenverkehrs, der mit dieser Regel für eingehenden Datenverkehr übereinstimmt.

• Behobenes Problem 116916: Edge-Pfade zu Peer-Edges und -Gateways können nach dem Hinzufügen oder Löschen einer IPv6-Kernel-Standardroute zu bzw. aus einem beliebigen Ziel über eine Edge-Schnittstelle, die vom Edge-Verwaltungsprozess verwendet wird, ausfallen.

  Die Edge-Pfade können beim Hinzufügen oder Löschen einer IPv6-Kernel-Standardroute ausfallen, die eine beliebige Schnittstelle umfasst, die vom Edge-Verwaltungsprozess verwendet wird, um Pfade mit anderen Knoten (also Edge oder Gateways) zu erstellen.

  Wenn dieses Problem ohne Fix auftritt, muss ein Benutzer die IPv6-Route entfernen und den Dienst neu starten.

• Behobenes Problem 116925: FTP-Datenverkehr kann von der DPI-Engine (Deep Packet Inspection) des VMware SD-WAN Edge fälschlicherweise als generisches TCP klassifiziert werden.

  Dies hat erhebliche Auswirkungen auf einen Kunden, der eine Business Policy oder eine Firewallregel verwendet, die für FTP-Datenverkehr vorgesehen ist, da die Regel nicht funktioniert.

  Der FTP-Datenverkehr wird als APP_TCP und nicht als APP_FTP_DATA klassifiziert. Dies liegt daran, dass die FTP-Steuerungs-Flows aus dem Kontext der DPI-Engine entfernt werden, sobald die Klassifizierung abgeschlossen ist. Damit der FTP-Datenverkehr jedoch ordnungsgemäß klassifiziert werden kann, sollte der Flow in der DPI-Engine beibehalten werden.

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

  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.

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

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

• Behobenes Problem 117320: Für einen Kunden mit aktivierter statusbehafteter Firewall und eingeschaltetem Syslog enthalten Syslog-Meldungen für Datenverkehr, der einer LAN-seitigen NAT-Regel entspricht, nicht die Quell-IP-Adresse.

  Es wird erwartet, dass eine vollständige Syslog-Meldung für beliebigen Datenverkehr die Quell-IP-Adresse enthält, insbesondere für Datenverkehr, der NAT verwendet.

• Behobenes Problem 117831: Die Standard-Firewallregeln des VMware SD-WAN Gateways verhindern, dass der Linux Azure-Agent nach dem Start des SD-WAN-Diensts mit der Azure-Fabric kommuniziert.

  Dies hat zwar keine Auswirkungen auf die SD-WAN-Funktion, bestimmte Metriken können aber im Azure-Portal für die VM des Gateways fehlen.

  Der Linux Azure-Agent benötigt ausgehende Kommunikation über die Ports 80/TCP und 32526/TCP mit WireServer (168.63.129.16). Nach dem Start des Gateway-Diensts wird Port 32526 blockiert.

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

  Dieses Problem kann auftreten, wenn der Edge ein ike-Paket mit einer im Vergleich zu ike_ds nicht übereinstimmenden Version empfängt. Das Problem wird verursacht, wenn der Edge-Dienst nicht übereinstimmende Versionspakete verarbeitet und eine Mutex-Sperre verwendet, um einen Cookiewert in ike_ds zu ändern. Tritt jedoch ein Versionskonflikt auf, löst der Edge eine SA-Löschung (Security Association, Sicherheitsverbindung) aus, die erneut versucht, Mutex auf demselben ike_ds zu verwenden. Dies führt zu einem Edge-Deadlock und einem Dienstausfall mit anschließendem Neustart.

• Behobenes Problem 117943: Auf einem VMware SD-WAN Edge mit WLAN-Fähigkeit kann die automatische Kanalauswahl für einige Länder dazu führen, dass der Edge Kanäle auswählt, die entweder zu einer schlechten WLAN-Leistung oder sogar zu einem vollständigen Ausfall des WLANs führen.

  In einigen Ländern, wie z. B. in Großbritannien, dauert es sehr lange, bis das WLAN hochgefahren wird, wenn es für das 5-GHz-Band konfiguriert ist (oder es kann sogar ganz ausfallen). Die automatische Kanalauswahl für das 5-GHz-Band kann in bestimmten Ländern dazu führen, dass ungeeignete Kanäle ausgewählt werden - entweder Kanäle mit sehr geringer Leistung oder Kanäle, die eine Radarerfassung erfordern (was den Start verzögern oder verhindern kann).

  Wenn Sie auf einem Edge ohne Fix für dieses Problem das 5GHz-Band in einem europäischen Land auswählen, konfigurieren Sie den Funkkanal explizit auf 36, 40, 44 oder 48 (anstatt ihn auf „auto“ zu belassen).

• Behobenes Problem 118097: Ein Operator- oder Partnerbenutzer stellt beim Debuggen eines VMware SD-WAN-Gateways möglicherweise fest, dass der Befehl debug.py --path kein Ergebnis zurückgibt.

  Das Problem wird durch einen nicht verarbeiteten Schlüssel bei Vorhandensein eines vorübergehenden Tunnels verursacht, wodurch der Befehl debug.py --path während der Verarbeitung vorübergehender Pfade durch das Gateway unterbrochen wird.

• Behobenes Problem 118348: Wenn ein Benutzer für ein Kundenunternehmen, das mit einer erweiterten Hochverfügbarkeitstopologie bereitgestellt wird, DHCP auf einer VMware SD-WAN Edge-Teilschnittstelle aktiviert, kommt es auf dem HA-Edge unter Umständen zu einem Ausfall des Datenebene-Diensts, wodurch ein Core-Fehler generiert und ein Neustart zur Wiederherstellung ausgelöst wird.

  Tritt dieses Problem auf dem aktiven Edge auf, wird ein HA-Failover ausgelöst und der Standby-Edge wird heraufgestuft. Tritt dieses Problem auf einem Standby-Edge auf, erfolgt zwar kein Failover, aber der Datenverkehr, der die WAN-Links des Standby-Edge verwendet, wird kurzzeitig unterbrochen.

• Behobenes Problem 118436: DNS-Datenverkehr kann unter Umständen nicht zu einem Underlay-DNS-Server weitergeleitet werden.

  Dieses Problem kann auftreten, wenn die geroutete Schnittstelle eines VMware SD-WAN Edge ohne Gateway und DHCPv6 mit IPv6-Schnittstelle als IP-Adresse des DNS-Servers, aber ohne IPv6-Standardroute auf einem Partner-Gateway konfiguriert ist. In dieser Konfiguration wird die DNS-Antwort des Underlays vom Edge verworfen.

• Behobenes Problem 118591: Für eine Unternehmens-Site des Kunden, die eine erweiterte Hochverfügbarkeitstopologie verwendet, kann es beim Standby-HA-Edge zu häufigen Schnittstellen-Flaps kommen.

  Wenn bei erweiterter HA-Bereitstellung eine hohe Anzahl von Flows gesendet oder eine hohe Anzahl von Routen installiert wird, wird der Zustand der Standby-Edge-Schnittstelle von AKTIV (UP) auf INAKTIV (DOWN) und wieder auf AKTIV (UP) geändert.

• Behobenes Problem 119010: Auf den VMware SD-WAN-Edge-Modellen 520 und 540 leitet der Edge möglicherweise keinen Datenverkehr von einem VLAN an den LAN-Ports 1 bis 4 an ein VLAN an den LAN-Ports 5 bis 8 weiter und umgekehrt.

  Die Edge-Modelle 520 und 540 verfügen über zwei LAN-Netzwerkkarten mit jeweils vier Ports für insgesamt 8 LAN-Ports. Wenn ein LAN für einen LAN-Port auf der ersten Portbank von Ports und ein anderes VLAN konfiguriert ist, das für einen LAN-Port auf der zweiten Portbank konfiguriert ist, verarbeitet der Edge diesen Datenverkehr nicht ordnungsgemäß und er wird verworfen.

• Behobenes Problem 119033: Während eines Startvorgangs kann es beim VMware SD-WAN-Gateway zu einem Ausfall des Datenebene-Diensts kommen, sodass ein Neustart zur Wiederherstellung erforderlich ist.

  Details zu NAT-Portzuteilungen werden absichtlich in einem gemeinsam genutzten Arbeitsspeichersegment außerhalb des Gateway-Dienstprozesses (verwaltet durch den NAD-Prozess) gespeichert. Dies wird durchgeführt, um sicherzustellen, dass der Gateway-Dienst seine NAT-Tabelle schnell neu initialisieren kann, wenn der Prozess neu gestartet wird. Es ist jedoch möglich, dass dieser persistente Zustand beschädigt wird, was dazu führt, dass der Gateway-Dienst sofort nach dem Neustart fehlschlägt.

  Auf einem Gateway ohne Fix für dieses Problem kann das Leeren der NAT-Tabelle oder ein Neustart des Betriebssystems verhindern, dass dieses Problem auftritt.

• Behobenes Problem 119466: Für eine Unternehmens-Site eines Kunden, die mit einer Hochverfügbarkeitstopologie bereitgestellt wird, kann der Datenverkehr, der einer n:1-NAT-Regel entspricht, nach einem HA-Failover fehlschlagen.

  Wenn dieses Problem auftritt, werden LAN-seitige NAT-Einträge nicht mit dem Standby-Edge synchronisiert. Da n:1-NAT auch PAT (Port Address Translation) umfasst, können LAN-seitige NAT-Einträge nicht basierend auf der Konfiguration erstellt werden und müssen synchronisiert werden, um eine Unterbrechung des Datenverkehrs bei einem HA-Failover zu verhindern.

• Behobenes Problem 119544: Wenn die ICMP-Echo-Antwort auf der Loopback-Schnittstelle eines VMware SD-WAN Edge deaktiviert ist, schlägt die L7-Integritätsprüfung mit dem Ergebnis fehl, dass der Edge ein Teardown eines CSS-Tunnels auslöst, für den die L7-Integritätsprüfung konfiguriert ist.

  Darüber hinaus wird die Kommunikation zwischen Edge und Orchestrator unterbrochen, wenn der Verwaltungsdatenverkehr direkt weitergeleitet wird.

  Wenn der Edge versucht, eine L7-Integritätsprüfungsanforderung (HTTP-SYN-Paket) zu senden, erreicht er die Loopback-Schnittstelle. Da die ICMP-Echo-Antwort (ICMP Echo Response) aber deaktiviert ist, werden die HTTP-Pakete verworfen. Wenn die L7-Integritätsprüfung kein ACK-Paket für das gesendete SYN-Paket erhält, schlägt die L7-Integritätsprüfung fehl, was zum Teardown des CSS-Tunnels führt.

  Wenn der Edge versucht, HTTPS-Pakete an den Orchestrator zu senden, erreicht er ebenfalls die Loopback-Schnittstelle. Da ICMP-Echo-Antwort (ICMP Echo Response) aber deaktiviert ist, werden die HTTPS-ACK-Pakete verworfen.

• Behobenes Problem 119811: Ein Kunde stellt möglicherweise fest, dass in seiner Ereignisliste pro Tag mehrere Edge-Ereignisse vom Typ MGD_WEBSOCKET_INIT und MGD_WEBSOCKET_CLOSE vorhanden sind.

  In der Ereignisliste des Orchestrators können mehrere Edge-Ereignisse vom Typ MGD_WEBSOCKET_INIT und MGD_WEBSOCKET_CLOSE ohne benutzerdefinierte Aktionen angezeigt werden.

  Diese Ereignismeldungen sind falsch und können bedenkenlos ignoriert werden, da sie den Schweregrad „Info“ aufweisen.

• Behobenes Problem 120940: Wenn mehrere Routen für dasselbe Präfix in BGP von unterschiedlichen Nachbarn in derselben internen VRF vorhanden sind (wie eine VRF, die für Nicht-SD-WAN-Ziele über Gateway-BGP-Sitzungen erstellt wurde), wird dieselbe Nachbar-IP für alle Routen aktualisiert.

  Das Problem kann beim SD-WAN Gateway mithilfe der Befehle debug.py --routes und debug.py --bgp_view outputs beobachtete werden und wird dadurch verursacht, dass der Routing-Prozess eines Gateways die Nachbar-IP (Quelle) nicht ordnungsgemäß aktualisiert.

• Behobenes Problem 121024: RAS-Datenverkehr (Remote Access Service) schlägt fehl, wenn eine mit dem Internetdatenverkehr übereinstimmende Business Policy auf einem VMware SD-WAN Edge konfiguriert ist.

  Wenn eine mit dem Internetdatenverkehr übereinstimmende Business Policy auf einem Edge konfiguriert ist und die Aktion in der direkten Steuerung des Datenverkehrs besteht, dann stimmt der Rückverkehr für den gesamten RAS-Datenverkehr, der diesen Edge erreicht, mit dieser Business Policy überein und wird auf dem Edge verworfen.

  Die einzige Problemumgehung besteht darin, eine spezifischere Business Policy zu konfigurieren, die auf RAS-Subnetze abgestimmt ist, und die Aktion so einzustellen, dass das Senden über mehrere Pfade (über das Gateway) erfolgt.

• Behobenes Problem 121338: Für eine Site, auf der ein WAN-Link als Hot-Standby konfiguriert ist, berücksichtigt der VMware SD-WAN Edge diesen Link als Teil der verfügbaren Bandbreite.

  Ein Hot-Standby-WAN-Link befindet sich entwurfsgemäß im Leerlauf und sollte nicht in der verfügbaren Bandbreite eines Edge enthalten sein. Da das Hot-Standby mit einbezogen wird, führt der Edge ungenaue Berechnungen für die insgesamt verfügbare Bandbreite durch, was zu Paketverlust führen kann.

• Behobenes Problem 121513: Bei einem Kundenunternehmen, das ein Partner-Gateway mit der aktivierten Option „Sichere BGP-Routen (Secure BGP Routes)“ verwendet, können Clientbenutzer Probleme mit der Qualität des Datenverkehrs feststellen.

  Datenverkehr kann für die Edges verworfen werden, wenn Datenverkehr mit einer BGP-Peer-IP-Adresse als Quelle hinter einem Partner-Gateway initiiert wird und die Option Sichere BGP-Routen (Secure BGP Routes) konfiguriert ist. Wenn Datenverkehr daher von einem BGP-Endpoint als Quelle initiiert wird, entsteht ein ungesicherter Flow im Gateway, da die Quellroute den Typ BGP-Peer aufweist, für den keine sichere Einstellungsverarbeitung durchgeführt wird. Wenn bei der Quellroutensuche auf den Edges jedoch eine sichere Route zurückgegeben wird, stimmt die sichere Einstellung des eingehenden Datenverkehrs und der Routensuche nicht überein. Dies führt zu einem Fehler bei der Quellroutensuche auf den Edges.

• Behobenes Problem 121606: Mit einem Partner-Gateway verbundene Kunden stellen möglicherweise fest, dass IPsec-VPN-Tunnel auf dem Partner-Gateway inaktiv sind.

  Der IPsec-Prozess des Gateways unterstützt maximal 64 IP-Adressen auf einer Schnittstelle. Bei diesem Problem auf einem Partner-Gateway werden die Übergabe-IP-Adressen bedingungslos zur IPsec-Prozessschnittstelle des Gateways hinzugefügt. Wenn die Anzahl der Übergabe-IP-Adressen den Grenzwert von 64 überschreitet, werden die älteren IP-Adressen im IPsec-Prozess überschrieben, was dazu führt, dass die Tunnel, die diese IPs verwenden, nicht mehr funktionieren.

  Wenn dieses Problem auf einem Gateway ohne entsprechenden Fix auftritt, steht unter der Voraussetzung, dass alle Übergabe-IP-Adressen des Partner-Gateways wie erwartet konfiguriert wurden, keine Lösung für dieses Problem zur Verfügung. Ansonsten kann das Entfernen unnötiger PG-Übergabe-IPs hilfreich sein, wenn dadurch die IPs im IPSec-Prozess des Gateways auf unter 64 reduziert werden. Nach dieser Konfigurationsänderung ist ein Neustart des Gateway-Diensts erforderlich.

  Darüber hinaus besteht eine Alternative darin, eine bestimmte Anzahl an IPsec-Tunneln auf ein zweites Partner-Gateway zu verschieben, die ausreicht, um die Gesamtzahl der Übergaben auf dem betroffenen PG auf unter 64 zu senken.

• Behobenes Problem 121815: Wenn bei einem mit einer Hochverfügbarkeitstopologie bereitgestellten Kundenunternehmen, das VNFs verwendet, auf einem Standby-Edge eine aktive LAN-Schnittstelle und eine ausgefallene VNF vorhanden sind und der aktive Edge über eine inaktive LAN-Schnittstelle und ein aktives VNF verfügt, findet kein HA-Failover statt, selbst wenn der Standby-Edge einen aktiven LAN-Port aufweist.

  Dieses Problem rührt daher, dass der Edge den VNF-Status als Teil der LAN-Anzahl in das HA-Taktsignal aufnimmt. Eine aktive VNF wird als zusätzliches LAN gezählt, was zu den aufgelisteten Symptomen führt.

  Das Problem wird behoben, indem der VNF-Status von der LAN-Anzahl entkoppelt wird, sodass HA-Failover-Entscheidungen ordnungsgemäß getroffen werden können. Mit dieser Änderung räumt der Edge einer VNF eine höhere Priorität ein, wenn grundlegende WAN- und LAN-Konnektivität vorhanden ist. Anders ausgedrückt: Wenn der aktive Edge über eine inaktive VNF und der Standby-Edge über eine aktive VNF verfügt, wird der Standby-Edge zum aktiven Edge heraufgestuft, wenn er über mindestens 1 WAN und 1 LAN verfügt, und zwar unabhängig von der LAN-/WAN-Anzahl auf dem aktiven Edge.

• Behobenes 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 Datenverkehr verworfen wird.

  Für einen Edge ohne einen Fix für dieses Problem kann ein Kunde die Quelle von einem Edge-VLAN in „Beliebig“ ändern.

• Behobenes Problem 122029: Ein mit GRE-Automatisierung bereitgestellter Cloud-Security-Service (in der Regel Zscaler), in dem der VMware SD-WAN Edge eine 5.2.x-Version verwendet, funktioniert nicht.

  Dieses Problem wird dadurch verursacht, dass sowohl die lokale IP-Adresse als auch die öffentlichen IP-Adressen nicht gesendet werden. Diese Informationen werden benötigt, damit der Orchestrator einen Konfigurationsstatus des Tunnels an den Edge senden kann. Der Tunnel muss sich im Status „Ausstehend“ befinden, damit der Orchestrator die automatisierte GRE-Konfiguration senden kann.

  Dieses Problem ist auf 5.2.x-Edges beschränkt. Ein Benutzer kann dieses Problem nur umgehen, indem er den Edge auf 5.1.x oder eine frühere Version herabstuft, den Tunnel hochfährt und anschließend ein Upgrade auf Version 5.2+ durchführt.

• Behobenes Problem 122528: Bei einem Kundenunternehmen, das statische WAN-Routen mit konfigurierten ICMP-Tests verwendet, kann es vorkommen, dass die ICMP-Tests an mehreren VMware SD-WAN Edges gleichzeitig nicht mehr funktionieren und der gesamte Datenverkehr über diese Routen unterbrochen wird.

  Jeder Edge verfügt über einen ICMP-Testsequenzzähler mit maximal 65535 Iterationen. Wenn dieser Zähler nach 65535 Iterationen überläuft, schlagen die Tests fehl.

  Auf einem Edge ohne eine Lösung für dieses Problem besteht die Abhilfe darin, den ICMP-Test zu entfernen, den Edge-Dienst neu zu starten und dann den Test wiederherzustellen.

• Behobenes Problem 123144: Auf der Seite „Überwachen (Monitor) > Edge > Ziele (Destinations)“ der Orchestrator-Benutzeroberfläche werden ungültige Zieldomänennamen angezeigt.

  Der Edge sendet ungültige Zielnamen wie IP:Port, die auf der Orchestrator-Benutzeroberfläche aufgrund eines Validierungsfehlers in den DNS-Hostnamen angezeigt werden.

• Behobenes Problem 123237: Auf einem VMware SD-WAN Edge mit Version 5.2.x, auf dem die Schnittstellen ausschließlich mit IPv6 konfiguriert sind, wird die Seite „Diagnose (Diagnostics) > Remote-Diagnose (Remote Diagnostics)“ nicht geladen.

  Wenn reine IPv6-Edge-Schnittstellen mit deaktivierten IPv4-Einstellungen konfiguriert sind, wird in einem Schlüsselskript eine Ausnahme ausgelöst und die Seite Diagnose (Diagnostics) > Remote-Diagnose (Remote Diagnostics) wird nicht geladen.

  Die Problemumgehung besteht darin, IPv4-Einstellungen mit einer Dummy-Konfiguration zu aktivieren.

• Behobenes Problem 123956: Ein Benutzer kann mit einer 5.2.x-Version nicht auf die lokale Benutzeroberfläche auf einem VMware SD-WAN Edge zugreifen.

  Die Browserseite wird nicht mit einem 404-Fehler geladen. Das Problem ist auf Ausnahmen zurückzuführen, die sowohl in Skripts für die Remote-Diagnose als auch in Skripts der lokalen Benutzeroberfläche ausgelöst werden.

• Behobenes Problem 124106: Wenn eine LAN-seitige NAT für n:1-Übersetzungen mithilfe von Port Address Translation (PAT) konfiguriert ist, erlaubt der aus der entgegengesetzten Richtung initiierte Datenverkehr unerwarteten Zugriff auf feste Adressen, die auf der Außenmaske und der ursprünglichen IP-Adresse basieren.

  LAN-seitige NAT-Regeln erlauben Verbindungen in beide Richtungen für n:1-Regeln, ohne dass es eine klare Möglichkeit gibt, den Datenverkehr in der Richtung 1:n zu verhindern. 1:n-Übersetzungen werden jetzt blockiert und Benutzer müssen explizite 1:1-NAT-Regeln erstellen, um den Datenverkehr zu aktivieren.

  Dieses Problem wird im Abschnitt Wichtige Hinweise ausführlich behandelt: Änderung des LAN-seitigen NAT-Verhaltens.

• Behobenes Problem 124162: Wenn ein Benutzer ein Packet Capture auf einer VMware SD-WAN Edge-Schnittstelle durchführt, sieht er möglicherweise ein Paket, das beschädigt zu sein scheint.

  Tatsächlich ist das Paket nicht beschädigt, es wird nur in der PCAP-Datei als beschädigt angezeigt. Dieses Problem ist auf einen Fehler in der Art und Weise zurückzuführen, wie der Edge Pakete in die Packet Capture-Schnittstelle schreibt. VLAN-getaggte Pakete können falsch geschrieben und in der PCAP-Datei als beschädigte Pakete (ungültiger Ethertyp (invalid ether-type)) angezeigt werden.

• Behobenes Problem 124263: Ein Kunde beobachtet möglicherweise eine hohe CPU-Nutzung auf einem VMware SD-WAN Edge bei der Verarbeitung von IPv6 Neighbor Discovery- (ND) und L2-Kapselungspaketen.

  Die Fehlerbehebung auf dem Edge deutet darauf hin, dass api - vc_ip6_host_addr_to_network_addr viel CPU verbraucht.

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

  Wenn eine Business Policy mit Internet-Backhaul konfiguriert ist und LAN-seitig ein Paket mit einer Größe von 3000 Byte oder mehr gesendet wird, meldet der Edge-Prozess große Paketgrößen an, was einen Dienstausfall auslöst.

• Behobenes Problem 125035: Wenn ein Kunde eine Fortinet 6.4.x-VNF bereitstellt, kann auf die Verwaltungs-IP-Adresse des Edge nicht zugegriffen werden.

  In Fortinet 6.4.x wurden Änderungen vorgenommen, die dazu führen, dass FortiLink und der transparente Modus nicht zusammenarbeiten. SD-WAN verwendet FortiLink nicht. Daher besteht die Lösung für dieses Problem darin, FortiLink zu deaktivieren, bevor der transparente Modus bei der Bereitstellung der VNF festgelegt wird.

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

• Behobenes Problem 125487: Der Datenverkehrsfluss von Edge zu Edge kann durch ein Problem mit der ARP-Auflösung unterbrochen werden.

  Wenn dieses Problem auftritt, leitet der Edge die ARP-Anforderung an die IP-Adresse des nächsten Hops weiter, indem er die IP-Adresse der primären Schnittstelle anstelle der IP-Adresse der Teilschnittstelle verwendet. Das Problem wird während der Flow-Erstellung ausgelöst, wenn eine nicht verbundene Route verwendet wird, um das Ziel zu erreichen. Wenn die Teilschnittstelle des Edge dann für diese Verbindung verwendet wird, füllt der Edge die Quell-IP-Adresse für die Teilschnittstelle nicht ordnungsgemäß aus.

• Behobenes Problem 126304: 1:1-NAT-Regeln, deren Quellübersetzung sich mit n:1-NAT-Regeln oder anderen 1:1-NAT-Regeln überschneidet, können zu Portkollisionen oder fehlgeschlagenen Übersetzungen führen.

  Zur Korrektur dieses Verhaltens wird im Fall einer Überschneidung der Quellübersetzung einer 1:1-NAT-Regel mit einer anderen Regel die Portadressübersetzung (Port Address Translation, PAT) auch für die 1:1-NAT-Regel aktiviert.

• Behobenes Problem 126458: Bei einem mit einer Hochverfügbarkeitstopologie bereitgestellten Kundenstandort, an dem für die HA-Edges die Modelle 520/540 verwendet werden, kann der Kunde mehrere HA-Failover beobachten, die aus einem Aktiv/Aktiv-Zustand resultieren.

  Die Bedingung wird auf mit HA konfigurierten 520/540-Edges ausgelöst, wenn die Anzahl der gleichzeitigen Flows 300.000 überschreitet.

  Auf HA-Edges, die die Modelle 520/540 verwenden und für die es keinen Fix für dieses Problem gibt, besteht die Problemumgehung darin, die HA-Failover-Zeit auf der Seite Konfigurieren (Configure) > Edge > Gerät (Device) von 700 ms auf 7000 ms zu erhöhen, da dies die Wechsel des Aktiv/Aktiv-Zustands reduziert.

• Behobenes Problem 127127: Ein VMware SD-WAN Edge erlernt keine Routen von Hub-Edges, wenn die VMware SD-WAN Gateways auf Version 5.1.x oder höher aktualisiert werden.

  Wenn ein Edge mit Zweigstelle-zu-Zweigstelle über Hubs und lediglich demselben Edge in der Liste konfiguriert ist und auf dem Gateway Version 5.1.x und höher ausgeführt wird, werden dem Edge die Routen nicht vom Gateway annonciert.

  Die einzige Problemumgehung besteht darin, den Edge aus der Konfiguration „Zweigstelle-zu-Zweigstelle über Hubs“ zu entfernen.

• Behobenes Problem 127403: Wenn Sie auf der Seite „Testen und Fehlerbehebung (Test & Troubleshoot) > Remote-Diagnose (Remote Diagnostics)“ der Orchestrator-Benutzeroberfläche „Fehlerbehebung bei OSPF – Umverteilte OSPF-Routen auflisten (Troubleshoot OSPF - List OSPF Redistributed Routes)“ oder „Fehlerbehebung bei BGP – Umverteilte BGP-Routen auflisten (Troubleshoot BGP - List BGP Redistributed Routes)“ ausführen, gibt der Test einen Fehler ohne Daten zurück.

  Nach der Ausführung einer der beiden Diagnosen bemerkt der Benutzer folgenden Fehler: „Fehler beim Lesen der Daten für den Test (Error reading data for test)“.

• Behobenes Problem 128377: In einem Kundenunternehmen, in dem BGP zum Routen verwendet wird, kann der Kunde unter Umständen beobachten, dass der Benutzerdatenverkehr aufgrund eines BGP-Fehlers unterbrochen wird.

  Der BGP-Prozess kann während der Bereinigung aufgrund eines ungültigen Arbeitsspeicherzugriffs von self_mac_hash abstürzen.

  Im Rahmen der Bereinigung von bgp_master ist self_mac_hash bereits bereinigt. Während der Verarbeitung der Meldung nach der bereits stattgefundenen Bereinigung greift BGP jedoch auf den gelöschten Hash zu, was den Fehler verursacht.

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

  Wenn ein gültiges Verwaltungspaket unerwartet bei einem IPSec-Tunnel des Nicht-SD-WAN-Ziels oder einer GENEVE-Schnittstelle eintrifft, kann auf dem Gateway bei der Verarbeitung dieses Pakets ein Fehler auftreten, der zum Fehlschlagen des Gateway-Dienstprozesses führt.

Behobene Probleme bei Orchestrator

• Behoben in Orchestrator-Version R5401-20231115-GA
• Behoben in Orchestrator-Version R5400-20231020-GA

Behoben in Orchestrator-Version R5401-20231115-GA

Orchestrator-Build R5401-20231115-GA wurde am 15.11.2023 veröffentlicht und ist der erste Orchestrator-Rollup für Version 5.4.0.

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

• Behobenes Problem 117138: Wenn Sie Zscaler-Automatisierung zum Erstellen eines Zscaler-Cloud-Security-Service (CSS) verwenden, werden Edge-zu-Zscaler-CSS-IPsec-Tunnel möglicherweise nicht erstellt.

  Der Orchestrator stellt sicher, dass nur eine Aktion pro Edge in die Warteschlange gestellt wird. Wenn jedoch eine Aktion im Status „BENACHRICHTET (NOTIFIED)“ verbleibt, werden alle nachfolgenden Aktionen nicht ausgeführt und die IPsec-Tunnel werden nicht aufgebaut.

  Bei einem Orchestrator ohne Fix für dieses Problem muss ein Operator-Benutzer die veraltete Edge-Aktion manuell aus der Orchestrator-Datenbank löschen.

• Behobenes Problem 123078: Wenn Sie die VMware SASE Orchestrator-Benutzeroberfläche verwenden und zur Seite „Überwachen (Monitor) > Edge > Übersicht (Overview)“ navigieren, sind die Spalten nicht ordnungsgemäß ausgerichtet und schwer zu lesen.

  Die Benutzeroberfläche enthält keine Informationen für die Spalte Gerät-Seriennummer (Device Serial Number), d. h. es gibt 11 Spalten, aber nur 10 Überschriften, was das Problem der Lesbarkeit verursacht.

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

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

  Dies führt zu Verwirrung bei einem Kundenbenutzer, der diese Einstellungen konfiguriert, ohne zu wissen, dass er dies nicht tun sollte, weil die IPv6-Version von OSPF nicht in Kraft ist.

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

  Der Kunde verwendet die alte Benutzeroberfläche, um die Aufgabe abzuschließen.

• 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 127727: Beim Erstellen eines neuen Cloud-Security-Service (CSS) kann ein Benutzer die Option „Inländische Voreinstellung (Domestic Preference)“ nicht konfigurieren.

  Wenn ein Benutzer 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 127774: Unter „Konfigurieren (Configure) > Edge > Gerät (Device) > Konnektivität (Connectivity) > Loopback-Schnittstellen (Loopback Interfaces)“ ist der Versuch eines Benutzers, eine Loopback-Schnittstelle zu konfigurieren, möglicherweise nicht erfolgreich.

  Wenn das Problem auftritt, konfiguriert ein Benutzer eine Loopback-Schnittstelle für einen Edge und speichert die Änderungen und die Benutzeroberfläche gibt keinen Fehler aus, aber die Konfiguration wird nicht angewendet und wird nicht auf der Seite der Benutzeroberfläche angezeigt.

• Behobenes Problem 127843: Die Benutzeroberfläche wird bei der Lokalisierung in die italienische Sprache nicht korrekt angezeigt.

  Dies hat Auswirkungen auf den Benutzer, da sich einige Navigationsregisterkarten überschneiden.

• Behobenes Problem 128017: Ein Kunde stellt möglicherweise fest, dass beim Navigieren zur Seite „Konfigurieren (Configure) > Edge > Gerät (Device)“ die Seite nicht geladen wird.

  Wenn dieses Problem auftritt, werden die Edge-Konfigurationsreferenzen fälschlicherweise vom Orchestrator aus seiner Datenbank gelöscht. Sobald diese Referenzen entfernt wurden, können sie nicht wiederhergestellt werden.

  Bei einem Orchestrator ohne Fix für dieses Problem besteht die einzige Problemumgehung darin, den Edge zu zwingen, alle Konfigurationen aus dem mit diesem Edge verbundenen Profil zu verwenden. Wenn der Edge über viele benutzerdefinierte Edge-Überschreibungskonfigurationen verfügt, würde dies bedeuten, dass Sie ein spezielles Profil nur für diesen Edge erstellen müssen.

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

  Ein Benutzer beobachtet, dass der Bildschirm „Abgelaufenes Kennwort (Expired Password)“ immer wieder aktualisiert wird, und zwar auf unbestimmte Zeit. Die einzige Möglichkeit, dies zu umgehen, besteht darin, dass ein Operator oder Partner mit der richtigen Rolle das Kennwort für den Benutzer zurücksetzt.

• 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-Adresse für nächsten Hop (Next Hop IP) 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 „Immer (Always)“ und „Bedingt (Conditional)“. „Keine (None)“ ist keine gültige Option und sollte nicht auf der Benutzeroberfläche angezeigt werden.

• 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 mit einem ungültigen Status auf einer aktuellen Seite navigiert, sind die Steuerelemente nach der Rückkehr ungültig und der Benutzer füllt die richtigen Informationen ein.

  Auf einem Orchestrator ohne Fix für dieses Problem muss ein Benutzer auf der Seite der Tabelle bleiben, auf der das Steuerelement ungültig ist. Alternativ kann der Benutzer diese Zeile entfernen und erneut hinzufügen.

• 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: Wenn ein Benutzer auf der Seite „Kunde (Customer) > Globale Einstellungen (Global Settings) > Kundenkonfiguration (Customer Configuration) > Dienstkonfiguration (Service Configuration) > SD-WAN“ die Dienstkonfiguration bearbeitet, muss der Benutzer jedes Mal den Domänennamen hinzufügen.

  Der Benutzer muss dies auch dann tun, wenn für den Kunden keine SSO-Authentifizierung (Single Sign-On) oder ENI (Edge Network Intelligence) konfiguriert ist. Ein Domänenname ist nicht zwingend erforderlich, wenn ein Kunde weder ENI noch SSO verwendet.

• Behobenes Problem 129584: Wenn ein Benutzer auf der Seite „Konfigurieren (Configure) > Edges > Business Policy“ eine vorhandene Business Policy-Regel bearbeitet, aktualisiert die Orchestrator-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. für 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 129756: Wenn ein Operator das Aktualisierungsschema für einen cloudbasierten VMware SASE Orchestrator ausführt, kann der Orchestrator möglicherweise keine Verbindung zur Remotedatenbank herstellen.

  Dieses Problem wirkt sich nicht auf VM-basierte Orchestrator-Instanzen aus.

• Behobenes Problem 129765: Beim Bearbeiten einer gerouteten Schnittstelle für einen VMware SD-WAN Edge wird auf der Orchestrator-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 des Felds „Optionen (options)“ unter „dhcpServer“ als Null anstelle eines leeren Arrays gesendet.

• Behobenes Problem 129894: Im Operator-Portal der Orchestrator-Benutzeroberfläche kann ein Benutzer beim Betrachten des Bildschirms „Gateway-Verwaltung (Gateway Management) > Gateways > Übersicht (Overview) > Kundennutzung (Customer Usage)“ feststellen, dass einige Edge-Client-Tunneldetails fehlen.

  Dieses Problem kann auftreten, wenn der Name des Edge, der Name des Gateway-Pools und der Gateway-Typ identisch sind.

• Behobenes Problem 130153: Für einen Unternehmensbenutzer mit einer Support-Rolle ist die Option „Dienst neu starten (Restart Service)“ im Menü „Überwachen (Monitor) > Edges > Edge auswählen (Select Edge) > Verknüpfungen (Shortcuts) > Remote-Aktionen (Remote Actions)“ nicht verfügbar.

  Dies hindert Benutzer mit Support-Rolle daran, einen Neustart des Edge-Diensts über das Menü „Verknüpfungen (Shortcuts)“ auf der Seite Überwachen (Monitor) > Edges durchzuführen.

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

  Auf der Benutzeroberfläche unter Konfigurieren (Configure) > Edge > Gerät (Device) > Routing und NAT (Routing & NAT) > Statische Routeneinstellungen (Static Route Settings) werden die Schnittstelleneinstellungen für Lokale Routen (Local Routes) auf N/A (Nicht verfügbar) geändert und können nicht bearbeitet werden. Die local_routes-Protokolle für diesen Edge zeigen "reachable": "False" für die betroffenen lokalen Routen.

  Dieses Problem kann auftreten, wenn sich die IP-Adresse für nächsten Hop (Next Hop IP) einer statischen Route im selben Subnetz des VLAN-Netzwerks befindet. In diesem Szenario entfernt die Orchestrator-Benutzeroberfläche die Schnittstelle der statischen Route, was dazu führt, dass für diese lokalen Routen die Erreichbarkeit als „false“ angezeigt wird.

• Behobenes Problem 131846: Wenn ein Benutzer auf der Seite „Globale Einstellungen (Global Settings) > Kundenkonfiguration (Customer Configuration) > Partnerübergabe (Partner Hand off) > Übergabeschnittstelle (Hand Off Interface)“ auf die Schaltfläche „Hinzufügen (Add)“ klickt, um eine statische Route hinzuzufügen, gibt die Orchestrator-Benutzeroberfläche eine Fehlermeldung aus.

  Wenn der Benutzer im Abschnitt „Statische Routen (Static Routes)“ auf die Schaltfläche Hinzufügen (Add) klickt, wird der Tabelle eine neue leere Zeile hinzugefügt, aber es wird 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 in your configuration)“ angezeigt. Dies wird durch eine fehlende Validierung für die Konfiguration der leeren statischen Route im Abschnitt „Partnerübergabe (Partner Handoff)“ des Bildschirms „Globale Einstellungen (Global Settings)“ verursacht, und dieses Problem betrifft nur Zeilen, in denen keine Informationen konfiguriert sind.

  Für dieses Problem gibt es zwei Problemumgehungen:

  • Füllen Sie alle Pflichtfelder aus. Dadurch wird die Fehlermeldung („Änderungen können nicht gespeichert werden...“) automatisch behoben.

  • Entfernen Sie alle neu hinzugefügten leeren Zeilen aus dem Abschnitt. Nach dem Entfernen dieser leeren Zeilen wird die Fehlermeldung automatisch behoben.

Behoben in Orchestrator-Version R5400-20231020-GA

Orchestrator-Version R5400-20231020-GA wurde am 23.10.2023 veröffentlicht und behebt die folgenden Probleme seit Orchestrator-Version R5302-20231011-GA.

Hinweis:

Version 5.4.0 enthält alle Orchestrator-Fixes, die in den Versionshinweisen zu 5.2.0 bis Version 5.2.0.3 (R5203-20230809-GA) aufgeführt sind, und alle Orchestrator-Fixes in den Versionshinweisen zu 5.3.0 bis Version 5.3.0.2 (R5302-20231011-GA).

• Behobenes Problem 48230: Auf der Seite „Überwachen (Monitor) > Edges“ ist die Suche nach Edges mithilfe von „Modell“ ///nicht ganz genau.

  Wenn ein Benutzer nach Modellnummer filtert, gibt der Orchestrator zusätzliche Edges zurück.

• Behobenes Problem 48609: Auf der Seite „Überwachen (Monitor) > Routing“ kann ein Benutzer den Segmentnamen in einer Multicast-Routentabelle nicht sortieren.

  In Version 5.4.0 wurde die API um die Aufnahme des Segmentnamens als Sortierparameter ergänzt, was bei der Sortierung des Segmentnamens hilfreich ist.

• Behobenes Problem 78581: Ein Benutzer kann ein VLAN annoncieren, wenn verbundene Routen auf der Orchestrator-Benutzeroberfläche deaktiviert sind.

  Diese Aktion sollte vom Orchestrator durch Auslösen eines Fehlers abgelehnt werden. In der korrigierten Version überwacht die Orchestrator-Benutzeroberfläche verbundene Routen und deaktiviert das Annoncieren-Flag basierend auf den verbundenen Routen und umgekehrt.

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

  Auf einem Orchestrator ohne einen Fix für dieses Problem sollte der Kunde alle VLAN-Geräteeinstellungen überprüfen und sicherstellen, dass sie gültig sind, da der Orchestrator keine Überprüfung vorsieht.

• Behobenes Problem 91869: Wenn ein Operator-Benutzer zu „Partner verwalten (Manage Partners)“ navigiert und auf die Schaltfläche „Operator-Profil hinzufügen (Add Operator Profile)“ klickt, wird die Beschreibung des Operator-Profils nach Erreichen einer bestimmten Länge abgeschnitten.

  Der Orchestrator sollte die Beschreibung des Operator-Profils unabhängig von der Textlänge nicht abschneiden.

• Behobenes Problem 92766: Auf der Seite „Überwachen (Monitor) > Routing“ sind die Paginierungsinformationen falsch.

  Wenn ein Benutzer auf die Schaltfläche Weiter (Next) klickt, wird die Benutzeroberflächenseite auch nach Erreichen der letzten Seite nicht angehalten, da die Filterlogik nicht ordnungsgemäß angewendet wird. Dies führt dazu, dass die angezeigte Seitenzahl nicht korrekt ist.

• Behobenes Problem 102121: Wenn die Secure Access-Konfiguration eines Edge mehrfach aktualisiert wird, ohne dass die Firewall-Konfiguration des Edge aktualisiert wird, während die Orchestrator-Benutzeroberfläche verwendet wird, werden die Updates der Secure Access-Konfiguration möglicherweise nicht mehr an die Edges gesendet.

  Das Problem trat am häufigsten bei Tests auf, bei denen die Technik absichtlich eine große Anzahl von Secure Access-Updates ohne Firewall-Updates erzwingt. In seltenen Fällen kann es jedoch auch von einem Kunden vor Ort ausgelöst werden.

  Wenn dieses Problem bei einem Orchestrator ohne Fix auftritt, kann ein Benutzer die Firewall-Konfiguration des Edge einmalig manuell über die Benutzeroberfläche aktualisieren. Nach der manuellen Firewall-Aktualisierung kann der Benutzer die Änderung der Edge Secure Access-Konfiguration von der Benutzeroberfläche aus erneut vornehmen und der Orchestrator würde die Änderung der Edge Secure Access-Konfiguration von der Benutzeroberfläche an die Edges weiterleiten.

• Behobenes Problem 103828: Der Anwendungssuchfilter des Anwendungszuordnungs-Editors ist unübersichtlich.

  Hierdurch wird das Überprüfen oder Ändern der Anwendungskonfiguration erheblich erschwert, indem zahlreiche Seiten mit Anwendungen manuell durchgeblättert werden müssen, um die gewünschte Anwendung zu finden.

• Behobenes Problem 104395: Im Abschnitt „Links deaktiviert (Links Down)“ auf der Seite „Überwachen (Monitor) > Netzwerk (Network) > Übersicht (Overview)“ werden nur die ersten 10 Sites mit deaktivierten Links angezeigt. Wenn ein Benutzer auf die Schaltfläche „Alle anzeigen (Viel all)“ klickt, leitet die Orchestrator-Benutzeroberfläche den Benutzer zum Abschnitt „Edges“ weiter, in dem alle Edges unabhängig vom Verbindungsstatus aufgelistet werden, obwohl der Benutzer nur Sites mit Edges mit einem oder mehreren deaktivieren Links anzeigen möchte.

  Wenn ein Benutzer auf das Symbol „Links deaktiviert (Links down)“ klickt, sollten in der Liste alle und nicht nur 10 deaktivierte Links angezeigt werden. Weiterhin gibt es nach dem Klicken auf „Alle anzeigen (View all)“ auch keine Möglichkeit, die Edges nach Verbindungs- oder Edge-Status zu sortieren.

• Behobenes Problem 108285: Wenn ein Benutzer beim Konfigurieren eines Profils auf der Orchestrator-Benutzeroberfläche eine Edge-Schnittstelle von geswitcht in geroutet ändert, hängt der Orchestrator die neue geroutete Schnittstelle an das Ende der gerouteten Schnittstelle an, anstatt sie am entsprechenden Index einzufügen.

  Die falsche Reihenfolge der gerouteten Schnittstellen in einer Profilkonfiguration führt zu Validierungsproblemen, wenn ein Benutzer eine statische Route mithilfe dieser Verweise für die entsprechende geroutete Schnittstelle hinzufügt.

• Behobenes Problem 108687: Ein Benutzer kann ein Nicht-SD-WAN-Ziel über Gateway so konfigurieren, dass mehrere Gateways mit derselben IP-Adresse vorhanden sind.

  Der Orchestrator sollte diese Konfiguration ablehnen und einen Fehler auslösen.

• Behobenes Problem 109125: Auf der Seite „Verwaltung (Administration) > Benutzerverwaltung (User Management)“ der Orchestrator-Benutzeroberfläche kann ein Benutzer SSH-Schlüssel nicht nach der Spalte „Dauer (Duration)“ sortieren.

  Daraus ergeben sich für einen Benutzer Einschränkungen bei der Suche nach der Dauer eines bestimmten SSH-Schlüssels.

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

  Ein Benutzer kann zu Kunden und Partner (Customers & Partners) > Kunden überwachen (Monitor Customers) > Diensteinstellungen (Service Settings) > Edge-Verwaltung (Edge Management) navigieren und im Abschnitt Allgemeine Edge-Einstellungen (General Edge Settings) die Option Grenzwert für Edge-Downlink (Edge Down Link Limit) auf einen Wert von mehr als 24 Stunden festlegen und speichern. Trotz dieser neuen Einstellung ist jedoch nach 24 Stunden kein deaktivierter WAN-Link mehr auf der Seite „Überwachen (Monitor)“ vorhanden.

• Behobenes Problem 110285: Ein Benutzer in einem Kundenunternehmen mit mehr als 5000 Netzwerkdiensten stellt unter Umständen fest, dass die Orchestrator-Benutzeroberfläche für „Netzwerkübersicht (Network Overview)“, „Überwachen (Monitor) > Edges“, „Konfigurieren (Configure) > Edges“ und „Konfigurieren (Configure) > Edges > Gerät (Device)“ langsam geladen wird.

  Dieses Problem wird dadurch verursacht, dass der API-Aufruf getEnterpriseServices zum Abfragen der Ergebnisse viel Zeit benötigt, wenn eine große Anzahl an abzurufenden Netzwerkdiensten vorhanden ist.

• Behobenes Problem 111407: Der VMware SASE Orchestrator lässt nicht zu, dass ein Benutzer die geroutete Schnittstelle eines Edge deaktiviert, wenn diese benutzerdefiniert ist und mit keinem WAN-Link verknüpft ist.

   Bei der Validierung des Orchestrators kann ein Benutzer Daten erst speichern, wenn ein WAN-Link hinzugefügt wird. Die einzige Problemumgehung besteht darin, einen WAN-Link hinzuzufügen.

• Behobenes Problem 111497: Auf der Seite „Konfigurieren (Configure) > Overlay-Flow-Steuerung (Overlay Flow Control)“ der Orchestrator-Benutzeroberfläche werden die VPN-Werte für den bevorzugten Ausstieg für Site-Subnetze als „Nicht definiert (Undefined)“ angezeigt.

  Wenn die Konfiguration des nächsten Hops für ein Nicht-SD-WAN-Ziel über Gateway konfiguriert ist, zeigen die Site-Subnetze auf der Seite Konfigurieren (Configure) > Overlay-Flow-Steuerung (Overlay Flow Control) die Option VPN für bevorzugten Ausstieg (Preferred Exit VPN) als „Nicht definiert (Undefined)“ für die VPNs an, deren Tunneltyp auf „ACTIVE_ACTIVE“ lautet.

• Behobenes Problem 111778: Wenn ein Benutzer ein Nicht-SD-WAN-Ziel über Gateway mit dem Typ „Prüfpunkt (Checkpoint)“ bearbeitet, ändert der Orchestrator den VPN-Typ in „Generischer IKEv1-Router (Generic IKEv1 Router)“.

  Dies verursacht Probleme für jeden Kunden mit einem NSD vom Typ „Prüfpunkt (Checkpoint)“ und kann zu Unterbrechungen führen, wenn der Benutzer die Vorgänge auf der Orchestrator-Benutzeroberfläche nicht nachvollziehen kann.

• Behobenes Problem 112123: Beim Hinzufügen eines VMware SD-WAN Edge 640-N wird der Modellname auf der Benutzeroberfläche von VMware SASE Orchestrator falsch angezeigt.

  Auf der Orchestrator-Benutzeroberfläche wird der Name als „EdgeModel.edge640-n“ und nicht als „Edge 640-N“ angezeigt.

• Behobenes Problem 112188: Für ein Kundenunternehmen, das ein Nicht-SD-WAN-Ziel mithilfe von GRE bereitstellt, zeigt der Orchestrator beim Ausfall des NSD-Tunnels die falsche Meldung an.

  Im Orchestrator wird folgende Meldung angezeigt: „Direkter Edge-IPSec-Tunnel inaktiv (Edge Direct IPsec tunnel down)“, wenn GRE als NSD-Tunnel verwendet wird.

• Behobenes Problem 112535: Beim Konfigurieren einer Firewallregel unter „Konfigurieren (Configure) > Firewall“ wird im Bildschirm „Quelle (Source) > Definieren (Define) > Transport“ der Transportport falsch angezeigt.

  Im Orchestrator wird lediglich „Transport“ für die Option „Transportport (Transport Port)“ angezeigt. Diese ungenaue Angabe kann beim Konfigurieren einer Firewallregel zu Verwirrung führen.

• Behobenes Problem 112826: Wenn ein Kunde eine Liste mit Warnungen über die Orchestrator-Benutzeroberfläche in eine CSV-Datei exportiert, werden nur 512 Elemente abgerufen.

  Derselbe Export mithilfe einer API kann bis zu 2048 Warnungen bereitstellen, was auch die erwartete Menge für den Export der Orchestrator-Benutzeroberfläche ist. Die Beschränkung auf 512 Elemente wirkt sich auf Kunden aus, die Warnungen exportieren, deren Anzahl den Grenzwert von 512 Elementen für den angegebenen Zeitraum überschreitet.

• Behobenes Problem 113474: Der Benutzer kann beim Konfigurieren der DHCPv6-Präfixdelegierung auf IPv6-LAN-Schnittstellen oder -Teilschnittstellen keine partielle Adresse für die Host-Schnittstelle konfigurieren.

  Dem Orchestrator fehlt die richtige Validierung, um eine partielle IPv6-Adresse zuzulassen.

  Erwartungen bei diesem Verhalten: Mit dem Fix werden die folgenden Typen vollständiger oder partieller Schnittstellenadressen für die DHCPv6-Präfixdelegierung im LAN und VLAN zugelassen oder blockiert:

  • Zulässige IPv6-Adressen:

    • 2001::20; 2222:db8:3333:4444:5555:6666:7777:8888

    • 2001:db8:3333:4444:CCCC:DDDD:EEEE:FFFF

    • ::1:0:0:0:1

    • ::f:1:0:f

    • ::f:1:e;

    • ::c:1

  • UNIQUE_LOCAL_IPV6 - fc00::

  • GLOBAL_UNICAST - 2000:: oder 2001:0DB8:C21A:1::

  • Blockiert IPv6-Adressen:

    • Leere Adresse – ::

    • Multicast-Adresse – FF01:0:0:0:0:0:0:18C, FF01:0:0:0:0:0:0:BAC0 oder FF01:0:0:0:0:DB8::

    • Loopback – 0:0:0:0:0:0:0:1 oder ::1

    • Verbindungslokal – fe80::210:5aff:feaa:20a2 oder fe80::260:97ff:fe02:6ea5

    • Sitelokal – fec0::

  • Nur ein Paar von :: kann verwendet werden, so dass die folgenden IP-Adressen blockiert werden: ::1:0:0::0:1 oder ::f:1:0::f

• Behobenes Problem 113530: Der Benutzer kann den IPv6-Adresstyp auf einer gerouteten LAN-Schnittstelle oder ‑Teilschnittstelle nicht von „DHCPv6-Präfixdelegierung (DHCPv6 Prefix Delegation)“ in einen anderen Typ ändern.

  Wenn der Benutzer im Abschnitt Konfigurieren (Configure) > Edge > Gerät (Device) > Schnittstelle (Interface) > LAN-IPv6 (LAN IPv6), in dem DHCPv6-Präfixdelegierung auf dem Orchestrator konfiguriert werden kann, einen anderen Adresstyp wie „Statisch/DHCP (Static/DHCP)“ oder „Statusbehaftet/DHCP statusfrei (Statusbehaftet/DHCP statusfrei)“ auswählt, ist der Zugriff auf die Option Speichern (Save) nicht möglich und der Benutzer kann die Änderung nicht abschließen. Das Problem ergibt sich aus einem Fehler in einem Prozess, in dem die Eindeutigkeit der Konfiguration der DHCPv6-Präfixdelegierung in einem Edge überprüft wird.

• Behobenes Problem 114151: Bei der Anzeige von Edges und Gateways auf den entsprechenden Listenseiten stellt das ihnen zugewiesene Zertifikat eine optionale Spalte dar.

  Da es sich bei der Verwendung von Zertifikaten um ein Standardverhalten handelt, sollten die Zertifikate immer in den Standardspalten für Edge- oder Gateway-Listen angezeigt werden, ohne dass sie vom Benutzer festgelegt werden müssen.

• Behobenes Problem 114444: Wenn ein VMware SASE Orchestrator auf Version 5.1.x oder höher aktualisiert wird, kann ein Benutzer seine Änderungen an der Konfiguration für ein Nicht-SD-WAN-Ziel über Gateway, für das bereits redundante Tunnel konfiguriert sind, nicht speichern.

  Der Benutzer kann die Konfiguration nicht auf der Seite „NSD über Gateway (NSD via Gateway)“ speichern, was auf Gateways zu Paketverlusten für redundante NSDs führen kann.

  Sie können dieses Problem umgehen, indem Sie auf der Benutzeroberfläche des NSD über Gateway für die redundanten BGP-Nachbarn den maximalen Hop auf 2 aktualisieren und die Änderungen speichern.

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

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

• Behobenes Problem 114897: Wenn Sie bei der VMware SASE Orchestrator-Benutzeroberfläche als Partner angemeldet sind oder wenn ein Operator die Partnerebene betrachtet, wird auf der Registerkarte „Kunden (Customers)“ die Option „Kunden und Partner (Customers & Partners)“ angezeigt.

  Der richtige Name lautet Kunden (Customers) und wird in dieser Orchestrator-Version angezeigt.

• Behobenes Problem 115441: Auf der Seite „Globale Einstellungen (Global Settings) > Kundenkonfiguration (Customer Configuration)“ werden Software- und Firmware-Images beim Konfigurieren der SD-WAN-Kachel nur angezeigt, wenn sie aktiviert sind.

  Software- und Firmware-Images sollten dem Benutzer statusunabhängig immer angezeigt werden.

• Behobenes Problem 115695: Auf der Seite „Überwachen (Monitor) > Edges“ kann ein Kunde in der Tabelle „Edge-Liste (Edge List)“ nicht nach einem Edge nach Beschreibung suchen.

  Bestimmte Wörter in der Beschreibung eines Edge (z. B. „Aktiviert“ oder der Standort des Edge) sind nützlich, um nach allen Edges mit einer ähnlichen Beschreibung zu suchen.

• Behobenes Problem 115837: Wenn Sie auf der Seite „Überwachen (Monitor) > Edges“ oder „Konfigurieren (Configure) > Edges“ der Orchestrator-Benutzeroberfläche nach Edges in der Haupttabelle suchen möchten, können die Edges erst durchsucht werden, wenn alle Edges geladen wurden.

  Beim Laden von Edges in die Haupttabelle blockiert das Listendrehfeld die Suchleiste, die erst wieder verwendet werden kann, wenn die Anforderung abgeschlossen ist. Dieser Vorgang kann insbesondere dann einige Zeit in Anspruch nehmen, wenn das Unternehmen eine große Anzahl von Edges enthält.

• Behobenes Problem 116021: Das Dialogfeld auf der Seite „Konfigurieren (Configure) > Edges > Zertifikatsdetails (Certificate Detail)“ der Orchestrator-Benutzeroberfläche ist nicht benutzerfreundlich.

  Das Dialogfeld Zertifikatsdetails (Certificate Detail) verfügt über 3 eingebettete Bildlaufleisten, wodurch es sehr eng und schwer zu bedienen ist.

• Behobenes Problem 116524: Kunden, die Edge Network Intelligence abonnieren und Analysen aktiviert haben, werden auf der Seite „Überwachen (Monitor)“ in der Linkliste auf der linken Seite zwei identische Links für „Analyse (Analytics)“ mit unterschiedlichen Namen angezeigt.

  Es gibt zwei Links für Edge Network Intelligence: Anwendungsanalyse (Application Analytics) und Zweigstellenanalyse (Branch Analytics), die beide auf denselben Inhalt in ENI verweisen. Dieser Fehler wird durch einen einzelnen Link auf der linken Seite namens Edge Network Intelligence behoben.

• Behobenes Problem 116610: Benutzer können keine neue Edge-Loopback-Schnittstelle über APIv2 hinzufügen.

  Es ist nicht möglich, eine neue Loopback-Schnittstelle mithilfe des PATCH-ADD-Vorgangs über APIv2 zu erstellen. Die Schemastruktur für die Loopback-Schnittstelle in APIv2 lässt keine Schnittstellen zu, die nach der Schnittstellen-ID benannt werden. In diesem Szenario schlägt die Aktualisierung der Loopback-Schnittstelle fehl.

• Behobenes Problem 116999: Wenn sich ein Operator-Benutzer beim VMware SASE Orchestrator anmeldet, wird auf der rechten Seite des Orchestrators das Menü „Partnermenü (Partner Menu)“ angezeigt.

  Dies kann beim Operator zu Verwirrung führen, da das Menü eigentlich „Operator-Menü (Operator Menu)“ heißen sollte.

• Behobenes Problem 117001: Der Benutzer kann auf der Seite „Verwaltung (Administration) > Benutzerverwaltung (User Management) > Rollen (Roles)“ der Orchestrator-Benutzeroberfläche nicht alle Rollentypen/Benutzer auf einer Seite anzeigen.

  Da die Seite Roles (Rollen) eine Paginierung aufweist, befinden sich nicht alle Rollen auf einer Browserseite, sondern verteilen sich auf mehrere Browserseiten. Das Problem besteht darin, dass die Steuerelemente der Benutzeroberflächenseite schwer zu erkennen sind. Mit dem Fix wird die Paginierung entfernt, und alle Rollen und Typen werden auf einer Seite platziert.

• Behobenes Problem 117020: Wenn ein Benutzer auf der Seite „Konfigurieren (Configure) > Netzwerkdienste (Network Services)“ die Registerkarte „TACACS-Dienste (TACACS Services)“ auswählt und versucht, einen TACACS-Dienst zu löschen, wird auf der Benutzeroberfläche die falsche Textzeichenfolge zum Bestätigen des Löschvorgangs angezeigt.

  Beim Löschen eines TACACS-Diensts wird auf der Benutzeroberfläche folgende Textzeichenfolge angezeigt: configuration.networkServices.deleteConfirm. Auf der Benutzeroberfläche sollte das richtige Löschdialogfeld „Möchten Sie dieses Element wirklich löschen? (Are you sure you wish to delete this item?)“ angezeigt werden.

• Behobenes Problem 117145: Für ein Kundenunternehmen, in dem VNFs bereitgestellt werden, deaktiviert der Orchestrator die VNF, wenn ein Benutzer eine Konfiguration in „Konfigurieren (Configure) > Gerät (Device)“ ändert.

   Der Orchestrator stellt die VNF nach deren Deaktivierung nicht erneut bereit, was zu erheblichen Störungen beim Kunden führt.

• Behobenes Problem 117152: Wenn ein Benutzer einen BGP-Filter für eine Community erstellt, die Ganzzahlwerte größer als 65535 aufweist, und diesen Filter einem Nachbarn zuordnet, lässt der Orchestrator diese Integration zu, obwohl der Edge den Filter ignoriert.

  Der Edge unterstützt nur Community-Werte im Format AA:NN mit den Werten (0-65535):(0-65535). Werden Werte größer als 65535 als Ganzzahl angegeben, ignoriert der Edge diese Werte, und der Orchestrator kann einen Filter mit einem Wert größer als 65535 nicht zurückweisen.

• Behobenes Problem 117385: Ein Benutzer kann beim Versuch, mehrere Konfigurationsänderungen durchzuführen, Geschwindigkeitsprobleme auf dem VMware SASE Orchestrator beobachten.

  Der Kunde kann nicht mehrere Konfigurationsänderungen auf dem Orchestrator durchführen, da die Vorgänge bis zu einer Minute dauern.

• Behobenes Problem 117537: Auf der Seite „Überwachen (Monitor) > Edges > Quellen (Sources)“ der Orchestrator-Benutzeroberfläche wird in der Liste der Clientgeräte eine falsche in der Regel geringere Anzahl an Geräten angezeigt.

  Dieses Problem tritt auf, wenn der Modus „Sichtbarkeit nach IP-Adresse (Visibility by IP Address)“ oder „Sichtbarkeit nach MAC-Adresse (Visibility by MAC Address)“ nicht im spezifischen Konfigurationsmodul des Standard-Edge, sondern in einem zugeordneten Modul festgelegt ist.

• Behobenes Problem 117573: Wenn ein Benutzer auf der Seite „Konfigurieren (Configure) > Gerät (Device) > VPN-> Cloud-VPN (Cloud VPN)“ versucht, eine Zweigstelle-zu-Hub-Site zu konfigurieren, können Hubs nicht mithilfe des Filtersymbols gefiltert werden.

  Wenn in einem Kundenunternehmen mehrere Hubs konfiguriert sind, gestaltet sich die Konfiguration eines Zweigstelle-zu-Hub-VPN aufgrund fehlender Filter schwierig.

• Behobenes Problem 117614: Auf der Seite „Konfigurieren (Configure) > Profil (Profile)“ der Orchestrator-Benutzeroberfläche fehlen mehrere Aktionen im Feld „Verknüpfungen (Shortcuts)“.

  Zu den fehlenden Verknüpfungen gehören: Profil migrieren (Migrate Profile); Profil duplizieren (Duplicate Profile); Profil ändern (Modify Profile); und Profil löschen (Delete Profile). Diese Aktionen befinden sich auf der Listenseite des Profils, aber der Kunde sollte einfacheren Zugriff auf diese Aktionen haben.

• Behobenes Problem 118265: Auf der Seite „Benutzerverwaltung (User Management)“ der Orchestrator-Benutzeroberfläche kann ein Admin-Benutzer mit den entsprechenden Berechtigungen ein Benutzerkonto nicht löschen, wenn er die Suche zum Auffinden dieses Kontos verwendet hat.

  Wenn der Benutzer die Suchleiste für die Suche nach dem Konto verwendet und mindestens 4 Zeichen eingibt, wird die Schaltfläche Löschen (Delete) nach dem Auffinden des Kontos abgeblendet und ist nicht mehr funktionsfähig.

• Behobenes Problem 118302: Auf der Seite „Überwachen (Monitor) > Edge“ der Orchestrator-Benutzeroberfläche kann der Benutzer den Verbindungsstatus für Edges nicht filtern.

  Die Orchestrator-API wurde dahingehend optimiert, dass der Verbindungsstatus als Filterparameter akzeptiert und der Vorgang zum Filtern des Verbindungsstatus auf dem Bildschirm „Edge-Liste (Edge List)“ unterstützt wird.

• Behobenes Problem 118527: Auf einem VMware SASE Orchestrator, der als Bastian-Orchestrator mithilfe einer externen Zertifizierungsstelle bereitgestellt wird, können Kunden beobachten, dass ein VMware SD-WAN nach erfolgreicher Hochstufung offline geschaltet wird.

  In einer Bastion-Umgebung, in der der private Orchestrator mit einer externen Zertifizierungsstelle integriert ist, wechselt der Edge kurz nach seiner Hochstufung zum privaten Orchestrator in einen Offline-Zustand.

  In einem Orchestrator ohne einen Fix für dieses Problem besteht die Problemumgehung darin, die Zertifikatswiderrufsliste (Certificate Revocation List, CRL) auf dem Edge-Gerät zu löschen und den Edge-Dienst neu zu starten.

• Behobenes Problem 118670: Das Laden der Seite „Überwachen (Monitor) > Netzwerkdienste (Network Services) > Edge-Cluster (Edge Cluster)“ kann mehr als 30 Sekunden in Anspruch nehmen.

  Wenn ein Unternehmen über mehr als 10.000 Netzwerkdienste verfügt, nimmt das Laden der Seite Überwachen (Monitor) > Netzwerkdienste (Network Services) > Edge-Cluster (Edge Cluster) viel Zeit in Anspruch.

• Behobenes Problem 118761: Der Benutzer kann im Dialogfeld „Software-Image zuweisen (Assign Software Image)“ auf der Seite „Edge-Auflistung (Edge Listing)“ keine Software-Images filtern.

  Die fehlende Filterung erschwert den Auswahlprozess, wenn zahlreiche Software-Images zur Auswahl stehen.

• Behobenes Problem 118764: Benutzer können im Dialogfeld „Operator-Profil zuweisen (Assign Operator Profile)“ auf der Seite „Edge-Auflistung (Edge Listing)“ keine Elemente filtern.

  Das Fehlen von Filteroptionen erschwert die Auswahl des Operator-Profils.

• Behobenes Problem 118767: Auf der Seite „Edge-Übersicht (Edge Overview)“ können Benutzer beim Aktualisieren der Auswahl „Edge-Lizenz (Edge License)“ Elemente weder filtern noch eine Auswahl treffen.

  Die fehlende Filterung erschwert den Auswahlprozess, wenn zahlreiche Edge-Lizenzen zur Auswahl stehen.

• Behobenes Problem 121336: Wenn für einen Edge oder ein Profil auf der Seite „Konfigurieren (Configure) > Gerät (Device)“ die Option „Zuweisung von Partner-Gateways (Partner Gateway Assignment)“ konfiguriert ist und Änderungen über einen API-Aufruf erfolgen, werden die Gateways im Ereignis „Profil-Update (Profile Update)“ immer als gelöscht angezeigt.

  Hierbei handelt es sich um ein kosmetisches Problem ohne Auswirkungen auf die Funktionen. Das Problem tritt auf, weil das Feld „Gateways“ in der Konfiguration veraltet ist.

• Behobenes Problem 121995: Ein Kunde erhält HA-Failover-Warnungen, obwohl er diese Warnungen auf der Seite „Konfigurieren (Configure) > Warnungen (Alerts)“ des Orchestrators deaktiviert hat.

  Wenn Unternehmenswarnungen zwar aktiviert, HA-Failover-Warnungen aber deaktiviert sind, wird die HA-Failover-Warnung an Unternehmensbenutzer gesendet.

• Behobenes Problem 122940: Wenn sich ein Benutzer auf der Seite „Gateway-Verwaltung (Gateway Management)“ befindet, wird er in bestimmten Fällen unter Umständen an den falschen Bildschirm weitergeleitet.

  Wenn ein Kunde ein Sicheres VPN-Gateway (Secure VPN Gateway) zuweisen möchte, sollte der Orchestrator an den Bildschirm Datencenter-Gateway zuweisen (Assign Datacenter Gateway) weitergeleitet werden. Er wird aber fälschlicherweise an den Bildschirm Super-Gateway zuweisen (Assign Super Gateway) weitergeleitet.

• Behobenes Problem 123593: Bei einem mit einer Hochverfügbarkeitstopologie bereitgestellten Kundenunternehmen, in dem die Edge Network Intelligence-Analyse aktiviert ist, kann der HA-Edge in seltenen Fällen die Analysekonfiguration nicht aus dem Edge Network Intelligence-Back-End abrufen.

  Es ist möglich, dass sowohl die aktiven als auch die Standby-Edges dasselbe Token vom ENI-Back-End erhalten. Wenn der Standby-Edge das Token nach dem aktiven Edge erhält, wird das Token des aktiven Edge als veraltet eingestuft, was zu diesem Szenario führt.

• Behobenes Problem 123619: Wenn eine VMware SASE Orchestrator-Instanz nicht auf das Internet zugreifen kann (z. B. eine lokal installierte Instanz), ist die Seite „Überwachen (Monitor) > Edge > Übersicht (Overview)“ leer und es werden keine Informationen angezeigt.

  Wenn der Orchestrator nicht auf das Internet zugreifen kann, ist der Zugriff auf die Seite Edge-Übersicht (Edge Overview) aufgrund fehlenden Zugriffs auf Google-Dienste nicht möglich.

• Behobenes Problem 123867: Die Link-Metriken und Serien-APIs geben einen Fehler zurück.

  Wenn die Link-Metriken oder Serien-APIs ohne eine Metrikliste aufgerufen werden, gibt die API irrtümlicherweise einen Fehler zurück, anstatt alle anwendbaren Metriken zur Antwort hinzuzufügen.

  Auf einem Orchestrator ohne einen Fix für dieses Problem muss ein Benutzer eine API-Anforderung mit einer Liste von zurückzugebenden Metrikfeldern übermitteln.

• Behobenes Problem 124092: Der Benutzer kann den Segmentnamen auf dem Bildschirm „Overlay-Flow-Steuerung (Overlay Flow Control)“ nicht anzeigen.

  Beim Filtern nach Segmentname wird der Segmentname nicht als Teil der Ergebnisse aufgeführt.

• Behobenes Problem 124743: Auf dem Bildschirm „Überwachen (Monitor) > Edge > Übersicht (Overview)“ des VMware SASE Orchestrator wird das Raster „Verbindungsstatus (Link Status)“ nicht vollständig geladen.

  Der Verbindungsstatus kann nicht geladen werden, weil mindestens ein WAN-Link als „Sicherung (Backup)“ oder „Hot-Standby (Hot Standby)“ konfiguriert ist. In diesem Fall fehlt der Status „Sicherung (Backup)/Hot-Standby (Hot Standby)“ in einem der Links, wodurch die Benutzeroberfläche fehlschlägt.

  Ein Benutzer kann dieses Problem umgehen, indem er den Linkmodus für „Sicherungstransport (Backup Transport)“ des Links von „Hot-Standby (Hot Standby)“ in „Aktiv (Active)“ ändert und speichert und den Modus anschließend wieder zurück in „Hot-Standby (Hot Standby)“ ändert.

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

• Behobenes Problem 127281: Auf der Seite „Konfigurieren (Configure) > Overlay-Flow-Steuerung (Overlay Flow Control)“ der Orchestrator-Benutzeroberfläche werden statische Konfigurationen auf gerouteten Teilschnittstellen auf der OFC-Seite nicht als verbundene Routen angezeigt.

  Wenn eine statische Konfiguration auf einer gerouteten Nicht-WAN-Schnittstelle oder -Teilschnittstelle durchgeführt wird, wird davon ausgegangen, dass sie auf der OFC-Seite als verbundene Routen angezeigt werden. Dies funktioniert jedoch nicht bei Teilschnittstellen, die IPv6-Konfigurationen verwenden und bei denen IPv6 nicht auch auf der übergeordneten Schnittstelle der Teilschnittstelle aktiviert ist.

• Behobenes Problem 127636: Auf der Seite „Überwachen (Monitor) > Edge > Quellen (Sources)“ der VMware SASE Orchestrator-Benutzeroberfläche funktioniert die Suche eines Benutzers nach einer Quelle über FQDN nicht.

  Die Funktion „Suche nach FQDN (Search by FQDN)“ funktioniert nicht wie erwartet, wenn die neue Benutzeroberfläche verwendet wird, wodurch 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.

  Sie können weiterhin nach IP-Adresse suchen, müssen aber eine vollständige Zeichenfolge verwenden.

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

  Dieses Problem hindert Benutzer daran, Edge-Zertifikate anzuzeigen. 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.

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 75171: Ein Edge-Clientbenutzer erhält keine IP-Adresse, wenn der DHCP-Server auf einer Site mit Nicht-SD-WAN-Ziel über Gateway konfiguriert ist, auf der der Edge als Relay-Agent fungiert.

  Das Problem ist darauf zurückzuführen, dass die Nachrichten zum DHCP-Angebot (DHCP Offer) vom Edge verworfen werden, da der Edge-Code diese DHCP-Konfiguration nicht berücksichtigt.

  Problemumgehung: Platzieren Sie den DHCP-Server an einem anderen Ort als einem Nicht-SD-WAN-Ziel.

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

  Da IPv6 und Standardrouten nicht konfiguriert werden, bilden sich die IPv6-Verwaltungstunnel des AWS-Gateways nicht und das Gateway funktioniert nicht.

  Problemumgehung: Es gibt keine Umgehung für dieses Problem. Vermeiden Sie daher die Bereitstellung eines Gateways mit den oben genannten Eigenschaften.

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

  Problemumgehung: Der Kunde kann L2-Schleifenerkennungsereignisse von Upstream-Switches ignorieren, die von der HA-Schnittstelle des Edge ausgehen (normalerweise GE1).

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

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

• 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 102583: An einer Site eines Kundenunternehmens, die mit einer Hochverfügbarkeitstopologie mit installierten VNFs bereitgestellt wird und an der das HA-Edge-Paar oder eines der Edge-Modelle 520/540 oder 610 installiert ist, kann die Erreichbarkeit der VNF des Standby-Edges von einem mit dem LAN verbundenen Client aus fehlschlagen.

  Die Ethernet-Switchkarte dieser Edge-Modelle verwirft ARP-Antwortpakete, die von einem VNF eines Standby-Edges an einen LAN-Client gesendet werden, was zu einem Verlust der Erreichbarkeit führt.

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

• 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 111592: Für ein Kundenunternehmen, das eine Hub/Spoke-Topologie verwendet, in der Business Policies für die Verwendung von Internet-Backhaul konfiguriert sind, ist der Internetdatenverkehr, der die Backhaul-Regel verwendet, entweder langsam oder funktioniert überhaupt nicht.

  In einigen Fällen wird der Business Policy-Abgleich während der Erstellung des Flows aufgrund aktualisierter DPI-Informationen (Deep Packet Inspection) geändert. Dies kann zum Verlust der logischen ID des Hub-Edge oder des Nicht-SD-WAN-Ziels führen, das die Pakete weiterleiten soll.

  Problemumgehung: Leeren Sie Flows, um zu erzwingen, dass die Flows von der DPI-Engine erneut überprüft werden.

• 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 111840: In einem Kundenunternehmen, das eine Hub/Spoke-Topologie mit 9 oder mehr Hub-Edges einsetzt, können Clientbenutzer aufgrund von suboptimalem Routing eine schlechte Datenverkehrsqualität feststellen.

  Wenn ein Spoke-Edge mit mehreren Hub-Edges konfiguriert ist, wird eine Route über den Hub-Edge gegenüber der direkten Route bevorzugt, was zu einem suboptimalen Routing führt.

  Problemumgehung: Konfigurieren Sie zuerst Hub-Edges, gefolgt von VPN-Hubs in der Liste der Zweigstelle-zu-Hub-Sites.

• Problem 120309: Kombinationen aus bestimmten PPTP-VPN-Clients und ‑Servern können bei Verwendung von 1:1-NAT mit dem PPTP-Internet und dem Client-Gerät hinter dem Edge eine Verbindung nach einer Unterbrechung möglicherweise nicht sofort wiederherstellen. Es wurde bestätigt, dass dieses Problem bei Windows Server 2016 und Windows 10-Client auftritt, aber es kann auch bei anderen Versionen auftreten.

  Das Problem wird dadurch verursacht, dass der Server dieselbe PPTP-Call-ID für die neue Verbindung verwendet, während der Client eine neue Call-ID verwendet. Wenn die Server-Call-ID für die neue Verbindung wiederverwendet wird, wird sie von der Firewall nicht als solche erkannt.

  Auf einem Edge ohne ein Fix für dieses Problem besteht die Problemumgehung darin, die veraltete PPTP-Verbindung aus der NAT-Tabelle zu löschen.

  Hinweis:

  Das gleiche Problem kann auftreten, wenn die Netzwerkstandorte von Client und Server vertauscht sind (d. h. der PPTP-Server im LAN hinter dem Edge und der Client im Internet/der Cloud). Diese Version des Problems wird mit dem Ticket #109830 nachverfolgt. Der Fix betrifft insbesondere Windows Server 2016-Clients. Windows 10-Clients weisen nach wie vor dieses Problem auf und wird mit diesem Fix nicht behoben.

  Problemumgehung: Leeren Sie die veraltete PPTP-Verbindung aus der NAT-Tabelle.

• Problem 121281: Bei einer Site eines Kundenunternehmens mit einer Hochverfügbarkeitstopologie kann der Kunde in seltenen Fällen feststellen, dass am Standby-Edge ein Ausfall des Datenebene-Diensts aufgetreten ist, einen Core-Fehler generiert und zur Wiederherstellung neu gestartet wurde.

  Es würde ein Ereignis über den Neustart des Standby-Edge auftreten und wenn der Benutzer eine HA-Fehlermeldung konfiguriert, würde er über dieses Ereignis benachrichtigt werden. Das Problem tritt in seltenen Fällen auf, wenn eine Route zwischen dem aktiven und dem Standby-Edge synchronisiert wird und der Standby-Edge-Dienst aufgrund einer Speicherbeschädigung bei der Verarbeitung der Routensynchronisierungsnachricht ausfällt.

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

• Problem 121371: Bei einem Kundenunternehmen, das für die Verwendung von Hub- oder Cluster-Interconnect konfiguriert ist und bei dem auch die statusbehaftete oder erweiterte Firewall verwendet wird, kann es bei Clientbenutzern zu einem Verlust des Datenverkehrs kommen.

  Asymmetrisches Routing kann zwischen dem Quell- und dem Zielknoten des Cluster-Hubs auftreten, sodass der ausgehende Datenverkehr einen direkten Overlay-Tunnel nimmt, während der Rückverkehr über eine Underlay-Route erfolgt.

  Problemumgehung: Die einzige Problemumgehung besteht darin, die statusbehaftete Firewall oder erweiterte Firewalldienste 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 PG-Übergabe-IP-Adressen wie erwartet konfiguriert sind, gibt es keine andere Lösung als das Verschieben einiger dieser Adressen zu einem anderen PG (z. B. Verschieben eines NSD über Gateway). Wenn es jedoch unnötige PG-Übergabe-IP-Adressen gibt, kann das Entfernen dieser Adressen helfen, wenn dadurch die Anzahl der IP-Adressen auf unter 64 reduziert wird. Nach einer Konfigurationsänderung muss der Gateway-Dienst neu gestartet werden.

• Problem 121805: Bei einem VMware SD-WAN Edge, der mit VNFs bereitgestellt wird, kann der Benutzer doppelte Antworten feststellen, wenn eine lokale VNF angepingt wird.

  Das Problem tritt auf, wenn vom Edge aus ein Ping auf die IP einer VNF durchgeführt wird.

  Problemumgehung: Pingen Sie immer von einem LAN-Client hinter dem Edge an, nicht vom Edge selbst.

• 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 123379: Bei einer Site eines Kundenunternehmens mit einer Hochverfügbarkeitstopologie kann der Kunde in seltenen Fällen feststellen, dass am Standby-Edge ein Ausfall des Datenebene-Diensts aufgetreten ist und dieser für die Wiederherstellung neu gestartet wurde.

  Dieses Problem kann auftreten, wenn ein Benutzer versucht, mithilfe eines Skripts IPv6-Adressen auf Teilschnittstellen in 128 Segmenten gleichzeitig zu konfigurieren. In diesem Szenario sammeln sich die Konfigurationen in einer Warteschlange an, was dazu führt, dass der Standby-Edge ausfällt.

  Problemumgehung: Es wird empfohlen, IPv6-Adresskonfigurationen auf Teilschnittstellen in kleineren Gruppen zu konfigurieren, damit das System Zeit hat, die Konfigurationen zu verarbeiten und anzuwenden.

• Problem 125509: Bei einem Kundenunternehmen, das VMware SD-WAN-Edge-Modelle der unteren Leistungsklasse verwendet, kann es je nach verwendetem Routing-Protokoll zu Flaps für BFD, BGP oder OSPF kommen.

  Auf Edge-Plattformen der Einstiegsebene (510, 520, 540, 610 und 620) bei hoher Flow-Skalierung und in Kombination mit dynamischem Routing und/oder Hochverfügbarkeitskonfiguration können OSPF/BGP-Routing-Flaps auftreten, wenn aggressive Hello- und Dead-Timer konfiguriert sind. Wenn der Kunde auch Edge Network Intelligence mit aktivierter Analyse verwendet, erhöht sich außerdem die Möglichkeit, auf dieses Problem zu stoßen.

  Problemumgehung: Wenn dieses Problem auftritt, besteht die Problemumgehung darin, die Standardintervall-Timer für OSPF (10, 40) oder BGP (60, 180) wiederherzustellen oder BFD vollständig zu deaktivieren.

• Problem 127920: Ein ICMP-Test, der an eine statische Route mit einer sekundären IP-Adresse als nächstem Hop angehängt ist, kann ausfallen, obwohl die sekundäre IP-Adresse aktiv und erreichbar ist.

  Wenn ein ICMP-Test an eine statische Route mit einer sekundären IP-Adresse als nächstem Hop angehängt ist, verwendet der Test die IP-Adresse der Hauptschnittstelle anstelle der sekundären IP-Adresse. Wenn der Peer die primäre IP-Adresse nicht erreichen kann, führt dies dazu, dass der ICMP-Test ausfällt, obwohl die sekundäre IP aktiv und erreichbar ist.

  Problemumgehung: In diesem Szenario gibt es keine andere Problemumgehung als die Nichtverwendung einer sekundären IP-Adresse.

• Problem 128379: Eine BGP-Zusammenfassungsroute, die ein Spoke Edge über ein MPLS-Backbone an einen Hub-Edge annonciert, kann in eine Schleife aus Rücknahme und Annoncierung geraten.

  Die Sequenz, die zu diesem Problem führt, sieht folgendermaßen aus:

  1. Der Spoke-Edge fügt seine autonome Systemnummer (Autonomous System Number, ASN) hinzu und annonciert das BGP-Zusammenfassungspräfix an den Kunden-Edge-Router (CE). Dann fügt der CE seine ASN hinzu und annonciert sie an den Hub-Edge.

  2. Der Hub-Edge verteilt das Zusammenfassungspräfix mit allen empfangenen ASNs in das Overlay (unter Verwendung des SD-WAN-Managementprotokolls VCRP) weiter. Der Hub-Edge verteilt auch die Präfixe, die er über den Uplink erhalten hat, weiter.

  3. Der Spoke-Edge empfängt dasselbe Zusammenfassungspräfix ebenfalls über VCRP mit der ASN des CE. Der Spoke-Edge verteilt dieses Overlay-Präfix in BGP weiter. Da As-Set in der Aggregatkonfiguration aktiviert ist, sammelt BGP ASNs aus dem Overlay-Präfix und fügt sie dem AS_PATH des Zusammenfassungspräfixes hinzu.

  4. Jetzt empfängt CE das Zusammenfassungpräfix mit dem aktualisierten AS_PATH. Da die ASN des CE Teil des aktualisierten AS_PATH ist, lehnt das CE das Zusammenfassungspräfix ab und zieht es vom Hub-Edge zurück. Der Hub-Edge zieht es dann über VCRP aus dem Spoke-Edge zurück.

  5. Jetzt ändert der Spoke-Edge den AS_PATH des BGP-Präfixes wieder auf normal und annonciert es erneut. Dieser Zyklus wiederholt sich ständig.

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

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 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 114475: Wenn ein Operator versucht, eine VMware SASE Orchestrator-Instanz der Version 4.2.0 auf 5.1.0 zu aktualisieren, meldet der Orchestrator möglicherweise, dass das Upgrade fehlgeschlagen ist.

  In den Protokollen beobachtet der Operator diesen Eintrag: Error while initializing CWS Server service Error: Too many connections.

  Dieses Problem wird durch einen Neustart von MySQL ausgelöst, bevor vco-db-schema installiert wird. Dies wird dadurch verursacht, dass MySQL die maximale Anzahl an Verbindungen nicht festlegt. Während der Orchestrator darüber hinaus meldet, dass die Installation fehlgeschlagen ist, wurde die Installation in Wirklichkeit abgeschlossen. Der Orchestrator kann neu gestartet werden, und alle Dienste funktionieren wie erwartet.

• 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 124568: Bei einem VMware SASE Orchestrator, der mit einer Notfallwiederherstellungstopologie (Disaster Recovery, DR) bereitgestellt wird, kann der Operator-Benutzer in seltenen Fällen feststellen, dass die DR unterbrochen wird, was zu einem vorübergehenden Ausfall der Replizierung zwischen den aktiven und den Standby-Orchestrator-Instanzen führt.

  Die Benutzererfahrung wird dadurch nicht beeinträchtigt, da dies nur auf die DR beschränkt ist. Auf der DR-Seite wird ein Fehlerstatus anstelle von STANDBY_RUNNING angezeigt.

  Problemumgehung: Dies ist ein vorübergehender Fehler und wird automatisch behoben.

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

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

  Problemumgehung: Um dieses Problem ohne Fix zu vermeiden, können Sie die Orchestrator-Systemeigenschaft, die die Toleranz für eine fehlgeschlagene Synchronisierung regelt, um einen angemessenen Wert erhöhen: vco.disasterRecovery.transientErrorToleranceSecs, um ein längeres Fenster für die automatische Wiederherstellung zu erhalten.

• 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 neue 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: Für dieses Problem gibt es keine Problemumgehung.

• 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 126695: Wenn ein Benutzer Webhooks für Warnungen konfiguriert, wird das Menü nicht angezeigt, wenn er auf die Schaltfläche „Nutzlastvorlage konfigurieren (Configure Payload Template)“ klickt.

  Dieses Problem tritt auf, wenn Webhooks auf der Seite SD-WAN > Einstellungen (Settings) > Alarme (Warnungen) > Webhooks der Benutzeroberfläche konfiguriert werden. Wenn ein Benutzer die Browserkonsole betrachtet, sieht er außerdem die folgende Meldung: ERROR TypeError: Cannot read properties of undefined (reading 'invalid').

  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 130115: Bei einem VMware SASE Orchestrator, der mit einer Notfallwiederherstellungstopologie (Disaster Recover, DR) konfiguriert ist, werden auf den DR-Seiten des aktiven und des Standby-Orchestrators im Abschnitt „Verlauf (History)“ unterschiedliche Details angezeigt.

  Der Benutzer sieht auf der aktiven Orchestrator-Instanz zusätzliche Zeilen für einen ausgefallenen DR-Status im Vergleich zu den Standby-Zeilen unter dem Abschnitt „Verlauf (History)“ und diese Zeilen sind auf der aktiven Orchestrator-Instanz nicht nach Zeit sortiert.