ベンダーロックと「unsupported transceiver」

もっとも多いトランシーバーのトラブルです。Cisco、Intel、HPE/Aruba、Juniper、Mellanox など、スイッチや NIC のベンダーは、モジュールが EEPROM から報告する識別文字列を確認し、認識できないモジュールを拒否またはフラグ表示します。

エンジニアが苦労の末に学ぶ重要な点があります。「unsupported」は「動作しない」という意味ではありません。ほとんどのプラットフォームでは、このステータスは単なる情報表示であり、ポートをアップさせることは可能です。

症状

有効な対策

Cisco。 すべてのポートでサードパーティ製モジュールを許可するために、次の2つのコマンドが基本設定に組み込まれるのが定番です：

service unsupported-transceiver
no errdisable detect cause gbic-invalid

プラットフォームごとの癖：一部の Catalyst 9200 のビルドでは、最初のコマンドが % Ambiguous command を返します。省略せずフルで入力してください。Nexus 9000 ではタブ補完のない隠しコマンドですが、受け付けられます。

Intel X520（Linux）。 Intel 製以外のモジュールを許可するオプションを付けてドライバーをロードします：

modprobe ixgbe allow_unsupported_sfp=1

NIC 自身の EEPROM のビットを書き換えることで恒久的に設定する方法も存在し、下記の参考資料で解説されています。NIC の EEPROM への誤った書き込みは現場で復旧できないため、慎重に扱ってください。

ASR 9000 シリーズ。 すでにアップしているポートにモジュールを挿入しても、検出されないことがあります。ポートを shut し、モジュールを挿入してから no shut してください。

根本的な解決策 — モジュールをリコーディングする。 モジュールのベンダー ID と型番を書き換え、純正モジュールとして認識させる方法です。これはまさに CodingBox が EEPROM editor で行うことで、CC_BASE/CC_EXT を再計算し、事前にバックアップを取得します。具体的な仕組みは EEPROM のリコーディングを参照してください。

誰もが繰り返す助言

各種類の純正 OEM モジュールを1つ、手元に保管しておきます。サポートチケットを起票する前にそれに差し替えれば、ベンダー側がサードパーティ製光モジュールのせいにすることができなくなります。

スイッチ側での確認

上記のいずれかを行った後は、モジュールが認識され読み取られていることを確認してください。NOS ごとのコマンドは光モジュールの検証を参照し、ベンチで CodingBox が読み取った識別情報と比較してください。

ホストが実際に比較する対象 — 名前、型番、OUI、シリアルのパターン、ベンダー署名 — と、立ち上げのどの段階で拒否するか：ベンダーフィールド、ホストが行うこと。

ベンダーごとの検証動作とオーバーライドを1つの表にまとめたもの：各 NOS のモジュール検証方法。プラットフォームが期待する正確な型番文字列：OEM 型番。NOS ごとのコマンド構文：ポート設定のレシピ。