One Switch, Many Networks: A Gentle Guide to VLANs

VLANs: one switch, many networks

Two posts ago I hung a “coloured wristband” on an Ethernet frame and promised it would matter later. Last post, per-VLAN spanning-trees wandered in uninvited. Both were IOUs for this one. So let’s finally talk about VLANs — the trick that lets a single switch quietly pretend to be several, and one of the most useful ideas in the whole networking toolbox.

The problem they solve is an everyday one. You’ve got one switch — or a building full of them — but you need Finance, the guest Wi-Fi, and the CCTV cameras to be utterly unable to see one another. The old answer was to buy separate switches for each and never plug them together: expensive, inflexible, and a headache the moment someone moves desks. VLANs are how we stopped doing that.

One switch pretending to be several

A VLAN — Virtual LAN — lets you carve one physical switch into several logically separate ones. Assign some ports to VLAN 10 and others to VLAN 20, and the two groups behave as though they’re on entirely different switches: same metal box, same power supply, but as far as the traffic is concerned they live in different worlds.

flowchart LR
  subgraph V10["VLAN 10 (Staff)"]
    P1["Port 1"]
    P2["Port 2"]
  end
  subgraph V20["VLAN 20 (Guest)"]
    P5["Port 5"]
    P6["Port 6"]
  end

Notice what isn’t in that picture: any line between the two groups. That’s not an oversight, it’s the entire point. A device in VLAN 10 can’t so much as see a device in VLAN 20, even though they’re plugged into the same switch a few ports apart. Picture one office building with keycard-separated floors — same lifts, same plumbing, but Accounting simply cannot badge onto the executive floor.

How the switch keeps them apart: access ports and trunks

Two kinds of port do all the work here, and the difference between them is the single most useful thing to get straight about VLANs.

  • An access port belongs to exactly one VLAN. The device you plug in — a PC, a printer — knows nothing about any of this; it sends perfectly ordinary, untagged frames, and the switch quietly stamps them “VLAN 10” as they arrive. The port is the VLAN, and the end device is none the wiser.
  • A trunk port carries many VLANs down a single cable — the link between two switches, or up to a router. One wire, all the VLANs, kept rigorously separate.
flowchart LR
  PC1(["Staff PC"]) -->|"access: VLAN 10"| SWA["Switch A"]
  G1(["Guest laptop"]) -->|"access: VLAN 20"| SWA
  SWA ==>|"trunk: VLANs 10 and 20 (tagged)"| SWB["Switch B"]
  SWB -->|"access: VLAN 10"| PC2(["Staff PC"])
  SWB -->|"access: VLAN 20"| G2(["Guest laptop"])

Access ports face your users; trunks face your other infrastructure. Which raises an obvious question: if a trunk is shovelling ten VLANs’ worth of traffic down one cable, how on earth does the far end tell them apart?

The wristband returns: the 802.1Q tag

This is where the coloured wristband from the encapsulation post finally earns its keep. On an access link there’s no need for a tag — the port already decides the VLAN, so the frame travels naked. But on a trunk, where many VLANs share one cable, each frame wears a little 802.1Q tag tucked inside it, stating exactly which VLAN it belongs to. The receiving switch reads the wristband, drops the frame into the right VLAN, and never lets the colours mix. One shared corridor, everyone wristbanded, no gatecrashing.

That’s the whole mechanism, really: access ports decide a VLAN by which port you used; trunks preserve the VLAN by tagging every frame. Get those two ideas straight and the rest is detail.

But now they can’t talk — and sometimes they must

We’ve built walls on purpose, and they work: VLAN 10 genuinely cannot reach VLAN 20. Lovely for the guest Wi-Fi and the CCTV. Less lovely when the Staff VLAN legitimately needs the file server sitting over on the Servers VLAN. So how does anything ever cross?

Full circle to Networking 101: moving within a network is a switch’s job, but moving between networks is a router’s. And as far as the network is concerned, each VLAN is a separate network. So to get from one VLAN to another, traffic has to travel up to a router (or a Layer 3 switch) that’s allowed to bridge the gap — under whatever rules you care to impose.

flowchart LR
  S(["VLAN 10 - Staff"]) --- SW["Switch"]
  V(["VLAN 20 - Servers"]) --- SW
  SW ==>|"one trunk, both VLANs tagged"| R{{"Router (or L3 switch)"}}
  R ==>|"the only sanctioned path between VLANs"| SW

The classic arrangement even has a nickname: router-on-a-stick. A single trunk runs from the switch up to the router carrying every VLAN, the router keeps a foot in each one, and it shuttles traffic between them. Here’s the bit for a security-minded brain: that router is the only sanctioned door between VLANs, which makes it the perfect place to hang access rules — “Staff may reach the file server on port 445, and nothing else.” Isolation by default; a single, inspectable crossing when you want one.

Why you’ll actually reach for them

Put it together and VLANs earn their place several times over:

  • Security segmentation. Guest Wi-Fi can’t see the finance systems; the CCTV cameras can’t see anything at all. Each VLAN is a boundary you drew on purpose.
  • Smaller broadcast domains. Every VLAN is its own broadcast domain — so a broadcast (or a broadcast storm, per the spanning-tree post) is contained to that one VLAN instead of flooding the entire site. You’ve quietly shrunk the blast radius.
  • Grouping by function, not geography. Someone on the first floor and someone on the third can share VLAN 30 no matter which switch each is plugged into. The network follows the org chart, not the floor plan.
  • Tidy extras, like a dedicated voice VLAN so the desk phones live apart from the PCs and can be prioritised.

The sharp edges (where VLANs bite back)

Because VLANs get leaned on as a security boundary, it’s worth knowing how that boundary gets attacked — and it nearly always comes down to trunks forming where they shouldn’t.

First, a Cisco-era foot-gun called DTP (Dynamic Trunking Protocol). By default, many switch ports will happily negotiate whether they’re an access port or a trunk with whatever’s plugged in. That sounds convenient and is a menace: a device that speaks DTP can talk an unconfigured port into becoming a trunk, and a trunk sees every VLAN. That’s switch-spoofing VLAN hopping — plug in, negotiate a trunk, and suddenly you’re on networks you were never meant to touch. This is exactly why “leave it on dynamic/auto and let it sort itself out” is a habit worth breaking.

Second, the native VLAN: the one VLAN on a trunk whose frames travel untagged (a backwards-compatibility hangover). If the native VLAN is left at the default — VLAN 1, which is also where every unconfigured port lands — you’ve handed over a second trick: double-tagging, where a frame is stamped with two 802.1Q tags and the outer one matches the native VLAN. The first switch strips the outer tag and cheerfully forwards the inner one straight into a VLAN the sender should never have reached.

The good news: the defence for all of it is the same, and it’s boring in the best way. Configure every single port explicitly — no port should be left to guess whether it’s access or trunk.

! Access port: pin the VLAN, kill DTP, protect the edge
interface Gi0/5
 switchport mode access
 switchport access vlan 30
 switchport nonegotiate
 spanning-tree portfast
 spanning-tree bpduguard enable

! Trunk: be explicit about what it carries; native VLAN off 1
interface Gi0/1
 switchport mode trunk
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10,20,30
 switchport nonegotiate

The rules that snippet encodes are the whole game: pin access ports to their VLAN and forbid them from ever trunking (nonegotiate kills DTP); make trunks state the exact VLANs they carry rather than “all of them”; and move the native VLAN off VLAN 1 to some unused throwaway ID that carries nothing. Then leave VLAN 1 itself empty and unused — treat it as cursed.

Warning

Never leave a switch port on dynamic or auto trunking. A port that can negotiate its own mode is a port an attacker can turn into a trunk — and a trunk sees every VLAN. Every port should be nailed down as either access or trunk, with negotiation switched off. “It just worked when I plugged it in” is, in this one case, precisely the problem.

The one-sentence version

A VLAN is one physical network convincingly split into many isolated ones: an access port decides a device’s VLAN by which socket it’s in, a trunk keeps VLANs apart by tagging every frame, and a router is the only sanctioned way to cross from one to another.

And that closes the loop I started three posts ago. Encapsulation showed how data gets wrapped for the journey; spanning-tree kept the switched network from eating itself; VLANs carve that network into deliberate, defensible pieces. The natural next step is the one Networking 101 promised on its way out — subnets, and the quiet maths that decides which of these networks a device thinks it’s on. That’s where we go next.

Previous
Next