各 NOS によるモジュール検証の仕組み

「モジュール検出」から「ポートアップ」までの間に、どのネットワーク OS もモジュールの識別情報に対する検証を実行します。何を比較するか、比較が失敗したときに何をするか、管理者がそれをオーバーライドできるかは、ベンダー、プラットフォーム、リリースによって異なります——そしてこの違いこそが、トランシーバー互換性というテーマそのものです。このページでは、ベンダーの文書と現場での観測に基づき、各社の挙動を並べて示します。これにより、ベンチで読み取ったモジュールを、対象のボックスに照らして判断できるようになります。

検証対象になりうる項目

ベンダーごとの挙動

以下は最近のリリース時点で公開されているコマンドと挙動です。詳細はプラットフォームとバージョンによって異なります。

ベンダーのオーバーライドが存在する場合、それは概して現状のまま提供されるものです——モジュールは動作しますが、ベンダーはその組み合わせのサポートを約束しません。フリートに関する判断はネットワークの管理者に委ねられます（サードパーティの光モジュール）。

「ベンダー X 向けにコーディングされた」が満たすべき条件

ベンチ側の作業の詳細：ベンダーロックとコーディング、 EEPROM のリコーディング。

拒否メッセージを読む

これらの状態を確認する NOS ごとのコマンド：スイッチでの光モジュールの検証。

ソフトウェアアップグレードによる変化

ベンダーはリリース間で検証を厳しくしたり緩めたりします——新しい署名検証、新しいサポート対象光モジュールリスト、隠しコマンドの削除、DDM 処理の変更。昨日まで動いていたサードパーティ製やコーディング済みの光モジュールのフリートが、アップグレード後に errdisable になることがあります（互換性マトリクスとファームウェア）。

CodingBox では

CodingBox は、上記の各検証が読み取る正確なバイト——ベンダー名、PN、チェックサム、コンプライアンスコード、電力クラス——を表示し、code database には特定のプラットフォームクラスが受け入れる識別情報が保存されます。コーディング後は試験用ポートで確認してください——最終判断を下すのはベンチではなくスイッチです（Check transceiver）。

サーバー側に対応する内容——NIC ベンダーごとのドライバーホワイトリスト、Intel のオーバーライド、Windows と ESXi の挙動：NIC でのトランシーバー互換性。