Résumé

  • BGP Graceful Restart permet à un voisin compatible de conserver des routes pendant le redémarrage d’une session ; cet état de contrôle n’est toutefois pas une preuve autonome que le routeur continue de transférer le trafic concerné.
  • La protection opérationnelle est un reçu par famille d’adresses reliant capacités annoncées, minuteries, continuité de paquets observée, fin de RIB et sort final des routes périmées.

Imaginons une maintenance planifiée, explicitement hypothétique. Un routeur redémarre son processus BGP, son voisin conserve les préfixes appris et le tableau de routage montre une reprise ordonnée plutôt qu’un retrait immédiat. Le trafic d’une famille d’adresses s’arrête néanmoins. Le voisin continue de choisir la route périmée jusqu’à ce qu’une minuterie ou un événement ultérieur la supprime. Un mécanisme conçu pour masquer une brève interruption du plan de contrôle a fait durer l’échec aussi longtemps que la décision de rétention.

Ce scénario ne prouve pas que Graceful Restart est défectueux. Il montre que ses deux côtés ont été confondus. Le protocole coordonne la reprise du contrôle ; son usage sûr exige aussi que l’état de transfert reste valable pendant que le voisin utilise les informations périmées.

Ce que la capacité annonce réellement

RFC 4724 permet d’annoncer la capacité Graceful Restart. Le bit Restart State indique que le locuteur a redémarré. Pour chaque AFI/SAFI, le bit Forwarding State indique si l’état de transfert a été conservé. La promesse n’est donc ni globale ni identique pour toutes les familles.

Si l’état n’a pas été conservé pour une famille, RFC 4724 impose au voisin de retirer les routes périmées correspondantes. S’il a été conservé, le voisin peut les garder pendant le rétablissement de la session et le rafraîchissement des routes. Cette différence forme la frontière de sûreté.

Restart Time estime le temps nécessaire au retour de la session. Le voisin applique également une limite locale de rétention. Aucun de ces nombres ne mesure la livraison des paquets ; ils bornent la durée pendant laquelle le contrôle accepte la déclaration de conservation.

La fin de RIB ferme une autre question

Après le retour de la session, le marqueur End-of-RIB indique que la mise à jour initiale d’une famille est terminée. Les routes rafraîchies deviennent courantes, les autres peuvent être supprimées. Il clôt la réconciliation du routage, pas la preuve de livraison pendant l’intervalle précédent.

Le retour de session, la réception d’End-of-RIB et le succès du trafic sont donc trois observations distinctes. Les réduire à « redémarrage réussi » empêche de savoir si le service a été protégé ou si une route est simplement restée installée.

Une rétention longue augmente la preuve requise

RFC 9494 ajoute Long-Lived Graceful Restart. Il définit une rétention prolongée et la communauté LLGR_STALE, puis recommande de déprioriser ces routes pour laisser gagner une alternative. C’est utile si le transfert survit réellement plus longtemps ; une hypothèse erronée devient aussi plus durable si cette conservation a pris fin.

La question n’est pas qu’une longue minuterie soit toujours mauvaise. Elle est de savoir si minuterie, préférence et solution de rechange correspondent à la plateforme et à la topologie exploitées. La preuve doit viser la bonne famille d’adresses, la bonne table et le bon chemin.

Une NOTIFICATION ne prouve pas le transfert

RFC 8538 permet d’appliquer Graceful Restart après certains messages BGP NOTIFICATION. Le message peut expliquer la fin de session et la procédure attendue du voisin ; il n’atteste pas que les paquets ont traversé l’équipement pendant l’événement. L’absence de retrait peut être le comportement demandé au voisin, pas un résultat de livraison.

Un reçu de redémarrage par famille

Pour chaque usage accepté, consignez les deux voisins, AFI/SAFI, capacités, bits Restart State et Forwarding State, Restart Time, limite locale, politique LLGR et chemin alternatif. Ajoutez les heures de perte de session, premier paquet réussi, retour de session, End-of-RIB et retrait ou rafraîchissement final.

La mesure doit représenter le service concerné. Un ping de loopback ne valide ni les préfixes clients ni une autre table. Un succès IPv4 ne valide pas IPv6 ; une carte de ligne, FIB, VRF ou cohorte de service n’en valide pas une autre. Le reçu doit correspondre à la famille, plateforme, table et trafic dont le voisin conserve l’état.

Sources