Un Lenovo ThinkSystem NE1032 marca los SFP+ de terceros como Unapproved y mantiene los puertos down
Llevamos un par de unidades ThinkSystem NE1032 RackSwitch como top-of-rack en una jaula de colocation pequeña. Los ópticos de marca Lenovo que heredamos solo cubren la mitad de los puertos, así que el resto se llenó con módulos SFP+ genéricos y un par de DAC cortos del mismo lote que ya usamos sin problemas en switches de otros fabricantes.
Equipo:
- Lenovo ThinkSystem NE1032 RackSwitch, configuración de fábrica aparte de las VLAN
- módulos SFP+ de 10G genéricos sin codificar
- dos DAC pasivos cortos en el enlace entre switches
- SFP+ codificados Lenovo en los puertos vecinos, funcionando bien
La información de puerto de cada módulo no Lenovo se lee igual:
port 17 transceiver present approval: Unapproved
port 17 link: down
Los módulos codificados en los puertos de al lado están up a 10G, así que el cableado y el extremo lejano no son el problema.
Probado hasta ahora:
- reasenté los módulos y los intercambié entre puertos, la calificación Unapproved sigue al módulo
- moví los mismos módulos genéricos a un switch de otro fabricante, donde enlazan a 10G de inmediato
- repasé la configuración de puerto e interfaz línea por línea, nada difiere de los puertos que funcionan
¿Hay alguna forma soportada de hacer que el switch acepte módulos que no reconoce, o comprar ópticos codificados es la única vía?
Comments 3
Esa calificación no es un veredicto sobre el óptico. El firmware lee el área específica de vendor de la EEPROM del módulo, aproximadamente los bytes 96-128, y todo lo que no coincida con su propia lista queda marcado como Unapproved, tras lo cual el puerto no puede subir. Nada que cambies en la configuración del puerto lo va a mover.
En el NE1032 hay una anulación documentada y es un simple comando global:
Guárdalo y reinicia el switch. Después del reload los módulos se manejan por sus campos MSA en lugar de por la comprobación de vendor, y los SFP+ genéricos suben como cualquier otro.
Dos advertencias. El comando es específico de la plataforma - la misma sintaxis no está garantizada en otros switches Lenovo, así que no lo despliegues como plantilla en todo el parque. Y soporte va a señalar encantado a los ópticos de terceros si abres un caso en un puerto con esto activado, así que guarda unos cuantos módulos codificados en el estante para una prueba de sustitución. Si prefieres no llevar la anulación en la configuración en absoluto, las alternativas son ópticos Lenovo genuinos o módulos de terceros pedidos ya codificados para Lenovo.
Misma historia en toda esa línea de switches, no solo en el NE1032. He visto un SFP codificado como Intel rechazado en un RackSwitch G8124-E, y un SFP-10G-LR-S Cisco-Finisar en un G8272 quedándose como Disabled con calificación Unapproved y el enlace down. El firmware califica cada módulo contra su lista de vendors primero y pregunta después.
Vale la pena saber esto antes de buscar el mismo comando en los equipos más antiguos: en los modelos RackSwitch basados en ENOS la anulación vive en el boot loader como un ajuste sfp Override en lugar de como comando de configuración, así que lo que funciona en CNOS simplemente no está ahí. No he tenido un G8124-E en las manos lo bastante recientemente como para guiarte por ese menú, así que verifícalo en tu propio equipo antes de planificar una ventana de corte en torno a ello.
Lo ejecuté en la ventana de mantenimiento. configure terminal, system unsupported-transceiver, exit, copy running-config startup-config, luego un reload - después de que el switch volviera, todos los módulos genéricos aparecen con normalidad y ambos enlaces DAC están a 10G. La información de puerto ya no lleva la calificación Unapproved en ellos.
Para quien encuentre esto más tarde: hizo falta el reload, los puertos no cambiaron de estado mientras el switch se mantuvo arriba. Y sí pusimos dos módulos codificados en el cajón de repuestos como se sugirió, para poder demostrar que un puerto está sano antes de llamar a nadie.