Uso compartido de carga VLAN en enlaces Metro-E entre dos Juniper EX 4200

8

Tenemos Juniper EX 4200 como conmutador central en dos sitios conectados Cisco 2960 y Cisco 3560 (conmutadores de capa de acceso). Para las VLAN pares, un conmutador Juniper es el puente raíz y para las VLAN impares, otro conmutador Juniper es el puente raíz.

Tenemos enlaces Cox y Verizon Metro-E que conectan conmutadores centrales (Juniper EX 4200 en ambos sitios).

Quiero compartir la carga de VLAN usando VSTP pero de alguna manera no funciona como se esperaba. Quiero pasar algunas VLAN a través de COX y algunas a través de Verizon. Cuando hay algún problema con Cox, todo el tráfico de VLAN pasa a través de Verizon y viceversa. RSTP también está habilitado en ambos conmutadores Juniper.

Veo aleteo MAC en los mensajes de registro en todos los conmutadores de capa de acceso de Cisco cuando saco ambos enlaces Metro-E juntos. Cuando solo Cox está conectado, todo funciona bien. Cuando solo Verizon está conectado, todo funciona bien. Pero cuando AMBOS COX y Verizon están conectados, la red se interrumpe y veo un aleteo MAC en todos los conmutadores Cisco. Todos los conmutadores Cisco ejecutan PVST.

¿Alguien sabe lo que está sucediendo y por qué VSTP no funciona cuando los enlaces COX y VERIZON Metro-E están activos?

Actualización (09-dic-2013): =====

Basado en Juniper KBs: KB18291 y KB15138, hice lo siguiente:

  1. Habilité un vlan 50 nativo común (y apagué el vlan 1) en todos los conmutadores Juniper y Cisco y configuré los puertos troncales donde los conmutadores Cisco se conectan a Juniper para el vlan nativo. (Esto se debe a que las BPDU de árbol de expansión se intercambian a través de VLAN nativa entre Cisco y Juniper). De manera predeterminada, Cisco vlan nativo es vlan 1 y no hay vlan nativo en Juniper. Por lo tanto, Juniper no comprende las BPDU y las trata como tráfico de difusión que las inunda a la VLAN correspondiente. Debido a este STP entre Cisco y Juniper no converge.

  2. Se cambió el modo de árbol de expansión de Cisco de PVST a Rapid-PVST (Juniper recomienda cambiar el modo de árbol de expansión de Cisco de forma predeterminada: PVST a Rapid-PVST). Rapid-PVST converge bien con el protocolo de árbol de expansión Juniper "VSTP".

  3. Declaraciones de protocolo RSTP eliminadas según la documentación de Juniper

  4. Se ingresó el comando de prioridad de interfaz vstp para VLAN y VLAN nativa en conmutadores Juniper

Ahora, cuando los enlaces de Cox y Verizon están activos al mismo tiempo, veo que algunos conmutadores Cisco que cuelgan a conmutadores de núcleo de enebro en ambos sitios se caen. También veo en Juniper (usando el comando "show ethernet-switching interfaces") que algunas interfaces donde los switches Cisco están conectados están bloqueadas por STP.

¿Alguien puede descubrir lo que está sucediendo?

cisco juniper-ex metro-ethernet ciudad estrella
fuente
¿Podría agregar un diagrama que detalle su red (que detalla los dispositivos y todas las interconexiones con sus detalles relevantes)? A menudo encuentro que los diagramas realmente ayudan a diagnosticar problemas de árbol de expansión.
YLearn
De nuevo, ¿por qué te aferras a la cinta adhesiva y al camino de superpegamento? Tómese el tiempo para configurar MST correctamente, y esto nunca será un problema nuevamente.
Ricky Beam
¿Alguna respuesta te ayudó? Si es así, debe aceptar la respuesta para que la pregunta no siga apareciendo para siempre, buscando una respuesta. Alternativamente, puede proporcionar y aceptar su propia respuesta.
Ron Maupin

Respuestas:

5

Regla n. ° 1: en un entorno de proveedores mixtos, se evita el uso de protocolos propietarios del proveedor

Hay (aparentemente) varias complicaciones al intentar usar VSTP (un protocolo Juniper) con PVST (RPVST en realidad, un protocolo de Cisco), mientras que ambos ejecutan una instancia RSTP por vlan, no lo hacen exactamente de la misma manera (algo sobre vlans nativos etiquetados / sin etiquetar, etc.)

Su mejor opción sería utilizar un estándar abierto y documentado con reglas que todos obedecen. Eso sería MST (802.1s, ahora parte de 802.1q.) Por supuesto, MST es mucho más complicado de configurar. (estado allí ... complejos cientos de vlans en 4 proveedores)

Todo esto supone que los transportistas no están jugando con el tráfico. Si sigo su descripción, los enlaces de metro-e están entre los conmutadores de enebro y los cisco cuelgan de los enebros en cada sitio. Si eso es cierto, solo hay una ruta desde un cisco hacia el otro lado, por lo que las solapas mac no deberían ser posibles, a menos que haya un par de enebros en cada extremo que redondea el tráfico entre los sitios. (o hay canales de ether que no están configurados / funcionando correctamente)

Ricky Beam
fuente
Sí ... los enlaces de Metro-E están entre los conmutadores de enebro y los colgadores de Cisco cuelgan de los enebros en cada sitio. Pero aún así, las aletas MAC en todos los conmutadores Cisco cuando COX y VERIZON están activos al mismo tiempo.
starcity
2

¿Los transportistas pasan sus marcos de control L2? Muy a menudo necesita pedirles específicamente que lo hagan.

Puede verificarlo verificando sus BPDU enviadas y recibidas en ambos conmutadores cuando ambos estén activos

mellowd
fuente