Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Premesse

Calcolo delle statistiche delle prestazioni del tunnel

Esempi di relazione tra valori BFD e perdita

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.

Questo valore determina il numero di bucket.

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

Nota: per ogni calcolo eseguito vengono presentati solo i valori interi. Anche se decimal è il risultato esatto, i valori interi vengono arrotondati all'intero più basso.

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