Comprendere la relazione del protocollo BFD con il routing compatibile con le applicazioni
Introduzione
Questo documento descrive la relazione esistente tra i pacchetti BFD Hello e le statistiche del tunnel di routing compatibile con app.
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza dei seguenti argomenti:
- Software Cisco Catalyst Defined Wide Area Network (SD-WAN).
- Routing Compatibile Con App.
- DCF.
Componenti usati
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
- Cisco Catalyst SD-WAN Manager.
- Bordi Cisco IOS® XE Catalyst SD-WAN.
Premesse
Il protocollo BFD (Bidirectional Forwarding Detection) viene eseguito su tutti i tunnel del piano dati tra i dispositivi Cisco IOS-XE Catalyst SD-WAN. Questo protocollo è usato per monitorare la condizione di vita e le caratteristiche del percorso dei tunnel, ad esempio le prestazioni del tunnel indicate come Perdita, Jitter e Latenza.
I dispositivi Edge usano le sonde BFD Hello per misurare la perdita, lo jitter e la latenza dei pacchetti sul tunnel. Queste statistiche vengono calcolate per ogni sonda BFD Hello e vengono rilevate in una finestra temporale scorrevole denominata intervallo di polling.
Queste statistiche su perdita, latenza e jitter vengono utilizzate dal routing compatibile con app per distribuire il traffico in base ai requisiti impostati nella policy, dette classi SLA, in cui determina la perdita, l'jitter e la latenza massime consentiti nel tunnel selezionato per il recapito dei dati.
Per questo motivo, è molto importante capire come vengono calcolate le misure e come una modifica dei valori BFD possa influire sul calcolo delle prestazioni del tunnel, principalmente per quanto riguarda la perdita media. I parametri BFD sono:
| Parametro |
Valore predefinito |
Intervallo |
Utilizzo |
| Intervallo hello BFD |
1 secondo |
da 1 a 65535 secondi |
Pacchetti per rilevare la durata della connessione del tunnel e rilevare gli errori sul tunnel. |
| Intervallo di polling |
10 minuti (600.000 millisecondi) |
da 1 a 4.294.967 millisecondi |
Frequenza con cui viene calcolata una misura di intervallo per fornire statistiche. |
| Moltiplicatore |
6 |
da 1 a 6 |
Valore che moltiplica l'intervallo di polling per specificare l'ora in cui calcolare la perdita media, la latenza media e il jitter medio. |
Calcolo delle statistiche delle prestazioni del tunnel
Per i parametri BFD impostati come predefiniti, il calcolo delle statistiche viene eseguito nel modo seguente:
Intervallo di polling / intervallo Hello BFD = 600.000 ms / 1000 ms = 600 BFD Hellos per bucket.
Poiché il moltiplicatore è impostato su 6, per calcolare la latenza media, l'oscillazione e la perdita vengono utilizzati 6 periodi fissi. Con i valori predefiniti è uguale a 1 ora. Questo tempo totale è anche noto come intervallo di route dell'applicazione.
Intervallo route applicazione = Intervallo di polling * Moltiplicatore = 600.000 ms x 6 = 3.600.000 ms uguale a 1 ora.
I calcoli delle statistiche di route dell'app vengono utilizzati dal routing compatibile con l'app per determinare le modifiche nel piano dati. Affinché un dispositivo Edge possa trarre vantaggio dalle statistiche di route dell'app, è necessario specificare le classi SLA nei criteri AAR in cui è impostato il livello massimo accettabile di jitter, perdita e latenza dei pacchetti. Queste classi SLA vengono utilizzate nei criteri AAR per instradare il traffico delle applicazioni specificate in base agli SLA.
Una volta configurate in un dispositivo Edge, le statistiche AAR vengono utilizzate per confrontare la perdita media, la latenza media e il jitter medio forniti dalle statistiche calcolate con tutti i bucket (sull'intero intervallo app-route). È inoltre importante notare che, per impostazione predefinita, gli SLA vengono aggiornati ogni dieci minuti dopo ogni intervallo di polling.
Per ottenere la perdita media, il jitter medio e la latenza media, vengono utilizzate le equazioni riportate di seguito.
Perdita media = (perdita totale in tutti i bucket * 100) / pacchetti totali.
Latenza media = (perdita totale in tutti i periodi fissi) / importo dei periodi fissi.
Variazione media = (variazione totale in tutti i periodi fissi) / importo del periodo fisso.
Il calcolo di questi valori insieme alla media di ciascun bucket può essere esaminato nella CLI con:
vEdge#show app-route stats
cEdge#show sdwan app-route stats
Nella GUI, la perdita media, la latenza media e il solo jitter medio possono essere rivisti nella sezione Monitor > Panoramica > Routing compatibile con le applicazioni.
Può anche essere rivisto nella sezione Monitor > Devices > Select Device > WAN > Tunnel.
Esempi di relazione tra valori BFD e perdita
Poiché gli eluenti dei dati di riferimento sono valori configurabili, possono essere modificati in base ai requisiti; tuttavia, è importante modificarli dopo un'attenta considerazione, altrimenti è possibile ottenere calcoli distorti o statistiche false positive poiché l'accuratezza del calcolo della perdita media dipende dai valori dei dati di riferimento. Ad esempio, con i valori predefiniti di:
| Parametro |
predefinito |
| Pacchetto hello BFD |
1 secondo |
| Intervallo di polling |
(600.000 millisecondi) 10 minuti |
| Moltiplicatore |
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
Perdita media = ((7+5+13+4+5+12)100)/ (596+596+597+594+596+594)
= 4600/3573
= 1,28 ~ 1%
Latenza media = (110+111+111+111+110+111)/6
= 110,66 ~ 110 ms
Variazione media = (50+50+53+53+50+50) / 6
= 3 /6 = 51 ms
In genere, è consigliabile modificare questi valori per rendere il calcolo più frequente, ma può causare un impatto significativo; ad esempio, se invece dei valori predefiniti, l'intervallo di polling viene modificato in:
| Parametro |
predefinito |
| Pacchetto hello BFD |
1 secondo |
| Intervallo di polling |
(60.000 millisecondi) 1 min. |
| Moltiplicatore |
6 |
Questa modifica significa che utilizza 1 x 60 = 60 pacchetti per bucket invece di 600 come impostazione predefinita. Il risultato della perdita media è il seguente:
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
Perdita media = ((1+3+1+3+2+1)*100)/(59+60+59+60+60+59)
= (1100)/ 357
= 3,08 ~ 3%
A questo punto, se ad esempio la classe SLA è impostata su Perdita massima pari a 3, il tunnel è al di sotto del limite della violazione del contratto di servizio. Tuttavia, se l'intervallo di polling viene modificato in:
| Parametro |
predefinito |
| Pacchetto hello BFD |
1 secondo |
| Intervallo di polling |
(6.000 millisecondi) 1 secondo |
| Moltiplicatore |
6 |
Questa modifica significa che utilizza 1 x 6 = 6 pacchetti per bucket invece di 600 come impostazione predefinita. Il risultato della perdita media è il seguente:
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
Perdita media = ((5)100)/(5+6+6+6+6+6)
= (500)/29
= 17,24 ~ 17%
Se l'intervallo di polling viene ridotto senza la corretta convalida del numero di pacchetti utilizzati per la misurazione, può influire sulla perdita media, lo stesso può valere se l'intervallo hello bfd viene aumentato senza aumentare l'intervallo pool.
Nell'ultimo esempio, poiché il numero di pacchetti utilizzati per il calcolo è molto basso, con un solo pacchetto perso, la perdita media può subire un impatto significativo. Il risultato di questi calcoli è un comportamento delle policy compatibile con l'app con failover multipli e molto frequenti.
Lo scopo di questa spiegazione non è quello di evitare la modifica di tali valori, al contrario, in molte situazioni tali sonde sono necessarie per essere modificate. Questo dipende completamente dai requisiti della rete, ma è molto importante verificare quanto quei pacchetti hello possano essere ridotti.
Il comando di configurazione per modificare globalmente l'intervallo di polling è:
vEdge(config)# bfd app-route poll-interval 600000
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
1.0 |
02-Feb-2024 |
Versione iniziale |
Feedback