Clúster de SRX1500 por fibra oscura: el puerto HA CONTROL se queda apagado con el SFP-LH 740-011612
Dos SRX1500 están en centros de datos separados a unos kilómetros de distancia, unidos por pares de fibra oscura que poseemos de punta a punta. Tienen que levantarse como chassis cluster, lo que significa que el enlace de control tiene que cruzar esa fibra en lugar de un cable de conexión dentro de un mismo rack.
La configuración:
- dos Juniper SRX1500, hardware idéntico
- Juniper SFP-LH 740-011612 en el puerto HA CONTROL de cada nodo
- un par de fibra oscura dedicado para el enlace de control, conectado directo
- el módulo de cobre SFP-T que venía con el chasis, usado antes en una prueba back to back
Con el SFP-LH instalado no hay absolutamente nada. Ningún LED en la jaula, ningún enlace, y el clúster nunca se forma:
> show chassis cluster interfaces
Control link status: Down
Control interfaces:
Index Interface Status
0 em0 DownLo que ya he hecho:
- moví el enlace de control al segundo par de fibra, sin cambio en ningún nodo
- intercambié los módulos entre los dos nodos, mismo resultado en ambos
- volví a poner el SFP-T como prueba de cordura, y se quedó caído hasta un reinicio completo del chasis, tras lo cual subió de inmediato
Ese último punto me preocupa más que la óptica muerta. ¿El puerto HA CONTROL de un SRX1500 acepta siquiera el SFP-LH 740-011612 o el SFP-SX 740-011613, o solo el SFP-T con el que viene? ¿Y alguien ha corrido un SFP DWDM en ese puerto y lo ha hecho funcionar?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 4
Antes de culpar a la óptica, ¿qué ve realmente el equipo en esa jaula? Publica
show chassis hardwarecon el SFP-LH insertado y verifica si aparece siquiera una línea Xcvr para ese slot, en ambos nodos. Si el módulo ni siquiera se inventaría, esto no es un problema de fibra ni de longitud de onda y ninguna cantidad de cambios de par lo va a resolver.Segunda cosa, diez minutos de trabajo: pon uno de esos módulos SFP-LH en un puerto de producción contra un par conocido y bueno. Si ahí enlaza y en la jaula HA se queda apagado, ya separaste el módulo del puerto y puedes dejar de discutir sobre la planta de fibra.
En la mitad DWDM de la pregunta hay al menos un dato: alguien corriendo óptica DWDM Champion ONE en la serie SRX1500 la tuvo funcionando. Antes de ir por ahí, confirma la longitud de onda exacta con el fabricante de la óptica o del DWDM primero, porque Juniper no necesariamente vende un módulo para eso, y ahí ya estás con óptica de terceros con todo lo que eso implica en el momento en que abras un caso.
El puerto de control HA es un animal distinto y yo no asumiría que se comporta como un puerto de producción. No hay una lista publicada de óptica para él más allá del SFP-T que viene con el chasis, y tu propia prueba dice que la jaula no se vuelve a leer en tiempo de ejecución: el módulo de cobre solo volvió tras un reinicio del chasis. Eso suena a que el puerto se inventaría al arrancar y nada lo vuelve a escanear después.
Si el clúster tiene que estar arriba pronto, mantén el transporte fuera del firewall. Termina el enlace de larga distancia en equipo que se dedica a la óptica, dale a cada SRX un enlace corto sobre el módulo que se sabe que acepta, y deja que el transporte se encargue de la longitud de onda. Menos elegante, mucho más rápido de entregar. Abre un caso de todas formas, porque el hecho de que no exista una lista de óptica soportada para ese puerto ya merece una respuesta por escrito.
Secundo la parte de no confiar en el estado del puerto en estos equipos. Tenemos un clúster de dos SRX380-POE-AC en Junos 21.4R3-S4.9 donde la falla va al revés: xe-0/0/17 y xe-0/0/18 reportan link UP con los LED encendidos y sin ninguna fibra conectada a ellos. Juniper SFP-SX 740-011613 como Xcvr 16-17, SFP+-10G-SR 740-021308 como Xcvr 18-19, ambos nodos mostrando el mismo inventario en
show chassis hardware, yshow interfaces terseinsistiendo en que las interfaces están up.Reasentar los módulos no cambió absolutamente nada. Esos puertos estaban destinados a un reth que terminamos construyendo en ge-0/0/14-15, así que a nadie le afecta, y nunca obtuve respuesta sobre si hay un PR detrás de esto. Entre eso y tu puerto de control apagado, yo no trataría el estado de la óptica en un SRX en clúster como evidencia de nada físico.
Dos notas al margen para cuando avances más por este camino.
Si al final acaba entrando una óptica DWDM en el trayecto, revisa la rejilla antes de pedir: un sintonizable de 50 GHz contra óptica fija de 100 GHz en el otro extremo es una forma bien conocida de perder una noche entera, y en Junos el canal viene de la opción de longitud de onda y no de nada que configures en la interfaz. Tampoco entres en pánico si el equipo reporta un número de canal que no coincide con lo que configuraste mientras la luz está en la longitud de onda correcta. Eso ha aparecido en sintonizables Cisco lo suficiente como para que la lectura de la CLI no sea de fiar.
Sobre el tema general de la documentación escasa para estas jaulas: misma plataforma, un módulo de cobre SRX-SFP-1GE-T enlaza sin problemas a 1 Gbps y se niega a subir a 100 Mbps, con la guía de hardware llamando a los puertos SFP 100/1000 mientras la hoja de datos del módulo dice 10/100/1000. Tampoco nadie me pudo decir cuál de los dos es verdad.