Por qué su sesión BGP no aparece en la tabla de rutas de la VPC

La historia que se repite es que un demonio de enrutamiento en un dispositivo VPN de EC2 enseñará a la VPC sus prefijos remotos en cuanto BGP suba. La mitad de eso es cierto. La sesión sube, y nada cambia en la tabla de rutas de la VPC por ello, por lo que el primer síntoma suele ser una subred que manda el tráfico en silencio a un agujero negro.

Aquí se confunden dos cosas distintas: el emparejamiento con un servidor de rutas y la instalación de rutas en una tabla.

El mito: sube BGP y la VPC aprenderá los prefijos

BGP es una conversación entre dos interlocutores, y en este diseño los interlocutores son el demonio de enrutamiento de su dispositivo y un punto de enlace de VPC Route Server que AWS coloca en una subred que usted posee. Esa conversación transporta prefijos. No toca la tabla de rutas de sus subredes de carga, porque esas tablas solo aprenden mediante la propagación que debe habilitarse en cada una. Hasta que eso ocurra, el tejido de la VPC no sabe nada de lo que sabe el dispositivo.

Los pasos de configuración están separados por una razón: asociar, crear el punto de enlace, emparejar y después habilitar la propagación.

Route Server es un plano de control, no un túnel

Route Server no cifra, no reenvía ni inspecciona un solo paquete. Existe para intercambiar BGP con el dispositivo y entregar los prefijos resultantes a las tablas de rutas configuradas para recibirlos. El plano de datos no cambia: los paquetes siguen saliendo por la interfaz de red del dispositivo, viajan por su VPN y vuelven por el mismo camino.

Eso significa que la comprobación de origen y destino en la instancia de reenvío sigue importando, porque la instancia ahora reenvía tráfico dirigido a otra persona.

Los grupos de seguridad y los controles de subred también se aplican al flujo reenviado. Route Server no hará que un dispositivo que descarta tráfico lo reenvíe, ni reparará una ruta de retorno que falte en el lado remoto.

La propagación es por tabla de rutas, no por VPC

Asociar el servidor de rutas con la VPC y habilitar la propagación en una tabla de rutas son dos decisiones, y solo la segunda cambia lo que hace una subred. Una VPC con seis tablas de rutas puede recibir un prefijo propagado en una y no en las otras cinco, lo que es exactamente correcto para una subred concentradora y exactamente lo que produce el desconcertante resultado de «funciona a medias». Incluso donde la propagación está activa, una ruta competidora puede ganar, porque la selección de rutas de la VPC prefiere el prefijo más largo y, a igual longitud, prefiere una ruta estática sobre una propagada. Esa preferencia se aplica en silencio.

Compruebe la tabla efectiva de la subred concreta en lugar de la lista de prefijos que anuncia el dispositivo. La API responde esa pregunta directamente: aws ec2 associate-route-server y aws ec2 enable-route-server-propagation --route-table-id <id> son los dos pasos que la gente olvida, y aws ec2 describe-route-tables --route-table-ids <id> muestra si el prefijo llegó como entrada de route server.

El dispositivo sigue llevando cada paquete

Anunciar alcanzabilidad no es lo mismo que tenerla. Una sesión BGP puede permanecer establecida mientras la VPN del dispositivo está caída, y un anuncio estático que nunca cambia sigue atrayendo el tráfico hacia un camino muerto. Route Server admite detección de fallos como BFD, pero eso prueba la vitalidad del par, no la salud de todo lo que hay detrás.

Ate el anuncio a la ruta remota real: anuncie el prefijo cuando el túnel y la red remota estén activos, y retírelo cuando no lo estén.

Retire un prefijo y observe qué pasa

Pruebe por etapas, y haga de la última etapa una retirada. Confirme que el anuncio llega, que el prefijo aparece en cada tabla prevista, que el dispositivo es el siguiente salto, que el reenvío cruza el túnel activo y que el extremo remoto responde. Después retire un prefijo de prueba, o cierre un túnel aprobado, y observe si el tráfico se mueve donde el diseño dice que debería. Anote las tablas de antes y después mientras la prueba sigue abierta.

Mover una ruta a un segundo dispositivo no mueve las sesiones que llevaba, porque el estado de NAT y del cortafuegos se queda en el primer equipo.

Para un conjunto fijo de una docena de prefijos, las rutas estáticas en las tablas de la VPC siguen siendo la respuesta más barata. Route Server se gana su sitio cuando la lista de prefijos cambia de verdad y la política de retirada es algo que puede explicar a la persona de guardia.