# CIDR notation and subnets

I've been given a script that will create a virtual network with the following IP range (in Azure): 10.0.0.0/16.

The script then goes on to create two subnets within that network with the following IP ranges: 10.0.5.0/24 and 10.0.6.0/24. My understanding is that this means the virtual network can address 2^16 host, while the subnets on the virtual network can address 2^24 hosts(?!). How can the subnets have a larger range than the network they reside on?

No. The number of bits in the CIDR notation is for how many network bits are in an address, not how many host bits are in an address. An IPv4 address is 32 bits, so you subtract the number of network bits from 32 to get the number of host bits:

``````10.0.0.0/16 = 32 - 16 = 16 host bits = 2^16 host addresses
10.0.5.0/24 = 32 - 24 =  8 host bits = 2^8  host addresses
``````

Also, with IPv4 you must subtract two from the number of host addresses* to arrive at the possible number of hosts on a network because you cannot use the network and broadcast addresses for host addresses.

*except for `/31` and `/32` networks

See the excellent answer to this question for how subnetting works.

• Yep. I personally feel CIDR got this wrong, and should have reversed the notation. As it is, a /8 is somehow bigger than a /24. Why not reverse the notation, to indicate the size of the network rather than the length of the mask? Mar 2, 2018 at 23:09
• @JoelCoehoorn, it's because the length of the prefix determines the routing, which is what layer-3 addresses are for. You need to look at this from the perspective of the networks and routers, not the hosts. Hosts on the same network use layer-2 to directly connect, but layer-3 addressing is for traffic between networks. Mar 2, 2018 at 23:13
• @JoelCoehoorn, you could possibly make a valid argument for your position, if CIDR notation was created in a vacuum. However, CIDR notation comes from a prior history of IP and in that history, network/subnet masks have always indicated the network portion of the address. To reverse this would have simply been too confusing (both for people and programmatically) and lead to many more problems. Mar 3, 2018 at 18:07