ネットワーク OS の全体像

スイッチベンダーは、独自のコマンド構文、独自のトランシーバー表示方法、そして認識できないモジュールへの独自のポリシーを備えたネットワーク OS（NOS）をそれぞれ出荷しています。このページでは、実際に出会うことになる各システム、それぞれの呼び方、トランシーバーコマンドの場所、そしてサードパーティ光学部品に対して既定でどのような立場を取るかをまとめます。これにより、ベンチで読み取ったモジュールを、実際に挿入する機器と突き合わせられます。

全体像

挙動はプラットフォームとリリースごとに異なります。最後の列は目安として扱い、ベンダーのドキュメントまたはテストポートで確認してください（NOS ごとのモジュール検証方法）。

コマンド体系

NOS ごとの正確な構文はポート設定のレシピ集を、識別情報の確認方法はスイッチでの光学部品の検証を参照してください。

オープンネットワーキング

SONiC（マーチャント ASIC 上に SAI 抽象化層を重ねた Linux）と Cumulus/NVUE は、NOS をハードウェアとは別に選べるソフトウェアに変えました。光学部品について言えば、何をどう読み取るかを決めるのはベンダーポリシーではなくプラットフォームプラグインであること、CMIS 対応は SONiC のリリースに依存すること、DDM と FEC のカウンターは Linux ツールから得られること、そして互換性のテストは自分の仕事になることを意味します（互換性マトリクス）。

NOS によって見え方がどう変わるか

• 命名：種別文字列（10GBASE-LR、QSFP-100G-SR4、SFP-10G-LR）はコンプライアンスコードと PN から導かれますが、その導き方は NOS ごとに異なります（コンプライアンスコード）。
• DDM の表示：しきい値とフラグまで表示するものもあれば、値のみのものもあります。外部校正を適用するものもあれば、しないものもあります（校正）。
• CMIS の深さ：データパスを完全に制御できるものから、「LPMode を解除して様子を見る」だけのものまであります（CMIS の問題）。
• ログ出力：拒否を示すメッセージの文言（unsupported、invalid、Mod_Inv、phony）が、最も手早い切り分け手段になります（症状索引）。

CodingBox では

トランシーバーサマリーは、モジュールの識別情報を Cisco IOS、Junos、Huawei VRP、Aruba のスタイルで表示するため、ベンチでの出力がスイッチの表示と一致するかを確認できます。両者の不一致こそが、コーディングやポリシーの問題が最初に表面化する場所です。

Linux ホストの行を掘り下げた内容として、NIC ベンダー、ドライバー、それぞれのモジュールコマンドについてはNIC ツールと診断と光ポートを備えた NICを参照してください。

これらのシステムそれぞれのインターフェース命名規則と管理ポート名についてはポートの命名と LEDを、トランシーバーデータの SNMP MIB とテレメトリー経路については管理と監視を参照してください。