Associer un port d’accès non étiqueté au bon VNI EVPN

Un hôte Ethernet ordinaire émet des trames non étiquetées, et la fabrique EVPN doit malgré tout les transporter dans le bon service locataire. Le port d’accès classe la trame dans un segment local, le VTEP associe ce segment à un VNI, et le point d’attachement distant présente la trame comme son hôte l’attend. Le VLAN et le VNI identifient des parties différentes de ce chemin et n’ont pas besoin de partager un numéro. Suivez le runbook ci-dessous dans l’ordre, car une erreur à n’importe quelle étape produit le même symptôme : un hôte qui émet et ne reçoit rien.

Suivre une trame à travers la fabrique

Pour un service simple basé sur VLAN, un chemin illustratif ressemble à ceci :

Host A: untagged frame
  to access port: local VLAN 110
  to VTEP A: L2VNI 50110
  to VTEP B: corresponding local service
  to access port: untagged frame to Host B

Les numéros de VLAN et de VNI sont des exemples, pas une règle. Le VLAN local est une classification d’ingress qui existe sur un seul commutateur ; le L2VNI est l’identifiant de service overlay que les deux VTEP comprennent. La spécification overlay RFC 8365 garde l’identifiant de service séparé de la manière dont un hôte est attaché, et elle nomme trois formes : basé sur VLAN, groupé et sensible au VLAN.

Configurer la classification d’ingress

L’hôte a une adresse et n’atteint rien, alors que le port lui-même apparaît. Déterminez dans quel mode d’attachement le port se trouve réellement — un port d’accès qui transporte des trames non étiquetées ou un trunk avec un VLAN natif — et configurez explicitement celui-là. Une trame non étiquetée quitte tout de même le port à l’intérieur d’un segment local nommé, et ce segment est une décision et non un effet secondaire de la plateforme. Ouvrez la configuration en cours du port et lisez la classification qu’il possède réellement, au lieu de faire confiance à un réglage par défaut du constructeur que vous n’avez jamais défini.

Sur un commutateur typique, la séquence consiste en un changement de mode et une affectation de VLAN d’accès, suivis d’une vérification que le port est réellement up et dans cet état. Si le port est un trunk, c’est le VLAN natif qui traite les trames non étiquetées, et il s’agit d’une configuration différente avec des modes de défaillance différents. Notez à la fois le mode et le VLAN avant de continuer.

show running-config interface Ethernet1/1
show interface Ethernet1/1 switchport
show vlan brief

Configurer le VTEP et la correspondance des VNI

Le VTEP ajoute l’encapsulation VXLAN et le VNI. L’hôte ne génère pas cet en-tête et n’a pas besoin de savoir que le service existe.

Associez le VLAN local au L2VNI avec la forme de commande prise en charge par la plateforme, et gardez cette correspondance cohérente aux deux extrémités du service. Un L2VNI de locataire et le L3VNI utilisé pour le routage entre sous-réseaux sont des objets différents, et mélanger leurs numéros casse le routage sans toucher au chemin L2 ; et rappelez-vous qu’une route d’underlay fonctionnelle vers le VTEP distant relève encore d’une autre couche du montage.

Si la correspondance est fausse, la trame entre quand même dans la fabrique et atterrit simplement dans le mauvais service. C’est pourquoi la vérification est une vérification de service, pas une vérification de lien.

Configurer la présentation d’egress

À l’extrémité distante, le service reçu doit être retransformé en ce que l’hôte attend : de l’Ethernet nu sur un port d’accès, un tag précis sur un trunk que vous contrôlez, et un traitement du tag interne qui correspond au modèle de service choisi. Vérifiez la liste des VLAN autorisés sur le trunk avant d’accuser l’overlay, car un tag que le trunk d’egress n’autorise pas est supprimé alors que l’overlay a déjà fait son travail. Confirmez que l’hôte distant attend la présentation qu’il reçoit plutôt que celle que votre schéma supposait.

La survie d’un tag interne est une propriété du modèle de service que vous avez choisi, donc aucun article ne peut promettre en général de le retirer ou de le conserver. Une conception qui suppose un comportement et une plateforme qui en implémente un autre passeront un test de lien et échoueront sur l’application.

Lisez ensemble l’apprentissage MAC local, la route de service EVPN et la correspondance du point d’attachement distant, et pilotez la découverte de voisins dont l’application a besoin plutôt qu’un simple ping. Une adresse MAC apprise dans un autre domaine de pont peut y être parfaitement valide et pointer malgré tout vers le mauvais service.

Vérifier avec une seule paire d’hôtes

Montez une paire d’hôtes et prouvez le chemin complet avant d’ajouter une seconde paire. Lisez ensuite l’état sur les deux VTEP et confirmez que le même identifiant de service apparaît aux deux extrémités.

show mac address-table vlan 110
show bgp l2vpn evpn
show nve peers

Pour chaque extrémité, notez quatre valeurs : la présentation du port, le segment local, le L2VNI et la présentation inverse en egress. Cette trace permet à l’ingénieur suivant de comprendre pourquoi l’hôte dispose d’une simple connexion non étiquetée alors que la fabrique transporte un service locataire. Si un changement échoue, remettez le port dans son VLAN précédent et retestez la même paire, afin que le retour arrière soit un état connu et non une supposition.