Résumé

  • Dans la RFC 10039, un domaine se définit par le comportement d’acheminement du trafic d’un locataire. Il ne se déduit ni d’un ASN, ni d’une instance IGP, ni d’un organigramme.
  • Le DOMAIN-ID est une déclaration configurée qui agit sur le réseau : sa présence dans D-PATH signale une boucle et la longueur de D-PATH intervient dans le choix de route. Une déclaration incohérente peut donc écarter une route légitime.

La première passerelle appelle le site central « domaine 6500:1 ». La seconde lui attribue 6500:3. Les deux sessions BGP montent, les préfixes EVPN et IPVPN sont bien formés et chaque équipe peut montrer une capture convaincante. Pourtant, les équipements ne racontent pas la même topologie logique. Au retour d’une route, chacun cherche son propre nom dans une histoire écrite avec le vocabulaire de l’autre.

C’est le piège discret de D-PATH. La RFC 10039 résout un problème concret d’interconnexion : un réseau de locataire peut traverser plusieurs domaines EVPN et IPVPN, reliés par des PE de passerelle qui réémettent les routes dans une autre famille. Avec plusieurs passerelles redondantes, une route peut repartir vers son domaine d’origine et former une boucle de plan de contrôle. L’attribut Domain Path mémorise les domaines traversés afin que la boucle puisse être reconnue.

Mais cette mémoire ne vaut que par le dictionnaire commun qui la précède.

Le domaine n’est pas la boîte du dessin

La définition normative ne suit pas les frontières administratives usuelles. Deux PE relèvent du même domaine si elles servent le même locataire et si les paquets échangés entre elles n’exigent pas, sur un routeur de transit, une recherche IP dans l’espace du locataire. Dès qu’une telle recherche intervient, une passerelle relie des domaines distincts.

Une seule AS peut donc contenir plusieurs domaines ; inversement, un domaine peut traverser plusieurs AS. Il en va de même pour les zones IGP. Un site, une région cloud ou une équipe d’exploitation peuvent constituer de bons repères de travail, mais ils ne remplacent pas le test de forwarding.

Le format du DOMAIN-ID peut renforcer la confusion. Ses six octets comprennent un administrateur global sur quatre octets et un administrateur local sur deux. La partie globale peut reprendre un ASN public ou privé, une adresse IPv4, ou une autre valeur. Il s’agit d’un espace de nommage pratique. Écrire un ASN dans le champ ne prouve pas que le domaine épouse l’AS ; écrire une adresse ne fait pas de son détenteur l’autorité du domaine.

L’obligation opérationnelle est ailleurs : chaque domaine doit posséder un identifiant unique, toutes les passerelles qui lui sont rattachées doivent utiliser exactement le même, et une passerelle placée entre deux domaines doit en porter deux différents. L’affectation peut être commune à l’interconnexion ou propre à chaque IP-VRF de locataire. Ce choix n’est pas décoratif : lors d’une fuite contrôlée entre VRF, la comparaison s’effectue dans le contexte des identifiants attachés à la VRF concernée.

Le registre local produit un effet de routage

D-PATH est un attribut BGP facultatif et transitif, enregistré par l’IANA dans les paramètres BGP sous le code 36. Chaque élément associe le DOMAIN-ID à un ISF_SAFI_TYPE, ce dernier indiquant si l’étape a emprunté EVPN, IPVPN ou, dans certains cas d’origine locale, la valeur zéro.

Cette information de SAFI facilite le diagnostic, mais elle ne participe pas au verdict de boucle. Si une passerelle retrouve dans D-PATH l’un des DOMAIN-ID configurés localement pour la VRF, elle traite la route comme revenue dans un domaine déjà traversé, quelle que soit la valeur SAFI accolée. Un conflit d’identifiants devient ainsi un faux positif capable d’écarter du trafic. Une divergence entre deux passerelles du même domaine produit l’effet inverse : le retour peut ne pas être reconnu.

L’identifiant pèse aussi dans la sélection. Après la comparaison de LOCAL_PREF, les candidats EVPN et non-EVPN qui n’ont pas le D-PATH le plus court sont retirés. L’absence de D-PATH compte comme une longueur nulle. Ce nombre ne mesure pourtant ni la distance physique, ni le délai, ni la congestion, ni le prix du transit. Il compte les passages déclarés par des passerelles selon une carte configurée. La carte devient donc une entrée de décision sans devenir pour autant une observation du terrain.

Voilà pourquoi une vérification de syntaxe est insuffisante. Voir le code 36 dans un UPDATE confirme que des octets ont circulé. Cela ne démontre ni l’unicité des noms, ni l’exhaustivité des passerelles, ni la cohérence des VRF, ni le résultat dans la FIB.

Deux modes, deux pertes possibles

La RFC laisse D-PATH désactivé par défaut et limite son usage aux routes IPVPN et EVPN. Le mode par défaut, No Propagation, réinitialise les attributs au moment où la passerelle réémet une route dans un autre domaine. D-PATH disparaît alors. Le domaine suivant reçoit moins d’état hérité, mais les passerelles redondantes peuvent rester vulnérables à une boucle ; une politique locale ou une communauté d’origine peut réduire le risque sans constituer une garantie universelle.

Uniform Propagation conserve au contraire un ensemble borné d’attributs : AS_PATH, D-PATH lorsque la famille le permet, et certains attributs internes sur les sessions iBGP. Les autres ne devraient franchir la limite qu’après autorisation explicite des politiques d’import et d’export. Ce mode préserve davantage de provenance, au prix d’un périmètre plus large pour une donnée malveillante ou sémantiquement inadaptée.

La question n’est donc pas « quel mode est sécurisé ? » mais « quel risque cette frontière accepte-t-elle ? ». Le premier mode sacrifie de la visibilité pour isoler l’état. Le second conserve une continuité utile, mais oblige à filtrer ce qui traverse. La réponse peut varier d’une interconnexion à l’autre ; elle doit être écrite et testée au même niveau de détail que les DOMAIN-ID.

Une forme valide peut porter une mauvaise réalité

La RFC prévoit des réactions précises aux erreurs d’encodage. Un D-PATH mal formé, trop court ou associé à une AFI/SAFI interdite déclenche le traitement treat-as-withdraw de la RFC 7606. Une valeur SAFI inconnue peut être conservée, car elle n’affecte pas le test d’identité. Si plusieurs D-PATH se trouvent dans le même UPDATE, seul le premier demeure.

Ce filet protège la session contre une structure cassée. Il ne sait pas qu’une valeur proprement encodée a été réutilisée dans deux domaines différents. Il ne sait pas qu’un ingénieur a rattaché une VRF au mauvais côté. La RFC avertit d’ailleurs qu’une configuration incorrecte ou un support inégal peut provoquer une détection de boucle erronée, la suppression de trafic, ou des choix de route sous-optimaux et incohérents.

La limite vers le client doit elle aussi être vérifiée. D-PATH est conçu pour le « jardin clos » du VPN. Une PE conforme le retire avant d’annoncer le préfixe au CE en unicast SAFI 1. Le document recommande aussi qu’un équipement mis à niveau rejette, par politique locale, certains D-PATH reçus de pairs classés comme non mis à niveau. Il ne définit pas comment établir ce classement. L’inventaire des versions et l’essai de comportement restent à la charge de l’opérateur.

Un accord de frontière avant le changement

Le bon objet de gouvernance est un accord de frontière par locataire et interconnexion. Il commence par le test de forwarding qui justifie le contour, puis désigne l’allocateur des DOMAIN-ID, le périmètre d’unicité, la recherche de collision et toutes les passerelles et VRF auxquelles la valeur sera appliquée. La notation choisie doit rester séparée de sa signification.

À cet accord s’ajoute un reçu de déploiement : versions logicielles, support observé, mode de propagation sur chaque frontière, liste d’attributs autorisés, règle pour les routes locales, canaris, seuil d’arrêt et voie de retour indépendante. Une passerelle qui ne peut pas participer doit être traitée comme un état explicite, pas comme une note de bas de page.

Les essais doivent faire travailler le mécanisme dans les deux sens. Une route légitime suit la séquence prévue ; une route contenant un identifiant local est reconnue comme retour ; une valeur SAFI inconnue ne neutralise pas la comparaison ; un encodage mal formé reste contenu ; un pair d’ancienne génération révèle son comportement réel. À la sortie CE, une capture prouve la disparition de D-PATH en SAFI 1.

Enfin, le même préfixe est suivi dans Adj-RIB-In, dans la sélection, dans la FIB et par un paquet canari. Une commande acceptée n’est qu’une configuration. Un attribut visible n’est qu’une déclaration. Le résultat opérationnel n’existe que lorsque les passerelles partagent la bonne déclaration et que le trafic distingue comme prévu le chemin légitime du chemin de retour.

Les bases restent publiques : RFC 4271 pour BGP, RFC 4364 pour IPVPN, RFC 7432, RFC 9135 et RFC 9136 pour EVPN. Elles spécifient des comportements. Elles ne certifient aucun produit, aucun réseau et aucun déploiement nommé.

Sources