Résumé

  • Route Refresh demande à un voisin de réannoncer les routes d’un AFI/SAFI sans réinitialiser la session ; la version étendue balise le début et la fin du rejeu.
  • Ces marqueurs ne certifient ni la version de configuration, ni le sens de la politique, ni la décision Loc-RIB, ni l’état de transfert.
  • La clôture exige un reçu reliant le commit, l’échange, une route témoin, le FIB, le trafic, les exceptions et le retour arrière.

Une fin d’échange, pas une fin de preuve

Prenons un changement contrôlé de politique d’import. Une route jusque-là acceptée doit désormais être rejetée depuis un fournisseur précis. Le système de configuration annonce un commit réussi. Le routeur demande un rafraîchissement ; Beginning-of-RIB apparaît, les annonces reviennent, puis End-of-RIB clôt la séquence. Le ticket semble terminé.

Une vérification sur un edge de production retrouve pourtant la route témoin. Le protocole n’a pas menti. L’équipe a seulement demandé au marqueur de prouver autre chose que ce qu’il décrit : l’échange s’est achevé, mais le résultat opérationnel n’a pas encore été établi.

RFC 2918 définit Route Refresh pour éviter la coupure d’une session BGP lors d’une nouvelle application des politiques. La capacité est négociée à l’ouverture de session. Le message ultérieur désigne un AFI et un SAFI ; le voisin réannonce alors les routes correspondantes de son état de sortie.

Le message ne contient ni empreinte de politique locale, ni numéro de transaction, ni règle attendue pour un préfixe. Il déclenche une action de protocole. Il ne constitue pas le reçu de la modification.

Ce que bornent BoRR et EoRR

RFC 7313 ajoute Enhanced Route Refresh. Beginning-of-RIB et End-of-RIB encadrent le jeu réannoncé et permettent au récepteur de traiter l’état devenu périmé. Leur précision est précieuse : ce voisin a commencé puis terminé le rafraîchissement de cette famille.

La portée s’arrête là. Les marqueurs n’attestent pas que la nouvelle configuration était active avant le premier UPDATE, qu’elle a été livrée à toute la flotte ou qu’elle agit dans le sens prévu. Ils ne prouvent pas davantage qu’une route choisie par BGP a été installée dans le FIB ni qu’un paquet a été livré.

Un rafraîchissement IPv4 unicast ne valide pas IPv6, un VPN ou un autre SAFI. Une session ne représente ni un second voisin ni un réflecteur ni tous les edges. Une seule observation EoRR ne peut donc pas devenir un indicateur global.

Importer et exporter sont deux décisions

RFC 4271 distingue les routes reçues, les routes sélectionnées dans le Loc-RIB et celles préparées pour être annoncées. Après une modification d’import, le récepteur a besoin d’un nouveau flux d’annonces pour réappliquer ses règles. Après une modification d’export, il faut démontrer que le locuteur a utilisé la bonne politique vers le voisin nommé.

Ces preuves n’ont ni le même propriétaire ni le même point d’observation. Le rejeu de l’état sortant du pair permet au routeur local de refaire son traitement entrant ; il ne certifie pas silencieusement les intentions de configuration des deux côtés.

RFC 5291 ajoute encore l’état des filtres de routes sortantes. Capacité, type de filtre, mode et installation doivent être identifiés. Un rafraîchissement ultérieur ne prouve pas à lui seul qu’un filtre ORF précis était présent et actuel.

La route témoin relie les couches

Chaque affirmation doit être testée à son étage. Un rejet d’import se vérifie dans les routes reçues et le résultat de politique. Le choix d’une alternative se vérifie dans le Loc-RIB. Un déplacement de trafic exige le FIB, la résolution du prochain saut et un chemin de paquets représentatif.

Ces vues peuvent diverger sans incohérence. Le préfixe rejeté d’un pair peut encore arriver d’un autre. Une meilleure route peut gagner dans BGP et échouer à résoudre son prochain saut. Une entrée FIB peut exister tandis qu’un tunnel ou un filtrage aval casse le service.

Utiliser une route témoin rend le changement vérifiable. Il faut consigner son état avant le commit, pendant la fenêtre BoRR–EoRR et après la clôture : préfixe, pair, chemin, attributs utiles, motif de décision et prochain saut. Une mesure de trafic adaptée à la famille et au service complète l’observation.

Interpréter Route Refresh avec cette limite protège sa valeur. L’échange terminé devient un jalon fiable au lieu d’un verdict trop large. En cas d’écart, l’équipe peut isoler une mauvaise version, une diffusion partielle, une famille erronée, une capacité absente, un état ORF différent ou un problème de transfert après une décision BGP correcte.