Résumé

  • Une mise à niveau planifiée peut vérifier et conserver les tables de transfert avant l’arrêt du contrôle ; un crash ne possède pas ce reçu préparatoire, même s’il tente ensuite un redémarrage gracieux.
  • RFC 5187 impose aussi la conservation du lien sémantique entre LSA ID et préfixe, puis entre Interface ID et interface, afin que les anciens LSA parlent encore des mêmes objets.

La console attribua le même statut « graceful » à deux événements. Le premier était un basculement programmé vers un processeur redondant, précédé d’un contrôle du FIB. Le second était un crash dont la raison restait inconnue. Aucun système n’avait observé l’état des tables juste avant la panne.

Le vocabulaire commun cachait une différence de preuve. Dans le premier cas, l’opérateur avait préparé la continuité. Dans le second, il espérait que l’état survivant était sain.

La grâce repose sur un transfert déjà prêt

RFC 3623 décrit un redémarrage du logiciel OSPF tandis que la fonction de transfert demeure active. La sécurité de la méthode suppose une topologie stable et des tables conservées. Avant un redémarrage planifié, le routeur doit s’assurer qu’elles sont à jour et qu’elles survivront.

RFC 5187 adapte ce mécanisme à OSPFv3. Le routeur émet une grace-LSA de portée locale au lien, type 0x000b. Elle contient obligatoirement la durée demandée et une raison : inconnue, redémarrage logiciel, rechargement/mise à niveau ou passage vers un contrôleur redondant.

Une panne imprévue n’a pas pu effectuer les étapes de préparation ni enregistrer l’intention avant l’événement. Elle peut encore tenter la procédure, mais l’incertitude doit rester visible. Le champ unknown n’est pas une variante esthétique de software upgrade.

Émettre une demande n’engage pas les voisins

La grace-LSA demande aux voisins de continuer à annoncer le routeur comme pleinement adjacent pendant une période bornée. Elle ne constitue pas une acceptation.

Chaque voisin applique sa politique : ne jamais aider, plafonner la durée, n’aider que certaines raisons, ou refuser pendant son propre redémarrage. La relation d’aide est propre à un segment. Un routeur peut donc recevoir du soutien sur une interface et pas sur une autre.

Le dossier doit enregistrer la demande, la décision de chaque voisin, son échéance et sa cause de sortie. Un voyant global ne doit pas remplacer cette matrice.

Les nombres doivent garder leur objet

Les LSA ID d’OSPFv3 pour les préfixes inter-zone et externes sont des entiers non signés de 32 bits. Ils ne contiennent pas le préfixe qu’ils désignent. RFC 5187 exige que le routeur conserve leur correspondance pendant le redémarrage.

Un même entier réaffecté à un autre préfixe produit une continuité numérique trompeuse. Un autre entier attribué au même préfixe provoque du churn alors que le besoin était de conserver la description. Il faut comparer la table complète avant et après : LSA ID, préfixe, longueur, portée et origine.

Cette obligation est le cœur distinctif de RFC 5187. Elle ne dit pas seulement « l’état a survécu ». Elle demande que le nom conservé continue à désigner le même objet.

Interface ID doit aussi survivre

Dans OSPFv3, les identifiants des Link-LSA et Network-LSA ainsi que les descriptions de liens dans les Router-LSA dépendent des Interface IDs. Leur changement crée un décalage entre les LSA antérieurs et l’état d’adjacence des voisins, ce qui termine prématurément le redémarrage gracieux.

La synchronisation entre voisins serait possible, mais RFC 5187 place la responsabilité sur le routeur qui redémarre : conserver est plus robuste, déterministe et simple. Beaucoup d’implémentations emploient IfIndex. RFC 2863 explique que sa persistance et sa réaffectation doivent être traitées explicitement.

Une étiquette physique identique ne suffit pas. Le reçu joint port, ifName, IfIndex, OSPF Interface ID, adresse link-local, Router ID voisin et références LSA avant/après.

Une topologie modifiée annule la fiction sûre

Pendant la grâce, le routeur reconstruit sa base et calcule des routes, mais s’appuie sur les entrées de transfert antérieures. Il ne peut pas les adapter rapidement à chaque changement. Les helpers surveillent donc la topologie et peuvent sortir sur modification pertinente, expiration ou réussite.

Le strict LSA checking est volontairement conservateur. Sa sortie anticipée n’est pas une anomalie que l’exploitation doit masquer pour conserver un taux de réussite. Elle restitue l’autorité à la convergence OSPF normale lorsque les hypothèses disparaissent.

Mesurer seulement le temps restant donne une image incomplète. Il faut observer les sorties de helpers, les changements LSA, les next hops, les compteurs, le chemin et la livraison.

L’authentification ne prouve pas la fraîcheur du monde

RFC 5187 décrit la possibilité de rejouer un Link-Update contenant une grace-LSA afin de faire croire qu’un routeur hors service redémarre. Le texte juge le rejeu de Hello plus simple pour garder l’adjacence et n’annonce donc pas une nouvelle classe de risque.

Cette nuance doit être conservée. Le message peut être formellement acceptable sans décrire la situation actuelle. Les mécanismes d’authentification de RFC 4552 et le trailer plus récent de RFC 7166 fournissent du contexte cryptographique ; l’exploitation conserve séquence, âge, anti-rejeu et observation du voisin.

Le reçu distingue la préparation de la récupération

Il contient : identifiant de changement ; caractère planifié ou non ; versions et processeurs ; Router ID ; durée et raison ; grace-LSA par interface ; politique et sortie de chaque helper ; preuve que le FIB était à jour ; fingerprint du transfert ; tests de paquets ; carte LSA ID-préfixe ; carte port-IfIndex-Interface ID ; chronologie des adjacences et de la LSDB ; RIB/FIB ; changement de topologie ; sécurité ; rollback et état final.

Dans les couches de réalité de Heng Lu, la raison codée et la période sont des symboles de coordination. La table de transfert et les paquets sont la réalité exécutable. Une adoption volontaire reste saine quand la politique locale demande davantage de preuve à un crash qu’à une opération préparée.

Sources

  1. RFC 5187 HTML
  2. RFC 5187 texte
  3. RFC Editor
  4. IETF Datatracker
  5. Historique
  6. Références
  7. Errata RFC 5187
  8. RFC 3623 — redémarrage OSPF gracieux
  9. Information RFC 3623
  10. RFC 5340 — OSPF pour IPv6
  11. Information RFC 5340
  12. RFC 2740 — OSPF IPv6 d’origine
  13. RFC 2863 — Interfaces Group MIB
  14. RFC 1213 — MIB-II
  15. RFC 4552 — authentification OSPFv3
  16. RFC 7166 — trailer d’authentification OSPFv3
  17. IANA — paramètres OSPFv3
  18. Heng Lu — couches de réalité
  19. Heng Lu — spécification minimale et adoption volontaire
  20. Heng Lu — code en service prioritaire