Lenovo RackSwitch G8124E refuses a generic 10G SR SFP+ with UNAPPROVED - SR SFP+ is DISABLED
We pulled a pair of G8124E out of a decommissioned rack and I am rebuilding them as the aggregation layer for an internal test environment. Budget for branded optics is zero, so everything goes in with generic 10G SR modules of the type we already run elsewhere.
- Lenovo RackSwitch G8124E, ex-IBM branded chassis
- generic 10G SR SFP+, duplex LC, same batch as the ones working in our production top-of-rack
- OM3 patch to a server NIC that links at 10G with the very same module type
The port comes alive for a moment and then the switch shuts it down:
UNAPPROVED - SR SFP+ is DISABLEDAfter that the link never establishes and the port stays down.
What I already tried:
- moved the module through four different cages, identical message every time
- swapped in a second module from the same batch and a third one from another supplier
- went through the interface config looking for something like an allow-unsupported knob and found nothing
Is there any way to make this box accept third-party optics, or is the approval check something you can only satisfy with Lenovo-coded modules?
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
Before anyone hands you a command, what does
show versionreport? On this family the remedy is not one command, it splits by code train: what you do on a 7.x image is not what you do on 8.x, so the version has to be established first.Also say whether the modules are plain generic or carry a recognisable vendor string in the EEPROM. The firmware rates each module by that string, and people with Intel-coded SFP+ in exactly this switch get the unapproved transceiver warning as well, so the message alone does not tell you much about the optic itself.
show versionputs it on a 7.x image, so the older train and not the current one.The modules are plain generic, no Intel or Cisco coding in them, they identify as the OEM that built them. I also put the third module into an IBM RackSwitch G8124 standing next to it and got the same behaviour there, so this is not one bad cage or one bad optic.
On the older streams there is a boot loader variable that switches the approval check off. It is described for 5.x, 6.x, 7.x and 8.3.x or lower, so a 7.x box is in scope.
You need the serial console for this, the mini-USB RS232 port, not the network. Reload the switch and hold Shift+M through the memory test until the boot loader gives you the
=>prompt, then:The value is case sensitive,
Overridewith a capital O. Runprintenvbeforebootso you can actually see that the variable was stored. Once the switch finishes booting it stops disabling unapproved SFP+ modules and the ports just come up.Two caveats. This is a lab and emergency measure, Lenovo does not support third-party optics and nothing here is official. And stay away from dual-rate optics on these older boxes, they cause trouble even after the check is out of the way.
It is the same story across the whole Lenovo switch line, not just the G8124E. I have a G8272 here that rates a Cisco-Finisar
SFP-10G-LR-Sas Unapproved, shows the port as Disabled and leaves the link down. Genuine Cisco optic, simply not on Lenovo's list.On the ThinkSystem side, NE1032 and NE1032T, it is CNOS rather than ENOS, and there the way in is a platform command to allow unsupported transceivers instead of the boot loader trick. I have not run that one myelf, so verify the syntax on your own box before you plan a window around it. The pattern underneath does not change: firmware compares the EEPROM vendor string against a list and disables whatever it does not recognise.
One thing to add to that: the override does not necessarily survive a firmware upgrade. If you push a new image and the ports go dead again, get back on the serial console and check
printenvbefore you start pulling modules, the variable may simply be gone.And do not treat vendor unlock switches as reliable in general. On Catalyst 9200 with IOS-XE 16.9.x
service unsupported-transceiverhas no effect at all thanks to CSCvk03296, and what people used instead wasno errdisable recovery cause gbic-invalidin global config, which kept the ports from being err-disabled and let FS and Cables and Kits modules run. Different vendor, same lesson: the documented knob and the knob that actually worrks are not always the same one.