Aplication-Aware Routing Policies
A possibilidade de migração dos onerosos contratos de transporte MPLS para circuitos de internet se tornou, sem sombra de dúvidas, o principal fator responsável pelo crescente movimento das empresas na adoção da tecnologia SD-WAN. Contudo, sabemos que não existe garantia de nível de serviço ou service level agreements (SLA) na internet. Pensando nisso, a solução Cisco SD-WAN aproveita o baixo custo de um circuito de internet enquanto faz a utilização de Application-Aware Routing e mitigação de packet-loss para garantia do SLA requirido pelo negócio.
Cisco SD-WAN provê a capacidade de se utilizar circuitos broadband econômicos, com a garantia de uma experiência de aplicação superior e confiável. Essa habilidade de utilizar internet como meio de transporte, preservando a qualidade de experiência do usuário, permite que as empresas otimizem seus recursos financeiros ao aproveitar toda a sua largura de banda contratada em um cenário Active/Active. Além de evitar a contínua necessidade de investimento em upgrade de circuitos.
Fonte: https://blogs.cisco.com/networking/application-aware-networking-with-cisco-sd-wan-2
Nesse artigo irei focar em explicar o processo para utilização de Application-Aware Routing, que pode ser dividido em três partes chave:
- Construção de um App-Route policy: O primeiro passo é a construção de uma App-Route policy que é uma tipo específico de centralized data policy. A construção dessa policy inclui a definição das listas necessárias, criação da policy para ter uma sequência de match com condição de ação, seguida pela ativação da policy.
- Medição e monitoramento da performance dos links de transporte: O próximo passo consiste no monitoramento em tempo real da performance dos tuneis SD-WAN para verificar se os tuneis estão cumprindo os requisitos de SLA.
- Mapeamento do tráfego de aplicações para um link de transporte específico: Após a performance do túnel ter sido analisada, as métricas obtidas são comparadas com os requisitos das classes SLA para determinar quais tuneis estão de acordo com a necessidade da aplicação. Decisões de encaminhamento de tráfego são realizadas respeitando o status de conformidade do túnel com o SLA.
Obs: O processo de construção e mapeamento de tráfego será detalhado futuramente através de um vídeo disponibilizado no canal. Caso tenha interesse em entender o processo de construção de uma policy recomendo a leitura do artigo anterior aqui.
Monitorando a performance do túnel
O monitoramento em tempo real da rede underlay é realizado através do protocolo Bidirectional Forwarding Detection (BFD). Pacotes BFD são enviados por cada router em cada túnel que esteja UP como parte da SD-WAN Fabric. Esses pacotes servem para dois propósitos: detecção de falhas e monitoramento da qualidade. Pacotes BFD são enviados em modo echo de forma bidirecional em cada túnel (Figura 1.0), ou seja, SD-WAN fabric não forma nenhuma vizinhança BFD. O protocolo BFD é padrão da solução Cisco SD-WAN e não é possível desabilita-lo.
Figura 1.0 – Envio de pacotes BFD
Durante a configuração do template para o BFD, mas especificamente na seção Color, encontramos a configuração de Hello Interval e Multiplier para cada color. O mais comum em design de uma SD-WAN fabric é utilizar BFD timers mais agressivos para links de conexão cabeada e timers mais conservadores para conexões LTE (3G/4G/5G).
Hello Interval: É basicamente a definição da frequência com que um probe BFD será enviada através de um túnel. O valor default é de 1 vez por segundo, sendo especificado em milissegundos na configuração.
Casos em que diferentes devices possuam diferentes BFD timers configurados para o mesmo túnel, ocorrerá uma negociação e o BFD irá utilizar o maior entre os dois valores. Isso pode ocorrer em cenários em que uma color LTE é utilizada para se conectar com uma color biz-internet. A figura 2.0 exemplifica esse tipo de design.
Figura 2.0 – Negociação de Hello Interval do BFD
Multiplier: É o valor que especifica quantas BFD probes precisam ser perdidas consecutivamente para que o protocolo considere o túnel DOWN, sendo 7 o valor default. Importante ressaltar que nos casos em que a interface de transporte mude o status de UP para DOWN não é necessário esperar com que o multiplier expire, o túnel correspondente a interface será imediatamente colocado em status down.
A figura 3.0 demonstra como os parâmetros hello interval e multiplier trabalham em conjunto. No cenário em questão ocorre um o rompimento unilateral de fibra:
Figura 2.0 – Detecção de falhas com BFD
Perceba que foi necessário 1s para identificar a falha, isso se deve ao fato de ter sido utilizado o multiplier de 5 e hello interval de 200ms. Contudo, se optar por utilizar os valores padrões, podem ser necessários até 7s para a identificação de uma falha como essa.
Monitorando a qualidade do caminho
Além da detecção de falhas no link, os pacotes BFD também são utilizados para medir a qualidade das rotas utilizadas. Essa utilização é feita através da configuração dos parâmetros App-Route Poll Interval e App-Route Multiplier. Lembre-se de que só pode existir uma configuração para cada um desses parâmetros em cada WAN Edge router.
App-Route Poll Intervall é basicamente o período que cada WAN Edge router irá calcular o jitter, loss e latência de cada túnel utilizando os pacotes BFD enviados durante o intervalo. A quantidade de pacotes BFD e o tamanho da amostragem utilizados para o cálculo dessa estatística não são configurados de forma explicita, ao invés disso, são uma combinação do Hello Interval e a duração do App-Route Poll Interval. App-Route utiliza média aritmética para definir estatísticas através dos pacotes BFD dentro do intervalo definido. Portanto, é muito importante garantir que se tenha uma boa quantidade de BFD probes em um intervalo para que seja gerado estatísticas significantes para cada transporte.
App-Route Multiplier específica quantos polls coletados anteriormente deverão ser considerados para calcular se o túnel está compatível com o SLA definido. O valor default, e o máximo que se pode configurar, é 6. Basicamente, quando se configura um App-Route Multiplier de 3 queremos dizer que serão necessários a análise de ao menos 3 Poll Interval (também referido como “buckets”) para que se calcule a performance de um túnel, sempre considerando os buckets mais recentes.
Veja no exemplo da Figura 2.1 que temos o nosso SLA Class definido com o loss máximo de 2%, latência máxima de 100ms e jitter máximo de 30ms. Foi utilizado então um App-Route Polling Interval de 10.000ms e App-Route Multiplier de 3. Em outras palavras, a performance do túnel será definida a cada 10 segundos e a definição para saber se ele se encontra dentro do definido no SLA será a cada 30s.
Figura 2.1 – Cálculo de SLA
Vale dizer que esses parâmetros utilizados no exemplo são considerados bastante agressivos pois respondem rápido as oscilações do underlay, porém, podem resultar em falsos positivos que resultam em diversas comutações de tuneis.
Mesmo esse tipo de configuração sendo exclusiva para cada tipo de rede, os seguintes parâmetros podem atender bem grande parte delas:
- App-Route Polling Inter: 120.000ms (dois minutos)
- App-Route Multiplier: 6
- Hello Interval: 1000ms (um segundo)
- Hello Multiplier: 7
Com a utilização desses parâmetros é esperado que falhas unidirecionais no transporte sejam identificadas em 7s, cada túnel é avaliado individualmente a cada 2 minutos e a definição para saber se está de acordo com o SLA a cada 12 minutos. Além disso, cada poll interval terá dados de pelo menos 120 BFD probes o que acarreta estatísticas mais precisas e confiáveis para tomada de decisão.
Confesso que toda essa teoria na hora do estudo fica um pouco confuso de entender. Pensando nisso irei trazer em breve uma demonstração na prática do tema discutido aqui. Fique de olho no canal Lo0 e nas publicações aqui na Cisco Community para não perder nada!
Para todos que leram até aqui deixo duas perguntas sobre o tema como forma de estudo e caso tenham dúvidas ou considerações, sintam-se à vontade para postar nos comentários.
1. Which administratively configured options affect the calculation of loss, latency, and jitter statistics used for Application-Aware Routing? (Choose all that apply)
- BFD Hello Interval
- BFD Hello Multiplier
- Number of SLA Classes
- App-Route Poll Interval
- Number of Tunnels
- Number of Colors
- App Route Multiplier
2. When are the tunnels (re)evaluated for compliance with the sla classes?
- After every BFD packet is received by the WAN Edge router
- After every Hello Interval
- After every Hello Multiplier
- After every App-Route Poll Interval
