Genuine 160-9103-900 SFP+ comes up UCTF on a Ciena 3930 - where is the certified module list
Commissioning a 10G handoff for a customer on a 3930 that was already on site. The module is Ciena's own, pulled from our stock, and the port does come up - but the operational state is UCTF instead of Ena and the uncertified transceiver alarm sits there permanently. The acceptance test includes a clean alarm list, so I cannot hand this over as it is.
- Ciena 3930, software as it was delivered to site
- Ciena 160-9103-900 SFP+ 10G
- single-mode pair to the customer NTU, short distance
> port xcvr show
Port 1 ... Oper State: UCTFWhat I tried:
- reseated the module and moved it to another port, same result
- fitted a second 160-9103-900 from the same stock, identical UCTF
- confirmed the link forwards traffic, so this is not an optical problem
I expected a Ciena-branded module in a Ciena switch to be the one combination that never argues. How do I find out which transceiver models the running software actually certifies, and what makes the uncertified state go away?
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
That is exactly it, and it catches people out because everyone assumes the check is about the manufacturer. It is not. What the switch compares is the coding the module carries against the list of models its own software release certifies. A Ciena-built module whose model is absent from that list comes up UCTF, and a module from a compatible-optics vendor whose coding matches an entry in the list comes up clean.
So the workflow is:
Take an entry from the first command that matches the rate and reach you need, and source modules coded to it. We had the same UCTF on a 3930 and put in a ModuleTek 10G LR SFP+ coded to XCVR-S10V31, which is on the supported list - the port came up with operational state Ena and no uncertified indication, and nothing else on the switch was touched.
Caveats worth stating before a customer handover: this is a coding match, not a vendor support statement, so if the box is under contract, check what the agreement says about non-Ciena optics before you design it in. The other route is a software release that does list 160-9103-900, but on a live customer service an upgrade is usually the more expensive of the two.
Run
port xcvr show supportedand look for your model in the output. It dumps the models and line rates the release on the box is willing to certify, and that list is the only thing that counts hee - not what is stamped on the cage.Post what comes back, or at least whether 160-9103-900 appears in it. If it does not, you already have your answer, and the module being genuine Ciena has nothing to do with it. Worth saying which SAOS release the 3930 is on as well - the list is per-release, and a box that has been sitting on site for a while can easily predate a part number that later software does list.
Ran it. The list is long, but 160-9103-900 is not in it - I went through it twice. Software is whatever the box shipped with, nobody has touched the release since it was installed, and
port xcvr showstill puts the port at UCTF.So a genuine Ciena part is uncertified on a Ciena switch because this release does not list it. Not the answer I expected, but it does explain why the second module from the same stock behaved identically.
Worth adding the failure mode where coding is not the problem, because chasing coding is expensive. On an ME3600X running 15.3(1)S I had
%PHY-4-SFP_NOT_SUPPORTED: The SFP in Te0/1 is not supportedand a gbic-invalid err-disable on 10G modules.service unsupported-transceiverandno errdisable detect cause gbic-invalidchanged nothing, the modules never appeared inshow inventory,show interfaceprinted no media type at all, and an optical meter saw no light out of them. They were a dead batch - modules pulled from another ME3600 already in service worked instantly. No media type plus no Tx light means hardware, and no unlock command will save it.The other end of the scale is coding that is wrong for the platform specifically: third-party 80 km DWDM SFP+ in an ASR 9001 stayed down with a generic PID, and
transceiver permit pid alldid not rescue them, because IOS XR wanted a PID shaped like DWDM-SFP10G-xx.yy from that platform's optics matrix. The supplier recoded the batch and they came up. Your case sits in between: the coding is valid, it just is not on the release's list.