(Shoutout to @ShaunB93 for his help with this and pointing me in the right direction. Sharing this with community so others can review, edit and use for their own deployment exercises.)
This guide details configuring the Meraki vMX in Azure for routed mode, leveraging the dedicated LAN and WAN interfaces, and establishing connectivity with Azure workload Virtual Networks (VNets) via peering and BGP.
Initial vMX Configuration with Separate LAN/WAN Interfaces
The 19.1 vMX release introduces support for separate WAN and LAN interfaces, enabling distinct east-west and north-south traffic flows. During vMX installation, select "Enable and configure LAN interface" and provide separate WAN and LAN subnets.
Important Considerations for Azure Subnets and vMX Configuration:
When configuring your vMX appliance within an Azure subnet, it's crucial to understand Azure's IP address reservation scheme. Azure reserves the first four IP addresses in each subnet for essential network functions. For example, in the 192.168.1.0/24 subnet:
- 192.168.1.0: Network address
- 192.168.1.1: Azure default gateway
- 192.168.1.2: Azure DNS
- 192.168.1.3: Azure DNS
Therefore, the first usable IP address for your vMX LAN interface is 192.168.1.4 in this example. However, you must use the specific IP address assigned to the vMX LAN interface during the provisioning process. This IP address is not automatically 192.168.1.4 and may be different depending on your Azure configuration.
To find the correct IP address:
- Navigate to the vMX virtual machine in the Azure portal.
- Go to Networking (or Network settings, depending on the portal version).
- Locate the LAN interface and review its IP configuration. This will show the assigned IP address.
Once you have identified the correct IP address, configure the vMX LAN interface in the Meraki Dashboard:
- Go to Network-wide > Configure > Addressing & VLANs > LAN configuration.
- Update the vMX LAN settings with the following information:
- IP address: The IP address obtained from the Azure portal (e.g., 192.168.1.4, or the actual assigned address).
- Subnet: The Azure subnet address and mask (e.g., 192.168.1.0/24).
By using the correct, Azure-assigned IP address, you ensure proper communication and avoid IP address conflicts within your Azure environment.
Connecting to Workload VNets
Connectivity to Azure workload VNets can be achieved through VNet peering or BGP routing.
Direct Peering and Static Routing (Suitable for smaller, static networks)
Establish VNet Peering: Peer the vMX VNet with the target workload VNet. Azure documentation provides detailed instructions for this process. Ensure that both VNets are in the same region for optimal performance.
Create a Static Route in the vMX: Define a static route in the vMX to direct traffic to the workload VNet. For example, if the workload VNet is 10.0.0.0/24, create a static route with:
Explanation of Next Hop IP: The Azure default gateway (192.168.1.1) is used as the next hop because the vMX relies on Azure's routing infrastructure to traverse the VNet peering connection. The vMX doesn't directly peer with the workload VNet; Azure handles the inter-VNet routing.
Create an Azure Route Table: Create a route table in Azure and associate it with the workload VNet subnet. This route table defines the return path for traffic originating from the workload VNet. For example, to reach a Meraki branch network (e.g., BranchOne with network 10.100.0.0/24 and VPN Mode enabled) connected to the vMX via AutoVPN, add a route entry:
Name: To-BranchOne
Destination Type: IP Address
Destination IP/CIDR ranges: 10.100.0.0/24
Next Hop Type: Virtual Appliance
Next Hop Address: 192.168.1.4 (vMX VLAN Interface IP)
BGP Routing (Recommended for Larger, Dynamic Networks)
For larger networks, managing static routes can become complex. BGP provides dynamic route learning and simplifies network management. Configure the vMX for BGP in routed mode:
Meraki vMX BGP Settings:
Using the Azure LAN interface IP (192.168.1.1) as the next hop in the vMX BGP configuration ensures that the vMX advertises routes through Azure's routing infrastructure. The remote BGP neighbor on the Azure side peers with the vMX's VLAN interface IP (192.168.1.4) to establish the BGP session. This allows routes to be dynamically exchanged between the Meraki network and Azure, eliminating the need for manual route configuration.
Key Considerations for BGP:
Autonomous System Numbers (ASNs): Ensure that the ASNs used for BGP are correctly configured on both the vMX and the Azure side. Private ASNs are typically used for internal networks.
Route Filtering: For more complex networks, consider implementing route filtering to control which routes are advertised and learned by the vMX and Azure.
Troubleshooting: If you encounter BGP peering issues, check the BGP status on both the vMX and the Azure Virtual Network Gateway. Logs and debugging tools can help identify the root cause of the problem.
This document provides a comprehensive guide to configuring the Meraki vMX in Azure for routed mode. By following these steps, you can establish secure and reliable connectivity between your Meraki network and Azure workloads. Remember to consult the official Meraki and Azure documentation for the most up-to-date information and specific configuration details.
