When VLANs are not reaching across switches due to trunk issues, which steps should you start with?

When VLANs are not reaching across switches due to trunk issues, which steps should you start with?

• A. Replace cables and reboot the switches.
• B. Only check the access ports.
• C. Disable VLANs on all switches.
• D. Verify trunk mode on both ends, confirm allowed VLANs, ensure native VLAN IDs match, check 802.1Q tagging, and review DTP status.

Answer: (D)

When VLANs aren’t reaching across switches, the issue almost always sits at the trunk boundary between the switches. Trunk links must be configured consistently on both ends to carry multiple VLANs, so you start by validating the whole trunk setup rather than just individual ports. First, verify that both ends of the link are in trunk mode. If one side is an access port or the other end isn’t configured as a trunk, VLAN traffic won’t traverse beyond that link. The trunk mode on both sides allows tagged traffic for many VLANs to be carried across the link consistently. Next, check the list of allowed VLANs on the trunk. If the VLANs you need aren’t in the allowed set, traffic for those VLANs will be dropped as it moves across the link. Ensuring the correct VLANs are permitted on the trunk lets those networks span the switches. Then, ensure the native VLAN IDs match. Untagged traffic is associated with the native VLAN, so a mismatch means untagged frames could be misinterpreted or dropped, breaking communication for that VLAN across the trunk. Also confirm that 802.1Q tagging is being used properly and consistently. The whole purpose of a trunk is to tag frames with their VLAN IDs as they cross the link; any inconsistency in tagging can cause misrouted or dropped frames. Finally, review DTP status if your network uses auto-negotiation for trunks. If DTP is enabled on one side and disabled on the other, or if the negotiation fails, the trunk may not form correctly. In many environments, configuring trunks statically (without relying on DTP) reduces this risk and provides predictable behavior. Working through these areas quickly identifies misconfigurations at the trunk boundary that prevent VLAN traffic from moving between switches.

When VLANs aren’t reaching across switches, the issue almost always sits at the trunk boundary between the switches. Trunk links must be configured consistently on both ends to carry multiple VLANs, so you start by validating the whole trunk setup rather than just individual ports.

First, verify that both ends of the link are in trunk mode. If one side is an access port or the other end isn’t configured as a trunk, VLAN traffic won’t traverse beyond that link. The trunk mode on both sides allows tagged traffic for many VLANs to be carried across the link consistently.

Next, check the list of allowed VLANs on the trunk. If the VLANs you need aren’t in the allowed set, traffic for those VLANs will be dropped as it moves across the link. Ensuring the correct VLANs are permitted on the trunk lets those networks span the switches.

Then, ensure the native VLAN IDs match. Untagged traffic is associated with the native VLAN, so a mismatch means untagged frames could be misinterpreted or dropped, breaking communication for that VLAN across the trunk.

Also confirm that 802.1Q tagging is being used properly and consistently. The whole purpose of a trunk is to tag frames with their VLAN IDs as they cross the link; any inconsistency in tagging can cause misrouted or dropped frames.

Finally, review DTP status if your network uses auto-negotiation for trunks. If DTP is enabled on one side and disabled on the other, or if the negotiation fails, the trunk may not form correctly. In many environments, configuring trunks statically (without relying on DTP) reduces this risk and provides predictable behavior.

Working through these areas quickly identifies misconfigurations at the trunk boundary that prevent VLAN traffic from moving between switches.