Résumé

  • RFC 5283 permet à une FEC LDP précise de s’appuyer sur une route IP couvrante lorsque le voisin qui annonce le label est bien le prochain saut. Le label réannoncé reste précis, alors que la preuve de routage est agrégée.
  • Cette relation locale ne démontre ni la prise en charge sur tout le trajet, ni la vie du LER de sortie, ni la convergence du retrait, ni la programmation matérielle, ni le service client. Chaque limite réclame son propre reçu.

L’agrégation retire une route, pas l’identité du label

Le traitement LDP classique préfère une correspondance exacte entre la FEC de préfixe et la RIB. Dans un réseau multi-zone, cette exigence pousse à redistribuer chaque loopback de PE partout. Le LSP fonctionne, mais la hiérarchie IGP ne contient plus autant d’état qu’elle devait en économiser.

RFC 5283 conserve la FEC et assouplit la recherche. Une /32 peut trouver son prochain saut grâce à une /24 qui la contient, à condition que l’annonceur du label soit un prochain saut valide. Une FEC plus large que l’entrée RIB ne bénéficie pas de la règle.

Le routeur ne réannonce pas la /24 comme FEC. Il réannonce la /32 reçue. La granularité du label reste donc celle de la sortie ; seule la justification IP a changé d’échelle. Toute lecture opérationnelle doit garder ces deux objets séparés.

Un agrégat décrit une direction, pas tous ses habitants

Une route couvrante dit où envoyer l’ensemble. Elle ne dresse pas la liste des sorties encore vivantes derrière la frontière. Le préfixe agrégé peut rester parfaitement valide quand un LER précis tombe.

Le contrôle longest match vérifie un état local : entrée RIB couvrante, prochain saut sélectionné, voisin LDP annonceur. Il ne sonde pas le LER final, n’interroge pas chaque zone et n’observe aucun paquet client.

Le danger vient de l’apparence. Une FEC /32 semble plus affirmative qu’une /24, mais sa décision locale repose justement sur cette /24. Le nom précis du label ne doit pas agrandir la portée de la preuve qui le soutient.

La compatibilité ne crée pas la continuité

L’extension est optionnelle, configurable et normalement désactivée par défaut. Un ancien LSR reste compatible au sens où il ne produit pas d’effet secondaire nouveau. Mais il ne prolonge pas un LSP dont la FEC n’a plus d’entrée exacte.

Dans chaque zone où l’IGP agrège, tous les LSR du chemin pertinent doivent appliquer la procédure. Sinon, le LSP parti de la sortie s’arrête au premier nœud non conforme. Une chaîne sûre peut donc rester incomplète.

La capacité se mesure par zone, nœud et préfixe. Voir le label à un endroit ne prouve pas que chaque frontière a accepté la même règle. Le point d’arrêt est une donnée de migration, pas un motif pour annoncer un LSP de bout en bout.

La migration exige une période de double preuve

Le document autorise une mise en service progressive. Il impose toutefois une discipline : tant que tous les LSR d’une zone n’ont pas été mis à niveau avec succès, l’ABR doit continuer d’annoncer les routes spécifiques dont dépendent les LSP existants.

Ce n’est qu’après validation complète que les spécifiques peuvent disparaître et que l’agrégat peut rester seul. Avant ce seuil, correspondance exacte et longest match coexistent. Après, un équipement non conforme n’a plus de preuve RIB utilisable.

Le reçu de bascule doit inclure l’inventaire réel, l’activation par préfixe, la dernière annonce spécifique, la génération RIB, la présence des FEC avant et après, l’installation LFIB et un test de paquets. Une liste de changements terminés n’est pas une observation simultanée du système.

Une seule route pilote plusieurs FEC

L’agrégation réduit le nombre d’entrées IP, mais concentre les dépendances. Une route couvrante peut justifier des dizaines de FEC précises. Lorsqu’elle apparaît, disparaît ou change de prochain saut, chaque FEC incluse doit être réexaminée.

Une nouvelle route plus spécifique peut devenir le meilleur match pour une partie seulement des FEC. Leur NHLFE change alors que leur nom et leur label amont peuvent sembler stables. Un tableau de bord qui ne compte que créations et suppressions manque cette migration interne.

Il faut relier génération RIB, préfixe couvrant, prochain saut, ensemble des FEC dépendantes, label reçu, label local, NHLFE et accusé de programmation. Sans cette chaîne, la liste des FEC paraît correcte tandis que le chemin réel a changé.

Le gain de FIB ne s’étend pas automatiquement à la LFIB

RFC 5283 réduit la LSDB et les entrées IP dans la FIB. Il précise qu’il ne réduit pas les entrées LFIB : les LSP vers les sorties restent individuels. Résumer cette opération par « moins d’état » est donc trop vague.

Le contrôle de capacité doit nommer la table. Le calcul SPF, la programmation FIB, la programmation LFIB et la mémoire de labels n’ont pas le même facteur d’échelle. Une amélioration de la hiérarchie IP peut laisser intact le coût des labels et le nombre de dépendances lors d’une panne.

Cette précision vaut aussi pour les SLA. Réduire un temps de calcul ou un volume de routes n’atteste ni le temps de retrait LDP, ni la mise à jour matérielle, ni la durée de perte ressentie par l’application.

La panne du LER de sortie suit une autre horloge

Pour les pannes de lien, de routeur de transit ou d’ABR, le document ne change pas la convergence habituelle. La disparition du LER de sortie est le cas particulier : l’agrégat IGP peut rester présent parce que les autres membres existent encore.

La vérité précise revient alors par le contrôle ordonné de LDP. Le retrait de la FEC se propage saut par saut. Le document estime son délai comparable à celui de l’IGP, tout en signalant qu’il dépend de l’implémentation. L’usage de ce signal par MP-BGP, L3VPN ou une autre application reste hors périmètre.

Il existe donc un intervalle légitime où la route agrégée est verte et où un label amont n’a pas encore été retiré, alors que la sortie nommée a disparu. Ce sont deux horloges et deux autorités. La télémétrie doit montrer le retrait en cours, non transformer l’agrégat en verdict.

Une annonce spécifique réservée au contrôle, le retrait LDP ordonné ou, à l’accès, BFD peuvent apporter des signaux complémentaires. Aucun ne doit être remplacé par la seule présence de la route couvrante.

Le label installé ne ferme pas le service

Même après continuité du contrôle, il faut encore prouver la programmation LFIB, l’utilisation du bon NHLFE, le passage des paquets, le contexte VPN, la sortie attendue, le retour et l’application. Un LSP de contrôle n’est pas un reçu client.

Un test synthétique n’est probant que si sa classe, son contexte de service et son trajet correspondent à la promesse. Un ping vers une loopback d’infrastructure peut réussir sans démontrer le VPN ni le flux critique.

Le registre doit accepter des conclusions partielles : agrégat présent, FEC locale présente, capacité distante inconnue, retrait en transit, LFIB non confirmée, sonde sans retour. Ces états indiquent des responsables différents et évitent qu’une icône de label masque la panne réelle.

Composer le reçu aux deux granularités

Conserver au minimum :

  • FEC précise, famille d’adresses et LER de sortie ;
  • toutes les routes couvrantes considérées et le meilleur match retenu ;
  • génération RIB, métrique, prochain saut et voisin annonceur ;
  • capacité RFC 5283 et activation par préfixe de chaque nœud ;
  • labels reçus, locaux et réannoncés avec leurs horodatages ;
  • ensemble de FEC dépendant de chaque agrégat ;
  • NHLFE, LFIB et accusé matériel ;
  • zones et ABR traversés ;
  • état de migration entre routes spécifiques et agrégat ;
  • origine et progression du retrait ordonné ;
  • réaction MP-BGP, L3VPN ou applicative ;
  • observations de paquets aller-retour ; et
  • résultat du service effectivement annoncé.

Ce reçu distingue l’arrêt de la propagation, le délai de retrait et la panne de données. Il permet de profiter de l’agrégation sans lui confier une autorité qu’elle n’a jamais reçue.

Sources