Originales 160-9103-900 SFP+ kommt an einem Ciena 3930 als UCTF hoch - wo ist die Liste der zertifizierten Module
Inbetriebnahme einer 10G-Übergabe für einen Kunden an einem 3930, der schon vor Ort stand. Das Modul ist Cienas eigenes, aus unserem Lager, und der Port kommt auch hoch - aber der Betriebszustand ist UCTF statt Ena, und der Alarm für unzertifizierten Transceiver steht dauerhaft an. Die Abnahme verlangt eine saubere Alarmliste, so kann ich das nicht übergeben.
- Ciena 3930, Software im Auslieferungszustand vor Ort
- Ciena 160-9103-900 SFP+ 10G
- Singlemode-Strecke zum NTU des Kunden, kurze Distanz
> port xcvr show
Port 1 ... Oper State: UCTFWas ich versucht habe:
- Modul neu gesetzt und auf einen anderen Port verschoben, gleiches Ergebnis
- zweites 160-9103-900 aus demselben Lager eingebaut, identisches UCTF
- bestätigt, dass der Link Traffic durchreicht, also kein optisches Problem
Ich hätte erwartet, dass ein Ciena-Modul in einem Ciena-Switch genau die eine Kombination ist, die nie widerspricht. Wie finde ich heraus, welche Transceiver-Modelle die laufende Software tatsächlich zertifiziert, und wodurch verschwindet der unzertifizierte Zustand?
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
Genau das ist es, und es überrascht viele, weil alle annehmen, die Prüfung drehe sich um den Hersteller. Tut sie nicht. Der Switch vergleicht die Codierung, die das Modul trägt, mit der Liste der Modelle, die die eigene Softwareversion zertifiziert. Ein Ciena-gebautes Modul, dessen Modell auf dieser Liste fehlt, kommt als UCTF hoch, und ein Modul eines Compatible-Optics-Anbieters, dessen Codierung auf einen Eintrag der Liste passt, kommt sauber hoch.
Der Ablauf ist also:
Aus der Ausgabe des ersten Befehls einen Eintrag nehmen, der zu Rate und Reichweite passt, und Module besorgen, die darauf codiert sind. Wir hatten dasselbe UCTF an einem 3930 und haben ein ModuleTek 10G LR SFP+ eingesetzt, codiert auf XCVR-S10V31, das auf der unterstützten Liste steht - der Port kam mit Betriebszustand Ena hoch, ohne Hinweis auf unzertifiziert, und sonst wurde am Switch nichts angefasst.
Vor einer Kundenübergabe lohnt es, zwei Einschränkungen zu nennen: Das ist ein Codierungsabgleich, keine Aussage des Herstellers zur Unterstützung, wenn die Box also unter Vertrag steht, erst prüfen, was die Vereinbarung zu Nicht-Ciena-Optiken sagt, bevor man damit plant. Der andere Weg ist eine Softwareversion, die 160-9103-900 listet, aber bei einem laufenden Kundendienst ist ein Upgrade meist die teurere der beiden Optionen.
port xcvr show supportedausführen und im Output nach dem eigenen Modell suchen. Das listet die Modelle und Leitungsraten, die die Version auf der Box bereit ist zu zertifizieren, und diese Liste ist das Einzige, was zählt - nicht das, was auf der Cage aufgedruckt ist.Posten, was dabei rauskommt, oder zumindest, ob 160-9103-900 darin auftaucht. Wenn nicht, ist die Antwort schon da, und dass das Modul echtes Ciena ist, spielt keine Rolle. Auch wert zu nennen, welches SAOS-Release der 3930 fährt - die Liste ist pro Release, und eine Box, die schon eine Weile vor Ort steht, kann leicht älter sein als eine Teilenummer, die spätere Software listet.
Ausgeführt. Die Liste ist lang, aber 160-9103-900 steht nicht drin - zweimal durchgegangen. Software ist das, womit die Box ausgeliefert wurde, niemand hat das Release seit der Installation angefasst, und
port xcvr showsetzt den Port weiter auf UCTF.Ein echtes Ciena-Teil ist also unzertifiziert an einem Ciena-Switch, weil dieses Release es nicht listet. Nicht die Antwort, die ich erwartet hätte, aber sie erklärt, warum das zweite Modul aus demselben Lager sich identisch verhalten hat.
Lohnt sich, den Fehlerfall zu ergänzen, bei dem die Codierung nicht das Problem ist, weil die Jagd nach Codierung teuer ist. An einem ME3600X mit 15.3(1)S hatte ich
%PHY-4-SFP_NOT_SUPPORTED: The SFP in Te0/1 is not supportedund ein gbic-invalid err-disable bei 10G-Modulen.service unsupported-transceiverundno errdisable detect cause gbic-invalidänderten nichts, die Module tauchten nie inshow inventoryauf,show interfacezeigte gar keinen Medientyp, und ein optisches Messgerät sah kein Licht aus ihnen. Das war eine tote Charge: Module aus einem anderen, bereits laufenden ME3600 funktionierten sofort. Kein Medientyp plus kein Tx-Licht heißt Hardware, und kein Freischaltbefehl rettet das.Am anderen Ende der Skala steht eine Codierung, die speziell für die Plattform falsch ist: Third-Party-80-km-DWDM-SFP+ in einem ASR 9001 blieben mit einer generischen PID unten, und
transceiver permit pid allhat sie nicht gerettet, weil IOS XR eine PID in der Form DWDM-SFP10G-xx.yy aus der Optik-Matrix dieser Plattform wollte. Der Lieferant hat die Charge neu codiert, und sie kamen hoch. Dein Fall liegt dazwischen: Die Codierung ist gültig, sie steht nur nicht auf der Liste des Release.