Summary

  • Un marqueur BGP End-of-RIB indique que la mise à jour initiale est terminée pour une famille d’adresses après l’établissement de la session ; ce n’est pas un certificat global couvrant tous les AFI/SAFI.
  • Graceful Restart autorise délibérément le récepteur à conserver des routes marquées obsolètes pendant que le transfert continue. Leur remplacement, leur suppression, la sélection locale, le FIB et la viabilité du plan de données restent des preuves distinctes.
  • Il faut un reçu par pair et par famille reliant la cause du redémarrage, les capacités négociées, l’ensemble conservé, EOR, le nettoyage, le FIB et les tests de chemin.

La session s’est rétablie avant les preuves

Imaginons qu’une session BGP soit rétablie après un redémarrage. Le marqueur EOR d’IPv4 unicast arrive et l’outil de supervision passe la session au vert. Pourtant, une seconde famille contient encore des routes conservées de l’ancienne session, et un flux utilise toujours une entrée de transfert construite avant le redémarrage.

Le premier EOR ne contredit rien. Il clôt la mise à jour initiale d’une famille précise. Il ne parle pas au nom des autres familles négociées et ne teste pas la viabilité du transfert préservé. L’erreur consiste non pas à croire EOR, mais à transformer un fait protocolaire délimité en verdict global de fraîcheur.

Cette généralisation est tentante car Graceful Restart vise justement la continuité. Conserver le transfert évite des oscillations et des pertes inutiles. Mais ce mécanisme crée aussi une période où « continuer à transférer » et « avoir été validé à nouveau » ne signifient pas la même chose.

Ce que clôt réellement EOR

La RFC 4724 définit EOR, pour IPv4 unicast, comme un UPDATE sans NLRI joignable ni retrait. Pour les autres familles, le marqueur contient MP_UNREACH_NLRI sans route retirée pour le couple <AFI, SAFI> concerné. Le speaker l’envoie après avoir terminé la mise à jour initiale de cette famille, même s’il n’avait aucune mise à jour à transmettre.

La portée est inscrite dans l’encodage. Un EOR IPv4 ne dit rien sur IPv6, VPN, EVPN ou une autre famille. Même dans la famille visée, il signifie que l’émetteur a terminé ce qu’il entendait envoyer. Le récepteur doit encore appliquer les mises à jour, remplacer les routes obsolètes, supprimer celles qui le restent, exécuter sa sélection et programmer le transfert.

La RFC sépare également la production d’EOR de la capacité à préserver le transfert. Un speaker peut annoncer Graceful Restart sans aucune famille uniquement pour signaler qu’il produira EOR et qu’il sait assister un pair qui redémarre. La présence de la capacité ou du marqueur ne prouve donc pas que ce speaker a préservé un état de transfert utilisable.

Le bit Restart State résout un autre problème de coordination. Le speaker qui redémarre le positionne dans son nouvel OPEN ; un pair ne doit alors pas attendre son EOR avant de lui réannoncer des routes. Une fois la session revenue, le speaker en redémarrage diffère sa sélection pour une famille jusqu’à réception des EOR des pairs concernés ou expiration de son Selection_Deferral_Timer. Ce n’est qu’ensuite qu’il sélectionne, met à jour le transfert, retire son propre état stale et envoie l’EOR de cette famille. Une heure d’EOR privée de cette séquence confond la fin des annonces des pairs avec l’achèvement du transfert local.

Les routes conservées sont explicitement obsolètes

Lorsque le récepteur détecte la perte d’une session dont le pair avait annoncé Graceful Restart pour une famille, il conserve les routes de cette famille et les marque stale. Pour le transfert, il ne les distingue pas des autres routes. C’est une continuité intentionnelle, pas une affirmation de fraîcheur.

Les règles de nettoyage fournissent l’horloge manquante. Si la session ne revient pas avant le Restart Time annoncé, les routes conservées doivent être supprimées. Après rétablissement, elles le sont aussi immédiatement si la nouvelle capacité omet la famille, si son bit Forwarding State n’est pas positionné ou si la capacité a disparu. Les nouvelles annonces remplacent les routes stale ; à l’arrivée de l’EOR de cette famille, tout reliquat obsolète doit être retiré.

L’identité et le sort des routes comptent davantage que la couleur de la session. Avant EOR, une route conservée peut attendre son remplacement. EOR fixe la limite permettant de supprimer ce qui reste. Après EOR, la sélection locale et le FIB doivent encore produire un résultat exploitable.

La viabilité du transfert est une autre observation

Le bit Forwarding State par famille concerne la préservation de l’état de transfert. La RFC 4724 le lie à la préservation effective, avec une réserve de configuration. Ce n’est pas un test de paquet. La RFC laisse hors de son périmètre la méthode permettant de décider si le transfert du pair reste viable et ne cite BFD ou la surveillance de couche 2 qu’à titre d’exemples.

Un prochain saut préservé peut devenir inutilisable pendant que les routes sont conservées. Le FIB local peut prendre du retard sur le RIB. Des paquets peuvent être perdus ou boucler après le retour de la session et le traitement d’EOR. Inversement, le statut stale ne prouve pas un échec : le transfert conservé peut fonctionner exactement comme prévu.

La RFC 8538 étend ce comportement à certaines NOTIFICATION et à l’expiration du Hold Time lorsque les pairs ont échangé le bit N. Les deux speakers agissent alors comme récepteurs et gardent les routes de l’autre. Un Hard Reset exige au contraire une réinitialisation complète. Lorsque le bit N a été échangé, la règle qui supprimait une route déjà stale lors de redémarrages consécutifs est assouplie ; la minuterie devient donc la limite indispensable contre une conservation indéfinie. L’extension rend obligatoire un stale timer configurable, suggère 180 secondes par défaut et avertit des risques d’une conservation longue ou infinie.

Sources