Drittanbieter-32G-FC-SFP+ im Brocade G610: Ist mit Mod_Inv endgültig Schluss
Wir nehmen einen G610 in eine bestehende Fabric auf, und es liegt noch ein Karton Nicht-Brocade-16G/32G-FC-SFP+ von einem anderen Projekt übrig. Bevor ich irgendwelche Ports darauf plane, stecke ich erst mal eines auf der Werkbank in einen freien Port, um zu sehen, was der Switch daraus macht.
- Brocade G610, Gen 6
- Drittanbieter-32G-FC-SFP+, keine Brocade-Kennzeichnung auf dem Modul
- Brocade-Optik mit 16G aus einem älteren Switch ausgebaut, zum Vergleich
- gleiches Patchkabel bei beiden Tests
switchshow
...
8 8 010800 id N32 Mod_InvDazu kommt jedes Mal beim Einstecken des Moduls ein Eintrag im System-Error-Log über einen unqualifizierten Transceiver.
Was ich versucht habe:
- Modul in einen anderen Port gesteckt und sauber am Pull-Tab eingerastet
- Kabel getauscht und bestätigt, dass der Port mit einer Markenoptik problemlos linkt
- die Fabric-OS-Dokumentation durchsucht nach irgendetwas, das ein unqualifiziertes Modul durchlässt
Gibt es einen unterstützten Weg, nicht qualifizierte Optiken in einem G610 zu betreiben, oder ist mit Mod_Inv auf dieser Plattform einfach Schluss? Das würde ich lieber jetzt wissen als erst, nachdem die Optiken auf einer Bestellung stehen.
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 4
Mod_Inv ist dokumentiertes Verhalten, kein Fehler auf deiner Werkbank. Der Hardware Installation Guide zum G610 lässt keinen Interpretationsspielraum: Ein Modul muss für Brocade-Produkte qualifiziert sein, bevor der Switch es betreibt, alles andere landet in Mod_Inv, mit einer Zeile im System-Error-Log. Ein Override ist nicht dokumentiert - kein Schalter, kein Unsupported-Optics-Modus, nichts zum Aktivieren.
Die Liste, die du vor jeder Bestellung brauchst, ist die Brocade Transceiver Support Matrix, gegliedert nach Plattform, mit sowohl Fertigungs- als auch Bestell-Teilenummern. Steht ein Teil dort nicht für den G610, plane darum herum, statt zu hoffen.
Wo du sowieso lose Optiken in der Hand hast: am Pull-Tab herausziehen, sie werden heiß; hineinschieben, bis die Verriegelung einrastet; und darauf achten, welche Seite oben liegt - in der oberen Portreihe zeigt die goldene Kontaktkante nach unten, in der unteren nach oben. Außerdem kein Kabel, das für einen anderen Transceiver-Typ gedacht ist, in den Slot zwingen: Es geht weit genug rein, um gesteckt auszusehen, und verhält sich danach genau wie ein defektes Modul.
Verstanden bei den unmarkierten, die wandern zurück in den Karton.
Womit ich nicht gerechnet habe: Eine der Brocade-beschrifteten 16G-Optiken aus dem alten Switch landet auf dem G610 ebenfalls in Mod_Inv, während die daneben liegende, identisch aussehende normal hochkommt und linkt.
sfpshowzeigt mir bei beiden einen Brocade-Vendor-Namen und eine Teilenummer, und beide funktionieren in dem Chassis, aus dem sie stammen.Das Label auf dem Modul ist also offenbar nicht die ganze Geschichte. Was wägt Fabric OS noch ab, bevor es eine Optik für qualifiziert erklärt?
Das Label ist nicht das Kriterium - die Kombination aus Teilenummer, Seriennummern-Präfix und Fabric-OS-Release ist es. Die Support-Matrix ist pro Plattform aufgebaut und hat einen langen Schwanz an Fußnoten, und genau da wohnt diese Art Überraschung.
Ein paar davon, damit du die Form der Regel siehst. Secure Optics sind der lauteste Fall: In einem SX6-Blade oder einem 7810 kommen sie unterhalb von 8.2.1e oder 8.2.2c gar nicht erst hoch, während dieselben Module überall sonst ohne jede Versionsbedingung laufen. Das 2-km-4x32G-FC-QSFP will 8.1.0b, sobald es in einem X6-ICL-Port sitzt. Danach wird es beim Seriennummer-Präfix eng - ein JDB-Präfix zwingt dich auf 9.1.1a oder 9.2.0, andere Teile auf 9.2.0c2 oder 9.2.1b, ein BAB1-Präfix auf 9.2.0 - und mehrere 64G-Teile haben jeweils ihre eigene Untergrenze: 9.0.1a, 9.1.0, 9.1.1, in einem Fall 10.0.1. Ein paar Einträge sind auf 32G/16G gedeckelt, und das FC32-64 hat seine eigenen Ausschlüsse.
Praktisch für deine zwei Module: Teilenummer und Seriennummern-Präfix aus
sfpshownehmen, das Release ausfirmwareshow, dann die Matrix-Zeile für deine Plattform lesen, bevor irgendetwas als defekt erklärt wird. Noch eine Falle in derselben Tabelle: XBR-000479 besteht auf identischen Optiken an beiden Enden.Zum Vergleich: Die Ethernet-seitigen Nachfahren derselben Brocade-Familien beantworten die Frage in einem völlig anderen Register. SLX, VDX und MLX gehören inzwischen zu Extreme, und deren Optik-Portal führt pro Familie eine Freigabeliste - Module, Adapter, Patch- und Breakout-Kabel eingeschlossen. Die Policy-Notiz ist unverblümt: Drittanbieter-Hardware, die nicht auf dieser Liste steht, bekommt weder Garantie noch Konformitätserklärung; wer eine Optik außerhalb dieser Liste betreibt, oder das Interface-Modul daneben, trägt das Risiko allein - keine Haftung, keine Serviceverpflichtung seitens Extreme. Gelistete Teile bringen Zertifizierungsunterlagen mit: CE und CDRH, EN60825-1, GR-468, FCC CFR 21 1040.10, NRTL. Was das Portal nicht sagt, ist, was eine konkrete Plattform tatsächlich mit einem nicht gelisteten Modul macht - dort ist „unsupported" also eine kommerzielle Aussage, während es auf deinem G610 in der Firmware erzwungen wird.
Bei den älteren FC-Switches - 300, 6505, 6510, 6520 - verlangt die FAQ ausdrücklich Brocade-beschriftete SFPs und begründet das mit den engeren Wellenlängen- und Parametertoleranzen bei 16G, wo ein Modul außerhalb der Spec einen Port in Fault versetzen und Anwendungen mit sich reißen kann. Das ist die Begründung des Herstellers, so wie er sie aufschreibt, keine eigene Messung.