Verständnis der Beziehung zwischen BFD-Protokoll und anwendungssensitivem Routing

Einleitung

In diesem Dokument wird die Beziehung zwischen den BFD-Hello-Paketen und den Statistiken des anwendungssensitiven Routing-Tunnels beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Cisco Catalyst Software-Defined Wide Area Network (SD-WAN)
• Anwendungssensitives Routing.
• BFD

Verwendete Komponenten

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

• Cisco Catalyst SD-WAN Manager
• Cisco IOS® XE Catalyst SD-WAN-Edges.

Hintergrundinformationen

Das BFD-Protokoll (Bidirectional Forwarding Detection) wird über alle Tunnel der Datenebene zwischen Cisco IOS-XE Catalyst SD-WAN-Geräten ausgeführt. Dieses Protokoll wird verwendet, um die Lebensdauer und die Pfadmerkmale der Tunnel zu überwachen, z. B. die Tunnelleistung, die als Verlust, Jitter und Latenz gemeldet wird.

Edge-Geräte verwenden BFD Hello-Tests, um Paketverluste, Jitter und Latenz im Tunnel zu messen. Diese Statistiken werden für jeden BFD Hello-Test berechnet und über ein gleitendes Zeitfenster übernommen, das als Abfrageintervall bezeichnet wird.

Diese Statistiken zu Verlusten, Latenz und Jitter werden von App-Aware Routing verwendet, um den Datenverkehr auf der Grundlage der Anforderungen bereitzustellen, die in der Richtlinie, den so genannten SLA-Klassen, festgelegt sind. In dieser Richtlinie wird der maximal zulässige Verlust, Jitter und die maximale Latenz bestimmt, die in dem Tunnel zulässig sind, der zur Bereitstellung der Daten ausgewählt wurde.

Aus diesem Grund ist es sehr wichtig zu verstehen, wie die Messgrößen berechnet werden und wie sich eine Änderung der BFD-Werte auf die Tunnelleistungsberechnung auswirken kann, und zwar hauptsächlich auf den Mittelwert der Verluste. Die BFD-Parameter sind:

Parameter	Standardwert	Bereich	Nutzung
BFD Hello-Intervall	1 Sekunde	1 bis 65535 Sekunden	Pakete zur Erkennung der Lebensdauer der Tunnelverbindung und von Fehlern im Tunnel.
Polling-Intervall	10 Minuten 600.000 Millisekunden	1 bis 4.294.967 Millisekunden	Legt fest, wie oft ein Bucket-Measure berechnet wird, um Statistiken bereitzustellen.
Multiplikator	6	1 bis 6	Wert, der das Abfrageintervall multipliziert, um die Zeit für die Berechnung des mittleren Verlusts, der mittleren Latenz und des mittleren Jitters anzugeben. Dieser Wert bestimmt die Anzahl der Buckets.

Berechnung der Tunnel-Leistungsstatistik

Für standardmäßig eingestellte BFD-Parameter wird die Statistik wie folgt berechnet:

Polling-Intervall/BFD Hello-Intervall = 600.000 ms/1.000 ms = 600 BFD Hellos pro Bucket.

Da der Multiplikator auf 6 festgelegt ist, werden 6 Buckets verwendet, um die durchschnittliche Latenz, den Jitter und den Verlust zu berechnen. Bei den Standardwerten entspricht dies 1 Stunde. Diese Gesamtzeit wird auch als App-Routen-Intervall bezeichnet.

App-Route-Intervall = Polling-Intervall * Multiplikator = 600.000 ms x 6 = 3.600.000 ms = 1 Stunde

Die Berechnungen der App-Routing-Statistiken werden von App-Aware Routing verwendet, um Änderungen auf Datenebene zu ermitteln. Damit ein Edge-Gerät die App-Routing-Statistiken nutzen kann, müssen in der AAR-Richtlinie SLA-Klassen festgelegt werden, in denen der maximal zulässige Paketjitter, -verlust und -latenz festgelegt sind. Diese SLA-Klassen werden in der AAR-Richtlinie verwendet, um den Datenverkehr für bestimmte Anwendungen gemäß den SLAs weiterzuleiten.  

Nach der Konfiguration in einem Edge-Gerät werden die AAR-Statistiken für den Vergleich mit dem mittleren Verlust, der mittleren Latenz und dem mittleren Jitter verwendet, der durch die mit allen Buckets (über das gesamte App-Routen-Intervall) berechnete Statistik bereitgestellt wird. Beachten Sie außerdem, dass die SLAs nach jedem Abfrageintervall standardmäßig alle zehn Minuten aktualisiert werden.

Um den mittleren Verlust, den mittleren Jitter und die mittlere Latenz zu erhalten, werden folgende Gleichungen verwendet:

Mittlerer Verlust = (Gesamtverlust über alle Buckets * 100) / Gesamtpakete.

Mittlere Latenz = (Gesamtverlust über alle Zeiträume hinweg)/Anzahl Zeiträume.

Mittlerer Jitter = (Gesamt-Jitter für alle Gruppen)/Anzahl der Gruppen

Die Berechnung dieser Werte zusammen mit dem Durchschnitt der einzelnen Buckets kann in der CLI wie folgt überprüft werden:

vEdge#show app-route stats

cEdge#show sdwan app-route stats

Während der Ausführung in der GUI können der mittlere Verlust, die mittlere Latenz und der mittlere Jitter nur im Abschnitt Monitor > Overview > Application-Aware Routing (Überwachen > anwendungssensitives Routing) überprüft werden.

Sie kann auch im Abschnitt Monitor > Devices > Select Device > WAN > Tunnel überprüft werden.

Beispiele für BFD-Wertbeziehung mit Verlust

Da es sich bei BFD Hellos um konfigurierbare Werte handelt, können diese je nach Anforderung geändert werden. Es ist jedoch wichtig, sie nach sorgfältiger Überlegung zu ändern, da sonst verzerrte Berechnungen oder falsch positive Statistiken empfangen werden können, da die Genauigkeit der mittleren Verlustberechnung von den BFD-Werten abhängt. Beispielsweise mit Standardwerten von:

Parameter	standard
BFD-Hello-Paket	1 Sekunde
Polling-Intervall	600.000 Millisekunden 10 Minuten
Multiplikator	6

vEdge1# show app-route stats
app-route statistics 10.100.100.2 10.200.200.4 ipsec 12366 12346 
remote-system-ip 10.1.1.1 
local-color      private1 
remote-color     private1 
mean-loss        1 
mean-latency     110 
mean-jitter      51 
sla-class-index  0,2 
IPV6 TX  IPV6 RX 
TOTAL          AVERAGE  AVERAGE  TX DATA  RX DATA  DATA     DATA 
INDEX  PACKETS  LOSS  LATENCY  JITTER   PKTS     PKTS     PKTS     PKTS 
---------------------------------------------------------------------------- 
0     596       7     110      50        0        0        0        0 
1     596       5     111      50        0        1        0        0 
2     597      13     111      53        0        0        0        0 
3     594       4     111      53        0        0        0        0 
4     596       5     110      50        0        0        0        0 
5     594      12     111      50        0        2        0        0 

Mittlerer Verlust = (7+5+13+4+5+12)100)/ (596+596+597+594+596+594)

          = 4600/3573

          = 1,28 ~ 1 %

Mittlere Latenz = (110+111+111+111+110+111)/6

             = 110,66 ~ 110 ms

Mittlerer Jitter = (50+50+53+53+50+50)/6

            = 3 /6 = 51 ms

Hinweis: Für jede durchgeführte Berechnung werden nur ganzzahlige Werte angezeigt. Selbst wenn decimal das exakte Ergebnis ist, werden ganzzahlige Werte auf die nächstliegende ganze Zahl gerundet.

Normalerweise ist eine gute Option, um diese Werte zu ändern, damit die Berechnung häufiger durchgeführt wird. Dies kann jedoch erhebliche Auswirkungen haben. Beispiel: Wenn anstelle von Standardwerten das Abfrageintervall wie folgt geändert wird:

Parameter	standard
BFD-Hello-Paket	1 Sekunde
Polling-Intervall	60.000 Millisekunden 1 Minute
Multiplikator	6

Diese Änderung bedeutet, dass 1 x 60 = 60 Pakete pro Bucket anstatt standardmäßig 600 verwendet werden. Das Ergebnis des mittleren Verlustes ist:

vEdge1# show app-route stats
app-route statistics 10.100.100.2 10.200.200.4 ipsec 12366 12346
remote-system-ip 10.1.1.1
local-color      private1
remote-color     private1
mean-loss        3
mean-latency     112 
mean-jitter      51 
sla-class-index  0,2 
IPV6 TX  IPV6 RX 
TOTAL          AVERAGE  AVERAGE  TX DATA  RX DATA  DATA     DATA 
INDEX  PACKETS  LOSS  LATENCY  JITTER   PKTS     PKTS     PKTS     PKTS 
---------------------------------------------------------------------------- 
0     59       1     113      53        0        0        0        0
1     60       3     111      52        0        1        0        0 
2     59       1     111      51        0        1        0        0 
3     60       3     111      50        0        1        0        0 
4     60       2     115      50        0        0        0        0 
5     59       1     111      50        0        2        0        0 

Mittlerer Verlust = ((1+3+1+3+2+1)*100)/(59+60+59+60+60+59)

          = (1100)/ 357

          = 3,08 ~ 3 %

Wenn an diesem Punkt z. B. die SLA-Klasse auf "Maximum Loss" (Maximaler Verlust) von 3 festgelegt ist, befindet sich der Tunnel unter der Grenze der Verletzung des SLA. Wenn das Abfrageintervall jedoch wie folgt geändert wird:

Parameter	standard
BFD-Hello-Paket	1 Sekunde
Polling-Intervall	6.000 Millisekunden 1 Sekunde
Multiplikator	6

Diese Änderung bedeutet, dass statt 600 standardmäßig 1 x 6 = 6 Pakete pro Bucket verwendet werden. Das Ergebnis des mittleren Verlustes ist:

vEdge1# show app-route stats
app-route statistics 10.100.100.2 10.200.200.4 ipsec 12366 12346 
remote-system-ip 10.1.1.1 
local-color      private1 
remote-color     private1 
mean-loss        17
mean-latency     110 
mean-jitter      0 
sla-class-index  None
IPV6 TX  IPV6 RX 
TOTAL          AVERAGE  AVERAGE  TX DATA  RX DATA  DATA     DATA 
INDEX  PACKETS  LOSS  LATENCY  JITTER   PKTS     PKTS     PKTS     PKTS 
---------------------------------------------------------------------------- 
0     5       1     113      2        0        0        0        0 
1     6       1     110      1        0        1        0        0 
2     6       1     111      2        0        0        0        0 
3     6       0     111      0        0        0        0        0 
4     6       1     111      0        0        0        0        0 
5     6       1     111      0        0        2        0        0 

Mittlerer Verlust = ((5)100)/(5+6+6+6+6)

          = (500)/29

          = 17,24 ~ 17 %

Unabhängig davon, ob das Abfrageintervall reduziert wird, ohne dass die Anzahl der Pakete, die gemessen werden müssen, korrekt validiert wurde, kann es den mittleren Verlust beeinflussen. Dasselbe gilt, wenn das bfd Hello-Intervall erhöht wird, ohne dass das Pool-Intervall erhöht wird.

Da im letzten Beispiel nur sehr wenige Pakete für die Berechnung verwendet werden und nur ein Paket verloren geht, kann der mittlere Verlust erheblich beeinflusst werden. Das Ergebnis dieser Berechnungen ist ein anwendungssensitives Richtlinienverhalten mit mehreren und sehr häufigen Failover-Vorgängen.

Der Zweck dieser Erklärung ist nicht zu vermeiden, die Änderung dieser Werte, im Gegenteil, in vielen Fällen müssen diese Sonden geändert werden. Dies hängt vollständig von den Netzwerkanforderungen ab, es ist jedoch sehr wichtig zu prüfen, um wie viel diese Hello-Pakete reduziert werden können.

Der Konfigurationsbefehl, mit dem das Abfrageintervall global geändert wird, lautet:

vEdge(config)# bfd app-route poll-interval 600000