Meraki vMX向けのAWS Quick Startsには、冗長化切り替え用のAWS Lambdaスクリプトが用意されておりますが、 実案件で使用するには挙動を把握しておく必要があるため各種情報を整理しました。
CloudFormationのテンプレートを用いたデプロイは下記の記事を参照してください。
本記事は2022年04月頃の情報に基づいています。今後、スクリプトに改修が入った場合は本記事と内容と差異が出る可能性があります。
- AWS Lambdaスクリプト本体の公開先
- AWS Lambdaスクリプトの動作イメージ
- Amazon CloudWatch Events (Amazon EventBridge)による定期実行
- AWS Lambdaスクリプトの設定確認
- AWS Lambdaスクリプトの環境変数
- EC2 InstanceとMeraki Dashbaord上のTag情報の紐付け
- AWS Secrets ManagerにAPI Keyを格納
- Meraki Dashboard API
- 障害検知の仕組み
- Primary vMXの障害復旧時のPreemptの動作
- 補足
- 関連記事
AWS Lambdaスクリプト本体の公開先
AWS Lambdaスクリプトの動作イメージ
AWS Lambdaスクリプトからの各種ステータス情報の取得や設定の更新があるため、関連要素との連携箇所を整理します。
- Amazon CloudWatch Events (Amazon EventBridge)から、AWS Lambdaスクリプトを定期的に実行します。
- AWS LambdaスクリプトはAWS Secrets ManagerからMeraki Dashboard APIのAPI Keyを入手します。
- AWS LambdaスクリプトはMeraki Dashboard APIによりAuto VPN Routeの情報を取得します。
- Meraki vMXのEC2 Instanceのステータス情報を取得して、AWS Lambdaスクリプトは障害状況の判断を行います。
- 障害状況を加味して、Transit Gateway Route TableとRoute Tableに対して、AWS LambdaスクリプトがAuto VPN Routeを反映します。
Amazon CloudWatch Events (Amazon EventBridge)による定期実行
Amazon CloudWatch Events (Amazon EventBridge)にて定期的にAWS Lambdaスクリプトを呼び出します。 CloudFormationのテンプレートでは、実行間隔のデフォルト値が10分間隔となっております。そして、最短でも1分間隔になります。
AWS Lambdaスクリプトの設定確認
CloudFormationのテンプレートからデプロイすると複数のFuntionが設定されます。
冗長化切り替え用のFunction名は接頭辞が Cisco-Meraki-Sd-Wan-Vmx-W-vMXTransitGatewayRTLambd- になります。
AWS Lambdaスクリプトの環境変数
環境変数を用いてAWS Lambdaスクリプトに環境個別の情報を与えます。
CloudFormationでデプロイすると、テンプレートに入力した項目が自動的に反映されます。
| 設定項目 | 設定例 | 備考 |
|---|---|---|
| MERAKI_ORG_ID | MerakiのOrganization IDを指定 | |
| RT_ID | (例) rtb-xxxx | Route TableのIDを指定します。 |
| TGW_ATTACH_ID | (例) tgw-attach-xxxx | Transit Gateway AttachmentのIDを指定します。 |
| TGW_RT_ID | (例) tgw-rtb-xxxx | Transit Gateway Route TableのIDを指定します。 |
| vMX1Tag | (例) AWS_vMX1 | CloudFormationのテンプレートを用いた場合のTagのデフォルト値は vMX1 です。複数セット構築する場合は一意な値になるように調整します。 |
| vMX2Tag | (例) AWS_vMX2 | CloudFormationのテンプレートを用いた場合のTagのデフォルト値は vMX2 です。複数セット構築する場合は一意な値になるように調整します。 |
筆者がCloudFormationでデプロイした際は、環境変数の MERAKI_API_KEY が存在してMeraki Dashboard API Keyが設定されていました。
ですが、API KeyはAWS Secrets Managerによる管理となるため本来は MERAKI_API_KEY の設定は不要となります。
追記: 2022年06月08日に筆者のPull Requestがマージされて MERAKI_API_KEY は設定されなくなりました。
EC2 InstanceとMeraki Dashbaord上のTag情報の紐付け
Meraki vMXのEC2 Instanceと、Meraki Dashboard上のNetworkに同名のTagを付与して、Primary vMXとSecondary vMXを紐付ける必要があります。
| 設定対象 | Key | Value | 備考 |
|---|---|---|---|
| Primary vMXのEC2 Instance | MerakiTag | (例) AWS_vMX1 | CloudFormationのテンプレートを用いた場合のTagのデフォルト値は vMX1 です。複数セット構築する場合は一意な値になるように調整します。 |
| Secondary vMXのEC2 Instance | MerakiTag | (例) AWS_vMX2 | CloudFormationのテンプレートを用いた場合のTagのデフォルト値は vMX2 です。複数セット構築する場合は一意な値になるように調整します。 |
vMX1Tag と vMX2Tag はPrimary vMXとSecondary vMXの識別に使われているので別々の値を指定してください。
また当たり前の話になりますが、冗長化対象のペアとなるPrimary vMXとSecondary vMXはAvailability Zoneを分けてください。
EC2 Instanceのイメージが破損するなどして再デプロイした際は、Tagの設定をし忘れないように留意してください。
AWS Secrets ManagerにAPI Keyを格納
AWS Secrets ManagerにはMeraki Dashboard APIで情報を取得するためのAPI Keyが格納されます。
| 設定項目 | 設定名 |
|---|---|
| Secret Name | MerakiAPIKey |
| Secret key | Secret value |
|---|---|
| MerakiAPIKey | Meraki Dashboard APIのAPI Key を格納します。 |
Issue #31 の修正によってAPI Keyを格納するためのSecret keyの名称が変更されました。merakiapikey からキャメル ケースの MerakiAPIKey に変わっています。画面キャプチャは修正前の掲載当時のままになっております。(2022年10月07日に追記)
Meraki Dashboard API
Meraki Dashboard APIは大まかに分けて下記の2つのAPIによって、Auto VPN Routeの情報を取得しています。
getOrganizationApplianceVpnStatuses
https://developer.cisco.com/meraki/api-v1/#!get-organization-appliance-vpn-statusesDescription:Show VPN status for networks in an organization
getNetworkApplianceVpnSiteToSiteVpn
https://developer.cisco.com/meraki/api-v1/#!get-network-appliance-vpn-site-to-site-vpn/Description:Return the site-to-site VPN settings of a network. Only valid for MX networks.
Meraki Dashboard APIにはMeraki vMXのルーティング テーブルの情報を直接取得する手段がないため、 Auto VPNに関わる情報からMeraki vMXが学習しているAuto VPN Routeを割り出しています。
処理内容を例えるなら、Cisco IOS系で言うところの show ip route が実装されていないので、 show running-config の設定情報からルーティング テーブルを理論的に構築するような挙動になっています。
また、Meraki Dashboard APIの呼び出しは、下記のPythonのライブラリ経由で行っております。
上記の処理内容に関わる補足ですが、 AWS LambdaスクリプトのAuto VPN Routeの取得対象は、Spoke側のMXがHubsでPrimary vMXとSecondary vMXを直接指定している場合に限ります。 そのため、現状のAWS LambdaスクリプトではFull MeshやPartial Meshの環境には適用できません。
そして、Meraki MXおよびvMXのDC-DC Failover構成ではHub間のループを無効化する必要があり、 DC-DC Failover構成では事実上のFull MeshやPartial Meshがサポートされないにも等しい状況となります。 そのため想定動作を正とするならば、スクリプトの改修でMesh対応にするのは実質的に不可能となります。
障害検知の仕組み
Meraki vMXの障害の検知では、Boto3の describe_instance_status のMethodを用いてEC2 Instanceのステータス情報を取得して障害の有無を判断しています。
そのため、OSがクラッシュしてEC2 Instanceが停止するような障害が想定されています。 表現を変えると、NICに割り当てられているIPアドレスに対してpingを打つような実トラフィックを伴う動作にはなっていない点に留意してください。
Primary vMXの障害復旧時のPreemptの動作
AWS Lambdaのスクリプトは、VRRPで言うところのPreemptが有効になってるような挙動となります。
具体的には、まずvMX1が障害になると、vMX2にNext hopが書き換わります。 その状態でvMX1が障害から復旧すると、Next hopがvMX2からvMX1に自動的に書き換わる挙動になります。
AWS Lambdaスクリプトの該当処理ですが、
get_all_vpn_routes の関数内にて、
vMX1 に該当するAuto VPN Routeが見つかると for ループを break して抜けるため、
vMX2が同一のAuto VPN Routeを学習していてもNext hopがvMX2に上書きされないようになっています。
補足
AWS LambdaスクリプトはMerakiのサポートは受けられないため、実導入する際は必ず挙動を把握しておく必要があります。
また、一例となりますが、Firmware Upgrade時のルーティングの片寄せには対応していないため、サービス断時間を極限までに短くしたいような要件があると改修が必要になってきます。 ただし、そもそも改修が必要なほど厳格な要件がある環境には、シンプルが売りのMerakiの導入は向かない可能性があります。
