Hi Team,
I have used the vMX100 Setup Guide for Microsoft Azure found below on the Meraki website:
https://documentation.meraki.com/MX/Installation_Guides/vMX100_Setup_Guide_for_Microsoft_Azure
Been bashing my head against a wall trying to get connectivity from my DC in the Sydney branch office to the DC in Azure.
My network configuration is as follows:
Sydney Branch Office Network
MX100
192.168.0.0/24 - Office LAN
192.168.0.8 - SydneyDC
vMX100 VNET
vMX100
10.10.0.0/24 - vMX100 Subnet
10.10.0.4 - vMX LAN IP
Infrastructure VNET
It sounds like you have it right, I'll continue to look at it. Check for any ACL that may be in place. I found one in my own environment sitting a switch that created issues.
-Dennis
It looks like when you have deployed the VMX it was put into it's own VNET.
When you are deploying it and you get to the VNET configuration you need to click "Advanced" and select the existing VNET (where your servers are).
From the Meraki article. I took it that the vMX and server had to be on different vNETS infact I tried creating them on the same and the managed app won't allow this.
Before You Begin
You must have the following before you begin:
Note: Your virtual network must be in a separate resource group from the one hosting your vMX. If you assign the vMX to a resource group that already contains a virtual network/virtual subnet, you will not be able to deploy the vMX.
I just remember that when assign the VNET when deploying the VMX in Azure it had to go into an existing VNET. If you used a VNET in the same resource group as the VMX (which is the default) it wont work.
But following the Meraki documentation it explicitly states you can't have the vMX on the same VNET as your Servers VNET.
I have tried putting them in the same VNET and azure errors out (I think the managed app locks down the VNET it deploys so you can't make any changes to it)
You can only configure it at deployment time. You can not change it afterwards. You have to delete the managed app (VMX) and redeploy. During the deployment you should be able to select the existing resource group and VNET in the networking section (under advanced in the Azure portal).
Hi Philip,
So you suggest deleting the vMX managed app.
When redeploying what resource group should I put it into?
The actual app, VMX100, has to go into its own resource group. When it runs through the Azure setup it comes to a bit about the networking. In that section you need to go into Advanced (in the Azure portal), and select an existing resource group and an existing vnet.
You can pretend to do this with a trial run through first before deleting the current VMX.
Hi Philip,
See below screenshots. Tried wiping azure config all away.
Created new Resource Group with a VNET inside then provisioning vMX100 to be apart of that resource group.
No dice gives an error. Your thoughts?
You'll need to blow away everything relating to the existing VMX to be able to deploy it again using the same resource group name.
I think it is the next screen, "Deployment Details", where you need to select an existing resource group and then an existing VNET.
Hi Philip,
Everything was blown away. I set it up as you said. It didn't work.
You can not create the resource group without adding a vNET. When launching the managed app you can not associate the app to an existing resource group with a VNET defined. This is explained quite clearly in the Meraki instructions. Which will post again as it contravenes what you're trying to tell me.
Before You Begin
You must have the following before you begin:
Note: Your virtual network must be in a separate resource group from the one hosting your vMX. If you assign the vMX to a resource group that already contains a virtual network/virtual subnet, you will not be able to deploy the vMX.
Is anyone who is running a vMX successfully in Azure able to chime in?
From what I can see is that you have 2 seperate vNETs. 1 for Meraki, 1 for Infrastructure.
In this situation, you have to setup vNET peering between the two vNETS for communication. Unfortunately this will increase costs as there is a cost for network traffic over peering.
Now to do it the way you want it, you need to setup the following configuration.
What we have done here is create a Meraki vMX to use the same vNET as your internal infrastructure. Meraki only have the requirement to create infrastructure in its own Resource Group. If resource groups are in the same region, they can share vNETs. If you create seperate vNET's, the only way they can communicate is via vNET peering. This is a Azure networking basics.