If you want to know how CIDR subnetting works in practice, here’s the blunt version: a CIDR prefix like /24 is just a count of contiguous 1-bits in a 32-bit mask for IPv4 (or 128-bit for IPv6). You convert that prefix to a binary mask, logically AND it with any IP address to get the network address, invert it to find the broadcast (IPv4) and host range, and then carve the remaining host bits into subnets. In this workbook we’ll do that calculation by hand, apply it to a real three-tier VPC, and cover the mistakes that bite engineers in production.
Why Classless Subnetting Isn’t Just “Old Classes Without the Name”
Most beginner articles stop at “CIDR replaced classful A/B/C networks.” That’s true but useless when you’re staring at a terraform plan at 2 a.m. The real shift is that the network boundary is now a variable you control, not a fixed /8, /16, or /24 dictated by the first octet.
When I first tried to migrate a legacy data center to AWS, I assumed a /16 perimeter was enough because we had “class B mentality.” I was wrong. We needed dozens of smaller segments for microservices, and the variable-length subnet masking (VLSM) approach of CIDR let us pack those efficiently—but only after I learned to calculate boundaries exactly.
The thing nobody tells you about CIDR is that the prefix length is also a routing metric. A longer prefix (/32) is more specific and always wins over a shorter one (/24) in a router’s longest-prefix-match decision. That fact alone explains both subnet design and route summarization. The formal specification is RFC 4632, which obsoleted classful addressing in 2006, yet many network courses still teach classes first.
A second misconception: “CIDR is just slash notation.” No. It’s a combination of prefix notation and route aggregation. Without aggregation, the global BGP table would have collapsed decades ago. The prefix is the lever; aggregation is the load-bearing wall.
The Core Calculation: From /n to Usable Host Range
Let’s build a repeatable method. I call it the CIDR Translation Loop: prefix → mask → network → broadcast → usable. Below is the step-by-step for IPv4. The same loop applies to IPv6 with 128-bit math, which we’ll tackle later. Master this loop and you’ll never need to guess subnet sizes again.
Step 1: Convert the Prefix to a Binary Mask
Write 32 bits. Place n ones on the left, zeros on the right. For /26, that’s 26 ones and 6 zeros. Group into octets:
11111111 11111111 11111111 11000000
Convert each octet to decimal: 255.255.255.192. That’s your subnet mask. No memorization needed if you can count bits; but for speed I keep a cheat sheet (see below). The key is that the mask is just a filter.
Step 2: AND the IP with the Mask to Get the Network
Take an address, say 10.20.30.130. Convert to binary, align with mask, perform bitwise AND. The result is the network address. In our /26 example, the third octet is fully masked (255), and the fourth octet 130 (10000010) AND 192 (11000000) = 128 (10000000). So network is 10.20.30.128/26.
Step 3: Invert the Mask for Broadcast and Host Bounds
Invert the mask: 0.0.0.63. Add that to the network address: 10.20.30.128 + 63 = 10.20.30.191. That’s the broadcast for IPv4. Usable hosts run from .129 to .190—exactly 62 addresses (2^6 – 2).
Most people don’t realize the “-2” penalty only applies to IPv4 subnets that need a network and broadcast address. A /31 is valid for point-to-point links per RFC 3021, and /32 is a host route. Don’t blindly subtract two.
Worked Example Table
Here’s a quick visual block chart for a /24 carved into four /26s:
10.20.30.0/26 Network .0 Broadcast .63 Usable .1-.62 10.20.30.64/26 Network .64 Broadcast .127 Usable .65-.126 10.20.30.128/26 Network .128 Broadcast .191 Usable .129-.190 10.20.30.192/26 Network .192 Broadcast .255 Usable .193-.254
Notice the broadcast of the last subnet is .255, but the first three are not. That’s the myth-buster: broadcast is not always .255.
Advanced: Non-Octet-Aligned Prefixes (/20, /21)
A /20 mask is 255.255.240.0. The third octet 240 is 11110000, so you have 4 subnet bits in that octet, giving 16 subnets of size 256 within a /20. If you pick 172.16.32.0/20, the valid range is 172.16.32.0 – 172.16.47.255. I’ve seen terraform code fail because someone thought 172.16.32.0/20 ended at .255 of the third octet.
Another example: 192.168.51.137/21. Mask /21 = 255.255.248.0. Third octet 248 = 11111000. 51 decimal is 00110011. AND with 248 yields 00110000 = 48. So network is 192.168.48.0/21, broadcast 192.168.55.255, usable 192.168.48.1 – 192.168.55.254 (2046 hosts). That shows how an IP in the 50s maps back to a 48 network.
Subnet Zero and All-Ones Subnet Myth
Old routers reserved the first and last subnet of a major network (subnet zero and all-ones). Modern gear and cloud APIs permit them, but some legacy firewalls still log warnings. Know your platform before assuming a /26 inside a /24 is freely usable at both ends.
If you’d rather not hand-roll binary, our CIDR Calculator produces these bounds instantly. I still recommend learning the manual loop because cloud consoles occasionally reject Terraform plans due to implicit overlaps that only make sense once you see the bits.
IPv6 CIDR: Same Logic, Bigger Canvas
IPv6 uses 128-bit addresses. The prefix notation is identical: 2001:db8:abcd:0012::/64 means the first 64 bits are fixed. According to the IETF RFC 4291, IPv6 has no broadcast address; it uses multicast for discovery. That changes step 3 entirely.
How IPv6 Subnetting Differs in Practice
First, the “host bits” are usually 64 bits because Stateless Address Autoconfiguration (SLAAC) requires a /64 boundary. If you try to assign a /72 to an EC2 subnet, you’ll break auto-addressing. I learned this when a compliance team asked for “smaller IPv6 subnets” and we had to explain why /64 is the practical minimum for most segments.
Second, the sheer size means you rarely count individual hosts. A /64 yields 18 quintillion addresses. You design hierarchies: /48 for a site, /64 for a VLAN. Route summarization becomes trivial but also error-prone if you misalign nibbles (4-bit hex groups).
Why Nibble Boundaries Matter for IPv6
Because IPv6 is hex, planning at 4-bit boundaries (/60, /64, /68) keeps addresses readable. A /58 we used earlier splits at the 3rd hex digit of the 4th hextet. Misaligning to /59 creates addresses like 2001:db8::1:8000:: which is valid but confusing. I standardize on /56 per site, /64 per subnet, /128 per host route.
IPv6 Calculation Example
Take 2001:db8:1234:5600::/58. The prefix extends 58 bits, meaning the 4th hextet (5600) has 6 bits of network (since 48 bits cover first three hextets, 10 more bits into the 4th). The remaining 6 bits of that hextet are subnet bits. You can derive 64 subnets of /64 within that range. The math is hexadecimal, not decimal, which is why a visual block chart helps:
Base: 2001:db8:1234:5600::/58 Mask hex: ffff:ffff:ffff:ffc0:: Subnets step by 0x40 in 4th hextet: 5600, 5640, 5680, 56c0 ... up to 57c0
That’s a real-world allocation pattern I used for a multi-AZ VPC where each AZ got a /64 from a /58 pool. The alignment meant no overlapping /64s and clean summaries.
Designing a 3-Tier VPC with CIDR (IPv4 + IPv6)
Let’s apply the calculation to a concrete architecture: a public web tier, private app tier, and isolated database tier. I’ll use a 10.0.0.0/16 base VPC in AWS, which is a common pattern documented in the AWS VPC guide.
IPv4 Subnet Sizing Decisions
For a three-tier design across two availability zones, you need at least six subnets. A naive approach is six /24s (256 addresses each). But if your DB tier only needs 10 instances, that’s wasteful. Using VLSM, I allocated:
- Public: 10.0.0.0/22 (1022 usable) – handles autoscaling web fleet.
- Private app: 10.0.4.0/23 (510 usable) – moderate container pool.
- Database: 10.0.6.0/24 (254 usable) – RDS with standby.
This fits inside 10.0.0.0/21 (2048 addresses) leaving room for future tiers. The key insight: design from the largest tier downward, not arbitrarily equal slices.
Reserve Addresses in Cloud Subnets
In AWS, for every IPv4 subnet the VPC router reserves the first four addresses and the last address. For 10.0.6.0/24 that means 10.0.6.0 (network), .1 (router), .2 (DNS), .3 (reserved), .255 (broadcast/end). Usable is .4–.254 = 251. This contradicts the generic 254 formula and surprises anyone who sized DB clusters by the textbook.
IPv6 Allocation Inside the Same VPC
AWS assigns a /56 for the VPC, and you carve /64s per subnet. I mapped:
- Public AZ-A: 2001:db8:1:100::/64
- Public AZ-B: 2001:db8:1:101::/64
- Private AZ-A: 2001:db8:1:200::/64
- Private AZ-B: 2001:db8:1:201::/64
- DB AZ-A: 2001:db8:1:300::/64
- DB AZ-B: 2001:db8:1:301::/64
Because IPv6 has no NAT, every instance gets a globally routable address filtered by security groups. That’s a trade-off: simpler addressing but stricter firewall discipline. You cannot subdivide the /64 inside AWS—trying to assign a /80 will be rejected by the API.
The Overlap Mistake That Took Down a VPN
When I first tried this design, I reused 10.0.0.0/24 for public and later added a peering connection to an on-prem /16 that contained 10.0.0.0/16. The overlap caused asymmetric routing and silent packet drops. The fix was to renumber the VPC into 100.64.0.0/16 (shared address space per RFC 6598) before the tunnel came up. Lesson: always check CIDR overlap with existing routes before you commit.
Route Summarization (Supernetting) and Why It Matters
CIDR isn’t only for splitting; it’s for aggregating. If you advertise 10.0.0.0/24, 10.0.1.0/24, and 10.0.2.0/24 to a data center, you can summarize them as 10.0.0.0/22 if they are contiguous and aligned.
How to Compute a Summary Route
Find the lowest network address, convert to binary, count identical leading bits across all subnets you want to summarize. For the three /24s above, the first 22 bits match (10.0.0.0 to 10.0.3.255). The summary is 10.0.0.0/22. Use our CIDR Calculator to verify alignment—if the lowest address isn’t on a /22 boundary, summarization will include outside ranges.
IPv6 Summarization Example
If you hold 2001:db8:1:100::/64 through 2001:db8:1:1ff::/64, the summary is 2001:db8:1:100::/56 because a /56 covers 256 contiguous /64s aligned on the 100 hex boundary. That single route replaced 256 entries in my BGP table.
Trade-offs: Smaller Routing Tables vs. Blackholes
Aggregation reduces router memory and convergence time. But if you advertise 10.0.0.0/22 while only 10.0.0.0/24 exists, traffic to 10.0.1.0/24 may be blackholed. I’ve seen this in BGP where a supernet was announced without all components, causing intermittent failures. The mitigation is to only summarize when all child prefixes are internally reachable, or use null routes deliberately for discard.
Troubleshooting: Overlaps, Wrong Prefix, and Silent Failures
Here’s a field checklist I keep pinned:
- Confirm the prefix length matches the intended mask (a /25 is 255.255.255.128, not .192).
- Check network address is aligned: 10.0.0.130/26 is invalid because .128 is the network; the host bits must be zero in the network address.
- For IPv6, ensure /64 for SLAAC unless you use DHCPv6 only.
- Run an overlap test against VPC peering, VPN, and on-prem ranges.
- Remember AWS reserves the first four and last one IPs in each IPv4 subnet—your usable count is lower than 2^h-2 in cloud.
- Validate that supernets don’t accidentally include unallocated space that will blackhole.
API Rejection: “CIDR Block Is Not Valid”
Cloud providers reject networks where the host bits are set. If you type 10.0.0.1/24, the API corrects to 10.0.0.0/24 or errors. I keep a pre-commit script that masks addresses using the loop above. This caught a bug where a colleague committed 172.31.16.5/20 thinking it was a host assignment; the network was actually 172.31.16.0/20.
The most common “wrong prefix” error is using /32 on a subnet meant for multiple hosts. A /32 is a host route, not a subnet. I once debugged a Kubernetes node that couldn’t join because a Calico IP pool was misconfigured as /32 instead of /24.
The CIDR Engineering Cheat Sheet (Printable)
Print this table and stick it on your desk. It focuses on the prefixes engineers actually use, not the full /0-/32 list.
| Prefix | IPv4 Mask | Usable Hosts (IPv4) | Typical Use |
|---|---|---|---|
| /16 | 255.255.0.0 | 65,534 | Large VPC base |
| /20 | 255.255.240.0 | 4,094 | Multi-tier VPC |
| /21 | 255.255.248.0 | 2,046 | Large public cluster |
| /22 | 255.255.252.0 | 1,022 | Public subnet cluster |
| /23 | 255.255.254.0 | 510 | Private app tier |
| /24 | 255.255.255.0 | 254 (251 in AWS*) | Standard segment |
| /25 | 255.255.255.128 | 126 | Small team subnet |
| /26 | 255.255.255.192 | 62 | Small DB or management |
| /28 | 255.255.255.240 | 14 | Load balancer subnet |
| /30 | 255.255.255.252 | 2 | Inter-router link |
| /31 | 255.255.255.254 | 2 (RFC 3021) | Point-to-point link |
| /32 | 255.255.255.255 | 1 | Host route / loopback |
| /56 (IPv6) | n/a | 256 /64s | Site allocation |
| /64 (IPv6) | n/a | 18,446,744,073,709,551,616 | Single LAN segment |
*AWS reserves 5 addresses per subnet, so a /24 yields 251 usable EC2 addresses. That’s the kind of edge case the textbooks skip.
Visual Block Chart for Quick Mental Math
Prefix bits | Mask octet increment | Host bits /24 -> last octet 0 -> 8 host bits (256) /25 -> last octet 128 -> 7 host bits (128) /26 -> last octet 192 -> 6 host bits (64) /27 -> last octet 224 -> 5 host bits (32) /28 -> last octet 240 -> 4 host bits (16) /29 -> last octet 248 -> 3 host bits (8) /30 -> last octet 252 -> 2 host bits (4) /31 -> last octet 254 -> 1 host bit (2, special)
This chart is the mental model I use instead of memorizing decimal masks. Start from /24 as baseline and each added bit of subnetting halves the host count.
Putting It Into Practice with a Calculator and Final Thoughts
You now have the full loop: prefix to mask, mask to bounds, and bounds to design. The manual skill prevents costly cloud misconfigurations. When speed matters, the CIDR Calculator validates your work. For deeper IP allocation cost modeling, some teams even cross-reference our Ex Works Pricing Calculator to estimate egress fees tied to address sprawl—though that’s a financial tangent.
CIDR is not just notation; it’s an engineering lever. The next time someone says “just use a /24,” you’ll know exactly what that commits you to, and whether a /26 or a /22 serves the system better. That’s how CIDR subnetting works when it meets production.