Most network segmentation problems do not begin with a bad subnet mask.
They begin much earlier, when somebody needs another network and chooses the next convenient range.
A new wireless network goes in. Then CCTV. Then VoIP. A server VLAN appears. Guest Wi-Fi needs somewhere to live. A management network is added after somebody quite reasonably decides that switches, access points and hypervisors should not share a subnet with staff laptops.
Each individual decision may be perfectly defensible.
A few years later, however, the network diagram looks less like a design and more like an archaeological record.
The problem is rarely that nobody knows how to calculate a subnet. The problem is that nobody decided what the address space was meant to become.
Good network segmentation starts with that decision.
Segmentation is a design decision
Subnetting is mathematics. Segmentation is architecture.
The two are related, but they are not the same thing.
A subnet calculator can tell you that 10.20.40.0/24 contains 256 addresses and, in a conventional IPv4 LAN, 254 usable host addresses. It can give you the network address, broadcast address and subnet mask.
It cannot tell you whether CCTV cameras should be able to initiate connections to staff laptops.
It cannot decide whether printers belong on the corporate user network.
It cannot tell you whether the management interfaces of switches and firewalls should be reachable from guest Wi-Fi.
And it certainly cannot predict that, three years from now, somebody will need to connect your network to another organisation that happens to use exactly the same private address ranges.
Those are design decisions.
Before thinking about prefixes, begin by asking a more useful question: what are we separating, and why?
Start with function and trust
A typical small or medium-sized business might have several distinct groups of devices:
- staff workstations and laptops;
- servers;
- network infrastructure;
- administrative and management interfaces;
- voice devices;
- printers;
- CCTV cameras;
- building-management or IoT devices;
- guest Wi-Fi;
- development and test systems;
- backup infrastructure;
- externally exposed services.
There is no universal rule saying that each of those must have its own VLAN or subnet.
There is, however, a useful test. Ask what would happen if one device in that group were compromised. Would you be comfortable allowing it to communicate freely with everything else?
A CCTV camera, for example, may need to communicate with an NVR, DNS server and perhaps an NTP source. It probably has rather less reason to initiate connections to the finance director’s laptop.
A guest device needs internet access. It should not need access to Active Directory, printers, hypervisors or switch management interfaces.
A member of staff may need to use a printer. The printer does not necessarily need the same freedom to initiate connections back towards every employee device.
Once those relationships are understood, the network begins to design itself.
You are no longer creating VLAN 20 because “we need another VLAN”. You are creating a boundary because two groups of systems have different functions, different levels of trust or different consequences if something goes wrong. Containing that lateral movement is, in the NCSC’s own guidance, one of the main reasons segmentation exists at all.
Choose the address space before choosing the subnets
One of the easiest ways to create a difficult network is to allocate each subnet independently.
Perhaps the office begins with 192.168.1.0/24. Then somebody needs CCTV: 192.168.20.0/24. A voice network follows: 10.10.10.0/24. The new Wi-Fi project uses 172.16.5.0/24.
None of these ranges is inherently wrong — all three blocks come from the same reservation for private internets, RFC 1918. Together, however, they tell you very little.
A better approach is to begin with a sufficiently large parent block and allocate downwards from it.
Suppose an organisation chooses 10.20.0.0/16. That gives you a structure to work within. You might decide, for example:
| Purpose | Example allocation |
|---|---|
| Network infrastructure | 10.20.0.0/24 |
| Management | 10.20.1.0/24 |
| Corporate users | 10.20.10.0/23 |
| Servers | 10.20.20.0/24 |
| Voice | 10.20.30.0/24 |
| CCTV / IoT | 10.20.40.0/23 |
| Guest Wi-Fi | 10.20.50.0/23 |
| Reserved | Remaining address space |
This is not presented as the perfect addressing scheme. There is no such thing.
What matters is that somebody can look at the plan and understand the reasoning behind it.
Better still, in a multi-site organisation, you can reserve larger blocks per location. For example: Site A 10.20.0.0/20, Site B 10.20.16.0/20, Site C 10.20.32.0/20. Each site can then follow a similar internal structure.
That consistency becomes useful surprisingly quickly.
A support engineer seeing an address in 10.20.18.x may be able to infer the site and function without opening three spreadsheets and asking whoever happened to configure the firewall five years ago.
That is what a good address plan should do: reduce the amount of knowledge that exists only in somebody’s head — the same failure mode that makes the most valuable database in a business the one nobody has written down.
Do not design only for today
A common mistake is to count the devices currently in use and construct the smallest subnet that will hold them.
There are 42 cameras, therefore calculate the smallest network that accommodates 42 cameras.
Mathematically, that is tidy. Operationally, it may be less clever.
Will another building be added? Will the camera estate grow? Will the replacement system use additional management addresses? Will there be redundant controllers? Could another device category eventually share the same security zone? Will the network still be obvious to the person maintaining it in three years?
Address space is a resource, but private IPv4 address space within a sensibly chosen organisational plan is not normally so scarce that every network must be squeezed to its absolute minimum.
There is value in regularity. There is value in leaving space between allocations. There is value in being able to say that a particular range is reserved for infrastructure rather than discovering six unrelated systems scattered through it later.
Unused addresses in a deliberate plan are capacity. Unused addresses scattered through an accidental plan are confusion.
The /24 everywhere question
There is a temptation in network design discussions to turn every convention into a rule. Using /24 networks is one example.
A /24 is convenient. It is familiar, easy to recognise and provides 254 conventional usable IPv4 host addresses. For many business networks, that is entirely adequate.
There is nothing inherently unsophisticated about using /24 networks where they make operational sense.
The problem comes when /24 becomes the answer to every requirement.
A point-to-point or specialised infrastructure network may need very few addresses. A large wireless environment may need considerably more than 254. An IoT deployment might require hundreds or thousands.
This is where Variable Length Subnet Masking — VLSM, the classless addressing model formalised in RFC 4632 — becomes useful. Instead of assigning every requirement an identically sized block, VLSM allows you to allocate different prefix sizes according to need.
A large user population might receive a /22. A server segment might need only a /26. Another requirement might justify a /27.
The objective, though, should not be to win a competition for the fewest unused addresses.
The objective is to find a sensible balance between efficient allocation, future growth and operational clarity.
A technically perfect address plan that nobody can understand is not a particularly good plan.
A VLAN is not a security policy
This distinction is worth making because the terms are often used almost interchangeably.
A VLAN provides Layer 2 separation. That is useful, but it does not answer the important security question: what traffic is allowed to cross the boundary?
Imagine that staff devices are placed in VLAN 10 and IoT devices in VLAN 40. If the router or Layer 3 switch then permits unrestricted communication between VLAN 10 and VLAN 40, you have created separation, but relatively little security benefit.
Proper segmentation needs policy behind it. That might mean firewall rules or access-control lists stating that:
- guest devices may reach the internet but not internal networks;
- IoT devices may reach only the services they require;
- CCTV devices may communicate with their recording infrastructure;
- management interfaces may be reached only from designated administrative networks;
- users may access approved server services without receiving unrestricted access to the server segment;
- inbound connections between security zones are denied unless there is a documented reason to permit them.
The exact policy will depend on the environment. The important point is that segmentation makes security policy possible; it does not replace it.
A useful exercise is therefore to document every segment with two questions: what does this network need to reach? and what needs to reach this network?
If the answer is “everything”, it is worth asking whether the segment is achieving very much.
Think about failure as well as normal operation
Good network design is not merely about making legitimate traffic work. It should also make failures easier to contain and diagnose.
Consider what happens when a device begins broadcasting unexpectedly; malware reaches an endpoint; a DHCP server is accidentally introduced; a configuration error creates excessive traffic; an IoT device turns out to have a serious vulnerability; a contractor connects something you were not expecting; or one department suddenly consumes far more addresses than planned.
Segmentation reduces the size of the area affected by some of these problems. It also gives administrators more places to observe, control and understand traffic.
But there is a trade-off.
Every new segment creates another gateway, DHCP scope, firewall policy, monitoring requirement and piece of documentation. It may also create dependencies that need to be understood when services cross the boundary.
More segmentation is therefore not automatically better.
The right question is not how many VLANs can we create? It is: where does an additional boundary give us enough operational or security benefit to justify maintaining it?
That tends to produce rather better networks.
Plan for the networks you do not control
One of the less obvious reasons to plan private address space properly is that networks do not always remain isolated.
A business opens another office. A site-to-site VPN is commissioned. A cloud environment is connected. A customer requires access to a service. Two companies merge. An acquisition introduces another infrastructure estate.
Suddenly two networks that were designed independently need to route to one another.
And both use 192.168.1.0/24.
Or 10.0.0.0/8 has been treated as one enormous box of addresses from which teams picked whatever looked convenient.
Address overlap is often easy to ignore when networks are separate. It becomes considerably less entertaining when they need to communicate.
Renumbering is possible, of course. It is also the sort of project that rarely improves anyone’s week.
This is one reason larger environments benefit from allocating blocks hierarchically rather than choosing networks at random.
It is also worth maintaining a record of external address space that may need to interact with yours: cloud virtual networks, partner networks, VPN peers and acquired infrastructure.
You cannot prevent another organisation from choosing the same RFC 1918 range. You can at least avoid colliding with yourself.
Documentation is part of the design
A network plan is incomplete until another person can understand it.
At minimum, it is useful to record: network and prefix; purpose; VLAN ID, where relevant; site or location; default gateway; DHCP or static-addressing policy; security zone; important reservations; owner or responsible team; and notes explaining anything unusual.
There may be more. The particular fields matter less than maintaining a single source of information that people can find and trust.
This is the same problem that appears in asset registers, onboarding processes and operating procedures: information that exists somewhere is not necessarily information that the organisation can use. It is also why, in practice, a process nobody can describe is a process nobody can improve.
Network documentation also needs to record intent, not merely configuration.
10.20.40.0/23 — VLAN 40 is useful.
10.20.40.0/23 — CCTV and building IoT; isolated from corporate users; access permitted to NVR, DNS and NTP only is considerably more useful.
The first tells you what exists. The second begins to tell you why.
That distinction matters when somebody changes the network later.
The common mistake: calculating before designing
Subnet calculations are concrete. That makes them tempting.
You can type a prefix into a calculator and receive an immediate answer. Network address. Broadcast address. Mask. Usable range. Host count.
It feels like progress.
But you can perform every calculation correctly and still build a badly designed network.
A calculator cannot decide whether your addressing structure makes sense across five sites. It cannot know that a /27 which fits today’s requirement is likely to become cramped next year. It cannot decide which systems belong in the same trust zone. It cannot tell you whether two business units are likely to need connectivity after an acquisition. It cannot decide how much complexity your support team can reasonably maintain.
The arithmetic matters. The plan matters more.
A practical way to plan segmentation
For a new network — or when trying to bring some order to an existing one — I would approach the exercise roughly as follows.
- Inventory what exists. List the devices, services and existing networks. Do not begin by redesigning them; first establish reality. That includes awkward exceptions, forgotten static addresses, old VPN ranges and networks whose purpose nobody immediately recognises. Those tend to be the interesting ones.
- Group systems by function. Identify natural groups such as users, servers, voice, infrastructure, CCTV, IoT, guest access and management. Avoid creating categories simply because the technology allows you to — each group should have an operational reason to exist.
- Consider trust and communication. For every group, determine what it needs to communicate with. Treat that as a dependency exercise rather than starting immediately with firewall rules: you want to understand the required flows first.
- Choose the parent address space. Select a private address block large enough for the environment and foreseeable growth. If there are several locations, consider allocating a contiguous block to each site. If cloud or partner networks already exist, include them in the discussion before choosing ranges.
- Estimate capacity. Record current device counts and realistic future requirements. Do not size solely for the devices connected this afternoon — and at the same time, avoid reserving enormous blocks without a reason.
- Allocate the large structure first. Think from large to small: organisation, site, function, subnet. Doing this in reverse is how address plans become collections of unrelated exceptions.
- Carve the individual networks. Now calculate the actual prefixes. Use fixed sizes where consistency is valuable and VLSM where differing requirements make it worthwhile. Keep the result understandable.
- Reserve space deliberately. Future capacity should appear in the plan as reserved capacity rather than simply being whatever nobody has used yet. That small distinction makes later expansion much easier.
- Check for overlaps. Compare the proposed networks with existing sites, VPN peers, cloud address ranges and other infrastructure that may need connectivity. Do this before deployment rather than when the tunnel refuses to route.
- Define the policy between segments. Document the required traffic flows, then create firewall rules, ACLs and routing policy that implement them. A useful default is to permit what is required rather than assuming every internal network should trust every other internal network.
- Document the final plan. Record both the allocation and the reason for it — then keep the documentation updated when the network changes. This last part is less glamorous than creating VLANs. It is also the part your future self is most likely to appreciate.
Why I built NetCarve
This planning problem is what led me to build NetCarve, the subnet calculator and address planner in my project portfolio.
There are already plenty of subnet calculators. If all I need to know is the usable range for a /27, finding the answer has never been particularly difficult.
What takes longer is everything around the calculation. How should a larger block be divided? Where is the unused space? Which requirement should receive which prefix? Does an inherited list of networks contain overlaps? How do I turn the result into something I can put into the documentation?
NetCarve is a Chrome extension built around those questions, and it is free on the Chrome Web Store; the source is on GitHub.
It includes the usual IPv4 and IPv6 subnet calculations, but also a visual address planner that starts with a parent network and lets you split and name the resulting blocks. Subnets can be associated with VLAN IDs, and plans can be kept as projects.
There is also a VLSM solver: provide a base network and the required host counts and it calculates suitable allocations, shows unused capacity and can send the result into the visual planner.
The conflict checker accepts a list of networks and highlights duplicates and containment relationships — useful when dealing with inherited spreadsheets, VPN planning or networks assembled from several sources.
Plans and calculations can be exported as Markdown, plain text, CSV or JSON, which makes the result easier to move into client documentation, tickets or other systems.
One other design choice was important to me: the extension does its calculations locally. It requires no site access, makes no network requests and contains no analytics; projects remain in the browser profile.
The intention is not to make network-design decisions for you. It is to remove some of the mechanical work around those decisions so that more time can be spent on the part that actually matters: designing the network.
The practical next step
If you already manage a network, I would not begin by redesigning it. Start with something less dramatic.
List every subnet currently in use. Against each one, write: what is this network for? What belongs in it? What can it communicate with? Who owns it? How much of it is actually being used? Why was this prefix size chosen?
Then put the networks into one address-space view.
You may discover that the design is perfectly sensible. You may find a handful of historical oddities that merely need documenting. Or you may discover that what appeared to be a network plan is really fifteen years of individually reasonable decisions that have never been considered together.
Either result is useful.
Because good segmentation is not about squeezing addresses neatly into CIDR blocks. It is about creating boundaries that make the network easier to understand, secure, expand, troubleshoot and eventually hand to somebody else.
The arithmetic matters. The plan matters more.
