Résumé

  • RFC 2918 autorise un locuteur à demander la réannonce de l’Adj-RIB-Out actuel d’un voisin capable, pour un AFI/SAFI négocié ; le voisin conserve sa politique d’export.
  • RFC 7313 encadre un rejeu complet par BoRR et EoRR : les anciennes routes deviennent stale, les routes revenues les remplacent, les absentes sont supprimées à la fin.
  • Une commande réussie ou une session stable ne prouve pas l’effet. Il faut comparer les préfixes, attributs, décisions, FIB et trafic avant et après.

Un opérateur corrige un filtre entrant. Deux cents préfixes rejetés par erreur devraient désormais être acceptés. Le commit est valide, le routeur ne signale aucune faute. Pourtant, si ces annonces n’ont pas été conservées sous leur forme brute, la nouvelle règle ne possède aucune donnée à examiner.

L’erreur inverse est possible. Une règle plus restrictive doit retirer des routes déjà admises. Changer le texte ne démontre pas que l’état existant a été repassé dans la chaîne. La politique du dépôt peut être correcte tandis que la RIB continue d’exprimer l’ancienne décision.

La soft reconfiguration entrante résolvait ce problème en conservant une copie non modifiée de toutes les annonces reçues, y compris celles que la politique rejetait. La réévaluation restait alors locale. Cette indépendance consommait en permanence mémoire et calcul pour une opération rare.

RFC 2918 répartit autrement le coût. Un locuteur annonce la Route Refresh Capability, code 2, pour dire qu’il sait recevoir et traiter une demande. L’autre côté ne peut envoyer ROUTE-REFRESH qu’après avoir reçu cette capacité. La demande porte sur un couple AFI/SAFI déjà négocié.

Le voisin répond en réannonçant son Adj-RIB-Out pour cette famille, selon sa politique de filtrage sortante. C’est la frontière d’autorité essentielle. Le demandeur ne lit pas la base distante et ne force pas l’exposition d’une route filtrée. Il demande au voisin de dire de nouveau ce que celui-ci annonce aujourd’hui.

Le rejeu n’est donc pas une archive. Une route exportée la veille peut avoir été retirée, remplacée ou rendue inéligible par une nouvelle politique distante. Une route absente hier peut apparaître. Le résultat combine deux présents : export actuel du voisin et import actuel du demandeur.

Cette nuance interdit d’expliquer une variation par le seul changement local. Si 500 routes disparaissent après un refresh, elles peuvent avoir été bloquées par la nouvelle règle, retirées par le voisin ou modifiées avant le rejeu. Un simple compteur ne sépare pas ces causes.

RFC 2918 ne délimitait pas clairement le début et la fin d’une réannonce complète. Des UPDATE ordinaires peuvent arriver pendant l’opération. Tant que personne ne sait que le tour est terminé, l’absence d’une route ne signifie pas encore qu’elle ne reviendra pas.

RFC 7313 ajoute Enhanced Route Refresh, capacité 70. Le sous-type 1 marque Beginning-of-RIB-Refresh, BoRR ; le sous-type 2 marque End-of-RIB-Refresh, EoRR. Le sous-type 0 reste la demande normale.

À la réception de BoRR, le locuteur marque stale toutes les routes du voisin dans l’AFI/SAFI concerné. Chaque route réannoncée remplace son ancienne entrée. EoRR autorise la suppression immédiate de celles qui restent stale. Une absence ambiguë devient une non-réapparition dans une époque bornée.

Le monde ne s’arrête pas pendant ce rejeu. Les routes qui changent durant l’opération peuvent être annoncées selon leur nouvel état. Il faut traiter une séquence vivante, pas un fichier figé. EoRR indique la fin du cycle, pas la vérité de chaque route.

Le récepteur peut imposer une durée maximale locale de conservation du stale. Cette limite empêche une opération inachevée de préserver indéfiniment une ancienne joignabilité. Trop courte, elle peut toutefois supprimer des routes saines avant la fin d’un rejeu lent.

EoRR ne doit pas être confondu avec l’End-of-RIB du Graceful Restart. Le premier ferme une époque de réannonce ; le second participe à la continuité pendant un redémarrage du plan de contrôle. RFC 7313 ordonne leur interaction pour éviter une purge prématurée.

Les opérations soft entrantes et sortantes n’ont pas le même propriétaire. En entrée, le routeur local demande le rejeu distant ou exploite une copie brute locale. En sortie, il régénère ses propres annonces. Une même commande d’exploitation peut masquer cette différence de source et de dépendance.

La documentation Cisco montre les trois voies. Avec capacité négociée, un soft reset entrant envoie une demande. Sans capacité, une copie conservée peut être réexaminée. Sans l’une ni l’autre, il faut parfois réinitialiser la session entière, supprimant toutes ses routes pendant la reconstruction.

Le choix est économique autant que technique. Conserver les entrées brutes achète de l’indépendance locale au prix de ressources. Route Refresh économise cette mémoire mais dépend de la capacité, de la disponibilité et de l’export actuel du voisin. Le hard reset élargit le dommage à toute la relation.

FRRouting rappelle que certaines fonctions ont encore besoin des routes rejetées, par exemple des modes de maximum-prefix qui comptent l’ensemble reçu. La possibilité de redemander un flux actuel ne remplace pas forcément la conservation nécessaire à un autre contrôle.

RFC 5291 ajoute Outbound Route Filtering. Un récepteur peut communiquer certains filtres au voisin, et un refresh normal peut fonctionner avec ou sans ORF. Il s’agit d’une capacité séparée ; une demande ordinaire ne devient pas pour autant un éditeur de politique distante.

La preuve commence avant le changement. Relevez, pour chaque sens et famille, les capacités annoncées et reçues. La présence de Route Refresh basique ne démontre pas Enhanced Route Refresh. Le support local n’établit pas la capacité du voisin.

Conservez ensuite un état initial : ensemble exact des préfixes et attributs visibles, routes acceptées, meilleurs chemins, version de politique, uptime de session et next hops FIB. Si les routes rejetées ne sont pas observables, déclarez cette lacune.

Après le changement, limitez d’abord le refresh à un peer et un AFI/SAFI. Horodatez la demande, BoRR, EoRR et la durée. Surveillez EoRR absent, expiration stale, saturation du plan de contrôle, reset inattendu, retraits et basculements de meilleur chemin.

Comparez des ensembles, pas leurs seules tailles. Dix suppressions et dix ajouts produisent le même total. Un agrégat remplacé par des more-specifics change fortement le nombre. Une modification d’attribut peut changer le chemin sans changer le NLRI.

La FIB termine la démonstration. Une route acceptée peut perdre la sélection, avoir un next hop non résolu ou conduire vers une capacité insuffisante. Route Refresh rend des entrées disponibles ; il ne garantit pas le trajet des paquets.

Le rollback exige lui aussi un rejeu. Restaurer l’ancienne policy sans réévaluer laisse l’état nouveau en place. Et si l’export du voisin a changé entre-temps, le système ne peut promettre de retrouver exactement la photographie initiale.

L’automatisation doit enfin limiter le travail demandé au voisin et au routeur local. Des milliers de refresh simultanés peuvent produire un torrent d’UPDATE et de recalculs. « Soft » signifie sans destruction volontaire de session, pas sans coût.

La spécification minimale de Heng Lu apparaît dans l’objet étroit : un peer, une famille, une demande. Chaque AS garde sa policy et sa décision. La primauté du code exécuté fixe le verdict : capacités négociées, époque observée, différences de RIB et état de forwarding l’emportent sur le succès affiché par la commande.

Route Refresh sépare utilement la correction d’une policy de la destruction d’une session. Il ne sépare jamais la correction de sa preuve. Le voisin parle de nouveau ; seules les routes effectivement revenues et leur effet montrent que la règle nouvelle gouverne enfin le réseau.

Sources