Pourquoi votre L2VPN ignore le LSP RSVP-TE que vous venez de monter

Deux ingénieurs peuvent quitter la même fenêtre de maintenance persuadés que le nouveau chemin est en service, et avoir tous deux tort pour des raisons différentes. L'un a monté le LSP et supposé que le service suivrait. L'autre a laissé le service tranquille et supposé que rien n'avait changé. Un pseudowire n'utilise jamais que le transport vers lequel l'adresse de son pair se résout à cet instant, la vraie question est donc ce que cette résolution produit maintenant, et les deux conceptions y répondent différemment.

Une étiquette nomme un service, l'autre déplace un paquet

L'étiquette du pseudowire, signalée par LDP ciblé comme décrit dans la RFC 4447, indique au bord de fournisseur récepteur quel circuit d'attachement doit recevoir la trame. Elle ne dit rien de la façon dont la trame est arrivée là. L'étiquette en dessous appartient au transport, et cette pile est construite par ce qui a annoncé une joignabilité pour le loopback du pair, que ce soit LDP, RSVP-TE ou un chemin routé par segments. Comme des protocoles différents signalent les deux couches, l'une peut être saine tandis que l'autre est périmée. Cette séparation est toute la source de la confusion.

Autant le dire franchement : le pseudowire ne choisit pas le LSP. Il remet une trame au transport, et le transport décide à partir de l'adresse de destination qu'on lui a donnée.

C'est aussi pourquoi un ping propre à travers le nouveau LSP prouve si peu. Le LSP peut être actif, étiqueté et porter d'autres services pendant que votre pseudowire se résout encore par un autre prochain saut. Tant que vous n'avez pas lu la liaison, ces deux faits n'ont aucun rapport.

Option A : épingler le pseudowire à un transport choisi

Épingler signifie rendre déterministe la résolution de transport du service. Selon la plate-forme, cela prend la forme d'une politique de sélection de tunnel, d'un point de terminaison de transport explicite sur le service, ou d'une politique de route qui réécrit le prochain saut pour l'adresse du pair. Les trois font la même chose en dessous : elles forcent la résolution d'une destination sur un LSP précis. C'est ce qui rend le résultat auditable ensuite.

Le coût, c'est la portée. Une politique qui correspond à une adresse de pair touche tous les services pointés vers ce pair, pas seulement le pseudowire que vous aviez en tête.

Le repli mérite une décision avant la fenêtre de changement, pas pendant. Si le LSP épinglé tombe, soit vous laissez le service emprunter un autre chemin approuvé, soit vous le laissez s'arrêter. Une politique qui retombe discrètement sur un chemin violant une contrainte de latence ou de disjonction a transformé une panne propre en quelque chose de bien plus difficile à expliquer à quiconque.

Option B : laisser l'IGP choisir et regarder ce qui se passe

Laisser le service tranquille est une conception légitime, et souvent la meilleure. Le pseudowire suit la même résolution que tout autre trafic vers le loopback du pair, il hérite donc de la convergence de l'IGP, de la suppression de préfixes et de la redondance que le cœur offre déjà. Moins de politiques signifie moins d'endroits où une correspondance périmée peut se cacher. Le compromis est que vous ne contrôlez plus quel chemin prend le service, seulement qu'il en existe un.

Le multipath à coût égal aiguise ce compromis plus qu'il n'y paraît au premier abord. Le hachage se fait par flux, donc deux conversations dans un même pseudowire peuvent partir sur des étiquettes externes différentes.

Lisez le transfert installé avant de faire confiance à l'un ou l'autre

Commencez par l'adresse du pair plutôt que par le service. Sur Junos, show route 203.0.113.1 detail affiche le prochain saut sélectionné et l'opération d'étiquette, et show route table mpls.0 associe l'étiquette entrante à cette opération. Sur IOS XR, show mpls l2transport vc 100 detail donne l'état du pseudowire avec la pile imposée.

Confirmez le LSP que le transport utilise réellement, pas celui que nomme votre document de conception. traceroute mpls ipv4 203.0.113.1/32 sur IOS XR parcourt le chemin commuté par étiquettes et liste les étiquettes et les interfaces sortantes le long de celui-ci, ce qui est le plus proche de regarder le chemin vous-même. Répétez ensuite l'exercice depuis le bord de fournisseur distant, car la direction de retour se résout indépendamment et l'asymétrie est courante après un déploiement partiel de politiques. Un chemin juste dans un sens et faux dans l'autre est pire qu'un chemin uniformément faux, puisque la moitié de vos tests passeront.

Conservez les preuves avec l'enregistrement du service : adresse du pair, prochain saut, étiquette externe et la date à laquelle vous avez vérifié. Les politiques de route vieillissent mal, et personne ne se souvient de laquelle était en vigueur il y a deux trimestres.

Choisissez par mode de défaillance, pas par préférence

L'épinglage convient aux services dont une contrainte ne peut être exprimée par l'IGP, et aux équipes capables de maintenir la politique à chaque changement. Le laisser à l'IGP convient aux services qui doivent survivre à toute panne unique sans intervention humaine.

La question décisive est ce que vous coûte un mauvais chemin. Si un service sur le mauvais LSP se comporte seulement un peu moins bien, laissez l'IGP décider et consacrez l'effort à la supervision. Si un mauvais chemin casse un contrat, une constatation d'audit ou une exigence de disjonction, épinglez-le et écrivez le repli. Testez ensuite le repli, car un repli non testé est une supposition et non un plan. Quoi qu'il en soit, relisez la liaison installée après tout changement sur le cœur, et traitez un pseudowire qui est monté comme la preuve de rien d'autre que la signalisation fonctionne.