vlans and trunking explained, then configured

one switch, pretending to be many

vlans are one of those concepts that sound complicated until you see the picture, then they click instantly. you've got one physical switch, but you want your accounting team's traffic to never touch your guest wifi traffic, and you don't want to buy five switches to make that happen. vlans let you slice one switch into multiple isolated broadcast domains using nothing but configuration. no extra hardware, just smarter rules about which port talks to which network.

this matters for defenders because vlan misconfig is one of the most common ways networks end up flatter than they think they are. if you assume your iot devices are isolated but they're actually sitting on the same vlan as your file server, you've got a problem you don't know about yet.

access ports: one vlan, no tag

an access port is the simple one. it's the port your laptop, desktop, or printer plugs into. it belongs to exactly one vlan, and the switch strips any vlan tagging before the frame reaches your device. your pc has no idea vlans exist. it just sees a normal ethernet frame.

think of access ports as the "last mile" of the vlan setup. this is where you decide which network a device actually belongs to. put the wrong device on the wrong access port and you've just handed it access to a segment it shouldn't be anywhere near.

trunk ports: many vlans, tagged

a trunk port is different. it's the link between switches, and it needs to carry traffic for multiple vlans at the same time over a single cable. to make that work, the switch adds a small tag to each frame using the 802.1q standard. that tag is basically a label that says "this frame belongs to vlan 10" or "vlan 20" so the switch on the other end knows how to sort it.

without that tag, the receiving switch would have no clue which vlan a frame came from, and everything would collapse into one giant flat network again, which defeats the whole point.

how the tag actually protects segmentation

the 802.1q tag gets inserted into the frame header, and it travels with the frame across the trunk. when it arrives at the next switch, that switch reads the tag, strips it if the destination is an access port, and forwards the frame only to ports assigned to that same vlan.

this is the mechanism that keeps your isolated networks isolated even though they're physically sharing the same cable and the same switch hardware. it's not magic, it's just consistent labeling enforced at every hop.

here's the conceptual flow, no live commands needed to understand it:

pc on vlan 10 -> access port (untagged) -> switch adds 802.1q tag -> trunk port -> 
next switch reads tag -> strips tag -> delivers untagged to correct vlan 10 access port

where this breaks in the real world

the classic mistake is leaving a trunk port's native vlan misconfigured, or leaving unused ports in vlan 1 by default. attackers who understand vlan hopping techniques look for exactly these gaps, native vlan mismatches, double tagging tricks, or ports left in trunking mode when they shouldn't be. you don't need to know how to exploit that to defend against it, you just need to know it's a real failure mode and check for it.

another common one: someone plugs a rogue switch into an access port and it starts negotiating trunking automatically because dynamic trunking protocol is still enabled. that single unlocked port can suddenly become a bridge between vlans that were supposed to be separate.

the takeaway

vlans are the backbone of network segmentation, and segmentation is one of the cheapest, most effective defenses you have. the setup is simple in concept: access ports for end devices, one vlan each, untagged. trunk ports for switch to switch links, many vlans, tagged with 802.1q so nothing gets mixed up.

if you're auditing your own network, walk your switch configs and confirm three things: every access port is assigned to the vlan you actually intend, no unused ports are sitting open in a sensitive vlan, and dynamic trunking is disabled on ports that don't need it. that alone closes off a huge chunk of the lateral movement risk that comes from a network being flatter than everyone assumed. segmentation only works if you actually check that it's configured the way you think it is.