VLAN Planner
For a network that already exists. Write down what you actually run, and find out what is wrong with it before it finds you.
Local toolYour network plan stays in your browser. Nothing you enter is uploaded, logged, or sent to any server.
Findings
What gets checked
The same rules the designer applies, run against a scheme you already have. The point is that documentation drifts from reality, and the drift is where faults live.
- Duplicate VLAN IDs, and duplicate names, which make documentation ambiguous.
- Overlapping or identical subnets across VLANs.
- Gateways outside their subnet, or set to the network or broadcast address.
- DHCP ranges outside the subnet, reversed, including reserved addresses, or covering the gateway.
- Subnets above 85% full, where there is no room for a replacement device.
- VLAN 1 in use for user traffic, and IDs in the reserved 1002–1005 range.
Nothing here talks to your switches. It checks the plan as written, which is the document the next engineer will work from.
The ID space, and the parts of it you cannot have
A VLAN tag carries a 12-bit identifier, which gives 4,096 values. Two are spoken for: 0 means the frame carries a priority value but no VLAN, and 4095 is reserved. That leaves 1 to 4094 usable in principle. In practice, platform conventions remove more. Several vendors reserve 1002 to 1005 for legacy FDDI and Token Ring definitions that nothing has used in decades, and some reserve a further block for internal purposes, which is the sort of thing discovered when a switch refuses an ID that looked perfectly fine on the plan.
VLAN 1 is usable and generally should not be used. It is the default on most equipment, which means it is the VLAN an unconfigured port lands in, and control traffic often runs there. Carrying user traffic in it removes the distinction between "configured to be here" and "ended up here", which is exactly the distinction you want when tracing something unexpected.
One VLAN, one subnet — and when that stops being true
The usual convention is a strict one-to-one mapping between a VLAN and an IP subnet. It is a convention rather than a rule, and it earns its keep: it means a broadcast domain and an addressing boundary are the same boundary, so a question about one is answerable by looking at the other.
Deployments do break it — secondary addressing on an over-full segment, or several subnets sharing a VLAN during a migration. Both work and both cost you the correspondence. Once two subnets share a broadcast domain, "which VLAN is this host in" and "which subnet is this host in" have different answers, and every later piece of troubleshooting has to carry that exception in someone's head. If you do it, the important thing is to write down that you did and when it is meant to end.
Related tools
VLAN + Subnet Designer allocates a scheme from scratch. Trunk Visualizer covers tagging between switches.