Résumé

  • BGP-LS transforme des informations IGP et TE en objets BGP soumis à une politique de divulgation ; le résultat peut être physique, abstrait ou mixte et ne reproduit pas le LSDB à l'identique.
  • Une décision défendable doit relier la source, le producteur, l'Instance-ID, les retraits, l'époque reçue et la règle de fusion du consommateur au calcul puis au résultat réellement installé et observé.

Le premier écran de supervision est rassurant. Les sessions BGP sont établies, les deux producteurs répondent, le contrôleur possède des nœuds, des liens et des métriques. Pourtant, le lien que le moteur vient de choisir a disparu du réseau physique.

La cause se trouve dans la manière dont la connaissance a survécu à la panne. Un producteur a gardé le descripteur du lien dans un sens ; l'autre, isolé de l'autre côté, a gardé le sens opposé. Le consommateur a reconnu les extrémités et assemblé ces fragments comme s'ils formaient une observation commune. Il a obtenu une vue cohérente, mais fausse.

RFC 9552 décrit précisément ce risque lorsqu'un nœud devient inaccessible à des producteurs redondants. Le texte, publié en décembre 2023, remplace complètement RFC 7752 et reprend les mises à jour de RFC 9029. Son apport n'est pas seulement un nouveau format : il oblige à distinguer transport d'information, vérité topologique et pouvoir d'agir.

Une fabrication contrôlée, pas un miroir

Un producteur BGP-LS part généralement d'un LSDB OSPF ou IS-IS et d'une base d'ingénierie de trafic. Il en tire des NLRI de type nœud, lien ou préfixe, puis place les propriétés dans l'attribut BGP-LS. Un seul objet exporté peut réunir des éléments issus de plusieurs LSA ou LSP ; les numéros de séquence originaux ne voyagent pas avec lui.

Ce détail interdit une formule trop commode : « le contrôleur possède le LSDB ». Il possède une représentation dérivée. Certains champs n'ont pas vocation à sortir, certains éléments vieillis ou malformés sont écartés selon les règles du protocole source, et la politique peut retarder ou filtrer l'émission.

L'écart peut être volontaire. RFC 9552 autorise la diffusion d'une topologie physique, d'une vue abstraite faite de nœuds agrégés et de chemins virtuels, ou d'un mélange des deux. Un service ALTO n'attend pas forcément le même grain qu'un PCE. Une topologie différente de l'inventaire n'est donc pas coupable en soi ; elle doit être jugée par rapport au contrat accordé à ce consommateur.

Ce contrat devrait préciser le domaine source, les objets et attributs permis, le degré d'abstraction, la fréquence, le délai de fraîcheur et la finalité. Sans cela, deux équipes peuvent qualifier la même vue de « fidèle » et « inexacte » tout en parlant de deux obligations différentes.

Les rôles ne s'annulent pas quand ils partagent une machine

La norme nomme un producteur, un propagateur et un consommateur. Le producteur introduit l'information de topologie dans BGP. Le propagateur reçoit les UPDATE, exécute le processus de décision BGP et propage ce qui a été sélectionné. Le consommateur est l'application ou le processus qui exploite la vue ; il n'est pas nécessairement un locuteur BGP.

Un routeur, un serveur ou une plate-forme peut cumuler plusieurs rôles. L'audit doit néanmoins les séparer. Pour chaque transition, il faut pouvoir dire : quel objet a été dérivé, quelle route BGP a été choisie, quelle copie a été transmise, quelle règle a fusionné les objets et quelle décision applicative en a découlé.

L'interface allant du locuteur BGP au consommateur doit rester unidirectionnelle. Le consommateur ne doit pas pouvoir réinjecter par ce canal de l'information à originer en BGP-LS. Cette règle empêche l'outil d'analyse de devenir silencieusement l'auteur de sa propre preuve. Une demande de programmation doit passer par une interface distincte, avec identité, autorisation et journal propres.

L'identité comporte un domaine et une époque

Les objets non-VPN utilisent AFI 16388 / SAFI 71 ; les objets VPN utilisent SAFI 72. RFC 4760 apporte la négociation multiprotocole et les attributs MP_REACH_NLRI et MP_UNREACH_NLRI. La capacité négociée prouve l'existence du canal, jamais la fraîcheur d'un lien.

Protocol-ID distingue notamment IS-IS niveau 1 ou 2, OSPFv2, OSPFv3, Direct et Static. L'Instance-ID BGP-LS, sur huit octets, sépare les instances IGP. Les producteurs d'un même domaine doivent partager la même valeur ; des domaines différents doivent employer des valeurs uniques. Sinon, un consommateur peut dédoubler un même réseau ou fusionner deux réseaux indépendants.

Les descripteurs ASN, zone, identifiant de routeur et topologie complètent la clé. Changer l'un de ces descripteurs ne revient pas à modifier une fiche. L'ancien NLRI doit être retiré par MP_UNREACH, puis le nouveau annoncé. Sans preuve négative, l'ancien objet peut continuer à vivre comme un jumeau périmé.

Une migration d'Instance-ID ou de producteur doit donc avoir deux critères de succès : la nouvelle identité apparaît partout où elle est attendue, et l'ancienne disparaît du producteur, des RIB intermédiaires, des annonces par voisin et du graphe du consommateur.

Deux flux ne font pas une horloge

La redondance protège contre la perte d'un processus ou d'une session. Elle ne certifie pas que deux copies ont observé le même instant. Le processus de décision défini par RFC 4271 sélectionne une route selon les attributs BGP ; il n'élit pas l'observation physiquement la plus récente.

Des producteurs peuvent aussi varier dans leurs TLV optionnels. Le consommateur doit alors reconnaître les doublons, fusionner avec prudence ou rendre visible l'information manquante. Une différence de clé ou d'attribut ne doit pas être masquée par un simple compteur d'objets.

Pour le cas du lien coupé, la preuve utile réunit l'accessibilité du nœud source depuis chaque producteur, l'âge de l'objet IGP, l'époque LSDB/TED, les UPDATE exacts, le chemin BGP sélectionné, les retraits attendus et l'état de fusion côté consommateur. Deux sessions vertes ne répondent à aucune de ces questions.

RFC 9552 recommande de retirer les objets provenant de nœuds devenus inaccessibles, sauf si le cas d'usage exige explicitement de maintenir une vue LSDB complète. Cette exception doit avoir un propriétaire et une durée. Une conservation sans limite transforme une préférence de produit en vérité implicite.

Un NLRI sans attribut signale une perte

L'identité réside dans le NLRI ; de nombreuses propriétés résident dans l'attribut BGP-LS. Les règles d'erreur associées à RFC 7606 permettent qu'un attribut malformé soit écarté alors que le NLRI reste présent. Le lien n'a pas été supprimé ; ses propriétés ont pu être perdues pendant le transport.

Il faut donc afficher séparément « attribut absent par politique », « attribut inconnu mais propagé » et « attribut écarté pour erreur ». Assimiler ces états à une métrique vide peut conduire le calculateur à appliquer une valeur par défaut et à produire une route dont la prémisse n'a jamais été autorisée.

Les attributs volumineux peuvent en outre dépendre du support des messages étendus de RFC 8654. Si les producteurs excluent des TLV différents ou si le chemin n'offre pas les mêmes capacités, deux consommateurs peuvent recevoir une identité identique et des matières premières différentes. Le contrôle doit comparer les ensembles d'attributs, pas seulement les clés.

La réception ne vaut pas mandat d'exécution

BGP-LS peut fournir une topologie à une architecture PCE décrite par RFC 4655, à un service ALTO ou à d'autres contrôleurs. RFC 8571 permet notamment de transporter des métriques de performance TE. La norme de transport ne valide pas l'algorithme qui les consomme.

Il faut préserver une chaîne sans raccourci : LSA/LSP et époque source ; politique et identité du producteur ; capacité AFI/SAFI, UPDATE, retraits et sélection ; ensemble reçu et fusionné par le consommateur ; instantané et contraintes du calcul ; approbation ; transaction southbound ; acceptation par les équipements ; état label/FIB ; puis tests de paquets positifs et négatifs.

Un appel API réussi n'est qu'une étape. Un acquittement de l'équipement n'est pas une table de transfert. Une table de transfert n'est pas un trajet observé. La responsabilité s'arrête seulement là où la preuve s'arrête.

Isoler le trafic, protéger la connaissance

Les changements de topologie peuvent produire un rythme d'UPDATE supérieur à celui des préfixes BGP ordinaires. RFC 9552 recommande des route reflectors dédiés ou une isolation équivalente afin que cette charge ne perturbe pas la distribution classique, et limite la diffusion à un domaine administratif.

Cette isolation n'enlève rien à la sensibilité de la donnée. Topologie, capacité et métriques TE peuvent révéler des vulnérabilités opérationnelles ou commerciales. Les pairs doivent être explicitement approuvés et les voisins réservés à la consommation empêchés d'émettre des UPDATE.

Les guides Cisco IOS XR, IOS XE et Juniper montrent des contrôles d'Instance-ID, de politique, de file d'attente, de table et de voisin consommateur. Ils prouvent que l'on peut inspecter des implémentations réelles ; ils ne rendent ni les commandes ni les valeurs par défaut universelles. Version logicielle, héritage de configuration et état observé doivent accompagner chaque capture.

Sources