Lenovo RackSwitch G8124E verweigert generisches 10G SR SFP+ mit UNAPPROVED - SR SFP+ is DISABLED
Wir haben ein Paar G8124E aus einem ausgemusterten Rack gezogen, und ich baue sie gerade als Aggregation-Layer für eine interne Testumgebung wieder auf. Budget für markengebundene Optiken ist null, also kommt überall generisches 10G-SR-Modul rein, vom Typ, den wir anderswo schon fahren.
- Lenovo RackSwitch G8124E, ex-IBM-gebrandetes Chassis
- generisches 10G SR SFP+, Duplex-LC, gleiche Charge wie die, die in unserem Produktions-Top-of-Rack laufen
- OM3-Patch zu einer Server-NIC, die mit genau demselben Modultyp bei 10G linkt
Der Port erwacht kurz zum Leben, dann legt der Switch ihn wieder lahm:
UNAPPROVED - SR SFP+ is DISABLEDDanach kommt der Link nie zustande, und der Port bleibt unten.
Was ich schon versucht habe:
- Modul durch vier verschiedene Käfige gesteckt, jedes Mal dieselbe Meldung
- ein zweites Modul aus derselben Charge und ein drittes von einem anderen Lieferanten eingesetzt
- die Interface-Config durchsucht nach so etwas wie einem allow-unsupported-Schalter und nichts gefunden
Gibt es einen Weg, diese Box dazu zu bringen, Drittanbieter-Optiken zu akzeptieren, oder lässt sich die Approval-Prüfung nur mit Lenovo-codierten Modulen zufriedenstellen?
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
Bevor dir jemand einen Befehl in die Hand drückt: Was meldet
show version? Bei dieser Familie ist die Abhilfe kein einzelner Befehl, sie splittet sich nach Code-Train: Was man auf einem 7.x-Image macht, ist nicht das, was man auf 8.x macht, also muss zuerst die Version feststehen.Sag auch, ob die Module schlicht generisch sind oder einen erkennbaren Vendor-String im EEPROM tragen. Die Firmware bewertet jedes Modul nach diesem String, und Leute mit Intel-codiertem SFP+ in genau diesem Switch bekommen die Unapproved-Transceiver-Warnung ebenfalls, die Meldung allein sagt also nicht viel über die Optik selbst aus.
show versionzeigt ein 7.x-Image, also den älteren Train und nicht den aktuellen.Die Module sind schlicht generisch, keine Intel- oder Cisco-Codierung drin, sie identifizieren sich als der OEM, der sie gebaut hat. Ich habe das dritte Modul außerdem in einen daneben stehenden IBM RackSwitch G8124 gesteckt und dort dasselbe Verhalten bekommen, das ist also nicht ein schlechter Käfig oder eine schlechte Optik.
Auf den älteren Streams gibt es eine Bootloader-Variable, die die Approval-Prüfung abschaltet. Beschrieben ist sie für 5.x, 6.x, 7.x und 8.3.x oder niedriger, eine 7.x-Box fällt also darunter.
Dafür braucht es die serielle Konsole, den Mini-USB-RS232-Port, nicht das Netzwerk. Switch neu laden und Shift+M gedrückt halten, während der Memory-Test läuft, bis der Bootloader den
=>-Prompt gibt, dann:Der Wert ist case-sensitive,
Overridemit großem O.printenvvorbootausführen, damit man wirklich sieht, dass die Variable gespeichert wurde. Sobald der Switch fertig gebootet ist, hört er auf, unapproved SFP+-Module zu deaktivieren, und die Ports kommen einfach hoch.Zwei Vorbehalte. Das ist eine Labor- und Notfallmaßnahme, Lenovo unterstützt keine Drittanbieter-Optiken, und nichts davon ist offiziell. Und Finger weg von Dual-Rate-Optiken auf diesen älteren Boxen, die machen auch nach Abschalten der Prüfung noch Ärger.
Das ist dieselbe Geschichte über die ganze Lenovo-Switch-Reihe, nicht nur beim G8124E. Ich habe hier einen G8272, der ein Cisco-Finisar
SFP-10G-LR-Sals Unapproved bewertet, den Port als Disabled zeigt und den Link unten lässt. Echte Cisco-Optik, steht einfach nicht auf Lenovos Liste.Auf der ThinkSystem-Seite, NE1032 und NE1032T, läuft CNOS statt ENOS, und dort führt ein Platform-Befehl zum Erlauben nicht unterstützter Transceiver zum Ziel statt des Bootloader-Tricks. Den habe ich selbst nicht ausgeführt, also die Syntax auf der eigenen Box verifizieren, bevor man ein Wartungsfenster darum plant. Das Muster darunter ändert sich nicht: Die Firmware vergleicht den EEPROM-Vendor-String gegen eine Liste und deaktiviert, was sie nicht erkennt.
Noch etwas zum Ergänzen: Der Override übersteht ein Firmware-Upgrade nicht zwangsläufig. Spielt man ein neues Image auf und die Ports sterben wieder, zurück auf die serielle Konsole und
printenvprüfen, bevor man anfängt, Module zu ziehen, die Variable kann einfach weg sein.Und Vendor-Unlock-Schalter generell nicht als verlässlich behandeln. Auf Catalyst 9200 mit IOS-XE 16.9.x hat
service unsupported-transceiverdank CSCvk03296 überhaupt keine Wirkung, und was Leute stattdessen benutzt haben, warno errdisable recovery cause gbic-invalidin der globalen Konfiguration, das hat die Ports vor err-disable bewahrt und FS- sowie Cables-and-Kits-Module laufen lassen. Anderer Hersteller, gleiche Lektion: Der dokumentierte Schalter und der Schalter, der tatsächlich funktioniert, sind nicht immer derselbe.