Accton AS9716-32Dを100Gで: INNOLIGHT QSFP28 LR4はAristaにはリンクするがFortigate 3810D CFP2-LR4には一切リンクしない
SONiCのmasterビルド(build master.207726)を動かすAccton AS9716-32Dでリーフを立ち上げています。400G対応ポートのうち4本をファイアウォールペアに向けて100Gで動かす必要がありますが、どれ一つとしてリンクしません。
- Accton AS9716-32D, SONiC master.207726
- スイッチケージ側はINNOLIGHT TR-FC13R-N00 QSFP28 LR4
- 対向はFortigate 3810DでCFP2-LR4
- ポートは100G固定、オートネゴ無効、RS FEC、MTU 9100
sudo config interface speed Ethernet0 100000
show interfaces status
Interface Speed MTU FEC Admin Oper
Ethernet0 100G 9100 rs up down試したこと:
- ポートをPAM4の2レーンとNRZの4レーンの両方で試すも、どちらの向きでも違いなし
- RS FECの代わりに
sudo config interface fec Ethernet0 none - 同じINNOLIGHTモジュールと同じファイバーをArista QSFP28ポートに挿すと即座にリンクアップ
つまりオプティクスとファイバーの容疑は晴れています。この400Gポートを100Gで駆動する部分か、CFP2側がレーンに期待している何かのせいで、リンクが上がらないままです。このプラットフォームで400GケージからCFP2-LR4へ100Gで喋らせた方はいませんか、その場合ポートプロファイルはどうなっていたでしょうか。
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つ確認させてください。Fortigate側は何と言っていますか、CFP2は光を受けているのにdownのままなのか、それともモジュール自体を認識していないのか。それと3810DのポートはFECがどう設定されていますか。
LR4同士のペアでは、片側だけRS FECが有効になっているだけでリンクが永遠にdownのままになり得ますし、そもそもCFP2-LR4ポートには有効にできるRS FECがないのが普通です。
Fortigate側はインターフェースがdownと表示され、カウンタにも参考になる情報はありません。モジュール自体は認識されていて、そのポートは私たちが触る前は別の機器と100Gリンクを張っていました。あちら側にはFEC設定が見当たりません、表に出ているものも隠れているものも含めて。
こちら側ではRS FECはきれいに外れます。
sudo config interface fec Ethernet0 noneを実行するとFEC列はnoneになり、ポートは一度落ちてadmin up、oper downという同じ状態で戻ってきます。つまりスイッチ側だけRS FECを外しても何も変わりません。試した2つのプロファイルは同等ではなく、片方は構造的に動きません。CFP2-LR4は4レーンNRZのインターフェースで、ホスト側は25G電気信号が4レーン、ファイバー側は4波長になります。ポートプロファイルでケージを2レーンPAM4にしていると、スイッチは2x50Gを相手に押し込むことになりますが、相手はライン側に4本のNRZレーンを渡さなければならず、FEC設定に関係なく一切トレーニングしません。この組み合わせであり得るプロファイルは4レーンNRZだけです。
そこを固定すれば、残る変数はFECだけになります。100GBASE-LR4はRS FECを運びませんし、CFP2-LR4ポートには普通それを有効にする手段もありません。これはFortigate側で確認した内容とも一致します。こちら側のそのポートにまだ
rsが残っているなら、それだけでリンクが恒久的にdarkなままな理由として十分です。まとめると: 4レーンNRZ、オートネゴ無効、
sudo config interface fec Ethernet0 none、ポートをバウンスさせて、show interfaces statusを読み直し両方の設定が実際に反映されているか確認してください。そこに地味な規格の話も足しておきます。ここではFECはネゴシエーションされません。両端の静的なプロパティで、リンクの全レーンで一致していなければなりません。チャネライズド100Gについてのベンダーガイダンスも一言で同じことを言っています。100Gポートを25Gレーンに分割する場合、全レーンの両端が同じFECモードで動かない限りレーンは一切トレーニングしません。
TR-FC13R-N00のEEPROMが実際に何を申告しているかダンプしてみる価値もあります。これらのモジュールは100GBASE-LR4と25GBASE-LRへの準拠を報告していて、プラットフォームによってはconfigに打ち込んだ内容ではなくそのフィールドからデフォルトのレーンモードを選ぶものもあります。
ベンダーは違いますが形は同じ話です。MikroTik CCR2216とAristaの間をQSFP28 SR4オプティクスで100Gリンクさせていて、何か月も上がっていたのにある日ぱたりと上がらなくなったことがあります。その間にRouterOSは7.8から7.12.1に上がっていました。両端とも固定設定でした: CCR側はauto-negotiation=no、fec-mode=fec91、MTU 9000、100G-baseSR4-LR4、Arista側は100gfullでreed-solomon error correction。オプティクスを交換しても変化なし、4レーンすべての受信パワーは健全、ポートを4x25Gに分割してもレーンがフラップするだけでした。
結局そちらでも答えは見つかりませんでしたが、パターンはあなたのケースと同じです。オプティクスは無実で、片側のポートドライバが足元で変わったのです。masterのスナップショットに乗っているなら、それが真っ先に動かしてみる変数です。
最後のステップは注意してください。FECをnoneに設定して出力に
noneと出ても、それはポートが実際にRS FECなしで動いている証拠にはなりません。こうしたプラットフォームのいくつかでは、値はconfigデータベースに書き込まれてCLIはそれを素直に表示するだけで、serdes側はポートが本当に再作成されるまでプログラムされたモードを保持し続けます。400G対応ケージでは速度変更自体がポートを再作成するので、この2つのノブは絡み合っていて順番が重要になります。レーンプロファイルについても同じ注意が必要です。ブレイクアウト対応ケージでは、それは
sudo config interface speedだけでなくプラットフォームのポート設定から決まります。プロファイルが一度も再生成されていなければ、あなたが試した2つの設定は結局同じレーンマップの上で動いていた可能性があり、それならPAM4とNRZが同じに見えたのも説明がつきます。変更後は機器をリロードして、コールドスタートから確認してください。全部やってみました。ポートは4レーンNRZで再作成、こちら側のFECはnone、オートネゴ無効、config保存、フルリロード、コールドスタートから再確認しました。それでもCFP2のペアは依然downのままです。FortigateのRS FECは本当に外に出ていないので、あちら側で意図的にミスマッチを作ることすらできません。
一方で同じケージの同じINNOLIGHT TR-FC13R-N00は、Arista QSFP28ポート相手なら数秒でリンクします。モジュールとファイバーの容疑は晴れたままです。
完全な技術ダンプを添付したかったのですが、ここのサイズ制限を超えてしまいます。今のところ4本のポートはdownのままで、ファイアウォールのアップリンクは別の機器に移しました。このプラットフォームで400GポートをCFP2向けに実際に100Gで動かせている方がいたら、最終的にどのプロファイルに落ち着いたか知りたいです。