MerakiにとってInternet方向に向かうアップリンク設定はとても重要になります。
Campus Networkにおいては冗長構成を取ることが多く複数のアップリンクが存在することが多いです。
今回はIOS-XE Version 17.15 Cloud Config Modeで動作するCatalyst9300の冗長されたアップリンクの設定および動作についてまとめておきます。
検証環境
下図のような構成で検証を行いました。
赤枠で示しているCatalyst9300のアップリンクの動作を中心に確認していきます。
設定を確認しておきます。
Catalyst9300のSVIとしてVLAN11、12の設定が正しくされていることを確認します。
この検証ではVLAN11を優先アップリンクとして設定しています。
VLAN12は優先アップリンクがダウンした際のバックアップリンクとして機能します。
優先アップリンクにのみDefault Routeの設定が可能となります。
Default Routeを複数設定してECMPでアップリンク設定を行うことは出来ないようです。
Cloud CLIでDefault Route設定を確認してみます。
今回はOSPFよりも優先としないDefaut Routeの設定としましたので、OSPFよりも弱いAD値120でStatic Routeが設定されていることが分かります。
Default Routeが優先アップリンクにしか設定出来ないため、OSPFを設定し、上位のSwitchからECMPでDefault Routeを受信するようにします。
ルーティングテーブルを確認します。
OSPFでECMPにてDefault Routeを受信していることを確認します。
上記のAD値120で設定されているStatic Default RouteはOSPFに負けて消えていることが分かります。
最後にSwitchの状態を確認しておきます。
優先アップリンクVLAN11として設定しているGigabit1/0/1がMeraki Cloudへの疎通性のためのアップリンクとしてマーキングされていることが分かります。
管理IPとして優先アップリンクVLAN11である192.168.11.2になっています。
優先アップリンク障害時
優先アップリンクVLAN11の切断を行います。
暫くすると、オンラインは継続するものの管理IPが消えていることが確認できます。
VLAN12であるGigabit1/0/2のみがアップとなっていることも確認できます。
しかし、Gigabit1/0/2ではアップリンクのマーキングはされていません。
また、IPアドレスが未設定と表示されてしまいます。
VLAN12を介してOSPFでDefault Route広告を受けているのでCatalyst9300としては継続してMeraki Cloudとの疎通性が保たれるためオンライン状態は維持していることになります。
このような状態でもCloud CLIは機能します。
優先アップリンクの復旧
優先アップリンクを復旧させ全ての状態が戻ることを確認します。
Static Routeの設定によって表示が変わる？
優先アップリンク障害時には一部表示が不自然となるのは少し気持ち悪いと思うかもしれません。
そのような場合にはバックアップ側のアップリンクに何かしらのStatic Routeを記述することで一部改善することが出来るようです。
特に意味もないのですが下のようなVLAN12をネクストホップとするStatic Routeを追加します。
OSPFよりも優先しない設定にします。
再び優先アップリンクを切断します。
暫くすると管理IPがVLAN12である192.168.12.2に変更になることが確認できます。
しかし、ステータスが"!"である警告が出てしまいます。
Switchの状態をみてみると、VLAN12であるGigabit1/0/2にアップリンクのマークが表示されるようになったことが分かります。
しかし、「IPv4割り当て構成が不正です」と警告が表示されてしまいます。
IPアドレスはVLAN12のもので表示されています。
まとめ
今回はIOS-XE 17.15で動作するCloud ConfigモードなCatalyst9300でのアップリンク設定および表示についてまとめてみました。
障害時の表示上の気になるポイントはいくつかありましたが、実通信に関しては特に影響はないと思いますので本記事を参考にして試してみてください。
