Résumé

  • Dans l'exemple d'un projet IETF daté du 27 octobre, quatre routes portent le même préfixe. PE1 choisit celle de RD22 et l'importe dans VPN11 ; le compte rendu BMP identifie VPN11, mais perd RD22. Le tableau de bord sait où la route se trouve sans pouvoir nommer l'instance qui l'a fournie.
  • Le projet ajoute un champ d'origine distante et étend, dans sa révision 02, ce principe aux routes EVPN de type 5. L'émetteur peut l'omettre, le collecteur peut l'ignorer. Le choix de rendre cette origine indispensable appartient à l'opérateur.

Quatre routes, un nom qui disparaît

Le préfixe P1 arrive quatre fois sur PE1 dans le projet de Shunwan Zhuang et de ses coauteurs. PE2 en présente trois exemplaires depuis RD21, RD22 et RD23 ; PE3 en présente un autre depuis RD31. Tous peuvent être considérés par VPN11. PE1 retient, pour l'exemple, la route RD22. Le serveur de supervision reçoit alors l'entrée sélectionnée dans la table locale de VPN11. Le message lui donne P1, le prochain saut et RD11. L'instance RD22, qui a fourni la route retenue, n'y figure plus.

La scène n'est pas un incident réel. Elle met le doigt sur une économie d'information très concrète. Le personnel de supervision voit que VPN11 contient P1. Si deux instances distantes proposent ce même préfixe et que l'une remplace l'autre, la fiche d'arrivée ne raconte pas ce changement de provenance. Un contrôle qui devait surveiller les passages entre domaines administratifs se retrouve avec une preuve de présence, sans le nom du domaine source.

Le Datatracker de l'IETF classe le texte comme projet individuel actif. Il propose un ajout à BMP ; il n'a ni statut de RFC ni résultat de déploiement à présenter. Son intérêt éditorial tient à cette question : qui a le droit d'appeler « surveillé » un transfert entre instances lorsque le dispositif de surveillance ne peut identifier qu'un seul côté du transfert ?

Ce que la table locale peut raconter

Le RFC 9069 permet à BMP d'exposer la Loc-RIB, c'est-à-dire les routes sélectionnées par le processus de décision BGP local. Cette vue évite au collecteur de refaire tous les calculs à partir des annonces reçues. Mais le format de son en-tête se concentre sur l'instance locale : pour une route VPN, l'adresse du pair vaut zéro et le discriminateur désigne la table dont on observe la Loc-RIB. Dans l'exemple, c'est RD11. La route choisie venait de RD22.

Le routeur avait reçu les candidats ; la perte se produit dans le compte rendu vers le serveur BMP. Il serait facile de blâmer la mauvaise pièce. Le protocole permet de constater la sélection locale, et cette constatation est utile. Il faut simplement demander une autre donnée lorsque l'enquête porte sur la traversée d'une frontière de VRF. Un next hop désigne où envoyer la route ; il ne suffit pas à départager RD21, RD22 et RD23, tous proposés par PE2 dans l'exemple.

Le nouveau champ, nommé Remote VRF Information TLV, ferait voyager l'identifiant BGP distant et le discriminateur de route distant avec l'entrée surveillée. RD11 et RD22 auraient enfin deux places distinctes dans la même fiche. Le projet prévoit aussi, séparément, des champs facultatifs pour l'étiquette VPN ou l'identifiant SRv6 de la route distante. Ils éclairent le traitement de la route ; ils ne remplacent pas le nom de l'instance qui l'a fournie.

Cette distinction n'est pas un luxe d'archiviste. Une règle d'importation peut autoriser une famille de routes, mais l'équipe chargée de la contrôler doit pouvoir dire quelle instance précise a franchi le seuil. Si le collecteur ne garde que l'état final, l'opérateur peut montrer une route correctement sélectionnée tout en étant incapable de reconstituer sa provenance. La conformité du message et l'utilité du témoignage sont deux qualités différentes.

Le même trou dans EVPN

La révision 01 traitait déjà les routes VPN. La révision 02 ajoute un cas EVPN de type 5 importé entre instances EVI par routage et pontage intégrés. Dans son exemple, P1 part d'EVI21 sur PE2 et aboutit à EVI11 sur PE1. La fiche BMP ordinaire affiche P1 dans EVI11 et PE2 comme prochain saut. Elle ne dit pas que l'instance source était EVI21. Le champ proposé peut porter AFI 25, SAFI 70, l'identifiant BGP distant et RD21.

Un autre projet IETF sur les statistiques EVPN prévoit des compteurs par EVI, notamment pour des routes transférées entre VRF. Le nombre peut signaler qu'un mouvement a eu lieu ou qu'il a changé d'ampleur. Il ne donne pas l'origine de cette route P1. Pour une enquête, le compteur et la fiche de provenance se complètent ; ils ne se remplacent pas.

Il faut également respecter l'étage observé. Une entrée de Loc-RIB dit ce que le processus BGP local a sélectionné. Le projet ne démontre ni installation dans une table de transfert, ni passage de paquet, ni effet sur un service. Une supervision plus fine de l'origine améliore l'explication d'une décision de routage. Elle ne transforme pas cette décision en résultat réseau constaté.

L'option peut disparaître deux fois

Le texte autorise un émetteur BMP qui prend en charge l'extension à joindre le champ d'origine distante ; il ne l'y oblige pas. Le collecteur peut ensuite l'ignorer en restant compatible avec le traitement BMP existant. Les valeurs de type à enregistrer auprès de l'IANA restent à déterminer. Le projet fournit donc un vocabulaire possible, tandis que l'opérateur doit faire le travail moins élégant : vérifier que ses routeurs l'émettent, que son collecteur le conserve et que ses alertes l'utilisent.

La section sécurité du projet demande des appareils de supervision autorisés et dignes de confiance. Cette frontière de session importe. Elle ne décide pas quelles équipes doivent recevoir l'identité RD22, combien de temps elles la gardent, ni quel responsable accepte qu'elle manque. Un écran peut annoncer une session BMP saine pendant que l'information nécessaire à une vérification de politique a été écartée à l'entrée.

Sources