I’ve walked into enough networks where every VLAN is a /24 that I can usually guess how the addressing was planned. It wasn’t.
Someone picked 192.168.1.0/24 for the office. Then 192.168.2.0/24 for Wi-Fi. Then 192.168.3.0/24 for cameras. It worked, so they kept going until they ran out of convenient numbers. Nothing was technically wrong with it. It just wasn’t designed.
When I’m building or expanding a network, I don’t start by asking how many addresses a subnet can hold. I start by asking how the network is likely to change over the next few years. That usually leads to a very different addressing plan.
Stop defaulting to /24
The /24 subnet has become the networking equivalent of “I’ll fix it later.” It’s familiar. Easy to remember. Most small networks will work perfectly well with it.
The problem isn’t that /24 is bad. The problem is using it everywhere without thinking.
If a printer VLAN will never have more than twenty devices, giving it 254 addresses doesn’t make the network faster or more reliable. It just wastes address space and makes your addressing scheme harder to understand. The opposite happens too — I’ve seen guest wireless networks with a /24 that regularly ran out of DHCP leases because nobody considered how many phones and laptops would connect during busy periods. Subnet size should reflect the job it’s doing, not habit.
Think in powers of two
I don’t calculate subnet sizes from scratch very often anymore. I think in powers of two.
Need around 25 devices? That’s a /27. Around 50? A /26. Around 100? Probably a /25. A couple of hundred? Now you’re looking at a /24.
After you’ve done it enough times, you stop remembering subnet masks and start recognising patterns. The exact numbers matter less than developing an instinct for what “feels right.” If someone tells me they’re deploying thirty-five IP cameras, I’m already thinking /26 before I open a calculator. The calculator is there to confirm the plan, not create it.
Leave room for growth, not for anything
There’s a balance between planning ahead and planning for imaginary problems. I’ve seen networks where every VLAN was oversized because “we might need it someday.” Ten years later, they still hadn’t.
I usually aim for enough room that normal growth won’t require renumbering, but not so much that every subnet is mostly empty. If a department has fifteen users today and might grow to thirty over the next several years, a /26 makes sense. If they’re never going to exceed a dozen devices, a /28 is probably fine.
Good network design isn’t about eliminating every future change. It’s about avoiding predictable ones.
Group related networks together
The biggest improvement I ever made to my own designs wasn’t choosing different subnet sizes. It was becoming consistent.
Infrastructure lives together. Servers live together. Wireless networks live together. Voice lives together. Management interfaces live together. IoT devices live together.
The actual numbering doesn’t matter nearly as much as the organisation behind it. If every server VLAN starts with 10.20.x.x and every management network starts with 10.10.x.x, you spend less time looking things up and less time making mistakes. You also make life much easier for the next person who has to support the network. That next person might be you, three years from now.
Avoid overlapping before it happens
Network mergers, VPNs, and cloud connectivity all expose one common mistake: address overlap. Everyone loves 192.168.1.0/24 until two sites need to communicate and they’ve both used exactly the same range. Now somebody has to renumber a production network. Nobody enjoys that project.
When I’m designing a new environment, I think about where it might connect later. Will another office eventually be added? Is there a site-to-site VPN in the future? Will cloud resources need private connectivity? If the answer is yes, I’ll often move straight to a structured RFC1918 addressing plan instead of randomly picking another 192.168.x.x subnet. Future connectivity is much easier when the address plan was intentional from the beginning.
Documentation is part of the design
I’ve inherited networks where the VLAN list existed only in someone’s memory. Every switch had different descriptions. Some interfaces had none. The spreadsheet hadn’t been updated since before the last hardware refresh.
Good documentation isn’t something you create after the network is finished. It’s part of building it. Every VLAN should have a purpose. Every subnet should have an owner. Every IP reservation should make sense six months later. If someone else can’t understand the addressing plan after reading the documentation, the documentation isn’t finished.
Use the calculator after you’ve done the thinking
I use subnet calculators regularly — not because I don’t know subnetting, but because calculators are faster than mental arithmetic and far less likely to make a mistake after a long day on site.
The important part is that the calculator comes after the design. If you’re constantly entering different subnet masks until one “looks right,” you’re asking the tool to make design decisions for you. The free Subnet Calculator in the MB Networks SysAdmin Toolbelt is there to verify your work, calculate ranges, and save time — not to replace understanding.
Design the network you’ll have, not the one you have today
The best subnetting decisions are the ones nobody notices. New VLANs fit naturally into the existing structure. Documentation stays clean. VPNs come online without unexpected conflicts. Expanding a department doesn’t require renumbering half the building.
That’s rarely the result of clever calculations. It’s usually the result of spending ten extra minutes thinking about the address plan before the first switch is configured.
Questions or corrections? info@mb-networks.ca