Subnetting and CIDR Notation: A Practical Working Guide
From /24 to /30 — how to read, calculate, and carve up CIDR notation, with a manual verification method so subnetting stops being rote memorization at work.
"Carve me out a /26", "how many bits is the mask 255.255.255.192" — in network-related work, this conversation happens almost daily. Subnetting is really just a simple bit of arithmetic; this article walks through it thoroughly so you can do most of the calculations in your head without reaching for a tool.
What CIDR notation is saying
192.168.1.0/24 reads as "the first 24 bits are the network bits". An IPv4 address is 32 bits of binary; the prefix length determines "how many bits identify the network", and the remaining bits identify hosts within that network. So:
- /24: 24 network bits + 8 host bits → 256 addresses
- /16: 16 + 16 → 65536 addresses
- /28: 28 + 4 → 16 addresses
One conversion you must burn into memory: powers of two. 8 bits = 256, 7 bits = 128, 6 bits = 64, 5 bits = 32, 4 bits = 16. Every subnet calculation is built on these numbers.
Masks, wildcard masks, and boundaries
A mask is the number with all 1s in the network bits and all 0s in the host bits. /24 is 255.255.255.0; /25 is 255.255.255.128; /26 is 255.255.255.192. Spot the pattern — each host bit you give up halves the last octet: 0 → 128 → 192 → 224 → 240 → 248 → 252. The wildcard mask is the mask inverted bit by bit, used in ACLs and OSPF.
The easiest place to go wrong is non-byte-aligned boundaries. For a block like 192.168.1.64/26, the boundaries fall at 64, 128, 192 — not at multiples of 0 or 256. To determine "which /26 does this IP belong to", divide the address by 64, floor it, and multiply by 64: 100 ÷ 64 = 1.56 → 1 × 64 = 64, so 100 sits inside the 192.168.1.64/26 block.
Practical carving patterns
When cutting a /24 into smaller blocks, keep this table in mind:
| Prefix | Addresses per block | Usable hosts | Blocks per /24 |
|---|---|---|---|
| /25 | 128 | 126 | 2 |
| /26 | 64 | 62 | 4 |
| /27 | 32 | 30 | 8 |
| /28 | 16 | 14 | 16 |
| /30 | 4 | 2 | 64 |
A rule of thumb for real-world planning: reserve 20%–30% headroom per block. If the business needs 50 addresses, carve a /26 (62 usable) rather than a /27 (30 usable) — squeezing addresses back out of already-allocated blocks is one of the most painful jobs in network operations.
Three common misconceptions
Misconception one: both addresses in a /31 are usable. From /24 to /30, every block must subtract the network address and the broadcast address, but /31 is specifically defined by RFC 3021 for point-to-point links and uses both addresses; a /32 is simply a single host. So "usable = total - 2" only holds for /30 and larger.
Misconception two: the network and broadcast addresses can "occasionally" be used. They can't. The network address represents the whole block in routing tables and the broadcast address reaches every device in it — assigning either to a host will inevitably cause problems.
Misconception three: private addresses (192.168.x.x) can't reach the public internet, so they're insecure. Private addresses merely aren't routed on the public internet; security depends on the firewall policy at the NAT boundary, not on the address itself. Internal lateral-movement incidents almost always happen in environments that "assumed the internal network was safe".
Verification methods and tools
Worried about errors after calculating by hand? Two verification moves: AND the computed network address with the mask — it should reproduce itself; and feed the boundary addresses (first usable, last usable, broadcast) into a tool for a second check. For day-to-day work, the CIDR calculator instantly produces the mask, network/broadcast addresses, and usable range; inputs are never uploaded to the server, so it's safe to use for production address planning.
After carving your blocks, use batch IP lookup to inventory the actual ownership of the whole range, or port probing to confirm what key hosts expose — the three tools together map out an entire network's assets in ten minutes.
Summary
- The CIDR prefix length determines block size; the core is knowing your powers of two: 128 / 64 / 32 / 16
- Non-byte-aligned boundaries (/25, /26) are the easiest to get wrong; divide by the block size, floor it, and multiply back to locate
- /31 and /32 are the exceptions to the "minus 2" rule
- Plan with headroom, carve by the table, verify with tools
Check your own network: run a full disguise check on the homepage, or try the fingerprint test.