Meraki MXでDC間の冗長化や、Warm-Spareに非対応なMeraki vMX (Virtual MX)で冗長化する場合は、DC-DC Failoverの構成を取る必要があります。
DC-DC Failoverの情報は下記の公式ドキュメントに記載がありますが、「何故そのような仕組みになっているのか？」までは明記されていません。
そのため、DC-DC Failoverを成り立たせている要素を本記事では整理して紹介します。
下記のイメージ図は、DC-DC Failoverを成り立たせている必須級の要素を表したものです。 表現を変えると、MXでDC間の冗長化を行うには、この必須級の要素を満たさなければならないため、 DC-DC Failover構成における設計の要所を理解しておく必要があります。
- Meraki MX, vMXのModeとDC-DC Failoverの関係性
- Auto VPNへの参加とサブネットの重複
- Spoke発の通信フロー
- Auto VPN Peerの状態とAuto VPN Routeの関係性
- DC-DC FailoverはHubから同一ルートを広報する
- DC-DC Failover構成におけるHub間のループ
- DC-DC FailoverのFailoverの時間
- 最後に
Meraki MX, vMXのModeとDC-DC Failoverの関係性
DC-DC Failover構成では、DC側のMXは Passthrough or VPN Concentrator Mode である必要があるため、その理屈を順を追って紹介します。
Meraki MXのMode
Meraki MXには2種類のModeがあります。
- Routed Mode
- Passthrough or VPN Concentrator Mode
Routed Mode は拠点のInternetを収容するのに向いているModeです。 DC-DC Failover構成では、DC側に設置するMXは必然的に Passthrough or VPN Concentrator Mode となります。 表現を変えると、DCのInternet収容をMXですべきではありません。 DC側を Routed Mode にしてしまうと、Primary DCとSecondary DCによるDC間の冗長化が行えなくなってしまいます。
Meraki vMX (Virtual MX)のMode
仮想アプライアンスのvMX (Virtual MX)では、物理アプライアンスのMXとModeの名称が異なります。
Concentrator Mode の中に One-Armed Concentrator と NAT Mode Concentrator の区分があります。 MXのPassthrough or VPN Concentrator Mode は、vMX (Virtual MX) では One-Armed Concentrator に相当します。
そのため、本記事内での Passthrough or VPN Concentrator Mode は vMX の One-Armed Concentrator を含んだ意味合いとして解説します。
Concentrator Mode の中に One-Armed Concentrator と NAT Mode Concentrator の区分がありますが、基本的には One-Armed Concentrator となります。
そしてvMXがどちらのModeであっても、MXで言えば Passthrough or VPN Concentrator Mode に相当します。
そのため、本記事内での Passthrough or VPN Concentrator Mode は vMX を含んだ意味合いとなります。
筆者の解釈に誤りがありましたので、2022年06月21日付けで上述の内容を訂正しております。
NAT Mode Concentrator の詳細は下記の記事で解説しております。
vMXは各種Public Cloudに対応しているため、Modeの記述は各Public Cloud向けのドキュメントに記載があります。
vMX Setup Guide for Amazon Web Services (AWS) - Cisco Meraki
vMX Setup Guide for Google Cloud Platform (GCP) - Cisco Meraki
DC側のMXは原則的にOne-Armed構成
DC側に設置するMXは必然的に Passthrough or VPN Concentrator Mode になる点を紹介しました。 その Passthrough or VPN Concentrator Mode は、Passthrough と VPN Concentrator の言葉が混ざっており、 構成のイメージが大きく分けて2パターンあるように取れますが、原則的にDC側はOne-Armed構成のVPN Concentratorとなります。
Meraki MXはBPDUを透過するのみでSTPに対応していない点、LAGを組めない点があり、Passthrough構成にすると冗長性に問題が出ます。
Auto VPNへの参加とサブネットの重複
MXがAuto VPNへ参加する際は、Routed Modeの場合はAuto VPN内でサブネットが一意である必要があります。(Routed ModeではAuto VPN内でサブネットの重複が許されません。)
Routed ModeのMXは拠点のInternet収容用途がメインになるため、 例えば拠点1と拠点2で物理的に分かれていてLAN内のネットワークも分断されているのに、 サブネットが重複していたら送るべきAuto VPN Peerが一意に特定できなくなるからです。
それに対して Passthrough or VPN Concentrator Mode がAuto VPNへ参加する際は、サブネットの重複が許容されます。 Auto VPN内にサブネットが重複して広報されていても、DC間接続の渡りによってどちらのDC経由でも到達性が確保されているためです。
なお、DC側をRouted Modeにして、MXから対向DCにStatic Routeを向けつつ、そのStatic RouteをAuto VPNに広報するのもサブネット重複の制約に引っかかるためできません。
更に補足すると、Routed Modeはサブネットの重複が許されないため、 同一拠点内でMX (シングル・Warm-Spare構成)を複数セット用意して、一つの拠点で複数のInternetの出口を向くような構成が実質的にできなくなります。
上述のRouted ModeにおけるAuto VPN内のサブネット重複の制約により、DC側に設置するMXは必然的に Passthrough or VPN Concentrator Mode となります。
Spoke発の通信フロー
Spokeの視点で、複数のHubから同一のルートが広報されている場合は「Hubの優先度」に従ってルーティングが行われます。
優先度によって一意に宛先が決まるため、負荷分散が行われない点に留意してください。
また、あくまでもSpoke発の通信に適用されるため、ルーティング設計によって「戻りの通信」が異なるHubから返ってくる可能性があります。
非対称ルーティングは、一般的に通信フローやトラブルシューティングを複雑化してしまうため、DC内のルーティング設計には留意してください。
Auto VPN Peerの状態とAuto VPN Routeの関係性
Auto VPN Routeは基本的にAuto VPN Peerの状態 (Up/Down)に関わらず、常にRoute tableにインストールされた状態になります。 一般的なRouting & Switchの知識がある方には不思議な挙動に見受けられると思われます。
理屈的には、Auto VPN Peerの状態をトラッキングしていなくても、Routed Modeはサブネットの重複が許されてないので迂回経路が発生せず、 Auto VPN PeerがDownしているのであれば、トラッキングの有無に関わらずに該当拠点への到達性がないのは当たり前になるからです。
ただし、DC-DC Failover構成ではDC間接続による冗長化を行っていると想定しているため、Primary DCとSecondary DCのどちらのDCからも到達性があります。 そのため、DC-DC Failover構成では例外的な挙動があります。 Passthrough or VPN Concentrator Mode の複数のHubが、同一サブネット長のAuto VPNのルートを広報している場合に、 対象Auto VPN Routeを持つAuto VPN Peerの状態を死活監視して、障害時はルートを切り替える挙動になっています。
DC-DC FailoverはHubから同一ルートを広報する
DC-DC Failoverの構成ではDC側のHubは同一サブネット長のルートを広報する必要があります。同一のルートでなければFailoverの対象にならないためです。 そのため、Logest Matchで一方のDCを優先させる制御はできなくなります。
補足ですが、MX Routing Behavior の DC-DC Failover のセクションによると、サポートへ連絡すればLongest Matchによる制御にも対応可能にはなるようです。
If you require the spoke MX to be able to failover to a hub with a less specific subnet, please contact Cisco Meraki Support.
ただし、例外的な挙動を許容した設計とすると、MXの製品特性を大きく逸脱しかねないためリスクが伴う点を理解すべきです。 例外的な挙動を許容しなければならない時点で、そもそも論としてシンプルが売りのMeraki MXを導入するのがリスクになります。
DC-DC Failover構成におけるHub間のループ
DC-DC Failover構成ではHub間のループが発生するのが想定動作となります。
そのため、Hub間のループを引き起こされないようにする必要がありますが、注意点もあるため下記の記事に個別にまとめております。
DC-DC FailoverのFailoverの時間
DC-DC Failover構成では、Spokeから見たHubへのFailoverの時間は 20 ～ 30 秒になっております。
また、HubからSpokeへのFailoverは、ルーティング設計に依存する点に留意してください。 さらに、vMXをPublic Cloudに導入した場合は、Public Cloudの基盤側がRoute Tableの制御を持つため、冗長化の切り替えスクリプトや、BGPによる動的ルーティングの切り替えにFailoverの時間が依存します。
Warning: Failover between datacenters typically occurs in 20 to 30 seconds after connectivity between the remote site and the datacenter is lost. The failover time will vary if utilizing BGP, due to the iBGP hold-timer.
Meraki SD-WAN のドキュメントの Failover Times のセクションの表には、他のFailoverの観点と一緒に記載があります。
documentation.meraki.com
最後に
Meraki MXはクラウド管理型のため、Internetへの接続性に大きく依存しています。 そして、そのInternetは不特定多数のネットワークが集まって成り立っているため、専用線を用いてSLAが保証されている閉域網よりは不安定と表現できるかもしれません。 その対策として、Meraki MXはルーティングに対してはフラップが発生しにくい仕組みを取っていると推察されます。 そのため、一般的なR&Sと比較すると特殊な挙動となっており、DC-DC Failoverはその最たる例と言えると筆者は考えております。
また、Meraki MXは特殊な挙動同士が密接に関係しているため、意図しない挙動による考慮漏れが生まれないように、原則的にBest Practicesに沿って設計すべきです。
表現を変えると、導入環境がBest Practicesに適合しないのであれば、Meraki MXの導入は避けるべきです。
Meraki MXの特殊な挙動を全て読み切るのは難しく、多機能でもないため設計によるリカバリも困難であり、複雑な要件を個々に対応していくのが実質的に不可能なためです。
要は、プロの料理人が書き残したBest Practicesと呼ばれるレシピに、素人が自己流のアレンジを加えるようなやり方をすべきではありません。 Meraki MXに限らない話ですが、製品特性を踏まえて導入すべきです。
