Comprender la relación del protocolo BFD con el routing con reconocimiento de aplicaciones
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. |
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
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
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
1.0 |
02-Feb-2024 |
Versión inicial |
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)