My Home NW Lab

逸般の誤家庭のネットワーク

AWS環境でのMeraki vMXのDC-DC Failover構成 (AWS Quick StartsによるVPC新規作成パターン)

Meraki vMXはWarm-Spareを組めないため、AWS環境ではVIP (Virtual IP)を用いたGateway冗長化が行えません。
そのため、Primary vMXとSecondary vMXの2台のMeraki vMXを用意しても、AWS側のRoute TableにはNext hopを1つしか設定できず、 障害時には何かしらの手段を用いてNext hopを切り替える必要があります。

幸いにもMeraki vMXのFailoverを自動的に行うためのAWS Lambdaスクリプトが存在するため、本記事ではCloudFormationによるデプロイ方法を紹介します。

Meraki vMX向けのAWS Quick Startsの概要

Meraki vMXをAWSのBest Practicesに従ってデプロイするためのAWS CloudFormationのテンプレートが、Cisco社とAWS社により共同で作成されています。

aws-quickstart.github.io

本CloudFormationのテンプレートは、Transit Gatewayを使用する構成を前提としています。 AWS基盤が管理するRoute tableのNext hopの切り替えが必要なため、 シンプルな設計にするにはトラフィックをTransit Gateway経由にしてルーティング情報を集中的に管理し、 Next Hopの操作対象のRoute Tableを限定する必要があるのが背景にあります。

そのため、Transit Gatewayを使用しない構成にはそのままでは適用できない点に留意してください。

Meraki vMXの設計・構築前に

Meraki vMX向けのAWS Quick Startsは、導入におけるあらゆる問題を解決するような銀の弾丸ではありません。 導入環境に応じての細かな調整が必要になる可能性があります。 そのため、関連する資料は全て目を通して、スクリプトの挙動なども把握して考慮点がないか確認してください。

Meraki vMXはネットワーク機器の分類になるため、大きくはネットワーク エンジニアの範疇になると思われます。 しかしながら、スクリプトの挙動や、Public CloudであるAWSの特性を加味した設計が必要になってくるため、 実案件ではプログラミングやPublic Cloudの知見があるエンジニアの存在が必要不可欠になります。

GitHub上のリポジトリにCloudFormationのテンプレートやAWS Lambdaのスクリプトが公開されているので、必ず情報の把握に努めてください。

github.com

AWS QuickStartsはCloudFormationのテンプレートを用いたデプロイを前提としているため、 既存のAWS環境の構成によってはCloudFormationによるデプロイが行えない可能性があります。 そうなると、CloudFormationで行われる設定内容を把握して、AWS Lambdaのスクリプトも個別にデプロイする必要が出てきてしまいます。 そのような状態になった際に、知見がなくてGitHub上に公開されている情報が把握できないなら目も当てられません。

本記事の設定方針

Meraki vMX向けのAWS Quick Startsによるデプロイは2種類のパターンがあります。

  • Deploy Cisco Meraki Virtual MX into a new VPC
    Meraki vMXを新しいVPCにデプロイする方法です。本記事ではこの手順を扱います。

  • Deploy Cisco Meraki Virtual MX into an existing VPC
    Meraki vMXを既存のVPCに展開する方法です。

DC-DC Failoverに関して

Meraki vMXの冗長化は、DC-DC Failoverの構成となります。

  • DC-DC Failover自体に関しては下記の記事を参照してください。

    myhomenwlab.hatenablog.com

  • DC-DC Failoverの構成はHub間のループが発生してしまうため、対処方法は下記を参照してください。

    myhomenwlab.hatenablog.com

検証構成

筆者の検証構成では、 AWS側のVPCに 10.253.0.0/16 を割り当てて、そのアドレスの範囲から Public Subnet 1 には 10.253.0.0/24 と、Public Subnet 2 には 10.253.1.0/24 を払い出しています。
拠点のLAN側には 10.255.11.0/24 のサブネットが存在し、AWS側のMeraki vMXが学習するAuto VPN Routeとなっています。

なお、本記事の中では疎通確認用のEC2インスタンスは作成せず、AWS Quick Startsによるデプロイのみを取り扱います。

f:id:myhomenwlab:20220412155955j:plain
検証構成 (AWS視点)

f:id:myhomenwlab:20220412160018j:plain
検証構成 (Meraki視点)

また、AWSのRegionは Asia Pacific (Tokyo): ap-northeast-1 を指定しています。 筆者の検証時の所感ですが、拠点間の物理距離が離れているとAuto VPN経由の通信のパケットのドロップが気になったので、国内のRegionを指定しています。

AWS MarketplaceからCisco Meraki vMXのSubscribe

Meraki vMXのインスタンスを作成するには、AWS MarketplaceでCisco Meraki vMXをSubscribeしておく必要があります。

  • AWS Marketplaceで下記の Cisco Meraki vMX にアクセスして、Continue to Subscribe ボタンを押下します。

    aws.amazon.com

    f:id:myhomenwlab:20220402123831j:plain
    AWS MarketplaceからCisco Meraki vMXのSubscribe (1/3)

  • Terms and Conditions をよく読んだ上で、合意するのであれば Accept Terms ボタンを押下します。

    f:id:myhomenwlab:20220402123901j:plain
    AWS MarketplaceからCisco Meraki vMXのSubscribe (2/3)

  • Cisco Meraki vMX がSubsrcibeされると AWS Marketplace > Manage subscriptions に表示されます。

    f:id:myhomenwlab:20220402124039j:plain
    AWS MarketplaceからCisco Meraki vMXのSubscribe (3/3)

Meraki Dashboard API Keyの用意

Meraki Dashboard APIを用いるため、Meraki Dashboard上で予めAPI Keyの発行が必要になります。

AWS Lambdaのスクリプトを確認すると、読み取り系のMeraki Dashboard APIしか使用していなかったため、 筆者の場合はOrganizationに対してRead Onlyの権限を設定したAccountでAPI Keyを発行しました。

f:id:myhomenwlab:20220411092726j:plain
AWS Lambdaスクリプト向けのアクセス権限

Meraki Dashboard APIを使用するには、大きく分けて2つの手順があります。 セキュリティ観点を含めたAPI Keyの設定の詳細に関しては、下記の記事にまとめているので参考にしてください。

myhomenwlab.hatenablog.com

本記事内ではAPI Keyの発行までを簡潔に紹介します。

OrganizationレベルでAPIの有効化

  • メニュー: Organization > Settings より Dashboard API access セクションにある API Access にて、Organizationに対するAPIアクセスを有効にします。

    f:id:myhomenwlab:20220324000214j:plain
    API Access

AccountでAPI Keyを生成

  • メニュー: Account名 > My profile より API access セクションにある Generate new API keyAPI Keyを生成して情報を控えます。API Keyが漏洩すると悪用される危険性があるため厳重に管理します。

    f:id:myhomenwlab:20220324000233j:plain
    API keys

Meraki vMXのNetwrokの作成

  • Meraki vMXはWarm-Spare構成を組めないため、1台目 (Primary vMX)と 2台目 (Secondary vMX)のNetworkで個別に作成します。
    筆者は下記のようなNetwork名で作成しております。適宜読み替えてください。

    Network名 用途
    NW_AWS_vMX1 Primary vMX向け
    NW_AWS_vMX2 Secondary vMX向け
  • メニュー: Organization > Create network に移動します。

  • 設定項目: Network type には Security appliance を指定して、任意の名称でNetworkを作成します。
    備考: AWS向けのNetworkには、Meraki vMX以外を所属させる余地がないため Combined hardware にする必要がありません。

    f:id:myhomenwlab:20220402124326j:plain
    Meraki DashboardでNetwrokの作成

  • Networkを作成すると、メニュー: Security & SD-WAN > Appliance status の画面に移動します。 Meraki vMXのライセンス登録状況に応じて、Add-vMX-S, Add-vMX-M, Add-vMX-L のボタンが表示されるので、追加対象のボタンを押下します。

    f:id:myhomenwlab:20220402124517j:plain
    Meraki vMXデバイスの追加ボタン
    f:id:myhomenwlab:20220402124528j:plain
    Meraki vMXデバイスの追加後の表示

Meraki vMX用NetworkへのTagの追加

  • メニュー: Organization > Overview に移動します。

  • Cisco Meraki vMXのPrimary MXとSecondary MXになるNetworkに対して、一意なTagを追加します。
    筆者の環境では下記のように指定しております。AWS Lambdaのスクリプトから参照される情報になります。

    Network名 用途 Tag
    NW_AWS_vMX1 Primary vMX向け AWS_vMX1
    NW_AWS_vMX2 Secondary vMX向け AWS_vMX2

    対象のNetworkを一つずつ選択して、Tag ボタンから追加します。

    f:id:myhomenwlab:20220402125911j:plain
    MerakiのNetworkにTagの追加 (1/2)

    f:id:myhomenwlab:20220402125721j:plain
    MerakiのNetworkにTagの追加 (2/2)

AWS Quick Startsによるデプロイ

Regionの移動

  • AWS ConsoleからRegionを明示的に選択します。
    筆者は Asia Pacific (Tokyo) に指定しています。適宜読み替えてください。

    f:id:myhomenwlab:20220402131718j:plain
    AWSのRegionの選択

EC2 DashboardからKey Pairの用意

EC2 Dashboard から メニュー: Security & Network > Key PairsSSH Keyを予め発行しておきます。
CloudFormationでデプロイする際にKey Pairの指定が必須になっているためです。 ですが、Meraki vMXはSSHログインしてのコマンド操作には対応していないため、実質的にはSSHで接続する必要性はありません。

f:id:myhomenwlab:20220402133224j:plain
Key Piarの用意

CloudFormationによるデプロイ

  • AWS Quick StartsのMeraki vMXのページに移動して、How to deploy タブより Deploy Cisco Meraki Virtual MX into a new VPC を押下します。

    aws.amazon.com

    f:id:myhomenwlab:20220411093851j:plain
    AWS Quick StartsのMeraki vMX

Step 1: Specify template

  • デプロイ先のRegionに移動します。

    f:id:myhomenwlab:20220411094654j:plain
    AWSのRegionの指定

  • Amazon S3 URLAWS Quick StartsのMeraki vMX向けのURLが指定されているのを確認します。
    筆者が確認した際のURLは下記となっております。

    URL: https://aws-quickstart.s3.us-east-1.amazonaws.com/quickstart-cisco-meraki-sd-wan-vmx/templates/quickstart-cisco-meraki-sdwan-vmx-entrypoint-new-vpc.template.yaml

Step 2: Specify stack details

環境に応じたパラメータを入力してデプロイします。筆者が検証した際の情報を参考に記載します。
補足が必要なパラメータは個別に解説していきます。

設定項目 設定値 備考
Stack name Cisco-Meraki-Sd-Wan-Vmx CloudFormationのStackの名称です。Stackを識別しやすい任意の名称を指定します。
Meraki organization ID MerakiのOrganization IDを指定
Meraki organization API key MerakiAPI Keyを指定
Number of vMX instances 2 デフォルト値のままです。最小冗長構成の2台でvMXのInstanceを作成します。
Authentication token, first vMX instance 1台目のvMXの認証トーク vMXの1台目の認証トークンを発行して貼り付けます。都度変わるため毎回手動で貼り付けが必要です。
Authentication token, second vMX instance 2台目のvMXの認証トーク vMXの2台目の認証トークンを発行して貼り付けます。都度変わるため毎回手動で貼り付けが必要です。
Availability Zones to use for the SD-WAN VPC subnets ap-northeast-1a , ap-northeast-1c 筆者の環境の例です。Regionに応じたAZを指定します。
Meraki network tag, first vMX instance AWS_vMX1 Tagのデフォルト値は vMX1 です。複数セット構築する場合は一意な値になるように調整します。
Meraki network tag, second vMX instance AWS_vMX2 Tagのデフォルト値は vMX1 です。複数セット構築する場合は一意な値になるように調整します。
CIDR block for the VPC 10.253.0.0/16 筆者の環境の例です。VPCのCIDR Blockを指定します。
CIDR block for public subnet 1 10.253.0.0/24 筆者の環境の例です。1台目のvMXが配置されるPublic Subnetを指定します。
CIDR block for public subnet 2 10.253.1.0/24 筆者の環境の例です。2台目のvMXが配置されるPublic Subnetを指定します。
Transit gateway ASN 65001 筆者の環境の例です。AS番号を指定します。
Amazon EC2 instance type vMXのライセンスに応じて指定 vMX-S, vMX-M の場合は c5.large を指定し、vMX-L の場合は c5.xlarge を指定します。
CloudWatch Events rule rate rate(1 minutes) デフォルト値は10分ですが、障害検知時間の短縮のために1分に変更しています。

参考情報としてデフォルト値の画面を掲載します。

f:id:myhomenwlab:20220411100140j:plain
Step 2: Specify stack detailsのデフォルト値

Meraki Organization IDの確認

Meraki Dashboard の画面下部に organization ID の情報が表示されます。

f:id:myhomenwlab:20220402135802j:plain
Meraki Organization IDの確認

Meraki organization API keyと権限

Meraki vMXのルーティング情報を読み込むのにAWS LambdaのスクリプトMeraki Dashboard APIを使用しています。
AWS LambdaからのMerakiに対する設定の権限は不要であるため、Read-only の権限で専用のAccountを用意してAPI Keyを発行するのが好ましいです。

認証トークンに関して

Authentication token, first vMX instanceAuthentication token, second vMX instance にはMeraki vMXの認証トークンを指定します。
Meraki Dashboardのメニュー: Security & SD-WAN > Appliance status に移動して、Meraki vMXのデバイスの画面から Generate authentication token... ボタンを押下すると認証トークンが発行が可能です。
なお、Meraki vMXがMeraki Cloudに接続して認証できる状態になるまで1時間以内になるようにしてください。

f:id:myhomenwlab:20220411200716j:plain
認証トークンの発行 (1/2)

f:id:myhomenwlab:20220411200724j:plain
認証トークンの発行 (2/2)

Meraki vMXのインスタンスのタイプ

Meraki vMXは、vMX-S, vMX-M, vMX-Lのライセンス種別によってAWS側で指定すべきインスタンスのタイプが異なります。
ドキュメントを確認にして適切なインスタンスのタイプを指定します。

documentation.meraki.com

f:id:myhomenwlab:20220411101357j:plain
vMX Comparison Datasheet

AWS Lambdaスクリプトの実行間隔

AWS Lambdaスクリプトの実行間隔は CloudWatch Events rule rate で指定します。 デフォルトでは rate(10 minutes) となっており、障害の検知時間を短くするのであれば rate(1minutes) に変更してください。

Step 3: Configure stack options

Step 3ではCloudFormationのStackのオプションを適宜指定します。
参考情報としてデフォルト値の画面を掲載します。

f:id:myhomenwlab:20220411201035j:plain
Step 3: Configure stack optionsのデフォルト値

筆者は生成されたリソースを追いやすくするために、Tag情報のみを明示的に設定しました。

f:id:myhomenwlab:20220411201111j:plain
Tag情報の指定

Step 4: Review

CloudFormationのテンプレート内でIAM (Identity and Access Management)リソースを作成する可能性があるため、 続行するには Capabilities のセクションで下記の2点に同意する必要があります。

  • I acknowledge that AWS CloudFormation might create IAM resources with custom names.

  • I acknowledge that AWS CloudFormation might require the following capability: CAPABILITY_AUTO_EXPAND

f:id:myhomenwlab:20220411214843j:plain
Step 4: Review の Capabilities

Meraki vMXのステータスの確認

Primary vMXとSecondary vMXがMeraki Cloudとの接続性があり、Portsの状態が取得できているかを確認します。 もしMeraki vMXがMeraki Cloudとの接続性がなければ、Portsの状態が取得できないままになります。

f:id:myhomenwlab:20220411213258j:plain
Meraki vMXのステータスの確認

AWSのRoute Table & Transit Gateway Route Tableの事後 (After)確認

Meraki vMXの冗長化が関係するAWSのルーティングの設定には Route Table と Transit Gateway Route Table があります。 Meraki vMXのAuto VPNの設定をまだ行っていない場合にどうなるか確認しておきます。

なお、Meraki Dashboard側の設定も完了してAWS Lambdaスクリプトが動作すると、 Meraki vMXが学習しているAuto VPN RouteがAWS側の Route Table と Transit Gateway Route Table に反映されます。

AWSのRoute Tableの事前 (Before)確認

Route Table: Public Subnets には local と igw (Internet Gateway) しか載りません。

f:id:myhomenwlab:20220411215846j:plain
AWSのRoute Tableの事前 (Before)確認

AWSのTransit Gateway Route Tableの事前 (Before)確認

Transit Gateway Route Table: Cisco-Meraki-Sd-Wan-Vmx-WorkloadStack-... には CIDR block for the VPC で指定したVPCのCIDRブロックしか載りません。

f:id:myhomenwlab:20220412121200j:plain
AWSのTransit Gateway Route Tableの事前 (Before)確認

MerakiのAuto VPNの設定

AWS環境のMeraki vMXをHubとして、AWS環境の各拠点がHub & Spoke構成になるように設定します。

Meraki vMXのAuto VPNの設定

  • Primary vMXとSecondary vMXのそれぞれに設定します。

  • メニュー: Security & SD-WAN > Site-to-site VPN に移動します。

  • Type の設定を Hub に指定します。

  • Local networks を下記のように設定します。

    Name Subnet 備考
    AWS_NW 10.253.0.0/16 Name は任意の名称を指定します、Subnet にはCloudFormationのテンプレートの項目にあった CIDR block for the VPC と同じサブネットの範囲を指定します。

f:id:myhomenwlab:20220411220859j:plain
Hub側のSite-to-site VPNの設定

  • Primary vMXとSecondary vMXの両方に設定を行うのを忘れないようにしてください。

SpokeのAuto VPNの設定

  • Auto VPNに参加する各Spokeに対して設定します。

  • メニュー: Security & SD-WAN > Site-to-site VPN に移動します。

  • Type の設定を Spoke に指定します。

  • Hubs を下記のように設定します。

    # Name IPv4 default route 備考
    1 NW_AWS_vMX1 Uncheck Primary vMXを1番目に指定します。
    2 NW_AWS_vMX2 Uncheck Secondary vMXを2番目に指定します。

f:id:myhomenwlab:20220411221541j:plain
Spoke側のSite-to-site VPNの設定

  • 全てのSpokeに設定を行うのを忘れないようにしてください。

AWSのRoute Table & Transit Gateway Route Tableの事後 (After)確認

Meraki Dashboard上でAuto VPNのHub & Spoke構成が適切に設定されると、 Primary vMXとSecondary vMXによって学習されるAuto VPN Routeの情報が、AWS LambdaスクリプトによってAWS側の Route Table と Transit Gateway Route Table に反映されます。

f:id:myhomenwlab:20220411221713j:plain
AWSのRoute Tableの事後 (After)確認

f:id:myhomenwlab:20220412121651j:plain
AWSのTransit Gateway Route Tableの事後 (After)確認

ここまでの手順でCloudFormationによるデプロイと、AWS Lambdaスクリプトが動作しているかの簡単な確認が終わりとなります。