Cómo señalizar un cambio de VPLS multihoming a un dispositivo L2 CE

Tenemos la siguiente configuración:

Dos enrutadores MX se conectan al mismo sitio L2. La protección / redundancia de bucle se realiza a través de VPLS multihoming . En el otro extremo hay dos interruptores (EX4200 por ejemplo).

Cuando el enlace azul falla, los dos conmutadores y el resto de la infraestructura L2 deben saber que el tráfico ahora debe pasar por el enlace amarillo (y, en consecuencia, a través del interruptor EX a la derecha).

El problema es que la mac-table amarilla solo se llena cuando llega tráfico del VPLS a través del enlace amarillo. Si no se recibe tráfico de una determinada dirección MAC, el tráfico de esa dirección todavía se enviará a través del enlace azul y nadie sabe que ese enlace ahora está roto (excepto quizás el interruptor EX a la izquierda si el enlace falla físicamente).

No puedo encontrar una buena solución para solucionar este problema.

Algunos enfoques:

1. Puede reducir un poco el impacto al no hacer que el enlace azul / amarillo sea rápido para que el árbol de expansión pueda enviar un cambio de topología cuando la interfaz se baja / sube. Cuando la interfaz no baja físicamente, no tienes suerte. Por otro lado, la solución spanning-tree te morderá cuando el puerto vuelva a aparecer. VPLS llevará el sitio en línea, pero el puerto debe pasar por las etapas de aprendizaje de STP antes de reenviar el tráfico.

2. Podrías apilar los dos interruptores. Esto solucionará el problema para el resto de la infraestructura L2, ya que siempre se envían al mismo conmutador (pila). Aún así, la pila necesita saber cuándo cambiar a la otra interfaz de enlace ascendente con la instancia VPLS activa.

3. Al realizar el mantenimiento planificado (y si tiene una pila), puede desactivar el enlace primario manualmente para cambiar al enlace secundario. Luego, puede reducir la preferencia del sitio para el enlace desactivado en el enrutador para que el sitio ahora activo se convierta en el nuevo primario. Lo mismo al volver a cambiar. No es ideal y no funciona para interrupciones imprevistas.

Se agradece cualquier aporte sobre cómo resolver esto. (Esperar EVPN / TRILL no cuenta.))

1. Deshabilite Portfast en los puertos orientados a PE (en CE)
2. Habilite RSTP en la red CE
3. Favorecer "Enlace azul" con costo de interfaz

Al resolver esto en mi cabeza, creo que debería reaccionar de la siguiente manera:

Cuando el enlace azul muere, el CE dejará de enviar / recibir BPDU desde la interfaz azul. El temporizador de saludo RSTP predeterminado es de 2 segundos. Espera tres saludos perdidos antes de llamar a ese enlace "muerto". Una vez que se hayan perdido tres saludos (6 segundos), restablecerá el árbol STP y envejecerá las direcciones MAC.

Esta es básicamente la opción 1 que ha indicado anteriormente, excepto la forma en que leí los comentarios y su publicación original, parece que quiere que el PE participe en STP. Estoy sugiriendo que permita al cliente construir su propio árbol entre todos los CE.

Su red debería fallar sin problemas, y la red del cliente seguiría su ejemplo unos segundos más tarde.

Esto parece demasiado simple para ser la respuesta ... pero eso es lo que puedo ver en función de su escrito.

¿Qué tipo de presupuesto de convergencia estás buscando?

Si abandona la idea de usar la prevención de bucles VPLS y ejecuta un ID de sitio único, puede volver a STP. Experimentaría la pérdida de enlace a través de BPDU incluso en ausencia de falla de vivacidad del hardware.

Luego, podría ajustar su presupuesto de convergencia por TCN / tiempo de avance (tiempo de espera de MAC, después de que se haya visto TCN) o por un "tiempo de envejecimiento mac" más grande.
Por otro lado, tendrá más unidifusión desconocida en la red, que puede solucionar al asegurarse de que el tiempo de espera de ARP sea menor o igual a TCN / tiempo de avance

Probablemente no sé la respuesta que estás buscando, pero si hay alguna bala de plata aquí, me la estoy perdiendo. No creo que trill o EVPN draft lo ayuden en este escenario, si su VPLS o EVPN estarían de extremo a extremo en el puerto host, lo solucionaría de inmediato. Pero solo reemplazar VPLS a EVPN en el núcleo y mantener la LAN desconectada en ambos lados, proporcionaría el mismo problema.

Respetando las opciones que usted proporciona, personalmente seguiría el # 1 en su lista, pero no usaría ST común. Prefiero usar RST (o MST si necesita equilibrar la carga de VLAN a través de enlaces) ya que permite una transición rápida / más suave cuando un enlace sube o baja.

Esto aborda las preocupaciones que tiene sobre este enfoque:

1. "La interfaz no se cae físicamente": cada dispositivo que ejecuta RST genera BPDU (en lugar de simplemente retransmitir) y se utilizan como dispositivos vivos. Si no recibe las BPDU, la información quedará obsoleta.
2. "Es necesario pasar por las etapas de aprendizaje de STP antes de reenviar el tráfico": RST puede confirmar activamente que un puerto puede realizar una transición segura al estado de reenvío sin esperar temporizadores.

También consideraría hacer el # 2 además, ya que esto simplemente simplifica la administración de los dispositivos.

¿Quizás se podría hacer un guión de evento en el MX "fallido" para eliminar el enlace? Si hay algún tipo de transporte iluminado, entonces eso puede no funcionar.

En la mayoría de las aplicaciones en las que he trabajado de esta manera, hemos tenido tráfico bidireccional, de modo que las MAC eliminadas que deberían moverse eventualmente ingresan a través del puerto de respaldo, y la antigua entrada de FIB se desaloja y se instala el nuevo puerto.

Si su sitio L2 servido por esos EXes solo envía tráfico, entonces lo único que podría pensar sería disminuir el tiempo de envejecimiento de la tabla mac a una cantidad aceptable.