A closet switch has one job: move frames between ports. A VLAN lets it do that job for several networks at once, on the same physical hardware, without any of them seeing each other's broadcast traffic. That is the entire concept. The complexity is in the tagging.
Broadcast is the reason VLANs exist
Ethernet switches flood broadcasts to every port in the same broadcast domain. ARP requests, DHCP discovery, mDNS, and a surprising amount of vendor discovery traffic are all broadcasts. On a 48-port switch with 48 devices, that is tolerable. On a district network with 3,000 devices in one domain, it is not: every broadcast interrupts every device.
A VLAN is a boundary that stops the flooding. Ports in VLAN 104 are one broadcast domain; ports in VLAN 106 are another. The switch keeps a separate MAC address table per VLAN, and a frame that arrives on a VLAN 104 port is never forwarded out a VLAN 106 port.
Each VLAN is normally paired with one IP subnet. That pairing is a design convention, not a protocol rule, but it is the convention every network you will inherit follows.
The tag: 802.1Q
A frame leaving a switch port can carry a four-byte tag between the source MAC and the EtherType. The important part is a 12-bit VLAN ID, which allows 4,096 values; 0 and 4095 are reserved, leaving 4,094 usable VLANs.
Two port modes matter:
| Mode | Behavior | Used for |
|---|---|---|
| Access | One VLAN, frames leave untagged | End devices: laptops, APs in bridge mode, printers |
| Trunk | Many VLANs, frames carry tags | Switch-to-switch links, hypervisors, AP uplinks |
An access port is how a device that knows nothing about VLANs participates in one. The switch adds the tag on ingress and strips it on egress, so the laptop never sees it. A trunk is how tags survive between switches, because the receiving switch needs to know which VLAN each frame belongs to.
Native VLAN mismatch is the classic outage
A trunk has one untagged VLAN — the native VLAN, VLAN 1 by default. If one side expects untagged traffic in VLAN 1 and the other in VLAN 99, frames cross into the wrong broadcast domain. Nothing errors. Traffic leaks between VLANs, and the symptom is "some devices can see some things they shouldn't." Set the native VLAN to an unused ID on both ends, and never carry user traffic on it.
Worked example: one closet, three networks
A 48-port closet switch serves a classroom wing:
- Ports 1–20: student devices, VLAN 104,
10.40.40.0/21 - Ports 21–44: staff devices, VLAN 106,
10.40.60.0/22 - Ports 45–48: cameras, VLAN 108,
10.40.80.0/24 - Port 49: uplink trunk, tagged 104, 106, 108
Each access port is untagged in exactly one VLAN. The uplink carries all three tags. The switch does not route between them — that requires a layer 3 device, either the core switch or a firewall, with an interface in each subnet.
If you plug a laptop into port 5 and give it 10.40.60.50, it will not work. The port is in VLAN 104,
the switch will not route, and the gateway for 10.40.60.0/22 is not reachable from that broadcast
domain. This is correct behavior and a very common first-week confusion.
VLANs are not security
This is the most important sentence in the article: a VLAN is a broadcast boundary, not a trust boundary.
Trunking keeps frames apart at layer 2, but the moment you add layer 3 routing between VLANs — and you will, because staff need to print and students need the internet — the separation becomes a policy question, not a wire question. Whether VLAN 104 can reach VLAN 106 is decided by the router's policy, not by the switch's tags. Treat the VLAN as a label and the firewall rule as the control.
Where VLANs do help security
They reduce the blast radius of layer 2 attacks like ARP spoofing and DHCP starvation, and they give you a natural place to attach policy. That is real value. It is just not the same as segmentation, which is the article on trust boundaries later in this series.
VLANs are local to the switch
A VLAN ID has no meaning beyond the switches that carry it. VLAN 104 on one campus is unrelated to VLAN 104 on another unless you deliberately extend it. Two sites can both use VLAN 104 for different subnets and never conflict, because the traffic between them is routed at layer 3.
This is why district-wide VLAN numbering usually follows a scheme — site, function, or both — rather than being allocated per switch. A consistent scheme turns "which VLAN is that?" into arithmetic.
What breaks in production
- The trunk does not allow the VLAN. Most switches prune unlisted VLANs by default. Adding a VLAN to one switch and forgetting the uplink produces a network that exists everywhere except where it needs to go.
- Native VLAN mismatch. Two ends disagree about which VLAN is untagged, and traffic silently crosses domains. Always set it explicitly and identically.
- VLAN without an IP interface. The VLAN exists, ports are assigned, but nothing routes it. Devices get addresses from a DHCP scope on a server they cannot reach.
- DHCP scope on the wrong VLAN. The helper address points at a scope for VLAN 106 while the port is in VLAN 104. Addresses are handed out, and nothing works, because the gateway for that subnet is not on the wire.
- An access port plugged into another switch. Two access ports in different VLANs, connected by a cable, create a loop and a broadcast storm. Spanning Tree will block one of them, which is the only reason it is not always fatal.
Checklist
- Every access port has exactly one untagged VLAN, and it is documented.
- Trunks carry an explicit allowed list, and native VLAN is not 1.
- Every VLAN has exactly one subnet, one gateway, and one DHCP scope that agree.
- The layer 3 device has an interface in every VLAN that needs to route.
- VLAN IDs follow a written scheme, not a first-available habit.
Next
The moment two VLANs need to talk, you need a router. Continue with Routing, Gateways, and the Default Route.