概要
Meraki MXのDC-DC Failover構成では、Hub間でループするのが想定動作になります。
筆者がDC-DC Failover構成の検証をMXとvMXで行った際は、実際にはループが発生しませんでした。
そのため仕様の確認をサポートに行いましたが、
例え実際にはループが発生していなくても、ループするのが想定動作 であるため、ループする前提で扱うべき 旨の回答をサポートから得ております。(2022年03月頃)
そして、DC-DC Failover構成でHub間のループを防ぐには「Hub間のルート交換の無効化」 をサポートへ依頼する必要があります。
しかし、Organization全体レベルでの有効化が推奨であるため影響範囲が大きくなります。
なお、Networkレベルでの有効化は、「Hub間のルート交換の無効化」の適用の有無によって、意図しないルートのリークが発生する可能性があるため非推奨になります。
また、「Hub間のルート交換の無効化」をしてしまうと、DCとPublic Cloudで多面的なDC-DC Failover構成が取れなくなってしまいます。
詳細情報
Meraki MXではPrimary DCとSecondary DCでDCレベルの冗長化 を行うような構成を、DC-DC Failoverと呼んでいます。
自然災害などの災害対策に、DR (Disaster Recovery)環境を構成するイメージになります。
補足ですが、仮想アプライアンス のvMXで冗長化 構成を取る際は、Warm-Spare構成が組めないため、同一Region内の冗長化 であっても原則的にDC-DC Failoverの構成になります。
DC-DC Failoverの構成では、Primary DCとSecondary DCがDC間接続を行っている想定しており、どちらのDCを介しても同じNetworkに接続できる状態を作ります。
そのため、Primary DCのMXと、Secondary MXのDCが同じルートを広報する状態が出来上がります。
DC-DC Failover構成
Meraki MXのAuto VPN 経由の経路は、Auto VPN Peerの状態に関わらず常にルートがインストールされてUpしている状態となりますが、
DC-DC Failoverでは例外的にダウン検知が行われます。Primary DCとSecondary DC経由のルートの切り替えが行われなければDCレベルのFailoverが行えないためです。
DC-DC Failover構成で同一のルート が複数のHubから広報されていると、Auto VPN Peerの状態をトラッキング してダウン検知を行ってルートの切り替えを行います。同一ルートが複数のHubから広報される点 が、ループの原因となります。
MXはルーティング テーブルの学習の優先度があり、Auto VPN 経由よりStatic Routeが優先されますが、
Passthrough or VPN Concentrator ModeのMXは、Static Routeを管理系 (Underlay)のDefault Gateway (0.0.0.0/0)しか設定できないため、
Longest MatchにてAuto VPN 経由で学習したAuto VPN Peerのルートがインストールされます。
管理系 (Underlay)のStatic Routeは、Local Status Pageで設定する Gateway を指しています。また、Uplink側に対して個別のStatic Routeは設定できません。
Local Status PageのGateway の設定
ルートの学習の具体的な例ですが、例えばAuto VPN Peer経由のルートが「172.16.0.0/16」であった場合に、そのルートと同一のStatic Routeは存在しえないため[設定できないため]、
確実にAuto VPN Peer経由のルートがインストールされます。
そのため、Primary MXとSecondary MXが互いに互いをNext hopとして扱うためループの構成が出来上がります。
Hub間のループ
なお、Route Priorityに関しては下記のDocを参照してください。
documentation.meraki.com Route Priority
そして、Hub間のループを回避するためにはサポートに問い合わせて、「Hub間のルート交換の無効化」をする必要があります。
Hub間のルート交換の無効化
公式ドキュメントの情報源
Hub間ループの情報は、Meraki の公式ドキュメントではありませんが、下記の記事がまとまっております。
サポートの方からも、(Meraki の公式ドキュメントではなく)外部サイトの情報ではあるものの現在でも通じる参考情報として教えて頂いております。
apicli.com
ここまではループする前提で話を記載しましたが、筆者の環境ではループは発生しませんでした。
そのため、サポートに問い合わせ確認しましたが、現在でもループが発生するのが想定動作 の旨の回答がありました。
実際にループが発生していなくても、ループが発生するのが想定動作 であるので、
DC-DC Failover構成を組む際は「Hub間のルート交換の無効化」をサポートに依頼せざるを得なくなります。
本内容の証跡ですが、公式のドキュメントには記述が見当たらなかったため、サポートの方に依頼して日本語のドキュメントの方に情報を追記して頂きました。
よって、顧客から詳しい証跡を求められた場合は、それらの情報を伝えるしかありません。
また、筆者の環境でループが発生しなかった要因を推察しましたが、
eBGP MultihopでルートのFlapを防止するために、Local Networks 設定がStatic Route相当の扱いになっているのではないかと疑いました。
documentation.meraki.com
For eBGP multi-hop , this option is configured per neighbor. This value can be adjusted to peer the concentrator with something multiple hops away in the data center or cloud. If multihop is used AND the eBGP peer is also advertising the IP route that the MX is using to connect to the eBGP peer, 10.101.0.0/24 in the above example. Then this route MUST be added to the list of 'Local Networks' in the 'VPN settings' section above the 'BGP settings' section of the 'Site-to-site VPN ' page, as shown below:
しかしながら、Local Netwoks 設定の挙動の関係性もサポートに問い合わせましたが、特に関係ない旨の回答を得ています。Meraki MXの製品選定がリスクになりかねないため
再現環境を構築してサポートに問い合わせて確認を行っておりました。
結局のところは、想定される動作と実際の挙動は異なったままであり、挙動が異なる理由は不明のままとなります。
あくまでもサポートに問い合わせて想定動作 が分かったのみです。Meraki MXの提案や導入を行うのはリスクでしかないため、情報共有のために本記事を執筆しております。
グランド デザインへの影響
Hub間ループの回避策である「Hub間のルート交換の無効化」はとても影響が大きいため、グランド デザインに大きく跳ねる点に留意してください。
Meraki MX & vMXの提案や導入が破綻しかねないほどの影響があります。
実例を挙げると、Primary DC & Secondary DCの災害対策を行ってる環境に、
さらにAWS やAzureなどのPublic Cloudを追加しようとするとDC-DC Failover構成では「Hub間のルート交換の無効化」せざるを得ないため、
DC面とPublic Cloud面の間でルート交換できない状態になり、DCとPublic Cloud間で業務通信が行えなくなります。
また、DCのMeraki MXを廃止してPublic CloudのvMXへ移行するような案件では、移行のための並行稼働の期間を取らざるを得ないと、
移行設計のフェーズで問題になる可能性もあります。そのため多角的な視野で問題がないか確認してください。
DC & Public CloudのDC-DC Failover多面構成
本記事は2022年03月頃の情報を元にしております。
本内容は仕様に大きく依存して挙動に不明な点も残っているため、最新の情報は公式ドキュメントを確認したりサポートへ問い合わせて確認してください。
別見解の情報 (2022年10月04日に追記)
筆者がDC-DC Failoverにおけるルーティング ループの話をコミュニティに書き込んだ際に、Meraki のエンジニアの方からサポートの方と別の見解を述べられたので最新の情報を適宜確認してください。
その別見解もドキュメントには明記されてないため、最終的に何が正しいのか不明です。
community.meraki.com
