Routage des sites MPLS : ce que le CE apprend, et de qui

Un hôte d’un site ouvre une connexion vers un serveur d’un autre, et les deux sites se trouvent derrière le même VPN MPLS de niveau 3 géré. L’hôte ne connaît que sa propre passerelle par défaut et rien d’autre, ce qui est correct. L’essentiel est que le bord client local remette le paquet à son bord opérateur, et que l’état de routage VPN de l’opérateur le livre au site qui possède le préfixe de destination.

Suivre un paquet le long du chemin est le moyen le plus rapide de voir quelle partie relève du client et quelle partie appartient au service.

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

Où s’arrête le travail de chaque saut

Le CE-A a besoin d’une route vers le LAN distant qui pointe vers son raccordement opérateur local, et non vers l’adresse WAN du site distant. L’opérateur transporte ensuite le paquet à travers son propre cœur grâce à l’état de routage VPN, et le CE-B le remet sur le LAN de destination. À aucun moment un hôte n’a besoin de comprendre les étiquettes, les VRF ou le circuit internet de l’autre côté.

L’erreur qui revient sans cesse dans les tickets est de configurer l’adresse WAN du site B comme saut suivant sur le site A. Les deux sites ont acheté le même service, donc on a l’impression qu’ils devraient être voisins. Ils ne le sont pas : un saut suivant doit être joignable via la conception de routage que vous avez réellement, et le CE distant se trouve généralement à plusieurs sauts derrière un équipement que vous n’administrez pas. Une route statique construite sur cette hypothèse apparaît comme active et ne résout vers rien, ce qui est pire qu’une route absente parce qu’elle semble correcte dans la table.

La RFC 4364 sépare l’échange entre le bord client et le bord opérateur de la distribution des routes VPN par l’opérateur, et c’est exactement la frontière dont traite ce guide. Le travail du client est d’indiquer à son bord ce qu’il peut livrer et d’accepter la joignabilité que le service propose en retour.

Ce sur quoi la remise doit s’accorder

Choisissez le mécanisme avec l’opérateur plutôt qu’autour de lui. Les routes statiques, BGP ou un accord de protocole de routage entre le CE et le PE sont tous légitimes, et OSPF dispose d’un modèle MPLS VPN défini pour cette remise. Aucun de ces choix n’est une raison de construire une adjacence OSPF entre deux bords client distants à travers un cœur opérateur non spécifié, car c’est une conception que l’opérateur n’a pas acceptée et ne peut pas prendre en charge.

Avant la mise en service d’un nouveau LAN, notez quatre choses : le préfixe, la route locale suivante sur le CE, l’annonce que l’opérateur acceptera et les routes que l’opérateur renverra. Ajoutez tout filtrage, toute limite de préfixes ou toute restriction inter-sites imposés par le contrat. Une adjacence saine est un canal d’échange d’informations, et elle ne prouve pas qu’un préfixe donné a été accepté ; la session peut être établie alors que votre nouveau sous-réseau se trouve dans un filtre.

Suivez ensuite la réponse. Le site B a besoin d’une route de retour vers le LAN source, et l’hôte côté réception a besoin de sa propre passerelle et de ses propres autorisations de service. Une route qui apparaît sur le CE-A n’établit que la moitié d’un aller-retour, et c’est pourquoi un sens d’un test ping semble sain alors que l’application échoue toujours.

Vérifiez les deux remises avant validation

Relevez l’état de routage sur les deux bords client, confirmez avec l’opérateur que les préfixes LAN prévus ont été acceptés dans le VPN, puis testez une application autorisée dans chaque sens. Les tables de routage seules ne prouvent pas que l’application fonctionne, et un test d’application seul ne vous dit pas quel plan de contrôle a échoué lorsqu’elle ne fonctionne pas.

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

Lisez les trois sorties ensemble. La première indique ce que le bord croit, la deuxième ce qu’il a appris et auprès de quel pair, et la troisième ce qu’il transmettra réellement. Un désaccord entre elles est généralement un problème de politique ou de récursion plutôt qu’une annonce manquante, et il vaut la peine d’être résolu avant de demander à l’opérateur d’enquêter. Apportez ces trois sorties à l’appel avec l’opérateur, car elles répondent à la plupart des questions qu’un ingénieur support vous poserait autrement.

Sachez ce que le service ne fournit pas

Il s’agit d’un accès routé de niveau 3. Ce n’est pas un circuit de niveau 2 qui étend les diffusions entre sites, donc les protocoles de découverte, les applications dépendantes de la diffusion et les hypothèses de segment partagé ne voyagent pas avec lui. L’impression, la navigation par noms et tout ce qui dépend d’un segment local nécessitent leur propre conception.

La séparation VPN n’est pas non plus du chiffrement. La commutation d’étiquettes garde les clients séparés à l’intérieur du réseau de l’opérateur, et elle ne rend pas la charge utile confidentielle si le contrat exige la confidentialité. Là où cela compte, l’application ou une couche superposée doit la fournir.

Enfin, gardez le modèle de service écrit à côté de la configuration de routage du site. Le prochain ingénieur qui ajoute un sous-réseau devrait pouvoir lire quels préfixes sont annoncés, qui les accepte et quel est le chemin de retour attendu : la spécification BGP/MPLS IP VPN est la référence du modèle qui sous-tend tout cela.