Virtual LANs (VLANs)

A broadcast domain is the set of hosts that receive a frame sent to the Ethernet broadcast address `FF:FF:FF:FF:FF:FF`. In an untagged switched LAN, the broadcast domain equals the entire physical Link-Layer Switches and Bridging fabric: every port on every interconnected switch. A Virtual LAN (VLAN) redefines the broadcast domain to be a configured subset of ports, independent of physical topology, identified by a numeric VLAN ID (VID), an integer from 1 to 4094 (0 and 4095 are reserved). Two hosts in the same VLAN behave, from a layer-2 perspective, as if they sat on their own isolated switch; two hosts in different VLANs cannot exchange an Ethernet frame at all without passing through a layer-3 device. Ports on a VLAN-capable switch are one of two types. An access port belongs to exactly one VLAN and is unaware that VLANs exist — it sends and receives ordinary untagged Ethernet frames, and the switch internally associates every frame on that port with the port's configured VLAN. A trunk port carries frames belonging to multiple VLANs over a single physical link, which requires each frame to be marked with its VLAN ID so the receiving switch knows which broadcast domain it belongs to. That marking is done by the IEEE 802.1Q standard, which inserts a 4-byte tag between the source MAC address and the EtherType/length field of the Ethernet header. The tag carries a 12-bit VLAN ID field plus a 3-bit priority field (used for Quality of Service-style traffic prioritization, formally 802.1p) and a 1-bit flag historically used for token ring compatibility. Within a switch, every forwarding decision — flooding an unknown-destination frame, looking up a known destination in the MAC table, and learning a source MAC from an incoming frame — is scoped per VLAN. Concretely, the switch does not maintain one MAC address table; it maintains one table per VLAN (or equivalently, one table keyed by (VLAN, MAC) pairs). This is what makes VLANs a true isolation mechanism rather than a labeling convenience: a switch will never forward a frame from a port in VLAN 10 out to a port in VLAN 20, and a broadcast in VLAN 10 is flooded only to VLAN 10 ports.

Step 1 — Port configuration. Each switch port is administratively set to access mode with a single VLAN, or to trunk mode carrying a set of allowed VLANs (typically all VLANs, or a restricted list). Trunk mode also designates one VLAN as the native VLAN, whose frames are sent untagged on that trunk for backward compatibility with non-802.1Q equipment (a frequent source of misconfiguration, discussed below).

Step 2 — Tag insertion (ingress at access port, or already tagged from a trunk). When an untagged frame arrives on an access port, the switch does not modify the frame on the wire, but internally binds it to the port's VLAN ID for the duration of its processing. When a frame must leave the switch on a trunk port, the switch inserts an 802.1Q tag carrying that VLAN ID (unless the VLAN is the trunk's native VLAN, in which case the frame is sent untagged).

Step 3 — Per-VLAN learning. On receiving a frame, the switch reads (VLAN ID, source MAC) and records the mapping to the ingress port in the MAC table for that VLAN specifically. This is standard transparent bridge learning, but scoped by VLAN.

Step 4 — Per-VLAN forwarding. The switch looks up (VLAN ID, destination MAC) in that VLAN's table:

• If found, forward out the recorded port only (unicast, no flooding).
• If not found (unknown unicast), flood out every port that belongs to that VLAN, except the ingress port.
• If the destination is broadcast or an unknown multicast, flood out every port belonging to that VLAN, except the ingress port.

Step 5 — Tag removal (egress at access port). When a tagged (or internally VLAN-bound) frame is sent out an access port, the switch strips the 802.1Q tag (or, if it was never tagged, simply sends it as-is) so the receiving end host sees ordinary untagged Ethernet.

Step 6 — Inter-VLAN communication. Because a switch never bridges across VLANs, two hosts in different VLANs need a router or layer-3 switch. Either a single router interface is subdivided into per-VLAN sub-interfaces over one trunk link (router-on-a-stick), or a layer-3 switch instantiates a switch virtual interface (SVI) per VLAN, each with its own IP subnet, and routes between them internally. ``` // Simplified per-frame switch forwarding logic on a VLAN-aware switch // Each switch maintains: mac_table[vlan_id] -> { mac_address -> port } // port_config[port] -> {mode: ACCESS/TRUNK, // vlan (if ACCESS), // allowed_vlans (if TRUNK), // native_vlan (if TRUNK)} function RECEIVE_FRAME(frame, in_port): cfg = port_config[in_port] if cfg.mode == ACCESS: vlan = cfg.vlan // implicit VLAN, frame arrives untagged payload = frame // no tag to strip else: // TRUNK if frame.has_8021q_tag: vlan = frame.tag.vlan_id payload = strip_tag(frame) else: vlan = cfg.native_vlan // untagged frame on trunk = native VLAN payload = frame // --- learning --- mac_table[vlan][payload.src_mac] = in_port // --- forwarding --- dst = payload.dst_mac if is_broadcast(dst) or is_unknown_multicast(dst): FLOOD(payload, vlan, exclude = in_port) else if mac_table[vlan].has(dst): out_port = mac_table[vlan][dst] SEND(payload, out_port, vlan) else: FLOOD(payload, vlan, exclude = in_port) // unknown unicast function FLOOD(payload, vlan, exclude): for port in all_ports: if port == exclude: continue cfg = port_config[port] if cfg.mode == ACCESS and cfg.vlan == vlan: transmit_untagged(payload, port) else if cfg.mode == TRUNK and vlan in cfg.allowed_vlans: if vlan == cfg.native_vlan: transmit_untagged(payload, port) else: transmit_tagged(payload, vlan, port) function SEND(payload, out_port, vlan): cfg = port_config[out_port] if cfg.mode == ACCESS: transmit_untagged(payload, out_port) else: // TRUNK if vlan == cfg.native_vlan: transmit_untagged(payload, out_port) else: transmit_tagged(payload, vlan, out_port) ``` The tag itself sits directly after the source MAC address: ``` Ethernet frame WITHOUT 802.1Q tag: [ Dest MAC(6) | Src MAC(6) | EtherType/Len(2) | Payload | FCS(4) ] Ethernet frame WITH 802.1Q tag: [ Dest MAC(6) | Src MAC(6) | TPID=0x8100(2) | TCI(2) | EtherType/Len(2) | Payload | FCS(4) ] \_______ 802.1Q tag (4 bytes) _______/ TCI = 3-bit priority (802.1p) | 1-bit CFI/DEI | 12-bit VLAN ID ```

Space. Instead of one MAC table of size at most $N$ (total learned hosts), a VLAN-aware switch maintains $V$ tables, one per active VLAN, with combined size still $O(N)$ since each learned (VLAN, MAC) pair is stored exactly once regardless of how many VLANs exist. Splitting by VLAN costs a small constant factor of bookkeeping overhead (a VLAN index alongside each MAC entry) but does not change the asymptotic space, which remains $O(N)$ where $N$ is the number of distinct active hosts across all VLANs. The tag itself costs 4 bytes per frame on trunk links, negligible relative to typical frame sizes and irrelevant on access links where no tag is transmitted at all.

Time. Per-frame processing is $O(1)$ amortized with a hash-table implementation of `mac_table[vlan][mac]`, exactly as in ordinary bridge learning, because the VLAN ID is just an extra key component (or equivalently, the tables are physically or logically partitioned so lookup remains a single hash computation over the concatenated key). Flooding costs $O(P_v)$ where $P_v$ is the number of ports currently assigned to VLAN $v$, strictly less than or equal to the $O(P)$ flooding cost of an unpartitioned switch with $P$ total ports — VLANs never make flooding more expensive and typically make it cheaper by shrinking the flood domain.

Correctness of isolation. The key invariant maintained by the algorithm above is: > Invariant: for any two ports $p_1, p_2$ with disjoint VLAN membership, no frame received on $p_1$ is ever transmitted on $p_2$. This holds because both branches of `FORWARD` — the direct unicast branch (`SEND`) and the flood branch (`FLOOD`) — only ever select an output port whose VLAN set intersects the frame's associated VLAN ID; the `RECEIVE_FRAME` procedure assigns exactly one VLAN ID to every frame at ingress (from port configuration if access, or from the tag/native VLAN if trunk), and every learned entry in `mac_table[vlan]` is written only under that same VLAN key. By induction on the sequence of frames processed, a port never appears as a value under a VLAN key different from its own configured (or currently tagged) VLAN, so lookups and floods restricted to that key can never select a port outside the VLAN. This is precisely what distinguishes VLANs from mechanisms like port-based mirroring or ACLs bolted onto a flat broadcast domain: isolation is structural, enforced by the data structure itself, not by a filter that could be bypassed.

Correctness of trunking (tag transparency). A trunk must deliver frames to the correct VLAN on the far switch even though physically only one wire exists. This works because the VLAN ID is encoded in the frame itself (the tag), so the invariant above composes across multiple switches: each switch independently applies the same per-VLAN forwarding rule, using the tag as the source of truth for VLAN membership instead of port configuration. The native VLAN's untagged special case is the one deliberate violation of "every frame explicitly carries its VLAN" and is exactly the source of the double-tagging vulnerability discussed below.

Tradeoffs. VLANs add configuration surface: every switch in the path must agree on the same VLAN ID for the same logical network (a global naming problem, historically eased by VLAN Trunking Protocol variants, themselves a source of outages when misused). VLANs also do not scale past 4094 IDs, a real limit motivating overlay techniques such as VXLAN in large multi-tenant data centers. Finally, VLANs give isolation, not security by encryption or authentication — a device with a trunk-capable NIC or a misconfigured port can potentially defeat isolation (see double-tagging below), so VLANs complement but do not replace access control and encryption.

Consider the topology in the figure: Switch A and Switch B are connected by one 802.1Q trunk carrying VLAN 10 and VLAN 20, with a native VLAN configured as VLAN 99 (a convention many real deployments use — an unused "parking" VLAN as native, precisely to avoid the double-tagging pitfall). Host H1 (VLAN 10, on Switch A) sends an ARP request that eventually gets an answer from Host H3 (VLAN 10, on Switch B).

Notice VLAN 20's hosts H2 and H4 never see any of these eight frames — the broadcast in step 1 was flooded only within VLAN 10's port set, both on Switch A and, after crossing the tagged trunk, on Switch B. If H2 (VLAN 20) later sends its own broadcast, it independently floods only within VLAN 20's ports, using the same trunk wire but tagged VID=20, and Switch A's and Switch B's VLAN 20 tables are populated completely independently of the VLAN 10 tables shown above — exactly the isolation invariant proved earlier, now traced concretely. If H1 (VLAN 10) instead wants to reach a host in VLAN 20, no amount of switch flooding helps: the frame must be handed to a router or an SVI configured with an IP address in VLAN 10's subnet and another in VLAN 20's subnet, which performs an ordinary IP routing decision and re-encapsulates the packet in a new Ethernet frame tagged (or untagged) for the destination VLAN — this is the router-on-a-stick / SVI mechanism from Step 6 of "How it works," and it is the only path across the VLAN boundary.

The VLAN concept grew directly out of the transparent bridging and spanning-tree work that made scalable Ethernet switching practical, and was standardized as the IEEE moved to make VLAN tagging vendor-neutral rather than locked to proprietary inter-switch link protocols.

Enterprise campus networks use VLANs to separate departments, voice traffic (VoIP phones typically get their own VLAN via LLDP-MED/CDP auto-configuration), and guest Wi-Fi from the corporate network, all on shared switch hardware and shared trunk links between wiring closets. Data centers use VLANs to give each tenant or application tier (web, application, database) an isolated broadcast domain on shared top-of-rack switches, often combined with layer-3 SVIs on core switches for inter-tier routing. Service providers use VLAN tagging (sometimes stacked, "QinQ," two tags deep) to multiplex customer traffic over shared metro Ethernet links. Virtualization platforms expose VLAN tagging to virtual switches inside hypervisors, letting virtual machines on the same physical host belong to entirely different, isolated networks — the direct ancestor of software-defined overlay networking in cloud platforms. Any network engineer configuring a managed switch, any cloud architect designing tenant isolation, and any security team segmenting a network to contain breaches relies on the mechanisms described here.

Ask the tutor: How does the Spanning Tree Protocol interact with VLANs when a fabric runs one spanning tree instance per VLAN instead of one shared tree?