Getting 'Must be valid Ipv4 CIDR' error after passing subnet's CIDR block

Question

I have created a VPC(public and private subnets) on AWS with IPV4 CIDR block as 10.0.0.0/26 (i.e. it can have 2^6 = 64 IP addresses along with one subnet address and one broadcast address). I want to create following two subnets but I am getting Must be valid Ipv4 CIDR error:

1. A public subnet with 10.0.0.0/28 CIDR block, and
2. A private subnet with 10.0.0.8/28 CIDR block

If I am giving subnet mask as /28 and I want to divide the addresses into two subnets, the address will fall in range 10.0.0.0 [10.0.0.00000000] - 10.0.0.15 [10.0.0.00001111]. On the other hand, if I am giving CIDR block as 10.0.0.16/28, I am not getting any error. Why AWS is giving Must be valid Ipv4 CIDR error with CIDR block as 10.0.0.8/28?

Answer 1

A /28 has 2^(32-28) = 2^4 = 16 addresses, so the last octet of the all-zeroes address of the block must be evenly divisible by 16 (its least significant bits must be 0 0 0 0). The LSBs of 8 are 1 0 0 0.

10.0.0.8/28 is an invalid CIDR block. 10.0.0.0 through .15 is expressed in CIDR notation as 10.0.0.0/28.

---

Clarification, as requested, of the significance of the divisibility by the number 16, above:

It isn't exactly that the number of addresses is divisible by the last block, but rather that in CIDR notation x.x.x.x/n each block is always 2^(32-n) addresses in size and x.x.x.x must specify the first address in the block when you are specifying a block.

Converting an IPv4 address x.x.x.x to binary, you get a 32 bit number. The (32-n) least significant bits of the address x.x.x.x must be 0. This is the first (0th) address in the block, and is also called the "all-zeroes" address because the unmasked bits -- the final 32-n bits -- are all 0. When specifying a CIDR block for a subnet, this is the address that must be specified.

In the case of a /28 block, note that -- by definition -- any number expressed in binary whose least significant 32-28 = 4 bits are 0 0 0 0 is also divisible by 2^(32-28) = 16, and any other number is not.

For blocks of size /24 through /32, this math is easier for humans, since you don't need to mentally convert the whole of x.x.x.x in to binary -- you only need the last of the four octets.

The only possible /28 subnets that can be derived from a supernet of 10.0.0.0/26 are these:

10.0.0.0/28    .0 to .15
10.0.0.16/28  .16 to .31
10.0.0.32/28  .32 to .47
10.0.0.48/28  .48 to .63