RD contre RT dans un VPN MPLS : unicité contre politique d’importation

Deux sites clients peuvent annoncer 10.20.0.0/24 et tous deux restent valides au sein d’un même réseau opérateur. Le route distinguisher maintient ces annonces distinctes ; le route target décide quelle VRF client peut en prendre une copie. Ils apparaissent côte à côte dans la configuration et remplissent des rôles totalement différents. Les confondre conduit à des changements qui semblent raisonnables et ne corrigent rien.

Suivez une route du bord client jusqu’à une VRF distante et la séparation devient concrète : l’identité est attachée avant que la route entre dans BGP, et la politique de distribution est évaluée lorsque la route atteint le bord opérateur qui la reçoit.

Une route VPN-IPv4 est un RD plus un préfixe IPv4

La RFC 4364 définit la famille d’adresses VPN-IPv4 comme un route distinguisher de huit octets suivi d’une adresse IPv4 de quatre octets. Le RD est ajouté devant le préfixe du client, de sorte que deux préfixes identiques issus de sites différents deviennent deux routes BGP différentes.

Cette construction constitue tout le mécanisme d’unicité. L’opérateur n’a pas besoin que les clients s’accordent sur un espace d’adressage sans chevauchement, et une route d’un site ne peut pas remplacer silencieusement un préfixe identique d’un autre site.

Le format du RD est lui-même une valeur choisie par l’administrateur, souvent un numéro de système autonome et un numéro local. Sa forme numérique est une convention, pas le signe que les deux champs partagent un sens avec un route target qui utilise par hasard les mêmes chiffres.

Le RD rend les préfixes qui se chevauchent distinguables

Considérez deux annonces pour le même préfixe. Le site A porte le RD 65000:101 et le site B porte le RD 65000:202, tous deux pour 10.20.0.0/24. BGP détient maintenant deux routes VPN-IPv4 qui peuvent être comparées, filtrées et sélectionnées indépendamment.

Le RD n’indique pas quelle VRF doit recevoir l’une ou l’autre route, et il n’identifie ni un client ni un service. C’est un champ d’identité de la route, pas une liste d’appartenance. Le RD propre à une VRF n’a pas à correspondre au RD d’une route qu’elle importe.

C’est pourquoi changer un RD pour qu’il corresponde au numéro d’un autre site ne corrige rien. Si une route manque de l’autre côté, faire correspondre les chiffres crée un problème d’identité différent au lieu de réparer la décision d’importation.

Le RT est un attribut BGP, pas une étiquette du paquet

Une politique d’exportation attache un ou plusieurs route targets à la route sous forme d’attributs de communauté étendue BGP. Le bord opérateur qui reçoit compare ces attributs à la politique d’importation de chaque VRF. Le RT voyage avec la route dans le plan de contrôle. La comparaison se fait entièrement dans la politique de routage, avant qu’un paquet client ne soit transmis.

Les paquets de données du client ne portent pas le RT. Une fois la route installée dans une VRF, le transfert utilise la table de cette VRF et la pile d’étiquettes MPLS que l’architecture attribue. Le bord opérateur ne lit pas un route target dans chaque paquet client.

Une route peut porter plusieurs RT, et une VRF peut en importer plusieurs. La configuration ressemble souvent à un court bloc :

vrf definition CUST-A
 rd 65000:101
 address-family ipv4
  route-target export 65000:500
  route-target import 65000:500

Lisez ce bloc comme deux instructions distinctes. La ligne d’exportation contrôle ce qui est attaché aux routes qui quittent cette VRF ; la ligne d’importation contrôle ce que cette VRF accepte d’examiner. Des numéros identiques sont commodes, pas obligatoires.

L’éligibilité à l’importation n’est pas l’installation

Une route peut être éligible pour une VRF et pourtant ne pas apparaître dans sa table de transfert. L’éligibilité est un filtre ; ensuite le processus de décision normal de BGP compare les routes éligibles et en sélectionne une. Une route plus ancienne ou moins préférée peut perdre contre un autre chemin éligible.

Vérifiez la route sélectionnée, pas seulement la politique d’importation. Une VRF qui importe le RT 65000:500 et n’affiche aucune route pour 10.20.0.0/24 a peut-être reçu la route et l’a rejetée lors de la sélection, ou peut-être ne l’a jamais reçue.

Cette distinction compte aussi lorsqu’un préfixe inattendu apparaît. Une politique d’importation trop large peut attirer des routes que le site ne comptait pas utiliser, et l’unicité du RD n’y empêche rien. L’étendue de distribution est une question de politique de RT.

Diagnostiquez une route manquante dans l’ordre du plan de contrôle

Commencez par l’annonce : la VRF d’origine exporte-t-elle le RT prévu, et la route existe-t-elle comme route VPN-IPv4 sur le réflecteur de routes ou sur le PE qui reçoit ? Vérifiez ensuite l’attribut tel qu’il a été reçu, et non tel qu’il est configuré sur l’émetteur.

Comparez ensuite la liste d’importation de la VRF qui reçoit avec les valeurs réelles de RT de la route. Enfin, inspectez la route sélectionnée dans cette VRF et la liaison d’étiquette. Chaque étape répond à une question différente, et sauter au RD passe généralement à côté de celle qui est fausse.

Notez le RD, le RT exporté, le RT importé et le prochain saut sélectionné pour le site qui fonctionne et celui qui échoue. Quatre valeurs côte à côte transforment un vague « le VPN ne passe pas les routes » en l’étape précise du plan de contrôle qui diffère.