Résumé

  • La révision 19 n'active le comportement strict négocié que si les deux OPEN BGP annoncent la capability 74 ; une configuration unilatérale n'est pas cet accord.
  • Les temporisations restent locales. Un hold-down BFD, un holdtime BGP et un BfdHoldTimer mal alignés peuvent laisser un pair attendre ou fermer pendant que l'autre croit progresser normalement.
  • Une mise en production doit prouver l'état des deux automates, le mode exact du produit et le comportement de la version, pas seulement la présence du mot strict.

Le journal du routeur A répétait : attente de BFD. Celui du routeur B répétait : attente de BGP. Aucun câble n'était coupé. Les adresses répondaient. Les processus étaient actifs. Pourtant la session restait en Idle.

A attendait que la session BFD atteigne Up avant de laisser BGP avancer. B, selon son comportement local, attendait que la relation BGP soit suffisamment formée avant de créer ou de libérer l'état BFD attendu. Chaque machine protégeait une dépendance. Ensemble, elles avaient construit une boucle.

Ce scénario n'est pas hypothétique au sens où il serait inventé sans source. La documentation Juniper de la série 23.2 signale une attente indéfinie lorsqu'un routeur utilise mode strict et holddown alors que le pair ne porte pas la même configuration : le premier attend BFD, le second attend BGP. Cela ne prouve ni un incident chez un client ni un défaut universel. Cela montre pourquoi l'égalité syntaxique des configurations doit être distinguée de la compatibilité temporelle des automates.

draft-ietf-idr-bgp-bfd-strict-mode-19 tente précisément de rendre ce contrat explicite. Le texte, daté du 26 août 2026, reste un Internet-Draft actif du groupe IDR, destiné au Standards Track s'il est approuvé. Il n'est pas un RFC. Son état Datatracker reste I-D Exists; les examens précoces conservent des questions opérationnelles et de sécurité.

Une capacité commune évite de deviner le consentement

Le mécanisme IETF propose un point de rendez-vous. Le speaker qui prend en charge le mode strict et l'active annonce la capability 74 dans son OPEN. Le pair fait de même. Ce n'est qu'après avoir vu la capacité des deux côtés que l'attribut BfdStrictNegotiated devient vrai. BGP peut alors appliquer les sous-états d'attente définis par le projet.

Cette intersection est plus qu'un détail de protocole. Elle empêche en principe qu'une décision privée sur un équipement modifie silencieusement les attentes de l'autre. La configuration locale dit : « je suis prêt à utiliser cette règle ». L'OPEN dit : « voici la règle que je propose sur cette session ». La présence des deux annonces dit : « nous appartenons au même ensemble de compatibilité ».

Les produits peuvent néanmoins offrir un mode unilatéral ou un override. La documentation Cisco actuelle sépare un strict mode propriétaire, un mode négocié et une variante qui impose le comportement même si le pair n'annonce pas la capacité. Ces choix peuvent répondre à des besoins de migration. Ils changent aussi la source d'autorité : l'intersection de deux annonces devient une politique locale qui lie le voisin sans reçu bilatéral.

La question d'exploitation n'est donc jamais « le mode strict est-il activé ? ». Elle est : quel mode sémantique, dans quelle version, sous quelle commande, avec quelle capacité envoyée et reçue, et avec quel fallback si le pair ne répond pas ?

Trois horloges peuvent produire deux réalités

La révision 19 introduit BfdHoldTime, dont la valeur par défaut est de 30 secondes, et BfdHoldTimer pour empêcher une attente indéfinie lorsque le holdtime BGP négocié vaut zéro. Un autre délai, le BFD hold-down, peut obliger BFD à rester Up pendant une période de stabilité avant que BGP entre dans Established. Enfin, le holdtime BGP continue à borner l'absence de KEEPALIVE.

Ces horloges ne forment pas automatiquement une seule horloge distribuée. Le hold-down est configuré localement. Le projet recommande des valeurs similaires ; il ne négocie pas une valeur commune. Il précise que le holdtime BGP doit laisser assez de temps à l'initialisation BFD et au hold-down. Sinon un côté peut passer Established, attendre des KEEPALIVEs et fermer, tandis que l'autre n'est pas encore autorisé à les envoyer.

Le résultat visible peut être trompeur. Le routeur qui ferme inscrit expiration du holdtime. Le pair affiche attente de stabilité BFD. Un outil qui ne collecte qu'un des deux côtés conclut à une panne BGP ou à une lenteur de lien. Le mécanisme réel est une divergence de politique temporelle.

La bonne unité d'audit est donc la paire. Pour chaque extrémité, il faut le holdtime BGP, le BfdHoldTime, le hold-down ou dampening, le moment de création de BFD, l'état de la capability, le sous-état BGP et l'instant exact de chaque transition. Sans ces deux chronologies, « timeout » n'est qu'une étiquette finale.

Les sous-états sont des preuves, pas du bruit d'interface

Le projet ajoute ConnectDelayOpenBfdUpPending, ActiveDelayOpenBfdUpPending, OpenSentBfdUpPending et OpenSentConfirmedBfdUpPending. Ces noms paraissent lourds. Ils conservent pourtant la différence décisive entre plusieurs attentes.

Un pair distant peut voir sa session BFD monter avant la session locale. Il envoie alors son KEEPALIVE BGP et avance. Le local a reçu ce KEEPALIVE, mais son propre BFD n'est pas encore Up. La révision 19 mémorise cette situation dans OpenSentConfirmedBfdUpPending au lieu de prétendre que les deux plans ont avancé ensemble. L'examen BGPDIR de la révision 18 avait attiré l'attention sur cette course et sur le risque de traiter le KEEPALIVE précoce comme une erreur d'automate.

Une interface qui réduit tous ces états à « BGP down » détruit le reçu nécessaire au diagnostic. L'opérateur doit voir quelle condition manque, depuis combien de temps, ce que le pair a déjà envoyé et quelle horloge décidera de la prochaine action.

Quand BFD passe Down, le sous-code BFD Down de RFC 9384 améliore l'attribution immédiate. Avant Established, la session TCP est abandonnée et les ressources libérées. Après Established, les routes apprises sont aussi supprimées. Le code de fermeture dit quelle entrée a déclenché l'action. Il ne prouve pas si BFD a détecté une rupture réelle, subi une suppression de paquets, échoué par authentification ou rencontré une configuration incompatible.

La sortie doit être conçue avant l'entrée

Un déploiement sûr commence en observation. Les deux routeurs annoncent-ils capability 74 ? Le résultat négocié est-il identique ? Les durées configurées laissent-elles une marge commune ? Le produit affiche-t-il les sous-états ? La version réellement installée correspond-elle au comportement documenté ? Les contrôles doivent être faits sur un couple hétérogène, pas seulement sur deux images identiques en laboratoire.

Le test le plus instructif n'est pas la réussite nominale. Il consiste à retarder BFD sur un côté, à rendre les hold-down différents, à supprimer la capability sur un OPEN de test, puis à couper seulement les paquets BFD. Chaque expérience doit produire une cause visible et un retour déterministe.

Le rollback a lui aussi deux côtés. Désactiver le gate localement ne libère pas le pair s'il continue d'appliquer une règle unilatérale. Modifier la configuration pendant Established peut ne prendre effet qu'au redémarrage suivant. Le plan doit donc ordonner les changements, confirmer les capacités effectives, redémarrer uniquement la session concernée si nécessaire et préserver les traces avant de nettoyer l'état.

La doctrine de Running-Code Primacy fournit une discipline utile : le texte commun définit le minimum ; la réalité réside dans le code exécuté et l'accord localement vérifiable entre participants. Ici, ce principe ne combat pas le standard. Il exige que le standard soit observé là où il devient réel : dans deux automates, deux horloges et une intersection de capacités.

Le premier routeur peut attendre BFD. Le second peut attendre BGP. La solution n'est pas de déclarer l'un légitime et l'autre illégitime à partir d'un nom de commande. Elle consiste à rendre la dépendance explicite, bilatérale, visible et réversible avant que l'attente ne devienne une panne.

Sources