Meraki MXでDC間の冗長化 や、Warm-Spareに非対応なMeraki vMX (Virtual MX)で冗長化 する場合は、DC-DC Failoverの構成を取る必要があります。
documentation.meraki.com
下記のイメージ図は、DC-DC Failoverを成り立たせている必須級の要素を表したものです。
表現を変えると、MXでDC間の冗長化 を行うには、この必須級の要素を満たさなければならないため、
DC-DC Failover構成における設計の要所を理解しておく必要があります。
DC-DC Failoverの構成
Meraki MX, vMXのModeとDC-DC Failoverの関係性DC-DC Failover構成では、DC側のMXは Passthrough or VPN Concentrator Mode である必要があるため、その理屈を順を追って紹介します。
Meraki MXには2種類のModeがあります。
Routed Mode
Passthrough or VPN Concentrator Mode
Meraki MXの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の名称が異なります。
vMX Setup Guide for Microsoft AzureよりvMXの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日付けで上述の内容を訂正しております。
myhomenwlab.hatenablog.com
vMXは各種Public Cloudに対応しているため、Modeの記述は各Public Cloud向けのドキュメントに記載があります。
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
DC側のMXは原則的にOne-Armed構成
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が一意に特定できなくなるからです。
Routed ModeではAuto VPN へ参加するサブネットの重複は許されない
それに対して Passthrough or VPN Concentrator Mode がAuto VPN へ参加する際は、サブネットの重複が許容されます。
Auto VPN 内にサブネットが重複して広報されていても、DC間接続の渡りによってどちらのDC経由でも到達性が確保されているためです。
DC-DC Failover構成ではDC間接続により到達性を確保
なお、DC側をRouted Modeにして、MXから対向DCにStatic Routeを向けつつ、そのStatic RouteをAuto VPN に広報するのもサブネット重複の制約に引っかかるためできません。
DC-DC Failover構成は、DC側をRouted Modeにはできない = Routed Modeでは成り立たない
更に補足すると、Routed Modeはサブネットの重複が許されないため、
同一拠点内でMX (シングル・Warm-Spare構成)を複数セット用意して、一つの拠点で複数のInternetの出口を向くような構成が実質的にできなくなります。
同一拠点でRouted ModeのMXを複数セット構築しようとすると、サブネット重複の制約に引っかかる
上述のRouted ModeにおけるAuto VPN 内のサブネット重複の制約により、DC側に設置するMXは必然的に Passthrough or VPN Concentrator Mode となります。
Spoke発の通信フロー
Spokeの視点で、複数のHubから同一のルートが広報されている場合は「Hubの優先度」に従ってルーティングが行われます。トラブルシューティング を複雑化してしまうため、DC内のルーティング設計には留意してください。
Spoke発の通信フロー
Hubの優先度の設定箇所
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構成では、DC間接続があるため障害時の迂回が可能
DC-DC FailoverはHubから同一ルートを広報する
DC-DC Failoverの構成ではDC側のHubは同一サブネット長のルート を広報する必要があります。同一のルートでなければFailoverの対象にならないためです。
そのため、Logest Matchで一方のDCを優先させる制御はできなくなります。
【NG例】DC-DC FailoverのHubは、同一ルートを広報する必要がある
補足ですが、MX Routing Behavior の DC-DC Failover のセクションによると、サポートへ連絡すればLongest Matchによる制御にも対応可能にはなるようです。
documentation.meraki.com
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間のループが発生するのが想定動作となります。
myhomenwlab.hatenablog.com
DC-DC FailoverのFailoverの時間
DC-DC Failover構成では、Spokeから見たHubへのFailoverの時間は 20 ～ 30 秒になっております。
また、HubからSpokeへのFailoverは、ルーティング設計に依存する点に留意してください。
さらに、vMXをPublic Cloudに導入した場合は、Public Cloudの基盤側がRoute Tableの制御を持つため、冗長化 の切り替えスクリプト や、BGPによる動的ルーティングの切り替えにFailoverの時間が依存します。
documentation.meraki.com
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 Failover Times
最後に
Meraki MXはクラウド 管理型のため、Internetへの接続性に大きく依存しています。
そして、そのInternetは不特定多数のネットワークが集まって成り立っているため、専用線 を用いてSLA が保証されている閉域網よりは不安定と表現できるかもしれません。
その対策として、Meraki MXはルーティングに対してはフラップが発生しにくい仕組みを取っていると推察されます。
そのため、一般的なR&Sと比較すると特殊な挙動となっており、DC-DC Failoverはその最たる例と言えると筆者は考えております。
また、Meraki MXは特殊な挙動同士が密接に関係しているため、意図しない挙動による考慮漏れが生まれないように、原則的にBest Practicesに沿って設計すべきです。Meraki MXの導入は避けるべきです。Meraki MXの特殊な挙動を全て読み切るのは難しく、多機能でもないため設計によるリカバリ も困難であり、複雑な要件を個々に対応していくのが実質的に不可能なためです。
要は、プロの料理人が書き残したBest Practicesと呼ばれるレシピに、素人が自己流のアレンジを加えるようなやり方をすべきではありません。
Meraki MXに限らない話ですが、製品特性を踏まえて導入すべきです。
