Inter-AS VPNv4 : ce qu'exige le contrat de commutation d'étiquettes

Lire une étiquette VPNv4 sur un routeur de bordure AS ne vous apprend pas grand-chose tant que vous ignorez quel modèle inter-AS applique le raccordement. L'étiquette n'est pas une propriété de la route en soi ; elle consigne un accord sur l'encapsulation et la livraison entre deux routeurs. Identifiez le modèle avant de lire l'affichage. Sinon, vous déboguez un contrat que personne n'a écrit.

Quel modèle la frontière applique

L'arrangement VRF-à-VRF relie des VRF correspondants via des rattachements routés. Chaque côté voit l'autre comme un voisin client et ils échangent des routes IPv4 ordinaires, si bien que rien à cette frontière n'exige MPLS.

Un deuxième arrangement échange des routes VPNv4 étiquetées entre les routeurs de bordure eux-mêmes. Cela ne fonctionne qu'avec un chemin commuté par étiquette cohérent à travers l'interconnexion, ainsi qu'une distribution de route-target et un modèle de confiance que les deux côtés acceptent. Si l'une des pièces manque, le modèle n'est pas utilisé, quoi que la configuration laisse entendre.

Le troisième distribue la joignabilité des PE étiquetés tandis que les routes VPN circulent entre points d'extrémité ou réflecteurs de routes à travers les AS. Chacun des trois laisse un travail différent à la frontière, et mélanger le plan de contrôle de l'un avec les hypothèses d'interface d'un autre est l'échec classique. Ce décalage se manifeste généralement par une étiquette qui semble correcte d'un côté et disparaît de l'autre.

Lire un préfixe de bout en bout

Prenez un seul préfixe client autorisé et parcourez-le. Regardez ce qui a été annoncé, ce qui est arrivé, le prochain saut, l'étiquette et la politique d'importation qui l'a admis. Examinez ensuite comment le routeur résout le transfert vers ce prochain saut, car c'est là qu'une étiquette devient un paquet. Sautez l'une des deux moitiés et vous décrivez un plan de contrôle qui ne fait peut-être pas circuler le trafic. Les deux lectures n'ont de sens qu'ensemble.

Le numéro est local. Il ne signifie quelque chose que par rapport au routeur qui l'a attribué et au chemin qui transporte les paquets jusque-là, ce qui explique qu'une même valeur puisse apparaître deux fois avec deux sens différents. Comparez-la avec ce que le côté récepteur dit avoir reçu.

Une étiquette est locale, et la promesse aussi

La capacité se vérifie aux deux extrémités de l'interconnexion, pas à une seule. Une commande sur votre interface ne change rien à l'interface du fournisseur voisin, et une route que BGP a acceptée n'engage pas à elle seule le voisin à transmettre un paquet étiqueté.

Le RFC 4364 limite le peering VPNv4 étiqueté à des arrangements de confiance et met en garde contre l'acceptation d'étiquettes qui n'ont jamais été annoncées à ce pair. C'est une déclaration de sécurité autant que de protocole. Gardez la relation de routage de l'internet public à l'écart de l'échange de routes VPN privées. Si l'interconnexion est de l'IP simple, n'attendez pas qu'une étiquette y survive. Et lorsque la liaison est étiquetée, confirmez que l'étiquette de transport externe est correctement commutée à chaque saut.

Une étiquette qui semble correcte d'un côté et disparaît de l'autre est généralement ce décalage, pas un bug de routage.

Ce qu'il faut noter à la recette

La recette est un test de paquet, pas une revue de table. Suivez un paquet client jusque dans le VRF distant et suivez sa réponse en retour, puis notez quel modèle applique le raccordement. Ajoutez les responsables du raccordement des deux côtés et précisez si la frontière transporte de l'IP simple ou du trafic étiqueté.

Cette note permet au prochain opérateur de lire correctement le même affichage d'étiquettes. Sans elle, le modèle est déduit de la configuration, et les hypothèses déduites sont la façon dont la même erreur se répète. La section inter-AS du RFC 4364 est l'endroit où déterminer quel modèle était prévu.