Résumé

  • La RFC 5880 fait de BFD un moyen indépendant des protocoles de détecter une panne sur un chemin de transfert bidirectionnel, potentiellement avec une très faible latence.
  • Le signal n’est pas une politique de sélection de route : les applications créent et consomment les sessions, tandis que des temporisateurs agressifs imposent des coûts de trafic, de calcul et de faux positifs.

Un signal étroit aux conséquences larges

BFD surveille le chemin bidirectionnel entre deux moteurs de transfert. Selon la RFC 5880, ce chemin peut inclure les interfaces, les liaisons de données et, lorsque c’est possible, les moteurs de transfert eux-mêmes. Le protocole est volontairement indépendant du support, du protocole de données transporté et du protocole de routage qui utilise son état.

Cette portée étroite explique son intérêt. Un protocole de routage n’a pas forcément besoin d’attendre l’expiration de son propre Hello ou temporisateur de perte avant d’apprendre que le chemin de transfert est rompu. Plusieurs services peuvent exploiter le même état sous-jacent. Pourtant, BFD ne choisit ni le préfixe à déplacer, ni le prochain saut gagnant, ni l’adjacence à supprimer. Il fournit un état ; le client conserve l’autorité de politique.

La RFC 5882 fixe nettement la limite. Pour une application, BFD sert à vérifier la connectivité entre deux systèmes, pour un protocole de données et sur un chemin donnés. Il n’est pas destiné à prouver la santé du protocole de contrôle. Un état Down peut justifier une réaction de routage, mais ne prouve pas que tous les processus de contrôle sont défaillants ni qu’une solution de repli est sûre.

Créer une session est une décision d’autorisation

BFD ne possède aucun mécanisme de découverte. L’application fournit l’adresse distante et les autres paramètres nécessaires. La couverture est donc configurée, non déduite : un chemin jamais associé à une session n’est pas protégé parce que BFD fonctionne ailleurs sur le routeur.

La RFC 5882 indique aussi que plusieurs clients surveillant le même chemin pour le même protocole de données devraient partager une session BFD. L’état devient alors une dépendance commune. Un responsable doit définir quelles applications peuvent le consommer, quelle famille d’adresses et quel chemin il représente, et comment son changement se propage aux systèmes de contrôle.

Le fonctionnement en saut unique rend ces frontières concrètes. La RFC 5881 exige des sessions distinctes pour IPv4 et IPv6 lorsque les deux sont surveillés sur le même chemin. Elle impose également une valeur TTL ou Hop Limit de 255 pour les paquets Control reçus, afin de limiter leur acceptation à un pair directement connecté. L’authentification peut protéger ces paquets, mais son déploiement et ses clés restent sous responsabilité opérationnelle.

La règle de compatibilité est tout aussi importante. Lorsqu’un voisin est réputé ne pas prendre en charge BFD, la RFC 5882 indique que l’adjacence du protocole de contrôle ne devrait pas être bloquée pour ce seul motif. BFD ajoute un signal de panne ; il n’autorise pas à rendre la connectivité de base dépendante d’une fonction absente.

Le temps de détection s’achète avec de la capacité

En mode Asynchronous, chaque système envoie périodiquement des paquets Control. Si le nombre négocié n’arrive pas dans le délai de détection, la session passe à Down. Le mode Demand peut supprimer ces émissions périodiques une fois la session Up, mais seulement si un autre mécanisme vérifie indépendamment la connectivité. La fonction Echo facultative peut tester le chemin de transfert au moyen de paquets renvoyés par le plan de transfert distant.

Des intervalles plus courts ne créent pas une certitude gratuite. La RFC 5881 exige un dimensionnement qui évite de saturer la liaison, les files d’entrée ou le processeur chargé des paquets. Si le dispositif de surveillance surcharge le chemin ou l’équipement, des paquets BFD retardés peuvent être interprétés comme la panne que la surveillance a contribué à provoquer. Un temporisateur rapide réduit un vrai trou noir, mais peut transformer une congestion transitoire en retrait de route ou en oscillation de service.

La RFC 7419 réduit le risque d’interopérabilité grâce à un ensemble commun d’intervalles. Elle résout un problème de négociation, pas la décision de capacité. Une valeur comprise par deux équipements n’est pas automatiquement adaptée à chaque volume de sessions, architecture de files, domaine de panne ou politique de reprise.

Up ne veut pas dire stable

La machine d’état de base conserve une session Up si suffisamment de paquets Control arrivent dans la fenêtre de détection. Des pertes isolées à l’intérieur de cette fenêtre peuvent ne pas changer l’état. La RFC 9978, publiée comme spécification expérimentale, ajoute un comptage des paquets Control BFD manquants grâce à des numéros de séquence méticuleux et à un modèle YANG. L’objectif est de révéler une dégradation avant qu’elle ne dure assez longtemps pour faire passer la session à Down.

Cette extension a des limites strictes. Elle mesure les pertes de paquets BFD, pas les pertes ou le délai du trafic utilisateur. ECMP et l’agrégation de liens peuvent réordonner les paquets ; une comparaison naïve des séquences peut alors confondre réordonnancement et perte. Le signal peut orienter une analyse OAM, mais n’identifie pas seul la cause première.

Preuves et limites

Les RFC 5880, 5881 et 5882 définissent le mécanisme, les contraintes en saut unique et la relation avec les applications. La RFC 7419 normalise des intervalles communs. La RFC 9978 ajoute une mesure expérimentale de stabilité.

Ces sources ne donnent ni temporisateur universellement sûr, ni recensement actuel des déploiements, ni garantie propre à un fournisseur. Elles ne disent pas que l’état BFD révèle la cause et ne choisissent pas la route survivante.

Sources