Laboratório de Troubleshooting: Implement Bidirectional Forwarding Detection
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma empresa possui um circuito ExpressRoute com peering privado conectando o datacenter on-premises ao Azure. O BFD foi habilitado no MSEE há duas semanas e está operacional. O dispositivo CPE on-premises é um roteador Cisco IOS-XE. O engenheiro responsável relata que, após uma janela de manutenção na última sexta-feira, a sessão BFD nunca voltou a subir, embora a sessão BGP tenha se reestabelecido normalmente e o tráfego esteja fluindo sem aparente interrupção.
Durante a investigação, o engenheiro coleta as seguintes saídas:
# Cisco IOS-XE — verificação BFD
Router# show bfd neighbors details
IPv4 Sessions
NeighAddr LD/RD RH/RS State Int
10.0.0.1 4097/0 Down Down Gi0/0/1
Session state is DOWN and not using echo function
Local Diag: 0, Demand mode: 0, Poll bit: 0
MinTxInt: 300000, MinRxInt: 300000, Multiplier: 3
Received MinRxInt: 0, Received Multiplier: 0
Holdown (hits): 900ms (0)
O engenheiro observa ainda que a interface Gi0/0/1 está up/up, o MTU foi alterado de 1500 para 9000 durante a manutenção, e o BGP está com 14 prefixos recebidos normalmente.
Qual é a causa raiz da falha no estabelecimento da sessão BFD?
A. O intervalo de transmissão de 300 ms está acima do limite máximo suportado pelo MSEE, que exige no mínimo 1000 ms.
B. O campo Received MinRxInt: 0 indica que nenhum pacote BFD está chegando do peer MSEE, o que aponta para um problema de alcançabilidade ou filtragem dos pacotes BFD após a manutenção.
C. A alteração do MTU para 9000 bytes fragmentou os pacotes BFD, que são descartados pelo MSEE por não suportarem jumbo frames.
D. O BGP reestabeleceu a sessão antes que o BFD pudesse negociar os parâmetros, causando um conflito de estados que impede o BFD de subir.
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: a autenticação BFD foi habilitada inadvertidamente no dispositivo CPE on-premises durante a manutenção, e o Azure VPN Gateway do ambiente de testes adjacente não suporta esse recurso. No entanto, o cenário em questão é o circuito ExpressRoute de produção, onde o peer é o MSEE, que também não suporta autenticação BFD.
O ambiente tem as seguintes restrições:
- O circuito ExpressRoute está carregando tráfego de produção ativo
- Não há janela de manutenção aprovada até o próximo fim de semana
- A sessão BGP está estável e o tráfego não está impactado
- O time de segurança exige aprovação prévia para qualquer alteração de configuração em dispositivos de borda
Qual é a ação correta a tomar neste momento?
A. Remover imediatamente a configuração de autenticação BFD do CPE, pois a falha do BFD representa um risco latente de convergência lenta em caso de falha de enlace.
B. Reiniciar a sessão BGP no CPE para forçar a renegociação dos parâmetros BFD junto com o BGP.
C. Documentar o problema identificado, abrir a solicitação de aprovação junto ao time de segurança e aguardar a janela de manutenção para remover a configuração de autenticação.
D. Desabilitar o BFD completamente no CPE até que a janela de manutenção seja aprovada, garantindo que não haja tentativas de sessão com parâmetros inválidos.
Cenário 3 — Causa Raiz
Um engenheiro está configurando BFD sobre um túnel VPN Site-to-Site entre o Azure VPN Gateway e um firewall on-premises. O túnel IKEv2 foi estabelecido com sucesso. Após aplicar a configuração BFD no firewall, a sessão permanece em estado Init por vários minutos e então cai com o diagnóstico local No Diagnostic.
O engenheiro verifica as seguintes informações do ambiente:
# Firewall on-premises — configuração BFD aplicada
neighbor 172.16.0.1 bfd
bfd interval 750 min_rx 750 multiplier 4
# Verificação de conectividade
ping 172.16.0.1 source 172.16.0.2 count 100
Success rate is 100 percent (100/100)
# Rota para o peer BFD
172.16.0.1/32 via tunnel0 [1/0]
O engenheiro nota que o ping funciona perfeitamente e que o túnel IPsec está ativo há 3 dias sem interrupção. A versão do firmware do firewall é recente e suportada. O SKU do Azure VPN Gateway é VpnGw1.
Qual é a causa raiz do comportamento observado?
A. O intervalo de 750 ms é incompatível com o Azure VPN Gateway, que exige um valor mínimo de 1000 ms para sessões BFD sobre VPN.
B. O multiplier 4 excede o valor máximo suportado pelo Azure VPN Gateway para sessões BFD sobre túneis IKEv2.
C. O BFD não está habilitado ou não é suportado no SKU VpnGw1 do Azure VPN Gateway, e por isso o lado Azure nunca responde aos pacotes Init enviados pelo firewall.
D. O endereço de peer 172.16.0.1 pertence ao espaço de endereçamento do túnel interno, que não é roteável pelo plano de controle do Azure VPN Gateway para fins de BFD.
Cenário 4 — Sequência de Diagnóstico
Um operador recebe o seguinte alerta às 03h42:
"ExpressRoute circuit — BGP session down. Failover to secondary circuit in progress."
Ao iniciar a investigação, ele tem acesso ao CPE on-premises e às métricas do portal Azure. O BFD estava habilitado no circuito primário. Os seguintes passos de investigação estão disponíveis, fora de ordem:
- Verificar se os pacotes BFD estão sendo recebidos no CPE com
show bfd neighbors detailse confirmar o valor deReceived MinRxInt - Verificar o estado da interface física do CPE conectada ao provider com
show interfaces - Consultar o histórico de métricas de BitsInPerSecond e BitsOutPerSecond do circuito no portal Azure para identificar o momento exato da queda
- Confirmar se o circuito secundário assumiu corretamente verificando as rotas BGP ativas no CPE
- Verificar os logs do provider de conectividade para identificar se houve evento físico na camada do provider
Qual é a sequência correta de investigação?
A. 4 → 2 → 1 → 3 → 5
B. 2 → 1 → 3 → 5 → 4
C. 3 → 2 → 1 → 5 → 4
D. 1 → 3 → 2 → 5 → 4
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista definitiva está na saída do comando: Received MinRxInt: 0 e Received Multiplier: 0. Esses valores indicam que o dispositivo local nunca recebeu um pacote BFD de resposta do peer MSEE. Uma sessão BFD só avança do estado Down para Init quando o peer responde. Se os valores recebidos são zero, os pacotes simplesmente não estão chegando, o que aponta para bloqueio, filtragem ou roteamento incorreto dos pacotes BFD introduzido durante a manutenção.
A alteração de MTU para 9000 bytes é a informação irrelevante incluída propositalmente. Pacotes BFD são pequenos (geralmente abaixo de 100 bytes) e nunca seriam afetados por fragmentação de jumbo frames. O fato de o BGP estar funcional com prefixos recebidos confirma que a camada de transporte está operacional, o que elimina a hipótese de problema físico.
O distrator mais perigoso é a opção C, pois a alteração de MTU durante a manutenção cria uma correlação temporal falsa que pode desviar o diagnóstico para um caminho sem saída.
Gabarito — Cenário 2
Resposta: C
A causa está identificada e a correção é tecnicamente simples (remover a configuração de autenticação). Porém, o cenário impõe duas restrições críticas: ausência de janela de manutenção aprovada e exigência de aprovação prévia do time de segurança para alterações em dispositivos de borda.
A opção A ignora ambas as restrições. Embora o raciocínio técnico esteja correto (a ausência de BFD funcional é um risco de convergência), agir sem aprovação em produção viola o processo estabelecido e pode gerar impactos não planejados. A opção D cria um problema diferente: desabilitar o BFD remove a proteção de detecção rápida de falhas sem resolver a causa raiz, e também exigiria aprovação pela mesma lógica.
O ponto central deste cenário é que a decisão correta nem sempre é a mais tecnicamente elegante. Quando há restrições de processo e o impacto imediato é zero (tráfego fluindo normalmente pelo BGP), a ação correta é seguir o rito de aprovação e executar na janela adequada.
Gabarito — Cenário 3
Resposta: C
O diagnóstico No Diagnostic em conjunto com o estado Init persistente indica que o lado Azure nunca respondeu com um pacote BFD. Diferentemente do Cenário 1, aqui a conectividade IP está comprovada (ping 100% de sucesso, rota presente, túnel ativo há 3 dias). Isso elimina qualquer hipótese relacionada a alcançabilidade.
O SKU VpnGw1 é o elemento determinante. O suporte a BFD no Azure VPN Gateway está vinculado a SKUs específicos, e o VpnGw1 não oferece suporte a BFD. Como o lado Azure simplesmente não processa os pacotes BFD recebidos, o firewall on-premises envia repetidamente pacotes Init sem obter resposta, até que o holdown expire e a sessão caia com diagnóstico nulo.
O distrator mais perigoso é a opção A, pois valores de intervalo fora de especificação são uma causa real e comum de falha BFD, e a ausência de mensagem de erro explícita pode levar o operador a investigar parâmetros em vez de verificar o suporte do SKU.
Gabarito — Cenário 4
Resposta: B
A sequência correta segue a lógica de diagnóstico progressivo do mais próximo ao mais distante, e do físico para o lógico:
2 (interface física) é o ponto de partida porque uma falha na camada física explicaria todo o restante. Se a interface estiver down, não há necessidade de investigar BFD ou métricas.
1 (estado BFD) vem a seguir porque, se a interface estiver up, o próximo passo é entender se o BFD detectou corretamente a falha ou se foi o BGP que caiu por timeout.
3 (métricas do portal) permite correlacionar o momento da queda com o comportamento do tráfego, identificando se foi uma degradação gradual ou uma queda abrupta, o que ajuda a direcionar a investigação para o provider.
5 (logs do provider) é consultado após ter esgotado as verificações locais, pois depende de comunicação com terceiros e costuma ter latência de resposta.
4 (verificação do failover) fecha o ciclo confirmando que o circuito secundário assumiu corretamente. Este passo é de validação, não de diagnóstico da causa raiz, por isso pertence ao final.
A sequência A comete o erro clássico de verificar o resultado (failover) antes de entender a causa. A sequência D começa pelo BFD antes de validar a camada física, pulando um passo mais básico que poderia encerrar o diagnóstico mais cedo.
Árvore de Troubleshooting: Implement Bidirectional Forwarding Detection
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão binária ou de estado) |
| Laranja | Verificação ou validação intermediária |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
Diante de um problema real, inicie pelo nó raiz e responda cada pergunta com base no que é observável diretamente no ambiente, sem presumir causas. A cada bifurcação, o caminho correto é determinado pelo que você consegue confirmar, não pelo que você suspeita. Quando um nó de verificação intermediária (laranja) aparece, ele indica que uma inspeção adicional é necessária antes de confirmar a causa. Somente ao atingir um nó vermelho de causa identificada o diagnóstico está completo e a ação correspondente (verde) pode ser executada com segurança.