On a trunk link between the radiology-ward access switch and the aggregation switch, frames arrive on the link without an 802.1Q tag. Which VLAN does the receiving AOS-CX switch place these untagged frames into?
Select an answer to reveal the explanation.
Short Explanation
A trunk needs somewhere to put traffic that never got a tag in the first place, and that's the job of the native VLAN. Whatever VLAN you've designated as native on that trunk is where untagged frames land, no exceptions.
Full Explanation
A trunk port is configured with a native VLAN specifically to handle untagged frames — any frame that arrives without an 802.1Q tag is treated as belonging to that native VLAN, which is why matching the native VLAN on both ends of a trunk link matters so much. Saying trunk ports only accept tagged frames misses that native-VLAN handling is a defined, standard part of trunking; untagged frames are expected traffic, not an error condition. Flooding untagged frames to every allowed VLAN would break VLAN isolation entirely and is not how 802.1Q trunking works — a frame belongs to exactly one VLAN once it's classified. Assuming VLAN 1 regardless of configuration ignores that the native VLAN is administratively configurable and, on a well-segmented hospital network, is often deliberately changed away from VLAN 1 for security reasons. Caveat: a native VLAN mismatch between the two ends of a trunk is a classic hidden misconfiguration — traffic still passes, but frames intended for one VLAN silently leak into another, which is hard to spot without checking both switches. Operational check: compare the native VLAN setting on both sides of every inter-switch trunk during deployment validation, not just the allowed-VLAN lists.