Subnetting Explained: How to Read a CIDR Block and Size a Network

What the slash number means

An IPv4 address is 32 bits, written as four decimal octets. 10.0.5.130 is really 00001010 00000000 00000101 10000010. CIDR notation appends a prefix length: 10.0.5.130/22 says "the first 22 bits identify the network; the remaining 10 bits identify hosts within it".

That single fact produces every other number:

• Block size is 2^{(32 − prefix)}. For /22: 2¹⁰ = 1,024 addresses.
• The netmask is 22 ones followed by 10 zeros: 11111111 11111111 11111100 00000000 = 255.255.252.0.
• The network address is the address with every host bit cleared: 10.0.5.130 AND 255.255.252.0 = 10.0.4.0. So 10.0.5.130 lives in the block 10.0.4.0/22, not 10.0.5.0/22 — an easy thing to get wrong.
• The broadcast address is every host bit set: 10.0.7.255.
• Usable hosts run from 10.0.4.1 to 10.0.7.254: 1,022 of them.

The step that trips people up is the third one. 10.0.5.0/22 looks like a network address but is not one, because the 22-bit boundary falls in the middle of the third octet and 5 is not a multiple of 4. Routers and cloud consoles disagree about what to do with a misaligned block: some silently normalise it, some reject it, and some accept it and then behave strangely. Always state the aligned network.

Reading the third octet without a calculator

For prefixes between /17 and /24 the boundary is in the third octet, and the block size in that octet is 2^{(24 − prefix)}:

The same table applies to the fourth octet for /25 to /32 (step 128, 64, 32, 16, 8, 4, 2, 1) and to the second octet for /9 to /16. Once you know the step, the network is "round the octet down to the nearest multiple of the step", and the broadcast is "next multiple minus one". 192.168.77.200/26: step is 64 in the fourth octet, 200 rounds down to 192, so the block is 192.168.77.192/26 with broadcast .255 and hosts .193–.254.

Netmask, wildcard and the ACL that matched everything

A wildcard mask is the netmask inverted. /24 has netmask 255.255.255.0 and wildcard 0.0.0.255. Cisco IOS access lists, OSPF and EIGRP network statements take the wildcard form; almost everything else takes the netmask. The two are easy to confuse because both are four octets of mostly 255s and 0s.

The failure mode is quiet. An ACL written with 255.255.255.0 where 0.0.0.255 was meant tells the device "ignore the first three octets, match only the last" — which is very nearly "match everything". The rule appears to work in testing because the intended hosts do match; it also matches thousands of hosts that were never intended. When a permit rule is wider than it should be, nothing breaks, so nobody notices until an audit.

Addresses that are not what they look like

A block's numbers can be correct and still be the wrong block, because certain ranges have assigned meanings:

• 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 — RFC 1918 private space. Not routable on the public internet; the default choice for anything internal.
• 100.64.0.0/10 — RFC 6598 shared address space, meant for carrier-grade NAT. Cloud providers use it for managed services and load-balancer internals. It works like private space but is not RFC 1918, and some tooling treats it as public.
• 169.254.0.0/16 — link-local. Assigned automatically when DHCP fails, and used by cloud metadata services at 169.254.169.254. A host that "has an IP" in this range has no working network.
• 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 — reserved for documentation. Safe to put in a README, wrong to put in a config.
• 224.0.0.0/4 — multicast; 240.0.0.0/4 — reserved and unusable on most stacks.

Layerbit's subnet calculator labels each of these when you enter an address in them, which is worth a glance before a range goes into a design document.

Sizing a cloud network from the outside in

The most common real-world subnetting task is laying out a VPC. The mistakes are always the same: subnets that are too small for growth, subnets that cannot be aggregated for a route or a peering, and ranges that collide with an office network or another VPC when they are later connected. A method that avoids all three:

1. Pick the whole range first, generously. A /16 (65,536 addresses) per VPC is the usual choice. Address space is free; renumbering is not.
2. Make it unique across everything you might ever connect. If the office uses 10.0.0.0/16 and a partner uses 10.1.0.0/16, take 10.20.0.0/16. Overlap is the one thing peering and VPNs cannot fix.
3. Halve by the coarsest dimension. Split the /16 into a public /17 and a private /17, or into per-environment /18s. Each split is one more bit of prefix.
4. Carve subnets per availability zone at a fixed size — a /20 (4,096) for private application subnets, a /24 for public load-balancer subnets — and keep the sizes uniform within a tier so the layout is predictable.
5. Leave gaps. Allocate three AZs but reserve space for a fourth. Use half the private /17 and keep the other half unallocated. The gap costs nothing until the day it saves a migration.

Remember that cloud providers reserve addresses inside every subnet: AWS takes five (network, router, DNS, a future-use address, broadcast), so a /28 yields 11 usable hosts rather than 14. Kubernetes and container networking are hungrier still — a node pool that assigns a /24 of pod addresses per node exhausts a /16 at 256 nodes, which is why cluster pod ranges are typically /14 or larger.

The same ideas in IPv6

IPv6 addresses are 128 bits written as eight hexadecimal groups, with the longest run of zero groups compressed to :: and leading zeros dropped. 2001:0db8:abcd:0000:0000:0000:0000:0001 is written 2001:db8:abcd::1. The prefix logic is identical; the numbers are simply larger, which is why a proper calculator needs 128-bit integer arithmetic rather than floating point.

Three conventions replace the IPv4 habits. A single LAN is always a /64, because stateless address autoconfiguration needs 64 bits of interface identifier. A site typically receives a /48 (65,536 /64s) or a /56 (256 of them) from its provider. And there is no broadcast address: the all-ones address in a subnet is an ordinary host. The temptation to conserve IPv6 space with /120 subnets should be resisted — it breaks autoconfiguration and saves nothing meaningful out of 2⁶⁴ addresses per LAN.

Adjacent is not aggregatable

Two /24s can be summarised into one /23 route only if they share the first 23 bits. 10.0.2.0/24 and 10.0.3.0/24 do — their third octets are 00000010 and 00000011 — so 10.0.2.0/23 covers exactly those two. 10.0.3.0/24 and 10.0.4.0/24 are just as adjacent, but they differ in the third bit from the right, so the smallest block covering both is 10.0.0.0/21, which also covers six other /24s you did not intend to advertise.

This matters when a route table, a peering connection or a firewall has a limit on entries and you want to summarise. Allocating subnets on aligned boundaries from the start — the "halve by the coarsest dimension" step above — is what makes summarisation possible later. The calculator's supernet check reports whether a covering block is an exact aggregate or spills over, so you can see the difference before a route goes live.

The number after the slash is the whole story

Subnetting has a reputation for being fiddly because it is usually taught as a lookup table. Taught as "the prefix says how many bits are fixed", it reduces to three operations: raise two to a power, round down to a multiple, and check alignment. Everything else — masks, wildcards, host counts, aggregation — is a restatement of those. The mistakes that actually cost time are not arithmetic ones; they are the misaligned block accepted silently by one vendor and rejected by another, the ACL wildcard that matched too much, and the VPC laid out with no room to grow. All three are visible before deployment if you look.

Frequently asked questions