The Subnet Mistakes Network Engineers Keep Making (And How to Stop)

Subnetting Is Not Hard. It Is Just Unforgiving.

There are a handful of topics in networking that experienced engineers will admit, quietly, they still get wrong from time to time. Subnetting is near the top of the list. The math is not difficult, the rules have not changed since 1993, and the worst-case calculation fits on the back of a napkin. And yet a meaningful share of outage post-mortems, AWS support tickets, and 3 a.m. pages still come back to someone confidently typing a CIDR block that does not say what they think it says.

The reason is not that engineers are bad at math. It is that subnetting punishes the kind of small, plausible-looking mistakes that brain-on-autopilot rapidly produces. A /24 looks like a /23 if you are reading too fast. A 10.0.0.0/8 in one VPC overlaps with a 10.0.0.0/16 in another and the routing table will helpfully tell you so only after the VPN peering goes live. The first usable host in a /30 is not the network address, and the broadcast is not the last address you want to assign. Each of these is obvious in isolation and easy to miss in context.

This post walks through the mistakes that show up most often in real environments — from junior network engineers building lab racks to senior cloud architects designing multi-region VPC layouts. Each one has the same shape: a calculation you could do by hand, an assumption you carried in from the last network, and an unlucky moment when nobody double-checked.

Mistake 1: Confusing the Network Address with a Usable Host

The first address in any IPv4 subnet is the network address. The last address is the broadcast. Neither is assignable to a host on a standard subnet, which means a /24 has 254 usable addresses, not 256. The /29 you carved out for a small server segment has 6 usable, not 8.

This is the canonical subnetting mistake and it never fully goes away. The reason it persists is that the calculation is correct in your head when you sit down to do it, but at the moment you are typing an IP into a configuration file you are not doing the calculation again. You are reading the network plan, picking the next address, and trusting that whoever drew the plan accounted for the off-by-two. A surprising fraction of the time, they did not. The router gets the network address as its inside interface, the DHCP scope starts at the broadcast, the firewall denies its own gateway. The symptom is usually "the new subnet works for most clients but not all," which is the worst kind of symptom because it does not point cleanly at the cause.

The fix is dull and effective: every time you stand up a new subnet, write down the network address, the broadcast, the gateway, and the usable range on the same line, all at once. Do not eyeball it. If a calculator gives you a number that disagrees with your napkin, trust the calculator until you can prove otherwise. The subnet calculator on this site will give you all four values from a single CIDR input, which is the format the rest of this article assumes.

The /31 and /30 Exceptions That Trip People Up

A /30 has four addresses and exactly two usable hosts. People expect this. A /31, defined in RFC 3021 in 2000, has two addresses and both of them are usable, because point-to-point links do not need a broadcast. People do not expect this, because they learned subnetting on /24s and the "subtract two" rule lives in muscle memory. If you are configuring a /31 between two routers and your IPAM tool refuses to let you assign 192.168.1.0 to one side and 192.168.1.1 to the other, the tool is wrong, not RFC 3021. Newer Cisco IOS, Juniper Junos, Arista EOS, and every modern Linux kernel handle /31 links without complaint. Legacy gear sometimes does not. Know which side of that line your hardware sits on before you commit a design.

Mistake 2: Reading the Prefix Length Backwards

The number after the slash is the count of bits in the network portion, counted from the left. A larger number means a smaller subnet. This is a topic where everyone nods, says "yes obviously," and then writes 10.10.0.0/8 in a Terraform module when they meant 10.10.0.0/16, because 8 felt smaller and they were thinking of subnet size, not prefix length.

The mistake reverses a 65,536-address subnet into a 16,777,216-address subnet, which then either fails to validate because it overlaps another VPC or, worse, succeeds and quietly takes ownership of routes you needed for something else. Cloud providers are particularly punishing here because the CIDR you choose for a VPC is effectively permanent. AWS allows secondary CIDR ranges to be added, but the primary cannot be changed without recreating the VPC and migrating every resource inside it. A /8 picked in a rush is a multi-year cleanup project.

The defensive habit is to read the prefix length out loud as a host count rather than as a number. "Slash twenty-four" becomes "two hundred fifty-six addresses." "Slash sixteen" becomes "sixty-five thousand." It sounds patronizing in writing and it cuts down on errors meaningfully in practice, because the inversion catches your attention at the moment you are about to type the wrong number.

Mistake 3: Picking a Subnet That Overlaps With Something You Cannot See

RFC 1918 gives you three private address ranges to work with: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Every networking diagram in every onboarding doc uses 10.0.0.0/24 or 192.168.1.0/24 as an example, which is exactly why these specific ranges are the worst possible choice for any subnet you actually deploy. The corporate VPN your remote employees use is on 10.0.0.0/24. The hotel Wi-Fi they connect from is on 192.168.1.0/24. Their home router is on 192.168.0.0/24. Every Cisco AnyConnect or WireGuard tunnel that lands on one of these is going to fight a routing table that already has a more-specific route for the local network.

The result is a class of bug that looks like "VPN works fine from the office, broken from home, intermittently broken from coffee shops." It is a hard bug to reproduce in a controlled environment because you cannot easily simulate the chaos of every consumer network in the world. The cheap fix is to avoid the cliché ranges entirely. Pick a /16 inside 10.0.0.0/8 that is not the first or last few, and pick a /16 inside 172.16.0.0/12 if you want a second range for VPCs in a different region. Picking 10.47.0.0/16 instead of 10.0.0.0/16 costs you nothing and removes an entire category of collision from your future.

Inside cloud environments, the trap repeats at a different scale. AWS VPCs that need to peer or be joined by Transit Gateway cannot have overlapping CIDRs. Engineers who spin up VPCs ad hoc with whatever block looks tidy at the time end up with five accounts, all using 10.0.0.0/16, and no way to join any of them without renumbering. The standard advice — write down a CIDR allocation plan for the whole organization before the first VPC exists — is unfashionable and works. Even a spreadsheet is enough. A spreadsheet that knows 10.10.0.0/16 belongs to dev-us-east-1 and 10.11.0.0/16 belongs to dev-eu-west-1 will save you from the worst case.

Mistake 4: Forgetting That CIDR Boundaries Are Not Arbitrary

A CIDR block must start on an address boundary that is divisible by its block size. 192.168.4.0/22 is a valid block because 4 is divisible by 4. 192.168.6.0/22 is not, because 6 is not. This rule is easy to violate when you are mentally subdividing space and trying to be efficient.

The symptom of a misaligned CIDR is that your firewall, router, or cloud provider rejects the configuration outright. That is the lucky case. The unlucky case is that a less-strict tool accepts the input, silently rounds it to the nearest valid boundary, and now you are routing a slightly different range than your documentation says. Linux's ip route for example will accept 192.168.6.0/22 and normalize it to 192.168.4.0/22 with no warning. The route is wrong, the comment is wrong, and the bug only surfaces when traffic for the addresses you thought were excluded shows up where you did not expect it.

The defensive habit is to always pick the network address as the boundary, then derive the range, rather than picking a range and trying to find a CIDR that fits. If you need to cover 192.168.6.0 through 192.168.9.255 you do not get to express that as a single CIDR — it crosses a boundary. You either split it into two CIDRs (192.168.6.0/23 plus 192.168.8.0/23) or you allocate a larger block that covers the range cleanly. There is no third option that does not lie to you.

Mistake 5: Treating VLSM as an Optimization Rather Than the Default

Variable Length Subnet Masking — handing out differently sized subnets from a single parent block — has been standard practice since RFC 1878 in 1995. It is not exotic. And yet plenty of networks are still designed as if every subnet has to be the same size, usually because someone learned subnetting on an exam that used a single fixed /24 across every example.

The cost of treating every subnet as a /24 is that you waste address space wildly. A point-to-point router link does not need 254 addresses; it needs two. A management VLAN with four switches does not need 254; it needs six. A user VLAN with 30 employees needs 32. Padding every one of these to a /24 means a /16 supports 256 subnets instead of the thousand or so you could actually fit. In a cloud environment where IP space inside a VPC is genuinely scarce — especially if you use EKS or GKE and every pod gets a real IP — this is the difference between a workable cluster and a renumbering project in 18 months.

The mental shift is to size each subnet for its actual use case, document the size in the IPAM, and accept that the resulting plan looks irregular. A network that has /30s for transit links, /28s for management, /26s for small server segments, and /23s for user VLANs is not messy; it is correct. The instinct to make it tidy by giving everything a /24 is the same instinct that breaks the design.

Mistake 6: Trusting the Subnet Mask From a Screenshot

A surprising number of misconfigurations come from someone reading 255.255.255.224 off a screenshot or a piece of paper, converting it incorrectly to CIDR, and typing the wrong prefix into the new device. The conversion is not hard — 224 is 11100000, which is three set bits, which makes it a /27 — but it is exactly the kind of small calculation that an engineer does in their head while doing four other things, and the failure mode of doing it wrong is silent until traffic does not flow.

The two masks people consistently get wrong are 255.255.255.240 (/28, not /29) and 255.255.255.248 (/29, not /28). The off-by-one between them is easy to make and the resulting subnet is either half or double what you intended. Either outcome leaves a host that thinks its peer is on the same network when it is not, or thinks a remote host is local and never asks the gateway to route the packet.

The same problem in reverse happens with wildcard masks on Cisco ACLs, where 0.0.0.255 is the inverse of 255.255.255.0 and the two get mixed up. The only reliable defense is to derive everything from the CIDR, not from a mask written in dotted decimal. If you see a dotted-decimal mask in documentation, convert it to a prefix length immediately and use the prefix length everywhere downstream.

Mistake 7: The Default Gateway Outside the Subnet

A host's default gateway must be inside the host's subnet. This sounds like a tautology and it is, but it gets violated regularly in two situations. First, when somebody copies a configuration from one host to another and forgets to update the gateway. Second, when somebody changes the subnet mask on a host without updating the gateway, narrowing the subnet to the point where the gateway address is no longer covered.

The host will accept the configuration. ARP will fail silently — the gateway IP is not on the local broadcast domain, so no ARP response ever comes back. The host will try to reach anything off-subnet, get no response, and time out. Pinging the gateway directly will fail. Pinging another host on the same subnet will succeed, which is the diagnostic moment that points cleanly at the cause. If the host can reach its neighbors but cannot reach its gateway, the gateway is not its neighbor.

This particular mistake compounds with mistake 6, because the engineer who picked the wrong mask now has a host that thinks the gateway is on a different network than it actually is. Two small errors stacked are much harder to debug than either one alone.

Mistake 8: Forgetting That Cloud Subnets Are Smaller Than You Think

AWS reserves five IP addresses in every subnet: the network address, the VPC router, the DNS server, a future-use address, and the broadcast. So an AWS /28 has 11 usable addresses, not 14. An AWS /29 has 3 usable addresses, not 6, which makes a /29 nearly useless for most purposes. GCP reserves four. Azure reserves five. The exact list and reasoning varies, but the pattern is consistent: do not assume the textbook host count.

The practical implication is that the smallest subnet you should ever provision in AWS for actual workloads is a /28, and even that is tight if you need a load balancer, a NAT gateway, and a few EC2 instances. AWS itself recommends /24 for most application subnets, which gives you 251 usable addresses and leaves room for autoscaling. Allocating /28s aggressively to save space tends to bite you the first time an Auto Scaling group needs to spin up four extra instances and there is nowhere to put them.

This is also where Kubernetes networking changes the picture entirely. A cluster running the AWS VPC CNI assigns a real VPC IP to every pod. A modest cluster with a few hundred pods will exhaust a /24 in an afternoon. Plan node subnets and pod CIDR allocation deliberately, or you will get an EKS cluster that mysteriously cannot schedule new pods because there are no IPs to assign.

Mistake 9: Letting "It Works" Replace Verification

The unifying theme across every mistake above is that subnet configurations frequently appear to work even when they are wrong. A host with the wrong subnet mask will reach its neighbors. A VPC with an overlapping CIDR will route internally until the day you try to peer it. A subnet whose gateway lives outside the range will pass tests for any traffic that stays local. The wrong configuration is not loudly wrong; it is quietly wrong, and the quietness is what makes it dangerous.

The discipline is to verify the subnet on paper, not in the running system. After you have configured a host or a VPC, write out the network address, broadcast, mask, gateway, and usable range, and confirm each one matches the design document. If you have a calculator that produces these values from a CIDR — and that is exactly what the subnet calculator exists to do — paste your CIDR in and read the values back. A 30-second sanity check on the way out catches the configuration error that would otherwise be discovered by a customer at 4 a.m. on a holiday.

None of this requires being a brilliant subnetter. It requires treating subnetting as a discipline where small errors compound into outages, and applying the same boring rigor to every change. The engineers who never get bitten by these mistakes are not the ones with the deepest knowledge of IPv4 arithmetic. They are the ones who write the calculation down, then check it against the same calculation done by a different tool, and only then commit. That is the whole technique, and it is enough.