BGP Anycast et flap intermittent sur peering inter-cloud/on-prem

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' ?

Oui, et quelles sont tes valeurs de `keepalive` et `holdtime` configurées sur ton routeur on-prem ? Et sur les routeurs Cloud si tu as la main dessus. Il faut que ce soit compatible. Souvent les defaults Cloud sont plus longs.

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.