Résumé

  • Le délai LLGR proposé par un voisin n’atteste ni la survie du chemin de données ni la validité actuelle de la route ; il autorise seulement une conservation bornée, famille d’adresses par famille d’adresses.
  • Une exploitation défendable doit relier capacités négociées, délai accepté, marquage, préférence et diffusion à la résolution du next hop, au FIB, aux paquets, puis à une sortie vérifiée par EoR, expiration ou intervention humaine.

Prenons un incident volontairement illustratif. La session BGP d’un PE disparaît. La période de Graceful Restart ordinaire s’achève, mais une route plus spécifique reste installée pendant six heures supplémentaires. LLGR la classe comme périmée et la rend moins préférable. Une route fraîche, mais moins spécifique, existe toujours. Pour les destinations couvertes par le préfixe conservé, le choix de correspondance le plus long continue pourtant d’envoyer les paquets vers l’ancien chemin.

Le protocole n’a pas menti. Le routeur n’a pas nécessairement de bogue. Le RFC 9494 offre précisément la possibilité de dissocier plus longtemps la disparition du plan de contrôle du retrait des informations qu’il avait publiées. Cette dissociation peut être utile. Elle peut aussi transformer une panne visible en état périmé, durable et beaucoup moins visible.

Le sujet n’est donc pas la simple compatibilité LLGR d’une plateforme. Il est la garde d’une information devenue orpheline : qui accepte sa durée de vie, qui supporte ses conséquences et quelles observations ont le droit d’y mettre fin avant l’horloge ?

Deux périodes, deux risques

Le RFC 4724 définit le Graceful Restart de BGP. La capacité 64 transporte notamment un Restart Time et des indications par AFI/SAFI. Lorsqu’une session tombe, le voisin helper peut conserver temporairement les routes du speaker en redémarrage. Les marqueurs End-of-RIB délimitent ensuite la fin de la mise à jour initiale de chaque famille.

Le RFC 8538 élargit les circonstances où cette conservation peut s’appliquer. Deux pairs qui ont échangé le bit N peuvent traiter de nombreuses NOTIFICATION et l’expiration du Hold Time selon les règles de reprise gracieuse. Le sous-code Hard Reset d’un message Cease réclame au contraire une terminaison complète. Le motif exact du reset fait donc partie des preuves, au même titre que son heure.

LLGR ajoute la capacité 71. Chaque tuple contient un AFI, un SAFI, des indicateurs et un Long-Lived Stale Time codé sur 24 bits. Le temps est exprimé en secondes. Le RFC ne prescrit pas de valeur par défaut : la nature des informations portées par BGP, l’échelle du réseau et les scénarios de panne ne justifient pas tous le même budget.

La capacité LLGR ne se suffit pas à elle-même. Si elle arrive sans capacité GR, elle doit être ignorée. Elle réutilise la logique de session, les marqueurs EoR et les mécanismes de reprise définis auparavant. Une exploitation qui journalise « LLGR reçu » sans vérifier GR, l’AFI/SAFI et les indicateurs n’a pas encore établi que la procédure était applicable.

Les deux périodes peuvent s’enchaîner. Durant GR, les routes conservées ne perdent pas leur préférence du seul fait de GR. Lorsque cette première période s’achève, LLGR peut prendre le relais et rendre les routes least preferred. Avant le rétablissement de la session, la borne théorique est la somme du Restart Time reçu et du LLST reçu, corrigée par les limites locales.

Chaque période peut être nulle. Le receiver peut aussi plafonner la valeur proposée. Le pair annonce donc une possibilité ; l’opérateur local décide de l’exposition réelle. Confondre ces deux valeurs revient à attribuer au voisin une autorité que l’architecture laisse au helper.

Être moins préféré ne signifie pas disparaître

Au début de LLGR, le helper lance un minuteur propre à la famille et attache la communauté bien connue LLGR_STALE. L’IANA lui attribue 0xFFFF0006, soit 65535:6. Toute route non least preferred doit battre une route LLGR stale lors de la sélection. Entre deux routes toutes deux dépréciées, les critères ordinaires reprennent.

Cette règle réduit le risque sans annuler la route. Une route périmée encore seule candidate exacte peut rester best path. Surtout, une route fraîche moins spécifique ne remplace pas nécessairement son effet dans le plan de transfert. Le RFC 9494 avertit qu’un préfixe couvert peut perdre sa connectivité lorsque la route stale reste sélectionnée.

Dans un cœur qui transfère saut par saut, le danger ne se limite pas au black hole. Les routeurs iBGP n’observent pas tous la même session locale. L’un peut déprécier une route devenue stale ; un autre peut encore la considérer fraîche. Ils peuvent choisir des sorties différentes et se renvoyer les paquets. Le RFC décrit ce risque de boucle et déconseille LLGR pour de tels ensembles de routes.

Un réseau à tunnels réduit certaines divergences de décision du cœur, sans valider pour autant le service final. La règle de résolvabilité du RFC 4271 reste applicable. Le next hop doit continuer à se résoudre. Le RFC 9494 cite BFD comme observation complémentaire possible, notamment en eBGP, mais BFD ne mesure pas l’application située au-delà.

Une route retenue n’est donc pas une route certifiée. LLGR reporte le retrait. Il ne prouve ni l’origine, ni l’autorisation, ni la programmation matérielle, ni la livraison d’un paquet utile.

Deux communautés et une frontière de confiance

La deuxième communauté introduite par le RFC est NO_LLGR, 0xFFFF0007 ou 65535:7. Une route qui la porte ne doit pas être conservée pendant la période longue. Le speaker peut ainsi exclure les informations qui ne supportent pas ce traitement ; le helper peut aussi ajouter cette exclusion par sa politique locale.

Cette faculté constitue un chemin de refus, pas une signature. Le RFC 1997 définit les communautés comme attributs de politique. Leur valeur ne révèle pas de façon authentifiée qui les a écrites. Une chaîne de preuve doit conserver les attributs reçus et réannoncés à chaque frontière utile, ainsi que les politiques qui ont pu les supprimer ou les ajouter.

Une route LLGR stale ne devrait pas être annoncée à un voisin qui n’a pas lui-même annoncé la capacité LLGR. La restriction évite d’exporter un état périmé vers un speaker incapable d’en appliquer la préférence minimale. Elle montre aussi que la rétention locale et le droit de propagation sont deux décisions distinctes.

Le RFC prévoit une exception étroite pour un déploiement partiel. L’annonce à un voisin iBGP ou de confédération non compatible est possible si NO_EXPORT est ajouté et si LOCAL_PREF est fixé à zéro. Cette préférence doit rester cohérente dans l’AS. L’objectif n’est pas d’afficher une étiquette, mais d’éviter que des critères différents produisent des sélections incompatibles.

Le retour de la session ne clôt pas le dossier

Pour chaque famille, le bit F de LLGR indique si l’état a effectivement été préservé lors du redémarrage précédent. Si la nouvelle session ne présente plus la famille, si ce bit n’est pas positionné ou si les capacités nécessaires ont disparu, le helper doit éliminer immédiatement les routes stale correspondantes.

Le minuteur n’est pas une réserve renouvelable à chaque battement de session. Sauf intervention manuelle, un LLST en cours n’est pas modifié tant qu’une nouvelle session n’est pas établie et synchronisée. La synchronisation est elle-même propre à l’AFI/SAFI : elle arrive avec l’EoR de cette famille ou à l’expiration du Selection_Deferral_Timer.

Le LLST continue de courir après le retour de la session jusqu’à l’EoR. S’il expire pendant la synchronisation, les routes que le pair n’a pas rafraîchies sont retirées. Un voisin affiché Established peut donc coexister avec un inventaire stale qui diminue. Il faut comparer l’ensemble conservé à l’ensemble effectivement réannoncé.

EoR signifie que le pair a terminé son envoi initial pour une famille. Il ne mesure pas les paquets. Une route fraîchement réannoncée peut encore échouer à la résolution, ne pas entrer dans le FIB, référencer un label obsolète ou mener à un service indisponible. La fin de l’époque de contrôle ne vaut pas réception au niveau applicatif.

Les usages où attendre a du sens

BGP ne transporte pas seulement de la portée IP classique. Certaines NLRI décrivent des contraintes de Route Target, des règles FlowSpec, de la découverte ou d’autres états proches de la configuration. Leur reconstruction peut être lente et provoquer beaucoup de churn sans améliorer immédiatement le transfert. Une conservation longue peut alors constituer un choix rationnel.

Ce raisonnement explique pourquoi le standard exige une activation affirmative par AFI/SAFI et interdit l’activation par défaut. LLGR n’est pas une qualité abstraite de haute disponibilité. C’est une exception liée au sens de l’état, à son périmètre et aux dépendances qui doivent rester valides pendant son vieillissement.

Dans un VPN MPLS, cette dépendance peut être un label. Une ancienne route peut continuer à référencer un label après que l’egress a voulu le réutiliser. Si le label est attribué à un autre VPN avant la disparition de toutes les anciennes routes, l’isolation peut être compromise. Le RFC demande que la borne basse de réutilisation dépasse la borne haute du LLST.

Les documentations de Cisco, Juniper et Nokia confirment la nécessité d’une preuve par produit et version. Cisco expose des temps envoyés et acceptés ; Juniper distingue receiver, restarter, familles, politiques et clear manuel ; Nokia documente des familles et états observables propres à SR OS. Les valeurs par défaut et périmètres ne sont pas interchangeables.

Reconstituer une période stale

Le dossier commence par les deux OPEN ou par une sortie de voisin faisant autorité. Il doit montrer capacités GR et LLGR, tuples AFI/SAFI, Restart Time, LLST, bits N et F, valeur annoncée et plafond local. Le délai proposé et le délai effectivement accepté doivent rester deux champs différents.

Il faut ensuite horodater la cause du reset, la fin de GR et l’entrée en LLGR. Pour chaque route, conserver l’ajout de LLGR_STALE, la présence ou l’ajout de NO_LLGR, la sélection Loc-RIB et les annonces qui ont traversé la frontière de capacité. La seule vue d’une communauté n’explique pas son effet.

Le plan de transfert apporte la preuve décisive : résolution récursive, membre FIB, label ou tunnel si nécessaire, puis paquets ou requêtes de service pendant la période stale. Un best path sans résultat observable demeure une intention du plan de contrôle.

Enfin, l’EoR, l’expiration ou le clear opérateur doivent produire un inventaire des routes non rafraîchies retirées. Si le service revient, la réannonce propre doit être visible ; s’il ne revient pas, le retrait doit se propager. Le propriétaire de la réduction du délai et du rollback doit être nommé avant l’incident.

Sources