この記事について
Cisco Secure ConnectのDCのOutage時のMerakiAutoVPNにおけるフェールセーフ設定について解説します。
※ネットワーク設計の要素を含むため、あくまでも一構成例として捉えていただきますようよろしくお願いいたします。
デフォルトの構成について
Cisco Secure Connectを利用したサイト間VPNの場合、Cisco Secure ConnectのAsia DCではデフォルト構成でNaritaをプライマリHubとSingaporeをスペアHubとされます。
Meraki Auto VPNでSpokeが使用するHubは、Site-to-Site VPNページのHubsの上位から順番に使用します。
図1：デフォルト構成でのHubsの設定内容
プライマリHubのNaritaがダウンした場合には、スペアHubのSingaporeに自動的に切り替わる冗長構成となっております。
図2：参加しているMerakネットワークが全てSpokeの場合の構成例
Merakiネットワークに参加している拠点がすべてSpokeで構成されている場合、Spoke拠点間の通信はSecure Connect拡張ヘッドエンドを経由します。そのため、以下の状況が発生すると、サイト間通信が完全に停止する可能性があります
- 2つのデータセンター（DC）が同時にダウンした場合
- BGPピアリングが同時にダウンした場合
全拠点がSpokeの場合での各拠点における動作
上記の状況が発生した場合、各拠点では次のような動作が想定されます。
クライアントのインターネット通信
初めは、Cisco Secure Connect のDC向けBGPルートのHoldタイムが経過するまで通信できなくなります。
Holdタイムが経過すると、ローカルWANインターフェースのゲートウェイにルートが切り替わり、インターネット通信は可能になりますが、拠点間通信は引き続き不可能となります。
MX ルーティング動作 - Cisco Meraki ドキュメント
デフォルトではIPv4 default route設定がOFFになっていますが、Site-to-Site VPNの設定でIPv4 default route設定がONになっている場合にはインターネット通信できなくなることが想定されます。
※この設定はONとすることを避けていただくことを推奨しております。
DNSサーバーやDHCPサーバーは別拠点のものを使用している場合にはインターネット接続ができなくなる恐れがあります。
DNSサーバーとして社内のオンプレミス環境を使用している場合（例：DNSサーバーがHQに存在する場合）、DCがダウンしていることで名前解決が失敗します。
Network CがHQ(head quarter)としたとき、HQにあるDNSサーバーでの名前解決が必要な通信は、この影響で失敗する可能性があります。
フェールセーフ設定について
オンプレミスのMXをHub拠点として追加することで、上記の状況で発生する動作を回避することができます。
以下に、HQにオンプレミスのDNSやDHCPサーバーが存在する場合を想定した構成例を示します。
Network CがHQとした場合にこの拠点をHubとすることで、サイト間VPN接続を担保することができます。
図3：参加しているMerakネットワークの一つをHubにした場合の構成例
オンプレミスのDNSやDHCPサーバーを考慮しない場合には最も上位モデルのMXをHubとしていただくのが良いものと存じます。
構成手順を以下に説明します。
1,下記のドキュメントを参考にCisco Secure Connect SitesにMerakiの拠点をHubとして登録
Meraki SD-WAN Hub Integration with Secure Connect - Cisco Meraki Documentation
登録後、上記で追加した拠点のSites Featuresが"Hub"になっていることを、Secure Connect>Sitesページからご確認ください。
図3：参加しているMerakネットワークの一つをHubにした場合のSitesページの画面
2,各拠点のサイト間VPNページにてHubsの項目にて、Add a hub (ハブを追加)をクリックし、手順1で追加したHubを選択し保存
※上記のドキュメントに記載されている通り、HubsにはIPv4 default routeのチェックを入れない
この設定は2通りあり、ネットワーク要件によって構成が二分されます。
それぞれのメリットとデメリットが存在するため、以下に例を記載します。
・拠点間の通信を直接通信とする。
1つ目にオンプレミスのMXとすることで、ネットワークリソースを効率的に利用することができますが、
Meraki HUB経由でアクセスすることにより、Cisco Secure Connectが提供するCDFW（クラウド型ファイアウォール）を通過しないため、以下の問題が発生します。
- アプリケーション制御の一元管理ができなくなる
- 拠点間の全ての通信がアクティビティログ上に記録されなくなる
- ポリシーの一貫性
図4：Hubsの設定内容
Network CをHQとしたとき、上記の設定の場合HQがダウンするとNaritaにfailoverし、さらにNaritaがダウンするとSingaporeにfailoverします。
※上から順番に使用します。
・拠点間の通信をCisco Secure Connect経由にする。
1つ目をCisco Secure Connectとすることで、Spoke間通信はCisco Secure Connectが提供するCDFW（クラウド型ファイアウォール）を通過します。
しかし、SpokeMXとHubMXの直接通信については直接接続のBGPピアを使用するため、この通信についてはCDFWを経由しなくなります。
※普段は全く使用しない予備機MXをオンプレミスのHUB拠点用に用意しておくことで回避は可能です
また、インターネット通信と拠点間通信が同じSecure Connect拡張ヘッドエンドを共有することになるため、直接拠点間の通信を行った場合よりもスループットが低下することが見込まれます。
図5：Hubsの設定内容
上記の場合でも、Network CをHQとしたとき、上記の設定の場合NaritaがダウンするとSingaporeにfailoverし、さらにSingaporeがダウンするとHQにfailoverします。
※上から順番に使用します。
上記のため、拠点間通信についてはumbrellaのアクティビティログに残らなくても問題ないという環境であれば、このフェールセーフの構成は気軽に使用できますが、全てのトラフィックをCisco Secure Connectが提供するCDFW（クラウド型ファイアウォール）を通過するようにしたい場合には追加のリソースが必要となります。
ハブ統合のための柔軟な設計
現在は、「2025 プラットフォーム最適化」がリリースされており、新しい制御機能により、MXスポークとハブの異なる設定により、より柔軟なネットワーク設計が可能になります。
クラウドファブリックパスを使用して、登録済みのすべてのMXスポークとハブを相互接続できます。
Meraki 組織を最適化するには、Secure Connect サポートケースを開き、「2025 プラットフォーム最適化」をリクエストをください。
Meraki SD-WAN ハブと Secure Connect の統合
※これらの最適化を適用するには、短時間のダウンタイムが必要となりますのでご注意ください。
※すべてのMXブランチの設定とルートがリセットされ、既存の全体のフットプリントが削減されます。
※シスコのサポートエンジニアが詳細についてご説明し、ネットワーク運用への影響を最小限に抑える最適なタイミングを調整をお願いいたします。
