Un Lenovo RackSwitch G8124E rechaza un SFP+ 10G SR genérico con UNAPPROVED - SR SFP+ is DISABLED
Sacamos un par de G8124E de un rack dado de baja y los estoy reconstruyendo como la capa de agregación de un entorno de pruebas interno. El presupuesto para ópticos de marca es cero, así que todo entra con módulos 10G SR genéricos del tipo que ya usamos en otros lados.
- Lenovo RackSwitch G8124E, chasis con marca ex-IBM
- 10G SR SFP+ genérico, dúplex LC, mismo lote que los que funcionan en nuestro top-of-rack de producción
- patch OM3 a una NIC de servidor que enlaza a 10G con ese mismo tipo de módulo
El puerto cobra vida un momento y luego el switch lo apaga:
UNAPPROVED - SR SFP+ is DISABLEDDespués de eso el enlace nunca se establece y el puerto se queda caído.
Lo que ya probé:
- moví el módulo por cuatro jaulas distintas, mismo mensaje cada vez
- probé un segundo módulo del mismo lote y un tercero de otro proveedor
- revisé la configuración de la interfaz buscando algo como un ajuste allow-unsupported y no encontré nada
¿Hay alguna forma de hacer que este equipo acepte ópticos de terceros, o la comprobación de aprobación solo se satisface con módulos con código Lenovo?
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
Antes de que nadie te dé un comando, ¿qué reporta
show version? En esta familia el remedio no es un solo comando, se divide por rama de código: lo que haces en una imagen 7.x no es lo que haces en 8.x, así que primero hay que establecer la versión.También di si los módulos son genéricos simples o llevan una cadena de fabricante reconocible en la EEPROM. El firmware califica cada módulo por esa cadena, y a gente con SFP+ con código Intel en este mismo switch también le sale la advertencia de transceptor no aprobado, así que el mensaje solo no dice mucho sobre el óptico en sí.
show versionlo ubica en una imagen 7.x, así que es la rama más antigua y no la actual.Los módulos son genéricos simples, sin código Intel ni Cisco, se identifican como el OEM que los fabricó. También puse el tercer módulo en un IBM RackSwitch G8124 al lado y obtuve el mismo comportamiento ahí, así que no es una jaula mala ni un óptico malo aislado.
En las ramas más antiguas hay una variable del boot loader que apaga la comprobación de aprobación. Está documentada para 5.x, 6.x, 7.x y 8.3.x o inferior, así que un equipo 7.x entra en ese rango.
Necesitas la consola serie para esto, el puerto mini-USB RS232, no la red. Reinicia el switch y mantén Shift+M durante la prueba de memoria hasta que el boot loader te dé el prompt
=>, luego:El valor distingue mayúsculas,
Overridecon O mayúscula. Ejecutaprintenvantes debootpara poder ver realmente que la variable se guardó. Una vez que el switch termina de arrancar deja de deshabilitar los módulos SFP+ no aprobados y los puertos simplemente suben.Dos advertencias. Esto es una medida de laboratorio y de emergencia, Lenovo no da soporte a ópticos de terceros y nada de esto es oficial. Y mantente lejos de ópticos de tasa dual en estos equipos antiguos, causan problemas incluso después de quitar la comprobación.
Es la misma historia en toda la línea de switches Lenovo, no solo el G8124E. Tengo un G8272 aquí que califica un
SFP-10G-LR-SCisco-Finisar como Unapproved, muestra el puerto como Disabled y deja el enlace caído. Óptico Cisco genuino, simplemente no está en la lista de Lenovo.Del lado ThinkSystem, NE1032 y NE1032T, es CNOS en vez de ENOS, y ahí el camino es un comando de plataforma para permitir transceptores no soportados en vez del truco del boot loader. Yo mismo no lo he ejecutado, así que verifica la sintaxis en tu propio equipo antes de planear una ventana en torno a eso. El patrón de fondo no cambia: el firmware compara la cadena de fabricante de la EEPROM contra una lista y deshabilita lo que no reconoce.
Una cosa para añadir a eso: el override no necesariamente sobrevive a una actualización de firmware. Si empujas una imagen nueva y los puertos vuelven a morir, entra de nuevo por la consola serie y revisa
printenvantes de empezar a sacar módulos, la variable puede simplemente haber desaparecido.Y no trates los interruptores de desbloqueo de fabricante como confiables en general. En un Catalyst 9200 con IOS-XE 16.9.x
service unsupported-transceiverno tiene ningún efecto gracias a CSCvk03296, y lo que la gente usó en su lugar fueno errdisable recovery cause gbic-invaliden configuración global, que evitó que los puertos quedaran en err-disable y dejó correr los módulos de FS y Cables and Kits. Otro fabricante, misma lección: el ajuste documentado y el ajuste que realmente funciona no siempre son el mismo.