Beschreibt alle möglichen Remote-Diagnosetests, die Sie auf einem Edge durchführen können, um Diagnosedaten zu erhalten. Die Diagnosedaten enthalten Edge-spezifische Protokolle für die Analyse.

Mit VMware SD-WAN Orchestrator können Sie verschiedene Remote-Diagnosetests auf einem ausgewählten Edge über das Menü Testen und Fehlerbehebung (Test & Troubleshoot) > Remote-Diagnose (Remote Diagnostics) ausführen.

Im Folgenden sind die unterstützen Remote-Diagnosetests aufgeführt:

ARP-Tabellenauszug (ARP Table Dump)

Führen Sie diesen Test aus, um den Inhalt der Tabelle ARP-Tabelle anzuzeigen. Die Ausgabe ist auf 1.000 ARP-Einträge begrenzt.

ARP-Cache löschen (Clear ARP Cache)

Führen Sie diesen Test aus, um die ARP-Cache-Einträge für die angegebene Schnittstelle zu löschen.

DNS-Test (DNS Test)

Führen Sie diesen Test aus, um eine DNS-Suche des angegebenen Domänennamens durchzuführen.

Neustart des DNS/DHCP-Diensts (DNS/DHCP Service Restart)

Führen Sie diesen Test aus, um den DNS/DHCPv4-Dienst neu zu starten. Dies kann als Fehlerbehebungsschritt dienen, wenn DHCP- oder DNS-Anfragen für Clients fehlschlagen.
Hinweis: Mit dieser Remote-Diagnoseoption wird der DHCPv6-Dienst nicht neu gestartet.

DSL-Status

Der DSL-Diagnosetest ist nur für 610-Geräte verfügbar. In der Version 4.3 sind Tests auch für 620-, 640- und 680-Geräte verfügbar. Bei der Durchführung dieses Tests wird der DSL-Status angezeigt, der Informationen wie „Modus (Mode)“ (Standard oder DSL), „Profil (Profile)“, „xDSL-Modus (xDSL Mode)“ usw. enthält, wie in der folgenden Abbildung dargestellt.

Informationen zum Auszug der Kontextprotokollierung

Was ist der Zweck dieses Tests?

Kontextprotokollierung erfolgt pro Linux-Thread-Protokollierungsinfrastruktur. Dieser Test listet die Threads auf, die kontextbezogene Protokollierung verwenden.

Wann kann dieser Test ausgeführt werden?

Führen Sie diesen Test aus, um einen Auszug der Threads zu erstellen, die die Kontextprotokollierung verwendet haben. Anweisungen zum Ausführen eines Remote-Diagnosetests auf Edges finden Sie im Thema Ausführen von Remote-Diagnosetests auf Edges im VMware SD-WAN-Handbuch zur Fehlerbehebung.

Zu prüfende Punkte in der Testausgabe

Der Test gibt den Thread-Namen, die Thread-ID und den Kontextprotokollstatus („Ein“ oder „Aus“) für den Thread aus, der die Kontextprotokollierung verwendet.
  • Kontextprotokollstatus „Ein“ bedeutet, dass die Kontextprotokollierung für den angegebenen Thread aktiviert ist.
  • Kontextprotokollstatus „Aus“ bedeutet, dass die Kontextprotokollierung für den angegebenen Thread deaktiviert ist.
Nachfolgend sehen Sie ein Beispiel für die Testausgabe:

Aktivieren oder Deaktivieren der Kontextprotokollierung

Was ist der Zweck dieses Tests?

Kontextprotokollierung erfolgt pro Linux-Thread-Protokollierungsinfrastruktur. Dies kann verwendet werden, um die Kontextprotokollierung zu aktivieren oder zu deaktivieren.

Wann kann dieser Test ausgeführt werden?

Führen Sie diesen Test aus, um die Kontextprotokollierung für bestimmte Threads oder alle Threads zu aktivieren oder zu deaktivieren. Anweisungen zum Ausführen eines Remote-Diagnosetests auf Edges finden Sie im Thema Ausführen von Remote-Diagnosetests auf Edges im VMware SD-WAN-Handbuch zur Fehlerbehebung.

Zu prüfende Punkte in der Testausgabe

Geben Sie eine Thread-ID an, wenn Sie die Kontextprotokollierung für einen bestimmten Thread aktivieren oder deaktivieren möchten, oder geben Sie die Option Alle (All) an. Sobald der Test ausgeführt wurde, wird die Aktion angewendet. Sie können die Änderungen mithilfe des Testbefehls „Informationen zum Auszug der Kontextprotokollierung (Dump Context Logging Information)“ validieren.

Nachfolgend sehen Sie ein Beispiel für die Testausgabe:

Firewallsitzungen leeren (Flush Firewall Sessions)

Führen Sie diesen Test aus, um eingerichtete Sitzungen der Firewall zurückzusetzen. Wenn Sie diesen Test auf einem Edge ausführen, werden nicht nur die Firewallsitzungen geleert, sondern es wird auch aktiv ein TCP RST für die TCP-basierten Sitzungen gesendet.
Hinweis: Wenn Sie die IPv6-Firewallsitzungen leeren möchten, führen Sie den Test Firewallsitzungen leeren (Flush Firewall Sessions) über die neue Orchestrator-Benutzeroberfläche aus.

Flows leeren (Flush Flows)

Führen Sie diesen Test aus, um die Flow-Tabelle zu leeren, wodurch der Benutzerdatenverkehr neu klassifiziert wird. Verwenden Sie Filter für Quell- und Ziel-IPv4- oder IPv6-Adressen, um bestimmte Flows zu leeren.

NAT leeren (Flush NAT)

Führen Sie diesen Test aus, um die NAT-Tabelle zu leeren.

Gateway

Führen Sie diesen Test aus, indem Sie auswählen, ob der Gateway-Dienst für Cloud-Datenverkehr verwendet werden soll oder nicht.
Hinweis: Dies wirkt sich nicht auf das Routing des VPN-Datenverkehrs aus.

GPON-Status

Führen Sie diesen Test auf allen ausgewählten 6x0-Edge-Geräten aus, um den GPON-SFP-Status anzuzeigen, einschließlich der Anbieter-MAC, des Hostverbindungsstatus, der Verbindungsrate, der Leistung von Sender (TX) und Empfänger (RX) und des optischen Status.

HA-Info (HA Info)

Führen Sie diesen Test aus, um Basis- und Schnittstelleninformationen aktiver und Standby-Edges anzuzeigen, wenn HA aktiviert ist.

IPv6 ND-Cache leeren (IPv6 Clear ND Cache)

Führen Sie diesen Test aus, um den Cache aus der ND für die angegebene Schnittstelle zu löschen.

IPv6 ND-Tabellenauszug (IPv6 ND Table Dump)

Führen Sie diesen Test aus, um die IPv6-Adressdetails der Neighbor Discovery (ND)-Tabelle anzuzeigen.

IPv6 RA-Tabellenauszug (IPv6 RA Table Dump)

Führen Sie diesen Test aus, um die Details der IPv6-RA-Tabelle anzuzeigen.

IPv6-Routentabellenauszug (IPv6 Route Table Dump)

Was ist der Zweck dieses Tests?

Mit dem Befehl „IPv6-Routentabellenauszug (IPv6 Route Table Dump)“ wird die vollständige Routing-Tabelle in IPv6 aufgelistet.

Wann kann dieser Test ausgeführt werden?

Führen Sie diesen Test aus, wenn Sie die Route in der FIB-Tabelle von IPv6 überprüfen möchten. Sie können den Test ausführen, indem Sie eine der folgenden Optionen angeben:
  • Segment: Wählen Sie das Segment aus, für das Routen angezeigt werden müssen. Wählen Sie „Alle (Alle)“ für alle Segmente aus.
  • Präfix (Prefix): Geben Sie ein bestimmtes Präfix an, für das Routen angezeigt werden müssen.
  • Routen (Routes): Wählen Sie in der Dropdown-Liste eine der folgenden Optionen aus:
    • Alle (All): Zeigen Sie alle Routen für jedes Präfix an.
    • Bevorzugt (Preferred): Zeigen Sie die bevorzugte Route allein für jedes Präfix an (dies ist die Route, die für die Datenweiterleitung verwendet wird).

Zu prüfende Punkte in der Testausgabe

Nachfolgend sehen Sie ein Beispiel für die Testausgabe:

Die Remote-Diagnoseausgabe zeigt die folgenden Informationen an:
Bereich Beschreibung
Adresse (Adress) Gibt die in der Tabelle verfügbaren IPv6-Routen an.
Segment Gibt das Segment an, in dem die Routen verfügbar sind und vom Edge verarbeitet werden.
Netzmaske (Netmask) Gibt den Adressbereich in IPv6 an.
Typ (Type) Gibt den Routentyp an, z. B. Cloud, Edge2Edge, beliebig (Underlay oder Verbunden) usw.
Kosten (Cost) Gibt die Routenkosten oder Metriken an, die bei der Auswahl der Routenkriterien verwendet werden.
Erreichbar (Reachable) Gibt den Status der Route an:
  • True – Erreichbar (True – Reachable)
  • False – Nicht erreichbar (False – Not Reachable)
Nächster Hop (Next Hop) Gibt im Falle lokaler Routen die lokale Ausgangsschnittstelle an. Im Falle von Overlay-/Remote-Routen wird die Art des nächsten Hops angegeben. Beispiel: „Cloud-Gateway“ im Falle von Cloud-Routen, „Cloud-VPN“ im Falle eines Datencenters oder „Edge-zu-Edge“-Routen usw.
Name für nächsten Hop (Next Hop Name) Gibt den Namen des nächsten Hop-Geräts an.
Zielname (Destination Name) Gibt den Namen des Zielgeräts an.
Grund für Verlust (Lost Reason) Gibt den Code dafür an, warum eine Route die Berechnungslogik für die Routing-Präferenz an die nächste bevorzugte Route verliert, sowohl auf Edges als auch auf Gateways.
Grund für (nicht) erreichbar ((Not) Reachable Reason) Gibt den Grund an, warum die Route erreichbar oder nicht erreichbar ist.
Hinweis: Eine nicht aufgelöste Route, die über BGP mit mehreren Hops gelernt wurde, weist möglicherweise auf eine Zwischenschnittstelle hin. Weitere Informationen finden Sie unter BGP-Routen mit mehreren Hops.

Status der Schnittstelle

Führen Sie diesen Test aus, um die MAC-Adresse und den Verbindungsstatus physischer Schnittstellen anzuzeigen.

LTE-Modeminformationen (LTE Modem Information)

Führen Sie diesen Test an einem ausgewählten Edge mit integriertem LTE-Modul wie 510-LTE oder 610-LTE durch, um Diagnosedetails wie Modeminformationen, Verbindungsinformationen, Standortinformationen, Signalinformationen, Firmware-Informationen und Statusinformationen für das interne LTE-Modem zu erfassen.

LTE-SIM-Umschaltung (LTE SIM Switchover)

Führen Sie diesen Test nur für 610-LTE-Geräte aus, um aktive SIMs zu schalten. Beide SIMs müssen eingelegt werden, um diesen Test durchzuführen. Der Test dauert ca. vier bis fünf Minuten.

Nachdem der Test erfolgreich ist, können Sie den Status der aktuellen aktiven Benutzeroberfläche im SD-WAN Orchestrator unter der Registerkarte Überwachen (Monitor) -> Edges -> Übersicht (Overview) überprüfen.

Aktive Firewallsitzungen auflisten (List Active Firewall Sessions)

Führen Sie diesen Test aus, um den Status der aktiven Firewallsitzungen anzuzeigen (bis maximal 1.000 Sitzungen). Sie können die Anzahl der zurückgegebenen Sitzungen mithilfe von Filtern begrenzen: Quell- und Ziel-IP-Adresse, Quell- und Zielport sowie Segment.
Hinweis: Es können keine Sitzungen angezeigt werden, die abgelehnt wurden, da es sich dabei nicht um aktive Sitzungen handelt. Zur Fehlerbehebung bei diesen Sitzungen müssen Sie die Firewallprotokolle überprüfen.
Hinweis: Informationen zu IPv6-Firewallsitzungen können über die neue Orchestrator-Benutzeroberfläche angezeigt werden. Zum Anzeigen der Informationen zu IPv6-Firewallsitzungen müssen Sie den Test Aktive Firewallsitzungen auflisten (List Active Firewall Sessions) über die neue Orchestrator-Benutzeroberfläche ausführen.
Die Ausgabe der Remotediagnose zeigt die folgenden Informationen an: Segmentname, Quell-IP, Quellport, Ziel-IP, Zielport, Protokoll, Anwendung, Firewallrichtlinie, aktueller TCP-Zustand ggf. vorhandener Flows, Empfangene/gesendete Byte und Dauer. Es gibt 11 eindeutige TCP-Zustände gemäß Definition in RFC 793:
  • LISTEN: Steht für das Warten auf eine Verbindungsanforderung von einem beliebigen Remote-TCP und Port. (Dieser Zustand wird in einer Remote-Diagnoseausgabe nicht angezeigt.)
  • SYN-SENT: Steht für das Warten auf eine passende Verbindungsanforderung, nachdem eine Verbindungsanforderung gesendet wurde.
  • SYN-RECEIVED: Steht für das Warten auf die Bestätigung einer Verbindungsanforderung, nachdem eine Verbindungsanforderung gesendet und empfangen wurde.
  • ESTABLISHED: Steht für eine offene Verbindung. Empfangene Daten können an den Benutzer übermittelt werden. Der normale Zustand für die Datenübertragungsphase der Verbindung.
  • FIN-WAIT-1: Steht für das Warten auf eine Verbindungsabbruchanforderung vom Remote-TCP oder auf die Bestätigung einer zuvor gesendeten Verbindungsabbruchanforderung.
  • FIN-WAIT-2: Steht für das Warten auf eine Verbindungsabbruchanforderung vom Remote-TCP.
  • CLOSE-WAIT: Steht für das Warten auf eine Verbindungsabbruchanforderung vom lokalen Benutzer.
  • CLOSING: Steht für das Warten auf die Bestätigung einer Verbindungsabbruchanforderung vom Remote-TCP.
  • LAST-ACK: Steht für das Warten auf die Bestätigung einer Verbindungsabbruchanforderung, die zuvor an das Remote-TCP gesendet wurde (die schließt die Bestätigung der Verbindungsabbruchanforderung ein).
  • TIME-WAIT: Steht für das Warten auf genügend Zeit, um sicherzustellen, dass das Remote-TCP die Bestätigung seiner Verbindungsabbruchanforderung erhalten hat.
  • CLOSED: Steht für gar keinen Verbindungsstatus.

Aktive Flows auflisten (List Active Flows)

Führen Sie diesen Test aus, um aktive Flows im System aufzulisten. Verwenden Sie Filter für Quell- und Ziel-IPv4- oder IPv6-Adressen, um exakt die gewünschten Flows anzuzeigen. Diese Ausgabe ist auf maximal 1.000 Flows begrenzt.

Clients auflisten (List Clients)

Führen Sie diesen Test aus, um die vollständige Liste der Clients anzuzeigen.

Pfade auflisten (List Paths)

Führen Sie diesen Test aus, um die Liste der aktiven Pfade zwischen lokalen WAN-Links und jedem Peer anzuzeigen.

MIBs für Edge (MIBs for Edge)

Führen Sie diesen Test aus, um Edge-MIBs zu sichern.

NAT-Tabellenauszug (NAT Table Dump)

Führen Sie diesen Test aus, um den Inhalt der NAT-Tabelle anzuzeigen. Verwenden Sie den Filter für die Ziel-IP-Adresse, um exakt die gewünschten Einträge anzuzeigen. Diese Ausgabe ist auf maximal 1.000 Einträge begrenzt.

NTP-Auszug (NTP Dump)

Führen Sie diesen Test aus, um das aktuelle Datum und die aktuelle Uhrzeit für die Informationen zu Edge und NTP anzuzeigen.

Ping-IPv6-Test

Führen Sie einen Ping-Test für das angegebene IPv6-Ziel aus.

Ping-Test (Ping Test)

Führen Sie einen Ping-Test für das angegebene IPv4-Ziel aus.

USB-Modem zurücksetzen (Reset USB Modem)

Führen Sie diesen Test an einer ausgewählten Edge-Schnittstelle durch, um ein nicht funktionierendes USB-Modem, das mit der angegebenen Schnittstelle verbunden ist, zurückzusetzen. Beachten Sie, dass nicht alle USB-Modems diese Art von Remote-Reset unterstützen.

Auszug der Routentabelle (Route Table Dump)

Was ist der Zweck dieses Tests?

Mit dem Befehl „Auszug der Routentabelle (Route Table Dump)“ wird die vollständige Routing-Tabelle in IPv4 aufgelistet.

Wann kann dieser Test ausgeführt werden?

Führen Sie diesen Test aus, um die Route in der FIB-Tabelle von IPv4 zu überprüfen. Sie können den Test ausführen, indem Sie eine der folgenden Optionen angeben:
  • Segment: Wählen Sie das Segment aus, für das Routen angezeigt werden müssen. Wählen Sie „Alle (Alle)“ für alle Segmente aus.
  • Präfix (Prefix): Geben Sie ein bestimmtes Präfix an, für das Routen angezeigt werden müssen.
  • Routen (Routes): Wählen Sie in der Dropdown-Liste eine der folgenden Optionen aus:
    • Alle (All): Zeigen Sie alle Routen für jedes Präfix an.
    • Bevorzugt (Preferred): Zeigen Sie die bevorzugte Route allein für jedes Präfix an (dies ist die Route, die für die Datenweiterleitung verwendet wird).

Zu prüfende Punkte in der Testausgabe

Nachfolgend sehen Sie ein Beispiel für die Testausgabe:

Die Remote-Diagnoseausgabe zeigt die folgenden Informationen an:
Bereich Beschreibung
Adresse (Adress) Gibt die in der Tabelle verfügbaren IPv4-Routen an.
Segment Gibt das Segment an, in dem die Routen verfügbar sind und vom Edge verarbeitet werden.
Netzmaske (Netmask) Gibt den Adressbereich in IPv4 an.
Typ (Type) Gibt den Routentyp an, z. B. Cloud, Edge2Edge, beliebig (Underlay oder Verbunden) usw.
Kosten (Cost) Gibt die Routenkosten oder Metriken an, die bei der Auswahl der Routenkriterien verwendet werden.
Erreichbar (Reachable) Gibt den Status der Route an, unabhängig davon, ob sie „True“ für „Erreichbar (Reachable)“ oder „False“ für „Nicht erreichbar (Not Reachable)“ lautet.
Nächster Hop (Next Hop) Gibt im Falle lokaler Routen die lokale Ausgangsschnittstelle an. Im Falle von Overlay-/Remote-Routen wird die Art des nächsten Hops angegeben. Beispiel: „Cloud-Gateway“ im Falle von Cloud-Routen, „Cloud-VPN“ im Falle eines Datencenters oder „Edge-zu-Edge“-Routen usw.
Name für nächsten Hop (Next Hop Name) Gibt den Namen des nächsten Hop-Geräts an.
Zielname (Destination Name) Gibt den Namen des Zielgeräts an.
Grund für Verlust (Lost Reason) Gibt den Code dafür an, warum eine Route die Berechnungslogik für die Routing-Präferenz an die nächste bevorzugte Route verliert, sowohl auf Edges als auch auf Gateways.
Hinweis: LR_NO_ELECTION zeigt die beste Route an.
Grund für (nicht) erreichbar ((Not) Reachable Reason) Gibt den Grund an, warum die Route erreichbar oder nicht erreichbar ist.
Hinweis: Eine nicht aufgelöste Route, die über BGP mit mehreren Hops gelernt wurde, weist möglicherweise auf eine Zwischenschnittstelle hin. Weitere Informationen finden Sie unter BGP-Routen mit mehreren Hops.
In der folgenden Tabelle sind die Ursachencodes für einen Edge und die entsprechenden Beschreibungen aufgeführt:
Ursachencode Beschreibung
PR_UNREACHABLE Bei Overlay-Routen ist der Remote-Peer (entweder Gateway oder Edge) nicht erreichbar.
IF_DOWN Egress-Schnittstelle ist inaktiv.
INVALID_IFIDX Egress-Schnittstelle, wenn der Index für diese Route ungültig ist.
SLA_STATE_DOWN Der durch die IP-SLA-Nachverfolgung angegebene Status lautet „inaktiv (down)“.
HA_STANDBY Handelt es sich bei dem lokalen Edge um einen Standby-Edge, werden alle vom aktiven Edge synchronisierten Routen zur Vereinfachung des Betriebs als erreichbar markiert.
LOCAL_MGMT Verwaltungsrouten sind immer erreichbar.
LOOPBACK Loopback-IP-Adresse ist immer erreichbar.
SELF_ROUTE Selbst erstellte IP-Routen sind immer erreichbar.
RECUR_UNRES Rekursive Routen werden als erreichbar markiert, so dass rekursive Auflösung zur Vereinfachung des Betriebs durchgeführt werden kann.
VPN_VIA_NAT vpnViaNat-Routen sind immer erreichbar.
SLA_STATE_UP Der durch die IP-SLA-Nachverfolgung angegebene Status lautet „aktiv (up)“.
IF_RESOLVED Egress-Schnittstelle ist aktiv und wurde aufgelöst.
PR_REACHABLE Bei Overlay-Routen ist der Remote-Peer (entweder Gateway oder Edge) erreichbar.
LR_NO_ELECTION Beste Route.
LR_NP_SWAN_VS_VELO Der Vorgänger wird ausgewählt, da es sich um eine nicht bevorzugte statische WAN-Route handelt (eine Route, bei der das Flag „bevorzugt (preferred)“ auf „falsch (false)“ gesetzt ist), im Vergleich zur aktuellen Route, die eine Route über Velocloud ist.
LR_NP_SWAN_VS_DEFRT Der Vorgänger wird ausgewählt, da es sich um eine nicht bevorzugte statische WAN-Route handelt, wenn sie mit der aktuellen Route verglichen wird, die die Standardroute ist.
LR_NP_ROUTE_TYPE Der Vorgänger wird ausgewählt, da sein Routentyp im Vergleich zur aktuellen Route besser ist. Außerdem handelt es sich bei einer der zu vergleichenden Routen in diesem Fall um eine nicht bevorzugte Route.
LR_BGP_LOCAL_PREF Beide Routen werden mithilfe von BGP erlernt. Der Vorgänger wird ausgewählt, da er eine höhere lokale Präferenz als die aktuelle Route aufweist.
LR_BGP_ASPATH_LEN Beide Routen werden mithilfe von BGP erlernt. Der Vorgänger wird ausgewählt, da er einen niedrigeren AS-Pfadwert als die aktuelle Route aufweist.
LR_BGP_METRIC Beide Routen werden mithilfe von BGP erlernt. Der Vorgänger wird ausgewählt, da er einen niedrigeren Metrikwert als die aktuelle Route aufweist.
LR_EXT_OSPF_INTER Der Vorgänger wird ausgewählt, da es sich um eine von OSPF erlernte Route mit einer Inter- oder Intra-Area-Metrik im Vergleich zur aktuellen Route handelt, die von BGP erlernt wurde.
LR_EXT_BGP_RT Der Vorgänger wird ausgewählt, da es sich um eine von BGP erlernte Route handelt, im Vergleich zur aktuellen Route, die eine von OSPF erlernte Route mit dem Metrik-Typ OE1 oder OE2 ist.
LR_EXT_METRIC_TYPE

Beide Routen sind OSPF-Routen. Der Vorgänger wird ausgewählt, da er einen besseren Metriktyp als die aktuelle Route aufweist.

Reihenfolge der Präferenz für OSPF-Metriktypen: OSPF_TYPE_INTRA, OSPF_TYPE_INTER, OSPF_TYPE_OE1, OSPF_TYPE_OE2.

LR_EXT_METRIC_VAL Beide Routen sind OSPF-Routen. Der Vorgänger wird ausgewählt, da er einen niedrigeren Metrikwert als die aktuelle Route aufweist.
LR_EXT_NH_IP Beide Routen sind OSPF ECMP-Routen. Die aktuelle Route geht an den Vorgänger verloren, weil sie später erlernt wurde.
LR_PG_BGP_ORDER Beide sind Remote-BGP-Routen mit denselben BGP-Parametern. Die aktuelle Route wird ausgewählt, da es sich um eine Partner-Gateway-Route (PG) handelt und im Vergleich zur aktuellen Route einen niedrigeren Wert für „Reihenfolge (order)“ aufweist.
LR_NON_PG_BGP_ORDER Beide sind Remote-BGP-Routen mit denselben BGP-Parametern. Die aktuelle Route wird ausgewählt, da es sich um eine Nicht-PG-Route handelt und im Vergleich zur aktuellen Route einen niedrigeren Wert für „Reihenfolge (order)“ aufweist.
LR_EXT_ORDER Beide sind Remote-OSPF-Routen mit derselben Metrik. Der Vorgänger wird ausgewählt, da er einen niedrigeren Wert für die Reihenfolge als die aktuelle Route aufweist.
LR_PREFERENCE Bei beiden handelt es sich entweder um BGP- oder OSPF-Routen. Der Vorgänger wird ausgewählt, da er einen geringeren Wert für die Voreinstellung als die aktuelle Route aufweist.

LR_DCE_NSD_STATIC_PREF

DCE – Datencenter, NSD – Nicht-SDWAN-Site

Bei beiden handelt es sich um lokale statische NSD-Routen. Der Vorgänger wird ausgewählt, da es sich um eine bevorzugte Route handelt (bevorzugtes Flag auf „wahr (true)“ festgelegt) im Vergleich zur aktuellen Route, die nicht bevorzugt wird.
LR_DCE_NSD_STATIC_METRIC Bei beiden handelt es sich um statische NSD-Routen. Der Vorgänger wird ausgewählt, da er einen niedrigeren Metrikwert als die aktuelle Route aufweist.
LR_DCE_NON_REMOTE Bei beiden handelt es sich um statische NSD-Routen. Der Vorgänger wird ausgewählt, da es sich um eine lokale Route (nicht remote) handelt und die aktuelle Route eine Remoteroute ist.
LR_DCE_NSD_STATIC_REMOTE_ORDER Bei beiden handelt es sich um statische Remote-NSD-Routen. Der Vorgänger wird ausgewählt, da er im Vergleich zur aktuellen Route einen niedrigeren Wert für die Reihenfolge aufweist.
LR_DCE_DC_DIRECT Bei beiden handelt es sich um statische NSD-Routen. Der Vorgänger wird ausgewählt, da sein DC_DIRECT-Flag festgelegt ist und für die aktuelle Route dieses Flag nicht festgelegt ist. Dies ist die Route, bei der das Flag „n – nonVelocloud“ in der Ausgabe „routes“ festgelegt ist. Hierbei handelt es sich um Routen, die von einem NSD vom Edge erlernt werden.
LR_DCE_LOGICAL_ID Bei beiden handelt es sich um statische NSD-Routen. Der Vorgänger wird ausgewählt, da er über eine bessere logische ID als die aktuelle Route verfügt.
LR_NETMASK

Der Vorgänger wird ausgewählt, da er über eine höhere Netzmaske als die aktuelle verfügt.

Dies wird nicht funktionieren, da die Netzmaske eine andere ist und es sich um einen eigenen Netzwerk-/Routeneintrag handelt.

LR_NETADDR

Der Vorgänger wird ausgewählt, da er über eine höhere Netzwerkadresse als die aktuelle verfügt.

Dies wird nicht funktionieren, da die Netzwerkadresse unterschiedlich ist. Es handelt sich um einen eigenen Netzwerk-/Routing-Eintrag.

LR_CONN_FLAG Der Vorgänger wird ausgewählt, da es sich um eine verbundene Route handelt und die aktuelle Route keine verbundene Route ist.
LR_SELF_FLAG Der Vorgänger wird ausgewählt, da es sich um eine eigene Route handelt und die aktuelle Route keine eigene Route ist.
LR_SLAN_FLAG Der Vorgänger wird ausgewählt, da es sich um eine statische LAN-Route handelt und die aktuelle Route keine statische LAN-Route ist.
LR_SWAN_FLAG Der Vorgänger wird ausgewählt, da es sich um eine statische WAN-Route handelt und die aktuelle Route keine statische WAN-Route ist.
LR_NSD_STATIC_LOCAL Der Vorgänger wird ausgewählt, da es sich um eine lokale statische NSD-Route handelt und die aktuelle Route eine NSD-BGP-Route ist.
LR_NSD_BGP_VS_NON_PREF_STATIC Der Vorgänger wird ausgewählt, da es sich um eine NSD-BGP-Route handelt und die aktuelle Route eine statische, nicht bevorzugte NSD-Route ist.
LR_NSD_STATIC_PREF_VS_NSD_STATIC Der Vorgänger wird ausgewählt, da es sich um eine statische bevorzugte NSD-Route handelt und die aktuelle Route keine statische NSD-Route ist.
LR_CONN_STATIC_VS_NSD_BGP Der Vorgänger wird ausgewählt, da es sich um eine remote verbundene/statische Route handelt und die aktuelle Route eine NSD-BGP-Route ist.
LR_OPG_SECURE_STATIC Der Vorgänger wird ausgewählt, da es sich im Gegensatz zur aktuellen Route um eine sichere statische PG-Route handelt.
LR_ROUTED_VS_VELO Der Vorgänger wird ausgewählt, da es sich um eine Route handelt, die aus Routing-Protokollen erlernt wurde, im Vergleich zur aktuellen Route, die eine „v - ViaVeloCloud“-Route ist.
LR_INTF_DEF_VS_ROUTED Der Vorgänger wird ausgewählt, da es sich um eine Standard-Cloud-Route der Schnittstelle handelt, während die aktuelle Route eine Route ist, die über Routing-Protokolle (lokal oder remote) erlernt wurde.
LR_ROUTE_TYPE Der Vorgänger wird ausgewählt, da er im Vergleich zum aktuellen eine bessere Route aufweist.
LR_E2DC_REMOTE Der Vorgänger wird ausgewählt, da es sich um eine Edge2DC-Route und eine lokale Route handelt und die aktuelle Route eine Remote-Route ist.
LR_CONNECTED_LAN Bei beiden handelt es sich um verbundene Routen. Der Vorgänger wird ausgewählt, da es sich um eine verbundene LAN-Route handelt und die aktuelle Route keine verbundene LAN-Route ist.
LR_VELO_REMOTE_FLAG Bei beiden handelt es sich um Cloud-Routen. Der Vorgänger wird ausgewählt, weil es sich im Vergleich zur Remote-Cloud-Route um eine Remote-Route handelt, während die aktuelle Route eine lokale Cloud-Route ist.
LR_VELO_EdgeD_ROUTED Bei beiden handelt es sich um Cloud-Routen. Der Vorgänger wird ausgewählt, da es sich um eine per Routing-Protokoll erlernte Route handelt und die aktuelle Route nicht per Routing-Protokoll erlernt wurde.
LR_VELO_PG_ROUTE Bei beiden handelt es sich um Cloud-Routen. Der Vorgänger wird ausgewählt, da es sich um eine PG-Route handelt und die aktuelle Route keine PG-Route ist.
LR_VIA_VELO_ROUTE Bei beiden handelt es sich um Cloud-Routen. Der Vorgänger wird ausgewählt, da es sich um eine Route über VeloCloud handelt und die aktuelle Route keine Route über VeloCloud ist.
LR_REMOTE_NON_ROUTED Beides sind Remote-Routen (Overlay-Routen). Der Vorgänger wird ausgewählt, weil es sich um eine Route handelt, die nicht über ein Routing-Protokoll erlernt wurde (statisch/verbunden), und die aktuelle Route ist eine Route, die über ein Routing-Protokoll erlernt wurde.
LR_REMOTE_DCE_FLAG Beides sind Remote-Routen (Overlay-Routen). Der Vorgänger wird ausgewählt, da es sich um eine Edge-Route des Datencenters handelt („D - DCE“ ist in der Ausgabe „routes“ gesetzt) und die aktuelle Route keine Edge-Route des Datencenters ist.
LR_METRIC Der Vorgänger wird ausgewählt, da er einen niedrigeren Metrikwert als die aktuelle Route aufweist.
LR_ORDER Der Vorgänger wird ausgewählt, da er im Vergleich zur aktuellen Route eine geringere Reihenfolge aufweist.
LR_LOGICAL_ID Der Vorgänger wird ausgewählt, da er über eine bessere logische ID als die aktuelle Route verfügt.
LR_EXT_BGP_VIA_PRIMGW Beides sind BGP-Routen. Der Vorgänger wird ausgewählt, da es sich um eine NSD-BGP-Route handelt, die vom primären NSD-VCG erlernt wurde. Die aktuelle Route wurde möglicherweise vom redundanten NSD-VCG erlernt.
Die folgende Tabelle enthält die Ursachencodes für ein Gateway und die entsprechenden Beschreibungen:
Ursachencode Beschreibung
LR_NO_ELECTION Beste Route.
LR_NVS_STATIC_PREF Der Vorgänger wird ausgewählt, da es sich im Vergleich zur aktuellen Route um eine statische NSD-Route handelt.
LR_EXT_BGP_VS_OSPF Der Vorgänger wird ausgewählt, da es sich um eine BGP-Route handelt und die aktuelle Route eine OSPF-Route mit dem Metriktyp OE1/OE2 ist.
LR_EXT_BGP_ROUTE Bei beiden handelt es sich um Cloud-Routen. Der Vorgänger wird ausgewählt, da es sich im Vergleich zur aktuellen Route um eine BGP-erlernte Cloud-Route handelt (sie ist statisch).
LR_CLOUD_ROUTE_VS_ANY

Der Vorgänger wird ausgewählt, da es sich um eine Edge2Edge- oder Edge2Datacenter-Route handelt und die aktuelle Route eine statische Cloud-Route ist.

Edge2Edge/Edge2Datacenter > Statische Cloud (Cloud static).

LR_BGP_LOCAL_PREF Bei beiden handelt es sich entweder um Edge2Edge- oder Edge2Datacenter-Routen, die über BGP erlernt wurden. Der Vorgänger wird ausgewählt, da er im Vergleich zur aktuellen Route einen höheren lokalen Präferenzwert aufweist.
LR_BGP_ASPATH_LEN Bei beiden handelt es sich entweder um Edge2Edge- oder Edge2Datacenter-Routen, die über BGP erlernt wurden. Der Vorgänger wird ausgewählt, da er im Vergleich zur aktuellen Route einen geringeren AS-Pfadwert aufweist.
LR_BGP_METRIC Bei beiden handelt es sich entweder um Edge2Edge- oder Edge2Datacenter-Routen, die über BGP erlernt wurden. Der Vorgänger wird ausgewählt, da er im Vergleich zur aktuellen Route einen geringeren Metrikwert aufweist.
LR_DCE_NSD_STATIC_PREF Beides sind Edge2Datacenter-Routen. Der Vorgänger wird ausgewählt, da es sich im Vergleich zur aktuellen Route um eine statische NSD-Route handelt.
LR_DCE_NSD_STATIC_METRIC Bei beiden handelt es sich um statische Edge2Datacenter-Routen. Der Vorgänger wird ausgewählt, da er im Vergleich zur aktuellen Route einen geringeren Metrikwert aufweist.
LR_DCE_NSD_STATIC_GW_NON_REMOTE Bei beiden handelt es sich um statische Edge2Datacenter-Routen. Der Vorgänger wird ausgewählt, da es sich um eine lokale Route handelt und die aktuelle Route eine Remote-Route ist.
LR_DCE_LOGICAL_ID Bei beiden handelt es sich um statische Edge2Datacenter-Routen. Der Vorgänger wird ausgewählt, da er im Vergleich zur aktuellen Route eine bessere logische ID aufweist.
LR_E2DC_METRIC Beides sind Edge2Datacenter-Routen. Der Vorgänger wird ausgewählt, da seine Metrik im Vergleich zur aktuellen Route geringer ist.
LR_DC_IPADDR Beides sind Edge2Datacenter-Routen. Der Vorgänger wird ausgewählt, da seine Datencenter-IP-Adresse im Vergleich zur aktuellen Route kleiner ist.
LR_E2DC_NETADDR

Beides sind Edge2Datacenter-Routen. Der Vorgänger wird ausgewählt, da seine Netzwerkadresse im Vergleich zur aktuellen Route kleiner ist.

LR_E2E_PREFERENCE Beides sind Edge2Edge-Routen. Der Vorgänger wird ausgewählt, da sein Voreinstellungswert im Vergleich zur aktuellen Route kleiner ist.
LR_E2E_METRIC Beides sind Edge2Edge-Routen. Der Vorgänger wird ausgewählt, da sein Metrikwert im Vergleich zur aktuellen Route kleiner ist.
LR_E2E_LOGICAL_ID Beides sind Edge2Edge-Routen. Der Vorgänger wird ausgewählt, da er eine bessere logische ID als die aktuelle Route aufweist.
LR_E2E_NETADDR Beides sind Edge2Edge-Routen. Der Vorgänger wird ausgewählt, da seine Netzwerkadresse im Vergleich zur aktuellen Route kleiner ist.
LR_OPG_SECURE_STATIC Der Vorgänger wird ausgewählt, da es sich um eine sichere statische PG-Route handelt und die aktuelle Route keine sichere statische PG-Route ist.
LR_ROUTE_TYPE Der Vorgänger wird ausgewählt, da er einen besseren Routentyp als die aktuelle Route aufweist.
LR_NETMASK

Der Vorgänger wird ausgewählt, da er über eine höhere Netzmaske als die aktuelle verfügt.

LR_METRIC Der Vorgänger wird ausgewählt, da er einen niedrigeren Metrikwert als die aktuelle Route aufweist.
LR_PREFERENCE Bei beiden handelt es sich um Routen, die von Routing-Protokollen erlernt wurden. Der Vorgänger wird ausgewählt, da er einen geringeren Wert für die Voreinstellung als die aktuelle Route aufweist.
LR_NETADDR

Der Vorgänger wird ausgewählt, da seine Netzwerkadresse im Vergleich zur aktuellen Route kleiner als ist.

LR_LOGICAL_ID Der Vorgänger wird ausgewählt, da seine logische ID im Vergleich zur aktuellen Route besser ist.

Quellschnittstellen-Dump (Source Interface Dump)

Führen Sie diesen Test aus, um die Liste der Quellschnittstellen zu sehen, die von verschiedenen Diensten für ein Segment verwendet werden.

Systeminformationen

Führen Sie diesen Test aus, um Systeminformationen wie z. B. die Systemlast, aktuelle Statistiken zur WAN-Stabilität und Überwachungsdienste anzuzeigen. Die WAN-Stabilitätsstatistiken umfassen die Angabe, wie oft die Verbindung mit einzelnen VPN-Tunneln und WAN-Links für mindestens 700 Millisekunden unterbrochen wurde. Die Tunnel-Trennungen enthalten nicht die Anzahl der direkten IPsec-Verbindungen.

Traceroute

Führen Sie eine Traceroute über das Gateway oder direkt über eine der WAN-Schnittstellen zu dem angegebenen Ziel aus.

Fehlerbehebung bei BFD – BFD-/BFDv6-Peer-Status anzeigen (Troubleshoot BFD - Show BFD / BFDv6 Peer Status)

Führen Sie diesen Test aus, um den Status aller BFD-Peers mit IPv4- oder IPv6-Adresse anzuzeigen.

Fehlerbehebung bei BFD – BFD-/BFDv6-Peer-Zähler anzeigen (Troubleshoot BFD - Show BFD/BFDv6 Peer counters)

Führen Sie diesen Test aus, um alle Zähler der BFD-Peers mit IPv4- oder IPv6-Adresse anzuzeigen.

Fehlerbehebung bei BFD – BFD-Einstellung anzeigen (Troubleshoot BFD - Show BFD Setting)

Führen Sie diesen Test aus, um die BFD-Einstellung und den Nachbarstatus anzuzeigen.

Fehlerbehebung bei BFDv6 – BFDv6-Einstellung anzeigen (Troubleshoot BFDv6 - Show BFDv6 Setting)

Führen Sie diesen Test aus, um die BFDv6-Einstellung und den Nachbarstatus anzuzeigen.

BGP-Routen mit mehreren Hops

Über BGP mit mehreren Hops könnte das System Routen lernen, die eine rekursive Suche erfordern. Diese Routen besitzen eine IP-Adresse für den nächsten Hop, der sich nicht in einem angeschlossenen Subnetz befindet, und verfügen nicht über eine gültige Exit-Schnittstelle. In diesem Fall muss auf den Routen die IP-Adresse für nächsten Hop mithilfe einer anderen Route in der Routing-Tabelle aufgelöst werden, die über eine Exit-Schnittstelle verfügt. Wenn Datenverkehr für ein Ziel besteht, für das diese Routen gesucht werden müssen, werden Routen, die eine rekursive Suche erfordern, zu einer verbundenen IP-Adresse und Schnittstelle für nächsten Hop und aufgelöst. Bis zur rekursiven Auflösung verweisen die rekursiven Routen auf eine Zwischenschnittstelle.

Sie können die nicht aufgelösten Routen, die auf die Zwischenoberfläche verweisen, in den folgenden Remote-Diagnosetests anzeigen:

Fehlerbehebung bei BGP – Umverteilte BGP-Routen auflisten

Führen Sie diesen Test aus, um die an BGP-Nachbarn umverteilten Routen anzuzeigen.
Hinweis: Eine nicht aufgelöste Route, die über BGP mit mehreren Hops gelernt wurde, weist möglicherweise auf eine Zwischenschnittstelle hin. Weitere Informationen finden Sie unter BGP-Routen mit mehreren Hops.

Fehlerbehebung bei BGP – BGP-Routen auflisten

Führen Sie diesen Test aus, um die BGP-Routen von Nachbarn anzuzeigen. Sie können das IPv4- oder IPv6-Präfix eingeben, um bestimmte BGP-Routen anzuzeigen, oder das Präfix leer lassen, um alle BGP-Routen anzuzeigen.
Hinweis: Eine nicht aufgelöste Route, die über BGP mit mehreren Hops gelernt wurde, weist möglicherweise auf eine Zwischenschnittstelle hin, wie in der obigen Abbildung gezeigt. Weitere Informationen finden Sie unter BGP-Routen mit mehreren Hops.

Fehlerbehebung bei BGP – Routen nach Präfix auflisten

Führen Sie diesen Test aus, um alle Overlay- und Underlay-Routen für ein bestimmtes IPv4- oder IPv6-Präfix und die zugehörigen Details anzuzeigen.
Hinweis: Eine nicht aufgelöste Route, die über BGP mit mehreren Hops gelernt wurde, weist möglicherweise auf eine Zwischenschnittstelle hin. Weitere Informationen finden Sie unter BGP-Routen mit mehreren Hops.

Fehlerbehebung bei BGP – Annoncierte BGP-Nachbar-Routen anzeigen

Führen Sie diesen Test aus, um die für einen Nachbarn annoncierten BGP-Routen anzuzeigen.

Fehlerbehebung bei BGP – Gelernte BGP-Nachbar-Routen anzeigen

Führen Sie diesen Test aus, um alle von einem Nachbarn gelernten akzeptierten BGP-Routen nach Filtern anzuzeigen.

Fehlerbehebung bei BGP – Empfangene BGP-Nachbar-Routen anzeigen

Führen Sie diesen Test aus, um alle von einem Nachbarn gelernten BGP-Routen vor Filtern anzuzeigen.

Fehlerbehebung bei BGP – Details zum BGP-Nachbarn anzeigen

Führen Sie diesen Test aus, um die Details des BGP-Nachbarn anzuzeigen.

Fehlerbehebung bei BGP – BGP-Routen nach Präfix anzeigen

Führen Sie diesen Test aus, um alle BGP-Routen und ihre Attribute für das angegebene Präfix anzuzeigen.

Fehlerbehebung bei BGP – BGP-Übersicht anzeigen

Führen Sie diesen Test aus, um den vorhandenen BGP-Nachbarn und die empfangenen Routen anzuzeigen.

Fehlerbehebung bei BGP – BGP-Tabelle anzeigen

Führen Sie diesen Test aus, um die BGP-Tabelle anzuzeigen.

Fehlerbehebung bei BGPv6 – Annoncierte BGPv6-Nachbarn-Routen anzeigen

Führen Sie diesen Test aus, um die für einen Nachbarn annoncierten fBGPv6-Routen anzuzeigen.

Fehlerbehebung bei BGPv6 – Gelernte BGPv6-Nachbar-Routen anzeigen

Führen Sie diesen Test aus, um alle von einem Nachbarn gelernten akzeptierten BGPv6-Routen nach Filtern anzuzeigen.

Fehlerbehebung bei BGPv6 – Empfangene BGPv6-Nachbarn-Routen anzeigen

Führen Sie diesen Test aus, um alle von einem Nachbarn empfangenen BGPv6-Routen vor Filtern anzuzeigen.

Fehlerbehebung bei BGPv6 – BGPv6-Nachbarn-Details anzeigen

Führen Sie diesen Test aus, um die Details des BGPv6-Nachbarn anzuzeigen.

Fehlerbehebung bei BGPv6 – BGPv6-Routen nach Präfix anzeigen

Führen Sie diesen Test aus, um alle BGPv6-Routen für das Präfix und deren Attribute anzuzeigen.

Fehlerbehebung bei BGPv6 – BGPv6-Übersicht anzeigen

Führen Sie diesen Test aus, um den vorhandenen BGPv6-Nachbarn und die empfangenen Routen anzuzeigen.

Fehlerbehebung bei BGPv6 – BGPv6-Tabelle anzeigen

Führen Sie diesen Test aus, um die Details der BGPv6-Tabelle anzuzeigen.

Fehlerbehebung bei OSPF – Umverteilte OSPF-Routen auflisten (Troubleshoot OSPF - List OSPF Redistributed Routes)

Führen Sie diesen Test aus, um alle an den OSPF-Nachbarn umverteilten Routen anzuzeigen.

Fehlerbehebung bei OSPF – OSPF-Routen auflisten (Troubleshoot OSPF - List OSPF Routes)

Führen Sie diesen Test aus, um die von OSPF-Nachbarn erlernten OSPF-Routen für das angegebene Präfix anzuzeigen. Zeigt alle OSPF-Routen von Nachbarn an, wenn das Präfix nicht angegeben ist. Dieser Test zeigt OSPF-Routen mit Aktionen an, wie z. B. eingehender Filter mit angewendeter Overlay-Flow-Steuerung aus Orchestrator.

Fehlerbehebung bei OSPF – OSPF-Datenbank anzeigen (Troubleshoot OSPF - Show OSPF Database)

Führen Sie diesen Test aus, um die Zusammenfassung der OSPF-Verbindungsstatus-Datenbank anzuzeigen.

Fehlerbehebung bei OSPF – OSPF-Datenbank für E1-Self-Originate-Routen (Troubleshoot OSPF - Show OSPF Database for E1 Self-Originate Routes)

Führen Sie diesen Test aus, um die selbst erstellten E1 LSA-Routen anzuzeigen, die OSPF-Routern vom Edge annonciert wurden.

Fehlerbehebung bei OSPF – OSPF-Nachbarn anzeigen (Troubleshoot OSPF - Show OSPF Neighbors)

Führen Sie diesen Test aus, um alle OSPF-Nachbarn und zugehörige Informationen anzuzeigen.

Fehlerbehebung bei OSPF – OSPF-Routentabelle anzeigen (Troubleshoot OSPF - Show OSPF Route Table)

Führen Sie diesen Test aus, um die vorhandene OSPF-Routentabelle anzuzeigen, in der OSPF-Informationen aus erlernten und neu verteilten Routen angezeigt werden.

Fehlerbehebung bei OSPF – OSPF-Einstellung anzeigen (Troubleshoot OSPF - Show OSPF Setting)

Führen Sie diesen Test aus, um die OSPF-Einstellung und den Status des Nachbarn anzuzeigen.

USB-Port-Status

Führen Sie diesen Test aus, um den Status der USB-Ports auf einem Edge anzuzeigen.

VPN-Test (VPN Test)

Wählen Sie ein Segment aus dem Dropdown-Menü aus und klicken Sie auf Ausführen (Run), um die VPN-Konnektivität zu jedem Peer zu testen.
Wenn der VPN-Test ausgeführt wird, wählt der Edge die Quell- und Ziel-IP aus und initiiert die Tunnelanforderung. Die ausgewählte Quell- und Ziel-IP sollte die folgenden Kriterien erfüllen:
  • Es sollte sich um eine verbundene Routen-IP-Adresse handeln.
  • Sie sollte erreichbar sein und die Routen sollten annonciert werden.

Wenn der Edge keine gültige IP-Adresse als Quell-IP zum Initiieren der Tunnelanforderung auswählen kann, schlägt der VPN-Test mit dem folgenden Fehler fehl.

Branch-to-Branch vpn is disabled. Please enable it before running the test

Bandbreitentest für WAN-Link (WAN Link Bandwidth Test)

Führen Sie den Bandbreitentest für einen angegebenen WAN-Link aus. Dieser Test hat den Vorteil, dass es in Umgebungen mit Mehrfachverknüpfungen nicht zu Störungen kommt. Nur der zu testende Link ist für den Benutzerdatenverkehr gesperrt. Das bedeutet, dass Sie den Test auf einem bestimmten Link erneut ausführen können und der bzw. die anderen Links weiterhin dem Benutzerdatenverkehr dienen.

Da der Bandbreitentest durchgeführt wird, wenn der Tunnel nach einer Zeit der Instabilität wieder eine Verbindung herstellt, gab es in der Praxis Fälle, in denen sich der Link zwar genügend für eine Tunnelkonnektivität erholt hat, aber nicht genug, um die Bandbreite des WAN-Links genau zu messen. Um diesen Szenarien Rechnung zu tragen, wird, falls der Bandbreitentest fehlschlägt oder einen deutlich reduzierten Wert misst, die letzte bekannte „fehlerfreie“ Messung verwendet und ein erneuter Link-Test für 30 Minuten nach der Einrichtung des Tunnels geplant, um eine ordnungsgemäße Messung zu gewährleisten.

Hinweis: Für WAN-Links über 900 MBit/s wird empfohlen, dass der Benutzer die Bandbreite des WAN-Links definiert.