By: Mitchell Gulledge, Jack Stromberg
This document is a detailed step by step deployment process for automating connectivity from your Cisco Meraki branch to Azure Virtual WAN. Supported Use Cases along with a reference architecture will be provided.
vWAN Connectivity Architecture
High Level diagram listed below
In the above diagram, there is a branch that tunnels directly to an Azure Virtual WAN Hub. This tunnel is automatically built utilizing the toolkit provided. IKEv2 is utilized for securing connectivity to the VPN Gateway; more details on what the default proposals used can be found at the end of this document.
- Each branch MX must be on firmware 15.12 or greater to take advantage of IKEv2.
- This guide assumes the creation of Virtual WAN and the Virtual WAN hubs have previously been created in the Azure Portal.
For steps on creating a Virtual WAN please reference: https://docs.microsoft.com/en-us/azure/virtual-wan/virtual-wan-site-to-site-portal#openvwan
For steps on creating a Virtual WAN Hub please reference:https://docs.microsoft.com/en-us/azure/virtual-wan/virtual-wan-site-to-site-portal#hub
- Owner access at the Resource Group level containing the Virtual WAN resource is required to delegate permissions to the automation script.
Supported Use Cases
The design supports the use cases for in-region and inter-region Azure connectivity for branch (spoke) sites. In this scenario, a branch securely builds an IPSec tunnel to the Azure Virtual WAN VPN Gateway. Specifically, the branch will build a single tunnel to the Instance 0's IP address of the VPN Gateway. The toolkit will configure two tunnels with two different IPs (Each being Instance 0 and 1 for the VPN Gateway). However, only a single tunnel will be active at any given time. This is due to the fact that Cisco Meraki does not support Equal Cost Multipath and therefore cannot have 2 VPN tunnels to the same destination (private subnet). Below is a screenshot of the sample configuration that will be built once the branch has been tagged accordingly:
The IPSec policies will be programmed to the following values:
If a branch site experiences an ISP outage, the IPSec tunnel will be re-built utilizing the backup ISP automatically. Only one active tunnel can be configured per destination (In the example VNET 1 and 2). In other words, only a single tunnel is used on an uplink at any given time. When that uplink is detected as Down state, the appliance then builds the tunnel out its backup WAN interface.
The events for detecting an uplink failover are:
Query the DNS servers (primary or secondary) configured on the Internet interface for the following hosts:
Ping 188.8.131.52 every second.
ARP for the default gateway and its own IP (to detect a conflict).
Details on these tests are outlined in the following documentation:
Azure VPN Gateway Failover
In order to facilitate high availability for the VPN Gateways a combination of the VPN status API and Events API is used to detect gateway failover. The following endpoint is queried during the Azure Function:
If the tunnel is detected as down for the site, we look at the events API to ensure that this wasn't taken down due to no interesting traffic on the tunnel:
More information can be found for the GW failover can be found in the meraki_vpn_failover() function in the following github:
By relying on the Meraki API + Azure function detecting a gateway failover in Azure may take up to several minutes to be detected.
Obtain Cisco Meraki API Key and Org Name
The API Key and Org Name will be needed for the script to configure your Meraki device.
To view your Organization name navigate to Organization > Settings and the following can be seen:
For access to the API, first enable the API for your organization.
Navigate to Organization > Settings > Dashboard API access
Enable the API
Navigate to the my profile page and generate an API key
Note: The API key is associated with a Dashboard administrator account.
Note: The toolkit also contains a firmware validation checker. One of the requirements for the solution is that the branch MX must be on firmware 15 or greater.
Run the deployment script to create the Azure Function app:
For automation, Azure Functions are used to run a Python script every 5 minutes to sync the configuration between the Cisco Meraki and Virtual WAN configurations. An Azure Resource Manager (ARM) Template is used to help facilitate the deployment process and creation of the Azure Function, Storage Account, and Application Insights resources.
Note: Each time a change is made to an IPSec Profile on the Meraki device, a renegotiation attempt is triggered for all non-Meraki VPN tunnels. In environments with hundreds of tunnels, it may not be favorable to have this happen during business hours, so you can choose to enable a maintenance window for when the automation makes changes to the VPN profiles (the maintenance window feature will not disrupt failover detection capabilities or trigger renegotiations of all tunnels during a failover scenario). If needed, you can specify a tag on any of the tunnels in scope of virtual wan with a value of vwan-apply-now, and the next sync will commit changes.
To deploy the Azure Function, click on the deploy to Azure buttons below:
Next, click the Deploy to Azure button.
When logged in to the Azure Portal, fill out the required parameters and click Review + Create.
Note: The Function App Name should not contain any special characters other than “-“. The function app also needs to be unique globally within Azure, so please use a name that is unique to your organization.
Tip: More information on each of the required parameters can be found by hovering over the icon in the Azure Portal.
4.Click Create on the Summary blade.
Delegate access to the function app in the Azure Portal:
Once the template has finished deploying, the Azure Function will not have any access to your Virtual WAN resources once provisioned. To delegate access to Virtual WAN and a Storage Account used to store the Virtual WAN configuration files, please complete the following steps.
Sign in to the Azure portal with your Azure account.
Navigate to your Resource Group that contains your Virtual WAN and Storage Account resources.
Select Access control (IAM), + Add, and select Add Role Assignment.
Click the Assign access to dropdown and select Function App
Specify the following:
Role: Network Contributor
Select the service principal
Cisco Meraki Workflow
Initially, there will be no tagged Meraki networks so the script will sleep and perform the same GET to obtain any networks with the relevant tag. In order to deploy a new branch, the user would navigate to Organization > Overview and select the checkbox next to the network that you wish to connect. Below is a snippet of the Meraki Dashboard Overview page:
Once the network is tagged appropriately, connectivity is then automatically established. A customer gateway in the Azure Virtual WAN dashboard is created with a matching network name to that of the Meraki branch. Site1 will be named Site1 in both the Azure Virtual WAN and Meraki dashboards. Additionally, a site to site VPN will appear on the site to site VPN page.
In this example we have a site named branch 1 that has been provisioned and already connected to dashboard. Additionally, on the Appliance Status page the firmware version can be verified as seen below:
Post site provisioning
Once the device has been provisioned and connected to dashboard with the correct firmware, we are ready to connect. As described above, the next step is to appropriately tag the dashboard network that the user want to connect to Azure.
Tag naming convention
In order for the function to properly detect new sites to be provisioned to Virtual WAN the following syntax must be applied:
- Tag template = vwan-(hub name)-unique identifier (number)
- Hub name example value = westus-vwan-hub
- Actual tag value = vwan-westus-vwan-hub-1
In order to scale the configuration, availability tags are placed on the Meraki VPN config. This ensures that the correct IPsec config is being distributed to the branch sites. Both the tunnel name and availability tag match what was configured by the user. This can be seen by inspecting the same example that was displayed above. Each tag must be followed by a unique identifier to segment VPN configurations within the Meraki Dashboard.
This document encompassed a step by step deployment guide along with a design guide for connecting your MX branch directly to Azure vWAN. Azure functions in conjunction with Meraki API is utilized to make a secure, automated, and scalable solution to meet any enterprise needs.
Q: Why do I see 184.108.40.206 as a WAN uplink?
A: If you have two uplinks with the same public IP from the same WAN, you will receive 220.127.116.11 as a place holder address. Two site links with the same public IP address is not a valid VWAN configuration and the automation will check for this behavior, so 18.104.22.168 has been leveraged as a placeholder in the event additional checks have been disabled within the script.
Q: How do I ensure the automation remains working if I generate a new Meraki API Key?
A: You can navigate to the Azure Function in the Azure Portal and select Configuration under Settings. Under Application settings, modify the value for the setting called meraki_api_key.
Q: The automation doesn’t seem to be doing anything, how do I figure out what’s going on?
A: The Azure Function will log many points of execution to help facilitate troubleshooting. Navigate to your Function App, select Functions, choose Meraki-VWAN-Automation, and click Monitor. On the Monitor blade, you can select any of the run dates and see the logging information as the code executes. In many cases, a Type of Error will be logged at points where the script reaches out to make API calls.
Note: Logs may take up to 5 minutes display after the script has executed.
Q: How do I force the automation script to run on demand?
A: Navigate to your Function App, select Functions, choose Meraki-VWAN-Automation, and click on Code + Test under Developer. On the Code + Test blade, click the Test/Run button, and then click the Run button. You should see HTTP response code 202 Accepted. Once you see the response code, you can close out of the blade/navigate to another part of the Azure portal and the script will still continue to finish executing.
Note: Logging can be found under the Monitor section, but please note it can take up to 5 minutes for logs to be displayed after execution.
Note: If the maintenance window feature is enabled, you will need to apply a tag with a value called vwan-apply-now to any of the IPSec tunnels in scope of Virtual WAN. This will ensure changes take effect.
Q: How do I stop or pause the automation from running?
A: Navigate to your Function App and click the Stop button and click Yes to confirm you are sure. When you are ready to resume it, click Start where the Stop button was.
Q: Are Azure US Government Cloud regions supported for this integration?
A: Azure US Government Cloud is not supported at this time due to requirements on Azure Functions – Linux Consumption Plans. Once Linux Consumption Plans for Azure Functions are available, the integration can be updated to bring support for gov cloud. An estimated availability time for Linux Consumption Plans for Azure Functions can be found here: https://azure.microsoft.com/en-us/global-infrastructure/services/?regions=usgov-non-regional,us-dod-central,us-dod-east,usgov-arizona,usgov-texas,usgov-virginia&products=functions
When To Contact Meraki Support
Users should contact Meraki support when experiencing unsuccessful WAN uplink failover as described in the following documentation:
Additionally, users should contact support if API calls are seen in the Meraki Dashboard changelog but the configuration is not reflected on the devices configuration. Please refer to the following documentation for more information on our API:
For issues related to the code within the Azure function app please refer to the open issues or open a new issue in the following link:
For Azure vWAN specific issues please contact Azure support.
How To Contact Support
Cases can be submitted directly within the Dashboard. This option helps Support quickly locate your network and resolve issues more quickly.
To submit a case in Dashboard:
- Log-in to Dashboard.
- Navigate to Help > Get help > Still need help? > Submit an email case.
- Use the provided fields to explain the question or issue. Please include any relevant details.
- Click Submit.
You will receive a confirmation email, and a Support Engineer will get back to you as soon as possible. You can update the case if needed by replying to that email, or visiting the Help > Get help > View full case history page in Dashboard.
Phone support is available for customers experiencing high impact issues where quick resolution is a top priority.
When contacting Cisco Meraki Support via phone, please have your customer number and support passcode ready. These can both be found at the Help > Get help > Still need help? > Call the Meraki Support team page.
The general Support number is +1 (415) 937-6671. A full list of region-specific phone numbers can be found in Dashboard under Help > Get help > Still need help? > Call the Meraki Support team > View regional phone numbers, or on the Meraki Support home page.
Contacting Support by phone with the support passcode ready is the most efficient way to resolve any Network outage situations. This will ensure that any parties that may also need to get involved can be involved as early as possible. (escalations, account team etc)