Pourquoi une route de sous-réseau AWS VGW ne peut pas choisir un seul tunnel VPN

Deux connexions Site-to-Site VPN aboutissent sur une même passerelle privée virtuelle et annoncent le même préfixe de site. La table de routes du sous-réseau contient une entrée pour ce préfixe, pointant vers la passerelle, et aucun champ qui nomme un tunnel. La préférence entre les connexions se joue donc ailleurs que là où la console parle de routage. Savoir quelle couche détient la décision, c’est la différence entre un secours qui fonctionne et un changement qui ne fait rien.

Deux couches sont en jeu: la route du VPC qui désigne la passerelle, et le choix de tunnel de la passerelle elle-même. Les confondre produit des modifications qui semblent correctes dans la table de routes et ne déplacent jamais un paquet.

Deux couches qui n’en font qu’une en apparence

La route de sous-réseau répond à une seule question : pour cette destination, quel attachement ? Sa cible est la passerelle privée virtuelle, et sa métrique ne concurrence que d’autres routes de la même table. Rien dans cette entrée ne distingue le tunnel un du tunnel deux, ni la connexion A de la connexion B. Un préfixe plus spécifique est une autre correspondance de destination, pas un choix de chemin plus fin.

La passerelle répond à la question suivante : parmi les tunnels qu’elle détient pour ce préfixe, lequel porte le trafic maintenant. Cette décision vient de l’état du tunnel et des attributs BGP reçus de la passerelle client, et elle n’apparaît jamais dans la table de routes du sous-réseau.

Ce que la VGW compare réellement

L’état vient d’abord. Un tunnel hors service, ou une session BGP qui n’est pas montée, perd avant qu’aucun attribut ne soit examiné. C’est pourquoi préfixer un chemin sur une connexion qui échoue déjà ne change rien.

Parmi les chemins éligibles pour le même préfixe, AWS préfère l’AS_PATH le plus court. Quand deux chemins ont la même longueur, elle compare le MED, sous réserve de la condition documentée sur le premier AS du chemin. Lisez l’ordre publié plutôt que la version du folklore, car le folklore omet généralement l’étape d’état et l’exception des routes statiques. Une conséquence : trois préfixages sur la connexion de secours rendent la primaire strictement plus courte, et c’est la manière habituelle d’exprimer la préférence.

Le préfixage, et quand il ne fait rien

Le préfixage se fait dans les annonces sortantes de la passerelle client, pas dans AWS. Vous ajoutez votre propre ASN deux ou trois fois au préfixe que vous voulez qu’AWS évite, et AWS voit alors un chemin plus long pour cette connexion. La connexion primaire conserve l’annonce sans préfixage. Si les deux connexions annoncent depuis le même ASN avec le même nombre de préfixages, vous n’avez exprimé aucune préférence.

Vérifiez le chemin reçu côté AWS après la modification. Un préfixage qui n’a jamais quitté l’équipement client ressemble exactement à un préfixage qu’AWS a ignoré.

Les routes statiques ignorent tout l’argument

Si la connexion utilise le routage statique, il n’y a aucun AS_PATH à allonger. AWS documente les routes VPN statiques comme prioritaires sur les routes apprises par BGP pour le même préfixe, donc une conception mixte ne se comporte pas comme une conception entièrement dynamique. Décidez d’abord du type de routage, puis choisissez le mécanisme de préférence qui existe pour lui.

Avec deux connexions statiques annonçant le même préfixe, le levier utile est le préfixe : annoncez une plage plus spécifique sur la connexion que vous voulez utiliser, et acceptez d’avoir changé quelle destination correspond plutôt que quel chemin gagne.

Pourquoi une passerelle de transit est une autre réponse

Une passerelle de transit prend en charge le multipath à coût égal entre les attachements VPN, si bien que deux connexions peuvent partager le trafic au lieu qu’une reste en secours. Cette conception a une autre surface de défaillance : les flux se répartissent sur les tunnels, et un tunnel qui tombe ne déplace qu’une partie de la charge. Copier une recette VGW sur une passerelle de transit, ou l’inverse, crée des attentes qu’aucune des deux plateformes ne satisfait.

Choisissez le modèle avant le mécanisme : actif et secours avec une préférence figée, ou actif et actif avec ECMP.

Ce qu’il faut vérifier après la configuration

Confirmez quatre choses dans l’ordre. La table du sous-réseau résout toujours le préfixe vers la passerelle prévue. La passerelle liste les deux tunnels comme actifs. L’AS_PATH reçu sur la connexion à éviter est plus long que l’autre. Et un flux réel depuis une instance de ce sous-réseau traverse le tunnel attendu, observé aux deux extrémités plutôt que déduit d’un statut vert.

Exécutez ensuite le test de bascule approuvé et regardez le chemin survivant porter le service. Une préférence qui n’existe que dans un diff de configuration n’est pas encore une préférence.