13 commentaires
Flap BGP aléatoire ça sent le problème de timers ou d'underlay network instable. La première chose à faire est de regarder les logs BGP de _tous_ les routeurs impliqués. Que disent-ils quand ça flappe ? 'Hold Timer Expired', 'Cease', 'Notification' ?
Sur mon routeur on-prem (Cisco CSR), j'ai configuré timers bgp 20 60 (20s keepalive, 60s holdtime). Côté AWS Transit Gateway, c'est les valeurs par défaut AWS, donc 30s keepalive, 90s holdtime. Côté GCP Cloud Router, c'est 30s keepalive, 90s holdtime aussi.
Les logs montrent principalement 'Hold Timer Expired' côté cloud quand le flap se produit. Parfois 'Cease - Peer Deconfigured' sur le on-prem.
Hold Timer Expired sur le cloud signifie qu'il n'a pas reçu de keepalive de ton on-prem pendant 90 secondes. Si ton on-prem envoie des keepalives toutes les 20s et qu'il flappe, ça veut dire que les paquets BGP ne passent pas.
La différence de timers n'est pas idéale mais ça ne devrait pas faire flapper comme ça directement. Regarde le chemin réseau. Des pertes de paquets sur le lien VPN/Direct Connect/Interconnect ?
C'est clair. Fais un MTR ou un traceroute étendu depuis ton routeur on-prem vers les IP des routeurs Cloud. Cherche les pertes de paquets ou la latence instable. Les tunnels VPN sont parfois sujets à des micro-coupures ou des changements de chemin sous-jacents qui impactent la connectivité.
Y a-t-il des firewalls intermédiaires avec des timeouts de session agressifs qui couperaient les flux inactifs trop vite ? Même si BGP est actif, un firewall avec un timeout de 30s pourrait être un souci si les keepalives sont perdus.
J'ai lancé des MTRs longs. Pas de perte de paquets persistante. Quelques spikes de latence mais rien qui justifie un hold timer de 90s. Pas de firewall explicite entre mon routeur et la terminaison Cloud sur les IPs BGP. C'est Direct Connect et Cloud Interconnect.
Les Cease - Peer Deconfigured sur l'on-prem sont parfois déclenchés quand on bascule manuellement le trafic Anycast pour maintenance.
'Cease - Peer Deconfigured' en manuel, ok. Mais si ça arrive tout seul, c'est grave. Est-ce que tu as des scripts de health check qui gèrent l'annonce des préfixes Anycast ? Genre si un service est down, il retire le préfixe ?
Un script trop agressif ou buggé peut faire flapper les sessions BGP indirectement en retirant le peering lui-même au lieu du préfixe.
Oui, on a un script python qui tourne sur une machine à côté du routeur on-prem. Il surveille l'état de nos services Anycast. Si un service est injoignable localement, il exécute un no neighbor X remote-as Y puis neighbor X remote-as Y une fois le service rétabli, pour forcer un reset de la session BGP et purger la table de routage. Il tourne toutes les 10 secondes.
Voilà ton problème. Le no neighbor puis neighbor c'est une hache. Tu déchires et recrées la session BGP complète au lieu de retirer un préfixe. Ça déclenche un 'Cease - Peer Deconfigured' à l'autre bout et les routeurs Cloud avec leur holdtime à 90s ne vont pas apprécier du tout. C'est _extrêmement_ disruptif.
Absolument. Un no neighbor c'est la pire chose pour gérer un service Anycast. Tu dois plutôt utiliser BGP communities ou un simple retrait/ré-annonce du préfixe spécifique (no network X.X.X.X puis network X.X.X.X) sans toucher à la session elle-même.
Le script qui s'exécute toutes les 10 secondes est trop rapide. Si le service a un micro-lag, tu déstabilises toute ton infrastructure.
Je vois. Le but était de forcer un refresh rapide mais je n'avais pas anticipé l'impact du no neighbor. Le 'Hold Timer Expired' sur le cloud doit être une conséquence du cloud qui n'attend pas la recréation de la session ou un timing de dingue.
Je vais revoir ce script. En attendant, est-ce que baisser les holdtime sur les routeurs Cloud pour matcher mon on-prem (60s) aiderait à stabiliser même avec ce script de démolition ?
Oui, réduire les holdtime côté cloud à 60s aiderait à les faire converger plus vite si la session se casse, mais ça ne résout pas la cause racine. La cause racine est le script qui tue la session.
Modifie ton script pour juste retirer le préfixe (withdraw un network) au lieu de no neighbor. C'est la façon propre de gérer un flap de service sur un Anycast BGP.
Ok, je modifie le script pour qu'il ne fasse plus de no neighbor mais seulement le withdraw du préfixe Anycast quand le service est en panne. J'ai aussi aligné les timers BGP sur les routeurs Cloud à 20s keepalive et 60s holdtime pour avoir une convergence plus rapide en cas de problème réel.
On a eu aucun flap depuis 2 heures. Le script était clairement le coupable. Merci pour l'analyse pointue ! C'était super utile.
Laisser une réponse
Vous devez être connecté pour poster un message !
Salut l'équipe. On gère un service Anycast DNS/HTTP réparti entre on-prem, AWS et GCP. Le BGP est la colonne vertébrale. Depuis quelques jours, on observe des flaps intermittents sur nos sessions BGP entre notre routeur on-prem et les routeurs cloud (Transit Gateway AWS, Cloud Router GCP).
Les services Anycast deviennent injoignables pendant 30-60 secondes par moment. C'est aléatoire et pénible. Je ne vois pas d'erreurs évidentes dans les logs applicatifs.
Des pistes pour le diagnostic ?