Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Antecedentes

Cálculo de Estadísticas de Rendimiento del Túnel

Ejemplos de relación entre los valores de BFD y la pérdida

Introducción

Este documento describe la relación que existe entre los paquetes Hello de BFD y las estadísticas del Túnel de Ruteo con Reconocimiento de Aplicaciones .

Prerequisites

Requirements

Cisco le recomienda que tenga conocimiento acerca de estos temas:

- Red de área extensa definida por software (SD-WAN) Cisco Catalyst.

- Routing con reconocimiento de aplicaciones.

- BFD.

Componentes Utilizados

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

- Administrador de SD-WAN de Cisco Catalyst.

- Cisco IOS® XE Catalyst SD-WAN Edges.

Antecedentes

El protocolo de detección de reenvío bidireccional (BFD) se ejecuta en todos los túneles del plano de datos entre los dispositivos Cisco IOS-XE Catalyst SD-WAN. Este protocolo se utiliza para supervisar la actividad y las características de la ruta de los túneles, como el rendimiento del túnel notificado como pérdida, fluctuación y latencia.

Los dispositivos periféricos utilizan sondas Hello BFD para proporcionar una medición de la pérdida de paquetes, la fluctuación y la latencia en el túnel. Estas estadísticas se calculan para cada sonda Hello BFD y se toman sobre una ventana de tiempo deslizante llamada intervalo de sondeo.

El routing con reconocimiento de aplicaciones utiliza estas estadísticas de pérdidas, latencia y fluctuación para entregar el tráfico según los requisitos establecidos en la política, denominadas clases de SLA, en las que se determina la pérdida, fluctuación y latencia máximas permitidas en el túnel seleccionado para entregar los datos.

Debido a esto, es muy importante entender cómo se calculan las medidas y cómo un cambio en los valores de BFD puede afectar al cálculo del rendimiento del túnel principalmente significa pérdida. Los parámetros BFD son:

Parámetro

Valor Predeterminado

Rango

Uso

intervalo hello BFD

1 segundo

De 1 a 65535 segundos

Paquetes para detectar la actividad de la conexión de túnel y para detectar fallos en el túnel.

Intervalo de sondeo

10 minutos

(600.000 milisegundos)

De 1 a 4.294.967 milisegundos

Frecuencia con la que se calcula una medida de depósito para proporcionar estadísticas.

Multiplicador

6

1 a 6

Valor que multiplica el intervalo de sondeo para especificar el tiempo para calcular la pérdida media, la latencia media y la fluctuación media.

Este valor determina el número de depósitos.

Cálculo de Estadísticas de Rendimiento del Túnel

Para los parámetros BFD establecidos como predeterminados, el cálculo de las estadísticas se realiza de la siguiente manera:

Intervalo de sondeo / Intervalo de saludo BFD = 600.000 ms / 1.000 ms = 600 saludos BFD por cubeta.

Dado que el multiplicador se establece en 6, significa que se utilizan 6 bloques para calcular la latencia, fluctuación y pérdida medias. Con los valores predeterminados, esto equivale a 1 hora. Este tiempo total también se conoce como intervalo de ruta de la aplicación.

Intervalo de ruta de aplicación = Intervalo de sondeo * multiplicador = 600.000 ms x 6 = 3.600.000 ms igual a 1 hora.

Los cálculos de las estadísticas de App-route son utilizados por App-Aware Routing para determinar los cambios en el plano de datos. Para que un dispositivo perimetral aproveche las estadísticas de ruta de aplicación, las clases de SLA deben especificarse en la política AAR en la que se establece la fluctuación, pérdida y latencia de paquetes máxima aceptable. Estas clases de SLA se utilizan en la política de AAR para enrutar el tráfico de las aplicaciones especificadas de acuerdo con los SLA.

Una vez configuradas en un dispositivo Edge, las estadísticas de AAR se utilizan para comparar con la pérdida media, la latencia media y la fluctuación media proporcionadas por las estadísticas calculadas con todos los bloques (durante todo el intervalo de ruta de la aplicación). También es importante tener en cuenta que los SLA se actualizan después de cada intervalo de sondeo, cada diez minutos de forma predeterminada.

Para obtener la pérdida media, la fluctuación media y la latencia media, las ecuaciones utilizadas son:

Pérdida media = (pérdida total en todos los bloques * 100) / Paquetes totales.

Latencia media = (pérdida total de todos los períodos) / cantidad de períodos.

Fluctuación media = (fluctuación total en todos los depósitos) / cantidad de depósitos.

El cálculo de esos valores junto con el promedio de cada cubeta se puede revisar en la CLI con:

vEdge#show app-route stats

cEdge#show sdwan app-route stats

Mientras se esté en la GUI, las pérdidas medias, la latencia media y la fluctuación media sólo se pueden revisar en la sección Monitor > Overview > Application-Aware Routing .

También se puede revisar en la sección Monitor > Devices > Select Device > WAN > Tunnel.

Ejemplos de relación entre los valores de BFD y la pérdida

Dado que los saludos BFD son valores configurables, pueden modificarse en función de los requisitos; sin embargo, es importante modificarlos después de una cuidadosa consideración; de lo contrario, se pueden recibir cálculos sesgados o estadísticas de falsos positivos, ya que la precisión del cálculo de la pérdida media depende de los valores BFD. Por ejemplo, con valores predeterminados de:

Parámetro

predeterminado

paquete de saludo BFD

1 segundo

Intervalo de sondeo

(600.000 milisegundos)

10 minutos

Multiplicador

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

Pérdida media = ((7+5+13+4+5+12)100)/ (596+596+597+594+596+594)

= 4600/3573

= 1,28-1%

Latencia media = (110+111+111+111+110+111)/6

= 110,66 ~ 110 ms

Fluctuación media = (50+50+53+53+50+50) / 6

= 3 /6 = 51 ms

Nota: Para cada cálculo realizado, sólo se presentan valores enteros. Incluso cuando decimal es el resultado exacto, los valores enteros se redondean al entero inferior más cercano.

Normalmente, es una buena opción modificar estos valores para realizar el cálculo con más frecuencia, pero puede causar un impacto significativo; por ejemplo, si en lugar de los valores predeterminados, el intervalo de sondeo se modifica para:

Parámetro

predeterminado

paquete de saludo BFD

1 segundo

Intervalo de sondeo

(60.000 milisegundos)

1 min

Multiplicador

6

Este cambio significa que utiliza 1 x 60 = 60 paquetes por cubeta en lugar de 600 como valor predeterminado. El resultado de la pérdida media es:

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

Pérdida media = ((1+3+1+3+2+1)*100)/(59+60+59+60+60+59)

= (100)/ 357

= 3,08 ~ 3%

En este punto, si por ejemplo, la clase SLA se establece en una Pérdida Máxima de 3, entonces el túnel está por debajo del límite de la violación del SLA. Sin embargo, si el intervalo de sondeo se modifica a:

Parámetro

predeterminado

paquete de saludo BFD

1 segundo

Intervalo de sondeo

(6.000 milisegundos)

1 segundo

Multiplicador

6

Este cambio significa que utiliza 1 x 6 = 6 paquetes por cubeta en lugar de 600 como valor predeterminado. El resultado de la pérdida media es:

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

Pérdida media = ((5)100)/(5+6+6+6+6+6)

= (500)/29

= 17,24-17%

Si el intervalo de sondeo se reduce sin la validación correcta de cuántos paquetes se utilizan para medir, puede afectar la pérdida media, lo mismo puede aplicarse si el intervalo hello de bfd se incrementa sin aumentar el intervalo de pool.

En el último ejemplo, como se utilizan muy pocos paquetes para hacer el cálculo, con sólo un paquete perdido, la pérdida media puede verse afectada significativamente. El resultado de estos cálculos es un comportamiento de política con reconocimiento de aplicaciones con varias y muy frecuentes conmutaciones por error.

El propósito de esta explicación no es evitar la modificación de esos valores, por el contrario, en muchas situaciones es necesario modificar esas sondas. Esto depende completamente de los requisitos de la red, pero es muy importante revisar cuánto se pueden disminuir esos paquetes de saludo.

El comando de configuración para modificar globalmente el intervalo de sondeo es:

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