Résumé

  • Chaque adjacence multi-zone de RFC 5185 possède son propre contexte et sa propre machine d’état point à point, mais toutes peuvent s’appuyer sur la même interface et le même circuit.
  • Mettre une adjacence en retrait ne protège pas un service si les autres projections restent sur la ressource en maintenance. Le dossier de changement doit rattacher chaque vue OSPF au port, à la carte, à la fibre et au groupe de risque communs.

Le plan de maintenance avait retiré l’adjacence de la zone 1. Le tableau de bord montrait encore deux chemins FULL entre les routeurs de bordure, et l’opérateur valida la redondance. Lorsque le technicien coupa le circuit, les deux chemins restants disparurent avec le premier.

Le drainage avait modifié une vue de routage, pas la dépendance physique. Les trois adjacences utilisaient le même port, la même carte et la même commande opérateur. Le plan avait confondu la survivance d’objets OSPF avec celle du service.

Pourquoi créer plusieurs vues d’une liaison

Publié en mai 2008 sur la voie normative, RFC 5185 part d’un cas où deux ABR disposent d’une liaison rapide dans le backbone. Une autre zone relie les mêmes routeurs par des chemins internes plus lents. OSPF préférant un chemin intra-zone à un chemin inter-zone, le trafic de cette zone peut ignorer la liaison rapide.

L’extension établit sur l’interface commune une adjacence supplémentaire rattachée à cette zone. Elle fournit alors un chemin intra-zone sans retirer la liaison de la zone 0. Le gain est réel : le calcul SPF voit une topologie mieux adaptée à l’intention locale.

Mais aucune nouvelle fibre n’apparaît. Le lien virtuel ne résout pas le cas sans déplacer l’appartenance du lien ; les adresses secondaires consomment des adresses, ne couvrent pas les interfaces non numérotées et peuvent gonfler la table. Déclarer le même sous-réseau dans plusieurs zones contredirait le modèle des zones. La solution ajoute donc du contexte d’adjacence, pas de l’infrastructure.

FULL décrit une relation de protocole

Chaque adjacence ajoutée reçoit une structure d’interface OSPF toujours typée point à point, quel que soit le type du média sous-jacent. La machine d’état de l’interface suit ce modèle ; la structure de voisin et sa machine d’état restent celles d’OSPF. L’adjacence principale continue parallèlement selon RFC 2328.

Lorsqu’une adjacence multi-zone atteint FULL, le routeur l’inscrit dans la Router-LSA de la zone comme lien de type 1. Le Link ID est le Router ID distant. Le Link Data est l’adresse du voisin, ou l’IfIndex sur un lien non numéroté. Contrairement à un lien point à point numéroté ordinaire, aucun lien de type 3 n’est annoncé pour cette adjacence.

FULL prouve donc l’achèvement de l’échange d’état de liens pour cette relation. Il ne prouve pas une seconde alimentation, un autre conduit ou un supplément de débit. Deux machines d’état peuvent être indépendantes dans le logiciel tout en partageant exactement le même mode de panne.

La maintenance exige un parent physique

Une fenêtre de maintenance doit être attachée à la ressource qui sera touchée. Si l’inventaire commence par les adjacences, il lui faut un parent stable : interface locale, carte, membre d’agrégat, circuit, fournisseur et groupe de risque. Chaque adjacence principale ou multi-zone référence ce parent.

Le plan de retrait se calcule ensuite sur les consommateurs de la ressource. Il ne suffit pas de relever le coût d’une adjacence si une autre vue de zone attire encore le trafic vers le même lien. Les LSDB, calculs SPF, RIB et FIB avant et après le changement montrent le plan logique ; les compteurs d’interface et la vérification du chemin montrent l’exécution.

RFC 6987 permet d’annoncer une métrique maximale pour un routeur en maintenance ou surchargé. RFC 9355 permet d’influencer le coût vu dans l’autre sens. Ce sont des leviers de contrôle, pas des reçus de sortie physique. Tant que la mesure ne montre pas que le trafic a quitté le circuit, celui-ci reste engagé.

Additionner les projections fabrique de la capacité

Les extensions de trafic de RFC 3630 peuvent annoncer métrique TE, bande passante maximale, bande passante réservable, disponibilité par priorité et groupe administratif. Ces attributs décrivent la ressource de liaison. Ils ne sont pas recréés à chaque changement de zone.

Si un circuit de 100 Gbit/s porte trois adjacences et que l’outil additionne trois fiches à 100 Gbit/s, il annonce 300 Gbit/s fictifs. Le même défaut fausse la marge de maintenance : l’outil peut croire qu’il retire un tiers d’une capacité alors qu’il retire la totalité du support.

Le calcul défendable déduplique par identifiant de circuit, compte la capacité une seule fois et énumère séparément les consommateurs logiques. La télémétrie par zone explique la demande et la sélection de route ; la télémétrie physique borne ce qui peut être livré.

Le choix intra-zone peut concentrer le risque

L’objectif même de RFC 5185 est de modifier la préférence de route. Une fois la liaison rapide visible comme intra-zone, un trafic auparavant distribué sur des liens internes peut s’y concentrer. L’amélioration de latence ou de coût peut donc agrandir le périmètre d’une coupure du circuit commun.

Le dossier doit conserver les volumes déplacés, la marge résiduelle, les chemins alternatifs et le point de retour. Une adjacence FULL après le changement ne répond pas à la question de savoir si le lien est saturé. Une alerte de congestion ne répond pas non plus à la question de savoir quelle zone a provoqué le déplacement. Le rapprochement des deux couches est indispensable.

Dans les termes des couches de réalité de Heng Lu, la Router-LSA rend une structure symbolique exécutable par SPF ; le câble et les paquets forment la contrainte opérationnelle. La symbolisation est utile tant qu’elle ne reçoit pas le pouvoir de multiplier le réel.

L’asymétrie interopère, puis complique l’incident

L’extrémité distante doit seulement présenter l’adjacence comme point à point. Les deux routeurs n’ont pas besoin d’une configuration multi-zone identique pour interopérer, même si RFC 5185 recommande la symétrie afin de faciliter représentation et diagnostic.

Cette souplesse soutient une adoption volontaire : chaque opérateur peut introduire l’extension sans exiger un modèle interne identique chez son voisin. Son coût est documentaire. Lors d’un incident, un côté peut parler d’une adjacence multi-zone et l’autre d’un point à point ordinaire.

Le reçu commun doit donc inclure Router ID, Area ID, interface, adresse du voisin ou origine de sa découverte, vue de chaque extrémité et identifiant physique partagé. Sans cette correspondance, deux équipes observent le même échec avec des noms incompatibles.

Le démultiplexage ne doit pas arbitrer une ambiguïté

L’Area ID d’un paquet reçu sélectionne normalement le contexte multi-zone. Sur un média non point à point, le voisin est configuré ou découvert hors OSPF et les paquets lui sont envoyés en unicast. Pour un paquet backbone, une correspondance simultanée avec un lien virtuel et une adjacence multi-zone constitue une erreur de configuration à traiter avant l’exécution.

Cette règle offre un précédent utile au changement : si deux interprétations valides réclament la même observation, le système ne choisit pas selon l’ordre d’arrivée. Il refuse la précondition ambiguë. Un plan de maintenance devrait faire de même lorsqu’il ne peut établir le parent physique d’une adjacence.

OSPFv3 sépare topologie et adressage

En OSPFv3, les liens de Router-LSA ne dépendent pas de la sémantique des adresses. L’adjacence supplémentaire peut donc décrire le voisin sans inventer de préfixe. RFC 5185 précise qu’aucun préfixe correspondant n’est annoncé dans l’intra-area-prefix-LSA et qu’une link-LSA ne devrait pas être émise pour cette adjacence. L’adresse link-local du voisin peut provenir des en-têtes Hello.

Un inventaire qui exige une adresse nouvelle pour chaque arête topologique créera alors une donnée imaginaire. Un inventaire correct conserve trois registres reliés : topologie OSPF, adressage observé et ressource physique.

Le reçu de changement réunit les trois vérités

Le minimum utile contient l’identifiant immuable du changement ; le cliché topologique ; versions logicielles et rôles ABR ; interface locale ; provenance de l’adresse voisine ; circuit, conduit, carte et fournisseur ; adjacence principale et adjacences ajoutées ; Area ID ; type du média et modèle point à point ; transitions des machines d’état ; Link ID, Link Data et métrique ; absence attendue du type 3 ; comportement OSPFv3 ; LSDB, SPF, RIB, FIB et trafic avant/après ; capacité dédupliquée ; risque commun ; symétrie ou asymétrie ; validation des collisions ; critères de drainage et de retour.

Cette discipline ne nie pas les adjacences multiples. Elle leur donne leur juste autorité. RFC 5185 crée plusieurs chemins topologiques valides afin que les décisions futures restent locales. L’opérateur préserve cette liberté en refusant qu’un graphe logique transforme un seul circuit en plusieurs promesses physiques.

Sources

  1. RFC 5185 — HTML
  2. RFC 5185 — texte
  3. Page d’information RFC Editor
  4. Document IETF Datatracker
  5. Historique IETF Datatracker
  6. Références IETF Datatracker
  7. Errata RFC 5185
  8. RFC 2328 — OSPF version 2
  9. Page d’information RFC 2328
  10. RFC 5340 — OSPF pour IPv6
  11. Page d’information RFC 5340
  12. RFC 3630 — extensions d’ingénierie de trafic
  13. RFC 6987 — annonce de routeur stub
  14. RFC 7770 — capacités optionnelles OSPF
  15. RFC 8665 — extensions Segment Routing
  16. RFC 9355 — métrique inverse OSPF
  17. RFC 3137 — annonce de routeur stub OSPF
  18. Heng Lu — couches de réalité
  19. Heng Lu — spécification minimale et adoption volontaire
  20. Heng Lu — primauté du code en service