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の設計・構築前に
- 本記事の設定方針
- DC-DC Failoverに関して
- 検証構成
- AWS MarketplaceからCisco Meraki vMXのSubscribe
- Meraki Dashboard API Keyの用意
- AWS Quick Startsによるデプロイ
- Meraki vMXのステータスの確認
- AWSのRoute Table & Transit Gateway Route Tableの事後 (After)確認
- MerakiのAuto VPNの設定
- AWSのRoute Table & Transit Gateway Route Tableの事後 (After)確認
- 関連記事
Meraki vMX向けのAWS Quick Startsの概要
Meraki vMXをAWSのBest Practicesに従ってデプロイするためのAWS CloudFormationのテンプレートが、Cisco社とAWS社により共同で作成されています。
本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のスクリプトが公開されているので、必ず情報の把握に努めてください。
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自体に関しては下記の記事を参照してください。
DC-DC Failoverの構成はHub間のループが発生してしまうため、対処方法は下記を参照してください。
検証構成
筆者の検証構成では、
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によるデプロイのみを取り扱います。
また、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ボタンを押下します。Terms and Conditionsをよく読んだ上で、合意するのであればAccept Termsボタンを押下します。Cisco Meraki vMXがSubsrcibeされるとAWS Marketplace > Manage subscriptionsに表示されます。
Meraki Dashboard API Keyの用意
Meraki Dashboard APIを用いるため、Meraki Dashboard上で予めAPI Keyの発行が必要になります。
AWS Lambdaのスクリプトを確認すると、読み取り系のMeraki Dashboard APIしか使用していなかったため、 筆者の場合はOrganizationに対してRead Onlyの権限を設定したAccountでAPI Keyを発行しました。
Meraki Dashboard APIを使用するには、大きく分けて2つの手順があります。 セキュリティ観点を含めたAPI Keyの設定の詳細に関しては、下記の記事にまとめているので参考にしてください。
本記事内ではAPI Keyの発行までを簡潔に紹介します。
OrganizationレベルでAPIの有効化
メニュー:
Organization > SettingsよりDashboard API accessセクションにあるAPI Accessにて、Organizationに対するAPIアクセスを有効にします。
AccountでAPI Keyを生成
メニュー:
Account名 > My profileよりAPI accessセクションにあるGenerate new API keyでAPI Keyを生成して情報を控えます。API Keyが漏洩すると悪用される危険性があるため厳重に管理します。
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にする必要がありません。Networkを作成すると、メニュー:
Security & SD-WAN > Appliance statusの画面に移動します。 Meraki vMXのライセンス登録状況に応じて、Add-vMX-S,Add-vMX-M,Add-vMX-Lのボタンが表示されるので、追加対象のボタンを押下します。
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ボタンから追加します。
MerakiのNetworkにTagの追加 (1/2) 
MerakiのNetworkにTagの追加 (2/2)
AWS Quick Startsによるデプロイ
Regionの移動
EC2 DashboardからKey Pairの用意
EC2 Dashboard から メニュー: Security & Network > Key Pairs でSSH Keyを予め発行しておきます。
CloudFormationでデプロイする際にKey Pairの指定が必須になっているためです。
ですが、Meraki vMXはSSHログインしてのコマンド操作には対応していないため、実質的にはSSHで接続する必要性はありません。
CloudFormationによるデプロイ
AWS Quick StartsのMeraki vMXのページに移動して、
How to deployタブよりDeploy Cisco Meraki Virtual MX into a new VPCを押下します。aws.amazon.com
AWS Quick StartsのMeraki vMX
Step 1: Specify template
デプロイ先のRegionに移動します。
AWSのRegionの指定 Amazon S3 URLにAWS 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 | MerakiのAPI 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分に変更しています。 |
| Key pair name | 事前に用意したKey Pairを指定 | Key pair name を指定しないとエラーでCloudFormationの処理が止まってしまいます。 |
参考情報としてデフォルト値の画面を掲載します。
Meraki Organization IDの確認
Meraki Dashboard の画面下部に 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 instance と Authentication token, second vMX instance にはMeraki vMXの認証トークンを指定します。
Meraki Dashboardのメニュー: Security & SD-WAN > Appliance status に移動して、Meraki vMXのデバイスの画面から Generate authentication token... ボタンを押下すると認証トークンが発行が可能です。
なお、Meraki vMXがMeraki Cloudに接続して認証できる状態になるまで1時間以内になるようにしてください。
Meraki vMXのインスタンスのタイプ
Meraki vMXは、vMX-S, vMX-M, vMX-Lのライセンス種別によってAWS側で指定すべきインスタンスのタイプが異なります。
ドキュメントを確認にして適切なインスタンスのタイプを指定します。
documentation.meraki.com
AWS Lambdaスクリプトの実行間隔
AWS Lambdaスクリプトの実行間隔は CloudWatch Events rule rate で指定します。
デフォルトでは rate(10 minutes) となっており、障害の検知時間を短くするのであれば rate(1minutes) に変更してください。
Step 3: Configure stack options
Step 3ではCloudFormationのStackのオプションを適宜指定します。
参考情報としてデフォルト値の画面を掲載します。
筆者は生成されたリソースを追いやすくするために、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
Meraki vMXのステータスの確認
Primary vMXとSecondary vMXがMeraki Cloudとの接続性があり、Portsの状態が取得できているかを確認します。 もしMeraki vMXがMeraki Cloudとの接続性がなければ、Portsの状態が取得できないままになります。
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) しか載りません。
AWSのTransit Gateway Route Tableの事前 (Before)確認
Transit Gateway Route Table: Cisco-Meraki-Sd-Wan-Vmx-WorkloadStack-... には CIDR block for the VPC で指定したVPCのCIDRブロックしか載りません。
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と同じサブネットの範囲を指定します。
- 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番目に指定します。
- 全ての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 に反映されます。
ここまでの手順でCloudFormationによるデプロイと、AWS Lambdaスクリプトが動作しているかの簡単な確認が終わりとなります。
