FortiGate 101FのRJ45/SFP共用ポート17-20がFortiOSアップグレード後に無応答になる
40人規模のオフィス向けにFortiGate 101Fを2台ペアで運用していて、特に変わった構成ではありません。port17はコアスイッチへのSFPアップリンク、port19はサーバールームへのRJ45で、どちらも共用のRJ45/SFPブロック(ポート17-20)の中にあります。先月のメンテナンスウィンドウでペアをFortiOS 7.4.4に上げたのですが、それ以来このブロックが死んでいます。
- FortiGate 101F。もう1拠点のFortiGate 100Fも同じ挙動
- port17: 1G SFPモジュールでスタック構成のアクセススイッチへ
- port19: RJ45で1Gのスイッチポートへ
- FortiOS 7.4.4、7.2系のビルドからアップグレード
ポート1-16は問題なく、共用ポートだけが落ちています。気になったのは、GUIの速度オプションがアップグレード前と見た目が変わっていて、実行中の設定にはこう入っていたことです。
config system interface
edit "port17"
set speed 1000full
next
endこれを誰かが入力したわけではありません。アップグレード前はこの機種のすべてのポートがautoでした。
これまで試したこと:
- SFPを挿し直し、動作確認済みの別のものに交換したが変化なし
- 対向を別のスイッチポートに移動
- ファイアウォールをコールドリブートしたが、設定は上記のまま残る
100F/101Fの共用RJ45/SFPブロックは、アップグレード時にautoが失われるのが仕様なのでしょうか、それともどこかで設定が壊れたのでしょうか。正しい戻し方は何でしょうか。
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 5
設定はオフィスの誰かが壊したわけではなく、アップグレードがやったことです。100Fと101Fでは、アップグレードが共用RJ45/SFPポートに対して、それまでautoだったところへ黙って固定の1000fullを書き込みます。対向がそのレートで問題ないかどうかは確認しません。対向次第で、間違ったレートでリンクするポートになったり、まったくリンクしないポートになったりします。専用ポートは触られないのに17-20だけ死んでいる理由はまさにこれです。Fortinet側ではknown issue 989629として記録されていて、7.2.9のリリースノートに書かれています。影響を受けるのはv7.2.8以降、v7.4.2以降、v7.6.0以降の系列です。
speedはポートごとに手で戻してください。
v7.2.8とv7.4.2からv7.4.4までは単純なautoが選択肢に出てこないので、GUIの見た目が違って見えるのはそのためです。そこでは1000autoを使ってください。v7.2.9、v7.4.5、v7.6.0以降では通常の選択肢が戻ってきているので、そちらでは
を使います。port18からport20も使っているなら同じ作業を繰り返してください。それと、次のウィンドウに向けて: 管理経路がポート17-20のどれかを通っていないか事前に確認してください。そうでないとボックスはアクセスポートが1000fullに固定された状態で戻ってきて、コンソールから直すために現地へ車を走らせることになります。
実際にどのビルドから上げたんですか。「7.2系のビルド」だと範囲が広すぎて、直すために何を入力すべきかは系列によって違います。もうひとつ知っておきたいのは、対向がオートネゴシエーションに対応しているのか、それとも固定されているのかということです。常にオートネゴシエーションしかしない相手は、固定レートのポートに対しては何も反応しません。
何かを変える前にひとつ確認してください。管理経路はポート17-20のどれかを通っていますか。通っているなら、次の変更はネットワーク越しではなくコンソールから行ってください。
共用ポートがおかしな動きをして辿り着いた人のために、一般論も付け加えておきます。たいていの機種ではそのペアは本当に排他的です。NETGEARはGS716T-200でこれをdual personalityと呼んでいて、2つのSFPケージそれぞれが最後の銅ポートのどちらかとペアになっていて、そのペアのうち生きていられるのは片方だけです。モジュールを挿すと、対応するRJ-45が黙って使えなくなります。あのモデルはどのポートもギガビットなので、光アップリンクが買っているのは帯域ではなくケーブル経路です。
FortiGateのブロックでも同じ発想があり得るので、実際に見ているのがport17のどちら側なのか確認してください。ケージにモジュールを挿しつつ同じポートの銅側にもパッチコードを挿すというのはよくある自滅パターンで、CLIから見ると速度の問題にそっくりに見えます。
ベンダーは違いますが、同じ種類の苦労話です。EX-UM-2X4SFPアップリンクモジュールを積んだEX4200で、xe-0/1/0は問題なく10Gで動くのに、xe-0/1/1はVLANに追加することすらできず、トラフィックも一切通りませんでした。両ポートとも1Gでは動作し、SFP+はshow chassis hardwareにきちんと表示されていて、モジュールを入れ替え、予備のEX-UM-2X4SFPを試し、ファクトリーリセットまでやったところで、そのモジュールが実際何なのかを誰かが教えてくれました。
壊れていたものは何もありませんでした。あのモジュールはハードウェア上0番と2番の番号がついた2つのケージにしかSFP+を受け付けず、残りのペアは1Gオプティクスまでしか扱えません。つまり10Gインターフェースとして使えるのはxe-0/1/0とxe-0/1/2だけで、私が格闘していたxe-0/1/1は何を挿しても10Gでは動くはずがなかったのです。オプティクスを隣のケージに移してxe-0/1/2を設定して解決しました。混在モードのケージでは、何かをRMAに出す前にそのブロックが何をサポートしているか読んでおくことです。
コンボポートの排他性という切り口には注意が必要で、今回のケースの説明にはなりません。ポートはアップグレード前は動いていて、共用ブロックだけが後から壊れ、しかも誰も入力していない速度の行が設定に入っています。これはケージの優先順位ではなく書き換えの話です。
とはいえ逆方向の思い込みで痛い目を見ることもあります。以前、D-Link DES-1210-52スイッチをファイバーでOSNOVO NS-SW-8GX2Gにアップリンクする構成で1週間つぶしたことがあります。光ポートではリンク表示があるのにLANもインターネットも一切通らず、同じスイッチを銅でチェーン接続すると問題なく動き、ファームウェア更新でも何も変わりませんでした。コンボポートが何日も最有力容疑者でした。実際の故障は対向側で、それらのSFPモジュールが挿さっていたOSNOVO側のポートが内部的に死んでいて、焼けていたんです。オプティクス自体はそこに挿さったまま完全に健全でした。
なので、ローカルの設定が正しいことを確認したら、自分のボックスについて何か結論を出す前に、対向側の動作確認済みのポートに動作確認済みのモジュールを挿してみてください。