Résumé

  • Le RFC 3277 décrit une course précise : les voisins peuvent publier leurs nouvelles adjacences vers un routeur revenu alors que son propre LSP, conservé avant le redémarrage, reste encore celui que le domaine emploie.
  • Le bit Overload retire provisoirement le droit de transit, mais son effacement ne prouve ni l’identité de l’ensemble BGP requis, ni la résolution des next hops, ni l’installation dans la FIB, ni la livraison des paquets.

Un graphe de routage peut être faux sans contenir une arête mensongère.

Dans le scénario du RFC 3277, RtrB porte d’abord le chemin le moins coûteux entre RtrA et une destination externe D.1, atteinte via RtrD. RtrB tombe. RtrA bascule vers RtrC, qui fonctionne depuis assez longtemps pour disposer de la topologie et des routes BGP nécessaires. Lorsque RtrB revient, ses adjacences IS-IS se reforment en quelques secondes. Le coût redevient attractif. RtrA lui renvoie les paquets.

Mais la session BGP de RtrB et les routes externes n’ont pas encore suivi. La connectivité IGP est revenue avant l’autorité de forwarding dont le transit externe dépend. Le paquet arrive sur une machine qui sait qu’elle a des voisins, mais pas encore comment atteindre D.1.

Publié en avril 2002 comme RFC informatif, le RFC 3277 ne crée pas un nouveau champ. Il utilise le bit Overload du LSP IS-IS pour maintenir la joignabilité des réseaux directement connectés tout en interdisant provisoirement le calcul de chemins de transit par le routeur. Le bit pourra être effacé après la synchronisation BGP, ou après un autre déclencheur choisi par l’implémentation.

Cette description est déjà utile. La partie décisive vient ensuite : comment faire en sorte que le domaine voie le bit avant de réutiliser le routeur ?

Le graphe mélange deux générations

Le LSP que RtrB avait émis avant sa disparition peut rester dans les bases des autres routeurs. À son retour, RtrB établit une adjacence avec RtrA puis avec RtrD. Chacun de ces voisins régénère son propre LSP et annonce la relation nouvelle. Or RtrB peut encore être en train de synchroniser sa base et ne pas avoir diffusé son nouveau LSP avec Overload.

Le domaine possède alors des arêtes présentes et un sommet ancien. SPF peut relier le tout. L’adjacence publiée par RtrA est actuelle. Le LSP conservé porte une origine légitime. Leur assemblage ne correspond pourtant à aucun état cohérent du routeur revenu.

Une vérification qui se limite à « signature valide », « durée de vie non expirée » et « adjacence UP » ne détecte pas cette faute de génération. La cohérence exige de savoir à quelle incarnation du processus appartient chaque objet, et dans quel ordre les faits ont acquis le droit d’influencer le calcul.

Le RFC 3277 recommande donc au routeur de mettre à jour et de diffuser son LSP dès chaque établissement d’adjacence, avant même la synchronisation de la base. Il ne s’agit pas seulement de rendre l’information plus fraîche. Le nouveau LSP doit porter Overload assez tôt pour empêcher les LSP des voisins de réactiver l’ancien portrait de RtrB.

L’ordre de publication devient ainsi un mécanisme de contrôle. Un voisin qui annonce la relation ouvre une possibilité de chemin. Le routeur qui publie son état Overload limite cette possibilité. Si la première action arrive seule, le réseau peut accorder une autorité de transit à un objet hérité.

Pour l’audit, il faut conserver l’identité du boot, la séquence et la provenance du LSP auto-originaire, l’instant d’établissement de chaque adjacence, les accusés de diffusion, la génération de base utilisée par SPF et la décision de route qui en découle. Une ligne de journal plus récente ne rajeunit pas le contenu qu’elle relit.

Rester joignable sans devenir un corridor

Pourquoi ne pas émettre un LSP vide ? Parce que la remise en route de BGP dépend souvent d’une adresse loopback annoncée dans l’IGP. Les sessions iBGP s’appuient sur cette identité stable. Retirer toute la joignabilité locale empêcherait de reconstruire le protocole dont on attend précisément la convergence.

Le bit Overload exprime donc un état intermédiaire : le routeur et ses préfixes locaux doivent rester atteignables, mais il ne doit pas encore servir de transit entre d’autres nœuds.

Le sujet est voisin du mécanisme OSPF du RFC 3137, déjà couvert par BTW, sans le répéter. Le texte OSPF traite de MaxLinkMetric, du maintien de la joignabilité propre, de la préférence plutôt que du retrait et du cas où aucun autre chemin n’existe. Ici, l’objet éditorial est la composition temporelle propre à IS-IS : une adjacence nouvelle rend actif un LSP d’une incarnation antérieure avant l’arrivée de l’état Overload actuel.

Overload ne dit pas ce qui manque à RtrB. Il ne certifie ni le nombre de routes BGP, ni la préservation de la FIB, ni l’état des interfaces. Il transmet une instruction étroite au domaine : ne pas calculer de transit par ce nœud maintenant.

L’effacer est tout aussi étroit. Cela rend le nœud admissible au prochain SPF. Ce n’est pas un certificat universel de santé.

Une quantité BGP ne donne pas l’identité des routes

Le RFC laisse les déclencheurs à l’implémentation. Il cite un délai de N secondes après le démarrage ou l’atteinte de N préfixes dans la BGP Loc-RIB.

Le délai mesure du temps, pas un accomplissement. Un pair peut être lent, une famille d’adresses absente, une politique incorrecte ou un next hop irrésolu. À mesure que la table et la charge du plan de contrôle augmentent, un délai auparavant prudent peut devenir téméraire.

Le compteur se rapproche du phénomène attendu, mais reste une cardinalité. Deux ensembles de 900 000 routes peuvent avoir des membres différents. Une route par défaut ou un préfixe d’infrastructure critique peut manquer alors que des milliers d’autres entrées remplissent le quota. La présence dans la Loc-RIB ne prouve pas que le chemin est résolu ou installé dans le matériel.

Un seuil demeure exploitable s’il reste présenté comme un seuil. L’opérateur doit documenter sa provenance, les routes indispensables vérifiées séparément, le coût d’un faux positif, la personne autorisée à modifier la politique et le signal qui remettra Overload si l’observation contredit la décision.

Une réception plus forte peut joindre la liste des pairs attendus, les familles, un digest de l’ensemble de routes, les préfixes obligatoires, la résolution des next hops, la comparaison RIB/FIB et un test contrôlé du chemin de transit. Cette liste n’est pas une nouvelle obligation du RFC ; c’est la traduction opérationnelle du fait qu’un compteur ne peut porter l’autorité de tous ces objets.

Le refus de transit exige lui-même une topologie sûre

Contrairement à une simple hausse de métrique, le modèle Overload du RFC 3277 exclut le routeur de tout chemin de transit. Si RtrB est le seul passage vers des routeurs en aval, son exclusion peut supprimer le dernier chemin faisable. Une défense contre le blackhole devient alors une cause d’indisponibilité.

La prudence n’a donc pas la même forme dans un réseau redondant et dans un réseau sans alternative. Il faut prouver que le chemin de repli existe, qu’il a la capacité suffisante, qu’il ne partage pas la même défaillance et que sa FIB est actuelle. Le dessin du RFC suppose ces qualités pour RtrC ; il ne les démontre pas pour un déploiement réel.

Le RFC avertit aussi qu’une interprétation incorrecte du bit par certains systèmes du domaine peut créer des boucles. L’authentification d’un LSP peut établir son origine ; elle ne garantit pas une mise en œuvre homogène du calcul ou de la programmation FIB.

La politique de démarrage doit donc répondre à deux questions : quel fait permet au routeur revenu de reprendre le transit, et quel fait permet au reste du domaine de continuer sans lui pendant l’attente ?

Le RFC 8706 retient l’arête au lieu de courir derrière elle

Le RFC 5306 a normalisé le restart signaling IS-IS en 2008. Le RFC 8706 l’a remplacé en 2020 et distingue le routeur qui restart avec un forwarding conservé du routeur qui start sans cet état.

La différence est matérielle. Signaler un redémarrage planifié tout en ayant perdu la FIB laisserait les voisins maintenir une croyance que le plan de données ne peut plus honorer. Le texte plus récent l’interdit.

Pour un routeur en start, les LSP de l’incarnation précédente peuvent rester dans le réseau et paraître plus récents que les premières séquences émises après réinitialisation. Le RFC 8706 donne au routeur le bit SA du Restart TLV. Il peut demander aux voisins de supprimer l’annonce de l’adjacence jusqu’à la réception d’un IIH où SA est effacé. L’adjacence supprimée ne doit pas non plus entrer dans leur calcul SPF.

Le contrôle se déplace. Le RFC 3277 demandait au nouveau LSP Overload de gagner la course contre les annonces voisines. Le RFC 8706 permet de retenir l’arête qui rendrait l’ancien LSP exploitable. Les deux approches montrent que l’identité temporelle n’est pas une annotation : elle décide si le graphe peut agir.

La publication d’une norme ne prouve pas le support universel de SA, son activation ni le comportement des domaines mixtes. Ces états doivent être lus dans l’équipement et testés.

Plusieurs mécanismes de reprise, plusieurs preuves

BGP Graceful Restart peut conserver certaines entrées de forwarding pendant la reprise du contrôle. IP Fast Reroute peut protéger localement une panne détectée. Ordered FIB convergence peut réduire des transitoires en ordonnant les mises à jour après un changement de topologie.

Aucun de ces mécanismes ne donne une identité commune à une adjacence neuve et à un ancien LSP. Aucun compteur ne se transforme en inventaire par leur seule présence. Aucun LSP qui efface Overload ne prouve l’installation matérielle ou la livraison d’un service.

Le Restart TLV, le bit Overload, l’état BGP retenu, le résultat SPF, la RIB, la FIB et la sonde répondent à des questions différentes. Leur corrélation produit une preuve ; leur fusion en une seule lumière verte détruit l’explication.

La doctrine Heng Lu du dossier demande un noyau commun étroit et une autorité vérifiable dans l’état exécuté. Appliquée ici, elle autorise le protocole à dire « ne me choisissez pas pour le transit ». Elle ne l’autorise pas à déclarer implicitement que BGP est complet, que la puce a reçu toutes les routes ou que l’utilisateur est servi.

La chaîne défendable suit l’incarnation, la conservation éventuelle du forwarding, l’adjacence, le nouveau LSP, sa diffusion, l’interprétation d’Overload, la synchronisation IS-IS, l’ensemble BGP requis, la résolution, l’installation FIB, l’admission graduée du transit, le paquet observé, le résultat et le retour arrière.

Incertitude

Cette analyse porte sur les textes protocolaires, pas sur un incident nommé ni sur un inventaire actuel des implémentations. Le RFC 3277 évoque plusieurs grands réseaux sans les identifier et sans fournir de mesures ; cette phrase ne démontre ni adoption contemporaine ni gain quantifié. Le support du RFC 8706, les déclencheurs, les versions mixtes, la programmation matérielle et la capacité de repli doivent être vérifiés localement.

Sources