Lenovo ThinkSystem NE1032 zeigt SFP+ von Drittanbietern als Unapproved und hält die Ports unten
Wir betreiben ein Paar ThinkSystem NE1032 RackSwitch als Top-of-Rack in einem kleinen Colo-Käfig. Die geerbten Lenovo-Optiken decken nur die Hälfte der Ports ab, also wurde der Rest mit generischen SFP+-Modulen und ein paar kurzen DACs aus derselben Charge aufgefüllt, die wir bei anderen Hersteller-Switches schon problemlos einsetzen.
Ausstattung:
- Lenovo ThinkSystem NE1032 RackSwitch, Standardkonfiguration bis auf die VLANs
- generische, uncodierte 10G-SFP+-Module
- zwei kurze passive DACs auf dem Inter-Switch-Link
- Lenovo-codierte SFP+ in den Nachbarports, laufen einwandfrei
Die Port-Informationen sehen bei jedem Nicht-Lenovo-Modul gleich aus:
port 17 transceiver present approval: Unapproved
port 17 link: down
Die codierten Module in den Ports daneben sind mit 10G oben, Verkabelung und Gegenstelle sind also nicht das Problem.
Bisher versucht:
- Module neu gesteckt und zwischen Ports getauscht, die Unapproved-Bewertung folgt dem Modul
- dieselben generischen Module in den Switch eines anderen Herstellers gesteckt, dort linken sie sofort mit 10G
- Port- und Interface-Konfiguration Zeile für Zeile durchgegangen, nichts unterscheidet sich von den funktionierenden Ports
Gibt es einen unterstützten Weg, den Switch dazu zu bringen, Module zu akzeptieren, die er nicht erkennt, oder ist codierte Optik kaufen die einzige Möglichkeit?
Comments 3
Diese Bewertung ist kein Urteil über die Optik. Die Firmware liest den herstellerspezifischen Bereich des Modul-EEPROM, grob Bytes 96-128, und alles, was nicht auf ihre eigene Liste passt, wird als Unapproved gestempelt, danach darf der Port nicht hochkommen. Nichts, was du an der Port-Konfiguration änderst, bewegt das.
Auf dem NE1032 gibt es einen dokumentierten Override, und zwar einen einfachen globalen Befehl:
Speichern und den Switch neu starten. Nach dem Reload werden die Module über ihre MSA-Felder angesteuert statt über die Herstellerprüfung, und generische SFP+ kommen hoch wie alles andere.
Zwei Vorbehalte. Der Befehl ist plattformspezifisch - dieselbe Schreibweise ist auf anderen Lenovo-Switches nicht garantiert, also nicht als Vorlage über den ganzen Bestand ausrollen. Und der Support zeigt bereitwillig auf die Drittanbieter-Optik, wenn du auf einem Port mit aktiviertem Override einen Case eröffnest, also ein paar codierte Module fürs Tauschtest-Regal bereithalten. Falls du den Override lieber gar nicht in der Konfiguration haben willst, sind die Alternativen echte Lenovo-Optik oder Drittanbieter-Module, die schon für Lenovo codiert bestellt werden.
Gleiches Bild quer durch die ganze Switch-Reihe, nicht nur beim NE1032. Ich habe ein Intel-codiertes SFP gesehen, das in einem RackSwitch G8124-E abgelehnt wurde, und ein Cisco-Finisar SFP-10G-LR-S in einem G8272, das dort als Disabled mit Unapproved-Bewertung und Link unten saß. Die Firmware bewertet jedes Modul zuerst gegen ihre Herstellerliste und stellt danach Fragen.
Wissenswert, bevor du auf den älteren Boxen nach demselben Befehl suchst: auf den ENOS-basierten RackSwitch-Modellen sitzt der Override im Bootloader als sfp-Override-Einstellung statt als Konfigurationsbefehl, was auf CNOS funktioniert, ist dort schlicht nicht vorhanden. Ich hatte selbst länger keinen G8124-E mehr in der Hand, um dich durch dieses Menü zu führen, also am eigenen Gerät verifizieren, bevor du ein Wartungsfenster darum herum planst.
Im Wartungsfenster durchgeführt. configure terminal, system unsupported-transceiver, exit, copy running-config startup-config, dann ein Reload - nachdem der Switch wieder da war, zeigen sich alle generischen Module normal, und beide DAC-Links stehen auf 10G. Die Port-Informationen tragen die Unapproved-Bewertung nicht mehr.
Für alle, die das später finden: der Reload war nötig, die Ports haben ihren Zustand nicht geändert, solange der Switch durchlief. Und wie vorgeschlagen haben wir zwei codierte Module ins Ersatzteilfach gelegt, damit wir einen gesunden Port nachweisen können, bevor wir irgendjemanden anrufen.