Skip to content

Cisco Meraki vMX SD-WAN with AWS Transit Gateway Deployment

This lab guide covers deploying Cisco Meraki vMX SD-WAN appliances on AWS with AWS Transit Gateway to connect on-premises branches with AWS workloads using Lambda-based failover automation.

Overview

This guide covers deploying the Cisco Meraki vMX Partner Solution with AWS Transit Gateway in the AWS Cloud.

The Cisco Meraki vMX is deployed with AWS Transit Gateway to enable customers to easily connect their on-premises branches to their AWS workloads through automated route management.

Meraki vMX is a virtualized security and SD-WAN network appliance. This Transit Gateway deployment includes vMX as a node to extend the common policy, segmentation, and security of SD-WAN environments at scale. The deployment includes an active-active (or active-standby) pair of redundant vMX appliances in a highly available configuration. With AWS Transit Gateway, connectivity can be scaled across virtual private clouds (VPCs) with workloads in multiple AWS Regions. You can configure, monitor, and maintain all of your Meraki devices from a single Meraki dashboard.

Architecture: Transit Gateway Connectivity

This automation builds the regional vMXs that interconnect your on-premises branches to a new or existing Transit Gateway network. It uses AWS Lambda to run a 1 or 10 minute polling function that detects failover scenarios.

Lambda Operation Modes

  • Auto Lambda Mode: The polling function will auto learn new routes as well as auto failover. It will call the Meraki Dashboard API to learn any newly added/removed spoke branches in the Meraki autoVPN network. The CIDR addresses of each spoke will be added to both the VPC and TGW Route tables. Upon failover, these routes will automatically be pointed to the standby vMX.

  • Manual Lambda Mode: The polling function will also auto failover but will allow for manually added summary routes. Add summarized routes to your active vMX inside the VPC route table and, upon failover, these routes will automatically be pointed to the standby vMX. TGW Route table routes will also need to be manually added.

Architecture

This deployment sets up the following:

  • Highly available architecture that spans two Availability Zones
  • VPC configured with public and private subnets, according to AWS best practices, to provide you with your own virtual network on AWS
  • Internet gateway that connects the VPC to the internet
  • VPC route table associated with the public subnets to specify routing rules for outbound internet traffic
  • Meraki vMX appliances in the public subnets on Amazon Elastic Compute Cloud (Amazon EC2) instances
  • Elastic network interfaces in the private subnets to enable traffic routing from all subnets in the Availability Zone to AWS Transit Gateway
  • AWS Transit Gateway attached to the VPC, enabling connectivity to attached workload VPCs in other AWS Regions
  • Transit gateway route table associated with the VPC for routing rules to AWS Transit Gateway
  • Amazon CloudWatch to collect logs of vMX instance performance
  • AWS Lambda to monitor the state of the vMX instances. If an instance fails, AWS Lambda updates route tables to point to a healthy instance and logs the event in CloudWatch
  • AWS Secrets Manager to store a Meraki API key. AWS Lambda uses the API key to access the Meraki dashboard when updating route tables

Prerequisites

Before deploying this solution, ensure you have the following:

AWS Account Configuration

  1. Sign in to your AWS account with an IAM user role that has the necessary permissions
  2. Make sure that your AWS account is configured correctly with appropriate service limits and permissions

Meraki Dashboard Account Preparation

Meraki Dashboard Configuration

As long as you have available vMX licenses (small, medium, or large), and an API Key, the CloudFormation template will create the licensed Meraki vMX network and provide each vMX with a name and tag that is used for automation.

Deployment Options

Deploy vMX with Transit Gateway into a new VPC

This option builds a new AWS environment that consists of the VPC, subnets, security groups, Transit Gateway, TGW Route Table, and other infrastructure components. It also launches Meraki vMX networks in the Meraki Dashboard.

Post-Deployment Configuration

After deployment, you must complete the following steps:

Verify Meraki vMX Networks

Two Meraki vMX networks have been created each with a generated name and tag: <AWS TVPC-vMX-REGION-vMX#-AZ#-ACCOUNT>

Configure Meraki Spokes

  • Configure your branch sites as Meraki Auto VPN spokes with the vMX instances as the primary and secondary hubs. For more information, see Meraki Auto VPN - Configuration and Troubleshooting
  • From each branch network, advertise the local subnet into autoVPN

Meraki AutoVPN

Configure Transit Gateway Integration

Auto Lambda Mode Configuration

Verify that new spokes are auto injected into the VPC and TGW Route tables.

TGW Add Route

The Lambda function will automatically: - Learn new routes from the Meraki Dashboard API - Add CIDR addresses of each spoke to both VPC and TGW Route tables
- Automatically failover routes to the standby vMX upon primary failure

Manual Lambda Mode Configuration

Add any additional summary routes manually into the VPC and TGW route table.

Important Note: VPC routes must be pointed to the primary vMX only.

VMX Workload TGW RT Association

The Lambda function will: - Auto failover but allow for manually added summary routes - Automatically point routes to the standby vMX upon failover - Require manual addition of TGW Route table routes

vMX High Availability Architecture

The deployment architecture is fault tolerant with two vMX instances in different Availability Zones. An AWS Lambda function handles instance-level failures by checking the state of vMX EC2 instances. For software-level failures, it checks the vMX health state on the Meraki dashboard. In the case of a vMX instance failure, the AWS Lambda function logs the error in CloudWatch and updates the VPC and transit gateway routes to point to a healthy instance.

Testing vMX Failover

Failover can be tested by using a network ACL in the subnet of the active vMX that denies all traffic. AutoVPN will detect an outage. Remove the ACL to test fail back.

Lambda Failover Process: The Lambda polling function running every 1 or 10 minutes will detect an AutoVPN failure. All VPC routes pointing to the primary vMX will be moved to the secondary vMX.

Best Practices

For best practices when using Meraki vMX on AWS, see vMX Setup Guide for Amazon Web Services (AWS).

This completes the Cisco Meraki vMX SD-WAN deployment with AWS Transit Gateway. The solution provides highly available, scalable connectivity between your on-premises branches and AWS workloads through Lambda-automated route management and failover capabilities.