Résumé

  • La mise à niveau d’une paire de pare-feu a laissé Router B sans aucun préfixe BGP pendant 121 secondes, alors que les sessions étaient « Established » et que le trafic continuait vers le pare-feu.
  • Les captures et la reproduction en laboratoire du présentateur relient l’attente à une erreur de lecture du contexte IPv6 et à un TCP Reset ; l’attente du End-of-RIB IPv6 a aussi retardé l’installation des routes IPv4.

« Established » avait l’air rassurant. La table de routage répondait plus franchement : zéro préfixe pendant 121 secondes.

C’est l’incident décrit par Marian Rychtecký à NANOG 98. Pendant la mise à niveau d’une paire de pare-feu en haute disponibilité, les sessions BGP sont revenues à l’état « Established », mais Router B ne recevait aucun préfixe. Le trafic continuait d’être dirigé vers le pare-feu. Celui-ci n’avait pas installé les routes attendues ; les paquets ont donc été perdus dans un trou noir pendant près de deux minutes.

Le chiffre clé est 121 secondes. End-of-RIB est arrivé près du délai de reconnexion de 120 secondes, mais ce délai n’explique pas toute la panne. L’enquête de Rychtecký montre que la récupération IPv4 attendait une session BGP IPv6 précise. Le redémarrage gracieux considérait l’état du pair négocié comme inachevé tant que le marqueur End-of-RIB n’était pas arrivé. Une session bloquée dans une famille d’adresses retenait ainsi les routes de l’autre.

Les captures de paquets ont révélé un reset TCP sur la nouvelle session. En laboratoire, l’adresse IPv6 attendue du pair, 2001:db8:1::2, était stockée sous la forme 2001:db8:1:. Le système ne pouvait plus rattacher la connexion au bon contexte VRF et BGP et renvoyait un reset. Pendant une partie de la bascule, l’ancienne connexion TCP semblait encore active : la nouvelle rencontrait donc un état périmé.

La leçon dépasse « le redémarrage gracieux peut échouer ». L’état BGP vert ne garantissait ni des routes dans la table ni le rétablissement du transfert. La mise à niveau du pare-feu a déclenché l’incident ; l’adresse de pair mal lue et l’attente entre familles en ont formé le mécanisme ; la RIB vide et les paquets perdus en ont été l’effet.

Le présentateur indique qu’un délai de connexion plus court a accéléré, dans ce cas, la reconnexion et l’échange End-of-RIB. C’est une solution rapportée pour cette configuration, pas un réglage universel : raccourcir une attente peut ouvrir une autre fenêtre de défaillance. La correction durable consiste à tester toute la chaîne, de la reconnexion TCP aux marqueurs par famille, à l’installation des routes puis à la livraison des paquets.

Les diapositives ne précisent ni les modèles, ni les versions logicielles, ni les pertes mesurées côté client ; ces relevés diraient s’il s’agissait d’un défaut isolé ou d’un problème répété.

Sources