Cisco Switch Not Passing Traffic? Here's How to Diagnose It

By Stackvora Team · 2026-09-01 · 8 min read

The port is up, the cable is fine, but traffic won't pass. Work this ladder top to bottom — each step eliminates a layer.

Step 1: Physical and link layer

show interfaces status
show interfaces Gi1/0/1

Look for: err-disabled (port-security or BPDU guard shut it down — show errdisable recovery tells you why), speed/duplex mismatch, and CRC/input errors climbing (bad cable or SFP).

Step 2: Is the switch learning the MAC?

show mac address-table interface Gi1/0/1

• No MAC learned — the device isn't sending, or it's in the wrong VLAN. Check the access VLAN assignment.
• MAC learned on the wrong port — the device moved; you may have a loop or a rogue switch. show cdp neighbors reveals what's really plugged in.
• MAC flapping between ports — classic Layer 2 loop. Check STP now.

Step 3: Spanning Tree

show spanning-tree vlan 20
show spanning-tree inconsistentports

A port in BLK that should forward, or inconsistent state (usually a native-VLAN mismatch on a trunk), stops all traffic silently. Match native VLANs on both ends of every trunk.

Step 4: VLAN and trunk verification

show interfaces trunk
show vlan brief

The two killers: the VLAN exists on the switch but isn't allowed on the trunk (switchport trunk allowed vlan is a whitelist), and the VLAN doesn't exist at all on one switch in the path (VTP transparent sites, manual adds forgotten).

Step 5: Security features eating traffic

• Port security: show port-security interface Gi1/0/1 — violation counters > 0 means it already acted.
• DHCP snooping: an uplink without ip dhcp snooping trust kills all DHCP downstream.
• Dynamic ARP inspection: fails silently when DHCP snooping table is empty.
• Storm control: check for suppression counters on broadcast-heavy segments.

The fast summary

Paste your show output into Stackvora AI for a guided diagnosis, or browse the Cisco knowledge base.

Layer-by-layer quick reference

Work bottom-up and confirm each layer before climbing. Most "switch not passing traffic" tickets resolve at layer 2: a missing allowed VLAN on the trunk or a port stuck err-disabled.

The err-disabled gotcha

A port in err-disabled state looks physically fine but passes nothing. Run show interfaces status err-disabled to see the reason — port-security violations, BPDU guard, and link-flap detection are the usual suspects. Fix the cause first, then recover with shutdown followed by no shutdown on the interface, or tune errdisable recovery interval 300 so benign flaps self-heal.

When to escalate

Collect show tech-support output before reloading anything — a reboot erases the counters and logs TAC needs. Escalate when you see incrementing hardware queue drops on a healthy link, repeated stack-member reloads, or MAC addresses flapping between ports with no physical loop: those point to hardware or firmware defects, not configuration.

Still stuck? Paste show interfaces and show spanning-tree output into Stackvora AI for a line-by-line diagnosis, or browse switch guides in the knowledge base.

Key takeaways

• Troubleshoot bottom-up: physical, VLAN/trunk, MAC learning, then IP — most tickets close at layer 2.
• Err-disabled ports look healthy on the surface; check show interfaces status err-disabled early.
• Trunk allowed-VLAN mismatches are the single most common cause of "one VLAN works, another doesn't".
• Capture show tech-support before reloading — reboots destroy the evidence.

Switches rarely fail silently without leaving counters behind. The interface error counters, STP states, and MAC table tell a complete story if you read them in order. Keep the layer-by-layer table from this guide in your runbook, and use Stackvora AI to interpret unfamiliar counter output — the knowledge base also documents platform quirks for Catalyst, Nexus, and small-business lines.