A new branch is the rare moment when the address plan can be right from day one. There are no undocumented statics yet, no printer squatting in the DHCP pool, no “temporary” /24 that became permanent. The work you do before the switches arrive decides whether the site’s record and its live network start in agreement or start drifting on the first morning. This guide walks through a worked example: a 40-person office with phones, Wi-Fi, printers, cameras and a small server closet, carved out of one summarizable block.
Step 1: Inventory what will actually connect
Count devices by role, then add headroom. A reasonable starting sheet for the example office:
| Role | Devices today | Planned growth | Target usable hosts |
|---|---|---|---|
| Staff wired + Wi-Fi | 40 people × 2–3 devices | +50% | ~200 |
| Guest Wi-Fi | 30–60 | burst | ~250 |
| VoIP phones | 45 | +50% | ~70 |
| Printers, MFPs, IoT | 15 | +100% | ~30 |
| Cameras and door controllers | 12 | +50% | ~20 |
| Network management | 6 | small | ~10 |
| Local servers / appliances | 3 | small | ~10 |
Use the largest realistic number, not today’s. Re-addressing a live subnet later costs far more than a few unused addresses now.
Step 2: Request one summarizable block
Ask for a single block from the organization’s plan that covers everything, so the WAN and VPN can route the site as one prefix. The rows above total roughly 590 hosts, so a /22 (1,024 addresses) fits with room to spare. In the example, the branch receives 10.60.0.0/22. Record it in your IPAM as the site’s container before carving anything.
Step 3: Split largest-first (VLSM)
Allocate the biggest subnets first, each on its natural boundary, then fill the remaining space with progressively smaller ones. That order avoids fragmentation.
| VLAN | Name | Subnet | Usable hosts | Gateway | Mask |
|---|---|---|---|---|---|
| 10 | Staff | 10.60.0.0/24 | 254 | 10.60.0.1 | 255.255.255.0 |
| 20 | Guest | 10.60.1.0/24 | 254 | 10.60.1.1 | 255.255.255.0 |
| 30 | Voice | 10.60.2.0/25 | 126 | 10.60.2.1 | 255.255.255.128 |
| 40 | Printers/IoT | 10.60.2.128/26 | 62 | 10.60.2.129 | 255.255.255.192 |
| 50 | Cameras | 10.60.2.192/27 | 30 | 10.60.2.193 | 255.255.255.224 |
| 90 | Management | 10.60.2.224/28 | 14 | 10.60.2.225 | 255.255.255.240 |
| 60 | Servers | 10.60.2.240/28 | 14 | 10.60.2.241 | 255.255.255.240 |
| — | Reserved | 10.60.3.0/24 | — | — | — |
Keep the last /24 unassigned on purpose. It is where the next unexpected requirement goes (a lab, a second floor, an OT network) without breaking the summary route.
Step 4: Check the math with a calculator
Subnet arithmetic is easy to get subtly wrong at 5 p.m. A desktop calculator such as LizardSystems LanCalculator (Windows; free for personal use, with a paid business licence per machine at the time of writing) handles this well. Its vendor page says it can split a network by number of subnet bits, maximum number of subnets or maximum hosts per subnet, show addresses in several notations, and create and export a list of subnets or of the addresses inside each one.
A practical way to use it for VLSM:
- Enter
10.60.0.0/22and split into four /24s. Confirm the four boundaries match the table. - Take
10.60.2.0/24and split by hosts per subnet. Accept the first /25 for voice. - Split the remaining
10.60.2.128/25again: first /26 for printers, then continue with /27 and /28s from what remains. - Export the subnet list and attach it to the change ticket.
If you prefer a scriptable cross-check, Python’s standard library does the same arithmetic on any OS:
import ipaddress as ip
for s in ["10.60.2.0/25", "10.60.2.128/26", "10.60.2.192/27",
"10.60.2.224/28", "10.60.2.240/28"]:
n = ip.ip_network(s)
print(s, n.num_addresses - 2, n[1], n[-2], n.netmask)
Any overlap will show up immediately as a repeated address in the ranges printed.
Step 5: Define zones inside each subnet
Decide, per subnet, where statics, reservations and the DHCP pool live. For the staff /24, for example: .1 gateway, .2–.9 infrastructure, .10–.49 reserved for statics and reservations, .50–.250 dynamic pool. The reasoning behind that split is in DHCP reservations vs static IPs. Small subnets such as the /28s are usually fully static and need no pool.
Step 6: Build the record before the hardware
- Create the site, the /22 container and each subnet in your IPAM, with VLAN IDs and names. phpIPAM and NetBox both model VLANs and nested prefixes; NetBox’s VLAN groups can also enforce unique VLAN IDs per site.
- Add gateways, switch management addresses and any known statics as named entries.
- Configure DHCP scopes and exclusions straight from the record, not from memory.
- On go-live day, run a discovery pass on each subnet you own and compare the result against the record. Anything unexpected is either a missing entry or a device that plugged into the wrong port.
Common mistakes
- Sizing Wi-Fi by headcount. Phones, laptops, tablets and watches multiply fast; guest networks spike during events.
- Allocating small subnets first. You end up with holes that can’t host a /24 later.
- Reusing another site’s VLAN numbers with different meanings. Keep VLAN 30 as voice everywhere; it makes templates and troubleshooting portable.
- Forgetting infrastructure addresses. Gateways, HSRP/VRRP virtual IPs, AP management and UPS cards all need room.
- Skipping the reserved block. A plan with 0% free space is already out of date.
- Documenting after go-live. By then the record is a transcription of whatever happened, not the plan.
Related
Browse the subnet planning and calculators category for other options, the IPAM software category for where to keep the plan, and phpIPAM vs NetBox if you are choosing between the two open-source records. Obtain any tool from its vendor’s own site; see where to get the software.