VLANs and Trunking
A VLAN slices one physical switch into multiple isolated broadcast domains by stamping a 12-bit ID into the frame. Two hosts on the same switch but in different VLANs cannot reach each other at layer 2 any more than if they were plugged into separate switches — the tag is what keeps prod traffic away from dev, or one tenant away from another, on shared hardware. It is how a single switch fabric serves segments that must stay apart.
The mechanism is an 802.1Q tag inserted into the Ethernet header. Access ports belong to exactly one VLAN and carry untagged frames to ordinary hosts that know nothing about VLANs; trunk ports carry many VLANs at once between switches, tagging each frame so the far end knows which VLAN it belongs to. Get the access/trunk distinction right and most VLAN problems disappear; get it wrong and traffic leaks between segments that were supposed to be isolated.
The 802.1Q Tag
802.1Q inserts a 4-byte tag between the source MAC and the EtherType. It begins with the tag-protocol identifier 0x8100 — which is what an outer EtherType of 0x8100 signals — followed by 3 bits of priority (802.1p class of service), a 1-bit flag, and the 12-bit VLAN ID. Twelve bits give 4096 values, but 0 and 4095 are reserved, leaving 4094 usable VLAN IDs.
The tag adds 4 bytes to the frame, pushing a full-size frame from 1518 to 1522 bytes on the wire. Switches that do not expect tagged frames may drop them as oversized "baby giants," which is one reason trunk links and the switches on both ends must agree the port is a trunk. The tag exists only on the wire between switches; an access port strips it before handing the frame to an unaware host.
# a VLAN subinterface on Linux: tag 10 rides out eth0 ip link add link eth0 name eth0.10 type vlan id 10 ip link set eth0.10 up ip addr add 10.0.10.2/24 dev eth0.10 # frames out eth0.10 carry 802.1Q tag, VLAN ID 10
Access Ports versus Trunk Ports
An access port is a member of one VLAN. Frames arrive and leave it untagged; the switch adds the VLAN association internally based on which port the frame came in on. This is what you plug a laptop, a server, or a printer into — the device has no idea a VLAN exists, and the switch keeps its traffic confined to that one VLAN.
A trunk port carries many VLANs between switches (or to a router or hypervisor) and tags every frame so the far end can sort them back out. A trunk is configured with an explicit allowed-VLAN list; anything not on the list is dropped. The classic outage is plugging a host into a trunk port or a trunk into an access port — the tagging expectation mismatches and traffic either vanishes or lands in the wrong VLAN.
The Native VLAN
Every trunk has one native VLAN whose frames cross the trunk untagged. It exists for backward compatibility with devices that send untagged frames onto a trunk, and by default it is VLAN 1. Untagged frames received on a trunk are assumed to belong to the native VLAN; tagged frames go to whatever VLAN their tag names.
The native VLAN is a security hazard. If the two ends of a trunk disagree on which VLAN is native, frames silently leak from one VLAN into another — a misconfiguration that breaks isolation without any error. Worse, the native VLAN enables one form of VLAN hopping, where a double-tagged frame escapes its VLAN. Set the native VLAN to an unused, dead VLAN and tag everything, so no traffic you care about ever rides a trunk untagged.
Inter-VLAN Routing
VLANs are isolated by design, so two VLANs that need to talk require a layer-3 device to route between them — there is no layer-2 path across the boundary, which is the whole point. The traditional approach is a "router on a stick": one trunk to a router with a tagged subinterface per VLAN. Modern networks use a layer-3 switch with a switched virtual interface (SVI) per VLAN, routing between them in hardware at line rate.
This is also where the "VLANs are not security" warning bites. A VLAN isolates broadcast at layer 2, but the moment you add inter-VLAN routing, traffic flows between them unless an ACL on the routed interface says otherwise. Isolation that depended only on the VLAN evaporates the instant a router bridges the two — real segmentation needs layer-3 access controls, not just separate VLAN IDs.
A VLAN is a layer-2 construct: it defines a broadcast domain, the set of ports that flood broadcasts to each other. It says nothing about IP addressing — it is purely about which frames reach which ports.
A subnet is a layer-3 construct: a range of IP addresses sharing a prefix, defining who is "local" for routing purposes. The two usually map 1:1 — one VLAN, one subnet — because it keeps addressing comprehensible, but nothing enforces it. You can run multiple subnets in one VLAN or split a subnet across VLANs, and both are confusing enough to avoid unless you have a specific reason.
- Mismatching the native VLAN across a trunk. If one end calls VLAN 1 native and the other calls VLAN 99 native, untagged frames silently cross into the wrong VLAN, breaking isolation with no error message to warn you.
- Treating VLANs as a security boundary on their own. A VLAN isolates broadcast at layer 2, but with inter-VLAN routing enabled, traffic flows freely between VLANs unless a layer-3 ACL blocks it — separate VLAN IDs are not access control.
- Leaving the default VLAN 1 as the native VLAN and carrying real traffic on it, which exposes the trunk to double-tagged VLAN-hopping attacks and management traffic on the same VLAN as user data.
- Plugging a host into a trunk port or a trunk into an access port. The tagging expectations mismatch, so the host's untagged frames land in the native VLAN or the trunk's tagged frames are dropped, and connectivity fails in a way that looks like a dead cable.
- Forgetting that two VLANs cannot communicate without a router. Designing separate VLANs for prod and a shared service, then being surprised they cannot reach each other, because nothing routes between them until a layer-3 device is added.
- Set the trunk native VLAN to a dedicated unused VLAN and tag all real traffic, so nothing you care about ever crosses a trunk untagged and the double-tagging hopping vector is closed.
- Prune each trunk's allowed-VLAN list to only the VLANs that must cross it, so a misconfiguration cannot leak an unrelated VLAN and broadcast flooding stays off links that do not need it.
- Map one VLAN to one subnet as the default convention, because the 1:1 alignment keeps addressing and troubleshooting comprehensible and avoids the confusion of multiple subnets sharing a broadcast domain.
- Enforce inter-VLAN policy with ACLs on the layer-3 SVIs, not with VLAN separation alone, since routing between VLANs opens the path unless an explicit rule on the routed interface restricts it.
- Configure access ports explicitly as access with a single assigned VLAN rather than relying on dynamic trunk negotiation, which prevents a rogue device from negotiating a trunk and reaching VLANs it should never see.
Knowledge Check
Two hosts sit on the same physical switch but in different VLANs. Why can't they reach each other directly?
- They are in separate layer-2 broadcast domains, so reaching across needs a router
- The switch lacks the bandwidth to forward between two VLANs at once
- ARP requests cannot resolve a MAC address across the two VLANs
- The inserted 802.1Q tag invalidates the frame's FCS checksum, so the host in the other VLAN drops it as corrupted
What is the risk of mismatched native VLANs on the two ends of a trunk?
- Untagged frames leak from one VLAN into another, breaking isolation silently
- The trunk refuses to come up until both ends agree on the native VLAN
- All tagged traffic on the trunk is dropped until the mismatch is resolved
- Every VLAN ID carried on the trunk gets renumbered on the wire to match the native VLAN's value at the far end
Why is "we put them in separate VLANs" not a complete security control?
- Once a router bridges the VLANs, traffic flows unless an ACL restricts it
- VLAN tags use weak encryption that an attacker can decrypt
- There are only 4094 VLAN IDs, so an attacker can guess the right tag
- Access ports continuously advertise their VLAN membership to whatever device happens to be connected to them
You got correct