O BGP aprendeu o prefixo, mas o tráfego ainda contorna o túnel

O gateway da filial mostra o prefixo da nuvem na sua tabela BGP, a sessão com o provedor está estabelecida e, ainda assim, a requisição de um usuário para esse prefixo sai pela interface errada. Nada está quebrado do jeito que o monitoramento sugere, porque “o BGP aprendeu” é uma afirmação sobre o plano de controle. Entre essa tabela e o pacote há quatro transições separadas, e o fluxo para exatamente em uma delas. Percorra os portões em ordem e pare no primeiro que falhar.

Primeiro portão: o que o vizinho realmente enviou

Comece pelo prefixo como recebido, não como resumido. Procure a rede e a máscara exatas na tabela BGP e anote o próximo salto, o caminho AS e qualquer comunidade que uma política de importação possa casar. Uma rota resumida em um painel pode esconder o fato de que o prefixo específico nunca foi aceito.

A política de importação é o lugar habitual onde uma rota desaparece sem erro. Uma lista de prefixos, um filtro de comunidades ou um mapa de rotas de entrada podem descartar a atualização enquanto a sessão permanece ativa e saudável, e é por isso que uma luz verde de vizinho prova tão pouco. A ausência de uma linha de log não significa a ausência de uma decisão. Normalmente significa que a decisão foi tomada em silêncio, exatamente como configurado.

show ip bgp 10.60.20.0/24
show ip bgp neighbors 203.0.113.5 advertised-routes
show ip route 10.60.20.0
show ip cef 10.60.20.0

Leia a saída nessa ordem. Os dois primeiros comandos dizem se a informação chegou e o que o par afirma ter enviado; os dois últimos dizem se algo alcançou as tabelas de roteamento e encaminhamento. Um prefixo presente no primeiro comando e ausente no terceiro é um problema de seleção ou instalação, não de conectividade.

Segundo portão: seleção, depois instalação

O BGP escolhe o melhor caminho, e o caminho escolhido não é instalado automaticamente. O próximo salto precisa ser resolvido, e outra fonte de rotas pode já possuir esse prefixo com uma distância administrativa melhor. Uma rota estática que sobrou da migração vence facilmente um caminho BGP válido e envia o tráfego para outro lugar.

O RFC 4271 mantém três ideias separadas: o que um par enviou, o que este falante escolheu como melhor e o que anunciará adiante. São papéis conceituais, não três bancos de dados físicos que um fornecedor precise expor, mas é justamente essa separação que torna “está no BGP” uma resposta incompleta.

Verifique também qual contexto de roteamento você está lendo. Uma rota instalada em uma VRF à qual a interface do usuário não pertence é invisível para os pacotes desse usuário, e a tabela parece correta o tempo todo.

Terceiro portão: a consulta que se aplica a este fluxo

Agora pare de perguntar sobre a rota e comece a perguntar sobre o pacote. Anote o endereço de origem do usuário, o destino, o protocolo, a porta e a interface de entrada, porque cada um deles pode selecionar uma política diferente. Depois olhe a consulta que se aplica a essa combinação em vez da tabela de roteamento geral.

ip route get 10.60.20.25 from 10.60.10.40
ip rule show
sudo tcpdump -ni tun0 'host 10.60.20.25'

Um prefixo mais específico é a surpresa mais comum aqui, e uma rota de política é a segunda. As duas se sobrepõem ao agregado que você estava olhando, e nenhuma delas é visível em um resumo da tabela BGP.

Um ping originado do próprio gateway não é evidência sobre a sessão de um usuário. Endereço de origem diferente, caminho de política diferente e, muitas vezes, resultado diferente. Teste com a mesma origem que a aplicação usa, ou aceite que o teste responde a outra pergunta.

Quarto portão: a metade remota do caminho

Se a consulta local seleciona o túnel, o pacote ainda precisa ser aceito pela política de proteção, permitido pela regra de encaminhamento e respondido por algo do outro lado. Uma ACL de cripto que não inclui o par de endereços descarta o tráfego enquanto o túnel se declara ativo, o que produz um tempo limite indistinguível de uma falha de roteamento.

O caminho de volta importa tanto quanto o de ida. O lado da nuvem precisa saber como alcançar a origem da filial, seja por uma rota, seja por uma tradução que você configurou deliberadamente. Caminhos de volta assimétricos são comuns em projetos testados apenas em uma direção.

Correlacione uma conexão autorizada recente com três observações: a política local que casou, os contadores do túnel que se moveram e a recepção no lado remoto onde isso é visível. Se os contadores não se movem, o pacote nunca entrou no túnel, diga o que disser a tabela de rotas. Se se movem e nada chega, o lado remoto está descartando ou roteando errado. Esses dois resultados levam a equipes completamente diferentes.

Nomeie a transição que falhou

Escreva o resultado como um de cinco estados: não recebido, não aceito pela política, não selecionado, não instalado ou não correspondido por este fluxo. Acrescente um sexto para o caso em que o caminho local está correto e a extremidade remota não consegue responder. Essa frase é a entrega, e é muito mais útil do que uma captura de tela de um vizinho estabelecido.

Mantenha também um teste negativo no plano de aceitação: um destino que não deve atravessar o túnel, verificado após a mudança. Uma lista de verificação que só prova o caminho feliz não pega a regra ampla de política que alguém acrescentar na próxima janela de manutenção.