SONiCのQSFP28ケージに挿したQSAアダプタ: 10G光モジュールはリンクするがDDMが出ない
SONiCを動かしているホワイトボックススイッチで、大量にある10G光モジュールを再利用していて、いくつかのQSFP28ケージにはQSAタイプのアダプタ(10GTek QSA-100A)を挿し、普通の10G SFP+モジュールを載せている。機構的にも電気的にもこれは問題ない。おかしくなるのは管理系のほう。
- スイッチ: 1Uホワイトボックス、そのプラットフォーム向けにビルドしたSONiC
- アダプタ: 10GTek QSA-100A、QSFP28ケージをSFP+に変換
- 光モジュール: 廃止したアクセススイッチから抜いた10G SFP+モジュール
- 同じ光モジュールは、別の機器のネイティブなSFP+ケージでは正常に読める
アダプタを挿したポートで見えているもの:
QSFP28 cage -> QSA-100A -> 10G SFP+
link: up, traffic passes
inventory: port still handled as a QSFP cage
DDM/DOM: nothing returned for the portここまで試したこと:
- 2台目のアダプタと2つ目の光モジュールに交換したが、まったく同じ挙動
- その組み合わせを別のQSFP28ケージに移したが、結果は同じ
- その光モジュールが別の場所のネイティブSFP+ポートでは診断情報をフルに返すことを確認済み
この診断データの欠落は、パッシブなアダプタがそもそも運べない性質のものなのか、それともスイッチのソフトウェア側の話なのか。ソフトウェア側だとしたら、直すべき場所はプラットフォーム層なのか、それとも汎用のトランシーバコードなのか。
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 7
プラットフォームのコードに誰かが潜り込む前に、話を半分に分ける質問を一つ。その同じケージにネイティブのQSFP28モジュールを挿したら、そこからは診断情報が取れるのか、それとも何を挿してもそのポートのDDMは死んでいるのか。
ネイティブのパーツが問題なく読めるなら、ケージとI2C経路は健全で、話はすべてポートドライバがアダプタ経由で届いたものをどう解釈するかに帰着する。ネイティブのパーツでも空で返ってくるなら、このスレッドの残りは読まなくていい、それはアダプタとは無関係の別の故障だ。
よく知られた、かなり地味な管理インターフェースの違いで、ここでアダプタは犯人ではない。
SFP側では2つのI2Cアドレスが使われていて、識別データは0x50、診断マップは0x51にある。QSFP系のパーツはそれを全部0x50の下にまとめ、ページを切り替えて残りにアクセスする。だから、そのケージはQSFPだと教えられたドライバは単一アドレスでページを探しに行き、0x51には何も聞きにいかない。識別情報はポートが上がる程度にはもっともらしく返ってくるが、診断情報だけは一向に解決しない。これはまさに投稿の内容そのものの形。
直すべき場所はプラットフォーム層で、光モジュールでもアダプタでもない。どのプラットフォームも自前のSfpUtil実装を持っていて、そちらの環境ではそのポートをQSFPケージではなくSFPケージとして宣言する必要がある。誰かがそれをやるまで、アダプタ経由のポートのDDM/DOMは空のまま。それさえ済めば、ネイティブのSFP+ケージと同じようにモジュールが読まれるようになる。
リンクは生きているのに診断情報の裏に何もないというのは、このポートにおいてソフトウェアが間違っているときの見え方だ。ぎりぎりの光モジュールの見え方ではない。
規格の名前を挙げておく価値がある、そうすれば違いは一目瞭然になる。SFP側はSFF-8472で、診断情報は2つ目のアドレスでアクセスする専用のメモリマップに載っている。QSFPとQSFP28はSFF-8636に従い、新しいパーツはCMISで、どちらも単一アドレスの下にページセレクトでぶら下がる形になっている。
アダプタはその橋渡しができない。あれは機構的にも電気的にもパッシブな部品で、管理系の配線はそのまま素通りし、途中で何も変換されない。だからホスト側は、1バイトでも読む前にどちらのメモリモデルが適用されるのかを教えられている必要があり、アダプタにはそれを伝える手段がない。
対比として、Dell ONIE系のハードウェアでは同じ種類の問題がもっと厳しい形で出る。407-BBRO QSAの中に407-BBOU 10GBASE-SR SFP+(SFP-10GSR-85)を入れて、S4048-ONの40GポートとS6010-ONの任意のポートに挿した。どちらもOpenSwitch OPX 3.1 dev2で動いている:
opx-ethtoolはメディアを正しく識別し、トランシーバはenabledかつqualified、admin状態もupで、対応速度は1000、10000、40000Mbpsと表示するが、それでもポートは一向に上がらない。速度、デュプレックス、オートネゴのどれをどう設定しても、デフォルトのままでも変わらない。誰かがOPXのplatform-configリポジトリにenhancement requestとして起票し、「ここでQSAを動くようにしてほしい」と書いたが、誰も答えていない。今もオープンのままだ。
ベンダーロックでも不良光モジュールでもない。そのケージは、ネットワークOSによってアダプタモードに切り替えられることが単純にないだけで、インターフェース設定をどう組み合わせてもそれは代わってくれない。
関連はしているが、この2つのケースを一緒くたにしないでほしい。元の投稿にあるのは、診断情報が欠けているだけで動いているリンクで、データパスは正常、管理系の読み出しだけがおかしく、プラットフォームのSfpUtilにパッチを当てれば直る。Dellのケースはポートがそもそも一切上がらないケースで、そのケージ用のポートプロファイルがそもそも適用されていないことが原因。これは1つ下の層の話で、それ自体の修正が必要になる。
急いで症状だけを見比べた人が、まったく無関係の理由でポートが落ちているのに、トランシーバのコードを書き直すのに丸1日費やしてしまうということも起こりうる。
「アダプタは機構ではなくソフトウェアの機能」という話のもう一つの例。OS10 10.5.2.7が動くZ9264F-ONでは、10G SFP+メディア用にQSA28アダプタを使うということは、4x10Gブレイクアウトケーブルが使うのと同じport-groupプロファイルにそのポートを入れることを意味する:
このプラットフォームのport-groupプロファイルはQSFP28ポートのペア単位で動作するので、それを適用するとペアの相方のポートが無効になる。QSA28はインターフェース1個分でしかないのに、代償はブレイクアウトと同じ形で発生し、64の使用可能ポートが32になる。OS10のユーザーガイドにもDellの光学製品スペックシートにも、シングルポートのQSAモードは書かれていない。
その機器でネイティブの10Gが大量に必要なら、あらかじめ2:1のロスを見込んで計画するか、ラックに別の10Gスイッチを立てること。
誰かがこの手のものを箱買いする前に、チェックリストに2つ加えておきたい。まず、ネットワークOSがそのプラットフォームでQSAサポートをそもそも謳っているか。謳っているなら、それを有効にする代償は何か、ポート数なのか、診断情報なのか、それとも隣のケージまで道連れにするプロファイルなのか。はまり具合が問題になることはまずなく、この手のアダプタはどれもケージに何の問題もなく挿さる。
このスレッドのケースの違いは、ソフトウェアがどこまで面倒を見てくれるかだけだ。SONiCなら自分で直せる範囲で済み、ポートをSFPとして宣言すれば診断情報は戻ってくる。上のDell系プラットフォームでは、他人が書いたプラットフォームコードを待つしかなく、アダプタや光モジュールを交換しても事態はまったく動かない。