One switch, one big room
By now you know a switch is a receptionist who learns where everyone sits: it watches the source address on each frame, builds a forwarding table by MAC learning, and sends unicast frames out the one port that leads to the right desk. That is a huge improvement over a hub. But there is one kind of frame the switch still cannot be clever about: a broadcast, addressed to everyone at once. When a device shouts "who has this address?" or "is anyone a DHCP server?", the switch must flood that frame out every single port.
Recall the key fact from the previous guide: a plain layer-2 switch does NOT break up a broadcast domain. Connect ten switches together and you still have one giant broadcast domain; every broadcast reaches every device. In a small office that is harmless. In a building with hundreds of machines, accounting, engineering, the guest Wi-Fi, the security cameras, all sharing one flat network, it becomes a problem of both noise and trust. Broadcasts from one group flood everyone, and any machine can in principle talk straight to any other at layer 2.
The old way to fix this was physical: buy a separate switch for each group and wire them so they never touch. That works, but it is wasteful and rigid. You over-provision ports for the small group, you run out for the big one, and the day someone in accounting moves to a desk wired into the engineering switch, you are pulling cables. Surely we can keep one set of switches and one set of cables, yet still carve the office into separate rooms? That is exactly what a VLAN does.
The idea: a colour on every desk
A virtual LAN, or VLAN, is a way to take one physical switch and split it, in software, into several logical switches that pretend not to know each other. You assign each switch port a VLAN number, think of it as a colour. Maybe ports 1 through 8 are red (VLAN 10, accounting) and ports 9 through 16 are blue (VLAN 20, engineering). The rule the switch now enforces is simple: a frame that arrives on a red port may only be sent out other red ports, never a blue one. Red and blue share the same metal box, yet they behave like two separate switches that were never plugged together.
The payoff is that each VLAN becomes its own broadcast domain. When an accounting machine on a red port sends a broadcast, the switch floods it only to the other red ports; the blue engineering machines never hear it. We have sliced one flat LAN into many smaller, quieter, isolated LANs, without buying a single extra switch or moving one cable. The switch even keeps a separate MAC learning table per VLAN, so red's addresses and blue's addresses live in different worlds.
The trunk: one cable, many colours
Colours on one switch are easy. The hard part is two switches. Suppose the accounting team and the engineering team each have people on both the first-floor switch and the second-floor switch. Red and blue both need to span both boxes. You could run two cables between the switches, one red and one blue, but that does not scale; with 50 VLANs you would need 50 cables. The clever fix is to send all the colours down a single shared link and label each frame so the far switch knows which colour it belongs to.
That shared, all-colours link is called a trunk, and the labelling standard is IEEE 802.1Q, the heart of VLAN trunking. When a frame leaves one switch on a trunk port, the switch inserts a tiny four-byte VLAN tag into the Ethernet frame header, right after the source MAC address. Twelve bits of that tag hold the VLAN number, which is why VLAN IDs run from 1 to 4094. The receiving switch reads the tag, learns which colour the frame belongs to, strips the tag back off, and forwards the frame only within that VLAN. The tag is a temporary travel sticker, present only on the wire between switches.
Inside a switch (no tag needed -- port colour says it all):
[ dest MAC | src MAC | type | ........ payload ........ | CRC ]
On a trunk between switches (802.1Q tag inserted):
[ dest MAC | src MAC | 0x8100 | VLAN=10 | type | payload | CRC ]
\__ 4-byte tag, 12 bits = VID __/
Access port -> sends/receives UNTAGGED frames (one VLAN)
Trunk port -> sends/receives TAGGED frames (many VLANs)So switch ports come in two flavours. An access port faces an ordinary device, a laptop or a printer, and carries exactly one VLAN; frames there are plain and untagged, because the device has no idea it lives in a VLAN at all. A trunk port faces another switch (or a router) and carries many VLANs at once, every frame wearing its 802.1Q tag. Most desk wiring is access ports; the links between switches are trunks. That single distinction, access versus trunk, untagged versus tagged, is most of what you need to read a real switch configuration.
Walking a frame across the trunk
Let us trace a single frame so the access port, the tag, and the trunk all click into place. Picture two switches joined by one trunk. Alice in accounting (VLAN 10) sits on the first-floor switch; Bob, also in accounting (VLAN 10), sits on the second-floor switch. Alice sends Bob a frame.
- Alice's laptop sends an ordinary, untagged Ethernet frame into its access port. It has no clue VLANs exist; it just addresses the frame to Bob's MAC.
- The first-floor switch sees the frame arrived on a VLAN 10 access port, so it knows the frame is red. Bob is reachable only out the trunk, so the switch inserts an 802.1Q tag stamped VLAN 10 and sends the now-tagged frame down the trunk.
- The second-floor switch receives the tagged frame, reads VLAN 10 from the tag, and confines its lookup to VLAN 10's forwarding table. It finds Bob's MAC on a VLAN 10 access port.
- Before sending the frame out to Bob, the switch strips the 802.1Q tag back off, because Bob's laptop is an ordinary device that expects a plain, untagged frame. Bob receives exactly what Alice sent, none the wiser that it ever wore a tag.
- Had a VLAN 20 (blue) machine been broadcasting at the same time, its broadcast would also cross the trunk, but tagged VLAN 20, so the far switch would flood it only to blue access ports. Red and blue ride the same cable yet never mix.
Notice the elegance: the end devices stay blissfully simple and unaware, while all the VLAN intelligence lives in the switches and on the trunk between them. The tag exists only for the hop between switches and is gone the moment the frame reaches its destination port. This is the same layering instinct you have seen throughout the ladder, hide a mechanism behind a clean boundary so the thing above it never has to care.
Trunks, loops, and bundling links
VLANs do not erase the lessons of the last guide; they layer on top of them. A trunk is still just a link between switches, so the network of switches can still contain loops, and a loop still breeds a broadcast storm. The spanning tree protocol still runs underneath, pruning redundant links into a loop-free tree. In fact most networks run a per-VLAN flavour of spanning tree, so red and blue can each follow a slightly different tree across the same physical switches, balancing the load instead of leaving one trunk idle.
There is a related trick for the opposite problem. Sometimes one trunk is simply not fat enough; a single 1 Gbps cable between two busy switches becomes the bottleneck. Spanning tree forbids you from just plugging in a second cable, because that would be a loop it would disable. The answer is link aggregation: tell both switches to treat two, four, or eight parallel cables as one logical link. Spanning tree then sees a single fat pipe (no loop), while the switches spread frames across the bundled cables and add the bandwidth together, with the bonus that if one cable fails the others carry on.