Résumé

  • Le MinRouteAdvertisementIntervalTimer limite la fréquence à laquelle un locuteur BGP annonce à un pair des changements concernant une même destination. Il ne suspend pas le processus de décision local.
  • Si plusieurs chemins deviennent successivement les meilleurs pendant l’intervalle, le RFC 4271 demande d’annoncer le dernier chemin sélectionné lorsque l’envoi redevient permis. Le voisin reçoit l’état courant, pas toute la chronologie.
  • Raccourcir l’intervalle améliore la fraîcheur au prix de davantage d’UPDATE et de calcul distribué ; l’allonger absorbe l’agitation mais peut retarder une panne, une relève ou une réparation utile.

Prenons un préfixe et un pair. À 10 h 00, le chemin A est choisi puis annoncé. Quatre secondes plus tard, A disparaît et B devient meilleur. Cinq secondes encore, une règle locale fait préférer C. Le RIB local a vécu trois états et le FIB a pu en appliquer plusieurs. Le pair, lui, peut ne connaître que A puis C. B n’était pas imaginaire : il a seulement existé dans une période que le calendrier d’exportation a comprimée.

Cette compression est le cœur du Minimum Route Advertisement Interval, ou MRAI. Le RFC 4271 le définit comme la durée minimale entre des UPDATE successifs envoyés à un pair pour un ensemble commun de destinations. La valeur est associée au pair, tandis que la limitation porte sur la destination. Cela ne signifie pas qu’un changement de préfixe doive logiquement bloquer tous les autres derrière lui.

La norme ne réclame pas nécessairement un objet minuterie par préfixe. Une telle architecture pourrait consommer une quantité déraisonnable d’état. Une autre méthode d’ordonnancement convient si elle garantit à la fois l’espacement minimal et une borne supérieure constante au délai. L’interopérabilité porte sur le comportement temporel observable, non sur la forme du code interne.

Pendant l’attente, la décision BGP continue. La politique d’importation peut réévaluer chaque annonce, le meilleur chemin changer et le transfert local suivre. Ce qui attend est la prochaine déclaration vers ce voisin au sujet de cette destination. Lorsque plusieurs routes sont sélectionnées dans la fenêtre, le dernier résultat est annoncé à l’expiration. Le voisin reçoit donc une conclusion actuelle, sans forcément voir le cheminement qui l’a produite.

Le bénéfice est tangible. Un état intermédiaire qui disparaît vite ne déclenche ni message supplémentaire ni nouvelle décision chez chaque destinataire. Le RFC 4271 place d’ailleurs MRAI dans le contrôle de la charge du trafic de routage et nomme deux coûts : la bande passante des UPDATE et le calcul du processus de décision. Une préférence locale pour l’immédiateté devient sinon une dépense chez tous ceux qui reçoivent et propagent le changement.

L’histoire explique cette prudence. L’étude SIGCOMM de 1997 sur l’instabilité du routage observa, dans ses données de points d’échange, beaucoup plus d’annonces pathologiques que ce qu’une simple modification durable de topologie aurait justifié. Ses chiffres ne décrivent pas l’Internet de 2026, mais ils montrent qu’un flux BGP peut transporter un travail immense sans gain équivalent de connaissance stable.

L’étude SIGCOMM de 2000 sur la convergence expose le coût inverse. À partir de mesures passives et d’injections contrôlées de pannes, elle montra que défaillance, relève et réparation interdomaines pouvaient prendre plusieurs minutes. L’exploration de chemins et les décisions indépendantes produisaient pertes et délais transitoires. MRAI n’en était pas l’unique cause ; l’expérience prouve néanmoins qu’une minuterie qui économise des messages peut aussi prolonger l’âge de l’information distribuée.

Un petit intervalle n’est donc pas automatiquement vertueux. Il peut révéler plus tôt un remplacement valable, mais aussi exporter toutes les étapes d’une exploration de chemins. Des pairs synchronisés peuvent créer des pointes de charge, raison pour laquelle le RFC 4271 recommande de faire varier aléatoirement plusieurs minuteries, dont MRAI. Le débit moyen n’est pas la seule contrainte ; la simultanéité compte.

Un grand intervalle n’est pas automatiquement protecteur. Il peut fusionner des choix éphémères, mais retenir une réparation pendant que le pair perd encore des paquets. Le routeur émetteur peut déjà utiliser C tandis que le voisin agit sur A, sur un retrait ancien ou sur l’absence de solution. Une économie de contrôle sans budget explicite de fraîcheur transforme une protection locale en coût externe.

Il faut aussi éviter deux généralisations commodes. La première annonce n’attend pas universellement un intervalle complet : la règle concerne l’espacement par rapport à l’annonce précédente, l’état de l’ordonnanceur et le comportement de l’implémentation. Les retraits ne sont pas universellement instantanés, ni universellement différés. Sans trace de la plate-forme et de la version réellement exploitée, ces phrases dépassent la preuve.

Les relations internes et externes n’ont pas les mêmes besoins. Le RFC 4271 souligne la nécessité d’une convergence rapide à l’intérieur d’un système autonome et recommande un intervalle plus court pour iBGP, voire l’absence de cette procédure sur les routes internes. Ce n’est pas une injonction à mettre toutes les valeurs à zéro. C’est la reconnaissance qu’une organisation ne peut pas agir sur ses meilleurs chemins frais si son propre plan de distribution les cache inutilement.

Les valeurs suggérées par le RFC — 30 secondes pour eBGP et cinq pour iBGP — sont souvent récitées comme des propriétés universelles. Elles ne le sont pas. Le RFC 4273 expose une minuterie gérée par pair et reprend ces suggestions ; des produits appliquent d’autres valeurs selon le contexte. La documentation Cisco IOS citée, par exemple, décrit dans les familles concernées 30 secondes pour eBGP ordinaire, zéro pour iBGP et zéro pour eBGP dans une VRF. Une autre version peut décider autrement.

La hiérarchie de configuration complique encore la preuve. La valeur effective peut venir d’une famille d’adresses, d’un voisin, d’un peer group, d’un neighbor group ou d’un session group. Les règles de priorité peuvent rendre inopérante la ligne que l’ingénieur vient de lire. Un affichage d’état en cours d’exécution, tel que le temps minimal entre cycles d’annonce présenté par IOS XR, vaut davantage que l’intention apparente d’un modèle parent.

Même cet état ne suffit pas à expliquer l’impact. Il faut corréler pour un même NLRI les horodatages du meilleur chemin local, de l’Adj-RIB-Out, de la file MRAI, de l’UPDATE envoyé et de l’UPDATE reçu par le pair. Les événements FIB et les mesures de joignabilité indiquent ensuite si l’état intermédiaire retenu aurait évité une perte. Sans cette ligne de temps, une baisse du nombre de messages peut être célébrée alors que la récupération s’est dégradée.

MRAI n’est pas Route Flap Damping. Le damping attribue à l’instabilité passée une pénalité qui décroît et peut supprimer une route. MRAI ne porte aucun jugement historique sur la route ; il espace des déclarations vers un pair. Un chemin peut rester sélectionné localement pendant l’attente sans être annoncé. Il n’est pas pour autant « damped ».

Ce n’est pas non plus un mécanisme de vie de session. HoldTimer et Keepalive déterminent si la session BGP survit. BFD peut détecter rapidement une défaillance de transfert. Cette détection accélère la prochaine sélection locale, mais ne prouve pas que l’annonce résultante contournera le calendrier d’exportation. Le RFC 7938 demande précisément aux architectures de centres de données d’inclure MRAI dans leur calcul de propagation des événements.

ADD-PATH modifie ce qui peut être annoncé, pas l’autorisation temporelle de chaque annonce. Plusieurs chemins d’un même NLRI peuvent coexister sous des identifiants distincts, rendant visibles des options que l’annonce du seul meilleur chemin cachait. Cela ne rend pas tous les états locaux intermédiaires utiles et ne supprime pas l’ordonnancement sortant. Visibilité et cadence demeurent deux surfaces différentes.

La relation BGP comporte ainsi une délégation temporelle asymétrique. L’émetteur choisit la fréquence à laquelle il révèle ses changements ; le récepteur supporte l’âge de la connaissance qui en résulte. Il ne peut pas forcer un UPDATE au milieu de l’intervalle. Il peut en revanche mesurer les espacements, convenir d’objectifs de service, diversifier ses amonts et décider quelle obsolescence il accepte.

Le principe de spécification initiale minimale de Heng Lu éclaire cette frontière. Le protocole commun doit définir assez de comportement pour préserver l’interopérabilité et borner la charge. Il n’a pas à imposer une valeur unique à des processeurs, topologies, types de pairs et conséquences clients différents. Le choix reste local parce que les coûts le sont, à condition que ses effets soient visibles par ceux qui les subissent.

La primauté du code en fonctionnement fournit alors le test d’autorité. La configuration est une intention. L’héritage effectif, l’ordonnanceur, les UPDATE observés, la réception distante et la livraison de paquets constituent le système. Si cette preuve montre qu’une minuterie dite protectrice prolonge une panne client, la réussite du commit ne justifie pas le choix.

Trois décisions locales devenues un seul message ne constituent ni une tromperie ni une purification de la vérité. C’est une décision d’ordonnancement. La dernière route est la meilleure réponse locale au moment autorisé, pas une promesse qu’elle restera stable. Diriger consiste à nommer l’échange : moins de travail de contrôle contre une connaissance distribuée plus ancienne.

Sources