Browse Cisco Certification Guides

Diagnosing Problems

Study Cisco CCST Networking diagnostics: troubleshooting methodology, ticketing, documentation, information gathering, packet capture, ping, traceroute, ipconfig, ifconfig, and show commands.

Diagnosing Problems is the support workflow domain. Cisco expects entry technicians to gather useful evidence, follow a method, document what changed, and escalate with enough context.

Troubleshooting sequence

    flowchart TD
	  S["User symptom"] --> I["Identify scope"]
	  I --> E["Gather evidence"]
	  E --> L["Localize layer or path"]
	  L --> A["Apply safe action"]
	  A --> V["Verify result"]
	  V --> D["Document and escalate if needed"]

Basic diagnostic tools

Tool or command What it helps prove
ping basic reachability and latency signal
traceroute / tracert path and where traffic may stop
ipconfig / ifconfig / ip addr local addressing information
nslookup / dig DNS resolution
Wireshark capture packet-level evidence saved for analysis
show ip interface brief interface state and address summary on Cisco devices
show ip route routing table evidence
show mac address-table learned MAC addresses on a switch
show cdp neighbors directly connected Cisco neighbors where CDP is enabled

Symptom-to-check map

Symptom First useful checks
one user cannot connect cable/Wi-Fi, local IP config, gateway, DNS, recent changes
many users in one area fail access switch, AP, VLAN, uplink, local power, cabling closet
internal apps work but internet fails default route, firewall, NAT, provider, DNS, proxy
IP works but names fail DNS server, resolver configuration, search suffix, cached result
intermittent wireless issue signal strength, roaming, interference, channel congestion, authentication logs
slow service scope, throughput, latency, packet loss, server/app load, path changes

Safe troubleshooting method

Good support troubleshooting is controlled, not random:

  1. Define the symptom in observable terms.
  2. Identify scope: one user, one subnet, one site, one app, or all services.
  3. Gather local evidence before changing infrastructure.
  4. Test the simplest likely layer first.
  5. Make one safe change at a time.
  6. Verify that the user-facing symptom changed.
  7. Document commands, results, and remaining impact.

Packet capture role

Wireshark or another packet capture tool can provide evidence when simple commands are not enough. For CCST, think of packet capture as a way to preserve traffic evidence for analysis, not as a reason to guess. Useful capture questions include: did the host send traffic, did it receive a reply, was DNS queried, and was the service port contacted?

Good ticket notes

A useful escalation includes the symptom, affected users, time started, device and port, IP configuration, commands run, outputs observed, changes attempted, and current business impact.

Escalation quality

Weak escalation Strong escalation
“Internet is broken.” “Three users in room 204 lost internet at 09:10; local IPs assigned; gateway ping fails; switch port LEDs on; no recent desk moves reported.”
“DNS issue maybe.” “User can ping 8.8.8.8 but cannot resolve example.com; configured DNS server is 10.10.10.5; nslookup times out.”
“Rebooted device.” “Rebooted laptop after verifying cable and IP; symptom unchanged; attached ipconfig and ping output.”

Exam traps to avoid

  • Do not skip scope. Scope is often the fastest way to choose the next test.
  • Do not treat ping failure as proof the server is down; ICMP may be blocked.
  • Do not make multiple changes before verifying which one mattered.
  • Do not hide failed steps. Failed checks are useful evidence for escalation.
Revised on Monday, June 15, 2026
4. Infrastructure
6. Security