BGP aprendeu o prefixo, pero o tráfico segue evitando o túnel

A pasarela da sucursal mostra o prefixo da nube na súa táboa BGP, a sesión co provedor está establecida e, aínda así, a petición dun usuario a ese prefixo sae pola interface equivocada. Nada está roto como suxire a monitorización, porque «BGP aprendeuno» é unha afirmación sobre o plano de control. Entre esa táboa e o paquete hai catro transicións separadas, e o fluxo detense exactamente nunha delas. Percorra as portas en orde e detéñase na primeira que falla.

Primeira porta: que enviou realmente o veciño

Comece polo prefixo tal como se recibiu, non como se resumiu. Busque a rede e a máscara exactas na táboa BGP e anote o seguinte salto, a ruta AS e calquera comunidade que unha política de importación poida coincidir. Unha ruta resumida nun panel pode ocultar o feito de que o prefixo concreto nunca se aceptou.

A política de importación é o lugar habitual onde unha ruta desaparece sen erro. Unha lista de prefixos, un filtro de comunidades ou un mapa de rutas de entrada poden descartar a actualización mentres a sesión segue activa e sa, e por iso unha luz verde de veciño demostra tan pouco. A ausencia dunha liña de rexistro non significa a ausencia dunha decisión. Normalmente significa que a decisión se tomou en silencio, exactamente como está configurada.

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

Lea a saída nesa orde. Os dous primeiros comandos din se a información chegou e que afirma o par que enviou; os dous últimos din se algo chegou ás táboas de encamiñamento e reenvío. Un prefixo presente no primeiro comando e ausente no terceiro é un problema de selección ou de instalación, non de conectividade.

Segunda porta: selección, despois instalación

BGP elixe a mellor ruta, e a ruta elixida non se instala automaticamente. O seguinte salto ten que resolverse, e outra fonte de rutas pode posuír xa ese prefixo cunha distancia administrativa mellor. Unha ruta estática que quedou da migración gañará sen esforzo a unha ruta BGP válida e enviará o tráfico a outro sitio.

RFC 4271 mantén tres ideas separadas: que enviou un par, que elixiu este orador como mellor e que anunciará despois. Son roles conceptuais, non tres bases de datos físicas que un fabricante deba expor, pero é precisamente esa separación a que fai de «está en BGP» unha resposta incompleta.

Comprobe tamén que contexto de encamiñamento está a ler. Unha ruta instalada nunha VRF á que non pertence a interface do usuario é invisible para os paquetes dese usuario, e a táboa parece correcta todo o tempo.

Terceira porta: a consulta que se aplica a este fluxo

Agora deixe de preguntar pola ruta e comece a preguntar polo paquete. Anote o enderezo de orixe do usuario, o destino, o protocolo, o porto e a interface de entrada, porque cada un deles pode seleccionar unha política distinta. Despois mire a consulta que se aplica a esa combinación en lugar da táboa de encamiñamento xeral.

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

Un prefixo máis específico é a sorpresa máis habitual aquí, e unha ruta de política é a segunda. Ambas anulan o agregado que estaba mirando, e ningunha é visible nun resumo da táboa BGP.

Un ping orixinado na propia pasarela non é proba sobre a sesión dun usuario. Enderezo de orixe distinto, ruta de política distinta e a miúdo un resultado distinto. Probo coa mesma fonte que usa a aplicación, ou acepte que a proba responde a outra pregunta.

Cuarta porta: a metade remota do camiño

Se a consulta local selecciona o túnel, o paquete aínda ten que ser aceptado pola política de protección, permitido pola regra de reenvío e respondido por algo no outro lado. Unha ACL de cifrado que non inclúe o par de enderezos descartará o tráfico mentres o túnel se declara activo, o que produce un tempo de espera indistinguible dun fallo de encamiñamento.

O camiño de volta importa tanto como o de ida. O lado da nube ten que saber como chegar á orixe da sucursal, xa sexa mediante unha ruta ou mediante unha tradución que vostede configurou deliberadamente. Os camiños de volta asimétricos son comúns en deseños probados só nunha dirección.

Correlacione unha conexión autorizada nova con tres observacións: a política local que coincidiu, os contadores do túnel que se moveron e a recepción no lado remoto onde sexa visible. Se os contadores non se moven, o paquete nunca entrou no túnel, diga o que diga a táboa de rutas. Se se moven e non chega nada, o lado remoto está a descartalo ou a encamiñalo mal. Eses dous resultados levan a equipos completamente distintos.

Nomee a transición que fallou

Escriba o resultado como un de cinco estados: non recibido, non aceptado pola política, non seleccionado, non instalado ou non coincidente con este fluxo. Engada un sexto para o caso no que o camiño local é correcto e o extremo remoto non pode responder. Esa frase é a entrega, e é moito máis útil ca unha captura de pantalla dun veciño establecido.

Manteña tamén unha proba negativa no plan de aceptación: un destino que non debe atravesar o túnel, verificado despois do cambio. Unha lista de comprobación que só demostra o camiño feliz non atrapará a regra ampla de política que alguén engada na próxima xanela de mantemento.