vMX and related issues (deployment & operational concern)

Solved
Mohit_Chauhan
Here to help

vMX and related issues (deployment & operational concern)

Hi guys,

 

I am quite new to Azure and hope someone can help me with some ideas/suggestions/solution to few of my concerns in regards to commissioning up  vMX on Azure Cloud.

 

1. /25 or /24: Can we use /25 as the subnet instead of /24 for the vMX?The reason I am asking was that whenever I have tried using /25 it gave me the error in the end of the build. Has anyone tried that?

2. Spare Subnet Issue: We have a vnet in the RG (Aus Southeast region) with /22 subnet which gives us 4 x /24 subnets. Out of these 4 , 3 are already used (one for servers, one for DMZ and 3rd as GatewaySubnet). Now we are left with only 1 x /24 subnet free. We need to use VPN clients off this vMX. How do we deal with this situation?

   a) Can we use server subnet to install the vMX and use this 4th spare subnet for the VPN users?

       In this case, do we will still need to configure the Route Table so the servers can use vMX as the next hop to reach to   the WAN site? Or it will automatically do that given the vMX and servers are on the same subnet? Right now they are pointing to the Express Route for accessing the WAN sites as well as the Internet hosted in the client;s DC.

  b) Should we use this spare subnet just for vMX and then just add another vNet with /22 and then use a subnet from there? I think with that we will need to create some inter-vnet peering? Any thoughts on that?

 

Look forward to hear back on the above points so I can move forward with this build. Appreciate your time in reading the above and also thanks in advance if you can provide some inputs/ideas to my concerns.

 

Regards,

 

Mohit

1 Accepted Solution

It works maybe 90% of the time with deployments.  The other 10% you get constant packet loss

and the only way to resolve it is to completely delete the VMX and re-deploy it.

 

Client VPN does not use a subnet inside of the VNET.

View solution in original post

6 Replies 6
PhilipDAth
Kind of a big deal
Kind of a big deal

You should be able to use a /25.  I think I have a customer using /29's.

 

Client VPN users (to a VMX) won't be using a subnet out of Azure.  You will need to think up a new range outside of the Azure range for this.

You mentioned you have a subnet for the "Gateway".  This sounds like a good place to put the VMX.

Thanks so much for your inputs?

1. I have never thought of using GatewaySubnet for this as I was in the impression it should not be touched at all (as I mentioned I am quite new to Azure). The client is running Express Routes, I am hoping using GatewaySubnet should not impact that (or anything else) as we dont want that to be disturbed.

2. How about using the server subnet altogether. Is that a safe call?

3. When you say "Client VPN users (to a VMX) won't be using a subnet out of Azure", did you mean outside of the given vnet? As I was thinking that as other alternative to add another vnet in the same region and use a subnet from there, if it was possible?

 

Thanks.

It works maybe 90% of the time with deployments.  The other 10% you get constant packet loss

and the only way to resolve it is to completely delete the VMX and re-deploy it.

 

Client VPN does not use a subnet inside of the VNET.

Thanks for the quick reply.

"90% of the time" , is this using GatewaySubnet, or Server subnet?

 

It makes sense about client subnet. This could be any subnet (outside of Azure) just like any other SDWAN site, isnt it?

Server subnet.  Correct, like any other SD-WAN site.

Thanks Phil, that should be alright then. Having the VPN subnet no more my problem now, we should be good to use the 4th available subnet. It was good to know all the info you shared, especially to be able to use the GatewaySubnet for the vMX. I wish I could have more info on that including pros and cons with that approach.

Anyway thanks a lot for valuable inputs.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.