Un CRS226 reporta no-link y sfp-rx-lose yes en un uplink SFP-10G-LR con código Cisco
Nos hicimos cargo de un sitio de agregación pequeño y uno de los uplinks de 10G no ha subido desde que se cambió el módulo que llevaba. El módulo aparece listado como incompatible con el CRS226, así que ahí es donde cayó primero la sospecha, pero las lecturas no me parecen las de un módulo rechazado.
- MikroTik CRS226 en el sitio de agregación, módulo en sfp-sfpplus1
- Fiberworks SFP-10G-LR, con código Cisco
- par monomodo hacia el sitio remoto, parcheado a través de dos paneles en el camino
/interface ethernet monitor sfp-sfpplus1
status: no-link
sfp-rx-lose: yesLa temperatura y el voltaje de alimentación en la misma salida se leen completamente normales, y el módulo está claramente detectado - esto no es una lectura de jaula vacía.
Ya hecho de nuestro lado:
- reasenté el módulo y limpié ambos conectores
- lo moví al otro puerto SFP+, salida idéntica
- revisé la configuración del puerto, nada forzado, nada deshabilitado
Así que ¿cuál es?: ¿el CRS226 está rechazando silenciosamente un módulo con código Cisco y reportándolo como no-link, o sfp-rx-lose significa lo que creo que significa y debería mandar a alguien al otro extremo?
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 5
Tu propia salida ya respondió la pregunta de compatibilidad. Un módulo que el switch hubiera rechazado no estaría reportando temperatura y voltaje en absoluto - una lectura de monitor completa significa que el CRS226 leyó el módulo y se comunica con él perfectamente bien. Y
sfp-rx-lose: yeses la propia indicación de pérdida de señal del módulo: no ve luz en la fibra de recepción. Sin luz de entrada, sin enlace, diga lo que diga el código.Así que este es un problema de planta, no de compatibilidad. El orden en que yo lo trabajaría:
Para que conste, ese mismo tipo de módulo lleva meses corriendo en un CRS226 hasta un CCR aquí, así que el emparejamiento en sí no es el problema.
¿Qué hay en el otro extremo, y ese lado muestra su puerto como arriba? Si el transmisor remoto está encendido esperarías algo de potencia de recepción en vez de una simple pérdida de señal.
Dos comprobaciones baratas antes de que alguien vaya en camión. Intercambia las dos hebras en tu panel de parcheo y mira si la bandera se queda donde está. Y haz que el otro lado lea su propio módulo: si ambos extremos reportan pérdida de recepción, el par está roto en algún punto intermedio o alguien parcheó las hebras equivocadas en uno de esos paneles.
Vale la pena mantener separados dos modos de fallo mientras estás ahí. Sin luz en absoluto es lo que tienes tú, y es el fácil. La variante más desagradable es luz que está apenas presente: uno de un par de uplinks de fibra aquí registró una alarma de Rx power low en -20.2 dBm contra un umbral de -18.4 dBm y acumuló 46 mil errores de entrada y 42 mil errores CRC mientras el enlace se mantenía nominalmente arriba.
show interface transceiver detailyshow interface counters errorscontaron esa historia.El trabajo de campo es el mismo de todos modos - limpia e inspecciona ambas caras de conector, mide TX y RX, busca un tramo demasiado largo, un empalme malo o un cable de parcheo barato, y cambia el módulo si los niveles se mantienen bajos. Nunca demostré el culpable exacto en el nuestro, así que tómalo como una dirección y no como un veredicto.
Una cosa más para la lista de comprobación del otro extremo: un receptor puede morir por sí solo sin que haya nada mal en la fibra.
Cisco tiene un aviso de campo, FN-72192, que cubre un lote de QSFP-40G-LR4 - también vendidos como QSFP-40G-LR4-S y WSP-Q40GLR4L - que salieron de fábrica con el detector de recepción ligeramente fuera de donde debería estar. El aviso afecta a módulos cuyo número de serie empieza con ACW y cuyo código de fecha cae entre ACW2415xxxx-ACW2449xxxx: en esos el lado de recepción se degrada y el enlace cae. La plataforma que nombra es la serie ASR 900. El manejo es reemplazo ante fallo, así que es una comprobación de serie y un caso de soporte más que algo que configures.
La parte que se generaliza a tu enlace: la alerta temprana es un valor de recepción en los datos DOM que se desliza constantemente hacia abajo en vez de caer de golpe. Buen argumento para graficar el DOM en cada uplink en vez de leerlo solo cuando algo ya se rompió.
Sobre confiar en las lecturas - mayormente sí, pero no a ciegas. Hubo un caso que circuló de un stick ONT GPON Huawei metido en un slot SFP+ de MikroTik, reportando una potencia de recepción muy baja con descargas estancadas por debajo de 20 Mbps en un plan mucho más rápido, y nadie llegó a establecer si la lectura o la línea eran las culpables. Se quedó abierto.
En un par LR simple como el tuyo yo tomaría la salida del monitor al pie de la letra. En módulos raros en una jaula SFP+ vale la pena una segunda lectura desde el otro extremo antes de planear un viaje en camión por eso.