Network Troubleshooting: Ping, Traceroute, Wireshark, and Methodology

Network troubleshooting is the systematic process of identifying, isolating, and resolving problems in data communication. The most effective troubleshooters combine a structured methodology — often following the OSI model from layer 1 upward — with deep familiarity with diagnostic tools and a well-maintained knowledge base of past incidents. This guide covers the troubleshooting methodology, essential command-line tools, Wireshark packet analysis, common problem categories, and strategies for building a repeatable resolution process.

The Troubleshooting Methodology

Step 1: Define the Problem

Elicit the precise symptoms: “What specific functionality is broken? Does it affect one device, a department, or the entire site? When did it start? Has anything changed — a software update, hardware replacement, configuration change, cabling work?” The problem statement “the internet is slow” is too vague; “video conferencing from the east wing has 5-second lag starting this morning” is actionable.

Step 2: Establish the Scope

Determine the boundary of the problem. If one device cannot reach the internet, the scope is that device and its link. If all devices in a building lose connectivity, the scope is the building distribution or upstream WAN connection. Boundary identification eliminates unproductive investigation — if other devices on the same switch work, the problem is not at the switch.

Step 3: Formulate and Test Hypotheses

Rank hypotheses by probability and testability. Start with the cheapest and fastest tests: “Can you ping the gateway?” (30 seconds). Physical layer problems are underrated: a 2022 Enterprise Management Associates study found that 40 percent of network incidents originate at layer 1 (cables, connectors, transceivers). Test systematically — do not jump to application-layer analysis when a loose cable is the likely cause.

Step 4: Isolate and Resolve

Apply the corrective action — replace the cable, correct the configuration, restart the service. Verify that the fix resolved the original symptom and did not introduce new ones. Re-test all affected functionality before closing the ticket.

Step 5: Document

Record the symptoms, diagnostic steps, root cause, and resolution. This builds the knowledge base that shortens future troubleshooting. Note any monitoring gaps — if the problem was not detected automatically, configure an alert.

Essential Command-Line Tools

Ping

ping sends ICMP Echo Request packets (RFC 792) and measures Echo Reply latency. Ping confirms reachability and round-trip time. Normal LAN latency: under 1 ms. WAN latency: 5-150 ms depending on distance. Packet loss: any loss above 1 percent indicates an issue. TTL expiry (TTL exceeded in transit) reveals hop count. Ping is the most basic test: if ping to the default gateway works but ping to an external IP does not, the problem is beyond the gateway.

Traceroute

traceroute (Linux/Unix/macOS) or tracert (Windows) maps the router-level path to a destination by sending packets with incrementing TTL values. Each router that decrements TTL to 0 sends an ICMP Time Exceeded message (type 11), revealing its IP. Uses: identify where latency increases (transatlantic hops add 60-80 ms), where packet loss starts (upstream router dropping), or where routing loops occur (same IP address repeated). Asterisks (* * *) mean a hop did not respond, which can be normal (routers may prioritize forwarding over ICMP responses) or indicate a problem.

Nslookup and Dig

nslookup and dig query DNS servers. Dig is more powerful: dig example.com A returns IPv4 records. dig example.com AAAA returns IPv6. dig example.com MX returns mail servers. dig +trace example.com walks the entire delegation chain. dig @8.8.8.8 example.com tests a specific resolver. If a domain resolves with a different server but not the default, the default DNS server configuration is suspect.

Netstat and Ss

netstat and ss display active network connections, listening ports, and routing tables. On Linux, ss -tuln lists all TCP and UDP listening sockets with numeric addresses. netstat -s shows protocol statistics (TCP retransmissions, UDP errors). High TCP retransmissions (above 1 percent) indicate network congestion or packet loss. Check for unexpected listening ports that may indicate a compromised service.

Ipconfig, Ifconfig, and IP

ipconfig (Windows) and ifconfig/ip addr (Linux) show interface configuration: IP address, subnet mask, default gateway, DNS servers, and MAC address. Common errors: wrong subnet mask (communication fails outside the local network), missing default gateway (no internet access), duplicate IP address (intermittent connectivity — the DHCP conflict detection timer causes one device to drop off). ip neigh (Linux) shows the ARP table — missing ARP entries for the gateway indicate layer-2 connectivity problems.

Wireshark Packet Analysis

Wireshark captures frames and decodes protocol headers for in-depth analysis. Essential use cases: TCP handshake analysis — a SYN without SYN-ACK indicates the destination is not listening or a firewall is blocking. TCP retransmissions — filter tcp.analysis.retransmission to locate packets that were not acknowledged. DNS resolution time — filter dns and inspect the time delta between query and response. TLS handshake — filter tls.handshake.type to confirm cipher suite negotiation. Capture only the traffic of interest using capture filters (host 10.0.0.1, port 443), not all traffic on the segment — this avoids overwhelming the capture buffer on high-speed links.

Common Problem Categories

Physical Layer

Damage to cables, loose connectors, failed SFP transceivers, incorrect pinout, and exceeding distance limits (100 m for twisted pair, 550 m for OM4 10 Gbps) cause loss of signal or high error rates. Symptom: interface error counters show CRC errors, runts, or giants. Resolution: inspect cable and connector, test with a certifier, replace the suspect component.

IP Configuration and DHCP

Incorrect IP address, wrong subnet mask, missing gateway, or DHCP server failure. DHCP failures may be caused by pool exhaustion (all IP addresses leased), DHCP snooping blocking legitimate traffic, or a rogue DHCP server responding faster than the legitimate one. Resolution: verify DHCP server availability, check pool utilization, configure DHCP snooping with trusted port verification.

DNS

Misconfigured DNS servers, expired domain records, DNSSEC validation failure. Symptom: “Server not found” in the browser while ping to the IP address works. Resolution: verify DNS server addresses on the client, confirm domain records with dig, check DNSSEC chain.

Routing

Missing routes, incorrect next-hop IP, routing protocol adjacency failure. Symptom: traceroute stops at a specific hop. Resolution: check the routing table on the suspected router (show ip route), verify OSPF/BGP neighbor state, confirm route redistribution.

Firewall and ACL

Overly restrictive firewall rules, misconfigured ACLs (the implicit deny all at the end), asymmetric routing causing stateful firewall drops. Symptom: some traffic works, other traffic to the same destination fails (e.g., SSH works but HTTP fails). Resolution: check firewall logs for dropped packets, verify rule order (most specific first, deny rule not blocking expected traffic).

Building a Troubleshooting Toolkit

Standardize tooling across the team. Common incident response scripts — “ping the gateway, traceroute to the remote, check interface errors on the access switch” — reduce mean time to resolution. Implement network monitoring (Prometheus + SNMP, LibreNMS, PRTG) with thresholds for latency, packet loss, and interface errors. Configure syslog to centralize device logs. The best investment a network team can make is a well-maintained network diagram with IP addresses, switch names, uplink capacities, and VLAN assignments.

FAQ

Q: What is the first thing to check when a user reports no internet?
A: Physical connectivity — are the link lights on? Then check IP configuration — does the device have an IP address in the correct subnet? Then ping the default gateway. These three checks take 30 seconds and identify the cause in the majority of cases.

Q: How do I tell if packet loss is on my network or the provider’s?
A: Traceroute to an external destination. If packet loss appears only at or beyond the first hop outside your network (the ISP router), the loss is on the provider side. If loss occurs on your internal hops, it is an internal issue.

Q: What is a reasonable baseline for network latency?
A: Within a building: under 1 ms. Within a metropolitan area: under 5 ms. Cross-country (US): 30-60 ms. Transatlantic: 70-100 ms. Transpacific: 120-180 ms. Anything above 200 ms between any two modern data centers is abnormal.

Q: Why does Wi-Fi work but wired Ethernet does not?
A: The problem is likely port-specific — check if the switch port is administratively down, blocked by 802.1X, or disabled by port security. Compare the wired and wireless networks’ IP configurations, VLAN assignments, and gateway addresses.

Q: What does a TCP retransmission in Wireshark indicate?
A: The sender did not receive an acknowledgment within the retransmission timeout. Causes: packet loss (network congestion or faulty link), the receiver is too busy to process and ACK, or a firewall dropped the packet. If retransmissions exceed 2 percent of total TCP segments, investigate.

Internal Links

• OSI Model Guide — using the OSI model for systematic troubleshooting
• Cabling Standards — physical-layer testing and certification
• DNS Guide — DNS resolution troubleshooting with dig

References

• RFC 792, “Internet Control Message Protocol”
• RFC 2151, “A Primer On Internet and TCP/IP Tools and Utilities”
• Wireshark. “Wireshark User’s Guide.” Wireshark Documentation. https://www.wireshark.org/docs/
• Cisco. “Troubleshooting Ethernet.” Cisco Documentation. https://www.cisco.com/c/en/us/support/docs/lan-switching/ethernet/
• Kurose, J. F. and Ross, K. W., Computer Networking: A Top-Down Approach, 8th ed., Pearson, 2021, Section 1.4 (“Network Troubleshooting”)
• Tanenbaum, A. S. and Wetherall, D. J., Computer Networks, 6th ed., Pearson, 2021, Section 1.5 (“Example Networks”)

For a comprehensive overview, read our article on Cabling Standards.

For a comprehensive overview, read our article on Cdn Guide.