Supermicro E300-9A、pfSense Plus 22.05: USW-Aggregationでは普通にリンクするDACなのにix2とix3がno carrierのまま
うちのファイアウォールはpfSense Plus 22.05を動かしているSupermicro E300-9Aで、10G SFP+ポートが2つとも上がってきません。ix2もix3も、ケージに何を挿してもcarrierを表示しません。
ハードウェア:
- Supermicro E300-9A、pfSense Plus 22.05
- Ubiquiti DAC-SFP10-0.5Mと10Gtekのパッシブツインアックスケーブル
- 代替としてSupermicro AXS85-192-M3のファイバーモジュール
- スイッチ側はUbiquiti USW-Aggregation
# ifconfig ix2
ix2:
media: Ethernet autoselect
status: no carrierix3も同じ状態です。
これまで試したこと:
- 両方のケーブルともUSW-Aggregation上で他の機器の間では動くので、死んではいない
- 銅からAXS85-192-M3のファイバーモジュールに替えても、両ポートとも同じくno carrier
- アプライアンスを何度か再起動し、稼働中にモジュールを挿すことも試した
この機種にはケージが動き出す前に何か蹴ってやる必要があるものがあるのでしょうか、それとも2つとも死んだポートを見ているだけなのでしょうか。
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
ウォームリブートではどうにもなりません。あのポートはメディア状態をラッチしてしまい、再起動しても再プローブしないんです。アプライアンスをきちんとシャットダウンして、電源アダプタを2分ほど抜いてから、モジュールを挿した状態で起動し直してください。うちではそれで両ポートとも復活しました。別の人がIntel X552のポートで全く同じ症状を報告していたので、pfSenseの問題というより古いメディア状態が残っている話だと思います。
システムが稼働中にモジュールを挿した場合は、再起動ではなくインターフェースをバウンスしてください。
これでドライバがケージをもう一度見にいきます。恒久的な修正ではありませんが、ベンチでモジュールを入れ替えるときに再起動を省けます。結果はフロントパネルではなく
ifconfig -aで確認してください。まず完全に電源を抜くところから始めて、スイッチ側に触る前にDACで両方のケージを確認してください。ここでは1つずつ切り分けることが大事です。「どのモジュールでもno carrier」と「間違った速度でリンクする」は、たまたま同じケーブル経路にある別々の不具合であることが多いので。
完全に電源を抜くやり方でうまくいきました。シャットダウン、アダプタを抜く、2分ほど待つ、電源を入れ直す、で両ポートとも上がってきました。ix2とix3の間でDACをループさせたらきれいに10Gでリンクしましたし、AXS85-192-M3のペアも両ポート間で10Gが出ます。なのでケージとモジュール自体は問題ありません。
スイッチ側は別の話です。USW-Aggregation向けだとリンクは1Gでしかネゴシエーションしてくれず、どちらかの端で10Gを強制するとリンクが落ちて上がってこなくなります。問題の半分は消えましたが、厄介なほうの半分はまだ残っています。
その1Gにフォールバックする話、すごく見覚えがあります。うちではTL-SG3428XとTL-SX3008Fで同じ症状を追いかけました。そのSFP+ポートにぶら下がっているサーバーを再起動すると、スイッチ側のポート設定が何であろうと1Gでネゴシエーションして戻ってくるんです。Intel X520-DA2、Mellanox、HPのアダプタ、Intel E10GSFPSRと10GTekのオプティクス、ファームウェア更新、LinuxとWindowsで複数のドライババージョン、ポートプロファイル、どれも変わりませんでした。スイッチを再起動するか、ポート速度を一旦10Gから外してまた戻すと、次にホストがリセットされるまでは10Gリンクが復活します。
実際に効いたのはホスト側の何かではなくオプティクスを変えることでした。スイッチ側をTP-Link SM5110-SRモジュールにしたら、毎回10Gでリンクが戻ってきました。別の人がSG3428XMPPでも同じことを確認しています。ホスト側のリンクリセットの後、一部のサードパーティ製モジュールに対してスイッチがネゴシエーションを誤るのだろう、という見方でした。
あなたの環境はベンダーが違いますが、形は一致しています。まとめて買う前に、Ubiquitiブランドのモジュールを1つ借りて、aggregationスイッチの1ポートでテストしてみてください。
10Gの強制について。片方の端だけでやると、良くなるどころか悪化します。相手はまだネゴシエーションしようとしているのに、固定設定にはネゴシエートする相手がいなくなるので、リンクはただ落ちたままになります。まさにあなたが説明している挙動です。速度とデュプレックスは両端で固定するか、両端とも触らないかのどちらかにしてください。
MikroTikがらみで似た話が2つあるので、参考になれば。RB4011でFinisar FTLF8524P2BNV-BRを検出したケースでは、sfp-rx-lossもsfp-tx-faultも両方noなのにインターフェースはno-linkのままでした。これはSFP+ケージに挿した1G SFPはネゴシエーションではなく固定にする必要があるためです。
これもやはり両端で設定します。2つ目はCCR1072のケースで、リンク断の後にauto-negotiationがDONEのまま張り付いてしまい、ドライバが再起動しないというものでした。autonegを無効にして速度を固定するとリンクは戻りましたが、代わりにまともなリンクダウン検知は失われました。