Por qué una ruta de subred en AWS VGW no puede elegir un solo túnel VPN

Dos conexiones Site-to-Site VPN terminan en una misma puerta de enlace privada virtual y anuncian el mismo prefijo de sucursal. La tabla de rutas de la subred contiene una entrada para ese prefijo, apuntando a la puerta de enlace, y ningún campo que nombre un túnel. La preferencia entre las conexiones ocurre, por tanto, en un lugar que la consola no etiqueta como enrutamiento. Saber qué capa posee la decisión es la diferencia entre un standby que funciona y un cambio que no hace nada.

Hay dos capas en juego: la ruta de la VPC que dice qué puerta de enlace, y la elección de túnel de la propia puerta de enlace. Confundirlas produce ediciones que parecen correctas en la tabla de rutas y nunca mueven un paquete.

Dos capas que parecen una

La ruta de subred responde a una sola pregunta: para este destino, ¿qué adjunto? Su destino es la puerta de enlace privada virtual, y su métrica compite solo con otras rutas de la misma tabla. Nada en esa entrada distingue el túnel uno del túnel dos, ni la conexión A de la conexión B. Un prefijo más específico es otra coincidencia de destino, no una elección de ruta más fina.

La puerta de enlace responde a la siguiente pregunta: entre los túneles que mantiene para ese prefijo, cuál transporta tráfico ahora. Esa decisión proviene de la salud del túnel y de los atributos BGP recibidos de la puerta de enlace del cliente, y nunca aparece en la tabla de rutas de la subred.

Qué compara realmente la VGW

La salud va primero. Un túnel caído, o una sesión BGP que no ha subido, pierde antes de que se examine cualquier atributo. Por eso anteponer una ruta en una conexión que ya falla no cambia nada.

Entre las rutas elegibles para el mismo prefijo, AWS prefiere el AS_PATH más corto. Cuando dos rutas tienen la misma longitud, compara el MED, sujeto a la condición documentada sobre el primer AS de la ruta. Lea el orden publicado en lugar de la versión del folclore, porque el folclore suele omitir el paso de salud y la excepción de las rutas estáticas. Una consecuencia: tres anteposiciones en la conexión de respaldo hacen que la primaria sea estrictamente más corta, que es la forma habitual de expresar la preferencia.

Anteponer, y cuándo no hace nada

La anteposición ocurre en los anuncios salientes de la puerta de enlace del cliente, no dentro de AWS. Usted añade su propio ASN dos o tres veces al prefijo que quiere que AWS evite, y AWS entonces ve una ruta más larga para esa conexión. La conexión primaria conserva el anuncio sin anteponer. Si ambas conexiones anuncian desde el mismo ASN con el mismo número de anteposiciones, no ha expresado ninguna preferencia.

Compruebe la ruta recibida en el lado de AWS después del cambio. Una anteposición que nunca salió del dispositivo del cliente se ve exactamente igual que una que AWS ignoró.

Las rutas estáticas ignoran todo el argumento

Si la conexión usa enrutamiento estático no hay ningún AS_PATH que alargar. AWS documenta las rutas VPN estáticas como prioritarias sobre las rutas aprendidas por BGP para el mismo prefijo, así que un diseño mixto no se comporta como uno totalmente dinámico. Decida primero el tipo de enrutamiento y luego elija el mecanismo de preferencia que existe para él.

Con dos conexiones estáticas que anuncian el mismo prefijo, la palanca útil es el prefijo: anuncie un rango más específico en la conexión que quiere usar, y acepte que cambió qué destino coincide en lugar de qué ruta gana.

Por qué una puerta de enlace de tránsito es otra respuesta

Una puerta de enlace de tránsito admite multipath de igual coste entre adjuntos VPN, así que dos conexiones pueden compartir tráfico en lugar de que una quede en reserva. Ese diseño tiene otra superficie de fallo: los flujos se reparten entre túneles, y un túnel que cae mueve solo parte de la carga. Copiar una receta de VGW en una puerta de enlace de tránsito, o al revés, genera expectativas que ninguna de las dos plataformas cumple.

Elija el modelo antes que el mecanismo: activo y reserva con una preferencia fijada, o activo y activo con ECMP.

Qué verificar después de configurarlo

Confirme cuatro cosas en orden. La tabla de subred sigue resolviendo el prefijo hacia la puerta de enlace prevista. La puerta de enlace lista ambos túneles como activos. El AS_PATH recibido en la conexión que quiere evitar es más largo que el otro. Y un flujo real desde una instancia de esa subred atraviesa el túnel esperado, observado en ambos extremos en lugar de inferido de un estado verde.

Luego ejecute la prueba de conmutación aprobada y observe cómo la ruta superviviente transporta el servicio. Una preferencia que solo existe en un diff de configuración todavía no es una preferencia.