Understanding CIDR to create better Azure Subnets

Summary

When setting up an Azure Virtual Network, it can be difficult to understand how to design the IP Address range. In this post I’ll simplify what address space and CIDR notation means so that you can construct robust IP ranges in Azure.

General Rule

When you first create a Virtual Network, you need to set the IPv4 Address space.

This address space can be anything you specify, however Microsoft recommends sticking with the RFC1918 guidelines.

In the RFC1918 guidelines, it is recommended that Private Networks are built in the following IP Address spaces:

     10.0.0.0        -   10.255.255.255  (10/8 prefix)
     172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
     192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

There are no rules enforcing the above, however it’s generally used by network administrators. It also helps network administrators identify the types of networks they are dealing with.

As far as how much control you have over distributing host IPs, the table below should assist.

If you are operating in the Class C network space, the IP Address space in those ranges can eventually become exhausted. It you’ve ever built a home network, you’ve seen how quickly you can lose control of IPs when you have devices or virtual machines joining the network. If you’re in a small office environment, you might have print servers, files shares, users, employee mobiles and other network devices eating up the IP range.

There are also scenarios where you want to isolate devices on a network to specific groups. For instance, a consumer off-the-shelf Network Attached Storage (NAS) is sometimes used in an office setting to share files. The NAS itself may not have any authentication and authorisation built-in, therefore allowing anyone who has access to the network to also have access to the files.

What if you could break your single network into sub networks, each with it’s own specific IP range. For examples:

1. Finance Office – 192.168.10.0 will own everything within that Class C network (192.168.10.0 – 192.168.10.255)
2. Contact Centre – 192.168.20.0 will own everything within that Class C network (192.168.20.0 – 192.168.10.255)
3. General Employees – 192.168.30.0 will own everything within that Class C network (192.168.30.0 – 192.168.10.255)

This way, each group can have access to their own network where they can control print servers, mobiles devices joining the network, file shares etc.

It’s actually very possible to implement the above, and quite easily in Azure. It requires a little forward thinking and also some understanding of CIDR notation.

CIDR (Classless Inter-Domain Routing) notation

CIDR can become a complex subject to understand. In short CIDR notation allows you to control the Class B, and C ranges. It’s prefixed with a slash, followed by a number.

Examples

• 10.0.0.0/8 – Control Class B, C and Host.
• 10.0.0.0/16 – Control Class C and Host.
• 10.0.0.0/24 – Control Host only.

The prefix number denotes the Class that can be controlled. For example, in a home network if I stick with the RFC designations, my IPv4 Address space sits in 192.168.0.0. This means that I have some control over Class C and the Host. This means that my CIDR prefix should be /16. The implementation in Azure would look like:

192.168.0.0/16 – This CIDR IP Address space will allow me to control Class C ranges. With that in mind, I can create the following subnets:

If I needed control over both Class C, B and the host. Again, sticking to the RFC designations, I would use the IP range: 10.0.0.0 with a CIDR prefix of /8.

Subnet Address Range

Similar to IPv4 Address ranges, when creating a subnet, you are taking a slice of the primary address. CIDR notation is used again, however this time you need to ensure that the prefix does not overlap into a range that you have already specified. Otherwise you’ll receive an overlapping error.

Understanding all this, you should be able to create better IPv4 Address Space and Subnets.