Fremd-SFP+-Optik bleibt down auf einem gebrauchten DCS-7150S-24: ist die enable3px-Flash-Datei noch eine Option?
Ich habe mir für das Lab ein paar gebrauchte Arista-Switches zugelegt und bin direkt in die Optik-Sperre gelaufen. Arista-codierte Module linken, passive DAC-Kabel linken, und alles Fremde lässt den Port down.
Das Lab-Setup:
- DCS-7150S-24, gebraucht gekauft, kein Supportvertrag und kein Account-Team im Rücken
- diverse Fremd-SFP+-Module
- passive DAC-Kabel für die kurzen Strecken im Rack
Et1 passive DAC -> link comes up
Et5 third-party SFP+ -> port stays down
Et6 Arista-coded SFP+ -> link comes upWas ich bisher herausgefunden habe:
- dass das DAC hochkommt, die Optik aber nicht, sagt mir, dass das eine Codierungsprüfung ist, kein Kabel- und kein Cage-Defekt
- es gibt einen Konfigurationsbefehl der Form
service unsupported-transceiver CUSTOMERNAME LICENSEKEY, der offensichtlich einen Key will, an den ich unmöglich rankomme - ältere Beiträge erwähnen statt eines Keys eine Marker-Datei auf dem Flash, aber ich kann nicht sagen, für welche Generation das gilt
Welcher der beiden Mechanismen ist der richtige für eine Box dieses Alters, und ist die Flash-Datei bei einem 7150S noch eine Option, oder bleibt nur noch der Key?
Comments 6
Bei dieser Generation ist es die Datei, und sie ist genauso simpel gestrickt, wie sie klingt. Aus der EOS-CLI:
Eine leere Datei, nichts drin - ihre bloße Existenz schaltet Fremdoptik nach dem Reload frei. Die Liste der Plattformen, auf denen das funktioniert, ist lang: DCS-7120T-4S, die DCS-7050-Familie und die ganze DCS-7150S-Linie, unter anderen, und jedes Modell hat ein neuestes EOS-Release, das die Datei noch respektiert, von grob 4.13.16M auf den ältesten Boxen bis zum 4.23-Train beim 7150S. Neuere Switches ignorieren die Datei komplett.
Ein 7150S-24 liegt also auf der guten Seite dieser Grenze, sofern man nicht über das hinausgegangen ist, was das Modell unterstützt. Das zuerst probieren, bevor man sich in Richtung Key-Route bewegt.
Welcher EOS-Train läuft auf diesem 7150S-24, und wurde nach dem Kauf aktualisiert? Das ist wichtig, weil die Grenze pro Plattform gilt, nicht pro Familie. Die Flag-Datei ist dokumentiert als funktionierend auf dem 7048T, dem 7120T-4S, dem 7140T-8S, den SFP+-Varianten 7124 und 7148, der 7050- und 7150S-Serie und den 7548S-LC-Linecards, aber das letzte EOS-Release, das sie noch respektiert, ist bei jedem einzelnen anders.
Wurde EOS auf einer gebrauchten Box schon aktualisiert, besteht eine gute Chance, sich selbst aus dem Trick herausaktualisiert zu haben, und dann ist die billige Lösung, einen Train zurückzugehen, statt einem Key hinterherzujagen.
EOS seit Ankunft der Box nie angefasst, sie läuft also noch auf dem Train, auf dem der Verkäufer sie gelassen hat - was sich als Glück herausgestellt hat. touch, write memory, reload gemacht - und die vorher toten Fremd-SFP+-Module kommen jetzt als ganz normale Ports hoch. Kein Key, kein Account-Team, sonst nichts nötig. Die DACs haben die ganze Zeit weiter funktioniert, wie erwartet.
Für alle, die hier mit einer neueren Box landen: Dort wird die Datei tatsächlich ignoriert, und der einzige Weg ist ein kundenspezifischer kryptografischer Key, der in der laufenden Konfiguration steht als
Der Key kommt vom Account- oder Sales-Team, nicht vom Support - der TAC ist nicht befugt, Unlock-Keys auszustellen, und schickt einen zurück zum Account Management, was eine Sackgasse ist, wenn der Switch aus dem Gebrauchtmarkt stammt.
Für Lab-Aufbauten wiederholenswert: Passive DAC-Kabel werden standardmäßig akzeptiert, egal wie der Unlock-Status aussieht. Sind die Strecken kurz genug, lässt sich die ganze Frage umgehen, indem man mit DAC verkabelt und die Optik für die Links aufhebt, die sie wirklich brauchen.
Kleine Korrektur zu "steht in der laufenden Konfiguration": Auf dem älteren Code, mit dem ich gearbeitet habe, gab es auch eine undokumentierte Variante desselben Befehls, wer also auf eine Referenz stößt, die nicht zur obigen Syntax passt: Daher kommt das, nicht von einem Tippfehler.
Meiner Erfahrung nach wirkte der Key auch ohne Reboot - die meisten Fremdoptiken fingen an zu funktionieren, direkt nachdem der Befehl eingegeben wurde, auch wenn sich ein paar Module trotzdem weigerten. Das war vor einer Weile auf Hardware, die ich nicht mehr habe, also am eigenen Gerät prüfen, bevor man ein Wartungsfenster darum herum plant.
Da dieser Vergleich jedes Mal aufkommt, wenn das Thema aufkommt: Bei Cisco IOS-XE und IOS XR sind es zwei Schritte statt einem. Der globale Befehl allein reicht nicht, man braucht auch den pro Interface, auf jedem physischen Port, der das Modul annehmen soll:
Die Zeile pro Interface ist die, die die Product-ID-Prüfung überspringt, der Port wird also zumindest versuchen, die Optik zu zünden - keine Garantie, dass das Modul dann funktioniert, nur dass die Plattform aufhört, es abzulehnen. Ich habe das auf IOS XR 5.3.3 und auf IOS-XE-Boxen gemacht.
Der Vorbehalt ist bei beiden Herstellern derselbe, und das ist der Grund, warum darüber immer wieder gestritten wird: Lässt sich ein Fehler auf einen kundenseitig verbauten Fremdtransceiver zurückführen, kann Support unter Garantie oder Vertrag verweigert werden. Fürs Lab in Ordnung, in Produktion eine Entscheidung, die man bewusst treffen sollte.