Normaliser les tags VLAN aux extrémités du pseudowire : un runbook

Définissez la trame que chaque extrémité client doit recevoir avant de toucher au pseudowire. Dans le cas simple, l’extrémité CE A envoie un tag qui délimite le service et l’extrémité CE B attend des trames non taguées, et c’est à l’extrémité fournisseur que cette différence est résolue. Le tag relève d’une politique locale et non du contrat Ethernet du client, et le pseudowire transporte la trame convenue plutôt que la trame d’origine. Écrivez les deux directions avant toute configuration.

Écrire d’abord le contrat de trame

La direction aller retire un tag et la direction retour le rajoute. Si vous n’en écrivez qu’une, vous testerez un chemin fonctionnel dans une direction et vous déclarerez le circuit sain.

Gardez le contrat assez court pour être collé dans le ticket de changement : quelle extrémité envoie tagué, laquelle attend non tagué, et quelle valeur de tag délimite le service.

S’accorder sur le mode du pseudowire

La RFC 4448 distingue les modes pseudowire brut et tagué et décrit la façon dont les tags qui délimitent le service sont traités. Le mode brut peut encore transporter des tags qui appartiennent à la trame client, si bien que la distinction porte sur le rôle de service d’un tag et non sur la simple présence d’un en-tête 802.1Q. Lire le mode comme tagué ou non tagué est la façon la plus courante de mal cadrer ce travail. Convenez du mode avec le pair avant de décider des opérations nécessaires.

Vérifiez ensuite le type réel de pseudowire et les paramètres du pair. Un rattachement VLAN local et un rattachement de port distant exigent un arrangement d’interfonctionnement pris en charge, et deux instructions de réécriture locales ne prouvent pas que les types de circuit annoncés concordent.

Si les attentes en matière de control word et de MTU diffèrent, vous avez un problème de négociation qu’aucune réécriture ne corrigera. Confirmez les deux à partir de la configuration en cours du pair plutôt que du document de conception.

Appliquer les opérations de tag locales

guide de réécriture VLAN CCC de Juniper documente les opérations pop, push et swap avec des restrictions propres à la plateforme. Pour une unité taguée compatible déjà configurée, la direction illustrative est input-vlan-map pop en entrée et output-vlan-map push en sortie. Ces lignes illustrent des opérations, pas une configuration complète d’interface ou de circuit. Confirmez la plateforme et la version exactes au lieu d’appliquer partout l’exemple d’une famille d’équipements.

Les paramètres VLAN et d’encapsulation pris en charge par l’unité doivent toujours définir le tag et la classification voulus. Une instruction de réécriture sur une unité qui classe les mauvaises trames déplace le problème au lieu de le corriger.

Préservez les éventuels tags client internes exigés par le service. Pour les tags empilés, déterminez quel tag externe vous manipulez avant de retirer quoi que ce soit.

Budgéter la taille, pas seulement les tags

Incluez les tags conservés, la pile MPLS réelle et le control word dans le budget de taille. La RFC 8469 recommande un control word pour les pseudowires Ethernet, et cette recommandation modifie le budget de trame que votre plateforme l’active ou non par défaut. Réconciliez un écart de MTU au lieu de supprimer son avertissement comme réparation. Un avertissement supprimé est une panne planifiée dont on a effacé la date.

Vérifiez le même budget sur les deux extrémités fournisseur, car un côté qui ajoute un tag et l’autre qui ajoute un control word suffisent à casser une charge utile qui allait bien auparavant.

Si les chiffres ne concordent pas, changez le plan plutôt que le niveau de journalisation.

Accepter trame par trame

Pour la recette, inspectez la trame attendue à chaque rattachement client dans les deux directions. Exercez ensuite le trafic applicatif et de contrôle dont le service a réellement besoin selon le plan de test approuvé, car un ping prouve bien moins qu’une trame taguée qui arrive intacte. Consignez le contrat de trame en entrée et en sortie avec la configuration du circuit. C’est cette trace qui rend le prochain changement vérifiable.

Gardez le mode, les opérations de tag, le budget MTU et le résultat de test au même endroit, car ils ne prennent sens qu’ensemble. Les répartir sur trois tickets garantit que le prochain ingénieur redécouvrira la même contrainte.

Le circuit est terminé lorsque les deux directions correspondent au contrat écrit au départ, et non lorsque la première direction passe.