Performance Troubleshooting¶
For when the network is up but slow, laggy, or dropping packets under load — distinct from the hard-down faults in Common Issues.
Start With Interface Counters¶
The fastest way to confirm whether the network itself is the bottleneck:
Cisco IOS — privileged EXEC:
show interfaces Gi0/1 | include error|drop|collision
Counters accumulate until cleared, so a scary number may be weeks-old history (e.g. a since-replaced cable) rather than a live fault. To confirm a problem is active, run clear counters Gi0/1 (privileged EXEC, confirm at the prompt), generate some traffic, then re-run the show command and see whether the numbers are still climbing.
| Symptom in counters | Points to |
|---|---|
| CRC errors climbing | Bad cable/connector — physical layer, see Common Issues |
| Late collisions | Duplex mismatch — see Interface Management |
| Output drops | Congestion — more traffic queued than the link can send |
| Input queue drops | The switch's own CPU/processing can't keep up with incoming traffic |
Congestion¶
If output drops correlate with a specific link (usually an uplink), that link doesn't have enough bandwidth for the current load. Options:
- QoS — prioritize latency-sensitive traffic (voice/video) so it isn't queued behind bulk transfers, see Quality of Service (QoS)
- EtherChannel — bundle multiple physical links for more aggregate bandwidth, see EtherChannel / Link Aggregation
- Identify the source — a single misbehaving device or an unexpected bulk transfer is often the actual cause, not a genuine capacity shortfall; SPAN/port mirroring a suspect port to see what's actually on it
System Resource Constraints¶
A switch under CPU or memory pressure can behave slowly even with a completely healthy network:
Cisco IOS — privileged EXEC:
show processes cpu sorted
show memory statistics
show processes cpu sorted shows what's consuming CPU — see Monitoring Commands.
High CPU is often caused by something generating excessive control-plane traffic (e.g. a spanning-tree topology flapping, or a broadcast storm — see Storm Control) rather than the data plane itself.
Wireless-Specific¶
For Ruckus AP performance issues specifically:
- Channel congestion/interference — especially in crowded RF environments with many other 2.4/5GHz networks nearby
- Client density — too many clients on one AP/SSID in a high-density area; a second AP exists partly to spread this load
- Band steering — confirm capable clients are actually being pushed to 5GHz rather than crowding 2.4GHz
Duplex Mismatch — The Classic Silent Killer¶
Worth calling out again from Interface Management: a duplex mismatch doesn't take a link down, it just makes it perform badly — often misdiagnosed as "flaky wifi" or "slow internet" when the actual fault is a wired mismatch upstream. Check show interfaces for late collisions on any link involved in a reported "slow" complaint before looking anywhere else.
Late collisions only appear on the side of the link running half duplex — the full-duplex side shows CRC errors and runts instead. Check the counters on both ends before ruling a mismatch out; a clean late-collision counter on one end proves nothing if that end happens to be the full-duplex side.