Résumé

  • Le HoldTimer historique mesure la dernière réception d’un message BGP admissible ; il peut rester satisfait alors que les UPDATE, retraits et KEEPALIVE locaux sont bloqués dans l’autre sens.
  • RFC 9687 ajoute un SendHoldTimer configuré localement. À son expiration, l’orateur consigne la cause, libère les ressources BGP, ferme TCP et repasse en Idle.
  • Une exploitation sûre distingue message produit, octets transmis, traitement distant et acheminement réel ; elle choisit un délai supérieur au HoldTime négocié et empêche les reconnexions de devenir une boucle de surcharge.

Le cas d’incident paraît contradictoire. Un routeur de bord retire une route défaillante et prépare l’annonce de remplacement. Le pair continue pourtant à lui envoyer des KEEPALIVE. Le HoldTimer repart à chaque arrivée, tandis que la file d’émission grossit parce que l’application distante ne lit plus son flux TCP. Le voisin conserve ainsi la dernière route reçue, précisément celle que l’AS local vient d’abandonner.

Ce n’est pas un défaut de décision de route. C’est une rupture de l’autorité de transmission : la nouvelle décision existe, mais ne peut plus devenir un fait partagé.

Deux directions, deux preuves

TCP fournit un flux bidirectionnel ; il ne garantit pas une progression symétrique. RFC 9687 prend comme exemple canonique une fenêtre de réception distante à zéro. Le pair peut encore écrire vers le système local, même s’il refuse tout octet dans le sens inverse. Une application saturée, un lecteur bloqué ou une file interne défaillante peuvent produire la même dissociation.

Dans RFC 4271, la réception d’un UPDATE ou d’un KEEPALIVE relance le HoldTimer. Ce mécanisme prouve une activité entrante. Il ne prouve ni qu’un retrait local a quitté la machine, ni que le processus distant l’a traité. De même, la création d’un UPDATE n’est pas son émission ; l’acceptation par le tampon noyau n’est pas sa lecture distante ; l’état TCP Established n’est pas la disponibilité de BGP.

La différence devient critique lorsque le message bloqué modifie la portée. Un KEEPALIVE retardé est un signal de santé ; un retrait retardé maintient une route périmée. La durée pertinente est donc l’âge de la dernière émission BGP réussie, pas seulement celui de la dernière réception.

Le mécanisme de RFC 9687

RFC 9687 ajoute SendHoldTime, SendHoldTimer et l’événement 29 SendHoldTimer_Expires à la machine d’états. La valeur est une politique locale par pair, non une capacité négociée. Le voisin n’a pas à connaître le mécanisme pour que le système local protège son propre état.

Lors de l’entrée en Established depuis OpenConfirm, le compteur démarre si SendHoldTime n’est pas nul. Chaque message BGP envoyé avec succès le relance. Il s’arrête à la sortie d’Established, ainsi que lorsque SendHoldTime ou le HoldTime négocié vaut zéro. Toute valeur non nulle doit être supérieure au HoldTime négocié.

Le RFC recommande une activation par défaut et propose le maximum entre huit minutes et deux fois le HoldTime négocié. Cette valeur est un point de départ, pas une politique universelle. Un réflecteur, un serveur de routes, un transit et un équipement contraint n’ont ni la même charge ni le même coût de réinitialisation.

À expiration, l’orateur doit consigner Send Hold Timer Expired, libérer les ressources BGP, fermer TCP, mettre à jour l’état de reprise et retourner en Idle. Une NOTIFICATION peut être tentée uniquement si elle ne retarde pas la fermeture. IANA réserve le code d’erreur 8, sous-code 0, sans données supplémentaires. Puisque le défaut peut justement empêcher sa livraison, le journal local est l’autorité première.

Aucun substitut entre les détecteurs

HoldTimer observe les réceptions BGP. SendHoldTimer observe la progression des émissions BGP locales. BFD éprouve la continuité d’un chemin de transfert. Les retransmissions et keepalive TCP renseignent le transport. Ces instruments peuvent raisonnablement diverger.

BFD peut rester sain alors que l’application BGP distante est figée. TCP peut rester Established. Le HoldTimer peut être continuellement relancé. L’expiration du SendHoldTimer révèle alors une absence précise : aucune progression de l’émission BGP locale.

Il faut conserver quatre propositions séparées dans la chronologie : réception locale, émission locale, traitement de route distant et transfert de paquets. Le nouveau compteur ne détecte pas tous les « zombies » BGP et ne prouve pas une panne de données. Il donne une limite à l’attente lorsque l’émission est durablement impossible.

Une fermeture peut aggraver une surcharge

Réinitialiser une session retire ou invalide les routes apprises, déclenche les recalculs et peut lancer un transfert de table complète à la reconnexion. Sur un réflecteur à fort éventail, plusieurs expirations simultanées créent une vague de convergence.

Un délai trop court transforme un ralentissement d’ordonnancement, une brève contre-pression ou une fenêtre nulle transitoire en coupure évitable. Si le lecteur distant reste saturé, les reconnexions et tables complètes renforcent la cause du blocage. Un délai trop long maintient en revanche l’autorité de routes périmées.

La valeur doit intégrer le HoldTime négocié, les pauses observées, les pics d’UPDATE, la taille des tables, le comportement des files et la dynamique de reprise. Les classes de pairs méritent des paramètres distincts. Un amortissement d’oscillation peut freiner les tentatives ; il ne répare ni la capacité ni un lecteur affamé.

Prouver l’asymétrie sans couper le chemin

Débrancher un lien ne teste pas ce mécanisme : BFD ou HoldTimer interviendra probablement d’abord. Le bon canari conserve le chemin de transfert et les messages entrants, tout en empêchant de manière contrôlée le récepteur BGP distant de lire.

BIRD 3.3.0 documente disable rx pour les tests et avertit de ne pas l’utiliser en production. Dans un laboratoire isolé, cet outil permet de créer l’asymétrie. Avant l’injection, il faut enregistrer versions, HoldTime, SendHoldTime effectif, état du compteur et files normales. Pendant le défaut, il faut montrer les KEEPALIVE entrants, l’arrêt de l’horodatage de dernière émission, la file croissante ou la fenêtre nulle et un retrait contrôlé bloqué.

À l’expiration, on capture la cause locale, l’éventuelle tentative de NOTIFICATION, la fermeture TCP et le passage en Idle. Après suppression du défaut, on vérifie l’absence de boucle de reconnexion, la correction de la route, le FIB et les paquets. Les listes de prise en charge de FRRouting et la commande de BIRD justifient l’essai du binaire déployé ; elles n’en constituent pas le résultat.

Le détenteur du droit de coupure doit détenir les traces

Une interconnexion commerciale ne doit pas être fermée sur la seule intuition d’astreinte. Conserver le dernier message produit, la dernière émission réussie, l’âge et la profondeur de la file, la fenêtre TCP, les retransmissions, les réceptions entrantes, les relances du compteur et la cause finale rend la décision vérifiable.

Les preuves de route doivent identifier les retraits ou remplacements retenus, la durée de la vue périmée et la convergence obtenue. Les paquets complètent le dossier : une session réparée ne garantit pas un transfert réparé.

Ces données vivent souvent dans des systèmes différents. La souveraineté pratique consiste à pouvoir les réunir, les conserver et agir. Sans ce lien, l’autorité de fermeture est arbitraire ou paralysée.