Aktualisiert am 8. Juni 2022 VMware SD-WAN™ Orchestrator Version R421-20211216-GA VMware SD-WAN™ Gateway Version R421-20210407-GA VMware SD-WAN™ Edge Version R421-20210624-GA-57011-60130 Prüfen Sie regelmäßig, ob Ergänzungen und Updates dieser Versionshinweise vorhanden sind.

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

• Empfohlene Verwendung
• Kompatibilität
• Wichtige Hinweise
• Revisionsverlauf
• Behobene Probleme
• Bekannte Probleme

Empfohlene Verwendung

Diese Version wird allen Kunden empfohlen, die die erstmals in Version 4.2.0 zur Verfügung gestellten Funktionen benötigen, sowie Kunden, die von den unten aufgeführten Problemen betroffen sind, die ab Version 4.2.0 behoben wurden.

Kompatibilität

Version 4.2.1 für Orchestrator-Instanzen, Gateways und Hub-Edges unterstützt alle früheren Versionen von VMware SD-WAN Edge ab Version 3.0.0 
Hinweis: Versionen vor 3.0.0 werden nicht unterstützt.

Die folgenden Interoperabilitätskombinationen wurden explizit getestet:

Orchestrator	Gateway	Edge
		Hub	Zweigstelle/Spoke
4.2.0	4.2.0	4.2.0	4.2.1
4.2.0	4.2.0	4.2.1	4.2.1
4.2.1	3.4.2	3.4.2	3.4.2
4.2.1	4.2.1	3.4.2	3.4.2
4.2.1	4.2.1	4.2.1	3.4.2
4.2.1	4.2.1	3.4.2	4.2.1
4.2.1	4.2.1	3.4.5	3.4.5
4.2.1	4.2.1	4.2.1	3.4.3, 3.4.4, 3.4.5
4.2.1	4.2.1	3.4.3, 3.4.4, 3.4.5	4.2.1
4.2.1	3.3.2 P3	3.3.2 P3	3.3.2 P3
4.2.1	4.2.1	3.3.2 P3	3.3.2 P3
4.2.1	4.2.1	4.2.1	3.3.2 P2, 3.3.2 P3
4.2.1	4.2.1	3.3.2 P2	4.2.1
4.2.1	3.2.2	3.2.2	3.2.2
4.2.1	4.2.1	3.2.2	3.2.2
4.2.1	4.2.1	4.2.1	3.2.2
4.2.1	4.2.1	3.2.2	4.2.1
4.2.1	4.0.0	4.0.0	4.0.0
4.2.1	4.0.0	4.0.1	4.2.1
4.2.1	4.2.1	4.0.0	4.0.1

Warnung: VMware SD-WAN Versionen 4.0.x und 4.2.x nähern sich dem Ende des Supports. 

• Version 4.0.x erreicht 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. 
• Version 4.2.x für Orchestrator-Instanzen und Gateways erreicht 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.   
• Version 4.2.x für Edges erreicht 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.
• Weitere Informationen finden Sie im Knowledgebase-Artikel: Ankündigung: Ende des Supports für VMware SD-WAN, Version 4.x (88319) (Announcement: End of Support Life for VMware SD-WAN Release 3.x (84151))

Hinweis: Version 3.x hat AES-256-GCM nicht ordnungsgemäß unterstützt. Dies bedeutet, dass Kunden, die AES-256 verwenden, ihre Edges immer mit deaktiviertem GCM verwenden (AES-256-CBC). 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.

Wichtige Hinweise

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

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

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

Upgrades auf diese Version können bei Edge 3x00-Modellen (z. B. 3400, 3800 und 3810) länger als normal (3-5 Minuten) dauern. Dies ist auf ein Firmware-Upgrade zurückzuführen, das das Problem 53676 behebt. Wenn ein Edge 3400 oder 3800 zuvor bei Version 3.4.5 oder 4.0.2 für seine Firmware ein Upgrade durchgeführt hätte, würde das Edge-Upgrade innerhalb der erwarteten Zeit durchgeführt. Weitere Informationen finden Sie unter „Behobenes Problem 53676“.

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

Wenn ein Benutzer die automatische Aushandlung für hartcodierte Geschwindigkeit und Duplex auf den Ports GE1 bis GE4 auf einem VMware SD-WAN Edge-Modell 620, 640 oder 680, auf den Ports GE3 oder GE4 auf einem Edge-Modell 3400, 3800 oder 3810 oder auf einem Edge-Modell 520/540 bei Verwendung eines SFP mit einer Kupferschnittstelle auf den Ports SFP1 oder SFP2 deaktiviert, kann der Benutzer feststellen, 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).

Dokumentierter Revisionsverlauf

9. April 2021. Erste Auflage.

13. April 2021. Zweite Auflage.

• Behobenes Problem 53676 wurde dem Abschnitt „Behobene Probleme bei Edge/Gateway“ hinzugefügt.  Dieses Problem wurde fälschlicherweise in den ursprünglichen Versionshinweisen ausgelassen.
• Es wurde ein Abschnitt „Wichtige Hinweise“ hinzugefügt, in dem die erweiterte Upgrade-Zeit eines 3x00 beschrieben wird, wenn die Firmware im Rahmen des Fix für 53676 aktualisiert werden musste.

21. April 2021. Dritte Auflage.

• Ein neuer Orchestrator-Build wurde hinzugefügt: R421-20210415-GA als aktueller Build.  Im Abschnitt „Behobene Probleme bei Orchestrator“ wurde ein neuer Abschnitt für R421-20210415-GA hinzugefügt.
• Das Ticket #61312 wurde zum Abschnitt „Behobene Probleme bei Orchestrator“ für R421-20210415-GA hinzugefügt.

7. Mai 2021. Vierte Auflage.

• Die Tabelle Kompatibilität wurde überarbeitet, um zwei neue getestete Kombinationen aufzunehmen:
  • Orchestrator und Gateway in Version 4.2.0 wurden als kompatibel mit einem Hub-Edge unter Verwendung von 4.2.0 und einem Spoke Edge mit 4.2.1 getestet.
  • Orchestrator und Gateway in Version 4.2.0 wurden als kompatibel mit einem Hub-Edge unter Verwendung von 4.2.1 und einem Spoke Edge mit 4.2.1 getestet.
• Behobene Probleme 55949 und 56149 wurden dem Abschnitt „Behobene Probleme bei Edge/Gateway“ hinzugefügt. Diese Tickets sollten in den ursprünglichen GA-Versionshinweisen enthalten sein.

15. Juni 2021. Fünfte Auflage.

• Das behobene Edge/Gateway-Problem 56876 wurde geändert, um ein zweites Szenario zu berücksichtigen, das der Fix für dieses Problem behebt. Es betrifft auch die Arbeitsspeicherverwaltung, die zu einer Edge-Kernel-Panik und einem Neustart führt.
• Das behobene Problem 54001 bei Edge/Gateway wurde hinzugefügt, das fälschlicherweise bei früheren Auflagen weggelassen wurde.

5. August 2021. Sechste Auflage.

• Es wurden sechs bekannte Probleme zum Abschnitt über offene Probleme bei Edge/Gateway hinzugefügt: #60006, #60225, #61361, #62552, #63359 und #67790.

11. August 2021. Siebte Auflage.

• Es wurde eine neue Edge-Version R421-20210624-GA-57011-60130 hinzugefügt und die bestehenden Tickets 57011 und 60130 in den neuen Abschnitt für diese Edge-Version verschoben.

16. September 2021. Achte Auflage. 

• Zu Wichtige Hinweise wurde folgender Hinweis hinzugefügt: Änderung des Trennzeichens in der BGPv4-Filterkonfiguration für das Voranstellen des AS-PATH.

21. Dezember 2021. Neunte Auflage.

• Ein neuer Orchestrator-Build R421-20211216-GA wurde zum Abschnitt „Behobene Probleme bei Orchestrator“ hinzugefügt. Dieser Orchestrator-Build behebt CVE-2021-44228, die Apache Log4j-Schwachstelle, durch Aktualisieren auf die Log4j-Version 2.16.0. Weitere Informationen zur Apache Log4j-Schwachstelle finden Sie im VMware Security Advisory VMSA-2021-0028.5.
• Zu Wichtige Hinweise wurde folgender Hinweis hinzugefügt: Einschränkung beim Deaktivieren der automatischen Aushandlung auf den VMware SD-WAN Edge-Modellen 520, 540, 620, 640, 680, 3400, 3800 und 3810. Dieser Hinweis behandelt ein Problem, das beim Konfigurieren einer erzwungenen Geschwindigkeit auf einigen Ethernet-Ports der aufgelisteten Edge-Modelle auftreten kann.

24. März 2022, zehnte Auflage

• Problem # 84825 wurde dem Abschnitt Bekannte Probleme bei Edge/Gateway hinzugefügt.

7. Juni 2022, 11. Auflage

• Behobenes Problem #54493 wurde dem Abschnitt Behobene Probleme bei Edge/Gateway hinzugefügt. Dieses Problem wurde in den Versionshinweisen zu Version 4.2.1 in der ursprünglichen Auflage irrtümlich ausgelassen.

Behobene Probleme

Die behobenen Probleme gliedern sich in folgende Gruppen:

• Behobene Probleme bei Edge
• Behobene Probleme bei Edge/Gateway
• Behobene Probleme bei Orchestrator

Behobene Probleme bei Edge

Behoben in Version R421-20210624-GA-57011-60130

Die folgenden Probleme wurden ab der Edge-Version R421-20210407-GA behoben.

• Behobenes Problem 57011: Immer dann, wenn Segmente auf einer mit einer Hochverfügbarkeitstopologie konfigurierten Site hinzugefügt und dann gelöscht werden, kann bei einem der HA-Edges ein Ausfall des Datenebene-Diensts und bei einem Dienstausfall auf dem aktiven Edge ein HA-Failover auf der Site ausgelöst werden.

  Wenn Segmente hinzugefügt und dann von einer HA-Site gelöscht werden, besteht die Möglichkeit veralteter Segmente (d. h., die gelöschten Segmente werden möglicherweise weiterhin auf einem der Edges im HA-Paar angezeigt). Aufgrund dieser Nichtübereinstimmung bei den Segmentinformationen zwischen den HA-Edges werden alle Ereignisse, die für das veraltete Segment bestimmt sind, möglicherweise an den anderen Edge gesendet, was zu einem Ausfall des Datenebene-Diensts, einem HA-Failover, wenn sich der Dienstfehler auf dem aktiven Edge befindet, und der Generierung eines Core-Dumps, der in einem nach dem Failover ausgeführten Diagnosepaket gefunden wird, führt. Für dieses Problem gibt es keine Problemumgehung.

• Behobenes Problem 60130: Auf einer Site kann es zeitweilig zu Phasen mit hohen Paketverlusten und Konnektivitätsproblemen geben.

  Dies wird durch die API verursacht, die die ARP-Auflösung überprüft und dem Edge eine erfolgreiche ARP-Auflösung für ein Gerät liefert, während eine MAC-Adresse von 00:00:00:00 bereitgestellt wird.  Diese Adresse wird im ARP-Cache gespeichert und alle Pakete, die für das Gerät bestimmt sind, auf dem die MAC-Adresse als Null aufgeführt ist, werden verworfen. Bei diesem Problem werden viele solche erfolgreichen ARP-Instanzen mit Null-MAC-Adressen geliefert, was zu einem hohen Paketverlust und Konnektivitätsproblemen führt.

  Dieser Fix behebt Probleme mit dem zwischengespeicherten Wert von MAC-Adressen in einem Flow (die häufigste Ursache für das Problem). Dieser Fix behebt jedoch nicht das seltenere Szenario, in dem der ARP sich selbst zwischenspeichert und dann eine Null-MAC zurückgibt. Dies wird in 62552 behandelt werden. Abgesehen von einem Edge-Image mit dem Fix gibt es für dieses Problem keine Problemumgehung.

Behobene Probleme bei Edge/Gateway

Behoben in Version R421-20210407-GA

Die folgenden Probleme wurden seit der Edge-Version R420-20201218-GA und der Gateway-Version R420-20210208-GA-53243-54800 behoben.

• Behobenes Problem 51025: Wenn ein WAN-Link auf einem VMware SD-WAN Edge in schneller Folge entfernt und neu erstellt wird (d. h. „Flapping“), wird der Routentabelleneintrag für das Standard-Gateway der gerouteten Schnittstelle möglicherweise entfernt und nicht erneut angewendet.

  Wenn bei einem Edge dieses Problem vorkommt, kommt es zum „Flapping“ des Links. Der Eintrag für die Standard-Gateway-Route wird für die Schnittstelle, die diesen Link nutzt, entfernt, was zu einer leeren Routentabelle für die Schnittstelle führt. Bleibt jedoch eine leere Routentabelle, wird die Linux-Verbindungsverfolgung (conntrack) standardmäßig zur nächsten Tabelle weitergeleitet, was zu einem Egress aller Pakete über die falsch geroutete Schnittstelle führt.

• Behobenes Problem 52102: Für ein Unternehmen, das eine Hub/Spoke-Topologie verwendet, werden vorhandene Flows bei der Wiederherstellung aus einem Hub-Edge-Failover für ein bestimmtes Tupel auf einer VMware SD-WAN Spoke Edge gelöscht.

  Die Reihenfolge der Ereignisse führt zu diesem Problem, wenn ein primärer Hub-Edge vom Failover wiederhergestellt wird:
  1. Wenn der primäre Hub-Edge ausfällt, wird die Route für diesen primären Hub-Edge aus der FIB entfernt, während die Routen in der RIB beibehalten werden.
  2. Vorhandene Flows wechseln nun zum sekundären Hub-Edge.
  3. Wenn der primäre Hub wieder aktiv wird, wird sofort ein Tunnel zwischen dem primären Hub von der Spoke-Edge aus eingerichtet.
  4. Routen in der RIB, die zuvor vom primären Hub über das Gateway gelernt wurden, werden gescannt und Routen werden in der FIB installiert, die auf diesen primären Hub verweist.
  5. Der Datenverkehr wechselt zurück zum primären Hub, obwohl der primäre Hub die Routen nicht von seinem BGP-Nachbarn gelernt hat.
  6. Dadurch stimmt die Routensuche mit der Standardroute überein und der Rückverkehr wird mit einem Backhaul-Flag markiert.
  7. Der Spoke-Edge erwartet keinen Rückverkehr mit einem Backhaul-Flag, was dazu führt, dass der Datenverkehr gelöscht wird. 

  Ohne diesen Fix besteht die Problemumgehung darin, zum Hub-Edge zu navigieren und die Remote-Diagnose „Flows leeren“ für das angegebene Tupel auszuführen, und der Datenverkehr wird wiederhergestellt.

• Behobenes Problem 53415: Wenn in einem Kundenunternehmen, in dem Edge Network Intelligence (ENI) aktiviert ist, der VMware SD-WAN Edge des Unternehmens WLAN-fähig ist, zeigt die ENI-Seite möglicherweise eine falsche MAC-Adresse für den WLAN-Zugriffspunkt an, und die Zugriffspunkt-IP wird als 160.254.3.1 angezeigt.

  Das Problem ist das Ergebnis einer Fehlkonfiguration der MAC-Adresse des WLAN-Zugriffspunkts, die auf einen Wert namens „selfMacAddress“ eingestellt ist, und der IP-Adresse des Zugriffspunkts, die auf der ENI-Seite immer für 160.254.3.1 konfiguriert ist. Der Fix leitet die MAC-Adresse von der WLAN-Schnittstelle wlan0 und der IP-Adresse der Analyseschnittstelle ab.

• Behobenes Problem 53477: Wenn in einer Hochverfügbarkeitstopologie konfigurierte VMware SD-WAN Edges in ein anderes Konfigurationsprofil verschoben werden, werden die Dienste der Edges wiederholt neu gestartet.   

  Bei diesem Problem ist einer der HA-Edges so konfiguriert, dass er über mehr LAN- oder WAN-Schnittstellen als der andere HA-Edge verfügt (z. B. ist ein WAN-Port auf einem der Edges deaktiviert). Wenn diese Edges dann in ein anderes Profil verschoben werden, wird der Edge-Dienst kontinuierlich neu gestartet.

• Behobenes Problem 53651: Wenn Sie auf einer Kunden-Site, die eine erweiterte Hochverfügbarkeitstopologie verwendet, eine Konfigurationsänderung an einer VMware SD-WAN Edge-Geräteeinstellung durchführen, die einen Neustart des Edge-Diensts erfordert, können nacheinander zwei HA-Failover auftreten.

  Für eine Konfigurationsänderung der Geräteeinstellung, die einen Neustart des Edge-Diensts erfordert, aktualisiert das HA-Modul fälschlicherweise die LAN/WAN-Anzahl auf das VMware SD-WAN Gateway, bevor der Edge-Dienst während der Konfigurationsverarbeitung neu gestartet wird. Wenn der erste HA-Failover stattfindet und der Dienst des aktuellen aktiven Edge als Teil der Degradierung zum Standby neu gestartet wird, missversteht das Gateway, dass der neue Standby Edge eine bessere LAN/WAN-Anzahl hat, und sendet einen Failover-Befehl an den neu beförderten aktiven Edge, was zum zweiten Failover führt.

  Hinweis: Eine Liste der Edge-Konfigurationsänderungen, die einen Dienstneustart auslösen können, finden Sie im KB-Artikel VMware SD-WAN Edge Konfigurationsänderungen, die einen Dienstneustart auslösen können (60247)

• Behobenes Problem 53676: Auf der VMware SD-WAN Edge 3x00-Plattform können sehr kurze Phasen der Instabilität der Eingangsspannung, die nur 4 Millisekunden betragen, zum Neustart des Edge führen.

  Dieses Problem tritt in der Regel auf, wenn eine unterbrechungsfreie Stromversorgung (USV) verwendet wird, die beim Wechsel von Leitung zu Batterie eine leichte Instabilität der Ausgangsspannung aufweist. Mit dem Fix für dieses Problem wird ein Upgrade der Firmware des Edge ausgeführt, damit er 20 bis 30 ms lang eine Instabilität der Spannung toleriert, bevor der Edge neu gestartet wird.

  Hinweis: Durch das Upgrade der 3x00-Firmware wird die Upgrade-Zeit des Edge auf 3-5 Minuten verlängert, wenn für die Edge-Firmware bei Verwendung von Version 3.4.5 oder 4.0.2 zuvor kein Upgrade durchgeführt wurde.

  Für ein Edge 3x00-Modell ohne diesen Fix besteht die einzige Option des Kunden darin, eine ausgereiftere USV zu verwenden, die ohne instabile Ausgangsspannung wechseln kann. 

• Behobenes Problem 53789: In VMware SD-WAN Virtual Edges, die unter ESXi ausgeführt werden, wird alle 30 Sekunden eine falsche Fehlermeldung in /var/log/messages geschrieben.

  Die falsche Fehlermeldung sieht so aus: GuestInfoGetDiskDevice: Fehlender Festplatten-Gerätename; VMDK-Zuordnung nicht verfügbar für "/", fsName: "/dev/root". (Fehlender Festplattengerätename; VMDK-Zuordnung für „/“ nicht verfügbar.) Sie wird immer in /var/log/messages protokolliert. /var/log/messages und das gespeicherte Gegenstück /velocloud/log/messages* werden voll, und wichtigere Meldungen fallen damit aus dem Protokoll. Sie werden daher nicht erkannt, wenn das Protokoll für den betroffenen Edge geprüft wird.

• Behobenes Problem 53929: An einem Kundenstandort, der eine Topologie mit erweiterter Hochverfügbarkeit verwendet, wechseln die Datenströme von „Cloud über Gateway“ nach einem HA-Failover zu einem Pfad „Direkt zur Cloud“.

  Wenn nach einem HA-Failover der Pfad zum VMware SD-WAN Gateway nicht verfügbar ist und der Datenverkehr den VMware SD-WAN Edge erreicht, fließt der Datenverkehr als „Direkt zur Cloud“ (Direct to Cloud) statt „Cloud über Gateway“ (Cloud via Gateway). Dies kann erhebliche Auswirkungen auf Datenströme haben, die auf Dynamic Multipath Optimization angewiesen sind, wie z. B. Echtzeitverkehr (z. B. Sprache und Video), da der Direktverkehr diese Optimierungen nicht nutzt.

• Behobenes Problem 54001: Ein VMware Edge kann Datenverkehr nicht senden, nachdem eine Tx-Warteschlange auf SFP-Schnittstellen hängen geblieben ist.

  In seltenen Fällen, wenn der Edge ein ungültiges Paket (weniger als 17 Byte oder mehr als 1.526 Byte) an DPDK sendet, wird die Übertragungswarteschlange angehalten, und jeder weitere Datenverkehr wird vom Edge nicht weitergeleitet. Durch einen Neustart des Edge wird das Problem vorübergehend behoben, aber das Problem kann erneut auftreten, wenn ein ungültiges Paket vom Edge-Dienst an DPDK gesendet wird. Nur das Upgrade auf eine Version mit dem Fix vermeidet dieses Problem.

• Behobenes Problem 54493: Ein Operator- oder Partneradministrator beobachtet möglicherweise eine steigende Anzahl von Handoff Queue Drops für Edge-Datenverkehr auf einem VMware SD-WAN Gateway. 

  Bei diesem Problem hat das Gateway keine CPU-Auslastungsprobleme oder DPDK-Ausfälle. Das Problem wird durch ein Steuerungsebenenereignis (z. B. Routenneuberechnung) ausgelöst, und das Gateway beginnt, Edge-Pakete während der Übergabe an verschiedene Threads in der Gateway-Pipeline zu verwerfen. Die Ursache des Problems ist eine unzureichende Warteschlangengröße für die Paketpufferung.

• Behobenes Problem 54694: Wenn ein Kunde die SNMP-Abfrage verwendet, liefert die SNMP-Überwachung ungenaue Messungen für ausgehenden Datenverkehr.

  Der SNMP-Aufruf für IF-MIB::ifHCOutOctets liefert TX-Pakete anstelle von TX-Bytes, was zu ungenauen Zählungen der ausgehenden Oktette führt. Und das wiederum beeinträchtigt die Fähigkeit des Kunden zur Überwachung seines Unternehmens. Dieses Problem ist das Ergebnis des snmpagent-Prozesses, der TX-Pakete gegenüber TX-Byte überwacht.

• Behobenes Problem 55949: In einigen Szenarien wird ein Nicht-SD-WAN-Ziel (NSD)-über-Gateway-Tunnel entfernt und für eine gewisse Zeit nicht wiederhergestellt.

  Wenn ein VMware SD-WAN Gateway eine erneute IKE-Schlüsselerstellung mit einem anderen NSD-Ziel auslöst und die versuchte erneute Schlüsselerstellung aufgrund eines Netzwerkproblems während der Aushandlung nicht erfolgreich ist, wird die erneute IKE-Schlüsselerstellung fortlaufend erneut versucht. Wenn ein Link wieder eingerichtet wird, ist es möglich, dass ein Dead Peer Detection (DPD)-Ereignis eine neu erstellte Phase 1-Sicherheitsverbindung (Security Association, SA) löscht. Dies führt dazu, dass die IPsec-SA zusammen mit einigen Peers gelöscht wird, meistens mit Zscaler. Wenn ein Peer eine IPsec-SA löscht, kann sie vom Gateway nicht erkannt werden, und ein Tunnel ist bis zur nächsten erneuten Schlüsselerstellung nicht mehr erreichbar.  Ohne den Fix besteht die einzige Möglichkeit, diese erneute Schlüsselerstellung zu erzwingen, im Aktivieren des Tunnels durch Deaktivieren und erneutes Aktivieren des betroffenen NSD über den VMware SD-WAN Orchestrator.

• Behobenes Problem 56149: Nach der Aktivierung von Dynamic Cost Calculation (DCC) in einem Kundenunternehmen, das BGP verwendet, zeigt ein VMware SD-WAN Edge möglicherweise einen falschen Routenvoreinstellungswert für automatisch korrigierte Routen an, wenn die BGP-Route für die Underlay-Route nicht mehr korrekt ist.

  Die Auswirkungen auf den Kunden sind asymmetrisches Routing aufgrund der falschen Remoteroutenvoreinstellung, was zu einer höheren Latenz und einer schlechten Leistung auf allen Kundenanwendungen führt. Nachdem DCC aktiviert wurde, sollte der neue RIB-Voreinstellungswert (Routing Information Base) auf der Route aktualisiert und die Route erneut beim VMware SD-WAN Gateway mit dem neuen RIB-Voreinstellungswert annonciert werden, der dann an alle Edges kommuniziert wird. Die Ursache des Problems ist, dass bei der automatischen Korrektur der Route diese RIB-Einstellung in der FIB-Tabelle des Peer-Edge nicht aktualisiert wird, wodurch der alte Pre-DCC-Wert beibehalten wird. 

• Behobenes Problem 56346: Ein Kunde kann verworfene Handoff Queue Drops beobachten, wenn er die Seite Monitor > System eines VMware SD-WAN Edge betrachtet.

  Eine Aktualisierung für das VCRP (VeloCloud Route Protocol)-Routenereignis führt zu Handoff Queue Drops im VCMP-(VeloCloud Management Plane)-Daten-Thread.  Das liegt daran, dass beim Empfang eines Routen-Updates alle Routen im jeweiligen Segment ungültig werden. Dies führt zu neuen Routensuchvorgängen im Datenpfad. Eine bestimmte Funktion, die als Teil der Routensuche aufgerufen wird, führt einen kostspieligen Hash-Enumerate-Vorgang durch, der zu einer um 40 % erhöhten VCMP-Daten-Thread-Auslastung führt.  In dem Fall, in dem dieses Problem vor Ort gefunden wurde, war die Menge der verworfenen Handoff Queue Drops nicht ausreichend, um die Netzwerkleistung zu beeinträchtigen.

• Behobenes Problem 56483: Paketverlust-, Jitter- und Latenzwerte werden in der WAN-Link-Live-Überwachung auf einem VMware SD-WAN Orchestrator auf dem Bildschirm „Überwachen (Monitor) > Transport“ nicht angezeigt.

  Ein Benutzer kann keine Echtzeitdaten zu Paketverlust, Jitter oder Latenz für einen bestimmten WAN-Link unter Überwachen (Monitor) > Transport abrufen, da das Diagramm als flache Linie angezeigt wird. Außerdem werden auf dem Bildschirm Überwachen (Monitor) > Edge > Übersicht (Overview) alle Werte für Verlust, Jitter und Latenz als „0“ angegeben. Verlaufsstatistiken werden unter Überwachen (Monitor) > Transport korrekt angezeigt. Dieses Problem betrifft nur Statistiken im „Live-Modus“. 

• Behobenes Problem 58535: Wenn ein Kunde eine statusbehaftete Firewall konfiguriert und unter Network & Flood Protection auch eine Negativliste konfiguriert hat, setzt sich die Negativliste automatisch auf die aggressivsten Einstellungen für neue Verbindungen und die statusbehaftete Firewall blockiert jede neue Verbindung.

  Das Problem hat eine kritische Auswirkung für Kunden, die eine statusbehaftete Firewall verwenden, da es die Negativlistenfunktion unbrauchbar macht. Sobald die Negativlistenfunktion aktiviert ist, werden die Firewall-Ereignisse mit den Protokollen gefüllt. „FLOOD_ATTACK_DETECTED“ und „Blacklisting source: xxx.xxx.x.x exceeded CPS limit: 0 per source“ (Quelle auf Negativliste: xxx.xxx.x.x hat den CPS-Grenzwert überschritten: 0 pro Quelle).  Dabei ist die IP-Adresse die Verwaltungs-IP-Adresse des Edge und CPS = Verbindungen pro Sekunde (Connections Per Second). Der Schwellenwert für neue Verbindungen wird auf 0 % gesetzt. Das bedeutet, dass jeder Verbindungsversuch die Negativliste zum Blockieren aller Verbindungen auslöst.  Der Standardwert für den Schwellenwert für neue Verbindungen ist 25 %.

• Behobenes Problem 56876: Bei VMware SD-WAN Edges kann ein Problem im Zusammenhang mit der Arbeitsspeicherverwaltung auftreten und eine Kernel-Panik ausgelöst werden, die zu einem Edge-Neustart führt.

  Dieses behobene Problem umfasst Fehlerbehebungen für zwei verschiedene Szenarien im Zusammenhang mit der Arbeitsspeicherverwaltung auf einem Edge, bei der eine Kernel-Panik ausgelöst wird:

  1. Im ersten Szenario, in dem ein Edge die dynamische Weiterleitung von Zweigstelle zu Zweigstelle verwendet, werden die dynamischen Tunnel erstellt, und ein kleiner Teil des Arbeitsspeichers wird für das Speichern von Leistungsindikatoren pro Peer reserviert. Wenn der dynamische Tunnel aus dem Netzwerk bereinigt wird, wird dieser Arbeitsspeicher nicht bereinigt, um die Hochfahrzeit bei der nächsten Verbindung desselben Peers zu optimieren. Auf einem kleinen Edge (z. B. Edge 500, 510, 520, 610), der im Laufe der Zeit eine Verbindung zu einer großen Anzahl unterschiedlicher Ziele herstellt, kann dies schließlich den verfügbaren Arbeitsspeicher ausschöpfen und eine Kernel-Panik und einen Edge-Neustart auslösen.  Ohne diesen Fix muss ein Benutzer den Edge-Dienst proaktiv neu starten, wenn die Arbeitsspeichernutzung im Bildschirm Überwachen (Monitor) > System des Edge auf dem VMware SD-WAN Orchestrator mehr als 90 % der Systemzustandsstatistiken beträgt.
  2. Beim Beheben des Arbeitsspeicherverlusts, der durch die dynamische Weiterleitung von Zweigstelle zu Zweigstelle verursacht wird, wurde festgestellt, dass malloc_trim (ein Prozess, der fragmentierten Arbeitsspeicher freigibt) nicht ordnungsgemäß aufgerufen wurde. Dieser Vorgang wurde auch für diesen Fix geändert. Wenn Sie malloc_trim nicht ordnungsgemäß aufrufen, kann dies zu einem anderen Problem führen und sich auf jeden Edge (nicht nur kleinere Edges) auswirken, wobei es nicht erforderlich ist, dass der Edge die dynamische Weiterleitung von Zweigstelle zu Zweigstelle verwendet, und Überwachen (Monitor) > System zeigt keine Arbeitsspeichernutzung an, die 90 % überschreitet. Dieses Szenario tritt viel wahrscheinlicher auf, wenn der Edge eine hohe Anzahl von Flows aufweist.
• Behobenes Problem 56931: Ein Kundenstandort, der ein Nicht-SD-WAN-Ziel (NSD) über Edge konfiguriert hat, kann falsche Edge-Zustandsstatistiken auf der VMware SD-WAN Orchestrator-Benutzeroberfläche anzeigen.

  Wenn ein NSD vom Edge aus konfiguriert wird, sendet der SD-WAN-Dienst beim ersten Mal nach einem Neustart eine Integritätsstatistik vom Edge an den Orchestrator mit einer Startzeit 0. Dies führt dazu, dass der Orchestrator nach einem Neustart des Edge die falschen Daten anzeigt.

• Behobenes Problem 57063: Wenn sich die Start- und Endzeit für einen API-Aufruf exakt mit der Zeit überschneidet, zu der ein VMware SD-WAN Edge Daten in den VMware SD-WAN Orchestrator exportiert, werden zwei Verhaltensweisen beobachtet: a) API-Aufrufe von Link-Metriken, die von der Orchestrator-Benutzeroberfläche oder SDK-Clients ausgegeben werden, beobachten einen höheren Wert als den normalen, der in der Antwort zurückgegeben wird. b) API-Aufrufe der Link-Serie, die über die Orchestrator-Benutzeroberfläche oder SDK-Clients ausgegeben werden, beobachten, dass der Wert der letzten Zeitserie höher als normal ist.

  Ein Benutzer könnte diese Diskrepanz beobachten, wenn er die Registerkarte Überwachen (Monitor) > Transport auf der Orchestrator-Benutzeroberfläche aufruft oder wenn ein SDK-Client getEdgeLinkMetrics-, getEdgeLinkSeries- oder getAggregateLinkMetrics-API-Aufrufe durchführt.  In beiden Fällen würde dies in Anbetracht der in der Symptombeschreibung angegebenen Anforderungen selten beobachtet werden.

Behobene Probleme bei Orchestrator

Orchestrator-Version R421-20211216-GA

Orchestrator-Version R421-20211216-GA wurde am 20.12.2021 veröffentlicht. Dieser Orchestrator-Build behebt CVE-2021-44228, die Apache Log4j-Schwachstelle, durch Aktualisieren auf die Log4j-Version 2.16.0. Weitere Informationen zur Apache Log4j-Schwachstelle finden Sie im VMware Security Advisory VMSA-2021-0028.5.

___________________________________________________________________

Behoben in Version R421-20210415-GA

Die folgenden Probleme wurden ab der Orchestrator-Version R421-20210326-GA behoben.

• Behobenes Problem 61312: Bei einem VMware SD-WAN Orchestrator kann ein Problem auftreten, bei dem Routen nicht mehr aktualisiert werden und die CPU-Auslastung des Orchestrators nahe 100 % liegt, insbesondere nach einem Upgrade des Orchestrators.

  Dieses Problem tritt auf, wenn ein Edge mehr als 2K Routen-Updates an die Routing-API des Orchestrators sendet. In den Szenarien, in denen der Orchestrator nicht in der Lage ist, alle Routen, die mit einem bestimmten API-Aufruf gesendet wurden, innerhalb von 60 Sekunden zu verarbeiten, führt dies zu einer Zeitüberschreitung für diesen Aufruf, was wiederum dazu führt, dass der API-Aufruf vollständig abgelehnt wird. Der Edge empfängt diese Ablehnung und versucht, dieselbe Anzahl von mehr als 2K Routen erneut an den Orchestrator zu pushen, was zu demselben Szenario wie zuvor führt und eine Schleife erzeugt, die die vCPU-Ressourcen des Orchestrators überlastet. Wenn dieses Problem auftritt, kann die Verarbeitung von Routen-Updates verhindert werden. 

  Um dieses Problem zu beheben, wurden zwei Systemeigenschaften hinzugefügt:

  edge.learnedRoute.maxRoutePerCall  Diese Eigenschaft stellt sicher, dass nur eine begrenzte Anzahl von Routen von einem Edge verarbeitet wird. Wenn der Eigenschaftswert „200“ lautet, werden 200 Routen pro Edge-Anforderung verarbeitet, was sicherstellt, dass eine Bestätigung rechtzeitig an den Edge gesendet wird.

  vco.learnedRoute.simultaneous.maxQueue  Diese Eigenschaft stellt sicher, dass nur die konfigurierte Anzahl von Edges gleichzeitig Routen-Anforderungen in der Warteschlange haben können. Wenn der Eigenschaftswert „8“ lautet, dürfen nur 8 Edges gleichzeitig Routen-Anforderungen senden, und diejenigen, die den konfigurierten Wert überschreiten, werden sofort zurückgewiesen, bevor die Routen bearbeitet werden.

______________________________________

Behoben in Version R421-20210326-GA

Die folgenden Probleme wurden ab Orchestrator Version R420-20210306-GA behoben.

• Problem 20900: Wenn der MaxMind-Geolokalisierungsdienst aktiviert ist und den MaxMind-Server nicht erreichen kann, funktionieren neue Aktivierungen von VMware SD-WAN Edge nicht.

  Der Edge baut zur Aktivierung eine HTTPS-Verbindung zum VMware SD-WAN Orchestrator auf. Die Standardzeitüberschreitung für die Anfrage beträgt 120 Sekunden und für die Proxyverbindung 60 Sekunden. Während der Orchestrator versucht, den Standort des Edge (IPv4-Remoteadresse) zu ermitteln, wartet der Upload auf die Antwort vom Maxmind-Dienst, um mit der Aktivierung fortzufahren. Daher wartet NGINX nach 60 Sekunden auf die Antwort des Upload-Dienstes und schließt die Verbindung. Die Aktivierung scheitert somit an einer 504-Zeitüberschreitung vom NGINX. 

  Mit der neuen Systemeigenschaft service.maxmind.timeout.seconds wird der Maxmind-API-Aufruf mit einer benutzerdefinierten Zeitüberschreitung durchgeführt. Wenn die Zeitüberschreitung erreicht ist, fährt der Aufruf mit dem Aktivierungsworkflow fort und somit wird der Edge erfolgreich aktiviert.

• Behobenes Problem 49997: Wenn der Analysemodus von VMware Edge Network Intelligence auf einem VMware SD-WAN Orchestrator aktiviert ist, kann ein neu angelegter Operator-Benutzer keine Verbindung mit den Analysebereichen der Orchestrator-Benutzeroberfläche herstellen.

  Operator-Benutzer, die nach der Aktivierung des Analysemodus erstellt wurden, sollten auf die VMware Edge Network Intelligence-Benutzeroberfläche aller Unternehmenskunden zugreifen können, die den Supportzugriff aktiviert haben, und das ist bei diesem Problem nicht der Fall.

• Behobenes Problem 52379: Der VMware SD-WAN Orchestrator sendet eine E-Mail mit der Meldung „Edge nicht aktiv“ (Edge Down), wenn sich der VMware SD-WAN Edge innerhalb des konfigurierten Verzögerungsintervalls neu einrichtet.

  Administratoren können fälschlicherweise benachrichtigt werden, dass ein Edge in ihrem Netzwerk ausgefallen ist, obwohl sie eine Verzögerung konfiguriert haben, damit ein Edge für eine bestimmte Zeit ausgefallen sein kann, bevor die Benachrichtigung ausgelöst wird.

• Behobenes Problem 53525: Wenn Sie die neue Benutzeroberfläche auf einem VMware SD-WAN Orchestrator verwenden und die Edge-Übersichtsseite anzeigen, wird in der Spalte „Links“ nicht der Status der Verbindung angezeigt (z. B. „Backup“, „Standby“).

  Diese Informationen zum Verbindungsstatus werden in der alten Benutzeroberfläche korrekt angezeigt. Mit diesem Fix werden sie auch in der neuen Benutzeroberfläche wie erwartet angezeigt.

• Behobenes Problem 53652: Wenn ein Kundenunternehmen, das eine benutzerdefinierte Anwendungszuordnung verwendet, von 3.x auf 4.x aktualisiert wird, beobachtet der Kunde möglicherweise zufällige Namen für seine benutzerdefinierten Anwendungen, die vor dem Upgrade erstellt wurden.

  Wenn eine benutzerdefinierte Anwendungszuordnung mit einer Anwendungs-ID (appId) konfiguriert wird, die bereits als Teil einer standardmäßigen anfänglichen Anwendungszuordnung vorhanden ist, zeigt der VMware SD-WAN Orchestrator immer den Anzeigenamen der standardmäßigen anfänglichen Anwendungszuordnung an und überschreibt den vom Kunden definierten Namen. Dies gilt auch, wenn der Orchestrator von einer niedrigeren Version auf eine höhere Version aktualisiert wird und die standardmäßige anfängliche Anwendungszuordnung der höheren Version eine appId hat, die mit einer appId der benutzerdefinierten Anwendungen, die in einer niedrigeren Version erstellt wurden, in Konflikt steht.  Nach dem Orchestrator-Upgrade zeigen diese benutzerdefinierten Anwendungen einen falschen Anzeigenamen an, der dem Anzeigenamen der appId für die standardmäßige anfängliche Anwendungszuordnung der höheren Version entspricht.

• Behobenes Problem 53752: Die Migration eines Kundenunternehmens schlägt fehl, wenn sie von einem VMware SD-WAN Orchestrator mit einer Version 3.4.x zu einem Orchestrator mit Version 4.2.0 versucht wird.

  Das letzte Enterprise-Migrationstool unterstützte das Release 4.2.x nicht und dies war die Ursache für Migrationsfehler.

• Behobenes Problem 53857: Eine VMware SD-WAN Orchestrator-Bereitstellung, die ein KVM-Image basierend auf Release 4.0.0 verwendet, schlägt fehl.

  Der Grund für den Fehler ist, dass das KVM-Image eine falsche Größe des virtuellen Laufwerks hat und die Volumes nicht auf die erforderliche Größe erweitert werden.  Bei einer Bereitstellung erweitern die Orchestrator-Skripte automatisch die Orchestrator-Volumes auf 80 % der maximalen Größe der zugrunde liegenden Festplatten (physische Volumes).  In diesem Fall ist die Erweiterung aufgrund der falschen virtuellen Größe für die Anforderungen der Orchestrator-Datenbank unzureichend und der Einsatz schlägt fehl.  Es ist möglich, einen Orchestrator mit einem älteren Build ohne diesen Fix einzusetzen, aber die Volumes müssen manuell in der Größe angepasst werden.

• Behobenes Problem 53987: Auf einem VMware SD-WAN Orchestrator ist das Edge-Ereignis „Link-MTU erkannt“ auf der Orchestrator-Benutzeroberfläche nicht durchsuchbar.

  Dieses Problem wurde auf Orchestrator-Instanzen mit Version 4.0.x und höher beobachtet.  Bei einer Ereignissuche in der Orchestrator-Benutzeroberfläche auf der Seite „Events“ ist „Link-MTU erkannt“ nicht in der Ereignisliste für den Filter verfügbar, was es schwierig macht, dieses Ereignis als Teil einer Fehlersuche zu isolieren.

• Behobenes Problem 54035: Wenn der Analysemodus von VMware Edge Network Intelligence aktiviert ist, werden Pakete, die für den syslog-Dämon, den aruba-Dämon und den snmptrap-Dämon bestimmt sind, auf dem VMware SD-WAN Edge verworfen, und diese Daten werden nicht im Edge Network Intelligence-Viewer angezeigt.

  Die für die Edge-Network-Intelligence-Dämonen (syslogd, amond und snmptrapd) bestimmten Pakete werden im Edge-Dataplane-Prozess aufgrund fehlender entsprechender iptable-Regeln verworfen. Infolgedessen werden die entsprechenden Statistiken nicht im Edge Network Intelligence-Backend empfangen.

• Behobenes Problem 55259: Wenn ein Administrator einen neuen VMware SD-WAN Edge auf der VMware SD-WAN Orchestrator-Benutzeroberfläche erstellt, fehlt das Feld „Standort festlegen“ (Set Location).

  Bei diesem Problem kann der Administrator den Edge erstellen, aber ohne Standortinformationen. Der Orchestrator kann keine automatische Geolokalisierung für den Edge durchführen und die richtigen Gateways zuweisen.  Der Administrator muss nach dem Erstellen des Edge einen zusätzlichen Schritt ausführen, um die Edge-Standortinformationen auf der Seite Konfigurieren > Edge > Edge-Übersicht (Configure > Edge > Edge Overview) auszufüllen.

• Behobenes Problem 55871: Einige API-Aufrufe an REST APIv2 (/sdwan) HTTP führen dazu, dass der Server HTTP 500-Fehler produziert.

  In einigen Fällen, in denen die Kundendaten nicht genau dem Schema entsprechen, das die API erwartet, produziert die API einen HTTP 500-Fehler, anstatt Daten zurückzugeben, die nicht mit dem dokumentierten API-Schema übereinstimmen. Dieses Verhalten war auf eine Designentscheidung zurückzuführen, die inzwischen überarbeitet wurde. Aufrufe von „GET /enterprises“, „GET /enterprises/{enterpriseLogicalId}/edges“ und „GET /enterprises/{enterpriseLogicalId}/clientDevices“ sind bekanntermaßen betroffen.

• Behobenes Problem 56763: Wenn auf einem VMware SD-WAN Orchestrator mit der Version 4.x oder höher mit aktivierten Berichten ein Bericht aus irgendeinem Grund nicht generiert werden kann, werden alle nachfolgenden Berichte für alle Kunden, die Orchestrator verwenden, ebenfalls erst dann generiert, wenn der Backend-Dienst vom Orchestrator neu gestartet wird.

  Dieses Problem wirkt sich erheblich auf einen betroffenen Orchestrator aus, da alle Kunden, die den Orchestrator verwenden, erst dann Berichte erhalten können, wenn der Orchestrator-Back-End-Dienst neu gestartet wird. Dieses Problem wird durch einen einzelnen Berichtsfehler verursacht, der den Berichtsdienst in einen fehlerhaften Zustand versetzt, von dem er außerhalb des Neustarts des Backend-Diensts auf dem Orchestrator nicht wiederhergestellt werden kann.  Dies liegt daran, dass die neue Berichterstellung nicht unabhängig von der vorherigen Berichterstellung erfolgt.  Der Fix stellt sicher, dass der Berichtsdienst unabhängig von einem Fehler bei der Berichtserstellung weiterhin neue Berichte erzeugt.

• Behobenes Problem 56824: Auf einem VMware SD-WAN Orchestrator mit Release 4.2.x schlägt die Zustellung von Warnungen an Webhook-Empfänger fehl, wenn die Empfänger-URL eine explizite Portnummer enthält.

  Benutzer, die zuvor Webhook-Empfänger-URLs konfiguriert hatten, die explizite Portnummern enthielten, können beobachten, dass die Warnmeldung an diese Empfänger auf unbestimmte Zeit fehlschlägt. Ohne den Fix in diesem Build müsste ein Administrator einen Reverse-Proxy konfigurieren, um Anfragen an den ursprünglichen Webhook-Empfänger weiterzuleiten, und die Webhook-Empfänger-URL so aktualisieren, dass sie auf den Reverse-Proxy verweist.

• Behobenes Problem 56896: Beim Benutzer kann es zu API-Fehlern und Gateway-Zeitüberschreitungen kommen.

  Dieses Problem tritt auf, wenn der Festplattenspeicher eines VMware SD-WAN Orchestrator aufgrund einer Ansammlung von Dateien voll wird. Diese Anhäufung tritt auf, weil es eine Möglichkeit gibt, die Verarbeitung von Flow-Statistiken für einen VMware SD-WAN Edge oder eine Liste von Edges zu deaktivieren, die einer Sperrliste-/Negativliste-Funktion ähnelt. Obwohl die Flow-Verarbeitung für diese Edges übersprungen wird, besteht das Problem darin, dass die Dateien auf der Festplatte des Orchestrators verbleiben, ohne gelöscht zu werden. In dem vor Ort gefundenen Fall dieses Problems gab es eine ausreichende Überwachung, um das Problem abzufangen und Probleme bei der Benutzererfahrung zu vermeiden, aber bei einem Orchestrator, bei dem es weniger Überwachung gab, könnte dies den Kundenverkehr beeinträchtigen. Ohne diesen Fix müsste ein Orchestrator-Operator Dateien auf dem Festplattenspeicher des Orchestrators mit einem Zeitstempel von mehr als 24 Stunden manuell löschen.

• Behobenes Problem 56909: Auf einem VMware SD-WAN Orchestrator, der Release 4.x verwendet, kann die Berichterstellung fehlschlagen, wenn ein Backup-Link enthalten ist.

  Wenn ein Link keine Linkstatistikdatensätze hat, wird bei der Berichterstellung ein Fehler ausgegeben.  Eine Verbindung, die auf Backup eingestellt ist, erzeugt keine Verbindungsstatistik, wenn sie während des für den Bericht ausgewählten Zeitraums strikt auf Backup bleibt. Ohne diesen Fix ist die einzige Möglichkeit, einen Bericht zu erstellen, die Abwahl des Backup-Links während des Erstellens eines Berichts, damit der Link einige statistische Daten für seinen Datensatz hat.

• Behobenes Problem 57087: Wenn der Benutzer versucht, das Profil eines VMware SD-WAN Edge über den Bildschirm „Konfigurieren (Configure) > Edge“ zu wechseln, beobachtet der Benutzer einen Validierungsfehler, der ein Benachrichtigungsfeld mit einer generischen Fehlermeldung anstelle des tatsächlichen Grundes enthält.

  Der angezeigte generische Fehler lautet „Fehler beim Verarbeiten von Element. Versuchen Sie es erneut (Error processing item. Please try again)“. Um den eigentlichen Grund des Validierungsfehlers zu finden, musste der Benutzer die Debugging-Konsole eines Webbrowsers überprüfen. Nach dem Fix wird der entsprechende Validierungsfehler/Grund für das Scheitern angezeigt.

• Behobenes Problem 58627: Benutzer, die für den Empfang von Warnungen konfiguriert sind, erhalten möglicherweise eine „Verbindung aktiv“-(Link Up)-Warnung, obwohl die Verbindung in Wirklichkeit unterbrochen ist.

  Nachdem ein Link als „inaktiv“ (Down) markiert wurde, kann es vorkommen, dass Statistiken für diesen Link, die vor dem Ausfall des Links erstellt wurden, bis zu einer Minute nach dem Ereignis nicht an den VMware SD-WAN Orchestrator gesendet werden.  Sobald der Orchestrator diese verzögerten Linkstatistiken empfängt, wird ihm vorgegaukelt, dass der Link wieder in Betrieb ist, und er löst daher einen „Verbindung aktiv“-(Link Up)-Warnung aus, wenn die Alarmeinstellungen aggressiv sind (z. B. 0 Minuten Verzögerung).  Der Fix stellt sicher, dass der Orchestrator verzögerte Verbindungsstatistiken nicht als Hinweis interpretiert, dass der Link jetzt eingerichtet ist.

• Behobenes Problem 59094: Wenn ein Operator versucht, ein VMware SD-WAN Orchestrator-Upgrade vorzunehmen, gibt das Aktualisierungsskript keine ordnungsgemäße Warnmeldung über die Anforderungen für die Schemaaktualisierung aus.

  Wenn ein Operator den Schritt zum Anwenden von Schemaänderungen auf die größeren Tabellen verpasst, kann es zu einem Fehler bei den Orchestrator-Diensten kommen.  Außerdem gibt es keine einfache Möglichkeit, herauszufinden, welche Änderungen fehlen. Dieser Fix behebt das Problem, dass bei einem Neustart des Backend-Dienstes alle fehlenden Schemaänderungen, die für eine große Tabelle erforderlich sind, neu generiert werden.

• Behobenes Problem 59967: Wenn ein Upgrade des VMware SD-WAN Orchestrator auf eine Version 4.2.x oder höher erfolgt ist und ein Operator-Benutzer versucht, auf die Seiten „Konfigurieren > Business Policy“ (Configure > Business Policy) oder „Konfigurieren > Firewallrichtlinie“ (Configure > Firewall policy) zuzugreifen, wird die Seite nicht geladen und der Benutzer erhält eine Fehlermeldung.

  Die Fehlermeldung lautet „Ein unerwarteter Fehler ist aufgetreten“ (An unexpected error has occurred). Dies betrifft Operator-Benutzer, nicht Partner- oder Kundenadministratoren. Die Seiten werden aufgrund einer fehlenden READ: OBJECT_GROUP-Berechtigung für Operatoren nicht geladen, d. h., der Orchestrator erkennt nicht, dass ein Operator über die erforderlichen Berechtigungen für den Zugriff auf die Seiten „Business Policy“ und „Firewall“ verfügt.

Bekannte Probleme

Bestehende Probleme in Version 4.2.1

Die bekannten Probleme gliedern sich in folgende Gruppen:

• 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 25855:

  Ein großes Konfigurations-Update auf dem Partner-Gateway (z. B. 200 BGP-aktivierte 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.  

• Problem 25997:

  Es ist möglicherweise ein Neustart des VMware SD-WAN Edge erforderlich, um den Datenverkehr in einer gerouteten Schnittstelle, die in einen Switch-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.  

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

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

• Problem 32731:

  Über OSPF annoncierte bedingte Standardrouten können nicht ordnungsgemäß zurückgenommen werden, wenn die Route deaktiviert ist. Durch erneutes Aktivieren und Deaktivieren der Route wird diese 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.

• Problem 32981:

  Hartkodierungsgeschwindigkeit und Duplex auf einem DPDK-fähigen Port erfordern möglicherweise einen Neustart des VMware SD-WAN Edge, damit die Konfigurationen wirksam werden, da dies die Deaktivierung von DPDK erfordert.

• 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 35807:

  Eine DPDK-geroutete Schnittstelle wird vollständig deaktiviert, wenn die Schnittstelle vom VMware SD-WAN Orchestrator aus deaktiviert und wieder aktiviert wird. 

• 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-fähigen 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 39134:

  Die Systemzustandsstatistik „CPU-Prozentsatz (CPU Percentage)“ wird unter „Überwachen (Monitor) > Edge > System“ für den VMware SD-WAN Edge und unter „Überwachen (Monitor) > Gateways“ für das VMware SD-WAN Gateway möglicherweise nicht korrekt gemeldet.

  Problemumgehung: Benutzer sollten verworfene Handoff Queue Drops für die Überwachung der Edge-Kapazität nicht des CPU-Prozentsatzes verwenden.

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

• Problem 39624:

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

• Problem 39659:

  Bei einer Site, die für erhöhte Hochverfügbarkeit mit einem WAN-Link an jedem VMware SD-WAN Edge konfiguriert ist, ist bei Ausfall des HA-Kabels möglicherweise ein Split-Brain-Zustand (aktiv/aktiv) möglich, wenn am Standby-Edge nur PPPoE und am aktiven Edge nur Nicht-PPPoE angeschlossen ist.

• Problem 39753:

  Das Deaktivieren von dynamischem Zweigstelle-zu-Zweigstelle-VPN kann zur Folge haben, dass zurzeit mit dynamischem Zweigstelle-zu-Zweigstelle gesendet werden, unterbrochen werden.

• Problem 40096:

  Wenn ein aktivierter VMware SD-WAN Edge 840 neu gestartet wird, besteht die Möglichkeit, dass in den Edge eingestecktes SFP-Modul den Datenverkehrs nicht mehr weiter gibt, 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 40421:

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

• 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 42388:

  Auf einem VMware SD-WAN Edge 540 wird ein SFP-Port nicht erkannt, nachdem die Schnittstelle vom VMware SD-WAN Orchestrator aus deaktiviert und wieder aktiviert wurde.

• Problem 42488:

  Wenn auf einem VMware SD-WAN Edge, auf dem VRRP für einen Switch- oder gerouteten Port aktiviert ist, das Kabel vom Port getrennt und der Edge-Dienst neu gestartet wird, werden die mit dem LAN verbundenen Routen annonciert.

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

• Problem 42872:

  Durch die Aktivierung der Profilisolierung in einem Hub-Profil, dem ein Hub-Cluster zugeordnet ist, werden die Hub-Routen nicht in der Routing Information Base (RIB) widerrufen.

• 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) in VMware SD-WAN Orchestrator.

• Problem 44526: Für ein Unternehmen, in dem zwei verschiedene Sites ihre VMware SD-WAN Edges als Hubs bereitstellen, während sie auch eine Hochverfügbarkeitstopologie verwenden, und jede Site die andere Hub-Site als Hub in ihrem Profil verwendet.  Wenn eine der Hub-Sites ein HA-Failover auslöst, kann es bis zu 30 Minuten dauern, bis beide Hub-Edges miteinander Tunnel wiederherstellen. 

  Wenn bei einem HA-Failover beide Hub-Edges versuchen, gleichzeitig einen Tunnel miteinander zu initiieren, und keine der beiden dem Peer antwortet, erfolgt der Paketaustausch zwischen den beiden Hubs zwar, aber IKE ist nie erfolgreich. Dies führt zu einem Deadlock, der nach maximal 30 Minuten automatisch beendet wird. Das Problem tritt zeitweise und nicht nach jedem HA-Failover auf. 

  Problemumgehung: Um dieses Problem zu verhindern, sollte der Kunde nur eine der beiden HA-Hub-Sites so konfigurieren, dass die andere Hub-Site als Hub für sich selbst verwendet wird.  Wenn beispielsweise zwei HA-Hub-Sites (Hub1 und Hub2) vorhanden sind, kann Hub1 Hub2 als Hub für sich selbst in seinem Profil haben, Hub2 darf jedoch Hub1 nicht als Hub in seinem Profil verwenden.

• Problem 44832:

  Datenverkehr von einem Nicht-SD-WAN-Ziel über Edge an ein anderes Nicht-SD-WAN-Ziel über (d. h. Hairpinning oder NAT-Loopback) wird auf dem VMware SD-WAN Edge verworfen.

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

• 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 46918:

  Bei einem VMware SD-WAN Spoke Edge mit Version 3.4.2 wird die ID des privaten Netzwerks eines Cluster-Hub-Knotens nicht ordnungsgemäß aktualisiert.

• Problem 47084:

  Ein VMware SD-WAN Hub Edge kann nicht mehr als 750 PIM-Nachbarn (Protocol-Independent Multicast) einrichten, wenn er über 4000 angeschlossene Spoke Edges verfügt.

• Problem 47244:

  Auf einem aktivierten VMware SD-WAN Edge 6x0 mit aktiviertem DPDK und einigen Kupfer-SFPs zeigt der Edge die Verbindung als aktiv (UP) an, auch wenn kein Kabel auf der VMware SD-WAN Orchestrator-Benutzeroberfläche eingesteckt ist.

  Problemumgehung: Durch das Einstecken und Abziehen eines Kabels wird der False-Zustand beseitigt.

• Problem 47355:

  Wenn dieselbe Route über lokales Underlay-BGP, Hub-BGP gelernt wird und/oder im Partner-Gateway statisch konfiguriert wird, ist die Sortierreihenfolge der Routen falsch, wobei Hub-BGP gegenüber dem Underlay-BGP bevorzugt wird.

• Problem 47664:

  In einer Hub- und Spoke-Konfiguration, bei der Zweigstelle-zu-Zweigstelle über Hub-VPN deaktiviert 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 47787:

  Ein VMware SD-WAN Spoke Edge, der mit einer Backhaul-Business Policy konfiguriert ist, sendet fälschlicherweise Datenverkehr über den VMware SD-WAN Gateway-Pfad, wenn dieser Flow vom Hub Edge zu diesem Spoke Edge initiiert wird.

• Problem 48166:

  Ein VMware SD-WAN Virtual Edge auf KVM wird nicht unterstützt, wenn ein Ciena-Virtualisierungsbetriebssystem verwendet wird, und am Edge kommt es zu wiederkehrenden Datenebene-Dienst-Ausfällen.

• Problem 48175:

  Ein VMware SD-WAN Edge mit Version 3.4.2 bildet eine OSPF-Nachbarschaft in einem nicht globalen Segment, wenn das nicht globale Segment über eine Schnittstelle verfügt, die im gleichen IP-Bereich konfiguriert ist wie eine Schnittstelle, die im globalen Segment konfiguriert ist.

• 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 48666:

  Die Path MTU-Berechnung des IPSec-Front-Gateways berücksichtigt den 61-Byte-IPSec-Overhead nicht, was zu einer höheren MTU-Ankündigung für den LAN-Client und anschließender IPSec-Paketfragmentierung führt.

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

• Problem 49172:

  Eine richtlinienbasierte NAT-Regel, die mit demselben NAT-Subnetz für zwei verschiedene VMware SD-WAN Edges konfiguriert ist, funktioniert nicht.

• Problem 49738:

  In einigen Fällen, in denen ein VMware SD-WAN Spoke Edge für die Verwendung mehrerer Hub Edges konfiguriert ist, kann der Spoke Edge möglicherweise keine Tunnel zu einem der in der Hub-Liste konfigurierten Hubs bilden.

• Problem 50518:

  Auf einem VMware SD-WAN Gateway, bei dem PKI aktiviert 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 51428: Verlust von Multicast-Datenverkehr kann auf einer Site beobachtet werden, auf der die VMware SD-WAN Edge über eine mit PIM konfigurierte Teilschnittstelle verfügt.

  Wenn eine mit PIM konfigurierte Teilschnittstelle unterwegs von einem Segment zu einem anderen verschoben wird, wird pimd (der Prozess, der PIM verwaltet) möglicherweise neu gestartet werden, und die Site erleidet unregelmäßig auftretende Verluste von Multicast-Datenverkehr.

  Problemumgehung: Deaktivieren Sie zuerst die Teilschnittstelle und verschieben Sie die Teilschnittstelle zu einem anderen Segment. Aktivieren Sie nach dem Verschieben die Teilschnittstelle erneut.

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

• Problem 52483: Wenn die Underlay-Berechnung für eine Schnittstelle aktiviert ist, leitet der VMware SD-WAN-Edge den Datenverkehr fälschlicherweise an dieselbe Schnittstelle weiter, anstatt an das Overlay weiterzuleiten.

  Dieses Verhalten wird durch ein Problem bei der Underlay-Berechnung und eine rekursive Routenauflösung verursacht.

  Problemumgehung: Deaktivieren Sie die Underlay-Berechnung für die betroffene Schnittstelle.

• 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 53337: Paketlöschungen können mit einer AWS-Instanz eines VMware SD-WAN Gateways beobachtet werden, wenn der Durchsatz über 3200 MBit/s liegt.

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

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

• Problem 53359: BGP/BFD-Sitzung schlägt möglicherweise während einiger DDoS-Angriffsszenarien fehl.

  Wenn Datenverkehr vom Client, der mit der gerouteten Schnittstelle zum LAN-Client verbunden ist, überflutet wird, kann die BGP/BFD-Sitzung fehlschlagen. Auch wenn der Datenverkehr mit hoher Priorität in Echtzeit zum Overlay-Ziel überflutet wird, kann die BGP/BFD-Sitzung fehlschlagen.

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

• Problem 53830: Bei einem VMware SD-WAN Edge haben einige Routen in der BGP-Ansicht möglicherweise nicht die richtigen Präferenz- und Ankündigungswerte, wenn das DCC-Flag aktiviert ist, was zu einer falschen Sortierreihenfolge in der FIB des Edge führt.

  Wenn die DCC (Distributed Cost Calculation) in einem skalierten Szenario mit einer großen Anzahl von Routen an einem Edge aktiviert ist, werden beim Betrachten eines Edge-Diagnosepakets für das Protokoll bgp_view einige der Routen möglicherweise nicht korrekt mit den Präferenz- und Ankündigungswerten aktualisiert.  Sofern dieses Problem überhaupt auftritt, würde es in einigen Edges als Teil eines großen Unternehmens gefunden werden (100+ Spoke-Edges, die entweder mit Hub-Edges oder Hub-Clustern verbunden sind).  

  Problemumgehung: Dieses Problem kann behoben werden, indem entweder die zugrunde liegenden BGP-Routen neu gelernt werden oder eine Option „Aktualisieren“ auf der OFC-Seite der VMware SD-WAN Orchestrator-Instanz für die betroffenen Routen durchgeführt wird. Bitte beachten Sie, dass beim „Aktualisieren“ einer Route die Routen von allen Edges im Unternehmen neu gelernt würden.

• Problem 53934: In einem Unternehmen, in dem ein VMware SD-WAN Hub-Cluster konfiguriert ist und der primäre Hub BGP-Nachbarschaften mit mehreren Hops 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 deaktiviert 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 für alle Segmente deaktiviert 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 deaktiviert wurde).

• Problem 56218: Bei einem Kundenstandort, der mit einer Hochverfügbarkeits-Topologie bereitgestellt wird oder bei dem HA gerade aktiviert wurde, kann es beim Upgrade der Edges von 3.2.x auf 3.4.x zu einem Ausfall des Standby-Edges kommen.

  Wenn HA aktiviert ist oder die HA-Edges von 3.2.2 auf 3.4.x aktualisiert werden, nachdem eine WAN-Einstellung über die lokale Benutzeroberfläche konfiguriert wurde, wird die HA-Schnittstelle (z. B. LAN1 oder GE1, je nach Edge-Modell) vom Standby-Edge entfernt und der HA-Status wird im VMware SD-WAN Orchestrator auf HA_FAILED gesetzt.

  Problemumgehung: Starten Sie den Standby-Edge neu, um ihn wiederherzustellen.

• Problem 60006: Wenn HA auf hardwarebasierten VMware SD-WAN-Edges wie dem 620 und 640 aktiviert ist, kann der Standby-Edge neu starten.

  Wenn HA auf einem 620 oder 640 aktiviert ist (dies sind die Modelle, bei denen dieses Problem beobachtet wurde), erkennt der Standby-Edge möglicherweise eine Aktiv/Aktiv-Panik und führt einen Neustart durch, um den Status „Aktiv/Aktiv“ (Active/Active) zu korrigieren. Dieses Problem wird durch Folgendes verursacht: Während der Edge-Initialisierung kommt es möglicherweise zu einer Wettlaufsituation zwischen der HA-Schnittstelleninitialisierung und der HA-Zustandsmaschineninitialisierung. Mit anderen Worten, die HA-Zustandsmaschine startet viel früher, als die Initialisierung des HA-Schnittstellentreibers abgeschlossen ist, und infolgedessen erkennt die HA-Zustandsmaschine kein Taktsignal vom Peer-Edge und geht in einen aktiven Zustand über.  Dieses Problem tritt nur selten auf, und sollte es bei einer bestimmten Site auftreten, ist es unwahrscheinlich, dass es zweimal in derselben Sitzung geschieht. Mit anderen Worten: Es wird nicht erwartet, dass die Site in einen endlosen Zyklus von Standby-Edge-Neustarts gerät.

  Problemumgehung: Es gibt keine Problemumgehung für dieses Problem, aber normalerweise wird der Standby-Modus nach dem ersten Neustart wiederhergestellt.

• Problem 60225: Bei der Ausführung der Remote-Diagnose „Status der Schnittstelle“ (Interface Status) für einen VMware SD-WAN Edge zeigt die Ausgabe auf dem VMware SD-WAN Orchestrator für SFP-Schnittstellen falsche Geschwindigkeits- und Duplexinformationen an.

  Die Daten auf Orchestrator sind für SFP-Schnittstellen nicht korrekt. Beispiel: Es wird 0 MBit/s Halbduplex angezeigt, während bei der direkten Anzeige auf dem Edge die Daten Vollduplex bei 1.000 MBit/s oder einen ähnlichen Wert anzeigen.

  Problemumgehung: Es gibt keine Problemumgehung.

• Problem 60523: Die IP-Adresse eines gerouteten Client schlägt fehl, wenn ein SLA-Test aktiviert ist.

  Das ICMP-Antwortpaket kann vom Edge-Datenebene-Dienst nicht verarbeitet werden, wenn ein SLA-Test für die IP-Adresse des gerouteten Clients aktiviert ist.  Ohne den Fix bestand die einzige Möglichkeit zum Beheben dieses Problems darin, den ICMP-Test zu deaktivieren.

  Problemumgehung: Deaktivieren Sie den ICMP-Test.

• Problem 61361: Bei der Anwendung eines Software-Updates zum Upgrade eines VMware SD-WAN Edge 3400, 3800 und 3810 auf Edge Version 3.4.5, 4.0.2 oder 4.2.1 kann es vorkommen, dass die Edge-Modelle nach dem Update nicht sofort wieder hochfahren.

  Die Versionen 3.4.5, 4.0.2 und 4.2.1 enthalten ein spezielles Firmware-Update für den komplexen programmierbaren Logikbaustein (Complex Programmable Logic Device, CPLD), das einen Neustart auslöst, der gelegentlich „stecken“ bleibt und einen manuellen Neustart des Systems erfordert.

  Problemumgehung: Schalten Sie den Edge manuell aus, um das Update abzuschließen.

• 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 aktivierter 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 62552: Auf einer Site kann es zeitweilig Phasen mit hohen Paketverlusten und Konnektivitätsproblemen geben.

  Dies wird durch die API verursacht, die die ARP-Auflösung überprüft und dem Edge eine erfolgreiche ARP-Auflösung für ein Gerät liefert, während eine MAC-Adresse von 00:00:00:00 bereitgestellt wird.  Diese Adresse wird im ARP-Cache gespeichert und alle Pakete, die für das Gerät bestimmt sind, auf dem die MAC-Adresse als Null aufgeführt ist, werden verworfen.  Bei diesem Problem werden viele solche erfolgreichen ARP-Instanzen mit Null-MAC-Adressen geliefert, was zu einem hohen Paketverlust und Konnektivitätsproblemen führt.

  Hinweis: Sowohl das Problem 60130 als auch dieses weisen dasselbe zugrunde liegende Verhalten und dieselbe Ursache auf, aber die erwarteten Fixes für jedes Ticket unterscheiden sich. 60130 wird mit einem defensiven Fix zur Umgehung des Problems behoben, während 62552 einen vollständigen Fix erhalten wird, der ein erneutes Auftreten des Problems verhindert.

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

• Problem 63359: Bei einer Site, die mit einer Hochverfügbarkeitstopologie und OSPF konfiguriert ist und bei der die VMware SD-WAN-Edges einen Verwaltungs-IP-Edge-Build verwenden, kann die OSPF-Konnektivität nach dem Upgrade dieser Edges von einem Verwaltungs-IP-Build der Version 3.4.x auf 4.2.x unterbrochen werden. 

  Wenn die HA-Edges auf einen Verwaltungs-IP-Build der Version 4.2.x aktualisiert werden, können die HA-Systeme ihre Router-ID als 169.254.2.2 definieren. Dies ist nicht das erwartete Verhalten, da die Edge-Auswahl der Router-ID die IP-Adresse der HA-Schnittstelle nicht berücksichtigen sollte. Diese Router-ID unterbricht die OSPF-Konnektivität und die Verbindung wird vollständig getrennt, da kein Routenaustausch mehr stattfindet.

  Problemumgehung: Starten Sie den Edge-Dienst neu (wodurch ein HA-Failover ausgelöst wird), da dadurch eine erneute Auswahl der Router-ID erzwungen wird, die nach dem Neustart korrekt sein sollte.

• Problem 67790: Für ein Kundenunternehmen, das BGP oder OSPF verwendet und einen oder mehrere eingehende Filter so konfiguriert hat, dass bestimmte Routen ignoriert werden, sind die eingehenden Filter nicht mehr wirksam, wenn die dynamische Kostenberechnung ( Dynamic Cost Calculation, DCC) in diesem Unternehmen aktiviert wird, und der Datenverkehr wird versuchen, diese Routen zu verwenden.

  Bevor DCC aktiviert wurde, enthält die FIB (Forwarding Information Base) nicht die Routen, die im eingehenden BGP/OSPF-Filter auf IGNORIEREN (IGNORE) gesetzt wurden.  Nachdem DCC aktiviert wurde, enthält die FIB nun diese Routen, und der Datenverkehr wird versuchen, diese Routen zu nutzen, was zu erheblichen Unterbrechungen im Datenverkehr des Kundenunternehmens führen kann.  

  Problemumgehung: OSPF/BGP muss neu gestartet werden, damit der eingehende Filter ordnungsgemäß angewendet werden kann.

• Problem 84825: Wenn für eine Site mit einer Hochverfügbarkeitstopologie, in der BGP konfiguriert ist, mehr als 512 Übereinstimmungs-/Festgelegte BGPv4-Regeln auf der Site konfiguriert sind, kann der Kunde beobachten, dass das HA-Edge-Paar kontinuierlich ausfällt, ohne dass es jemals wiederhergestellt wird.

  Mehr als 512 Übereinstimmungs- und Festgelegte BGPv4-Regeln bedeutet, dass ein Kunde mehr als 256 solcher Regeln für den eingehenden Filter und 256 Regeln für den ausgehenden Filter konfiguriert. Dieses Problem wäre für den Kunden störend, da das wiederholte Failover dazu führen würde, dass Flows für Echtzeitdatenverkehr wie z. B. Sprachanrufe, kontinuierlich unterbrochen und dann wiederhergestellt würden. Wenn bei HA-Edges dieses Problem auftritt, schlägt der Prozess zur Synchronisierung der Edge-CPU-Threads fehl, sodass der Edge zur Wiederherstellung neu gestartet werden muss. Beim heraufgestuften Edge tritt jedoch das gleiche Problem auf, und er wird seinerseits neu gestartet, ohne dass eine Wiederherstellung auf der Site erreicht wird.

  Problemumgehung: Ohne einen Fix für dieses Problem muss der Kunde sicherstellen, dass nicht mehr als 512 Übereinstimmungs- und Festgelegte-BGPv4-Regeln für eine HA-Site konfiguriert sind.

  Wenn auf einer Site dieses Problem auftritt und mehr als 512 Übereinstimmungs- und Festgelegte BGP/v4-Regeln konfiguriert sind, muss der Kunde die Anzahl der Regeln sofort auf 512 oder weniger reduzieren, um die Site wiederherzustellen.

  Wenn der Kunde mehr als 512 Übereinstimmungs- und Festgelegte BGPv4-Regeln benötigt, kann er alternativ ein Herabstufen der HA-Edges auf Version 3.4.6 vornehmen, wo dieses Problem nicht auftritt, allerdings auf Kosten der Edge-Funktionen, die in späteren Versionen enthalten sind. Dies ist nur möglich, wenn das Edge-Modell in Version 3.4.6 unterstützt wird, und der Kunde sollte sich vor dem Herabstufen vergewissern, dass dies der Fall ist.

Bekannte Probleme bei Orchestrator

• Problem 19566:

  Nach einem Hochverfügbarkeits-Failover wird die Seriennummer des Standby-VMware SD-WAN Edge möglicherweise als aktive Seriennummer im Orchestrator angezeigt.

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

  Mit „Überwachen (Monitor) > Transport > Verlust nicht grafisch dargestellt (Loss not graphing)“ wurde ein WAN-Link-Verlust beobachtet, während dieser Verlust in QoE-Diagrammen widergespiegelt wird. 

• 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-Außerkraftsetzung 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 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 34828:

  Der Datenverkehr kann nicht zwischen einem VMware SD-WAN Spoke Edge mit Version 2.x und einem Hub-Edge mit Version 3.3.1 übertragen werden.

• 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 und aktivieren Sie GRE auf Edge-Ebene, 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 und aktivieren Sie GRE auf Edge-Ebene, 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 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 40341:

  Obwohl die Skype-Anwendung auf dem Backend ordnungsgemäß als Echtzeitdatenverkehr kategorisiert wird, kann es beim Bearbeiten der Skype Business Policy im VMware SD-WAN Orchestrator vorkommen, dass die Dienstklasse fälschlicherweise „Transaktional (Transactional)“ anzeigt.

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

• Problem 44153:

  Der VMware SD-WAN Orchestrator sendet nicht kontinuierlich E-Mail-Warnungen an die im Abschnitt „Warnungen und Benachrichtigungen (Alerts and Notifications)“ konfigurierten E-Mail-Adressen.

• Problem 46254:

  Während einer VMware SD-WAN Edge-Aktivierung erkennt der VMware SD-WAN Orchestrator weder eine geänderte WAN-Link-MTU noch das Vorhandensein einer VLAN-ID für per DHCP konfigurierte Schnittstellen.

• Problem 47269:

  Die VMware SD-WAN 510-LTE-Schnittstelle wird möglicherweise für Edge-Modelle angezeigt, die keine LTE-Schnittstelle unterstützen.

• Problem 47713:

  Wenn eine Business Policy-Regel konfiguriert ist, während Cloud-VPN deaktiviert ist, muss die NAT-Konfiguration beim Aktivieren von Cloud-VPN neu konfiguriert werden.

• Problem 47820:

  Wenn ein VLAN mit deaktiviertem DHCP auf Profilebene konfiguriert ist, während gleichzeitig eine Edge-Außerkraftsetzung 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 darauf hinweist.

• Problem 48085:

  VMware SD-WAN Orchestrator ermöglicht es einem Benutzer, ein VLAN zu löschen, das mit einer Schnittstelle verknüpft ist.

• Problem 48737:

  In einem VMware SD-WAN Orchestrator, der die neue Benutzeroberfläche von Version 4.0.0 nutzt, aktualisiert der Orchestrator die Start- und Endzeit nicht auf die neuen Werte, wenn sich ein Benutzer auf der Seite „Überwachen (Monitor)“ befindet und das Start- und Endzeitintervall ändert und dann zwischen den Registerkarten wechselt.

• Problem 49225:

  VMware SD-WAN Orchestrator erzwingt keine Begrenzung auf insgesamt 32 VLANs.

• Problem 49790:

  Wenn ein VMware SD-WAN Edge auf Version 4.0.0 aktiviert wird, wird die Aktivierung zweimal in den Ereignissen gemeldet.

  Problemumgehung: Ignorieren Sie das doppelte Ereignis.

• Problem 50531:

  Wenn zwei Operatoren mit unterschiedlichen Berechtigungen dasselbe Browserfenster beim Zugriff auf die neue Benutzeroberfläche von VMware SD-WAN Orchestrator, Version 4.0.0, verwenden und der Operator mit geringeren Berechtigungen versucht, sich nach dem Operator mit höheren Berechtigungen anzumelden, werden dem Operator mit geringeren Berechtigungen mehrere Fehler angezeigt, die besagen, dass der Benutzer keine Berechtigung hat.

  Hinweis: Für den Operator mit geringeren Berechtigungen findet keine Eskalation der Berechtigungen statt, sondern nur die Anzeige von Fehlermeldungen.

  Problemumgehung: Der nächste Operator kann diese Seite vor der Anmeldung aktualisieren, um zu verhindern, dass die Fehler angezeigt werden, oder jeder Operator zur Vermeidung dieses Anzeigeproblems verschiedene Browserfenster verwenden.

• Problem 51722: In Version 4.0.0 des VMware SD-WAN 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 60039: Die RMA-Neuaktivierung funktioniert nicht, wenn das VMware SD-WAN Edge-Modell geändert wird.

  Bei der Durchführung einer RMA-Neuaktivierung für einen Standort, auf dem auch das Edge-Modell geändert wird, kann der VMware SD-WAN Orchestrator die Modelländerung nicht speichern, wodurch der Neuaktivierungslink nicht wirksam wird. Dies betrifft nur RMA-Neuaktivierungen, bei denen das Edge-Modell geändert wird. Eine RMA-Reaktivierung, bei der das Edge-Modell gleich bleibt, funktioniert wie erwartet.

  Problemumgehung: Wenn Sie ein anderes Edge-Modell für einen Standort verwenden, müsste der Benutzer einen neuen Edge erstellen und alle Edge-spezifischen Einstellungen manuell anwenden.