キャンパスLANのネットワークではあまりリングプロトコルを利用するケースはないですが、建屋間の配線などで簡単にケーブルを引けないような環境で、可用性のあるネットワークを制御する場合に利用されることがあります。
さらにこういったリングプロトコル対応したスイッチは比較的高価なL3スイッチで提供している傾向があるようで、大規模なネットワーク環境ならもちろん、正式なリングプロトコルを採用するべきですが、小規模の建屋を結ぶような場合に、以下に予算を抑え、更に使いやすいL2ネットワークを作れるかが今回のテーマとなります。
環境周り
- FortiGate300E（FortiOS7.0.2）冗長構成
- FortiSwitch 224E(OS7.0.2) 4台（内2台はMC-LAG)
- FortiSwitch 124D(OS3.6.11) 6台
- FortiSwitch 124F(OS7.0.2) 1台
- FortiSwitch 108D(OS3.6.11) 1台
- FortiSwitch 108E(OS7.0.2) 1台
- FortiSwitch 224D(OS7.0.2) 1台
- FortiSwitch 424D(OS7.0.2) 1台
※FortiSwitchの管理におけるNGFW機能は不要。ハードウェアの保守だけで利用できます。
※機器は適当に配置しています。
今回やりたい構成は以下のような、大きなリングで構成されたL2ネットワークです。
FortiSwitchによるリングトポロジーイメージ
Fortinetさん全面協力のもと、合計13台のエッジスイッチ手配いただき、リングトポロジーの検証ができました。
通常リング上のネットワークを使う場合は、リングプロトコルに代表される、ERPS(Ethernet Ring Protection Switching)、EPSR(Ethernet Protected Switched Ring)、RRPP(Rapid Ring Protection Protocol)、Cisco REP(Resilient Ethernet Protocol)など標準的なものから、メーカー独自のリング制御プロトコルなどがあります。
一旦全てののスイッチを工場出荷状態へ
届いたFortiSwitchを全て初期化していきます。フロントのボタン長押しによるリセットでも構わないですが、コンソールポートから以下のコマンドを実行して初期化しても構いません。
exec factoryreset
なお、コンソール接続する場合は、スイッチによってはボーレートが"115200"の場合があります。コンソールの応答がない場合はボーレートをチェックしてみてください。
接続前の状態
今回の手順ではすでに、MC-LAG及2段目のスイッチまではコンフィグレーション済みです。
この"A1"と"A2"のスイッチに対して、ループになるようにFortiSwitchをカスケードしていきます。
FortiSwitch 1台目の接続
FortiSwitchは基本的に自動設定が売りの製品です。特に事前のコンフィグレーションなしに、どんどんつないでいけば、自動的にトポロジーを認識して最適なネットワークを構成してくれます。
まずは、A1のスイッチに初期化された状態のFortiSwitchを接続してみます。
見ての通り、1台のスイッチが自動的に"A1"のスイッチの下に表示されました。この接続をISLという機能によって、隣接するFortiSwitchを認識しているようです。
FortiSwitch 2台目の接続
1台目と同じようにLANケーブルを使って接続します。
少し横長になってしまいましたが、正しく認識されています。 この調子で、どんどん接続していきます。
FortiSwitch6台目の接続
だいぶ横長になってきました。
FortiSwitch13第目の接続
更に横長になってしまいましたが無事13台のカスケード接続ができました。
CPUやメモリにはほぼ負荷のない状態です。
この時点では、リング構成になっていないので、ここから"A13"のスイッチと"A2"のスイッチを接続し、大きなリングを作ります。
リングトポロジーが無事に完了
ぐるりと大きな円を描いて、L2ネットワークが構成されています。しかし、ここまで1台ずつ、FortiGateで認識していることを確認してから接続しているため、全台接続するために結構時間がかかりました。（途中バージョンアップなども実施しています）
この時点では特にDiscardingされているポートもなく、全てActiveなリンクのようです。
特に意識していなくても、このようにリンクトポロジーが構成できることが確認できました。
FortiGateでFortiSwitchを管理する場合、上図のように自動的にトポロジーを表示してくれるので、SNMPのマップツールなどを使わなくても良い感じに仕上がります。
配置がおかしい場合は、編集もできるので必要に応じて変更してみてください。
物理トポロジを見るとちょうど半分のところで分離されているようです。
論理トポロジは当然ですが変わらずです。単純にFortiGateのスイッチインターフェースが、スイッチ台数×ポート数分が追加された感じです。イメージとしてはシャーシ型スイッチのスーパーバイザーがFortiGateで、ラインカードがFortiSwitchというのが妥当かもしれません。
上記のことから、リングトポロジーとはいえ、通信は一方通行へ流れているようになっていると思います。
通信が向かって左側へ回って接続されるイメージです。
障害テスト（スイッチの電源障害想定）
さて、ここまでは大方予想はできていたのですが、気になるのがスイッチの障害時のトポロジー変更に伴う収束時間です。
ネットワーク障害が発生した時に、どれくらいのダウンタイムが発生して、どういう影響が予想できるかというところをいくつかサンプルで確認してみます。
A7のスイッチをダウン
Pingによる確認を行っている端末が接続している左真横のスイッチをダウンさせます。
予想では、方向が逆回転するはずなので、大きなネットワークダウンが予想されます。
スイッチの画面ではインターフェースがダウンしたことがわかります。
障害時ダウンタイムの確認
この画面はPC8からPingを実施し続けている画面です
（インターネット（左）、PC3(真ん中）、PC13（右））
ICMPの応答が1000msで指定しているので、概ねロストしている分が切断時間と考えていいです。
思ったより早い収束時間です。概ね2秒程度のダウンタイムで復旧しています。
復旧時のダウンタイム
やはり、復旧時のほうが時間がかかる模様です。それでも数秒間の停止です。
これくらいのダウンタイムなら、日中に復旧させずに、時間外作業などで、新しいスイッチに取り替えることを検討したほうがよいでしょう。
以降のテストはダウンタイムのみ計測し、復旧は運用でカバーする想定で進めます。
A9のスイッチをダウン
今度は右真横のスイッチをダウンさせてみます。
ダウンタイム
なるほど。ダウンが発生しませんでした。通信が左回りなので、右側に障害が発生しても影響がないようですね。
当然ですが、PC8からPC13への通信は、正常時でも物理的にはたくさんのスイッチを経由していることがわかりました。
A4のスイッチのダウン
ダウンタイム
当然A4に接続しているPCへの疎通はなくなりますが、その他通信はすぐに復旧しました。
A12のスイッチのダウン
ダウンタイム
大方の予想通りで、右側の障害では左側にある通信には影響がなかったです。
MC-LAGのスイッチをダウン
今回のリングトポロジーで重要だと考えているのが、FortiGateから1段MC-LAGを構成していることです。
リングトポロジーと冗長化されたFortiGateへのマルチパスを提供しながら、なるべく障害ポイントを少なくすることができると思っています。
ダウンタイム
ほんの寸断があった模様ですが、ほぼ切断がなかったです。反対側もやってみましたがほぼ同様の結果でした。
FortiGateのダウン
冗長化されているFortiGateのActive機をダウンさせます。
ダウンタイム
これは、スイッチのトポロジに対しては影響がないため、LAN内におけるダウンタイムはないです。
当然ですがインターネット（FortiGateを経由する）通信に少し影響がありましたが、FortiGateのHAの切り替え機能はかなり優秀だと思います。
思いの他良い結果？でしたね
正直スパニングツリーをベースに動いていると思っているので、ここまで階層が深いとダウンタイムの収束までかなり時間がかかってしまうと思っていましたが、結構高速に収束して、復旧時のフラッピングなどもないように見えました。
全部のスイッチを一気に接続してみるとどうなるのか？
実は今回の検証をするにあたって、13台のリング構成を行うために、1台ず確認をしながら実施しました。ただこれはとても時間がかかります。
そのため、次は、適当にFortiSwitchをつないで放置してても、正しくリングトポロジーが形成されるか確認をしてみます。
マネージドFortiSwitchから全部削除します
一度接続確認ができたので、全てのスイッチを初期化して、全台一気に接続し、自動設定によるトポロジーの変化を見てみます。
FortiSwitchのA3〜A13までのLANケーブルを抜き、機器の初期化を行います。その後、一気にLANケーブルを接続する過程を見てみましょう。
FortiSwitchの自動設定の動画
概ねトポロジーの調整に30分弱かかりましたが(動画は10倍の高速再生です）、バージョンさえ統一できていれば、誰が接続しても30分あれば勝手に接続できていると考えるとめちゃくちゃ便利です。箱から出して、ラッキング後、正しくLANケーブルを接続するだけで、ランチでも行っている間にネットワークが自動的に構成されるわけです。
事前のCLIを使ったコンフィグレーションも不要なので、現場にベテランエンジニアを派遣しなくても、接続さえできれば設置が完了します。
このように、FortiGateのスイッチコントローラーを使ったFortiSwitchの自動設定とは、基本的なコンフィグレーションを不要とすることで、人為的なミスを防ぎながら、システムが自律的に最適なネットワークを構成することができる画期的な仕組みです。
構成さえできてしまえば、スイッチのホスト名やバージョン管理も遠隔で可能で、スイッチのポートの設定も全てGUIからできるので、もはやあのconf tから始まるコンソール操作はほぼ不要となります。
まとめ
今回は、ご贔屓頂いているパートナーさんからのリクエストを受けて、FortiSwitchの13台リングトポロジーというのを検証してみました。
事前にメーカーさんにも今回のようなネットワーク構成がFortiSwitchで実現できるか確認してみましたが、残念ながら実績もないという回答だったんですが、できない理由が実績がないだけなら、試しにやってみようと思った次第です。
結論からすると、13台のリングトポロジーは動いたという結果でした。
ただご注意いただきたいのは、動いたからサポート可能な構成かということではなく、あくまでも私が構築した環境下で、想定している範囲での動作においては問題なかったということです。実施する際は必ずご自身の判断で行ってください！場合によってはメーカーのサポートを受けれない場合もあります。
実際にエンドユーザー環境で利用する場合は、こちらのブログの情報も加味しながら、もう少し現実的な動作試験を行った上、こういったリングトポロジーの採用をご検討してください。またFortiGateやFortiSwitchなどの機器構成なども十分に検討する必要があります。
もしこのパターンが問題ないのであれば、例えば建屋をつなぐ工場の敷地のネットワークなどにも応用できる可能性があります。
また最近、SASEの登場により、インターネットに関連するセキュリティ機能がクラウド化していますが、有線、無線LANなどはクラウド化できないため、このようなSDN（Software Defined Network）を使うことで、少しでもLANの管理を簡単に、効率化することが重要です。
余談
FortiSwitchのループガード
この環境を使って、FortiSwitchで良くお問い合わせを受ける、ループガードの機能を検証してみました。
以下の構成のように、FortiSwitchの配下に、ノンインテリジェンスなHUBを接続し強制的にループを引き起こす検証です。
良くあることですが、同じHUBにLANケーブルを接続してしまって、ループがネットワーク全体に広がってしまうケースです。
ループガードを有効化する
設定はポートを右クリックして、ループガードを有効するだけです。
ループが自動的に検知されてブロック
システムイベントにループガードによってポートがシャットダウンされたことがわかります。
ポートの状態
ループガードの状態は直接FortiSwitchにアクセスしてコマンドを実行することで確認できます。
ポートの復旧
ポートは自動で復旧することはないので、ループを除去した後、手動で戻す必要があります。
コマンドはexec loop-guard reset port xです。
無事"Triggered"が取れて、ポートの活性化ができました。
以上です。
リモートアクセスのユーザー認証をＩＤａａＳと連携
著者紹介
SB C&S株式会社
ICT事業本部 技術本部 第3技術部
宮本 世華
釣りが好きです。
