BGP aprendió el prefijo, pero el tráfico sigue evitando el túnel

La puerta de la sucursal muestra el prefijo de la nube en su tabla BGP, la sesión con el proveedor está establecida y, aun así, la petición de un usuario a ese prefijo sale por la interfaz equivocada. Nada está roto como sugiere la monitorización, porque «BGP lo aprendió» es una afirmación sobre el plano de control. Entre esa tabla y el paquete hay cuatro transiciones separadas, y el flujo se detiene exactamente en una de ellas. Recorra las puertas en orden y deténgase en la primera que falle.

Primera puerta: qué envió realmente el vecino

Empiece por el prefijo tal como se recibió, no como se resumió. Busque la red y la máscara exactas en la tabla BGP y anote el siguiente salto, la ruta AS y cualquier comunidad que una política de importación pueda coincidir. Una ruta resumida en un panel puede ocultar el hecho de que el prefijo concreto nunca se aceptó.

La política de importación es el lugar habitual donde una ruta desaparece sin error. Una lista de prefijos, un filtro de comunidades o un mapa de rutas de entrada pueden descartar la actualización mientras la sesión sigue activa y sana, y por eso una luz verde de vecino demuestra tan poco. La ausencia de una línea de registro no significa la ausencia de una decisión. Normalmente significa que la decisión se tomó 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 la salida en ese orden. Los dos primeros comandos dicen si la información llegó y qué afirma el par que envió; los dos últimos dicen si algo llegó a las tablas de encaminamiento y reenvío. Un prefijo presente en el primer comando y ausente en el tercero es un problema de selección o de instalación, no de conectividad.

Segunda puerta: selección, después instalación

BGP elige la mejor ruta, y la ruta elegida no se instala automáticamente. El siguiente salto tiene que resolverse, y otra fuente de rutas puede poseer ya ese prefijo con una distancia administrativa mejor. Una ruta estática que quedó de la migración ganará sin esfuerzo a una ruta BGP válida y enviará el tráfico a otro sitio.

RFC 4271 mantiene tres ideas separadas: qué envió un par, qué eligió este orador como mejor y qué anunciará después. Son roles conceptuales, no tres bases de datos físicas que un fabricante deba exponer, pero es precisamente esa separación la que hace de «está en BGP» una respuesta incompleta.

Compruebe también qué contexto de encaminamiento está leyendo. Una ruta instalada en una VRF a la que no pertenece la interfaz del usuario es invisible para los paquetes de ese usuario, y la tabla parece correcta todo el tiempo.

Tercera puerta: la consulta que se aplica a este flujo

Ahora deje de preguntar por la ruta y empiece a preguntar por el paquete. Anote la dirección de origen del usuario, el destino, el protocolo, el puerto y la interfaz de entrada, porque cada uno de ellos puede seleccionar una política distinta. Después mire la consulta que se aplica a esa combinación en lugar de la tabla de encaminamiento general.

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 prefijo más específico es la sorpresa más habitual aquí, y una ruta de política es la segunda. Ambas anulan el agregado que estaba mirando, y ninguna es visible en un resumen de la tabla BGP.

Un ping originado en la propia puerta no es prueba sobre la sesión de un usuario. Dirección de origen distinta, ruta de política distinta y a menudo un resultado distinto. Pruebe con la misma fuente que usa la aplicación, o acepte que la prueba responde a otra pregunta.

Cuarta puerta: la mitad remota del camino

Si la consulta local selecciona el túnel, el paquete todavía tiene que ser aceptado por la política de protección, permitido por la regla de reenvío y respondido por algo al otro lado. Una ACL de cifrado que no incluye el par de direcciones descartará el tráfico mientras el túnel se declara activo, lo que produce un tiempo de espera indistinguible de un fallo de encaminamiento.

El camino de vuelta importa tanto como el de ida. El lado de la nube tiene que saber cómo llegar al origen de la sucursal, ya sea mediante una ruta o mediante una traducción que usted configuró deliberadamente. Los caminos de vuelta asimétricos son comunes en diseños probados solo en una dirección.

Correlacione una conexión autorizada nueva con tres observaciones: la política local que coincidió, los contadores del túnel que se movieron y la recepción en el lado remoto donde sea visible. Si los contadores no se mueven, el paquete nunca entró en el túnel, diga lo que diga la tabla de rutas. Si se mueven y no llega nada, el lado remoto lo está descartando o encaminando mal. Esos dos resultados llevan a equipos completamente distintos.

Nombre la transición que falló

Escriba el resultado como uno de cinco estados: no recibido, no aceptado por la política, no seleccionado, no instalado o no coincidente con este flujo. Añada un sexto para el caso en que el camino local es correcto y el extremo remoto no puede responder. Esa frase es el entregable, y es mucho más útil que una captura de pantalla de un vecino establecido.

Mantenga también una prueba negativa en el plan de aceptación: un destino que no debe atravesar el túnel, verificado después del cambio. Una lista de comprobación que solo demuestra el camino feliz no atrapará la regla amplia de política que alguien añada en la próxima ventana de mantenimiento.