VPNv4 a-t-il besoin de MPLS dans le cœur ? Pas nécessairement

Activer la famille d’adresses VPNv4 entre deux routeurs ne crée qu’un contexte de distribution de routes, rien de plus. Elle n’installe pas de chemin de transfert et n’indique pas quelle encapsulation portera un paquet client jusqu’au point final distant. Une fois ces deux faits séparés, la question « cela nécessite-t-il MPLS dans le cœur » devient plus étroite et peut recevoir une réponse concernant le plan de données pris en charge par la plateforme.

Ce que la famille d’adresses négocie réellement

BGP multiprotocole transporte les informations d’accessibilité de la couche réseau VPNv4 sous AFI 1 et SAFI 128, et chaque entrée associe un distinguateur de route à un préfixe et à une étiquette. La session négocie que les deux interlocuteurs peuvent encoder et décoder ces informations. Ce qu’elle ne négocie pas, c’est un plan de données. Tout ce qui suit ce paragraphe concerne le transfert, et rien de tout cela n’est réglé par l’établissement de la session.

Une session réussie est donc une preuve de capacité du plan de contrôle, non du transfert. Un routeur peut détenir des milliers d’entrées VPNv4 et tout de même abandonner chaque paquet client, et c’est pourquoi les deux classes de défaillance sont confondues au départ.

Notez l’étiquette dans le NLRI. C’est une étiquette de service, liée à un préfixe à l’intérieur d’une VRF, et elle joue un rôle de transfert une fois que le paquet atteint le point final de sortie. Savoir si un dispositif de transit la lit est une décision de conception distincte.

Réception, importation et transfert sont trois étapes

Recevoir une route, être autorisé à l’utiliser et pouvoir transférer avec elle sont assurés par des parties différentes de l’équipement. BGP stocke ce qu’il entend ; la politique d’importation et la correspondance de cible de route décident quelle VRF peut la considérer ; ensuite le plan de transfert doit résoudre le prochain saut annoncé en quelque chose qu’il peut réellement pousser sur un câble.

C’est dans cette étape intermédiaire que vivent les défaillances les plus surprenantes. Une route peut être présente dans la table BGP, valide et même la meilleure, tandis que la table de routes de la VRF reste vide parce qu’aucune cible de route ne correspondait à la liste d’importation. Rien ne journalise une erreur de protocole, car aucune erreur de protocole ne s’est produite.

La dernière étape est celle où la prise en charge par la plateforme se manifeste. Un prochain saut joignable dans le sous-réseau n’est pas automatiquement résolvable comme transport de service VPN, et l’équipement peut exiger un type de tunnel précis, une opération d’étiquette précise, ou les deux. Lire l’état de résolution est plus instructif que lire le nombre de routes.

Un cœur IP peut transporter une pile qu’il ne commute jamais

La distinction à conserver est entre « le cœur n’exécute pas MPLS » et « aucune étiquette n’existe nulle part dans le service ». Ce sont des affirmations différentes, et seule la première porte sur les dispositifs de transit. La RFC 4023 définit le transport de MPLS par des tunnels IP ou GRE, et c’est le mécanisme qui rend la seconde affirmation possible sur un cœur entièrement IP.

customer packet + service label
  encapsulated in GRE, addressed to the egress tunnel endpoint
  forwarded by ordinary IP routers on the outer header
  decapsulated at the endpoint, label still meaningful

Les routeurs de transit transfèrent selon la destination IP externe et n’ont besoin ni des préfixes clients ni de la commutation d’étiquettes native. À l’extrémité distante, le tunnel externe est retiré et l’étiquette de service reprend son travail. Le cœur a déplacé une charge opaque, ce qui est exactement ce pour quoi un réseau IP est bon.

Ce que cette conception ne vous donne pas, c’est une garantie universelle. Elle ne prouve pas que chaque routeur résout chaque prochain saut VPNv4 via n’importe quelle interface GRE, et elle n’est pas une raison de supprimer une configuration MPLS native qui fonctionne. C’est un contre-exemple à l’affirmation universelle, et la question pratique reste locale à la plateforme. Consignez cette question comme une limitation de plateforme plutôt que comme une règle de protocole.

Parcourez la chaîne sur l’équipement jusqu’à ce qu’elle casse

Partez de la route reçue et arrêtez-vous à la première étape qui échoue, car les étapes suivantes ne peuvent pas être diagnostiquées tant qu’une étape antérieure est cassée. Quatre commandes couvrent l’essentiel sur une implémentation typique.

show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_A

Lisez-les comme une séquence et non comme quatre vérifications indépendantes. La première confirme que la famille est active et que le pair échange des routes ; la deuxième montre si le préfixe est arrivé avec un prochain saut utilisable ; la troisième prouve l’éligibilité à l’importation ; la quatrième montre si le plan de transfert y a lié une étiquette ou un tunnel.

Testez ensuite le chemin de la charge de travail dans les deux sens, avec une MTU qui survit à l’encapsulation. GRE ajoute des octets d’en-tête, et un chemin qui passe de petites sondes peut échouer sur des paquets de taille maximale dans un seul sens, ce qui ressemble à une défaillance d’application plutôt que de transport.

Deux notes d’exploitation bouclent la boucle. GRE est une encapsulation, pas une confidentialité, donc un réseau de transit non fiable a besoin d’un dispositif de sécurité pris en charge par-dessus plutôt que d’une supposition. Et consignez quelle encapsulation la plateforme prend réellement en charge avant la revue de conception, car cette seule réponse décide si un cœur uniquement IP est un choix valable ou un plan qui ne peut pas transférer.