Comment signaler un changement de multihoming VPLS à un appareil L2 CE

Nous avons la configuration suivante:

Deux routeurs MX se connectent au même site L2. La protection / redondance de boucle se fait via le multihébergement VPLS . À l'autre extrémité se trouvent deux commutateurs (EX4200 par exemple).

Lorsque la liaison bleue échoue, les deux commutateurs et le reste de l'infrastructure L2 doivent savoir que le trafic doit maintenant passer par la liaison jaune (et par conséquent via le commutateur EX à droite).

Le problème est que la table mac jaune n'est remplie que lorsque du trafic arrive du VPLS via le lien jaune. Si aucun trafic n'est reçu d'une certaine adresse MAC, le trafic pour cette adresse sera toujours envoyé sur le lien bleu et personne ne sait que ce lien est maintenant rompu (sauf peut-être le commutateur EX sur la gauche si le lien échoue physiquement).

Je ne trouve pas de bonne solution pour résoudre ce problème.

Quelques approches:

1. Vous pouvez atténuer quelque peu l'impact en ne rendant pas le lien bleu / jaune rapide afin que le spanning-tree puisse envoyer un changement de topologie lorsque l'interface descend / monte. Lorsque l'interface ne descend pas physiquement, vous n'avez pas de chance. D'un autre côté, la solution Spanning Tree vous mordra lorsque le port reviendra. VPLS mettra le site en ligne, mais le port doit passer par les étapes d'apprentissage STP avant de transmettre le trafic.

2. Vous pouvez empiler les deux commutateurs. Cela résoudra le problème pour le reste de l'infrastructure L2 car ils envoient toujours au même commutateur (pile). La pile doit toujours savoir quand basculer vers l'autre interface de liaison montante avec l'instance VPLS active.

3. Lorsque vous effectuez une maintenance planifiée (et si vous avez une pile), vous pouvez désactiver manuellement le lien principal pour basculer sur le lien secondaire. Ensuite, vous pouvez réduire la préférence de site pour le lien désactivé sur le routeur afin que le site maintenant actif devienne le nouveau principal. Même chose lors du retour. Pas idéal et ne fonctionne pas pour les pannes imprévues.

Toute contribution sur la façon de résoudre ce problème est appréciée. (Attendre EVPN / TRILL ne compte pas.;))

1. Désactivez Portfast sur les ports orientés PE ​​(sur CE)
2. Activer RSTP sur le réseau CE
3. Privilégier le «lien bleu» avec le coût de l'interface

En travaillant cela dans ma tête, je pense qu'il devrait réagir comme suit:

Lorsque le lien bleu s'éteint, le CE cessera d'envoyer / recevoir des BPDU à partir de l'interface bleue. La minuterie de bonjour RSTP par défaut est de 2 secondes. Il attend trois hellos manqués avant d'appeler ce lien "mort". Une fois que trois hellos (6 secondes) ont été manqués, il rétablira l'arborescence STP et vieillira les adresses MAC.

Il s'agit essentiellement de l'option 1 que vous avez indiquée ci-dessus, à l'exception de la façon dont j'ai lu les commentaires et votre message d'origine, il semble que vous souhaitiez que le PE participe à STP. Je suggère de permettre au client de construire son propre arbre entre tous les CE.

Votre réseau devrait basculer en douceur et le réseau client suivrait le mouvement quelques secondes plus tard.

Cela semble trop simple pour être la réponse ... mais c'est ce que je peux voir sur la base de votre écriture.

Quel type de budget de convergence recherchez-vous?

Si vous abandonniez l'idée d'utiliser la prévention de boucle VPLS et exécutiez un siteID unique, vous pourriez revenir à STP. Vous perdriez la liaison via BPDU même en l'absence de panne de vivacité du matériel.

Ensuite, vous pouvez régler votre budget de convergence par TCN / forward-time (timeout MAC, après que TCN a été vu) ou par un plus grand marteau 'mac age-time'.
Le revers de la médaille est que vous aurez plus d'unicast inconnu dans le réseau, que vous pouvez contourner en vous assurant que le délai d'expiration ARP est inférieur ou égal à TCN / forward-time

Je ne connais probablement pas la réponse que vous cherchez, mais s'il y a une solution miracle ici, je la manque. Je ne pense pas que le projet Trill ou EVPN vous aiderait dans ce scénario, si votre VPLS ou EVPN était de bout en bout directement sur le port hôte, alors cela corrigerait cela. Mais le simple remplacement de VPLS par EVPN au cœur et le maintien d'un LAN déconnecté de chaque côté, poserait le même problème.

S'en tenir aux options que vous offrez, je suivrais personnellement # 1 sur votre liste, mais je n'utiliserais pas de ST commun. Je préfère utiliser RST (ou MST si vous avez besoin d'équilibrer la charge des VLAN sur les liaisons) car cela permet une transition rapide / plus fluide lorsqu'une liaison monte ou descend.

Cela répond à la fois aux préoccupations que vous avez pour cette approche:

1. "L'interface ne descend pas physiquement" - chaque périphérique exécutant RST génère des BPDU (plutôt que de simplement relayer) et ils sont utilisés comme keep alives. Le fait de ne pas recevoir de BPDU entraînera un vieillissement des informations.
2. "Besoin de passer par les étapes d'apprentissage STP avant de transférer le trafic" - RST est en mesure de confirmer activement qu'un port peut passer en toute sécurité à l'état de transfert sans attendre les temporisateurs.

J'envisagerais également de faire # 2 en plus car cela simplifie simplement la gestion des appareils.

Peut-être qu'un script d'événement pourrait être créé sur le MX "défaillant" pour supprimer le lien? S'il existe une sorte de transport éclairé, cela peut ne pas fonctionner.

Dans la plupart des applications sur lesquelles j'ai travaillé comme ça, nous avons eu un trafic bidirectionnel, de sorte que les MAC à supprimer qui devraient se déplacer finissent par arriver via le port de sauvegarde, et l'ancienne entrée FIB est expulsée et le nouveau port installé.

Si votre site L2 desservi par ces EX envoie uniquement du trafic, alors la seule chose que je pourrais penser serait de réduire le temps de vieillissement de la table mac à un montant acceptable.