VLAN Basics: What VLANs Are and How to Configure Them

What Is a VLAN? Layer 2 Segmentation Explained

A VLAN (Virtual LAN) is a logical partition of a switch that creates a separate Layer 2 broadcast domain. Devices can sit on the same physical switch, even the same rack, and still behave as if they were on entirely different networks — because the switch controls which ports are allowed to exchange frames with each other.

That\'s the whole idea in one sentence: VLANs let you group ports by function — Staff, Guest, IoT, Servers — without touching a single cable. The switch enforces the boundary in software, not in the wiring closet.

VLANs are a Layer 2 concept. A router, firewall, or Layer 3 switch is what actually decides whether traffic is allowed to move between VLANs — the switch on its own only decides who\'s inside the same one. For the physical hardware a VLAN design usually sits on top of, see how modems, routers, switches, and access points actually differ.

VLAN vs. Subnet: What\'s the Difference?

This is the question that trips up most people learning VLANs, because in a well-designed network the two line up so closely they feel like the same thing. They aren\'t.

Best practice is a strict 1:1 mapping: one VLAN, one IP subnet. Putting two subnets in one VLAN, or splitting one subnet across two VLANs, works technically but breaks the mental model everyone on the team relies on when troubleshooting — and it defeats half the point of segmenting in the first place. For the fuller Layer 2 vs. Layer 3 picture this distinction sits inside, see the OSI model explained layer by layer.

Why VLANs Exist: Security, Performance, and Design Benefits

VLANs exist because most networks need logical separation without duplicating physical infrastructure. Two benefits do almost all the work:

Security and isolation

A Guest VLAN can be kept off the internal subnets entirely, and a Servers VLAN can be reachable only through explicit ACLs or firewall rules at the routing boundary. The mistake to avoid: VLAN separation is not, by itself, a security control. It\'s an organizational boundary. Anything that actually needs to be blocked still has to be blocked at Layer 3 — ACLs, firewall policy, or both.

Performance: smaller broadcast domains

Every device in a broadcast domain has to process every broadcast frame — ARP requests being the constant background noise. A flat 500-device network means 500 devices processing every ARP broadcast from every other device. Split that into five 100-device VLANs and each device only sees broadcasts from its own 100 peers. On a large or noisy LAN this is a real, measurable reduction in CPU interrupts on end hosts, not just a theoretical tidiness win.

How VLAN Tagging Works: 802.1Q Explained

A single VLAN is trivial on one switch — just assign ports to it. The interesting problem is carrying multiple VLANs\' worth of traffic over one physical link between two switches (or a switch and a router), without them getting mixed up. That\'s what 802.1Q tagging solves.

802.1Q inserts a 4-byte tag into the Ethernet frame, right after the source MAC address and before the EtherType field:

Because tagging adds 4 bytes, a maximum-size tagged frame is 1522 bytes rather than the untagged 1518. Virtually every switch made in the last two decades handles this transparently (sometimes called "baby giant" frame support), but it\'s worth knowing about if you ever stack a second tag on top — 802.1ad (Q-in-Q) tunnels one VLAN inside another for service-provider or MSP multi-tenant designs, and that adds a second 4-byte tag, which is where legacy hardware and strict MTU checks occasionally start dropping frames.

On a trunk link, frames are normally sent tagged so the receiving switch knows exactly which VLAN each frame belongs to. Frames that arrive untagged on a trunk are assumed to belong to the native VLAN — the one VLAN per trunk that doesn\'t get a tag. Native VLAN handling has to be explicit and identical on both ends of the link; a mismatch there is one of the most common causes of traffic silently landing in the wrong VLAN (and it\'s also the mechanism behind one of the two VLAN hopping attacks, covered below).

Access Ports vs. Trunk Ports (and the Native VLAN Pitfall)

The most common trunk misconfiguration isn\'t the mode — it\'s leaving trunk negotiation and the allowed-VLAN list at their defaults. Two things to set explicitly on every trunk:

• Allowed VLAN list — only permit the VLANs that actually need to cross that link. A trunk carrying "all VLANs" by default is both a troubleshooting headache and a larger attack surface than it needs to be.
• Native VLAN — set it deliberately, keep it identical on both ends, and don\'t use it for user traffic. Many teams point it at an unused, unrouted VLAN specifically so that any traffic that lands there because of tagging problems goes nowhere.

VLAN ID Ranges: Normal Range vs. Extended Range, and What\'s Reserved

The 802.1Q VLAN ID field is 12 bits, so the theoretical range is 0–4095. VLAN IDs 0 and 4095 are reserved by the standard and aren\'t usable, which leaves 1–4094. On Cisco switches that range is further split into two management tiers:

The practical takeaway for most networks: you\'ll rarely touch the extended range unless you\'re running a large multi-tenant or service-provider environment. But if a VLAN ID above 1005 refuses to create, check show vtp status first — on VTP v1/v2 the switch needs to be in transparent mode before it will accept it.

For the exact command-mode requirements and VTP version behavior, see Cisco\'s configuration guide for extended-range VLANs.

VLAN Hopping: How Attackers Bypass Segmentation (and How to Stop It)

This is the part most "VLAN basics" guides skip, and it\'s the part that actually matters once you\'ve put a Guest or IoT VLAN next to something sensitive. There are two distinct techniques, and they\'re mitigated differently.

Switch spoofing

If a port is left in a dynamic trunking mode (Cisco\'s dynamic auto or dynamic desirable), an attacker\'s host can send Dynamic Trunking Protocol (DTP) frames and negotiate that port into trunk mode. Once it\'s trunking, the attacker\'s machine can see traffic on every VLAN permitted on that trunk. The fix is a one-line default, not a workaround: never leave end-device-facing ports on a negotiated mode.

interface GigabitEthernet0/1\n switchport mode access\n switchport nonegotiate

Double tagging

This one only works under a specific condition: the attacker\'s access port VLAN has to be the same as the trunk\'s native VLAN. The attacker crafts a frame with two 802.1Q tags — an outer tag matching the native VLAN, and an inner tag matching the target VLAN. The first switch strips the outer tag (because native VLAN traffic is untagged) and forwards what\'s left based on the inner tag, landing the frame directly in the victim\'s VLAN without ever passing through a router.

Because the attack depends entirely on the attacker sharing a VLAN with the trunk\'s native VLAN, the fix is structural: never use VLAN 1 — or any VLAN with real user devices on it — as a trunk\'s native VLAN. A single dedicated, unrouted, unused native VLAN on every trunk closes this off completely, which is also the standard the U.S. DoD\'s own switch security baseline requires.

This exact native-VLAN requirement is codified in DISA\'s Cisco IOS Switch L2S Security Technical Implementation Guide, which flags any trunk whose native VLAN still matches the default (VLAN 1) as a finding.

Voice VLANs and Private VLANs: When One VLAN Isn\'t Enough

Voice VLAN

Most desk IP phones sit between the wall jack and the PC, passing the PC\'s traffic through on the access VLAN untagged while tagging their own voice traffic into a separate voice VLAN over the same cable — one drop, two logically separate traffic streams. This isn\'t just organizational; it gives you a clean QoS trust boundary to mark and prioritize voice traffic before it competes with a large file transfer on the same link.

interface GigabitEthernet0/5\n switchport mode access\n switchport access vlan 10\n switchport voice vlan 50

Private VLANs (PVLANs)

A private VLAN subdivides one VLAN (and one IP subnet) into port roles that control who can talk to whom, without the overhead of a VLAN and subnet per group:

PVLANs solve a specific problem VLANs alone can\'t: dozens or hundreds of mutually-distrusting devices sharing one subnet without burning a VLAN ID and IP range per device or group.

Inter-VLAN Routing: Router-on-a-Stick vs. Layer 3 Switching

VLANs are separate Layer 2 domains by design, so devices in different VLANs can\'t reach each other without something routing between them — the same Layer 3 boundary covered in how the TCP/IP model actually moves data between networks. Two common ways to provide that routing:

Choose based on actual inter-VLAN traffic volume and how much you want policy enforcement centralized on one firewall (router-on-a-stick, if that router is also your firewall) versus distributed across a Layer 3 core.

Configuring VLANs: A Tested Small-Office Example

Three VLANs, one subnet each, a trunk between two switches:

! Create the VLANs\nvlan 10\n name Staff\nvlan 20\n name Guest\nvlan 30\n name Servers\nvlan 999\n name NATIVE_UNUSED\n\n! Staff PC on an access port\ninterface GigabitEthernet0/1\n switchport mode access\n switchport access vlan 10\n switchport nonegotiate\n\n! Trunk to the second switch - explicit allowed list, dedicated native VLAN\ninterface GigabitEthernet0/24\n switchport trunk encapsulation dot1q\n switchport trunk allowed vlan 10,20,30\n switchport trunk native vlan 999\n switchport mode trunk\n switchport nonegotiate

Verify it actually did what you configured — don\'t assume:

! Confirm VLANs exist and ports are in the right ones\nshow vlan brief\n\n! Confirm the trunk is up, carrying the right VLANs, and native VLAN matches on both ends\nshow interfaces trunk\n\n! Confirm a single port\'s mode and VLAN assignment\nshow interfaces GigabitEthernet0/1 switchport

Troubleshooting VLAN Issues: Commands and Common Symptoms

For the broader systematic approach these checks fit into, see network troubleshooting basics, step by step.

VLAN Best Practices Checklist

• Never carry user traffic on the default VLAN (VLAN 1); reserve it, unused, for control traffic only.
• Use a dedicated, unused, unrouted native VLAN on every trunk — identical on both ends.
• Set every end-device port to static access mode with DTP negotiation off.
• Keep a strict 1 VLAN : 1 subnet mapping.
• Explicitly prune each trunk\'s allowed-VLAN list to only what\'s needed.
• Document VLAN IDs, subnets, DHCP scopes, and purpose somewhere the whole team can find — a VLAN with no documented owner is the first one that gets misconfigured six months from now.

Once VLANs, subnets, and routing policy are mapped out on paper, building and documenting the surrounding systems — internal dashboards, automation, the software that actually runs on top of the network — is full-stack engineering work. That\'s the kind of build Netalith\'s custom software team takes on end to end.