Ask a lot of people to picture a subnet and they'll picture a /24 by default, 254 usable addresses, the last octet doing all the work. That instinct comes from somewhere real, but it quietly causes misreadings once you're outside the specific context that made it common in the first place. A firewall rule, a cloud VPC subnet, or a documentation table using anything other than /24 gets misread by anyone whose mental model stopped updating after the /24 assumption set in.
The Assumption Is Reasonable, Right Up Until It Isn't
None of this means /24 is a bad or outdated default to reach for as a starting guess. For a huge share of small, self-contained networks, it genuinely is the right size, and defaulting to it as a first guess costs nothing when it turns out to be correct. The actual risk isn't guessing /24 first. It's stopping there without confirming the guess against the specific prefix length that's actually written down in front of you, and treating every other prefix as if it behaves the same way that guess would have.
Where the /24 Default Actually Comes From
Before CIDR existed, IPv4 addressing used a fixed class system. Class A networks used the first octet for network identification, Class B used the first two, and Class C used the first three, which is exactly a /24 in modern notation. Class C was by far the most common size handed out to smaller organizations, and a huge amount of networking documentation, tutorials, and muscle memory got built around that specific block size during the years classful addressing was the norm. Wikipedia's article on classful network addressing covers this system in more detail, including why it eventually got replaced.
CIDR Broke the One-Size Assumption on Purpose
Classless Inter-Domain Routing exists specifically because rigid, fixed-size blocks wasted enormous amounts of address space. An organization needing 300 addresses had to take an entire Class B block of 65,534 under the old system, since there was no size in between. CIDR lets any prefix length from /1 to /32 be used, matching allocation size to actual need instead of forcing everyone into one of three fixed buckets. Wikipedia's page on CIDR explains how this shift happened and why it was necessary as the internet scaled past what the classful system could reasonably support.
Supernetting Combines Multiple /24s Into Something Bigger
Go the other direction and you get supernetting, where multiple contiguous /24 blocks get treated as one larger routable block, a /23 or /22, to reduce the number of separate routes a network has to advertise. Two adjacent /24s become a single /23 with 510 usable addresses instead of two separate blocks of 254 each. This is common at the ISP and large enterprise level specifically because advertising fewer, larger routes is more efficient than advertising many small ones, and it's a case where seeing "/23" and assuming it behaves like two independent /24s leads to real routing mistakes.
Splitting a /24 in Half Gives You Two /25s, Not Two Smaller /24s
Going the other direction, a single /24 split for two departments or two availability zones doesn't produce two smaller /24s, it produces two /25s, each with 126 usable addresses. This distinction matters because a /25 has a different network address, broadcast address, and valid host range calculation than a /24 does, and treating it like "basically a /24" when configuring a firewall rule or DHCP scope leads directly to addresses that either don't work or unexpectedly overlap with the neighboring /25.
Photo by panumas nikhomkhai on Pexels
Cloud VPCs Rarely Default to /24 at All
Anyone whose primary networking experience comes from cloud infrastructure has probably never seen a /24 as a starting default. A typical AWS VPC starts at /16, and individual subnets inside it are commonly carved into /20s or /24s depending on how many resources each availability zone needs, chosen deliberately rather than defaulted to. AWS's own documentation on VPC design covers the sizing tradeoffs at that scale, which look completely different from a small office network where a single /24 genuinely does cover everything.
The Original Addressing Scheme This All Sits On Top Of
All of this, classful addressing, CIDR, supernetting, cloud VPC sizing, sits on top of the original IPv4 addressing specification. The IETF's original Internet Protocol document is worth knowing exists even if you never read it end to end, since it's the root specification everything downstream, including the classful system that made /24 feel like the default in the first place, was eventually built on top of.
Documentation and Tutorials Reinforce the Assumption Long After It Stopped Being Universal
A lot of introductory networking material still teaches subnetting using /24 as the primary worked example, since it's the cleanest possible case, the split happens exactly on an octet boundary and the math involves whole, round numbers. That's a reasonable teaching choice, but it means an entire generation of tutorials and Stack Overflow answers default to /24 examples even when explaining concepts that apply identically to any prefix length. Someone learning primarily from that material absorbs the pattern that /24 is the normal case and anything else is an exception, when the reality in production networking is closer to the opposite: /24 is common but far from universal, especially the moment you're working with anything larger than a single small office.
Firewall Rules Are Where This Assumption Gets Expensive
The place this misreading causes the most concrete damage is firewall and access control rule writing. A rule intended to allow traffic from a specific /27 subnet, if someone misreads or miswrites it as a /24 out of habit, either fails to cover the actual intended range or, worse, opens access to a much larger block than intended, silently including addresses that were never supposed to have that access. Because firewall rules rarely fail loudly when they're too permissive, this class of mistake can sit unnoticed for a long time, discovered only during a security audit or, less fortunately, after it's already been exploited. Reading the actual prefix length on every rule, rather than assuming it matches whatever's most familiar, is a small habit that closes a real gap.
Reading the Actual Prefix Instead of Pattern-Matching
The fix for the /24 assumption isn't memorizing every other prefix length as a separate special case. It's treating the prefix length as data to actually read every time, rather than skimming past it because "it's probably a /24 like usual." A quick check against a calculator confirms the real host range and boundaries for whatever prefix is actually in front of you, instead of relying on a pattern that only held true under one specific, increasingly uncommon addressing convention.
https://evvytools.com hosts a free IP Subnet Calculator that takes any address and CIDR notation, /24 or otherwise, and returns the exact network address, broadcast address, and usable host range without any assumptions baked in. For the full mechanics behind how the math works for any prefix length, the guide on how subnet masks and CIDR blocks actually get calculated walks through it step by step.
Top comments (0)