Getting Comfortable with Azure Virtual Networks and DHCP

One of the great features of Azure IaaS is being able to extend your existing internal network to the cloud over a site-to-site VPN. You can bring your own IP addresses, but remember, the devil is always in the details. Or rather, knowledge is power!

Azure IaaS supports the standard private IP network ranges - 10.x, 172.x and 192.x – so you can easily give your Azure network a range that is comparable to the network range you are using in your data center.

However, Azure expects all guests to receive their IP address via DHCP. This took me a bit to grow comfortable with, as I spent years in smaller datacenters were each server was lovingly assigned an IP address that had been selected from a master spreadsheet. (Old school, I know!)  My favorite servers were given “choice” addresses with easy to remember numbers.

But networking is changing and we must change with it, so I’m becoming more comfortable with having less control over the particular address assigned to a given machine. This is key thinking when it comes to network virtualization.  By abstracting away some of the nuts and bolts of the network, the ability to be more flexible is introduced – which is good.  Someone I was talking to at a conference recently compared it to the adoption of IPv6.  IPv6 addresses are so long you would never statically assign them to a machine, that is all automated.

But, can I give my Azure VM a static address? Well, lets just say nothing is stopping you. You can go into your VM IP settings and do whatever you want.  But the risk of introducing a future IP address conflict is high and you will eventually lose the ability to connect to your VM.  Azure expects to get periodic DHCP renewal requests and when those stop the Azure fabric will remove that IP as active and stop forwarding traffic to it. There is no way to connect to the “console” of your Azure VM, so lost remote access to a machine due to an addressing issue will make for a very unhappy day.

Let’s say my internal network for my servers is 192.168.10.x/24.  I have two basic options for my Azure network:

1. Configure 192.168.10.x/24 in Azure, with a subnet for 192.168.10.128/25. I would need to make sure that everything in my physical datacenter was assigned IPs in the beginning half of the range, leaving 192.168.10.128 – 192.168.10.255 under Azure control. Azure also grabs a few other address out of the range for internal use, so I’d likely want to make sure I wasn’t using those in my physical network either. I think this option is messy and prone to errors. Also, I’m sure someone who does networking configuration all day will tell me it makes them cringe for more than one reason.
2. Create an different address range for Azure and make sure my internal switching gear is set up to route to it, like 192.168.20.x/24.  This would allow me to use a numbering scheme that makes sense within my organization, but also makes it easy to quickly identify resources that are internal vs. Azure based.

Keep in mind that any server in Azure will be assigned a persistent private IP address from your range with an infinite lease time, so if you are worried about domain controllers or other servers where the current “best practice” is to have a static assigned address, you can relax.  The only time a machine would loose it’s IP lease is when it’s in the “Stopped – Deallocated” state.

Finally, keeping with my “plan twice, create once” mantra, once your add a machine to an Azure network, you can only make limited changes - like adding new subnets or adjusting subnets that are not yet used.

For more information visit the Windows Azure Virtual Networks Overview.