Résumé

  • BFD contrôle rapidement la vivacité d’un chemin et d’un protocole de données déterminés ; la session reste liée à ses extrémités, son encapsulation et ses paramètres.
  • L’état Up ne démontre pas que tous les membres ECMP, familles d’adresses, routes, MTU ou services empruntent le même chemin valide.
  • Une affirmation de service exige un reçu commun : identité et temporisations BFD, RIB/FIB, couverture des membres, sondes bidirectionnelles à taille réelle et transaction applicative.

Un voyant vert à côté d’un flux perdu

Imaginez la scène : à la fin d’une maintenance, les adjacences sont revenues et le tableau de bord affiche BFD Up vers le prochain saut du client. Le changement est clos. Pourtant, les transferts volumineux continuent de s’interrompre : les petits paquets de contrôle prennent un membre sain du faisceau, tandis que certains flux de production sont hachés vers un membre dont l’entrée de transfert ou le traitement MTU est défectueux.

BFD n’a rien affirmé de faux. C’est l’opérateur qui a étendu la portée du constat. Le vert décrit une session et le chemin parcouru par ses paquets. La joignabilité du service englobe davantage : sélection de route, membres de transfert, deux sens, tailles utiles et comportement de l’application.

Le RFC 5880 assigne à BFD une mission volontairement précise : détecter rapidement les défauts du chemin bidirectionnel entre deux moteurs de transfert, liens inclus et, dans la mesure du possible, moteurs eux-mêmes. Le protocole est indépendant du média et du protocole de routage. Cette autonomie explique sa vitesse et sa réutilisabilité ; elle impose aussi de conserver le client et le chemin auxquels le résultat s’applique.

BFD ne découvre pas lui-même ses voisins. Une application demande la session et fournit adresses et paramètres. Une session distincte correspond à chaque chemin de communication et protocole de données. Lien physique, circuit virtuel, tunnel, LSP MPLS ou chemin multihop peuvent donc avoir des sessions différentes. Le sens de Up reste attaché à cette encapsulation.

Ce que signifie réellement Up

En mode asynchrone, les deux systèmes envoient périodiquement des paquets BFD Control ; une absence suffisamment longue conduit à Down. En mode Demand, les contrôles périodiques peuvent cesser parce qu’un autre mécanisme est censé vérifier la connectivité, avec une séquence Poll pour demander une vérification explicite. La fonction Echo fait boucler des paquets dans le plan de transfert distant.

Ces modes ne donnent pas la même preuve. Echo peut révéler certains défauts de transfert invisibles au seul échange de contrôle. Demand dépend d’un moyen indépendant. Une implémentation dans le plan de contrôle peut partager son destin avec le routage ; le bit C indique seulement si l’implémentation distante se déclare indépendante de ce plan. Réduire tout cela à Up efface le contexte décisif.

Les temporisations délimitent également le constat. L’intervalle d’émission souhaité, l’intervalle de réception requis et le multiplicateur de détection déterminent le délai avant Down. Up à un instant signifie que la machine d’état n’avait pas déclaré de panne selon ces paramètres. Cela ne promet ni l’avenir immédiat ni la réaction correcte du protocole client.

Pour le cas IPv4/IPv6 à un saut, le RFC 5881 lie la session au système distant, à l’interface et au protocole. IPv4 et IPv6 nécessitent des sessions séparées sur un même lien. Plusieurs sessions n’ajoutent une preuve de diversité que si elles traversent réellement des chemins réseau distincts.

Le même texte présente BFD comme un mécanisme OAM de contrôle de connectivité pour des services réseau. Il exclut toutefois l’usage BFD ordinaire comme détecteur de panne entre applications à travers Internet. Recevoir un paquet BFD chez le voisin ne signifie pas qu’une résolution DNS, une commande ou un transfert de fichier aboutit pour l’utilisateur.

Le client conserve la décision

Le RFC 5882 qualifie le rôle de BFD de consultatif. Les protocoles de routage et autres clients reçoivent l’état, puis appliquent leurs propres mécanismes. BFD ne transporte aucune information propre à l’application. Une chute peut accélérer le retrait d’une route, mais le client garde la responsabilité de l’adjacence, de la topologie et du transfert.

Même l’historique visible peut être filtré : une implémentation peut masquer un rapide cycle Up/Down/Up par hystérésis. AdminDown exprime une décision administrative et non nécessairement la panne du chemin. Il faut donc distinguer état courant, transitions, notification au client et action effectivement prise.

ECMP peut faire emprunter des membres différents aux sondes et aux flux. Un petit contrôle passe parfois là où un paquet de service échoue à cause de la MTU. Le retour peut être cassé. Une route peut figurer dans la RIB sans l’entrée FIB attendue. Enfin, l’application peut refuser une demande pourtant correctement acheminée.

Sources