Top 15 Network Troubleshooting Commands Every Engineer Should Know
Home › Network Troubleshooting › Top 15 Network Troubleshooting Commands
A practical field reference with real CLI output, output interpretation, and pro tips — covering Cisco IOS, Linux, and Windows for CCNA, CCNP, and senior network engineers
By Route XP | Published: March 2026 | Updated: March 2026 | Network Troubleshooting, Cisco, Networking Fundamentals
Top 15 Network Troubleshooting Commands — Cisco IOS, Linux & Windows CLI Reference
- ping — Layer 3 Reachability Test
- traceroute / tracert — Path Discovery
- show ip route — Routing Table Inspection
- show interfaces — Interface Health Check
- show ip arp — ARP Table Verification
- show ip bgp summary — BGP Neighbour State
- debug ip packet — Real-Time Packet Tracing
- tcpdump — Linux Packet Capture
- netstat / ss — Connection and Port State
- nslookup / dig — DNS Resolution Testing
- show spanning-tree — STP Topology Check
- ip ospf / show ospf neighbor — OSPF State
- show logging — Syslog and Error Events
- show cdp neighbors — Layer 2 Topology Discovery
- show tech-support — Full Diagnostic Snapshot
- Quick Reference Table
Every network outage has a story. And that story is almost always told through the output of a handful of CLI commands. Whether you're chasing a BGP session that won't establish, a host that can't reach its default gateway, or a mysterious interface flap at 3 AM, the commands below are the tools that experienced engineers reach for first.
This guide covers the 15 most impactful network troubleshooting commands across Cisco IOS/IOS-XE, Linux, and Windows — with real output examples, what to look for, and pro tips that go beyond what you'll find in a textbook.
1. ping — Layer 3 Reachability Test
Platform: Cisco IOS / Linux / Windows | OSI Layer: 3 (Network)
ping sends ICMP Echo Request packets to a target and measures whether Echo Reply packets are returned. It is always your first move — before spending time on routing tables or debugs, confirm whether you can reach the target at all.
Router# ping 10.10.20.1 source GigabitEthernet0/0 repeat 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 10.10.20.1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/2/4 ms
Reading the output: Each ! is a successful reply. A . (period) means a timeout — the packet was sent but no reply arrived in time. U means the router received an ICMP Unreachable back (destination or port unreachable — a different failure mode to a timeout). A mix of !.!.! often indicates a routing asymmetry or intermittent link issue.
source GigabitEthernet0/0 simulates the exact path.
2. traceroute / tracert — Path Discovery
Platform: Cisco IOS (traceroute) / Linux (traceroute) / Windows (tracert) | OSI Layer: 3
Traceroute maps the hop-by-hop path from source to destination by sending packets with incrementing TTL values. Each router that decrements TTL to zero returns an ICMP Time Exceeded message — revealing its IP address and the latency at that hop.
Type escape sequence to abort.
Tracing the route to 8.8.8.8
1 10.0.0.1 2 msec 1 msec 2 msec
2 203.0.113.1 8 msec 7 msec 9 msec
3 72.14.200.1 12 msec 11 msec 13 msec
4 8.8.8.8 14 msec 13 msec 14 msec
What to look for: A sudden latency spike between two hops points to a congested or slow WAN link at that segment. Three asterisks (* * *) mean that hop's router is not replying to ICMP — common for ISP core routers with ICMP rate limiting. If the trace stops mid-path, the last responding hop is your point of failure.
traceroute -T -p 443 8.8.8.8 uses TCP SYN packets on port 443 instead of UDP — this bypasses firewalls that block ICMP/UDP traceroute and gives you a more realistic path for HTTPS traffic.
3. show ip route — Routing Table Inspection
Platform: Cisco IOS/IOS-XE | OSI Layer: 3
If ping fails, the routing table is the first place to look. show ip route shows every prefix the router knows about, its source (connected, static, OSPF, BGP etc.), administrative distance, metric, and next-hop.
Routing entry for 192.168.100.0/24
Known via "ospf 1", distance 110, metric 20
Last update from 10.0.0.2 on GigabitEthernet0/1, 00:03:42 ago
Routing Descriptor Blocks:
* 10.0.0.2, from 10.0.0.2, via GigabitEthernet0/1
Route metric is 20, traffic share count is 1
Key fields: The letter prefix tells you the source — C connected, S static, O OSPF, B BGP, D EIGRP. The number in brackets is [AD/metric] — Administrative Distance / route metric. A missing route for your destination means either the route was never learned, has been withdrawn, or is being filtered.
show ip route longer-prefixes to see if a more-specific route is overriding your expected path. A /32 host route injected by a misconfigured script can silently override a correct /24 prefix.
4. show interfaces — Interface Health Check
Platform: Cisco IOS/IOS-XE | OSI Layer: 1–2
Before any Layer 3 investigation, confirm the physical and data-link layers are healthy. show interfaces reveals line protocol state, input/output errors, CRC errors, resets, and queue drops — the most critical indicators of hardware or cabling problems.
GigabitEthernet0/1 is up, line protocol is up
Hardware is ISR4451-X, address is aabb.cc00.0200
Internet address is 10.0.0.1/30
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec
5 minute input rate 45,000 bits/sec, 60 packets/sec
5 minute output rate 32,000 bits/sec, 42 packets/sec
0 input errors, 0 CRC, 0 frame
142 input errors, 78 CRC, 12 giants <-- bad cable / duplex mismatch
| Counter | Likely Cause |
|---|---|
| CRC errors | Faulty cable, bad SFP, duplex mismatch, electromagnetic interference |
| Input errors / Giants / Runts | MTU mismatch, duplex mismatch, bad NIC on connected device |
| Output drops | Interface is congested — QoS queue filling faster than it drains |
| Resets / Flaps | Physical link instability — check SFP seating, cable, and keepalive config |
show interfaces | include line|errors|rate to get a concise error summary across all interfaces at once — far faster than reading the full output for every port.
5. show ip arp — ARP Table Verification
Platform: Cisco IOS/IOS-XE | OSI Layer: 2–3
ARP bridges Layer 3 IP addresses to Layer 2 MAC addresses on the local segment. When a host can ping its own gateway IP but not beyond, or when traffic is not flowing despite a correct routing table, the ARP table is the next stop. A missing or incorrect ARP entry is a silent killer.
Protocol Address Age(min) Hardware Addr Type Interface
Internet 192.168.1.1 - aabb.cc00.0100 ARPA Gi0/0
Internet 192.168.1.10 4 0050.7966.6800 ARPA Gi0/0
Internet 192.168.1.20 0 Incomplete ARPA Gi0/0
An Incomplete ARP entry means the router sent an ARP request but received no reply — the target host is unreachable at Layer 2. Check whether the host is powered on, connected to the correct VLAN, and not blocked by an access list. Also look for duplicate IP addresses — two devices claiming the same IP will cause intermittent Incomplete entries as ARP replies race each other.
arp -n or ip neigh show to inspect the ARP/neighbour cache. The FAILED state is the Linux equivalent of Cisco's Incomplete.
6. show ip bgp summary — BGP Neighbour State
Platform: Cisco IOS/IOS-XE | OSI Layer: 4 / Application
For any network running BGP — whether it's an enterprise WAN, an internet edge, or a data center fabric — show ip bgp summary is the fastest way to assess the health of all BGP sessions at a glance.
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.0.2 4 65002 14821 14803 85 0 0 3d14h 120
10.0.0.6 4 65003 0 0 0 0 0 never Active
10.0.0.10 4 65004 512 508 85 0 0 00:12:33 45
Reading the State/PfxRcd column: A number means the session is established and that many prefixes are received — healthy. Active means the router is trying to establish a TCP session but failing — check reachability to the peer IP, ACLs blocking TCP/179, and whether the peer has this router configured. Idle means the session is administratively down or the peer IP is unreachable. A very recent Up/Down timestamp combined with a small prefix count often indicates the session is flapping.
show ip bgp neighbors 10.0.0.6 | include BGP state|hold|notification to pinpoint why a neighbour is stuck in Active — the notification error code tells you exactly what went wrong in the last session teardown.
7. debug ip packet — Real-Time Packet Tracing
Platform: Cisco IOS/IOS-XE | OSI Layer: 3
debug ip packet prints real-time output for every IP packet processed by the router's software path — showing source, destination, protocol, and interface. It is the most granular Layer 3 tool on IOS, but must be used carefully.
debug ip packet without a filter will print millions of lines per second and can crash the device. Always create a named access list that matches only the specific source/destination you care about, then pass it to the debug command.
Router# ip access-list extended DEBUG-FILTER
Router(config-ext-nacl)# permit ip host 192.168.1.10 host 10.10.10.1
Router(config-ext-nacl)# permit ip host 10.10.10.1 host 192.168.1.10
Router(config-ext-nacl)# exit
Router# debug ip packet DEBUG-FILTER detail
IP: s=192.168.1.10 (Gi0/0), d=10.10.10.1, len 84, forward
IP: s=10.10.10.1 (Gi0/1), d=192.168.1.10, len 84, forward
# Always turn off debug when done
Router# undebug all
show platform packet-trace or debug platform condition ipv4 — these trace packets in the hardware forwarding plane without the CPU impact of software debug.
8. tcpdump — Linux Packet Capture
Platform: Linux | OSI Layer: 2–7
tcpdump is the command-line packet analyser for Linux systems — the equivalent of running Wireshark without a GUI. It captures live packets on a specified interface with powerful BPF (Berkeley Packet Filter) expression filtering. Mastering tcpdump is essential for any engineer working on Linux servers, containers, or virtual network appliances.
$ tcpdump -i eth0 -n host 192.168.1.10 and host 10.10.10.1
# Capture HTTP and HTTPS traffic, write to file for Wireshark analysis
$ tcpdump -i eth0 -n -w capture.pcap port 80 or port 443
# Show TCP SYN packets only — useful for connection attempt tracing
$ tcpdump -i eth0 -n 'tcp[tcpflags] & tcp-syn != 0'
# Verbose output with hex dump
$ tcpdump -i eth0 -n -XX -vvv host 192.168.1.10
-n to disable DNS reverse lookups — without it, tcpdump tries to resolve every IP address it sees, dramatically slowing output and potentially missing fast bursts. Use -w to save captures to a .pcap file and open them in Wireshark for deeper analysis.
9. netstat / ss — Connection and Port State
Platform: Linux / Windows | OSI Layer: 4 (Transport)
netstat (and its modern Linux replacement ss) shows active TCP/UDP connections, listening ports, and socket statistics. It answers the question: is this service actually listening, and are connections being accepted?
$ ss -tlnp
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1234))
LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=5678))
# Check for established connections to port 443
$ ss -tn state established dport = :443
10. nslookup / dig — DNS Resolution Testing
Platform: Linux / Windows | OSI Layer: 7 (Application)
A surprising number of "network outages" turn out to be DNS failures. dig (Linux) and nslookup (Windows/Linux) query DNS servers directly, bypassing the local resolver cache and returning full resolution details — including which nameserver answered, the TTL, and the full answer chain.
$ dig @8.8.8.8 www.thenetworkdna.com A
;; ANSWER SECTION:
www.thenetworkdna.com. 300 IN A 172.217.25.3
;; Query time: 12 msec
;; SERVER: 8.8.8.8#53
# Trace the full delegation chain from root to authoritative NS
$ dig +trace www.thenetworkdna.com
ping www.google.com fails but ping 8.8.8.8 succeeds, DNS is broken — not the network. Use dig @<your-dns-server> <hostname> to confirm whether the resolver is responding. Use dig +trace to check the full delegation chain from root servers down — this reveals split-horizon DNS misconfigurations and stale delegation records.
11. show spanning-tree — STP Topology Check
Platform: Cisco IOS/IOS-XE (Catalyst Switches) | OSI Layer: 2
Spanning Tree Protocol (STP) issues are among the hardest problems to diagnose because they present as slow convergence, intermittent packet loss, or complete Layer 2 loops — symptoms that look like many other failures. show spanning-tree reveals the current STP topology, root bridge election, port roles, and port states.
VLAN0010
Spanning tree enabled protocol rstp
Root ID Priority 4106
Address aabb.cc00.0100
This bridge is the root
Interface Role Sts Cost Prio.Nbr
Gi0/1 Desg FWD 4 128.1
Gi0/2 Desg FWD 4 128.2
Gi0/3 Altn BLK 4 128.3
show spanning-tree detail | include ieee|occur|from|is exec to check for topology change counts. A rapidly incrementing TC (topology change) counter indicates a port is flapping and continuously triggering STP reconvergence — flooding the CAM table and causing temporary broadcast storms.
12. show ip ospf neighbor — OSPF Adjacency State
Platform: Cisco IOS/IOS-XE | OSI Layer: 3
For networks running OSPF, the first command when routes go missing is show ip ospf neighbor. It shows every OSPF adjacency, its state, the dead timer countdown, and which interface it was formed on.
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 FULL/DR 00:00:32 10.0.0.2 Gi0/0
3.3.3.3 1 EXSTART/DROther 00:00:10 10.0.0.6 Gi0/1
OSPF neighbour states to know: FULL is healthy — the adjacency is complete and LSAs are synchronised. 2WAY is normal for non-DR/BDR routers on broadcast segments. EXSTART / EXCHANGE stuck here usually means an MTU mismatch between the two ends — check ip ospf mtu-ignore as a temporary workaround and fix the MTU mismatch as a proper resolution. INIT or ATTEMPT means Hello packets are being sent but not received back — check ACLs, multicast reachability, and OSPF area mismatch.
00:00:02) that isn't dropping means the interface is healthy. But if you see the dead timer reach zero and the neighbour disappear, then reappear — that's an intermittent Hello packet loss. Check interface error counters first.
13. show logging — Syslog and Error Events
Platform: Cisco IOS/IOS-XE | OSI Layer: All
The router's local syslog buffer is often the fastest way to understand what happened before you got the call. Interface flaps, protocol state changes, security violations, and hardware errors all generate log messages — and the timestamps tell you exactly when events occurred.
Mar 6 14:22:01: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down
Mar 6 14:22:04: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Gi0/1 from FULL to DOWN
Mar 6 14:22:05: %BGP-5-ADJCHANGE: neighbor 10.0.0.6 Down Interface flap
Mar 6 14:28:33: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to up
service timestamps log datetime msec on every Cisco device. Without it, logs show only relative uptime — making it impossible to correlate events across multiple devices. With millisecond timestamps, you can sequence events across the entire network during a failure.
14. show cdp neighbors detail — Layer 2 Topology Discovery
Platform: Cisco IOS/IOS-XE | OSI Layer: 2
CDP (Cisco Discovery Protocol) is a Layer 2 multicast protocol that Cisco devices use to advertise themselves to directly connected neighbours. show cdp neighbors detail reveals the hostname, model, IOS version, IP address, and connected interface of every directly attached Cisco device — without consulting any documentation.
-------------------------
Device ID: SW-CORE-01
Entry address(es): IP address: 10.0.0.2
Platform: Cisco WS-C3850-48P, Capabilities: Switch IGMP
Interface: GigabitEthernet0/0, Port ID (outgoing port): GigabitEthernet1/0/1
Holdtime: 163 sec
Version: Cisco IOS Software, Version 16.12.5
%CDP-4-NATIVE_VLAN_MISMATCH or %CDP-4-DUPLEX_MISMATCH messages in the log. These mismatches are a silent cause of poor performance and intermittent packet loss that is almost impossible to find without CDP. On multi-vendor networks, use LLDP (show lldp neighbors detail) as the IEEE-standard equivalent.
15. show tech-support — Full Diagnostic Snapshot
Platform: Cisco IOS/IOS-XE | OSI Layer: All
show tech-support is not a single command — it is Cisco's built-in macro that runs dozens of show commands and concatenates the output into a single, comprehensive diagnostic snapshot of the device's current state. It is what Cisco TAC will request first when you open a service request.
Router# show tech-support | redirect flash:tech-support-2026-03-06.txt
# Then copy to a TFTP server
Router# copy flash:tech-support-2026-03-06.txt tftp://192.168.1.200/
show tech-support immediately after a failure event — before any changes are made and before the device reboots. Log buffers, CPU history, interface counters, and process memory data are all captured at that moment. Once you start troubleshooting and making changes, the diagnostic snapshot loses its forensic value.
Quick Reference Table
| # | Command | Platform | OSI Layer | What It Diagnoses |
|---|---|---|---|---|
| 1 | ping |
Cisco / Linux / Win | L3 | Basic IP reachability and RTT |
| 2 | traceroute |
Cisco / Linux / Win | L3 | Hop-by-hop path, latency per segment |
| 3 | show ip route |
Cisco IOS | L3 | Routing table, missing prefixes, AD/metric |
| 4 | show interfaces |
Cisco IOS | L1–L2 | CRC errors, drops, line protocol state |
| 5 | show ip arp |
Cisco IOS | L2–L3 | ARP resolution, duplicate IPs, L2 reachability |
| 6 | show ip bgp summary |
Cisco IOS | L3–L4 | BGP session state, prefix counts, flaps |
| 7 | debug ip packet |
Cisco IOS | L3 | Real-time per-packet forwarding decisions |
| 8 | tcpdump |
Linux | L2–L7 | Full packet capture, protocol analysis |
| 9 | ss / netstat |
Linux / Windows | L4 | Listening ports, active connections, socket state |
| 10 | dig / nslookup |
Linux / Windows | L7 | DNS resolution, nameserver responses, TTLs |
| 11 | show spanning-tree |
Cisco IOS | L2 | STP topology, root bridge, port roles/states |
| 12 | show ip ospf neighbor |
Cisco IOS | L3 | OSPF adjacency state, stuck at EXSTART/INIT |
| 13 | show logging |
Cisco IOS | All | Historical events, interface flaps, protocol changes |
| 14 | show cdp neighbors detail |
Cisco IOS | L2 | Connected devices, duplex/VLAN mismatches |
| 15 | show tech-support |
Cisco IOS | All | Full diagnostic snapshot for TAC / post-incident |
line protocol down state.
📘 Facebook 🐦 Twitter 💼 LinkedIn
CLI examples based on Cisco IOS/IOS-XE 17.x, Linux kernel 6.x (Ubuntu 24.04), and Windows 11. Output samples are representative and may vary by platform version. Always validate commands in a lab environment before applying to production. All content current as of March 2026.
