Two switches connected by a trunk link in a hospital's east wing begin dropping intermittent untagged traffic, and the technician discovers one switch has its trunk's native VLAN set to VLAN 1 while the other has it set to VLAN 99. What kind of fault is this?
Select an answer to reveal the explanation.
Short Explanation
Untagged frames only make sense if both ends of the trunk agree on which VLAN they belong to, and here they don't agree at all. One switch assumes untagged traffic is VLAN 1, the other assumes VLAN 99, so those frames land in the wrong VLAN on whichever end disagrees. That mismatch is exactly what causes the intermittent, confusing drops.
Full Explanation
The native VLAN on a trunk is the one VLAN whose traffic is sent untagged across that link, and both ends must agree on which VLAN that is, because a receiving switch simply assumes any untagged frame belongs to whatever it has configured as native. When the two ends disagree, untagged frames get placed into the wrong VLAN on one side, which can cause traffic to leak between VLANs or simply fail to reach its intended destination, producing the intermittent, hard-to-explain symptoms described. This is a textbook native VLAN mismatch rather than an allowed-VLAN exclusion, because an excluded VLAN would be dropped consistently and entirely, not intermittently misdelivered; the symptom here is about traffic landing in the wrong place, which is the native VLAN mechanism specifically. A spanning-tree priority mismatch influences which switch becomes the root bridge in a topology, but it does not cause untagged traffic to be misclassified into the wrong VLAN. A speed mismatch on a LAG member interface would typically prevent that member from bundling successfully or cause it to be excluded from the aggregate, which is a different symptom from VLAN misclassification. A concrete check is aligning the native VLAN configuration to the same VLAN number on both ends of the trunk.