How Full Is Too Full? Subnet Utilization and IP Capacity Planning

A subnet sitting at 80% full can mean two completely different things. On a point-to-point link between two routers, 100% is the design goal: two addresses, two routers, done, and it will stay that way until the building is rubble. On the subnet serving your office Wi-Fi, 80% on an ordinary Tuesday is a countdown timer, and the alarm goes off on whatever future morning the sales team hosts a vendor demo. A subnet, the block of IP (Internet Protocol) addresses assigned to one segment of a network, has a fixed size decided the day someone created it, and capacity planning is the art of noticing which kind of 80% you are looking at before the difference announces itself.

Start with what the percentage actually measures. A subnet's size comes from its CIDR (Classless Inter-Domain Routing) prefix, the slash number after the network address, and our visual guide to CIDR notation covers how that works from first principles. The everyday workhorse, a /24, contains 256 addresses, of which 254 are usable after the network and broadcast addresses are set aside, and in practice 253 once the router's own gateway address is spoken for. Utilization is simply addresses in use divided by addresses usable. The percentage is honest arithmetic, and yet it hides the two numbers that decide your fate: how many addresses remain free, and how fast they are being consumed.

It also matters what happens at 100%, because subnets fail rudely. Most user-facing subnets hand out addresses through DHCP (Dynamic Host Configuration Protocol), the service that leases an address to each device automatically when it joins the network. When the lease pool runs dry, the next device to arrive gets nothing at all: no address, no connectivity, and a help desk ticket that says the Wi-Fi is broken. The failures land on whoever joined the network most recently, so they look random, and while the network team investigates, someone under pressure hand-assigns an address that merely looks free, which trades an exhaustion problem for the duplicate-address fights that are even harder to diagnose.

Here is the trap inside the arithmetic: the DHCP pool is almost always smaller than the subnet. A sensibly carved /24 reserves a range for hand-assigned addresses, perhaps .1 through .99 for routers, printers, and servers, and leases out .100 through .250, a pool of 151 addresses. (Our guide to DHCP, static addresses, and reservations walks through why subnets get carved this way.) If only 20 of the static slots are occupied while 140 devices hold leases, the subnet as a whole reads a comfortable 63%, while the pool that actual laptops draw from is at 93% and three visitors away from empty. Whenever a subnet mixes static and dynamic ranges, the pool's utilization is the number that predicts the outage, and it is the one a subnet-level percentage quietly averages away.

Same subnet, two very different percentages

10.0.40.0/24  (254 usable addresses)

Static range  .1 – .99    ████░░░░░░░░░░░░░░░░  20 of 99 used
DHCP pool     .100 – .250  ██████████████████░░  140 of 151 leased

Subnet utilization:  63%   ← what a naive count reports
Pool utilization:    93%   ← what runs out on Tuesday

Lease duration adds a second wrinkle, because a lease outlives the device that took it. With the common 8-hour lease, every phone that walks through the lobby holds an address for the rest of those 8 hours, long after its owner has left the building. A 151-lease pool serving 130 steady devices looks survivable on paper, and then a 25-person all-hands meeting, each attendee carrying a laptop and a phone, empties it before lunch. High-churn subnets like guest Wi-Fi should run short leases, an hour or less, so abandoned leases return to the pool quickly; that single configuration change can behave like a pool expansion without moving a single address.

With those mechanics in hand, the original question gets a real answer. A population that grows by deliberate decisions, like a server subnet where every new address corresponds to a purchase order, can idle at 80% for years in perfect health: 50 free addresses against two new servers a month is roughly two years of runway. A population that grows by headcount and churns by the hour is a different creature, because 50 free addresses against 15 new laptops a month is one quarter, and DHCP exhaustion arrives as a cliff rather than a slope. The useful forecast is exactly that division: free addresses divided by net new devices per month equals months of runway. Compare the runway against how long a fix takes in your organization, including change windows and approvals, and act while the first number still exceeds the second.

Runway is the better metric, and percentage thresholds are the practical proxy, because a percentage needs no growth history to compute. The values that have settled into industry habit are 70% as the warning line and 85% as the action line, and they earn their keep on the velocity side too: a subnet that jumps ten points in a week is telling you about a new device rollout, a misbehaving script, or a lease-time change, and the percentage is merely the messenger.

When a subnet genuinely is filling, reach for the cheapest fix first: reclamation. Address records accumulate fiction over time, reservations for printers retired two budget cycles ago, static entries for servers that were decommissioned without paperwork, and leases pinned to laptops that left with their owners. An audit against reality routinely recovers 10 to 20% of a subnet, which at the 85% line buys months. This is also where record quality becomes capacity, because an inventory that drifted from the network, the chronic failure of spreadsheet-based IP tracking, makes every "free" address a small gamble, and the audit itself becomes the weekend-long project that gets postponed until the outage does it for you.

If reclamation is not enough, the next option is growing the subnet in place, turning the /24 into a /23 and doubling it to 510 usable addresses. The mechanics are gentle, a subnet mask change on the router and DHCP server while every device keeps its current address, but the option only exists if the adjacent block is still unallocated, and that was decided years ago by whether the original plan left growth gaps next to each allocation. Our worked example of designing an IP plan from scratch builds in exactly those gaps for exactly this moment; a plan packed edge to edge converts this easy fix into a hard one.

The remaining options restructure rather than stretch. Splitting carves the population along a natural seam, printers to one subnet, voice phones to another, each floor its own block, and tends to improve the network's health beyond capacity, since hundreds of chattering devices in one broadcast domain create noise that segmentation quiets. Re-carving, moving the whole population into a larger block somewhere else in the plan, is the expensive path, because it means renumbering: every static address, firewall rule, and hardcoded config gets touched, the same project-grade undertaking we mapped in our guide to merging networks after an acquisition. Split when the population has seams, re-carve when the subnet's mission has simply outgrown its corner of the plan, and price the renumbering honestly either way.

Everything above assumes you can see the numbers, and that assumption is where manual tracking quietly fails, because counting rows in a spreadsheet is most error-prone at exactly the moment accuracy matters. IPCraft computes utilization continuously for every subnet: each one shows its used and total counts with a utilization bar, the dashboard serves org-wide statistics pre-computed so the picture loads at a glance, and any subnet crossing 85% gets pinned to a high-utilization panel at the top. The color bands flip from green to yellow at 70% and yellow to red at 85%, the same lines drawn in the table above, so the dashboard renders the judgment this post just taught. The same counts are available through the API, which means your monitoring system can alert on utilization, or on runway you compute from it, alongside everything else it watches.

One closing perspective shift: this entire discipline is an IPv4 artifact. In IPv6 (Internet Protocol version 6, the successor with a vastly larger address space), the standard subnet holds about 18 quintillion addresses, utilization rounds to zero forever, and planning becomes a question of structure rather than scarcity, a reframing our guide to IPv6 address planning explores at length. Until your network lives there, the recipe stands: measure the pool and not just the subnet, know each subnet's growth rate so 80% has a denominator, alert at 70 and act at 85, and fix in cost order, reclaim first, grow if the plan left room, split or re-carve when it didn't.