Guide · 8 min read
How to subnet a CIDR range.
Not the exam version. The version you use when someone hands you a /16 and asks for a plan that will still make sense in three years.
Step 1 — write the requirements in hosts, not prefixes
Start with what people actually asked for. Resist converting to prefixes yet, because the conversion is where the padding decisions get hidden.
Site: 10.0.0.0/16
app servers 600 hosts
database 40 hosts
kubernetes pods 4,000 hosts
management VLAN 30 hosts
point-to-point 2 hosts × 6 links
future "some"That last line matters more than the others. An address plan with no reservation is a plan that will be renumbered.
Step 2 — convert each count to a prefix
For each requirement: add 2 for the network and broadcast addresses, round up to the next power of two, then subtract the exponent from 32.
600 hosts needs 602 addresses, which rounds to 1,024 = 210, so 32 − 10 =/22. Do not be tempted by /23: 512 addresses minus 2 leaves 510, and 600 does not fit.
| Requirement | Needs | Rounded | Prefix | Usable |
|---|---|---|---|---|
| kubernetes pods | 4,002 | 8,192 | /19 | 8,190 |
| app servers | 602 | 1,024 | /22 | 1,022 |
| database | 42 | 64 | /26 | 62 |
| management | 32 | 32 | /27 | 30 |
| each p2p link | 2 | 2 | /31 | 2 |
The /31 is not a typo. RFC 3021 allows both addresses of a /31 to be used on a point-to-point link, since there is no broadcast to reserve. If your hardware predates that, use /30 and accept the waste.
Step 3 — allocate largest first
This is the step people get wrong, and the reason is alignment. A /19 has to start on a multiple of 8,192 addresses. If you hand out the small blocks first, they land in the middle of those boundaries and the large block has nowhere clean to go.
So sort descending and allocate from the top of the space:
10.0.0.0/19 kubernetes pods 8,192 10.0.0.0 – 10.0.31.255
10.0.32.0/22 app servers 1,024 10.0.32.0 – 10.0.35.255
10.0.36.0/26 database 64 10.0.36.0 – 10.0.36.63
10.0.36.64/27 management 32 10.0.36.64 – 10.0.36.95
10.0.36.96/31 p2p link 1 2
10.0.36.98/31 p2p link 2 2
10.0.36.100/31 p2p link 3 2
...
10.0.36.106/31 p2p link 6 2
10.0.40.0/21 RESERVED 2,048 10.0.40.0 – 10.0.47.255
10.0.48.0/20 RESERVED 4,096 10.0.48.0 – 10.0.63.255
10.0.64.0/18 RESERVED 16,384 10.0.64.0 – 10.0.127.255
10.0.128.0/17 RESERVED 32,768 10.0.128.0 – 10.0.255.255Using different prefix lengths inside one space like this is variable-length subnet masking (VLSM). It is the normal way to subnet; fixed-size subnetting is only simpler on paper.
Step 4 — check alignment and overlap
Two rules, and they are quick to verify:
- Alignment. Each block's starting address must be divisible by the block's size. 10.0.32.0 as a /22 means address 8,192 with a size of 1,024 — 8,192 ÷ 1,024 = 8, so it is aligned.
- No overlap. Each block's first address must be greater than the previous block's last address.
This is exactly the check the split tree makes structurally impossible to get wrong. Because every node is produced by halving its parent, children are aligned and non-overlapping by construction. Split the branches you need and read the result off the tree rather than doing the arithmetic twice.
Step 5 — reserve in whole blocks
When you have allocated what you need, leave the rest alone — and leave it as the largest whole blocks that fit, not as a pile of /24s.
In the plan above the remainder is expressed as a /21, a /20, a /18 and a /17 rather than the 216 /24s that cover the same addresses. Both are the same space, but the first version still contains a /17-sized hole for a future requirement that needs one. Pre-splitting reservations is the most common way an address plan quietly runs out of room while still showing free space.
Common mistakes
- Forgetting the +2. 254 hosts fit in a /24. 255 hosts need a /23. The network and broadcast addresses are not available to hosts.
- Sizing to today. A subnet at 90% utilisation is a renumbering project. Size to the next power of two above your projection, not above your current count.
- Allocating smallest first. It always seems to work until the one large block has nowhere aligned to sit.
- Using 10.0.0.0/24 for everything. RFC 1918 gives you 16.7 million addresses in 10/8. Spending a whole /16 per site is fine and makes the plan legible.
- Ignoring the routing story. Subnets that summarise into one aggregate per site keep routing tables small. Interleaved allocations across sites do not summarise at all.
A note on IPv6
None of the sizing arithmetic applies. You get a /48 per site, you use /64 per subnet because that is the autoconfiguration boundary, and you have 65,536 of them. Assign them by meaning — VLAN ID, floor number, service — rather than by size. The IPv6 calculator will show you how much space a delegation really contains.