Edgecore AS9716-32D: PDDF環境でsfputilが400G QSFP-DDモジュールをQSFP28として読んでしまう
研究室で400GスプラインとしてAS9716-32Dを2台立ち上げているところです。PDDFプラットフォーム層を積んだコミュニティ版のSONiCイメージを使っています。光モジュール自体は問題なく、対向とはリンクしていますが、スイッチが光モジュールについて表示する内容が何もかも間違っています。
- Edgecore AS9716-32D (x86_64-accton_as9716_32d-r0)
- このプラットフォーム向けのPDDF入りコミュニティ版SONiCビルド
- 最初のケージに400G QSFP-DDモジュール(NeoPhotonics製)
読み取り自体は成功していて、モジュールは一覧に出ますが、ケージはQSFP28として報告されます:
admin@sonic:~$ sfputil show eeprom
Ethernet0: SFP EEPROM detected
Identifier: QSFP28 or later
Vendor Name: NeoPhotonics崩れているのはこのidentifierの行です。これはQSFP-DD製品なので、以下のバイト列はCMISではなくSFF-8636のフィールドセットとして解読されてしまい、後続のフィールドはノイズのように見えます。
ここまで確認したこと:
- モジュール自体は健全。同じ製品を別プラットフォームで読ませると正しく表示され、対向も光を検知している
- 抜き差しや別のケージへの移動をしても変化はなく、400Gポート全部が同じ挙動
- PDDFのデバイス記述では、これらのケージはQSFP28として宣言され、optoe1に紐付けられている
この最後の点が答えの全部なのか、QSFP-DDケージには単に別のoptoeデバイスが必要なのか、プラットフォーム記述を編集するのが正しい直し方なのか、それとも上位の何かにもケージの種別を認識させる必要があるのか、どうでしょうか。
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 4
症状はそのバインディングの問題とぴったり一致していて、光モジュール側をこれ以上疑う必要はありません。
AS9716-32D向けのPDDFデバイス記述は、400GのケージをQSFP28として宣言し、optoe1に紐付けています。optoe1はQSFP+やQSFP28が使うSFF-8636のEEPROMレイアウトを公開するものなので、CMISモジュールは間違ったマップ越しに読まれ、identifier以降は全部ノイズのように見えます。表示されているポート種別は検出された結果ではなく、単に記述に書かれている通りのものです。
QSFP-DDはCMISに従い、CMISはoptoe3が担当します。直し方は、該当ケージのPDDFデバイス記述で両方のフィールドを切り替えることです。種別はQSFP28からQSFP-DDへ、ドライバはoptoe1からoptoe3へ。同じ機体で400GのNeoPhotonics製品を使って確認済みで、変更後は
sfputil show eepromがモジュールを正しく解読して返してきます。注意点が二つあります。これはプラットフォームデータなので、変更をビルドするイメージ側に入れておかないと、イメージのアップグレードで古い記述に平気で戻されます。それと、upstreamではこの変更そのものは承認されたものの、プルリクエストはマージされずにクローズされ、その作業は後の変更に取り込まれる形になったので、自分のイメージに既に入っていると決めつけないでください。まず自分のプラットフォームのデバイス記述を読めば、そもそも追いかける価値があるかどうか一分でわかります。
プラットフォームのファイルに触る前に、そのポートで
sudo sfputil show eeprom -dの生ダンプを貼ってください。バイト列は全部揃っていて解釈だけがおかしいのであれば、これはモジュールの問題ではなくバインディングの問題で、RMAの話が出る前にその切り分けに10分かける価値があります。もう半分はもうご自分で答えを出しています。optoe1はQSFP+とQSFP28で使われるSFF-8636系のものなので、CMISモジュールをそれ越しに読むとidentifier以降がぐちゃぐちゃになります。まさに貼っていただいた出力そのものです。記述がQSFP-DDケージに対してoptoe1を指定している時点で、モジュール側を疑う余地はもう残っていません。
というわけで、そのケージのうち一つ分でいいので、PDDFデバイス記述の該当行も貼ってください。ドライバのフィールドだけが間違っているのか、宣言されているケージ種別も間違っているのか、それでわかります。
それでした。ケージ種別をQSFP-DDに、ドライバをoptoe3にしてリロードしたら、
sfputil show eepromがケージをQSFP28と呼ばなくなり、モジュールも正しく解読されるようになりました。上で出ていたアップグレードの話があるので、動いているスイッチにパッチを当てるのではなく、こちらがビルドするイメージの方に変更を入れました。後で見つけた人のために正直に書いておくと、これはEEPROMの読み方が直るだけで、それ以上ではありません。このプラットフォームのトランシーバー周りには他にも独自の癖が残っていて、この箱が完全に片付いたとは言えません。
残っている癖の話が出たので、同じプラットフォームで待ち構えているものを一つ。うちのAS9716-32D (x86_64-accton_as9716_32d-r0) でSONiCのmasterビルドを動かすと、
sudo sfputil show presenceはモジュールが挿さっているポートをPresentと表示してEEPROMも問題なく読めますが、show interfaces transceiver presenceは全ポートをNot presentと報告します。Syslogにはこれが繰り返し出ます:CLI経由でEEPROMを読もうとするとRuntimeError('PddfEeprom is not Programmed')で失敗します。これは再起動後にランダムに出て、根本原因が書き込まれたのを見たことがないので、あちらで信用できるpresenceチェックはsfputilだけです。
直接関係ないですが同じあたりの話として: この二つのコマンドは202012ブランチではキー名が食い違うことでも知られていて、これは202205で整理されています。出力が中身ではなく言い回しだけ違うなら、それが原因の可能性が高いです。