Una EX4200 reporta la EEPROM de la SFP+ como mal programada tras una actualización de Junos, mientras una MX960 sigue mostrando DOM
Tenemos unos cuantos tramos DWDM de 80 km sobre EX4200 con ópticas de terceros en ambos extremos, porque las piezas DWDM de marca nunca iban a entrar en el presupuesto. Eso funcionó bien durante años. Después de que las cajas EX pasaran a Junos 12.3, las ópticas siguen en los mismos puertos y los tramos siguen existiendo, pero el switch ha dejado de admitir que los módulos sean siquiera ópticas.
- EX4200, Junos 12.3 (DOM funcionaba bien en 11.4 en el mismo chasis)
- Integra SFPP-C51-80-10GD, SFP+ DWDM de 80 km
- MX960 en el otro extremo del mismo tramo, mismo número de pieza, DOM sigue completo
user@ex4200> show interfaces diagnostics optics xe-0/1/0
Physical interface: xe-0/1/0
Unknown cableEl log de mensajes imprime exactamente una línea al insertar el módulo: SFP+ of type 0 EEPROM is Mis Programmed.
Lo que ya he descartado:
- reasenté la óptica y la moví a otro puerto del mismo chasis, sin cambios;
- probé una EX3300 de repuesto y una QFX5100 en el laboratorio, ambas se comportan igual, así que no es una caja rota en particular;
- revisé de nuevo el otro extremo, la MX960 da diagnósticos completos para la misma pieza del mismo pedido.
¿Entonces el driver de la EX está exigiendo algo en la EEPROM que la versión anterior simplemente ignoraba? Y si es así, ¿se puede hacer algo con la óptica en sí, o es una conversación a tener con el proveedor?
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 6
Esa línea del log no es una queja genérica, es el driver diciéndote qué comprobación falló.
Los bytes 3 a 10 de la página A0 contienen los códigos de compliance del transceptor descritos en SFF-8472: los bits que indican 10GBASE-SR, LR, ER, los códigos SONET, los de Fibre Channel, etc. En este tipo de óptica los ocho bytes están a cero, por eso el mensaje lo llama tipo 0. La especificación espera que al menos un bit de ese campo esté activado; un campo de compliance todo a ceros no es una descripción de módulo válida. El código EX antiguo nunca lo miraba y pasaba directamente a analizar la página de diagnósticos; el driver más nuevo valida ese campo primero y luego se niega a tratar el módulo como una óptica de 10G conocida. De ahí el unknown cable y la falta de DOM. La línea MX no ejecuta esa comprobación en la misma ruta, que es exactamente por qué la misma pieza sigue funcionando ahí.
Compruébalo antes de discutir con nadie: entra al shell y ejecuta xcvrpeek page A0 en ese puerto, luego mira los offsets del 3 al 10. Todo ceros cierra el caso.
Repararlo en sitio es donde esto normalmente se complica. En teoría xcvrpoke reescribe esos mismos bytes. En la práctica muchos fabricantes bloquean la página A0 y la escritura devuelve EIO, y no hay nada que puedas hacer al respecto desde el lado del switch. Lo que queda es el proveedor: o bien envían ópticas programadas con códigos de compliance reales, o las envían con A0 desbloqueada para que puedas fijar los bits tú mismo. Si no pueden hacer ninguna de las dos cosas, es un problema del proveedor disfrazado de problema de Junos.
Dos cosas que conviene aclarar antes de que alguien empiece a adivinar.
Primero, la versión exacta en cada caja. Dices que la EX pasó a 12.3, pero ¿qué corre la MX960? Si sigue en una rama más antigua, las dos cajas no son realmente comparables y la diferencia todavía no te dice nada.
Segundo, ¿la pieza del lado MX es literalmente la misma SFPP-C51-80-10GD del mismo lote, o el mismo modelo de un pedido distinto? Los lotes difieren más de lo que a cualquiera le gustaría.
Publica
show interfaces diagnostics opticsde ambos extremos, más todo lo que imprime el log de mensajes al sacar y volver a insertar la óptica, no solo la línea que ya citaste.Misma pieza en ambos extremos, SFPP-C51-80-10GD, mismo pedido, números de serie consecutivos.
En la MX960,
show interfaces diagnostics opticsda el conjunto completo: temperatura, corriente de polarización del láser, TX power, RX power. En la EX4200 el mismo comando imprime la cabecera de la interfaz y luego la línea unknown cable, nada más. Reinsertar la óptica produceSFP+ of type 0 EEPROM is Mis Programmeden el log y nada más, sin importar qué puerto use.Lo que me molesta es que antes de la actualización esta misma óptica, en este mismo chasis y puerto, reportaba DOM sin quejarse ni una palabra.
Vale la pena añadir que la parte de solo lectura de esto existe también del otro lado de la valla. En Cisco,
show idprom interface <if> detailvuelca los bytes de identificación sin ninguna acrobacia de shell, lo cual es útil para revisar un lote en un switch de repuesto antes de que los módulos se acerquen a una caja Juniper.Leer es inofensivo en todas partes. Escribir desde el host es otro animal: xcvrpoke es una herramienta interna, no está soportada como forma de reparar módulos, y como se señaló, además está bloqueada por el vendor lock más o menos la mitad de las veces. Úsala para demostrar qué falla en la EEPROM, y luego entrega esa prueba a quien te vendió las ópticas.
Misma clase de problema, síntoma completamente distinto, por si alguien llega aquí desde una búsqueda.
Pusimos una SFP BiDi WDM de 1G sin marca en ge-0/0/1 de una EX4600 y la interfaz simplemente no existía. Ausente de
show interfaces terse, y cualquier comando contra ella devolvíaerror: device ge-0/0/1 not found. El log decíaOPTIC State changed for port: 0/0/1y luegoFibre channel transceiver plugged in without Fibre channel configuration!!. La EEPROM estaba codificada de forma que Junos clasificaba el módulo como transceptor Fibre Channel en vez de Gigabit Ethernet, así que nunca se creó ninguna interfaz Ethernet para él. Ninguna configuración arregla eso; un módulo correctamente codificado sí.Y no es solo el extremo barato del mercado. Hubo un lote de SFP+ de 10G de marca Citrix que hacía que los equipos NetScaler MPX y SDX registraran
*** Unsupported SFP+/SFP type !al arrancar, en piezas del propio fabricante. Las unidades buenas llevan una marca de revisión A2 en la etiqueta, las malas se devolvieron por RMA. Una mala codificación pasa en cualquier rango de precio.Confirmado, y gracias por los offsets exactos.
xcvrpeek en la página A0 muestra los offsets del 3 al 10 en cero en todas las unidades SFPP-C51-80-10GD que revisé, incluidas las que aún están en su caja. xcvrpoke devuelve directamente EIO, así que A0 está bloqueada y no hay nada que rescatar de nuestro lado.
Volví al proveedor con los offsets de bytes y la línea del log citada. Lo aceptaron y están recodificando el lote con códigos de compliance reales; las que están en la MX960 se quedan donde están, ya que en esa plataforma nada se queja. Marcando la explicación de arriba como la respuesta.