ethtool -mの先にあるトランシーバEEPROM用オープンツール群: sfppi、sfpdoctor、py-sfp-eeprom、oom

仕事の半分近くは、ある会社のオプティクスを別の会社のスイッチに挿すことなので、モジュールに「自分は何者か」を尋ねることに多くの時間を使っています。そのためのツールボックスは今のところコマンド一つ分の深さしかなく、ベンチのマシンに他に何を入れておく価値があるか知りたいと思っています。

• ベンチ作業用のSFP+とQSFP28ポートを持つLinuxマシン、それに特に役立っていないRaspberry Pi
• SONiCで動くラボ用スイッチ、それに客先の機材にたまたま備わっているベンダーCLI
• SFPからQSFP-DDまでのモジュールが入った引き出し、大半は他社向けにコーディングされている

今使っているもの:

ethtool -m enp3s0f0
ethtool -e enp3s0f0
sfputil show eeprom

ベンダー側については、その機器が提供するものが何であれそれを使います。show idprom、show interfaces diagnostics optics、display transceiver、/interface ethernet monitorなどです。それらはすべて読み取り専用です。書き込みはできず、チェックサムが本当に間違っているのか単に見慣れないだけなのかも教えてくれません。

見つけたもののまだ本格的には使っていないもの:

• sfppi、Raspberry Pi用のI2Cプログラマーで、チェックサムの修正もできる
• SFF-8472ページの読み取りとモデル化用のsfpdoctorとpy-sfp-eeprom
• スイッチ向けのオープンな光学モニタリングライブラリであるOCP oom、それにsfputilの土台になっているoptoeドライバ

商用のコーダーボックスは別の判断であって、今尋ねているのはそちらではありません。まず知りたいのは、実際にベンチに置かれているオープンツールはどれかということです。どれがフォームファクタを問わずページを確実に読めるのか、どれが書き込みに使って安全なのか、そして同じ引き出しの中でSFF-8472系とCMIS系の境界がどこにあるのか。

これらを組み合わせて実用的な手順を組み立てた人はいますか。それとも今でも作業ごとに別々のツールを使うしかないのでしょうか。