Introducción
En mi anterior serie de publicaciones, exploré Application Aware Routing (AAR) en profundidad, una tecnología clave en SD-WAN que dirige el tráfico sobre los transportes con mejor rendimiento. Si bien AAR ha sido una capacidad fundamental durante años, la evolución de las redes trajo nuevas ideas para mejorar su efectividad. Esto condujo a la introducción de Enhanced Application Aware Routing (EAAR).
Limitaciones de AAR
Antes de sumergirnos en EAAR, entendamos por qué fue creado. 🤓
La implementación actual de AAR mide la calidad del transporte utilizando BFD, enviando probes a un intervalo definido (1s por defecto). La pérdida, la latencia y jitter se derivan de esos paquetes y estos valores se colocan en cubetas que van rotando para calcular una métrica promedio que representa la salud del túnel. Este proceso generalmente toma entre 10 y 60 minutos y con algunos ajustes de configuración es posible lograr tiempos de 2 a 10 minutos.
Para aquellas redes que requieren una detección más rápida, surgen algunos desafíos:
- Bajar el intervalo de hello a menos de 1 segundo afecta la escala de túneles del dispositivo
- Bajar el multiplicador de BFD y el poll interval podrían conducir a falsos positivos, moviendo el tráfico incluso con condiciones de red transitorias.
- Cambio constante del tráfico de un lado a otro, no hay un mecanismo para determinar si un transporte es estable nuevamente después de un evento de degradación de la red.
Enhanced AAR
Entonces, ¿qué es EAAR y cómo mejora a su predecesor? 🤔
En pocas palabras, estas son las ventajas:
- Utiliza inline data en lugar de BFD. En otras palabras, los paquetes de plano de datos se utilizan para medir la pérdida, la latencia y el jitter.
- Capacidad de mover el tráfico en segundos en lugar de minutos
- Amortiguación (Dampening) implementada para propósitos de estabilidad, asegurando que los transportes sean estables antes de reenviar el tráfico a través de ellos.
- Medición más precisa de pérdida, latencia y jitter
Vamos por partes
Cuando EAAR está habilitado, los paquetes de datos se utilizarán para medir la pérdida, la latencia y la jitter. Entendamos las diferencias clave:
Medición de pérdida
Los routeres SD-WAN utilizarán inline data junto con los números de secuencia IPSEC para medir la pérdida.
Hay un mecanismo incorporado que permite a los routers determinar si la pérdida es local para el router
- Pérdida local - Por lo general, debido a caídas de QoS
O externo al router
- Pérdida de WAN - Cualquier pérdida de paquetes fuera del router
Para calcular la pérdida local, el router determinará la cantidad de paquetes que generó en comparación con la cantidad de paquetes que realmente fueron enviados. Para obtener la pérdida en el WAN, los routers SD-WAN vecinos informarán la cantidad de paquetes recibidos y utilizarán BFD (TLVs de Monitoreo de Ruta) para enviar esta información de vuelta al router original.
Hasta este punto, existe una mejora importante en cómo se realiza la medición de pérdidas, sin embargo, esto podría mejorarse aún más al aprovechar mediciones per queue de QoS. Para lograr esto, necesitamos asociar una clase de SLA con una App Probe Class. Veamos un ejemplo.
Con esta App Probe Class, el router utilizará (y generará paquetes de BFD) con DSCP 18, imitando el tráfico menos importante que estará sujeto a diferentes reglas y rutas en los routers locales y externos. Esto proporcionará una medición más precisa de la pérdida de paquetes para cada tipo de tráfico en los transportes especificados. Si no hay inline data, BFD se usa para obtener mediciones.
Nota Si usas GRE, la medición per queue no está disponible.
Aquí hay un visual para comprender mejor cómo se medirán la pérdida dependiendo de múltiples factores.
| Encapsulación | App Probe Class | Tipo de medición | Túneles públicos | Túneles privados |
|---|---|---|---|---|
| IPsec | Sí | Por SLA | total pérdida WAN + pérdida local por queue | pérdida WAN per queue + pérdida local por queue |
| IPsec | No | Todos los SLAs | total pérdida WAN + total pérdida local | total pérdida WAN + total pérdida local |
| GRE | - | Todos los SLAs | total pérdida WAN + total pérdida local | total pérdida WAN + total pérdida local |
Latencia
Para medir la latencia, el router simplemente calculará el tiempo necesario para enviar y recibir paquetes entre los dispositivos de origen y de destino. Se utiliza inline data y puede llegar a la granularidad de App Probe Class.
Jitter
Vale la pena mencionar que el jitter se calcula por dirección (recibir o transmitir). El jitter se calcula en el receptor e informa al remitente usando TLV BFD. Se utiliza inline data y, en caso de no haber tráfico de datos, se usa BFD.
SLA Dampening
Uno de los beneficios de EAAR es dirigir el tráfico en segundos en lugar de minutos, pero ¿qué pasaría si hay condiciones de red transitorias que hacen que los transportes no cumplan con el SLA cada pocos minutos? El tráfico cambiaría constantemente entre los transportes, lo que no es un escenario deseable y la razón por la cual se introdujo el dampening.
La idea general es que cuando un enlace de transporte deja de cumplir con el SLA, el tráfico se redirige a una ruta alternativa. Una vez que el transporte vuelve a estar en cumplimiento, el dispositivo no mueve el tráfico de inmediato. En su lugar, inicia un temporizador para asegurarse de que el enlace permanezca estable durante un período determinado antes de reutilizarlo.
Al final, el dampening ayuda a evitar cambios innecesarios en el tráfico, lo que podría afectar negativamente el rendimiento debido a la inestabilidad del transporte.
Configuración de EAAR
Para habilitar EAAR tenemos tres opciones predefinidas:
| Mode | Poll Interval | Poll Multiplier | Dampening Multiplier |
|---|---|---|---|
| Aggressive | 10s | 6 (10s-60s) | 120 (20 mins) |
| Moderate | 60s | 5 (60s-300s) | 40 (40 mins) |
| Conservative | 300s | 6 (300s-1800s) | 12 (60 mins) |
Nota Para usar tiempos personalizados, la configuración debe hacerse a través de plantillas CLI.
EAAR sigue el mismo principio fundamental que AAR, utilizando buckets que van rotando para calcular la pérdida promedio, la latencia y la jitter. Con el modo aggressive, el tráfico tomaría entre 10 y 60 segundos en cambiar, dependiendo de qué tan severo sea el deterioro.
El Dampening Multiplier (poll interval x Dampening Multiplier) es de 1200 segundos, lo que significa que antes de cambiar el tráfico a un transporte, debe ser estable durante 20 minutos.
En mi laboratorio, estoy usando Configuration Groups, sin embargo, esto está disponible a través de Templates también.
Puedes usar una variable, en lugar de un valor global, para que sea aplicable también a los dispositivos que no correrán EAAR. En este caso, los dispositivos habilitados para EAAR harán fallback a AAR.
La siguiente configuración se agrega a los dispositivos:
bfd enhanced-app-route enable
bfd enhanced-app-route pfr-poll-interval 10000
bfd enhanced-app-route pfr-multiplier 6
bfd sla-dampening enable
bfd sla-dampening multiplier 120
Veamos cómo funciona
Demo
En mi laboratorio, uso el Manager con versión 20.16.1 y mis dispositivos con 17.15.1a
Nota La versión mínima requerida es 20.12/17.12
Comencemos con algunas verificaciones después de aplicar la configuración.
Para verificar los temporizadores y multiplicadores configurados
BR10#show sdwan app-route params
Enhanced Application-Aware routing
Config: :Enabled
Poll interval: :10000
Poll multiplier: :6
App route
Poll interval: :120000
Poll multiplier: :5
SLA dampening
Config: :Enabled
Multiplier: :120
Para verificar qué sesiones de BFD están utilizando EAAR, busca la columna Flags
BR10#show sdwan bfd sessions alt
SOURCE TLOC REMOTE TLOC DST PUBLIC DST PUBLIC
SYSTEM IP SITE ID STATE COLOR COLOR SOURCE IP IP PORT ENCAP BFD-LD FLAGS UPTIME
-------------------------------------------------------------------------------------------------------------------------------------------------
1.1.1.20 200 up biz-internet biz-internet 30.1.10.2 30.1.20.2 12406 ipsec 20006 EAAR 0:00:20:31
1.1.1.20 200 up mpls mpls 30.2.10.2 30.2.20.2 12366 ipsec 20002 EAAR 0:00:20:38
1.1.1.20 200 up private1 private1 30.3.10.2 30.3.20.2 12366 ipsec 20003 EAAR 0:00:20:37
Para obtener más detalles sobre un túnel específico.
BR10#show sdwan app-route stats summary
Generating output, this might take time, please wait ...
app-route statistics 30.1.10.2 30.1.20.2 ipsec 12386 12406
remote-system-ip 1.1.1.20
local-color biz-internet
remote-color biz-internet
sla-class-index 0,1,2
fallback-sla-class-index None
enhanced-app-route Enabled
sla-dampening-index None
app-probe-class-list None
mean-loss 0.000
mean-latency 0
mean-jitter 0
TOTAL AVERAGE AVERAGE TX DATA RX DATA IPV6 TX IPV6 RX
INDEX PACKETS LOSS LATENCY JITTER PKTS PKTS DATA PKTS DATA PKTS
-------------------------------------------------------------------------------------------------------------
0 0 0 0 0 0 0 0 0
1 64 0 0 0 0 0 0 0
2 0 0 0 0 0 0 0 0
3 0 0 0 0 0 0 0 0
4 0 0 0 0 0 0 0 0
5 64 0 0 0 0 0 0 0
Nota que no hay tráfico entre mis dispositivos, por lo que el recuento total de paquetes en cada bucket es bajo.
La misma información está disponible a través de la interfaz gráfica, utilizando la opción de Real Time > App Route Statistics
Escenario 1 - Deterioro ligero
Esta es la topología de mi laboratorio
Para esta primera prueba, usaré los siguientes parámetros de SLA:
SLA_Real-Time
Loss: 3%
Latency: 150ms
Jitter: 100ms
La política AAR indica que:
- Use MPLS como transporte principal
- Si ningún color cumple con el SLA y Private1 está disponible, usarlo.
- Si Private1 no está disponible, se hace load balance entre todos los colores restantes.
Estoy haciendo match del tráfico entre 172.16.10.0/24 y 172.16.20.0/24.
BR10#show sdwan policy from-vsmart
from-vsmart app-route-policy app_route_AAR
vpn-list vpn_Corporate_Users
sequence 1
match
source-data-prefix-list BR10
destination-data-prefix-list BR20
action
backup-sla-preferred-color private1
sla-class SLA_Real-Time
no sla-class strict
sla-class preferred-color mpls
sequence 11
match
source-data-prefix-list BR20
destination-data-prefix-list BR10
action
backup-sla-preferred-color private1
sla-class SLA_Real-Time
no sla-class strict
sla-class preferred-color mpls
Estado inicial sin deterioro en la red
BR10#show sdwan app-route stats summary | i color|damp|mean
local-color biz-internet
remote-color biz-internet
sla-dampening-index None
mean-loss 0.000
mean-latency 1
mean-jitter 0
local-color mpls
remote-color mpls
sla-dampening-index None
mean-loss 1.212
mean-latency 1
mean-jitter 0
mean-loss 1.212
mean-latency 1
mean-jitter 0
local-color private1
remote-color private1
sla-dampening-index None
mean-loss 0.000
mean-latency 0
mean-jitter 0
mean-loss 0.000
mean-latency 0
mean-jitter 0
Observa que el número de paquetes por bucket aumentó dramáticamente
BR10#show sdwan app-route stats remote-color mpls summary
Generating output, this might take time, please wait ...
app-route statistics 30.2.10.2 30.2.20.2 ipsec 12366 12366
remote-system-ip 1.1.1.20
local-color mpls
remote-color mpls
sla-class-index 0,1
fallback-sla-class-index None
enhanced-app-route Enabled
sla-dampening-index None
app-probe-class-list None
mean-loss 1.176
mean-latency 0
mean-jitter 0
TOTAL AVERAGE AVERAGE TX DATA RX DATA IPV6 TX IPV6 RX
INDEX PACKETS LOSS LATENCY JITTER PKTS PKTS DATA PKTS DATA PKTS
-------------------------------------------------------------------------------------------------------------
0 131136 1501 0 0 100084 20846 0 0
1 131072 1438 0 0 95287 19605 0 0
2 131072 1400 0 0 100985 20937 0 0
3 131072 1781 0 0 85553 18271 0 0
4 64 0 0 0 72618 15942 0 0
5 131072 1589 0 0 65198 14226 0 0
El tráfico está utilizando MPLS como transporte primario
BR10# show sdwan policy service-path vpn 10 interface gigabitEthernet 4 source-ip 172.16.10.10 dest-ip 172.16.20.10 protocol 6 all
Number of possible next hops: 1
Next Hop: IPsec
Source: 30.2.10.2 12366 Destination: 30.2.20.2 12366 Local Color: mpls Remote Color: mpls Remote System IP: 1.1.1.20
Introduzco el 3% de pérdida de paquetes en el transporte MPLS y veré cuánto tiempo lleva cambiar el tráfico. Dado que ya hay alrededor del 1% de pérdida, el 3% debería ser suficiente para activar un cambio.
El transporte MPLS tiene más del 3% de pérdida
BR10#show sdwan app-route stats remote-color mpls summary
Generating output, this might take time, please wait ...
app-route statistics 30.2.10.2 30.2.20.2 ipsec 12366 12366
remote-system-ip 1.1.1.20
local-color mpls
remote-color mpls
sla-class-index 0
fallback-sla-class-index 1
enhanced-app-route Enabled
sla-dampening-index None
app-probe-class-list None
mean-loss 3.125 <<<<<<<<<<
mean-latency 0
mean-jitter 0
Después de 56 segundos, el tráfico cambió y cualquiera de los transportes que cumplen el SLA podría usarse
BR10# show sdwan policy service-path vpn 10 interface gigabitEthernet 4 source-ip 172.16.10.10 dest-ip 172.16.20.10 protocol 6 all
Number of possible next hops: 2
Next Hop: IPsec
Source: 30.3.10.2 12366 Destination: 30.3.20.2 12366 Local Color: private1 Remote Color: private1 Remote System IP: 1.1.1.20
Next Hop: IPsec
Source: 30.1.10.2 12386 Destination: 30.1.20.2 12366 Local Color: biz-internet Remote Color: biz-internet Remote System IP: 1.1.1.20
Si quito la pérdida, podemos ver que el mecanismo de dampening se activa. Entonces, si el transporte es estable durante 20 minutos, se volverá a utilizar como ruta preferida.
BR10#show sdwan app-route stats remote-color mpls summary
Generating output, this might take time, please wait ...
app-route statistics 30.2.10.2 30.2.20.2 ipsec 12366 12366
remote-system-ip 1.1.1.20
local-color mpls
remote-color mpls
sla-class-index 0
fallback-sla-class-index 1
enhanced-app-route Enabled
sla-dampening-index 1 <<<<<<<<<<
app-probe-class-list None
mean-loss 0.000
mean-latency 0
mean-jitter 0
Escenario 2 - Mayor deterioro
En este caso, introduciré una pérdida de paquetes del 10% para el transporte de biz-internet, lo que hace que private1 sea el único transporte cumpliendo el SLA.
Después de alrededor de 45 segundos, la pérdida de Biz-Internet fue de 12%
BR10#show sdwan app-route stats local-color biz-internet summary
Generating output, this might take time, please wait ...
app-route statistics 30.1.10.2 30.1.20.2 ipsec 12386 12366
remote-system-ip 1.1.1.20
local-color biz-internet
remote-color biz-internet
sla-class-index 0
fallback-sla-class-index 1
enhanced-app-route Enabled
sla-dampening-index None
app-probe-class-list None
mean-loss 12.500
mean-latency 0
mean-jitter 0
El tráfico cambió a private1 exclusivamente
BR10#show sdwan policy service-path vpn 10 interface gigabitEthernet 4 source-ip 172.16.10.10 dest-ip 172.16.20.10 protocol 6 all
Number of possible next hops: 1
Next Hop: IPsec
Source: 30.3.10.2 12366 Destination: 30.3.20.2 12366 Local Color: private1 Remote Color: private1 Remote System IP: 1.1.1.20
Después de eliminar la pérdida de paquetes, Biz-Internet tiene el mecanismo de dampening activado
BR10#show sdwan app-route stats local-color biz-internet summary
Generating output, this might take time, please wait ...
app-route statistics 30.1.10.2 30.1.20.2 ipsec 12386 12366
remote-system-ip 1.1.1.20
local-color biz-internet
remote-color biz-internet
sla-class-index 0
fallback-sla-class-index 1
enhanced-app-route Enabled
sla-dampening-index 1 <<<<<<<<<
app-probe-class-list None
mean-loss 1.562
mean-latency 0
mean-jitter 0
En este caso, el tiempo para cambiar el tráfico se redujo como consecuencia de un deterioro mayor.
Escenario 3 - Múltiples App Probe Class
Para este escenario final, veamos cómo obtener el mayor beneficio de EAAR.
La configuración es más compleja ya que involucra QoS, App Probe Class y política AAR.
- Se requiere QoS para clasificar y enviar tráfico en diferentes colas.
- App Probe Class para medir la pérdida, la latencia y el jitter en cada una de esas colas, de forma independiente.
Mi configuración de QoS tiene 3 colas y la cola 2 manejará el tráfico menos importante.
- cola 0 para el tráfico de control
- cola 1 para tráfico en tiempo real (marcado DSCP 46)
- cola 2 para tráfico transaccional (marcado DSCP 18)
Utilizo una política de datos para hacer match del tráfico en el lado del servicio, marcarlo con el DSCP correcto y ponerla en la clase de QoS correcta. También creé un shaper en mi interfaz MPLS.
Para demostrar las cosas, tendré dos transferencias de datos:
- HTTP GET (puerto 8000)
- Copia SCP (puerto 22)
Mis SLA tienen las siguientes configuraciones:
| SLA Class Name | Loss | Latency | Jitter |
|---|---|---|---|
| SLA_Real-Time | 3 % | 150 ms | 100 ms |
| SLA_Transactional | 5 % | 45 ms | 150 ms |
Lo primero que hay que notar es que mis dos clases de sondeo de aplicaciones se miden de manera independiente. Observa cómo la pérdida media para Transactional-Probe_Class es 1, mientras que para Real_Time_Probe_Class es 0.
BR10#show sdwan app-route stats local-color mpls summary
Generating output, this might take time, please wait ...
app-route statistics 30.2.10.2 30.2.20.2 ipsec 12366 12366
remote-system-ip 1.1.1.20
local-color mpls
remote-color mpls
sla-class-index 0,1,2
fallback-sla-class-index None
enhanced-app-route Enabled
sla-dampening-index None
app-probe-class-list None
mean-loss 0.000
mean-latency 1
mean-jitter 0
TOTAL AVERAGE AVERAGE TX DATA RX DATA IPV6 TX IPV6 RX
INDEX PACKETS LOSS LATENCY JITTER PKTS PKTS DATA PKTS DATA PKTS
-------------------------------------------------------------------------------------------------------------
0 16384 0 0 0 35827 111807 0 0
1 49152 0 1 0 37788 118236 0 0
2 49216 0 1 0 36859 115551 0 0
3 16384 0 1 0 23894 77280 0 0
4 32768 0 1 1 33179 103759 0 0
5 32768 0 1 0 21485 71702 0 0
app-probe-class-list Real_Time_Probe_Class
mean-loss 0.000
mean-latency 0
mean-jitter 0
TOTAL AVERAGE AVERAGE TX DATA RX DATA IPV6 TX IPV6 RX
INDEX PACKETS LOSS LATENCY JITTER PKTS PKTS DATA PKTS DATA PKTS
-------------------------------------------------------------------------------------------------------------
0 0 0 0 0 - - - -
1 32768 0 1 0 - - - -
2 32768 0 0 0 - - - -
3 0 0 0 0 - - - -
4 32768 0 1 2 - - - -
5 0 0 0 0 - - - -
app-probe-class-list Transactional-Probe_Class
mean-loss 0.000
mean-latency 1
mean-jitter 0
TOTAL AVERAGE AVERAGE TX DATA RX DATA IPV6 TX IPV6 RX
INDEX PACKETS LOSS LATENCY JITTER PKTS PKTS DATA PKTS DATA PKTS
-------------------------------------------------------------------------------------------------------------
0 16384 0 0 0 - - - -
1 49152 0 1 0 - - - -
2 49216 0 1 0 - - - -
3 16384 0 1 0 - - - -
4 32768 0 1 1 - - - -
5 32768 0 1 0 - - - -
Ahora, he bajado mi shaper. EAAR fue rápido en detectar un cambio en la latencia para el SLA Transactional, ahora son 53 ms.
BR10# show sdwan app-route stats local mpls summary
Generating output, this might take time, please wait ...
app-route statistics 30.2.10.2 30.2.20.2 ipsec 12386 12366
remote-system-ip 1.1.1.20
local-color mpls
remote-color mpls
sla-class-index 0,1,2
fallback-sla-class-index None
enhanced-app-route Enabled
sla-dampening-index None
app-probe-class-list None
mean-loss 0.000
mean-latency 53
mean-jitter 0
TOTAL AVERAGE AVERAGE TX DATA RX DATA IPV6 TX IPV6 RX
INDEX PACKETS LOSS LATENCY JITTER PKTS PKTS DATA PKTS DATA PKTS
-------------------------------------------------------------------------------------------------------------
0 2048 0 54 0 4396 8513 0 0
1 1024 0 55 0 4461 8534 0 0
2 8256 0 49 0 4429 8549 0 0
3 16384 0 54 0 4411 8549 0 0
4 0 0 53 0 4440 8549 0 0
5 0 0 54 0 4443 8549 0 0
app-probe-class-list Real_Time_Probe_Class
mean-loss 0.000
mean-latency 0
mean-jitter 0
TOTAL AVERAGE AVERAGE TX DATA RX DATA IPV6 TX IPV6 RX
INDEX PACKETS LOSS LATENCY JITTER PKTS PKTS DATA PKTS DATA PKTS
-------------------------------------------------------------------------------------------------------------
0 0 0 0 0 - - - -
1 0 0 0 0 - - - -
2 8192 0 0 0 - - - -
3 16384 0 0 0 - - - -
4 0 0 0 0 - - - -
5 0 0 0 0 - - - -
app-probe-class-list Transactional-Probe_Class
mean-loss 0.000
mean-latency 53 <<<<<<<
mean-jitter 0
TOTAL AVERAGE AVERAGE TX DATA RX DATA IPV6 TX IPV6 RX
INDEX PACKETS LOSS LATENCY JITTER PKTS PKTS DATA PKTS DATA PKTS
-------------------------------------------------------------------------------------------------------------
0 2048 0 54 0 - - - -
1 1024 0 55 0 - - - -
2 8256 0 49 0 - - - -
3 16384 0 54 0 - - - -
4 0 0 53 0 - - - -
5 0 0 54 0 - - - -
Ahora que no se cumple mi SLA Transactional con una latencia máxima de 45 ms, usaré NWPI para comprender cómo se envía el tráfico. Examinemos el tráfico HTTP con el puerto 80000
Observa que, en la dirección upstream, el color local y remote es private1, lo que indica que el tráfico se ha alejado de MPLS y su latencia de 53 ms. Justo lo que esperábamos ✅
Ahora, veamos cómo está fluyendo el tráfico en el puerto 22
Una vez más, observa el local y Remote Color en la dirección upstream, observa cómo MPLS todavía está en uso para este tráfico, ya que no hay problemas en los transportes para este tipo de tráfico.
En resumen, el tráfico con DSCP 46 funciona perfectamente bien en el transporte MPLS, sin embargo, el tráfico con DSCP 18 estaba teniendo más latencia que el SLA configurado, por lo que se trasladó a Private1 ya que cumple con el SLA.
Podemos confirmar que estamos midiendo y tomando decisiones de ruteo per queue, esta es una gran diferencia 🤯!
Lecciones aprendidas
- Utilizando inline data, el número de muestras aumenta dramáticamente en comparación con el tamaño de muestra de BFD. 📈
- EAAR puede redirigir el tráfico en segundos, en lugar de minutos. ⏩
- EAAR ofrece los mayores beneficios en los transportes con QoS, como MPLS. 🚀
- Incluso en los transportes sin QoS, las mediciones de inline data aumentan el tamaño y la precisión de las muestras. ⏳
- El temporizador de dampening es útil para garantizar que los transportes sean estables antes de marcarlos como válidos. ✅
- La interoperabilidad entre dispositivos que ejecutan EAAR y dispositivos que ejecutan AAR es posible 🔄
¡Espero que hayas aprendido algo útil! Nos vemos en el siguiente 👋