Just some stuff I discovered today …
Azure Virtual Networks contain address spaces (e.g.
192.168.0.0/16). I was under the impression a Virtual Network can contain only one address space, but that turned out to be incorrect. A Virtual Network can contain multiple address spaces (e.g.
10.10.0.0/24 – notice they have no relation to each other). A Virtual Network is just a logical way of saying all these address spaces belong to the same network. A Virtual Network is also the entity which has a gateway and to which you can connect your Physical Network.
Within a Virtual Network you create subnets. I thought you had to necessarily create subnets, but turns out they are optional. If you don’t want to create subnets just create a default one that encompasses the entire address space.
VMs in Azure are automatically assigned IP addresses. That is to say there’s a DHCP server running in Azure, and depending on which subnet your VM is connected to the DHCP server allocates it an IP address. (You can tell the DHCP server to always assign the same IP address to your VM – I discussed that in an earlier post). Remember though, that a DHCP server gives clients more than just an IP address. For instance it also tells clients of the DNS servers. Azure lets you specify up to 12 DNS servers to be handed out via DHCP. But there’s a catch though, and that’s the thing I learnt today – the DNS servers you specify are per Virtual Network, not per subnet (as I was expecting). So if your Virtual Network has multiple subnets and you would like to specify different DNS servers for each of these subnets, there’s no way to do it!
So, lessons learnt today:
- DHCP settings are per Virtual Network, not per subnet;
- Subnets matter only in terms of what IP address is allocated to the VMs connected to it;
- In my case I was better off creating multiple Virtual Networks for my various subnets, and using separate DNS servers for these;
- I think subnets are meant to “reserve” blocks of IPs for various servers. Better to explain this via an example.
- Say I have an address space
192.168.1.0/24. If I have just one subnet in this space (a subnet
192.168.1.0/24) then all my servers will get random IPs from
192.168.1.4onwards. But maybe I don’t want that.
- Maybe I want that all my web servers get IP addresses from a specific chunk for instance (
192.168.1.4 - 192.168.1.10), while all my DNS servers get from a different chunk (
192.168.1.11 - 192.168.11.16).
- One way would be to assign static IPs for each server, but that’s an overkill. Instead, what I could do is create subnets for each of these category of servers. The smallest subnet I can create is a
/29– i.e. a subnet of 8 hosts, of which 3 are reserved, so effectively a subnet of 5 hosts – and connect VMs to the these subnets. As far as VMs in each subnet are concerned they are in different networks (because the IP address class will be that of the subnet) but for all other intents and purposes they are on the same network. And from a DHCP point of view all subnets on the same Virtual Network will get the same settings. (Note to self: if the VMs are in a domain, remember to add these multiple subnets to the same site so DC lookup works as expected).
- Needless to say, this is my guess on how one could use subnets. I haven’t searched much on this …
- Say I have an address space
- Subnets are also recommended when using static IPs. Put all VMs with static IPs in a separate subnet. Note it’s only a recommendation, not a requirement.
- There is no firewall between subnets in the same Virtual Network.
I am not going to change my network config now – it’s just a test environment after all and I don’t mind if clients pick up a DNS server from a different subnet, plus it’s such a hassle changing my Virtual Network names and pointing VMs to these! – but the above is worth remembering for the future. Virtual Networks are equivalent to the networks one typically uses; Subnets are optional and better to use them only if you want to classify things separately.