Azure Exam Prep – Virtual Networks
Continuing the theme of exam prep, I thought I’d write a little about Azure Virtual Networks, or VNets.
If you see any of the “martetecture” material on the Internet, you’d rapidly come to the conclusion that VNets are a way to securely bind your on-premises corporate-network to the network you have in Azure on which all your servers and resources are sat. The idea behind this is that the stuff you have in Azure becomes a bit like a branch-office attached to your private network. The connection medium between the 2 is the Internet and the traffic is carried over SSL, which makes it very difficult for an eavesdropper to listen in on your communications. But did you know you can use VNets to also connect let’s say some servers in the Azure Dublin data centre to some servers in the Azure Singapore data centre? You can also use it to connect say an Azure Website running WordPress to an Azure VM running MySQL: it’s a way of bridging the gap between PaaS and IaaS services in Azure. It also gives you a good degree of control over the way the internal network works. This might be important if you intend to deploy core infrastructure such as Active Directory where the sites and services architecture assumes you have control over such things as sites and subnets.
There are 2 things to get your head around: address spaces and subnets. An address space is the contiguous universe of IP addresses between 2 limits – the lower address and the upper address. The subnet is an IP subnet in the traditional sense of the word but in this case, it lives within an address space.
Address Spaces
Address spaces and subnets are usually declared in CIDR notation. A number like 10.0.0.0/8. That’s a 32-bit base IP address plus a mask. This example means “mask off the top 8 bits, and the range of addresses that are left in the last 24 bits is the address space.
Figure 1: Address Space map for 10.0.0.0/8
The above example shows an address space from 10.0.0.0 (the lower address) to 10.255.255.255 (the upper address). Another example might be 10.0.0.0/16 as shown in the following figure.
Figure 2: Address Space map for 10.0.0.0/16
That would mask off the top 16 bits and leave the final 16 bits for an address space range of 10.0.0.0 to 10.0.255.255.
Whatever address space you define, you are creating a “space” with a collection of addresses (from the lowest to the highest), hence the term “address space”. Let’s imagine you had a VNet with a couple of IaaS VMs connected to it like the figure below:
Figure 3: VMs connected to a VNet
The text in red represents the address space. Note it’s the same for each VM. The text in black represents the individual address within that space. These 2 machines can communicate with each other on the VNet. Their addresses are within the permitted range for this address space of 10.0.0.0 to 10.0.255.255. But imagine if the IP address of the machine of the right had somehow got set to 10.1.20.31. It would be unable to communicate because it’s outside the range. Azure’s infrastructure would specifically prevent communication to or from that machine. It would become an island on its own.
Subnets
A subnet must exist within an address space. That means the range of addresses in a subnet must fit inside the address space. So hopefully you can see how subnetting an address space gives you a way to logically divide up the address space.
Look back up at figure 1. The lowest-order 24 bits represent all the possible addresses you could have in the address space. By further dividing those 24 bits, you could segment the network. The higher order bits would determine which subnet you are in, and the lower order bits would define which host on that particular network you are on.
Figure 4: Subnet within an address space.
Figure 4 shows how the remaining 24 bits have been subnetted. The following table gives a few examples of how to break these ideas down.
The table below assumes an address space of 10.0.0.0/8
| IP Address | Subnet | Host (within subnet) |
| 10.0.0.20 | 0 | 0.20 |
| 10.1.0.20 | 1 | 0.20 |
| 10.50.2.20 | 50 | 2.20 |
| 10.200.0.200 | 200 | 0.200 |
| 10.250.255.147 | 250 | 255.147 |
| 11.0.0.10 | invalid (it’s outside the address space) | invalid (it’s outside the address space) |
| 8.0.0.12 | invalid (it’s outside the address space) | invalid (it’s outside the address space) |
This is all very easy because I’ve divided the address space and subnet boundaries up on very neat byte boundaries. So the numbers fit exactly in the dotted address notation. But you can also create address spaces and subnets that don’t divide on these boundaries. You could for example have a subnet defined by the top say, 13 bits of a 32-bit address. The reason it makes things more difficult is because part of the subnet identifier would come from the second number and part of it would come from the third number of an IP address. And there’s nothing to be done other than visualise the address space in your mind, or draw it out.
Figure 5: Non byte-boundary subnet.
This would give a CIDR address for the address space as 10.0.0.0/8 and a subnet address of 10.0.0.0/13. If you count in from the most-significant-bit, you can see the subnet ends on the 13th bit. It certainly makes for complexity when trying to do calculations in your head in an exam! I’m hoping you can see that as you make the number of bits you use for the subnet bigger, you take them away from the maximum number of hosts you can have within a subnet. So these things are a compromise against each other. If you have no need (and foresee no need way in to the future) to be really tight up against the boundaries with subnets and address spaces, and you’re not at or near the limit – make life easy for yourself – set address space and subnets up on byte-boundaries. I reckon in the exam, if they want you to calculate something like this – they’ll give you a question with everything lining up on byte boundaries. After all, it’s not a TCP/IP exam…
What’s in a Virtual Network.
The security in Azure works in such a way that IP addresses that are not known to the infrastructure (on other words it didn’t issue them in the first place) are not routed anywhere. The result is that if you want things to talk to each other, you’ve got to let Azure’s infrastructure give you a dynamically assigned IP address. You might be getting all uppity at this point thinking you want to deploy something like an AD Domain Controller and best practice says to avoid DHCP. Well, with VNets you can relax. You will be issued an address over the DHCP protocol, but the lease duration is set to either 168 years or until you delete the VNet, whichever comes first. I’m pretty sure you’ll delete the VNet first and in fact, I haven’t thought about what will happen in 168 years. It’ll be somebody else’s problem by then.
This means whenever you shut a machine down, when it reboots, it’ll get the same IP address back again. So now you can relax about your AD Domain Controller deployments in Azure. The fact that every time you boot the machine and it gets the same address makes it just as good as a statically assigned IP address.
Each VNet reserves a few addresses. You might have noticed whenever you fire up the first machine in a VNet it gets a .4 address. That’s because .0 is reserved for broadcast requests while .1 is reserved for the default gateway (router). .2 and .3 are reserved for a special sort of gateway that you might later configure to communicate with your on-premises network. Note that .255 is also a broadcast address.
In the following figure, I configured a VNet thus:
| 10.0.0.0/8 | Address space = PlankyNet |
| 10.0.0.0/16 | subnet = SubNet-1 |
Figure 6: ipconfig output for a VNet.
You can see this is the first host in the subnet because it is assigned a .4 address. You can see it’s a 16-bit subnet, because the subnet mask (255.255.0.0) masks off the top 16 bits. You can also see the default gateway (router) is at 10.0.0.1 as predicted.
It doesn’t matter how large or small the subnet is, any range of available addresses are automatically reduced by 5 (because of the 5 reserved addresses mentioned above). So for example a 16-bit subnet (which gives a total of 65536 host addresses) is reduced to 65531. An 8 bit subnet has a maximum of 251 addresses (256-5). You can see this illustrated in the following figure.
Figure 7: Subnet range displayed in the Azure portal.
In Figure 7 you can see the 16 bit subnet mask results in 65531 available addresses giving a usable address range of 10.0.0.4 to 10.0.255.254.
Practice Questions
Q: How many hosts can occupy a single subnet in the following VNet?
Address space: 10.0.0.0/16
Subnet: 10.0.0.0/24
A: the “/24” means the first 3 octets fill in from the most significant bit and mask off the first 3 bytes. That leaves one byte (or 8 bits) of subnet space– or 256 hosts. But 5 addresses have to be subtracted which leaves 251 hosts.
Q: How many hosts can occupy a single subnet in the following VNet?
Address space: 10.0.0.0/8
Subnet: 10.0.0.0/24
A: THis is just a question to test that you understand the difference between the address space and the subnet. The subnet definition in this question is the same as the first question, the number of hosts doesn’t change. 251.
Q: You have the following VNet:
Address space: 10.0.0.0/8
Subnet: 10.0.0.0/16
You connect to a VM on this network over RDP and assign the following fixed IP address 10.0.0.100. Will you be able to connect to a VM at IP address 10.0.0.101?
A: No – the Azure VNet infrastructure prevents traffic to/from hosts it didn't assign an IP address to.
I hope this will help you if you’re taking the Azure Infrastructure Exam (533)…
Planky == @plankytronixx