// Guide · Networking & infrastructure

IP Subnet Planner

A three-step VLSM subnet planner that turns a single supernet into a clean, non-overlapping set of subnets for every VCF network plane — management, vMotion, vSAN, NSX TEP, edge uplinks. Built specifically for VCF 9 deployments where one IP overlap means a failed pre-check.

VLSMCIDRVCF 9 PresetsvSAN · NSX · vMotionIP AllocationOverlap Detection

Open the tool Jump to walkthrough

Quick start

Define your supernet — enter the parent CIDR (e.g. 172.16.0.0/16) that all child subnets will carve out of.
Add subnet requirements — pick a VCF preset or add custom rows. Specify a name and a target host count or prefix length per subnet.
Click Calculate — the tool emits a VLSM-aligned IP plan with no gaps, no overlaps, and a visual block map showing where each subnet sits in the supernet.
Review the IP allocation — copy individual subnets, or export the whole plan.

On this page

When to use this tool
How it works
Step-by-step walkthrough
Examples
Common mistakes
Related tools
FAQ

When to use this tool

Use this tool whenever you need to:

Carve a single allocated IP range (often /16 or /20) into multiple right-sized subnets for a VCF deployment.
Validate that no two subnets overlap before committing to a design — overlapping ranges cause silent routing failures and SDDC Manager pre-check errors.
Right-size subnets to host count instead of guessing prefix lengths.
Document the IP plan for handoff to network teams or for the VCF JSON Builder.

💡

Already have a draft IP plan? Skip to step 2 and add your existing subnet sizes — the tool will validate overlaps and re-fit them inside the supernet, telling you whether your draft works or where it collides.

How it works

VLSM (Variable Length Subnet Masking) lets you carve a single CIDR block into smaller subnets of different sizes, packed tightly without waste. The planner runs a first-fit allocator: largest requirement first, smallest last. Each subnet snaps to its natural boundary so the math always works.

The tool tracks three things in real time:

Used vs. free — how much of the supernet is allocated
Overlaps — flagged as red the moment they appear
Boundary alignment — every subnet starts on a valid boundary for its prefix length

Step-by-step walkthrough

1. Set the supernet

The supernet is the parent CIDR that all child subnets will be carved from. Common choices:

10.0.0.0/8 — large allocations across multiple sites
172.16.0.0/16 — typical single-site VCF management plane
192.168.0.0/20 — smaller deployment or lab

Pick the smallest supernet that still leaves headroom for future growth (workload domains, additional clusters, future TEP expansion).

2. Add subnet requirements

Click Add subnet for each network you need, or use the VCF preset button to populate the standard VCF planes in one click:

Management network
vMotion network
vSAN network
VM Management network
Host TEP network (overlay)
Edge TEP network
Edge uplink networks (×2 for BGP redundancy)

For each subnet, set either required hosts (the tool picks the smallest prefix that fits) or an explicit prefix length. Names are free-text but show in the export — use descriptive names like vcf-mgmt, vcf-vsan.

3. Calculate the IP plan

Click Calculate IP plan. The tool returns:

The full subnet table with network address, broadcast, usable range, and gateway suggestion
A visual block map showing how each subnet sits in the supernet (lets you spot wasted space)
Conflict markers if any subnet overlaps another
An overall capacity bar showing what % of the supernet is allocated

4. Export and use

Copy individual subnet rows for ad-hoc use, or export the full plan. The IP allocations are then ready to feed into the VCF JSON Builder as your management/vMotion/vSAN/TEP CIDRs.

Examples

Example · VCF management domain in /16

Carve 172.16.0.0/16 for a 4-host VCF management cluster:

vcf-mgmt        172.16.10.0/24    254 hosts
vcf-vmotion     172.16.11.0/24    254 hosts
vcf-vsan        172.16.12.0/24    254 hosts
vcf-vm-mgmt     172.16.13.0/24    254 hosts
vcf-host-tep    172.16.14.0/24    254 hosts
vcf-edge-tep    172.16.15.0/24    254 hosts

Uses 6× /24s out of a /16 — leaves ~99% of the supernet free for workload domains.

Example · Tight lab /22 deployment

Carve 10.10.0.0/22 for a 3-host PoC lab:

lab-mgmt        10.10.0.0/26      62 hosts
lab-vmotion     10.10.0.64/27     30 hosts
lab-vsan        10.10.0.96/27     30 hosts
lab-host-tep    10.10.0.128/26    62 hosts

Uses ~75% of the /22, keeps subnet sizes proportional to actual host count.

Common mistakes

⚠

Picking a too-small supernet A /24 supernet leaves no room for VCF planes — you'll need at minimum a /22 to comfortably split into mgmt + vMotion + vSAN + VM. Always size up; future workload domains need TEP and uplink CIDRs too.

🚨

Mixing public and RFC1918 ranges VCF's internal networks (TEP, vSAN, vMotion) should always be RFC1918 — don't use public IP space for these. The tool doesn't enforce this, but your routing and security posture will suffer.

⚠

Overlapping with existing networks The tool only validates overlaps within your supernet. If your new 172.16.0.0/16 conflicts with an existing corporate 172.16.0.0/12 at the routing layer, you'll discover it the hard way after deployment.

Tools that pair well with IP Subnet Planner:

FAQ

Does this tool save my IP plan anywhere?

No. Everything stays in your browser. Refresh the page and the plan is gone — copy or export anything you want to keep.

Can it import an existing IP plan from CSV?

Currently you add subnets manually or via VCF preset. CSV import is on the roadmap.

Why does VLSM order matter?

The planner allocates largest subnets first. If you list a /24 after a /27, the /27 might end up at an awkward boundary. The tool re-sorts internally so the result is always optimal regardless of input order.

Can I plan IPv6 subnets?

Not yet — current scope is IPv4 only, since VCF 9 management is still IPv4-primary. IPv6 planning is on the roadmap.

What does "right-sized" mean for a vSAN subnet?

For vSAN you only need an IP per host (3-8 in a typical cluster), so a /28 (14 hosts) is plenty. But many designs use /24 for consistency with management and to leave room for cluster expansion.