// Guide · Networking & infrastructure

VLAN Allocation Planner

A complete VLAN management workspace for VCF deployments. Allocate VLANs across management, vSAN, vMotion, NSX TEP, edge uplinks, workloads, and storage — with conflict detection, naming enforcement, subnet auto-fill, and switch config export for the four major vendors.

Full VLAN 1–4094 RangeConflict Detection9 VCF TemplatesNaming EnforcerCSV Import/ExportMulti-vendor Switch Configs

Open the tool Jump to walkthrough

Quick start

Pick a VCF template — adds the standard VCF mgmt + WLD VLANs in one click, or start blank for full control.
Adjust VLAN IDs — change any number to fit your existing range. Conflicts highlight in red instantly.
Add subnets and notes — link each VLAN to its CIDR (use the IP Subnet Planner output) and add L3 routing notes for your network team.
Export switch configs — pick your vendor (Arista EOS, Cisco NX-OS, Cisco IOS-XE, Juniper JunOS) and copy the VLAN, SVI, and trunk config snippets.

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 when you need to:

Allocate VLAN IDs across a VCF deployment — management, vMotion, vSAN, host TEP, edge TEP, uplinks, plus workload domain (WLD) VLANs.
Document the VLAN plan for the network team in a single sharable artifact.
Generate switch config snippets in your vendor's native syntax (no manual translation from a spreadsheet).
Avoid VLAN ID collisions with an existing campus or enterprise VLAN scheme.
Enforce naming convention across teams.

How it works

The tool is a structured spreadsheet purpose-built for VCF VLAN planning. Each row is one VLAN with: ID, name, type (Management/vMotion/vSAN/TEP/etc.), associated subnet CIDR, gateway, and notes. As you edit:

Conflicts are flagged immediately — duplicate IDs, overlapping subnets, invalid CIDR/gateway pairs.
Naming is enforced if you turn on the convention checker (e.g. all VLANs must start with vcf-).
Switch configs regenerate as you type — view in any of the four vendor formats.

Step-by-step walkthrough

1. Start from a VCF template (or blank)

The tool ships with 9 pre-built templates covering common VCF layouts:

vcf-management — single management cluster (mgmt + vMotion + vSAN + host TEP + edge TEP + 2 edge uplinks)
vcf-management + wld1 — adds workload domain 1 VLANs
Multi-WLD variations for stretched and consolidated topologies

Or click Add VLAN to start from scratch and build row by row.

2. Adjust VLAN IDs to your range

Templates default to common ranges (100, 110, 120…) but every site has a different VLAN allocation policy. Edit each VLAN ID to fit your existing range. Conflict detection runs as you type:

Red — duplicate VLAN ID
Amber — VLAN ID is reserved (1, 1002, 4095)
Green — clean

3. Set network type and CIDR

For each VLAN, pick the type from the dropdown (Management, vMotion, vSAN, Host TEP, Edge TEP, Edge Uplink, Workload, NSX ALB, Storage, Backup, DMZ, iSCSI, NFS, OOB, Custom). Add the subnet CIDR — usually from your IP Subnet Planner output. The gateway field auto-fills with the .1 address.

4. Add L3 routing notes

Use the notes column to document routing requirements for your network team:

Which VLANs need L3 routing between them (e.g. mgmt → workload)
Which need to stay isolated (TEP, vSAN should be L2-only)
External BGP advertisement for edge uplinks
OSPF/EIGRP areas if applicable

5. Export switch config

Pick your switch vendor:

Arista EOS — vlan, interface Vlan, switchport mode trunk
Cisco NX-OS — Nexus syntax with system jumbomtu hints
Cisco IOS-XE — Catalyst syntax
Juniper JunOS — set-style commands for QFX/EX

The tool emits VLAN definitions, SVI configs (where applicable), and recommended trunk configs for ESXi-facing ports.

Examples

Example · Single management domain VLAN range

VLAN  Name              Type         CIDR              Gateway
1610  vcf-management    Management   172.16.10.0/24    172.16.10.1
1611  vcf-vmotion       vMotion      172.16.11.0/24    172.16.11.1
1612  vcf-vsan          vSAN         172.16.12.0/24    172.16.12.1
1614  vcf-host-tep      Host TEP     172.16.14.0/24    172.16.14.1
1615  vcf-edge-tep      Edge TEP     172.16.15.0/24    172.16.15.1
1616  vcf-edge-uplink1  Edge Uplink  172.16.16.0/30    172.16.16.1
1617  vcf-edge-uplink2  Edge Uplink  172.16.17.0/30    172.16.17.1

Common mistakes

🚨

Using VLAN 1 for anything VLAN 1 is the default native VLAN on most switches. Any traffic untagged hits it. Use it for nothing — your management plane, in particular, must use a non-1 tagged VLAN.

⚠

Reserved VLAN ranges Cisco reserves 1002-1005 (Token Ring/FDDI legacy). Don't use them. The tool flags these automatically.

⚠

Edge uplink VLAN is not the same as Edge TEP Edge TEP is internal NSX overlay (carries inter-edge tunnels). Edge uplinks are external L3 BGP peering with the physical fabric. They're different VLANs and serve different purposes — don't conflate them.

⚠

Forgetting to enable jumbo on the switch VLAN On Cisco NX-OS, the global system jumbomtu 9216 sets system-wide capability, but each interface still needs mtu 9216. The exported config includes hints — read them.

Tools that pair well with VLAN Allocation Planner:

FAQ

Does the tool reserve any VLANs automatically?

No, you control every VLAN ID. The tool only flags conflicts — it doesn't add or reserve VLANs without you adding them.

Can I import an existing VLAN list from a spreadsheet?

Yes — paste a CSV with the columns: VLAN ID, name, type, CIDR, gateway, notes. The tool parses it and populates rows.

Why does the type field matter?

Beyond documentation, it drives switch config templates. Overlay/TEP types get jumbo MTU recommendations; uplinks get L3 SVI configs; management gets standard L2 trunk recommendations.

My company uses 4-digit VLAN IDs (1000+). Will the tool work?

Yes, the tool supports the full 1-4094 range. The defaults use 100-200 because that's a common starting point, but edit them to whatever you need.

Does it validate that my VLAN range is allowed in the trunk allowed-list?

No — that's a switch-side concern. The exported config includes a recommended switchport trunk allowed vlan add <list> snippet for ESXi-facing ports, but you must verify it doesn't conflict with other allowed-VLAN policies on those interfaces.