GPONスティックDFP-34X-2C2が数十秒経ってからようやくdmesgに現れ、しかも1Gでリンクする
自社WANの終端になっているLinuxボックスで、オペレーターのONTをSFP型のGPONスティックに置き換えようとしていますが、このスティックはトランシーバとはまるで違う挙動をします。挿し込んでもケージは30秒以上黙ったままで、2回もモジュールが死んでいると思い込むほど長く、ようやくカーネルが気づいた頃にはリンクはギガビット速度に落ち着いてしまい、これでは何のための作業かわかりません。
検証環境:
- Linuxルーターボックス、カーネルのSFPレイヤーが駆動するSFPケージ、mainlineカーネル
- ODI DFP-34X-2C2 GPONスティック
- 2つ目のサンプルとしてHuawei MA5671aスティック
- 同じケージに挿すと即座に現れる普通の1Gファイバモジュール、つまりケージ自体は問題ない
$ dmesg | grep -E 'sfp|Link is'
[ 77.104] sfp sfp-p0: module ODI DFP-34X-2C2 rev sn dc
[ 79.610] eth1: Link is Up - 1Gbps/Full - flow control off試したこと:
- スティックを挿し直し、インターフェースに触る前に数分放置。この待ち時間は毎回発生し、初回の挿入だけではない
- 検出後にインターフェースをバウンスさせてみたが、ネゴシエートされたモードは何も変わらない
- MA5671aも同じように遅く現れるので、1個だけの不良サンプルではない
これは単にLinuxホスト上でのGPONスティックの挙動なのでしょうか、それとも私の側で何か間違えているのでしょうか。挿入から検出の間に実際何が起きているのでしょうか。
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
憶測が始まる前に、はっきりさせておく価値があることが2つあります。1つ目、2行のgrepではなく、挿入以降のdmesgをそのまま全部貼ってください。ケージがカーネルのSFPレイヤーの裏にあるというのは疑う理由がありませんが、あなたがフィルタで落とした行こそが、モジュールが何回プローブされたか、途中で何が諦めたか、各試行にどれだけ時間がかかったかを示しています。
2つ目、スティックが最終的に上がった後、インターフェース自体は何ができると申告していますか。申告されているモードのどこかに2500baseXは出てきますか。そしてPON側でISPが渡してきている速度は何ですか。それがギガビットプランなら、得られているリンクは正しいものであり、直すべきものは何もありません。
残念ながら想定通りの挙動で、あなたのホスト側の問題ではありません。
GPONスティックはEEPROMチップを積んだトランシーバではありません。独自のSoC上で動く小さなLinuxコンピュータがSFPの外殻に押し込まれたもので、ホストがI2C経由で読むEEPROMはそのシステムによってエミュレートされています。スティック自身のファームウェアがそれらのページを提供できるところまで起動するまで、バス上では何も応答しません。だからこそ普通のモジュールなら即座に応答するところを、あなたは数十秒も座って待つことになります。モジュールの行が出る前のあの沈黙が、まさに起動時間です。
あなたの問題のもう半分は、エミュレートされたページが申告している内容がしばしば単に間違っているということです。これらのスティックのホスト側インターフェースは2500BASE-Xですが、EEPROMは別のことを言っていて、SFPレイヤーはそれを額面通りに受け取ってギガビットモードに落ち着きます。どちらの半分もカーネル内でモジュールごとのクワークとして扱われていて、設定でどうにかできるものではなく、OEM品のDFP-34X-2C2はまさにこの理由でそうしたクワークの1つを拾っています。
あなたのサンプルがそれに当てはまるかどうかは、そのスティックが報告するベンダー文字列とパーツ文字列次第で、それはリブランド品ごとに異なります。カバーされていると思い込む前に、あなたのdmesgの行が表示している内容をクワークが一致条件としているものと比較してみてください。
そもそもなぜクワークという手法が必要なのかを念押ししておくと、SFF-8472は通常のI2Cタイミング内で応答する受動的なメモリデバイスを前提としています。話せるようになるまでに30秒の起動時間を必要とするデバイスは何も想定していないので、規格に従うホストがモジュールを見限ったり、最終的に読めたモードビットをそのまま信用したりするのは当然の権利です。
上で触れたリブランドの話が実務上の落とし穴です。マッチングはベンダー文字列とパーツ文字列で行われるので、同じ物理スティックでも別の名前で売られているとクワークに一切引っかからず、はっきりした理由もなくギガビットリンクに逆戻りします。そして起動直後すぐにモジュールが存在することに依存するものは何も組まないでください。ここでのその競争には勝ち目がありません。
スティックのベンダーがEEPROMの中身を直してくれることを期待するのも楽観的すぎます。この問題が指摘されたとき、大手ISPでさえ彼らからほとんど何の反応も得られませんでした。
同じ種類の問題はコンシューマー向けルーターにも出てきますので、少なくとも仲間はいます。Archer BE800、BE900、GE800の10G SFP+コンボポートにスティックを挿したオーナーは、支払っている2.5の代わりに1Gbit/sしか得られず、TP-Link自身がそれらのポートで動作すると報告しているスティックのリストはODI DFP-34X-2C2、Huawei MA5671A、Nokia G-010SAで、結局みんなが行き着く同じ短いパーツリストです。
そこでの最初のアドバイスはファームウェアと挿し直しで、挿し直しの部分はでたらめではなく、最後までカチッとはまっていないモジュールは実際にフォールバックします。ベータビルドは最終的にポート設定を露出させました。モデルごとに1つずつです:
そのうちのどれかがボックスに入っていれば、SFPポートのモードはtelnet経由で設定可能になります。まずインターフェースを落とし、
ip link set eth1 downといった具合です。とはいえこれはあくまで回避策であって修正ではありません。1年後にも同じ苦情が来ていて、しかもスティックの話だけではありませんでした。ある人はそのポートにJT-COM製のJT-AOC-SFP-15 AOCを挿していて、別の人はAmpcom製のパッシブ10G SFP+ DACを挿していて、どちらも1Gbit/sに留まっていました。
誰かがスティックをNICに移すことを提案する前に、もう1つの故障モードを知っておく価値があります。Intel X520とkmod-ixgbeを使ったx86上のOpenWrt 19.07では、MA5671aは単に非サポートのSFPとして拒否されます。通常のモジュール設定ファイルでallow_unsupported_sfpを設定してもそこでは全く効果がなく、そのパラメータはモジュールをロードする際に渡す必要があります:
それでもドライバはやはり拒否します。そもそもスティックのEEPROMが普通のトランシーバを記述していないので、そのフラグでは取り繕えないからです。もしNICで進めることになったら、まず普通の1000BASE-T、LXまたはSXモジュールでポート自体を検証してください。そうしないとカードとスティックを同時にデバッグすることになります。
ただしその2つを一緒くたにしないよう注意してください。allow_unsupported_sfpはixgbeの内部にあり、そのドライバが特定のオプティクスをそもそも駆動する気があるかどうかを決めるもので、ここで問題になっているのとは別の判断です。長い待ち時間と誤ったモードは、汎用のSFPレイヤーがエミュレートされたページを読んでその結果をphylinkに渡すところから来ていて、モジュールごとのクワークが座っているのはそこです。
きちんとしたSFPケージを持つボードではixgbeのフラグは存在せず、修正にもなりません。そしてX520ではクワークのリストもあなたを救ってはくれません。表面上の症状は同じでも下の層が違うので、それを混同すると無駄にドライバを作り直す羽目になります。
ついでにもう1つ線引きをしておく価値があります。ホストにスティックを見せることと、OLTにそれを受け入れさせることは独立した問題で、2つ目の方がはるかに厄介な場合があります。
setmacとOMCIクエリを使ってZTE ZXHN F601からコピーしたアイデンティティ、GPONシリアル、PLOAMパスワード、LOID、ハードウェアシリアル、ファームウェア文字列のすべてを載せたXicom DFP-34X-2C2の、よく文書化された事例があります。スティックはO5状態までレンジングしたところでそのまま止まってしまい、ONU IDは割り当てられずトラフィックもありません。O5に到達するのはレンジングがうまくいったことを意味するだけで、MIBアップロードはOLTが期待するONTプロファイルにまだ一致する必要があるからです。そのスレッドで解決策を出した人は誰もいませんでした。
ですので、ローカルで2500BASE-Xが得られたとしても、難所は終わったと思い込まないでください。オペレーターがサービスプロファイルを特定の1つのONTモデルに紐付けている場合、サードパーティ製のスティックを受け入れさせるフィールドのコピーの組み合わせは存在しないかもしれません。