純正160-9103-900 SFP+がCiena 3930でUCTFになる、認定モジュールリストはどこにあるか

port xcvr show supportedを実行して、出力の中に自分の機種があるか探してください。これはこの機器のリリースが認定する意思のある機種とラインレートを吐き出すもので、意味を持つのはそのリストだけです。ケージに刻印されているものではありません。

返ってきたもの、少なくとも160-9103-900がそこにあるかどうかを貼ってください。なければもう答えは出ていて、モジュールが純正Cienaかどうかは関係ありません。3930がどのSAOSリリースなのかも教えてもらえると助かります。リストはリリースごとに違い、しばらく現地に設置されたままの機器は、後のソフトウェアならリストしている部品番号より前の時代のものである可能性が十分あります。

実行しました。リストは長いですが、160-9103-900は入っていません。2回確認しました。ソフトウェアは機器が出荷された時のままで、設置されて以来誰もリリースを触っておらず、port xcvr showは今もポートをUCTFのままにしています。

つまり純正Ciena製品がCienaのスイッチでuncertifiedになるのは、このリリースがそれをリストしていないからです。期待していた答えではありませんが、同じ在庫の2個目のモジュールが同じ挙動をした理由の説明にはなります。

コーディングが原因ではない故障パターンも付け加えておく価値があります。コーディングを追いかけるのはコストがかかるからです。15.3(1)Sを動かすME3600Xで、%PHY-4-SFP_NOT_SUPPORTED: The SFP in Te0/1 is not supportedと、10Gモジュールでgbic-invalidのerr-disableに遭遇したことがあります。service unsupported-transceiverとno errdisable detect cause gbic-invalidは何も変えず、モジュールはshow inventoryに一切出てこず、show interfaceはメディアタイプをまったく表示せず、光パワーメーターでも光は見えませんでした。これらは不良バッチで、すでに稼働中の別のME3600から抜いたモジュールは即座に動きました。メディアタイプなし、かつTx光なしはハードウェアの問題を意味し、どんなアンロックコマンドも救ってくれません。

もう一方の極端な例は、そのプラットフォーム特有の点でコーディングが間違っているケースです。ASR 9001に挿したサードパーティ製80km DWDM SFP+は汎用PIDのままdownし続け、transceiver permit pid allも救ってくれませんでした。IOS XRが、そのプラットフォームのオプティクスマトリクスにあるDWDM-SFP10G-xx.yyの形をしたPIDを求めていたからです。サプライヤーがバッチを再コードしたら上がりました。あなたのケースはその中間にあります。コーディング自体は有効ですが、単にそのリリースのリストに載っていないだけです。