Résumé

  • La fermeture progressive de la RFC 8326 déprécie un chemin avant de couper la session ; le redémarrage progressif de la RFC 4724 conserve temporairement le transfert et des routes marquées obsolètes.
  • Le dossier de changement doit préciser lequel des deux mécanismes s’applique, l’état réel du plan de données et les preuves exigées avant de poursuivre.

Deux opérations que le vocabulaire rapproche à tort

La RFC 8326 part d’un cas concret : la maintenance affectera le plan de transfert. Couper immédiatement une session EBGP peut créer une période sans route ou une convergence désordonnée. Le mécanisme GRACEFUL_SHUTDOWN maintient donc le chemin assez longtemps pour que d’autres routes deviennent préférées.

L’initiateur marque les annonces destinées au voisin, abaisse aussi la préférence des routes reçues sur la session concernée, attend la nouvelle propagation et la convergence, puis ferme la session. Le récepteur doit avoir préparé une politique qui reconnaît la communauté et attribue une faible LOCAL_PREF, la valeur recommandée étant zéro. L’objectif est de vider le chemin, pas de le maintenir comme chemin principal.

La RFC 4724 répond à une autre question. Elle permet de conserver le transfert pendant que BGP redémarre, à condition que le routeur puisse réellement préserver cet état. Les voisins gardent provisoirement des routes marquées comme obsolètes, la session revient, les mises à jour remplacent ces routes et un marqueur End-of-RIB clôt la reconstruction. Des délais bornent cette confiance.

Ainsi, une fermeture progressive demande au réseau de partir ; un redémarrage progressif lui demande de rester. Les confondre revient à supprimer la décision essentielle du changement.

Une communauté ne constitue pas une preuve

La valeur 65535:0 transporte l’intention de fermeture progressive. La RFC 1997 décrit les communautés comme un attribut BGP optionnel et transitif, dont l’application reste soumise à la politique locale. L’opérateur peut donc émettre le signal, mais il ne commande ni la politique du voisin ni la capacité de son chemin de rechange.

La LOCAL_PREF illustre ce partage d’autorité. Selon la RFC 4271, elle est calculée et diffusée à l’intérieur d’un système autonome ; la valeur la plus élevée est préférée. Elle n’est normalement pas transmise à un pair externe. Chaque réseau doit traduire la communauté reçue en décision interne. La réussite de l’évacuation dépend de deux configurations distinctes et d’un résultat observable.

Le signal ne prouve pas davantage que le lien sera effectivement indisponible. Il ne garantit ni l’existence d’un itinéraire alternatif, ni sa capacité, ni son installation dans le FIB. Ces éléments doivent être mesurés avant la coupure.

La conservation des routes exige une vérité sur le transfert

Le redémarrage progressif établit, lui aussi, une relation de confiance entre pairs. Le routeur redémarrant indique sa capacité, le voisin conserve certaines routes, puis les supprime lorsque les conditions ne sont plus satisfaites. Si la session n’est pas rétablie dans le délai annoncé, les routes obsolètes doivent disparaître. Si l’état de transfert n’est pas confirmé après reconnexion, elles ne doivent pas survivre par inertie.

La RFC 4724 avertit que des boucles ou des trous noirs transitoires restent possibles lorsque le plan de données n’a pas été préservé ou que la topologie évolue avant la fin de la convergence. Un contrôle de session ne suffit donc pas. L’exploitant doit surveiller le plan de données, les familles d’adresses négociées, les minuteries et la réception d’End-of-RIB.

Rédiger un changement vérifiable

Une fiche exploitable contient au minimum : le mode choisi ; l’hypothèse sur la survie du transfert ; la politique attendue du pair ; l’itinéraire alternatif et sa capacité ; les événements de convergence ; les délais ; le seuil d’abandon ; et le responsable du retour arrière.

Cette précision répartit correctement les coûts. L’initiateur finance l’automatisation et l’observation. Le pair entretient les politiques qui interprètent le signal. Les deux consacrent quelques minutes à la preuve de convergence. Sans ce travail, le coût est transféré aux clients sous forme de pertes de paquets dont l’origine demeure difficile à expliquer.

Sources et limite de la preuve

Le dossier s’appuie sur les RFC 8326, RFC 4724, RFC 1997 et RFC 4271. Elles décrivent les mécanismes et leurs exigences ; elles ne démontrent pas le taux de déploiement, l’uniformité des constructeurs ni la conformité d’un réseau nommé.