CIDR /24 vs /26: Find the subnet for 10.20.30.70 and count Azure IPs

You split 10.20.30.0/24 into four /26 subnets. Where does 10.20.30.70 belong? Their starting addresses are .0, .64, .128, and .192. Guessing from those numbers is risky at a boundary, so calculate the address ranges first.

We will follow .70 through its /26 boundary, then distinguish conventional IPv4 host counting from the number of IPs Azure can assign in that subnet.

Why does a /26 boundary advance by 64 addresses?

IPv4 addresses contain 32 bits. /24 fixes the first 24 as the network portion; /26 fixes 26. Fixing two additional bits divides the parent network into four subnets (2²).

Each /26 leaves six host bits, so it contains 2⁶ = 64 addresses. Its mask is 255.255.255.192. Within this /24, the last octet advances in blocks of 64:

Which /26 contains 10.20.30.70?

The diagram locates .70 in .64–.127. It also separates the conventional count of 62 IPv4 host addresses from Azure's 59 assignable addresses after its five reservations.

Because .70 is at least .64 and no more than .127, it belongs to 10.20.30.64/26. .63 closes the first subnet; .64 begins the second.

Within the second range, .64 is the network address and .127 is the last address. Conventional IPv4 host counting excludes both, leaving .65–.126, or 62 host addresses. That number is not automatically the number of IPs assignable to Azure resources.

Why can Azure assign 59 rather than 62?

Azure reserves the first four and last one IP addresses in each subnet. For this /26, .64–.67 and .127 are reserved. The calculable assignable range is .68–.126: 59 addresses. 10.20.30.70 is inside that range too. Microsoft's Azure VNet subnet guidance confirms the five-address reservation.

Keep “inside the CIDR block” distinct from “assignable to a resource on this platform.” Even if you need 59 instances, a /26 may leave no room for growth or for other address consumers. Check future capacity and overlap with connected networks as part of the design.

Verify the subnet boundaries with Python

The standard-library ipaddress module can confirm the arithmetic. Save this as subnet_check.py:

from ipaddress import ip_address, ip_network

parent = ip_network("10.20.30.0/24")
target = ip_address("10.20.30.70")

for subnet in parent.subnets(new_prefix=26):
    print(f"{subnet}: {subnet.network_address} ~ {subnet.broadcast_address}")

selected = ip_network(f"{target}/26", strict=False)
print(f"{target} belongs to {selected}")

assert str(selected) == "10.20.30.64/26"
assert ip_address("10.20.30.63") not in selected
assert ip_address("10.20.30.64") in selected
assert ip_address("10.20.30.127") in selected

10.20.30.0/26: 10.20.30.0 ~ 10.20.30.63
10.20.30.64/26: 10.20.30.64 ~ 10.20.30.127
10.20.30.128/26: 10.20.30.128 ~ 10.20.30.191
10.20.30.192/26: 10.20.30.192 ~ 10.20.30.255
10.20.30.70 belongs to 10.20.30.64/26

strict=False finds the network address .64/26 from the host address .70/26. ipaddress reports IPv4 network boundaries, not Azure-specific reservations. Subtract those separately when sizing Azure resources.

Key takeaways

Dividing a /24 into /26 networks creates four blocks of 64 addresses. .70 belongs to 10.20.30.64/26, spanning .64–.127. Conventional host counting yields 62; Azure reserves five of the 64 addresses, leaving 59 assignable ones in this example. Find the CIDR boundary first, then apply the platform's reservation rules.