ConnectX-4 MCX456A-ECAT、100GBASE-LR4でCisco NCSとリンクしないがループバックは両端とも通る
キャリア向けのCisco NCSに接続する一対のラックを運用していて、100Gのサーバーアップリンクの1本が、構築時から一度も上がったことがありません。サーバーを別のパッチパネルがあるキャビネットに移しても同じ結果だったので、単発の問題として扱うのはやめました。
- Supermicroサーバー、NVIDIA/Mellanox ConnectX-4 MCX456A-ECAT、両ポートとも空き
- 汎用の100GBASE-LR4 QSFP28、シングルモード、10kmリーチ、両端に1つずつ
- 対向側のCisco NCS、部屋間はダークファイバー
行き詰まっているのはこの点です。各モジュールは自分のデバイス上ではループバックを通ります。ファイバーを同じQSFP28にそのままループバックさせると、NICはクリーンな100Gリンクを報告し、NCS側も同様です。実際の区間を間に入れると、何も出ません。
# module looped back on the NIC itself
Speed: 100000Mb/s
Link detected: yes
# same module, real span to the NCS
Speed: Unknown!
Link detected: no
すでに試したこと:
- 両方のモジュールを同じロットの予備品に交換、変化なし
- サーバーを移動し、別のパネル経由でパッチし直した
- NICベンダーにケースを開いたが、回答はファームウェアのリリースノートにある検証済みトランシーバーリストへの案内だけで、なぜループバックが通るのかは説明されなかった
ConnectX-4のLR4に、ローカルではリンクするのに実際の区間を跨ぐと絶対にリンクしないという何かがあるのでしょうか、それとも自分は見当違いのほうを追いかけているのでしょうか。
Comments 3
これは互換性の問題ではなく、経路が汚れているように読めます。
これまで交換したものは全部、すでに健全と分かっている側に属していて、だから何も変わらなかったのです。手つかずのまま残っているのは区間そのものだけです。なので経路のほうに手を付けてください:
案内された検証済みトランシーバーリストも見る価値はありますが、ループバックで問題なく上がるモジュールは、すでにNICから正しく駆動されているということです。互換性リストが説明するのは端的に拒否されるモジュールについてであって、ローカルではリンクするのに区間を跨ぐと死ぬモジュールについてではありません。
清掃で直らなければ、次はダークファイバーに光源とパワーメーターを当てること、借りられるならOTDRを使うことです。別のNICや別の光モジュールのペアを買う前に。
ループバックが証明するのは、1つのポートが自分自身の声を聞き取れるということだけです。レーザー、受信部、レート設定です。2つの部屋の間にあるガラスについては何も語っておらず、それがまさにまだテストしていない部分です。だからもう一度NICを疑う前に、実際の区間をパッチした状態で両端の数値を取ってください。NCS側のポートのRx電力はいくつで、NIC側はいくつでしょうか。区間ありの状態でRxがLow Warnのしきい値を下回っているのは、ローカルのポートよりも対向側か経路そのものを指す典型的な兆候です。Linux側では
ethtool -mで同じ値が取れるはずで、もしCannot get module EEPROM information: Input/output errorが返ってきても、それをモジュールが死んでいると読まないでください。mlx5ではたいていファームウェア側のモジュールアクセスの問題で、mst start、mst cable add、続けてmlxcablesを使えばいずれにせよ値は取得できます。清掃が正解でした。端面にスコープを当ててみたところ、両方のモジュールと両方のパッチコードが汚れていて、部屋間のパネルを通っているコードのほうがより酷い状態でした。経路上のすべてを清掃して挿し直したところ、NCSへの100Gリンクは一発で上がり、それ以来ずっと上がったままです。
ループバックの結果がずっとモジュールは正常で経路のほうがおかしいと教えてくれていたのに、あれだけ長く互換性の角度で粘っていた自分に軽く腹が立ちます。あとからここに辿り着いた人へ: ループバックが証明するのはポートであって、ファイバーではありません。