Ethernet, Switching and VLANs

Brief

At Halcyon Clinics, a replacement reception switch goes live at 08:00. Ten minutes later, appointment terminals lose their gateway intermittently. A technician calls it a collision storm; the security lead says the clinical VLAN is a firewall. Packet captures show changing gateway MAC mappings, while a spare cable connects two wall outlets back to the same switching fabric.

You must separate three questions: where frames travel, who can impersonate a local neighbour, and which device actually permits a routed connection. This room follows frames through a switch, resolves an IPv4 neighbour with ARP, and designs VLAN and spanning-tree safeguards. Configuration exports, time-stamped tables and permitted/denied traffic tests become evidence rather than reassurance from a network diagram.

A VLAN limits Layer 2 reachability; it does not authenticate a host or decide which routed application connections are allowed.

Learn the source, forward by the destination

Ethernet uses 48-bit MAC addresses, commonly written as six hexadecimal octets, such as 02:00:00:00:00:0a. They identify link-layer interfaces, not trustworthy people: software can change them, and locally administered addresses need not identify a manufacturer. An ordinary Ethernet switch learns the source MAC and ingress port of a valid frame within its VLAN. Its forwarding table is effectively keyed by VLAN plus MAC, with dynamic entries removed after an aging interval.

Suppose VLAN 20 has terminal A on p1, terminal B on p2 and an uplink on p3. A sends to B while the table is empty: the switch learns A on p1, then floods the unknown unicast to p2 and p3, not back to p1. B replies; the switch learns B on p2 and sends the reply only to p1. Later known unicasts use the learned destination port; a destination learned on the ingress port is filtered. Flooding is not broadcasting: an unknown unicast retains B's destination MAC. Broadcast frames use ff:ff:ff:ff:ff:ff and are flooded within the VLAN.

For asset and segmentation controls, retain a time-stamped MAC table with VLAN and port configuration, but do not treat it as proof of identity or a full inventory: silent devices and aged entries disappear. An auditor can ask whether an unfamiliar MAC on a clinical port is an authorised endpoint; answering requires inventory and admission evidence beyond the learned table.

Broadcast domains, collision domains and ARP deception

A VLAN is a Layer 2 broadcast domain, even when it spans several switches over trunks. A router normally does not forward Ethernet broadcasts between VLANs. A legacy shared half-duplex segment forms one collision domain; switches separate those segments by port. On modern point-to-point full-duplex Ethernet, collisions do not occur and collision detection is not used. A broadcast storm can therefore saturate perfectly collision-free links. Count broadcast domains by active VLANs, not by the number of switches or cables.

ARP resolves an IPv4 next-hop address into a MAC on the local link. A host in 10.20.0.0/24 seeking 10.20.0.1 sends a broadcast request, then normally receives a unicast reply and caches the mapping. To reach a different subnet it resolves its gateway, not the remote server's MAC. ARP has no built-in authentication: a forged reply claiming that the gateway address belongs to an attacker's MAC can redirect or discard traffic. This is ARP spoofing, not a DNS change, and it can happen between hosts inside one VLAN.

Controls include ARP inspection against trusted address bindings, carefully limited trusted uplinks, and explicit bindings for static hosts where required. Address-assignment snooping can supply dynamic bindings, but a static printer may need separate treatment. Preserve neighbour-cache changes, binding tables and inspection drop logs with timestamps. The audit question is whether a forged gateway claim is actually rejected, not merely whether an inspection feature is enabled somewhere.

Carry VLANs without confusing separation with permission

An access port normally assigns untagged endpoint frames to one configured VLAN. An IEEE 802.1Q trunk carries several VLANs using a 4-byte tag containing a 12-bit VLAN identifier; ordinary VLAN IDs range from 1 to 4094. VLAN 20 and VLAN 30 can share one cable without sharing broadcast traffic. Explicitly allow only required VLANs on each trunk and configure endpoint ports as access ports rather than allowing automatic trunk negotiation.

In common trunk configurations, the native VLAN carries untagged frames. If one end assigns those frames to VLAN 20 and the other to VLAN 30, identical untagged traffic crosses an unintended boundary. Native tagging behaviour depends on configuration; verify both ends. Use a consistent unused native VLAN with no endpoint ports, tag native traffic where supported, and prune unnecessary VLANs. These measures reduce misclassification and some VLAN-hopping opportunities; they do not turn tags into authentication.

Traffic between VLANs requires Layer 3 forwarding, but a router with routes alone may permit all such traffic. Enforce least privilege using firewall policy or routed access-control rules, and address same-VLAN exposure separately. For example, permit reception VLAN 20 to the appointment service on its approved port while denying the clinical administration interface. Preserve both trunk exports and positive/negative connection tests; an auditor should ask which enforcement rule blocks the denied path, not just which VLAN names appear on the diagram.

Spanning tree prevents loops, not hostile conversations

Ethernet frames have no hop limit comparable to an IP packet's TTL. Two parallel forwarding paths can recirculate broadcasts, duplicate unknown unicasts and make source MAC entries flap between ports. Spanning Tree Protocol exchanges bridge protocol data units (BPDUs), elects the bridge with the lowest bridge identifier as root, and selects a loop-free forwarding topology using path cost and tie-breakers. Redundant links remain available but a redundant port is kept non-forwarding for the relevant tree; rapid variants use discarding, learning and forwarding states.

Do not disable spanning tree to 'speed up' redundant links. Designate the intended root, check root and port roles, and enable edge behaviour only on genuine endpoint ports. BPDU guard can disable an edge port receiving a BPDU, preventing an unexpected bridge from joining there; do not blindly apply that policy to legitimate switch uplinks. Tree convergence can briefly interrupt traffic, so test a link failure and record restoration time against the clinic's availability objective.

Availability control evidence includes root identifiers, topology-change events, interface counters and the failure-drill result. Repeated MAC movement plus rising broadcast counters supports a loop investigation, but MAC movement alone can also reflect legitimate relocation. An auditor asks whether a wiring error is contained and whether redundancy works under failure. Neither spanning tree nor a stable root prevents ARP spoofing or supplies application access control.

Answers are graded on the server: the answer key never reaches your browser.