Fortinetの25G DAC、同一FortiSwitch同士ではリンクするのにFS2048-FS648間だけリンクしない
2つのアグリゲーション列をFortiSwitchに統合している途中で、最後に残ったのが隣接ラックのFS2048とFS648を結ぶ25Gインターコネクトです。設計の他の部分は一発で立ち上がったのに、このリンクだけ頑として上がりません。
- FortiSwitch 2048、25Gフロントパネルポート
- FortiSwitch 648、25Gフロントパネルポート
- Fortinet FN-CABLE-SFP28-5 パッシブDAC、純正ケーブル、サードパーティ品ではない
- 両ポートともVLAN設定以外は未変更
出ている症状:
FS2048 port: down, no rx/tx counters moving
FS648 port: down, no rx/tx counters moving
same FN-CABLE-SFP28-5 between two FS648 units: up at 25G, stableすでに試したこと:
- 同じ箱に入っていた予備のFN-CABLE-SFP28-5に交換したが変化なし
- 両端を各シャーシの別の25Gポートに挿し替えたが変化なし
- 同一機種のFS648同士に挿し直してケーブル自体は正常であることを確認済み、そちらは即座にリンクアップする
つまりケーブルもポートも問題ないのに、この組み合わせだけがだめということです。リンクトレーニングが成立する前に、2機種間で25Gポートの何かを揃えておく必要があるのでしょうか。
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 6
まさにそれです。この2つのシャーシは世代の異なるASICとPHYで作られていて、25Gで各自が勝手に落ち着くエラー訂正方式が両側で一致しないため、リンクトレーニングが最後まで終わりません。残るのはきれいなdown/downの状態だけで、ログには手がかりになるものが何もありません。
両方のポートで手動で同じFECモードに固定してください。
FS2048側とFS648側それぞれで、各自のポート名を使って設定してください。CL91はリードソロモン方式で、CL74のfirecodeオプションよりかなり強力に訂正しますが、どちらを選ぶかは大した問題ではなく、両側で同じものを選ぶことの方がはるかに重要です。両方のPHYが同一方式でエンコード・デコードしなければトレーニングは完了しませんし、異なるPHYファミリー同士の「auto」は同一方式にはなりません。
2つ目の側をコミットした時点でポートはすぐに上がるはずです。後で3台目の機種を混在させる場合も、デフォルトが引き継がれると決めつけずに、そちらでも明示的に設定してください。
同一機種同士ではリンクするのに機種が違うと死ぬケーブルというのは、物理層のどこかで合意が取れていないということで、25Gの銅線ではほぼ常にFECが原因です。
まず何よりも、両方のポートで現在のfec-stateがどう設定されているか貼ってください。デフォルト値はFortiSwitchの世代によって違いますし、今回つないでいる2機種は同じASIC/PHYファミリーではないので、「両端とも工場出荷設定」は「両端とも同じ設定」を意味しません。
そこで2つのポートの値が違っていたら、他に何も触らないうちに答えが出たことになります。
どちら側も何も触っていないので、両方のポートともイメージがデフォルトで設定する状態のまま動いています。FS2048側は素の状態です。
FS648側も同じです。速度とオートネゴシエーションも未変更で、やったのはポートを正しいVLANに入れただけです。デフォルトが機種ごとに違うのであれば、同じケーブルが同一機種同士では何の問題もなく使えている理由の説明がつきます。
ちなみにFortinet以外でも同種の問題はよくあります。25GのSFP28パッシブDACがUniFi USW-Pro-AggregationとIntel SFP28カード搭載サーバーの間では問題なくリンクするのに、MikroTik CCR2004-1G-12S+2XSのsfp28-2に挿すと何も起きませんでした。どちら側にもエラーは出ず、ただリンクしないだけです。Ubiquiti UACC-DAC-SFP28-3MとLenovo 7Z57A03558も試しましたが結果は同じでした。一度だけポートが上がったものの2秒ほどで落ちたことがあり、これがケーブル不良ではなく何かがトレーニングに失敗しているというヒントでした。
またFECです。Ubiquiti側はFECを常時オンにしていて変更する方法はサポートされておらず、RouterOSは6.49でデフォルトをfec91からFECなしに変更しています。ここでうまくいったのは、FECオプションが表に出てくるRouterOS 7.4まで上げて
を実行してから、ポートをfec74、オートネゴシエーションはオフ、フローコントロールは両方向オフ、25Gbpsフルデュプレックスに設定し、さらにUniFi側でポートプロファイルを上書きして25G FDXに固定することでした。これは自分の機材と自分のファームウェアでの話なので、この手順はあくまで出発点として捉えて、各自の環境で確認してください。
付け加えると、同じつまみでもどのベンダーのCLIにいるかで名前が変わるので、ラックの中に複数ベンダーが混在した途端にこれが面倒になります。Catalyst 9300スタックとCatalyst 9500ペア間のCisco 25Gリンクでは、両端でfec cl108にしたところ上がりました。その9500ペアとNexus 9000間の100Gでは、両側でfec offにするのが正解でした。判断の中身は同じでもキーワードが違います。
そしてFECは常にオンにするものとは限りません。Nexus 93180YC-EXにSFP-H25GB-SRを挿してCavium製25Gアダプタにつないだケースでは、スイッチ側のポートはFEC autoのままオプティックの種類からFECを期待していたのに対し、NIC側はFEC非対応と報告していて、両端が合意できずモジュールは認識されたままインターフェースはdownし続けました。このときはスイッチ側インターフェースでfec offにしたのが正解で、show interfaceでモードがAutoからOffに変わったことを確認できます。
つまりルールは「cl91を使え」ではなく、「モードを決めて、両端に明示的に設定しろ」です。
確認できました。FS2048ポートでset fec-state cl91としただけでは何も変わりませんでしたが、続けてFS648ポート側でも同じ設定をしたところ数秒でリンクが上がりました。両側でカウンタが動いていて、各シャーシを再起動しても維持されています。
これからはこのペアのすべての25Gポートで、デフォルト任せにせず明示的に設定を入れておきます。たった1行の設定のために、何の問題もないケーブルを2晩かけて交換し続けたわけです。