Résumé

  • Route Target Constraints transforme l’intérêt d’import d’un PE en état de divulgation propre à chaque voisin : le NLRI d’appartenance part vers le détenteur des routes, puis les routes VPN qui correspondent reviennent vers le demandeur.
  • Cet état optimise la distribution, mais n’authentifie ni client ni VPN. Une mise en service défendable doit prouver la capacité AFI/SAFI, l’appartenance exacte, la synchronisation bornée, le changement d’Adj-RIB-Out, la politique de sécurité indépendante et le résultat VRF/FIB/paquets.

Le ticket de changement d’un nouveau VPN est déjà marqué « terminé ». La VRF existe, son Route Target d’import est visible, le préfixe attendu se trouve sur le PE d’origine et les sessions vers les réflecteurs sont Established. Pourtant, le PE destinataire ne reçoit rien.

La première tentation consiste à chercher une panne du préfixe. La deuxième, à réinitialiser BGP. Les deux passent à côté de l’objet absent : le réflecteur n’a pas reçu l’annonce d’appartenance au Route Target qui autorise la divulgation de cette famille de routes à ce voisin. Il ne bloque pas une route défectueuse. Il conserve une route valide hors d’un graphe de distribution qui ne contient pas encore le PE.

Le mécanisme défini par le RFC 4684 répond à un problème de volume. Dans un modèle dense, un route reflector peut envoyer de nombreuses routes VPN à un PE, qui rejettera ensuite celles dont aucune VRF locale n’importe le Route Target. RTC déplace cette information en amont. Le PE annonce ce qu’il veut pouvoir importer ; le RR construit un filtre de sortie et n’envoie que les NLRI VPN qui correspondent.

Ce gain de mémoire, de calcul et de bande passante crée un nouvel objet d’exploitation. L’état de session ne suffit plus. La route source ne suffit plus. Il faut auditer l’intérêt distribué.

Le Route Target ouvre une possibilité, il n’installe pas une route

Le RFC 4364 distingue le Route Distinguisher, qui rend uniques des préfixes VPN qui pourraient se chevaucher, et le Route Target, qui participe à la politique d’import et d’export. Une route peut porter plusieurs RT ; une VRF peut en importer plusieurs.

Une correspondance rend la route éligible à l’import. Elle ne garantit ni sélection, ni résolution du next hop, ni programmation d’un label, ni transmission. Le processus BGP, la politique locale, le plan de données et parfois le protocole PE-CE restent des étapes distinctes.

RTC ne modifie pas cette sémantique. Il permet à un pair de ne pas annoncer une route qui n’a aucune chance d’intéresser le récepteur selon l’état connu. Confondre le NLRI d’appartenance avec une preuve d’installation revient à confondre une demande de catalogue avec la livraison et l’usage du produit.

Cette distinction donne une méthode de diagnostic. Vérifier d’abord que la route a été créée. Vérifier ensuite que le RR la détient. Examiner l’intérêt RTC reçu du PE, le filtre dérivé et l’Adj-RIB-Out VPN propre à ce voisin. Seulement après viennent la réception, l’import VRF, la sélection, le FIB et les paquets.

Un graphe inverse, pas une commande distante

Le RFC 4684 encode l’appartenance sous forme de NLRI MP-BGP. L’information contient conceptuellement un AS d’origine et un Route Target. Elle voyage vers les systèmes qui disposent de routes marquées par ce RT. Ces routes se propagent ensuite dans le sens inverse de l’annonce d’intérêt.

Le couple AFI 1 / SAFI 132 identifie cette famille. MP_REACH_NLRI annonce une appartenance et MP_UNREACH_NLRI la retire. Hors route par défaut, la clé associe quatre octets d’AS d’origine à huit octets de Route Target ; sa longueur va de 32 à 96 bits. L’encodage en préfixe permet de couvrir un ensemble de RT, mais un intérêt plus large élargit également le périmètre de divulgation.

Le préfixe de longueur zéro représente le Route Target d’appartenance par défaut. Il signifie que le pair accepte l’ensemble des annonces VPN concernées. Il ne désigne ni route IP par défaut, ni VRF par défaut, ni client universel. Il désactive pratiquement la sélectivité pour cette relation.

Un RR peut légitimement annoncer cet intérêt large à certains clients, et une migration partielle peut conserver une distribution dense pour des pairs sans RTC. Mais ce choix doit avoir un propriétaire et un budget. Une route d’appartenance par défaut peut multiplier les routes reçues, les événements de convergence et les informations visibles à la frontière.

La capacité n’est que la porte d’entrée

Le RFC 4760 fournit MP_REACH_NLRI, MP_UNREACH_NLRI et la négociation multiprotocole. Pour échanger une famille dans les deux sens, chaque pair annonce le couple AFI/SAFI correspondant. Le RFC 4684 s’appuie sur cette capacité pour RTC.

Une configuration family route-target ou rtfilter ne prouve pas la négociation effective. Une négociation réussie ne prouve pas qu’un RT précis a été annoncé. La présence du RT dans une table ne prouve pas qu’il a produit le bon filtre pour le bon voisin.

La note opérationnelle Route Target Constraint de Cisco montre, sur les produits concernés, comment la liste des RT d’import des VRF alimente l’adresse-family rtfilter, puis comment le RR installe un filtre reçu et relance une marche incrémentale des routes VPN. La documentation Juniper family route-target décrit le même partage des rôles entre PE demandeur et RR sélectif.

Ces commandes sont des indices propres à un produit. La preuve reste l’état d’exécution : OPEN négociés, UPDATE reçus, table d’appartenance, politique appliquée, filtre dérivé et annonces VPN effectivement préparées.

Le meilleur chemin d’appartenance ne suffit pas toujours

Plusieurs PE d’un même AS peuvent annoncer exactement la même clé {AS d’origine, RT}. Une sélection BGP ordinaire peut réduire ces chemins à un seul meilleur. Pour une reachability classique, un chemin peut suffire. Pour l’appartenance, il faut conserver les directions dans lesquelles les routes VPN devront être renvoyées.

Le RFC 4684 impose donc de considérer tous les chemins iBGP disponibles d’un préfixe RT lors de la construction du filtre, et pas seulement le meilleur. Il adapte aussi les règles d’annonce des appartenances locales dans une topologie de réflexion. Ces règles reposent sur une architecture de clusters cohérente telle que la décrit le RFC 4456.

Un écran qui montre « RT présent » ne répond pas à la question opérationnelle. Il faut savoir quels clients ont annoncé cet intérêt, quels chemins le RR a conservés, et quel filtre il a construit pour chaque pair. Une égalité de clés ne rend pas les demandeurs interchangeables.

Cette exigence distingue RTC d’ADD-PATH. ADD-PATH expose plusieurs chemins d’une même reachability avec des identifiants locaux. RTC doit préserver plusieurs directions de demande afin que la distribution inverse atteigne tous les PE intéressés.

Rejoindre et quitter sont des transitions distribuées

Lorsque le RR reçoit une annonce ou un retrait d’appartenance, le RFC 4684 lui demande de réévaluer ses RIB-OUT VPN et de produire l’ensemble minimal d’annonces ou de retraits nécessaire. La création d’une VRF n’est donc pas terminée au commit. Sa suppression ne l’est pas lorsque la ligne de configuration disparaît.

Pour une arrivée, la preuve va de l’intention d’import locale à l’annonce RTC, puis au chemin conservé par le RR, au filtre élargi, à l’Adj-RIB-Out VPN, à la réception, à l’import VRF et au trafic. Pour un départ, il faut prouver que plus aucune VRF locale n’utilise le RT avant de retirer l’intérêt, puis vérifier que seules les routes devenues sans correspondance disparaissent.

Les routes avec plusieurs RT rendent les compteurs trompeurs. Le retrait d’un intérêt ne doit pas supprimer une route encore justifiée par un autre RT. Un total inchangé peut cacher l’échange d’une route attendue contre une route indésirable. Les contrôles doivent comparer des identités de route et leurs attributs.

EoR donne un repère, pas le droit d’attendre sans fin

Le RFC recommande un marqueur End-of-RIB pour la famille RTC, même sans Graceful Restart. Le récepteur peut attendre ce repère avant de libérer les premières annonces VPN afin de ne pas distribuer un état dense avant de connaître les intérêts.

Cette attente doit être bornée. Le RFC donne 60 secondes comme valeur par défaut. Ce délai n’est pas une promesse universelle de service ; il interdit surtout qu’un EoR absent suspende indéfiniment la distribution.

Le dossier de changement doit enregistrer l’horodatage EoR, la valeur effective du délai et le comportement à expiration. L’équipement libère-t-il l’état déjà connu, adopte-t-il un mode plus dense ou applique-t-il un comportement spécifique ? L’heure de passage à Established ne fournit pas cette information.

Le RFC 7543 montre comment un Covering Prefix ORF peut amener un RR à réclamer, via RTC, des routes VPN qui lui manquent. Cette composition confirme justement que les objets restent distincts : ORF est transporté avec ROUTE-REFRESH, l’appartenance RTC avec UPDATE.

Une optimisation qui refuse le rôle de barrière de sécurité

Le RFC 4684 affirme que les filtres de sortie construits à partir de l’appartenance RT ne sont pas destinés à la sécurité. Entre domaines administratifs, des filtres indépendants doivent contrôler les NLRI entrants et sortants, et l’appartenance elle-même doit pouvoir être filtrée.

Cette limite est indispensable. Un NLRI RTC est une assertion BGP d’un pair. Il n’authentifie pas le client, ne prouve pas un contrat, ne valide pas la route VPN et n’autorise pas le pair à étendre librement le vocabulaire des RT.

Un pair qui peut annoncer n’importe quel intérêt peut demander une divulgation beaucoup plus large. Une route par défaut RTC acceptée sans restriction peut supprimer la sélectivité à une frontière sensible. Une traduction de RT non reproduite dans la politique d’appartenance peut créer deux graphes incompatibles.

La politique de sécurité doit donc rester séparée : espace de RT autorisé, voisins habilités, filtres d’appartenance entrants, filtres VPN sortants, traduction explicite, limites de volume, journalisation et retrait. RTC réduit le coût de cette distribution ; il ne fabrique pas la confiance.

Sources