Résumé
- RFC 5302 autorise la distribution sélective de routes de Level 2 vers une zone Level 1, à condition de marquer leur provenance descendante et d’empêcher toute réannonce vers Level 2.
- Un ancien routeur uniquement Level 1 peut ignorer le bit sans créer, à lui seul, le chemin de retour ; la même ignorance sur un routeur Level 1/Level 2 rend la frontière dangereuse.
Une réussite locale peut masquer une faute de frontière
Dans une validation classique, l’équipe regarde le destinataire. La route apparaît-elle ? A-t-elle la bonne métrique ? Le trafic suit-il un chemin utile ? Ces réponses mesurent l’effet recherché de la fuite descendante. Elles ne montrent pas ce que feront les autres frontières de la zone lorsqu’elles liront la même annonce.
RFC 1195 organisait IS-IS sur deux niveaux. Les zones Level 1 rejoignent une topologie Level 2 par des routeurs attachés aux deux niveaux ; pour l’extérieur de sa zone, un routeur Level 1 utilise normalement la frontière attachée la plus proche. Les informations pouvaient monter de Level 1 vers Level 2, mais le mouvement inverse n’était pas défini. RFC 5302 introduit ce mouvement afin d’offrir des chemins plus précis que la route par défaut.
La précision ouvre toutefois une boucle informationnelle. Un préfixe appris en Level 2 descend dans un LSP Level 1. S’il est ensuite pris pour une origine interne ordinaire, une autre frontière peut le réannoncer en Level 2. Le problème n’est donc pas de savoir si le préfixe est joignable, mais si sa provenance résiste à chaque passage d’autorité.
Le bit n’est qu’une mémoire de direction
Les TLV 128 et 130 de RFC 1195 portent respectivement les informations d’accessibilité IP internes et externes. Le bit de poids fort du champ Default Metric était réservé : l’émetteur le mettait à zéro et le récepteur l’ignorait. RFC 5302 réemploie cette position comme bit up/down.
Lorsqu’un routeur Level 1/Level 2 dérive un préfixe du calcul Level 2 et le publie dans un LSP Level 1, il met le bit à un. Dans le modèle à deux niveaux, les autres préfixes le gardent à zéro. Une frontière qui apprend par Level 1 une route portant le bit ne doit pas la réannoncer dans Level 2.
Ce mécanisme encode une règle de circulation, pas un résultat opérationnel complet. Il ne dit pas si la route a été préférée, placée dans la RIB globale, programmée dans la FIB ni si un paquet a été livré. Même l’authentification du LSP n’atteste pas la justesse de la politique. Un routeur légitime et correctement authentifié peut exécuter un logiciel trop ancien pour comprendre le sens nouveau du bit.
L’ancienneté du logiciel n’a pas le même prix partout
Le choix d’un ancien bit réservé permet une compatibilité utile. Un routeur conforme à RFC 1195 était censé ignorer cette position. Un appareil uniquement Level 1 peut donc recevoir une route marquée comme descendante et la traiter comme une route intra-zone. RFC 5302 précise que ce comportement ne produit pas, par lui-même, une boucle parmi les seuls routeurs Level 1.
Sur une frontière Level 1/Level 2, la même tolérance efface la barrière. Ne reconnaissant pas la marque, le routeur peut croire à une origine Level 1 et publier le préfixe vers Level 2. La norme cite alors trois familles de conséquences : boucles de routage, chemins sous-optimaux et instabilité supplémentaire.
Il serait excessif d’en conclure que tout le parc doit être mis à jour. Il serait insuffisant de mettre à jour uniquement la frontière qui injecte la route. L’exigence porte sur tous les routeurs Level 1/Level 2 de chaque zone où la distribution descendante est activée. Une frontière de secours silencieuse, un chemin de maintenance ou un équipement qui n’annonce habituellement rien reste dans le périmètre dès lors qu’il peut devenir le chemin de retour.
La nature de la route ne tient pas dans le numéro du TLV
Le TLV et le type de métrique forment deux dimensions distinctes. TLV 128 désigne l’accessibilité IP interne, TLV 130 l’accessibilité externe. Une métrique interne peut être comparée aux coûts des liens du domaine ; une métrique externe ne le peut pas. Cette dernière n’est valide que pour un préfixe externe, et la combinaison TLV 128 plus métrique externe doit être ignorée.
Dans la préférence SPF IS-IS, un préfixe interne et un préfixe externe doté d’une métrique interne ont la même priorité. Un préfixe externe à métrique externe passe après la même destination annoncée avec une métrique interne, quelle que soit la valeur numérique. Les routes Level 1 ordinaires précèdent Level 2, puis les routes interzones descendues de Level 2 vers Level 1 ; les classes à métrique externe viennent ensuite.
L’erratum vérifié 3994 corrige un détail qui change la provenance du calcul : la route externe interzone à métrique externe est dérivée pendant le SPF Level 2, non pendant le SPF Level 1. Garder seulement un champ « installée » supprimerait justement cette distinction. Le reçu doit conserver niveau d’origine, LSP source, TLV, nature interne ou externe, type et valeur de métrique, bit, calcul SPF, décision RIB et état FIB.
Une activation manuelle doit produire une autorisation vérifiable
RFC 5302 recommande de ne pas distribuer les routes Level 2 vers Level 1 par défaut et de forcer une configuration manuelle. Cette friction crée un point de gouvernance. L’autorisation peut nommer les zones, les préfixes, la génération de politique, les frontières concernées, les filtres, les résumés, la fenêtre d’observation et la condition de retour arrière.
La configuration d’une frontière ne vaut pas preuve pour les autres. Avant l’activation, l’inventaire doit couvrir toutes les frontières de la zone et établir leur capacité à comprendre le bit. Pendant l’opération, plusieurs points d’observation doivent voir la marque descendre. Après, chacun des autres passages possibles doit prouver l’absence de réannonce interdite en Level 2. Ici, l’absence n’est pas un manque de données : elle est le résultat attendu.
La discipline vaut aussi dans le sens montant normal. Une frontière ne devrait publier en Level 2 que les routes Level 1 qu’elle utilise effectivement pour transférer les paquets, et non recopier sans discernement toute sa base Level 1. Filtrage et agrégation restent des décisions explicites.
Ne pas transformer une règle locale en interdit universel
Dans le modèle à deux niveaux de RFC 5302, le bit up/down n’a pas de fonction opérationnelle dans un LSP Level 2. La recommandation est de l’ignorer à ce niveau et d’accepter le préfixe. RFC 7775 précise ensuite qu’il n’existe pas de type de route interzone Level 2 dans ce modèle et corrige une formulation de préférence IPv6 issue de RFC 5308.
La règle « ne pas remonter » s’applique donc à une route marquée apprise en Level 1 par une frontière, pas à toute annonce Level 2 portant accidentellement le bit. Une alerte qui omet le niveau du LSP et le rôle du récepteur produit une politique plus large que le protocole.
Le reçu utile traverse toutes les frontières
Pour chaque préfixe, un reçu non secret peut relier famille d’adresses, niveau initial, système et LSP sources, TLV, nature de route, type et valeur de métrique, état du bit à l’entrée, politique descendante et génération approuvées, version et capacité de chaque frontière, annonce Level 1, observations depuis les autres frontières, absence explicite de retour Level 2, source du SPF, sélection RIB, installation FIB, résultat de transfert et décision de repli.
Il faut préserver les verbes. Reçu, accepté, sélectionné, installé, annoncé, supprimé, transféré et livré ne sont pas synonymes. Le tableau de bord le plus trompeur est celui où toutes les installations sont vertes alors qu’une frontière non observée a déjà rendu le préfixe au cœur.
Sources
- https://www.rfc-editor.org/rfc/rfc5302.html
- https://www.rfc-editor.org/rfc/rfc5302.txt
- https://www.rfc-editor.org/info/rfc5302/
- https://datatracker.ietf.org/doc/rfc5302/
- https://datatracker.ietf.org/doc/rfc5302/history/
- https://datatracker.ietf.org/doc/rfc5302/references/
- https://datatracker.ietf.org/doc/rfc5302/referencedby/
- https://www.rfc-editor.org/errata/rfc5302
- https://www.rfc-editor.org/rfc/rfc1195.html
- https://www.rfc-editor.org/rfc/rfc2966.html
- https://www.rfc-editor.org/rfc/rfc5305.html
- https://www.rfc-editor.org/rfc/rfc5308.html
- https://www.rfc-editor.org/rfc/rfc7775.html
- https://www.rfc-editor.org/rfc/rfc5120.html
- https://www.rfc-editor.org/rfc/rfc3784.html
- https://www.rfc-editor.org/rfc/rfc5304.html
- https://www.rfc-editor.org/rfc/rfc5310.html
- https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
