How Big Should a Subnet Actually Be? Right-Sizing Broadcast Domains

Ask a network engineer how big to make a new subnet and the honest answer, most of the time, is a /24, because 254 hosts is a familiar number and the address reads cleanly with the network sitting in the third octet, as in 10.0.40.x with nothing left to decide. The habit is a leftover from the era of classful addressing, when a Class C network was a /24 by definition and the question never came up. It is wrong about as often as it is right, oversized by a factor of a hundred for a link between two routers and dangerously flat for a campus of six hundred laptops. The reflex skips the decision it looks like it is making, because a subnet has two sizes at once, and only one of them is the count of addresses.

The first size is capacity, the number of addresses the prefix can hold, and it is the one everyone calculates. The second is the broadcast domain, the set of devices that hear every broadcast and every ARP (Address Resolution Protocol) request the segment produces, and it is the one that decides how loud the network gets, how far a failure travels, and how cleanly you can separate one group of machines from another. Right-sizing a subnet means choosing a prefix that satisfies both at once, and the surprise, once you start weighing them against each other, is that the count of addresses is rarely the constraint that binds.

Begin with what a subnet is, since the word carries the whole argument. A subnet is the block of IP (Internet Protocol) addresses assigned to one segment of a network, and its size is fixed the moment someone chooses the CIDR (Classless Inter-Domain Routing) prefix, the slash number that says how many leading bits are frozen as the network's identity; our visual guide to CIDR notation builds that up from first principles. A /24 freezes twenty-four bits and leaves eight for hosts, which is 256 addresses, 254 of them usable once the network and broadcast addresses are set aside. That is the capacity question, and it is genuinely easy. Subnet sizing stays hard because three other forces pull on the same number, and they do not all pull the same way.

The first of them is the force capacity-math already serves: how many devices need an address, now and across the years this subnet will live. The trap is sizing for the count on the day you build it, because a subnet is awkward to grow once it carries production traffic, so the number that matters is the realistic peak three to five years out. That peak is usually larger than an inventory suggests, since one desk now accounts for a laptop, a phone, a dock, and a share of the wireless access points overhead, and dual-stack and IoT (Internet of Things) devices push the count higher still. A sound design lands somewhere near half full at steady state, which leaves room to absorb growth without a scramble; our guide to subnet utilization and capacity planning covers what to do when a live subnet drifts toward the crowded end of that range. Size for the peak you can defend, then round up to the next prefix that holds it with margin to spare.

The second force is the one the title points at. Every device in a subnet shares a single broadcast domain, so every ARP request, every DHCP (Dynamic Host Configuration Protocol) discover, and every multicast service announcement reaches all of them at once. A handful of hosts make background noise nobody notices. A few hundred make enough that ARP tables swell, modest hardware works harder to keep up, and one misbehaving device can wash broadcast traffic over everyone on the segment. The ceiling that has settled into practice is a few hundred hosts to a domain: a /24 sits comfortably beneath it, a /23 at 510 is getting large, and a /22 with 1,022 hosts on one flat segment is loud enough to regret. Switching has muted the raw volume of this since the days of shared hubs, and the next two forces do not care how good the switches are.

The third force is blast radius. A subnet is a unit of failure as much as a unit of addressing, because the faults that occur at layer 2, the Ethernet layer beneath IP, hit the whole segment together: a forwarding loop, a unicast flood from a saturated MAC table, a rogue DHCP server leasing out bad addresses, a broadcast storm. When five hundred users share one subnet, an event like that is a single incident and five hundred tickets, and the team spends the outage isolating something a smaller domain would have held to one floor. Spreading a population across several subnets does nothing to prevent these faults, but it caps how many people any one of them can take down.

The fourth force pulls back toward smaller, against capacity. A subnet is the natural boundary for access control, since firewall rules and router ACLs (access control lists) act on traffic as it crosses between subnets, never within one. Two hosts on the same subnet talk directly at layer 2 with nothing between them to inspect or deny, so a printer, a database server, and a security camera that share a subnet form one trust zone whether anyone intended it or not. Sizing well often means carving by role and trust rather than by raw count, giving voice phones their own block and cameras another even when the numbers would let them sit together; our guides to DHCP, static, and reservation strategy and to VLANs (virtual LANs) versus VRFs (virtual routing and forwarding instances) get into how those segments get built and kept apart. This force has only grown heavier as microsegmentation and zero-trust designs push enforcement closer to each host.

Hold those four forces together and the default /24 shows itself for what it is, a guess that happens to suit one case well, the ordinary user access subnet, and most others poorly. Spend a /24 on a point-to-point link between two routers and you have set aside 254 addresses for two endpoints and built a broadcast domain no one needed, the precise waste our guide to point-to-point links exists to prevent with its case for the /31 and its two usable addresses. Run the other way and pour an entire office into a single flat /16, sixty-five thousand addresses in one broadcast domain, and you have signed up for every problem on the list together: noise, an enormous blast radius, and a security model with no interior walls. The pattern surfaces wherever address space looks abundant, which is why Kubernetes clusters quietly burn through 10.0.0.0/8 and why merging two companies that both grew into 10/8 becomes the renumbering project nobody put in the budget.

A repeatable way through this begins before the arithmetic, with the role the segment plays, because the role implies both a size profile and a trust profile. A router link wants two addresses; a server rack wants tens of tightly governed ones; a user access network wants a few hundred with steady churn; a guest network wants isolation above all else. With the role fixed, count the devices and project the peak across the subnet's life, pick the smallest prefix that holds that peak with comfortable headroom, and only then test the result against the broadcast, failure, and trust ceilings. That last test is where the name right-sizing is earned, because the two halves of the decision can disagree: when the count argues for a /22 but the segment is flat user traffic, the better build is several /24s behind separate router interfaces rather than one domain of a thousand hosts, each a broadcast domain of its own, summing to the same capacity with a quarter of the blast radius. Capacity says go bigger, the domain says split, and the split wins.

One more habit keeps the plan from turning on you later. Leave the address space immediately above each subnet unassigned, so a /24 that fills can grow into a /23 in place with a mask change instead of a renumbering, a gap that costs nothing today and buys the cheapest expansion there is when utilization climbs. Our worked example of designing an IP plan from scratch leaves those gaps deliberately, and the utilization guide explains why growing in place is the fix you most want on the table when a subnet crosses its action line. A plan packed edge to edge saves a few addresses now and turns every later expansion into a project.

Across the roles a typical network carries, this process settles into a short list of sensible starting points, each anchored by whichever of the four forces binds hardest. The table below pairs the common segment types with the prefix they tend to want and the constraint that sets the size.

The split-or-stretch call is the one worth seeing laid out. Take a floor with three hundred user devices and a little growth ahead, and three ways to size it.

Three ways to size one floor

Floor population: 300 devices now, ~360 at projected peak

10.20.4.0/23                 510 usable, one broadcast domain
  ██████████████░░░░░░ 360 hosts   all in one domain, large blast radius

10.20.4.0/24 + 10.20.5.0/24  254 + 254 usable, two broadcast domains
  ██████████████░░░░░░ ~180 each   same fill, half the blast radius   ← right size

10.20.4.0/24                 254 usable, one broadcast domain
  ████████████████████ 360 hosts   over capacity, does not fit

The flat /23 fits the addresses and fails everything else, three hundred hosts and rising in one broadcast domain. The tight /24 keeps the domain small but cannot hold the population, already over capacity before the next hire badges in. Two /24s behind separate interfaces carry the same people at comfortable headroom while cutting the size of any single failure in half, and they cost only a second gateway and a second DHCP scope to operate. Holding both of a subnet's sizes in view at once is what turns the reflex back into a decision.

A few habits reliably produce the wrong size. The reflexive /24 everywhere is the common one, harmless until it lands on a router link or a thousand-host campus. Sizing for today's device count with no headroom is the next, a choice that feels efficient and guarantees the renumbering you would otherwise meet only after an acquisition. Sizing purely by count while ignoring trust boundaries yields subnets you cannot write a clean policy for, because traffic that never leaves the segment never reaches a firewall. And over-correcting into dozens of tiny /29s for the sake of caution trades one problem for two, a route table littered with fragments and a standing tax of gateways and scopes to maintain, with a renumbering still waiting the day one fragment outgrows its six usable addresses. The target is enough subnets to contain failure and separate trust, sized with room to grow, and no more than that.

All of this assumes you can see the shape of the plan while you decide, which is where choosing prefixes in a spreadsheet works against you. IPCraft shows a subnet's capacity and current utilization the moment you create it, sets it inside the parent-and-child hierarchy so overlaps and the free space above a block are visible before you commit, and suggests the next available prefix of whatever size you ask for, which turns the growth gap into something you can see rather than something you have to remember to leave. The same structure is reachable through the API, so an allocation request from Terraform or a provisioning script asks for a size and gets back a block that fits the plan instead of one carved by hand and hoped over.

It is worth ending where the address-count half of the question stops mattering. In IPv6 (Internet Protocol version 6, the successor with room for roughly three hundred forty undecillion addresses) the convention gives every subnet a /64, about eighteen quintillion addresses, whether it serves two hosts or two thousand, and capacity falls out of the decision entirely. What stays is the part of this post that was never about running out of room: how large a broadcast domain you want, how far you will let a failure spread, and where the lines between one trust zone and the next belong, a reframing our guide to IPv6 address planning follows the rest of the way down. Addresses were always the easy half of subnet sizing, and the day they stop being scarce, the half that remains is the half that was doing the real work all along.