Edgecore AS5114-48X(dentOS): ポート18のSFP+は認識されるがonlpdumpはRX_LOSのまま
検証用にラックにONIEボックスを何台か置いていて、そのうちの1台がdentOSを動かすEdgecore AS5114-48X-O-AC-F-EC。ポート18は隣接スイッチへの10Gリンクを担うはずなのに、プラットフォームがモジュールをはっきり認識しているにもかかわらず、まったくリンクアップしない。
- スイッチ: Edgecore AS5114-48X-O-AC-F-EC, dentOS (ARM64)
- モジュール: ポート18のIntel FTLX8571D3BCV-IT SFP+
- 対向へのデュプレックスLCパッチコード、正常に動いているポートのコードと同じロット
カーネルはこのモジュールに何の不満もなく、プラットフォーム層もそれを認識しているが、ステータスビットは別の話をしている:
kernel: ... port 18: switched to inband/10gbase-r link mode
$ onlpdump
...
sfp @ 18 = Present
Status: 0x00000004 [ RX_LOS ]
すでにやったこと:
- モジュールを挿し直し、両端のコネクタを清掃した
- 対向側でTXとRXを入れ替え、その後パッチコード自体を動作確認済みのものに丸ごと交換した
- 同じモジュールを別の空きポートに移してみたが、そこでも同じ結果だった
つまりEEPROMの読み出しは正常で、MAC側も10gbase-rに切り替わっているのに、受信側は一向に光を見ない。onlpdumpがpresenceフラグとステータスのビットマスクしか渡してくれない中で、モジュール、ファイバ設備、プラットフォームのどこに問題があるのかをどうきれいに切り分ければいいのか。
Comments 5
RX_LOSそのものは、受信側が十分な光を見ていないということしか言っていない。だから機器を疑う前に、対向側は何と言っているのか。対向ポートがDDMを出せるなら、そのTxパワーを読んでレーザーが実際に発光していてポートがshutされていないことを確認すること。両端の光モジュールの種類とファイバモードが揃っているかも知っておく価値がある。ショートリーチのモジュールとロングリーチのモジュールが向き合っている、あるいはファイバが違うというケースは、まさにこれと同じ見え方をする。
それと、ポート18で別のパートナンバーのモジュールも試したのか、それともこのモジュールをポート間で動かしただけなのか。
対向は別スイッチの10Gポートで、両端とも同じショートリーチの光モジュール。そのポートは、まさに同じパッチコードで別のモジュールを使えば問題なくリンクするので、対向のレーザーは生きていてファイバ経路もエンドツーエンドで健全。ポート18はadmin upで、コードを逆にしても結果は同じ。
厄介なのは、こちら側で観測できるものの少なさで、onlpdumpが返すのはpresenceとステータスのビットマスクだけ。dentOS側には対向と比較できるRxの数値がないので、どちら側の問題なのか分からないまま「何かが受信できていない」で止まっている。
症状から原因へ、自分ならこの順番で当たる。検出できているというのは、I2C/EEPROM経路とMAC周りの配線が正しいことしか証明しない。inband/10gbase-rについてのカーネルの行はホスト側が自分自身を設定しているだけで、光子が1つでも届いたことを意味しない。RX_LOSが立っている状態で残る容疑者は3つ、光が来ていないか入れ替わったファイバ、送信していない対向、そしてこのプラットフォームで動かない受信部。
最初の2つはすでにかなり詰めているので、ビットを集めるのはやめて数値を取りに行くこと。デジタル診断を出せるスイッチなら何でもいい。EXOSなら
show ports <port> transceiver informationで、温度、電源電圧、レーザーバイアス、TxとRxのパワーが得られ、モジュールの閾値を外れた値にはすべてフラグが立つ。debug hal show optic port <port>を足せば、EEPROMからベンダー、パートナンバー、シリアル、コネクタ、波長も分かる。自分はX460-G2-24x-10G4で死んだ10Gポートをこの方法で追いかけて、受信側でおよそ-26.78dBmという値を見つけたことがある。これでは10Gのショートリーチもロングリーチの受信部もロックできない。こちらのモジュールが送信している間に対向がRxの値を出せるなら、少なくとも対向のレーザーが動いているかどうかは分かる。それが済んだあとに残るのは、プラットフォームがこの特定のパーツをうまく扱えていないという可能性。
こちらも同じ機種で、このプラットフォームではモジュールのサポートは規格単位ではなくパーツ単位になっている。うちのAS5114-48XではAvago AFBR-703SDZ-IN2 rev G2.3が何の調整もなしにリンクアップする、プラットフォームはこれをシリアルAA1329A5UTAのIntel Corpとして報告してくるので、最初に見た人は混乱する。
同じスイッチ、同じファイバで一度も動かなかったパーツが2つある。そちらが持っているIntel FTLX8571D3BCV-IT rev Aと、OPNEXT TRS5020EN-S301。どちらも検出はされるが、どちらもそちらのポート18とまったく同じ状態で止まる。ファイバ設備にもう一晩費やす前に、動作確認済みのパーツを借りてみること。
そのビットについては正確に言っておく価値がある。RX_LOSはSFF-8472で定義されたモジュール自身のloss-of-signal出力で、プラットフォーム層はそれをstatus 0x00000004としてそのまま出しているだけ。これは受信部のLOS閾値を下回ると立つので、「光が足りない」ということしか教えてくれず、理由は一切語らない。だからこそ、EEPROMの読み出しが完全にきれいなのと、光の経路が死んでいるのが矛盾なく両立する。
実測のRx値にこだわるべきもう一つの理由は、CLIから見ると減衰と非互換がまったく同じに見えること。同僚のところではZyxelのポートが-25.69dBm前後になっていたことがあり、直った原因はモジュールではなく、パッチコードと誰かがいじったパッチパネルだった。dentOS側でDDMが読めないなら、対向かホスト側から読むこと。ビットマスクだけではこれは決着しない。