Entender a relação do protocolo BFD com o roteamento com reconhecimento de aplicativos

Introdução

Este documento descreve a relação que existe entre os pacotes Hello do BFD e as estatísticas do túnel de roteamento com reconhecimento de aplicativo.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Rede de Longa Distância Definida pelo Software Cisco Catalyst (SD-WAN).
• Roteamento com reconhecimento de aplicativos.
• BFD

Componentes Utilizados

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

• Cisco Catalyst SD-WAN Manager
• Cisco IOS® XE Catalyst SD-WAN Edges

Informações de Apoio

O protocolo BFD (Bidirectional Forwarding Detection) é executado em todos os túneis de plano de dados entre os dispositivos Cisco IOS-XE Catalyst SD-WAN. Esse protocolo é usado para monitorar as características de vida e de caminho dos túneis, como o desempenho do túnel relatado como Perda, Tremulação e Latência.

Os dispositivos de borda usam sondas Hello BFD para fornecer uma medição de perda de pacotes, instabilidade e latência no túnel. Essas estatísticas são calculadas para cada sonda Hello do BFD e são obtidas em uma janela móvel de tempo chamada intervalo de polling.

Essas estatísticas de perda, latência e jitter são usadas pelo App-Aware Routing para fornecer o tráfego com base nos requisitos definidos na política, chamadas classes SLA, nas quais ele determina a perda máxima, jitter e latência permitidas no túnel selecionado para entregar os dados.

Por isso, é muito importante entender como as medidas são calculadas e como uma alteração nos valores de BFD pode afetar o cálculo de desempenho do túnel principalmente a perda média. Os parâmetros BFD são:

Parâmetro	Valor padrão	Faixa	Uso
intervalo de Hello BFD	1 segundo	1 a 65535 segundos	Pacotes para detectar a atividade da conexão de túnel e para detectar falhas no túnel.
Intervalo de sondagem	10 minutos (600.000 milissegundos)	1 a 4.294.967 milissegundos	A frequência com que uma medida de período é calculada para fornecer estatísticas.
Multiplicador	6	1 a 6	Valor que multiplica o intervalo de sondagem para especificar o tempo para calcular a perda média, a latência média e o jitter médio. Esse valor determina o número de buckets.

Cálculo de estatísticas de desempenho de túnel

Para os parâmetros da BFD definidos por defeito, o cálculo das estatísticas é feito do seguinte modo:

Intervalo de Polling / Intervalo de Hello BFD = 600.000 ms / 1000 ms = 600 Hellos BFD por bucket.

Como o multiplicador é definido como 6, isso significa que 6 buckets são usados para calcular a latência média, o jitter e a perda. Com valores padrão, isso equivale a 1 hora. Esse tempo total também é conhecido como intervalo de rota de aplicativo.

Intervalo de rota de aplicativo = Intervalo de sondagem * multiplicador = 600.000 ms x 6 = 3.600.000 ms igual a 1 hora.

Os cálculos das estatísticas de rota de aplicativo são usados pelo Roteamento com reconhecimento de aplicativo para determinar alterações no plano de dados. Para que um dispositivo de Borda aproveite as estatísticas de rota de aplicativo, as classes SLA devem ser especificadas na política AAR na qual o máximo aceitável de variação de pacotes, perda e latência é definido. Essas classes SLA são usadas na política AAR para rotear o tráfego para aplicativos especificados de acordo com os SLAs.  

Uma vez configuradas em um dispositivo de Borda, as estatísticas de AAR são usadas para comparar com a perda média, a latência média e o jitter médio fornecidos pelas estatísticas calculadas com todos os buckets (durante todo o intervalo de rota de aplicativo). Também é importante observar que os SLAs são atualizados após cada intervalo de pesquisa, a cada dez minutos por padrão.

Para obter a perda média, o jitter médio e a latência média, as equações usadas são:

Perda Média = (perda total em todos os buckets * 100) / Total de pacotes.

Latência Média = (perda total em todos os períodos) / quantia de períodos.

Variação média = (variação total em todos os buckets) / quantidade de bucket.

O cálculo desses valores juntamente com a média de cada bucket pode ser revisado no CLI com:

vEdge#show app-route stats

cEdge#show sdwan app-route stats

Enquanto estiver na GUI, a perda média, a latência média e o jitter médio somente podem ser revisados na seção Monitor > Overview > Application-Aware Routing.

Ele também pode ser revisado na seção Monitor > Devices > Select Device > WAN > Tunnel.

Exemplos de Relação de Valores de BFD com Perda

Como os Hellos de BFD são valores configuráveis, eles podem ser modificados com base nos requisitos; no entanto, é importante modificá-los após uma consideração cuidadosa, caso contrário, cálculos distorcidos ou estatísticas de falsos positivos podem ser recebidos, já que a precisão do cálculo de perda média depende dos valores de BFD. Por exemplo, com valores padrão de:

Parâmetro	padrão
pacote hello de BFD	1 segundo
Intervalo de sondagem	(600.000 milissegundos) 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 

Perda média = ((7+5+13+4+5+12)100)/ (596+596+597+594+596+594)

          = 4600/3573

          = 1,28 ~ 1%

Latência Média = (110+111+111+111+110+111)/6

             = 110,66 a 110 ms

Variação média = (50+50+53+53+50+50) / 6

            = 3 /6 = 51 ms

Nota: Para cada cálculo feito, somente valores inteiros são apresentados. Mesmo quando decimal é o resultado exato, os valores inteiros são arredondados para o inteiro mais próximo mais baixo.

Normalmente, é uma boa opção modificar esses valores para fazer o cálculo com mais frequência, mas pode causar um impacto significativo; por exemplo, se, em vez de valores padrão, o intervalo de polling for modificado para:

Parâmetro	padrão
pacote hello de BFD	1 segundo
Intervalo de sondagem	(60.000 milissegundos) 1 min.
Multiplicador	6

Essa alteração significa que ele usa 1 x 60 = 60 pacotes por bucket em vez de 600 como padrão. O resultado da perda média é:

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 

Perda média = ((1+3+1+3+2+1)*100)/(59+60+59+60+60+59)

          = (1100)/357

          = 3,08 ~ 3%

Neste ponto, se, por exemplo, a classe SLA for definida como Perda máxima de 3, o túnel estará sob o limite da violação do SLA. No entanto, se o intervalo de polling for modificado para:

Parâmetro	padrão
pacote hello de BFD	1 segundo
Intervalo de sondagem	(6.000 milissegundos) 1 segundo
Multiplicador	6

Essa alteração significa que usa 1 x 6 = 6 pacotes por bucket em vez de 600 como padrão. O resultado da perda média é:

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 

Perda média = ((5)100)/(5+6+6+6+6+6+6)

          = (500)/29

          = 17,24 ~ 17%

Se o intervalo de poll for reduzido sem a validação correta de quantos pacotes são usados para medição, isso pode afetar a perda média, o mesmo pode ser aplicado se o intervalo de hello de bfd for aumentado sem aumentar o intervalo de pool.

No último exemplo, como poucos pacotes são usados para fazer o cálculo, com apenas um pacote perdido, a perda média pode ser afetada significativamente. O resultado desses cálculos é um comportamento de política com reconhecimento de aplicativos com vários failovers muito frequentes.

A finalidade dessa explicação não é evitar a modificação desses valores, pelo contrário, em muitas situações esses testes precisam ser modificados. Isso depende completamente dos requisitos da rede, mas é muito importante revisar o quanto esses pacotes de saudação podem ser reduzidos.

O comando de configuração para modificar globalmente o intervalo de pesquisa é:

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