BGP a appris le préfixe, mais le trafic contourne toujours le tunnel

La passerelle de l'agence affiche le préfixe du cloud dans sa table BGP, la session avec le fournisseur est établie, et pourtant la requête d'un utilisateur vers ce préfixe sort par la mauvaise interface. Rien n'est cassé comme le suggère la supervision, car « BGP l'a appris » est une affirmation sur le plan de contrôle. Entre cette table et le paquet, il y a quatre transitions distinctes, et le flux s'arrête exactement à l'une d'elles. Parcourez les portes dans l'ordre et arrêtez-vous à la première qui échoue.

Première porte : ce que le voisin a réellement envoyé

Partez du préfixe tel qu'il a été reçu, non tel qu'il a été résumé. Recherchez le réseau et le masque exacts dans la table BGP et notez le prochain saut, le chemin AS et toute communauté qu'une politique d'importation pourrait correspondre. Une route résumée dans un tableau de bord peut masquer le fait que le préfixe précis n'a jamais été accepté.

La politique d'importation est l'endroit habituel où une route disparaît sans erreur. Une liste de préfixes, un filtre de communautés ou une carte de routes entrantes peuvent écarter la mise à jour pendant que la session reste active et saine, et c'est pourquoi un voyant de voisin vert prouve si peu. L'absence d'une ligne de journal ne signifie pas l'absence d'une décision. Elle signifie généralement que la décision a été prise en silence, exactement comme configuré.

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

Lisez la sortie dans cet ordre. Les deux premières commandes indiquent si l'information est arrivée et ce que le pair affirme avoir envoyé ; les deux dernières si quelque chose a atteint les tables de routage et de transfert. Un préfixe présent dans la première commande et absent de la troisième est un problème de sélection ou d'installation, pas de connectivité.

Deuxième porte : la sélection, puis l'installation

BGP choisit le meilleur chemin, et le chemin choisi n'est pas installé automatiquement. Le prochain saut doit se résoudre, et une autre source de routes peut déjà posséder ce préfixe avec une meilleure distance administrative. Une route statique laissée par la migration gagnera sans peine contre un chemin BGP valide et enverra le trafic ailleurs.

RFC 4271 maintient trois idées séparées : ce qu'un pair a envoyé, ce que ce locuteur a choisi comme meilleur et ce qu'il annoncera ensuite. Ce sont des rôles conceptuels, non trois bases de données physiques qu'un constructeur doit exposer, mais c'est précisément cette séparation qui fait de « c'est dans BGP » une réponse incomplète.

Vérifiez aussi quel contexte de routage vous lisez. Une route installée dans une VRF à laquelle l'interface de l'utilisateur n'appartient pas est invisible pour les paquets de cet utilisateur, et la table semble correcte tout le temps.

Troisième porte : la recherche qui s'applique à ce flux

Arrêtez maintenant de vous demander quelle est la route et commencez à vous demander quel est le paquet. Notez l'adresse source de l'utilisateur, la destination, le protocole, le port et l'interface d'entrée, car chacun d'eux peut sélectionner une politique différente. Regardez ensuite la recherche qui s'applique à cette combinaison plutôt que la table de routage générale.

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 préfixe plus spécifique est la surprise la plus courante ici, et une route de politique la seconde. Les deux l'emportent sur l'agrégat que vous regardiez, et ni l'une ni l'autre n'est visible dans un résumé de la table BGP.

Un ping émis depuis la passerelle elle-même n'est pas une preuve au sujet de la session d'un utilisateur. Autre adresse source, autre chemin de politique, et souvent un autre résultat. Testez avec la même source que celle utilisée par l'application, ou acceptez que le test réponde à une autre question.

Quatrième porte : la moitié distante du chemin

Si la recherche locale sélectionne bien le tunnel, le paquet doit encore être accepté par la politique de protection, autorisé par la règle de transfert et recevoir une réponse de quelque chose de l'autre côté. Une ACL crypto qui n'inclut pas la paire d'adresses écartera le trafic alors que le tunnel se déclare actif, ce qui produit un délai d'attente indiscernable d'une panne de routage.

Le chemin de retour compte autant que le chemin sortant. Le côté cloud doit savoir comment atteindre la source de l'agence, soit par une route, soit par une traduction que vous avez configurée délibérément. Les chemins de retour asymétriques sont courants dans les conceptions testées dans un seul sens.

Corrélez une connexion autorisée récente avec trois observations : la politique locale qui a correspondu, les compteurs du tunnel qui ont bougé et la réception côté distant là où elle est visible. Si les compteurs ne bougent pas, le paquet n'est jamais entré dans le tunnel, quoi que dise la table de routage. S'ils bougent et que rien n'arrive, le côté distant l'écarte ou le route mal. Ces deux résultats mènent à des équipes totalement différentes.

Nommez la transition qui a échoué

Écrivez le résultat comme l'un de cinq états : non reçu, non accepté par la politique, non sélectionné, non installé ou non correspondant à ce flux. Ajoutez un sixième pour le cas où le chemin local est correct et où l'extrémité distante ne peut pas répondre. Cette phrase est le livrable, et elle est bien plus utile qu'une capture d'écran d'un voisin établi.

Gardez aussi un test négatif dans le plan de recette : une destination qui ne doit pas traverser le tunnel, vérifiée après le changement. Une liste de contrôle qui ne prouve que le chemin heureux n'attrapera pas la règle de politique large que quelqu'un ajoutera à la prochaine fenêtre de maintenance.