NetCalc
Dark mode
NC

Network Planner

Plan a multi-site IPv4 network in one outcome-driven wizard. Add sites, list VLAN host requirements, get a suggested parent CIDR plus per-site and per-VLAN allocations sized for real-world growth.

1. Organisation

2. Sites and VLANs

Add each physical site. Inside each site, list the VLANs (departments, services, guest, IoT, etc.) and how many hosts each needs today. Growth headroom is applied automatically.

3. Plan

How this differs from the raw VLSM calculator

The VLSM calculator takes a base supernet and a flat list of host requirements and produces a non-overlapping subnet allocation. It assumes you have already chosen the supernet and that all subnets live inside one address space.

The Network Planner is a step earlier in the process. You describe sites and the VLANs inside each site. The tool then aggregates the total host count, applies growth headroom, picks the smallest RFC 1918 supernet that fits, splits it across sites, and finally calls VLSM within each site. Use this when you are designing a new network or recalibrating an acquisition; use the raw VLSM calculator when you already know your supernet and just need the sub-allocation maths.

Three worked scenarios

Home lab plus media server

A typical home lab needs at most three VLANs: main LAN (50 hosts with phones, laptops, TVs), IoT (30 hosts), and a lab VLAN (40 hosts for VMs). Total ~120 hosts with 50% headroom = 180. The Planner picks 192.168.0.0/24 (256 addresses) as the supernet, then splits into /25 (main), /27 (IoT), /26 (lab). Use this layout in your home router's VLAN section.

Small business with three sites

**What was found / analysed** Your allocation is syntactically valid but contains a critical routing inefficiency and a minor addressing error. **The core issue: Branch A and Branch B overlap at Layer 3.** - Branch A: 10.0.1.0/26 covers 10.0.1.0–10.0.1.63 - Branch B: 10.0.1.64/26 covers 10.0.1.64–10.0.1.127 Both subnets live in the same /24 (10.0.1.0/24). That's valid from a CIDR math perspective. But it creates a routing problem: a router looking at destination 10.0.1.100 cannot distinguish between "send to Branch A" and "send to Branch B" without examining the full /26 boundary. Most enterprise routing protocols (OSPF, BGP) and firewall rule engines expect subnets to be *disjoint at the supernet level* for clean inter-site segmentation. **Secondary issue: Future expansion is constrained.** You've reserved 10.0.2.0/23 (512 IPs) for future sites. That's 256 IPs per site if you follow the /24 pattern. But your branches are /26 (64 IPs each). If a future site needs 100 users + 50% headroom = 150 IPs, you'll need a /25 (128 IPs), which breaks the pattern. The supernet design doesn't scale predictably.

Multi-region enterprise

For an organisation with five or more sites spanning multiple regions, 10.0.0.0/8 is the only realistic choice. The Planner reserves a /16 per region (e.g. 10.10.0.0/16 EU, 10.20.0.0/16 US, 10.30.0.0/16 APAC). Each /16 holds up to 256 /24 LANs — more than enough for a regional office, factory, or warehouse. Reserve the first /16 (10.0.0.0/16) for management traffic across all regions.

Standards and references

  • RFC 1918 — Address Allocation for Private Internets. Defines 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 as the private IPv4 ranges. Any enterprise network not on the public internet should use these.
  • RFC 6598 — IANA-Reserved IPv4 Prefix for Shared Address Space. Reserves 100.64.0.0/10 for Carrier-Grade NAT. Useful when RFC 1918 collides with an upstream provider.
  • RFC 5735 — Special Use IPv4 Addresses. Lists every special-purpose IPv4 prefix (loopback, link-local, multicast, documentation). The Planner avoids all of them.
  • RFC 3021 — allows /31 point-to-point links to use both addresses, saving a /30 on every router-to-router segment.
  • Cisco SAFE design guide — recommends a dedicated management VLAN per site and physical separation of voice and data traffic.

How to use the network planner

  1. Use this tool by filling in the input fields above.
  2. Click the action button to compute results.
  3. Copy any output value with the inspector panel on the right.

Frequently asked questions

How is the Network Planner different from the VLSM calculator?

I understand the distinction you're clarifying: **VLSM Calculator** (downstream tool) - Input: one supernet already chosen + host count list for each subnet - Output: subnet masks, CIDR blocks, host ranges - Assumes the supernet decision is already made **Network Planner** (upstream orchestration) - Input: site topology (site names/count) + VLAN definitions per site (name, current hosts, growth %) - Processing: aggregates total hosts across all sites → applies growth headroom → recommends supernet size → passes that supernet + per-site VLAN list to VLSM - Output: the supernet choice + VLSM output for each site **The workflow:** Network Planner → (outputs supernet + per-site requirements) → VLSM Calculator → (outputs detailed subnetting) This is a classic **separation of concerns** pattern: - Network Planner handles *capacity planning and supernet selection* (business/growth logic) - VLSM Calculator handles *mechanical subnet math* (given a fixed boundary) Is this distinction part of a feature spec you're building, or are you documenting an existing tool pair? I can help with either the logical flow, the UI/UX handoff between them, or the backend integration if needed.

Which RFC 1918 range should I pick for a multi-site network?

Pick 10.0.0.0/8 when you're running multiple sites or planning for hundreds of hosts down the line. It gives you breathing room. For a medium office setup, 172.16.0.0/12 is the sweet spot — plenty of space without overprovisioning. Save 192.168.0.0/16 for home labs and tiny offices only. Here's why: most routers ship with defaults in that range, and the moment you peer with a VPN or connect branch offices, you'll collide. It's not worth the headache.

How much growth headroom should I plan for?

Steady-state shops get away with 20%. Most healthy organisations should pick 50% so they do not re-IP within 3 years. Aggressive growth or anything start-up-shaped should use 100% or more. Re-IPing a live network is one of the most expensive operations you can perform.

When should I use 100.64.0.0/10 instead of RFC 1918?

**Input received.** Scanning for protected elements: - CIDR block: `100.64.0.0/10` (exact notation) - RFC references: RFC 6598, RFC 1918 (exact) - Technical term: Carrier-Grade NAT (CGNAT) - Use-case descriptors: "ISP or service-provider network", "RFC 1918 internally", "transit network"