5 Layer 2 Switching Troubleshooting Scenarios

A practical guide to tracing Layer 2 traffic, diagnosing VLAN and spanning-tree problems, and verifying repairs on switches.

Trace the traffic path

Trace the frame’s path from the endpoint’s , across each , to the destination . Check configuration and operational state at each point before changing settings. The examples use Cisco IOS-style commands; exact output and syntax can vary by switch model and software version.

A useful sequence is:

Check whether the endpoint port is up and assigned as an in the intended .
Check that the exists and is active on each switch that needs to forward its traffic.
Check every along the path for operational status, permitted VLANs, and matching native VLANs.
Check spanning tree for the affected : identify the and port roles, and determine whether the path is forwarding or blocking.
Check MAC address learning and test connectivity again after making a correction.

Useful checks include show brief, show interfaces , show interfaces switchport, show spanning-tree <id>, and show mac address-table dynamic.

A department cannot reach its gateway

In this scenario, PC-A is connected to SW1 in 20. Its gateway is reached through the from SW1 to SW2, while other VLANs work.

The is assigned to 20, but the ’s allowed list omits 20:

A can be up and operational while excluding a particular . Add 20 without removing VLANs already required on the link:

Verify the on both switches and confirm that 20 is active and permitted end to end. Entering a new allowed list without add can unintentionally remove other VLANs.

A works locally but not across switches

In this scenario, two PCs in 30 communicate when connected to SW1, but a 30 PC on SW2 cannot reach them. The is active on SW1 but missing or inactive on SW2:

Trunking alone does not create a usable on every switch. Create or activate 30 on SW2, then check that it is allowed on the inter-switch :

Recheck show brief and show interfaces . If the is still unavailable, inspect the allowed list at both ends of the and check any additional switches in the path.

A reports a native- inconsistency

A between SW1 and SW2 carries multiple VLANs. After a change, some traffic stops and spanning tree reports a native- or PVID inconsistency. The status is up, but the native VLANs differ:

On an 802.1Q , native- traffic is sent untagged. A mismatch can place traffic into different VLANs at the two ends and trigger an inconsistency. Correct the mismatch rather than working around the protection.

Configure the intended consistently at both ends, and ensure it exists and is allowed where required:

Then confirm the operational details and status. Do not disable to clear the symptom: the inconsistency warns that the link’s assumptions disagree.

A redundant link is blocking

When SW1 and SW2 have two Layer 2 paths, a user may expect both links to forward traffic. For 10, SW2 reports one root port forwarding and one alternate port blocking:

Altn BLK indicates an alternate path held out of forwarding by to prevent a Layer 2 loop. This can be normal with redundant links; a blocked port is not automatically a fault. selects a loop-free topology for each or spanning-tree instance.

If the wrong switch is acting as root, first verify the intended design with show spanning-tree 10 on all relevant switches. Then set a deliberate root priority on the intended root switch, using a lower priority value than competing switches. For example:

Recheck the root ID and port roles. Do not force a blocked port into forwarding without understanding the topology: parallel forwarding paths can create loops, broadcast storms, and MAC-table instability.

The switch does not learn the endpoint MAC address

A PC may fail to communicate even with devices in its local although the link light is on. Check the access-port state and assignment, then look for the endpoint’s MAC address:

If the port is in the wrong , correct it to the intended access . If the is correct but no MAC is learned, check the physical link, endpoint NIC, port security or other interface restrictions, and whether the endpoint is transmitting. If the MAC is learned in the expected , continue tracing the MAC and across trunks toward the destination.

Verify each repair

After each change, verify the specific failure point rather than relying on one successful ping:

show brief: confirm that the exists and is active.
show interfaces : confirm that the link is trunking, the needed is allowed, and native VLANs agree.
show spanning-tree <id>: confirm the expected root and port roles, and that the path is forwarding where needed.
show mac address-table dynamic: confirm that endpoint MAC addresses are learned in the expected .
Retest connectivity, then save the configuration if the change is intended to persist.

Make one controlled change at a time. This helps identify the actual cause and reduces the risk of introducing a loop or disrupting unrelated VLANs. In general, trace the end to end: check access-port assignment, existence, state and allowed list, native- agreement, and the forwarding path. Correct the underlying mismatch, then verify with show commands and an end-to-end test.