VLANs, trunking and spanning tree

Why this matters

The previous lesson defined VLANs. This one carries them between switches, which is where the configuration detail and most of the faults live.

Trunking, the native VLAN, voice VLANs, link aggregation and duplex mismatch are all high-frequency exam material, and the last of them is one of the best troubleshooting questions on the paper because its symptoms look nothing like its cause.

The lesson

802.1Q tagging

An access port carries one VLAN, so the switch knows which VLAN a frame belongs to by which port it arrived on. A trunk carries many VLANs over one link, so that no longer works — the frame itself has to say.

802.1Q inserts a 4-byte tag into the Ethernet header containing the VLAN ID (12 bits, giving 1–4094) and a 3-bit priority field used by QoS. The receiving switch reads the tag, places the frame in that VLAN, and strips the tag before delivering it to an access port. End devices never see tags.

Two consequences worth knowing:

The tag makes the frame 4 bytes larger — 1522 rather than 1518 — which is why older equipment sometimes reported "baby giant" errors on trunk links.

802.1Q is an open standard, which matters when connecting equipment from different vendors. ISL was Cisco's proprietary alternative and is obsolete.

The native VLAN

On an 802.1Q trunk, one VLAN is carried untagged. That is the native VLAN, and it exists for backward compatibility with devices that do not understand tags.

By default it is VLAN 1, and two things follow that the exam tests.

Both ends of a trunk must agree on the native VLAN. If one end says VLAN 1 and the other says VLAN 99, untagged frames arriving on that link are placed in the wrong VLAN — traffic leaks between VLANs that are supposed to be separate. Most switches detect this and log a native VLAN mismatch, which is a gift when troubleshooting.

It is a security concern. VLAN hopping by double tagging exploits the native VLAN: an attacker sends a frame with two tags, the first switch strips the outer one because it matches the native VLAN, and the frame arrives in a VLAN the attacker should not reach. The standard mitigations are to change the native VLAN to an unused one, never use VLAN 1 for anything, and where supported require tagging on the native VLAN too.

Voice VLAN

IP phones present a specific problem: the phone and the PC plugged into the back of it share one cable and one switch port, but their traffic should be treated completely differently. Voice needs priority and its own subnet; the PC does not.

A voice VLAN solves it. The port is configured with an access VLAN for the PC and a separate voice VLAN for the phone. The phone tags its traffic with the voice VLAN; the PC's untagged traffic falls into the access VLAN. One cable, two VLANs, no trunk configuration needed on the user port.

The benefits are the examinable ones: voice traffic is separated for security and addressing, and it can be prioritised by QoS as a class, so a large download on the PC does not degrade the call sharing its cable.

The phone typically learns its voice VLAN automatically via LLDP-MED or CDP, which is why a phone that comes up in the wrong VLAN usually means those discovery protocols are disabled on the port.

Link aggregation

Link aggregation combines several physical links into one logical link. The standard is 802.3ad, negotiated by LACP (Link Aggregation Control Protocol). Vendors call the result a port channel, EtherChannel, bond or LAG.

Two benefits:

More bandwidth. Four 1 Gb links behave as one 4 Gb link in aggregate.

Redundancy. If one member fails the bundle stays up with reduced capacity, and the failover is immediate — no spanning-tree reconvergence, because spanning tree sees one logical link and never blocked the members.

That second point is the subtle one. Without aggregation, a second link between two switches is a loop, and STP blocks it — you get redundancy but no extra bandwidth. Aggregation gives you both.

The honest limitation: a single flow does not exceed the speed of one member link. Traffic is distributed per conversation using a hash of source and destination addresses, so one large file copy between two hosts uses one link. Aggregation adds aggregate capacity across many conversations, not speed for one. A question describing "we bonded four links and one transfer is still 1 Gb" is testing exactly this, and the behaviour is correct.

Both ends must be configured, with matching speed, duplex and VLAN settings on every member.

Speed and duplex

Speed is the link rate — 10, 100, 1000 Mbps and up. Duplex is whether the link can send and receive simultaneously. Full duplex can; half duplex cannot, and must wait for the medium to be free.

Modern equipment auto-negotiates both, and auto-negotiation on both ends is almost always the correct configuration.

The duplex mismatch. This is the classic fault and one of the best exam questions in domain 5, because the symptoms point away from the cause.

It happens when one end is set manually and the other is left on auto. The auto end cannot negotiate with a fixed partner, so it falls back to half duplex — while the manually configured end runs full duplex. The link comes up. The link light is on. Everything looks fine.

But one end transmits whenever it likes, and the other end, in half duplex, sees incoming traffic while it is transmitting and calls that a collision. The result is:

• The link works, so nothing appears broken.
• Throughput is terrible — often a few percent of the rated speed.
• It gets worse under load, because more traffic means more collisions.
• The interface counters show late collisions on the half-duplex end and FCS or CRC errors on the other.

Late collisions are the giveaway. A normal collision happens early in a frame; a late collision means the other end was already transmitting, which on a switched full-duplex link should be impossible.

The fix is to set both ends the same — either both auto, or both hardcoded identically. The rule to remember: never hardcode one end only. That single sentence prevents the entire fault.

Related counter reading, useful across domain 5: runts are frames below the 64-byte minimum, giants exceed the maximum, FCS errors indicate corruption in transit (often a cable or interference), and input errors rising steadily on a healthy-looking link is the sign of a physical problem the link light will never show you.