A network engineer needs to add a new switch to an existing network. The switch must be configured to support VLANs and trunking. The engineer connects the switch to the existing network via a trunk port. After configuration, the VLANs on the new switch are not receiving traffic from the core network. The core switch shows the trunk is up but no VLANs are allowed. What is the most likely cause?
The allowed VLAN list explicitly controls which VLANs are permitted on the trunk. If the desired VLANs are not in the allowed list, their traffic will be dropped.
Why this answer
The core switch shows the trunk is up but no VLANs are allowed, which directly indicates that the allowed VLAN list on the trunk port does not include the desired VLANs. By default, a trunk port permits all VLANs, but if an administrator explicitly restricts the allowed VLAN list (e.g., with the 'switchport trunk allowed vlan' command), only those VLANs are forwarded. Since the new switch is not receiving traffic, the core switch's trunk likely has an empty or incorrect allowed VLAN list, preventing the desired VLAN traffic from crossing the trunk.
How to eliminate wrong answers
Option A is wrong because a native VLAN mismatch would cause control plane issues (e.g., CDP/STP problems) or traffic being placed in the wrong VLAN, but it would not cause the trunk to show 'no VLANs are allowed' — the allowed VLAN list would still be present. Option B is wrong because if the trunk encapsulation were not set to 802.1Q, the trunk would likely not come up at all (e.g., Cisco switches default to 'negotiate' or require 'switchport trunk encapsulation dot1q'), and the core switch would not show the trunk as 'up' with a VLAN list issue; the problem statement explicitly says the trunk is up, so encapsulation is correctly configured.