Linux Network Troubleshooting Commands and Monitoring Tools: 16 Tools for Faster Diagnosis

Most outages that look mysterious are one of five faults: a dead link, a wrong route, a blocked port, a broken DNS lookup, or congestion. Each fault leaves a different trace, and each Linux command reads a different layer of the stack. Working from the bottom up avoids chasing symptoms.

This guide covers 10 command-line tools and 6 monitoring platforms listed on SaaSPodium. It explains what each tool answers, shows the commands engineers reach for first, and ends with a repeatable workflow. ICMP, the protocol behind ping and traceroute, is defined in RFC 792, and the DNS lookups that dig performs follow RFC 1035.

For teams running Linux servers behind SSO, CRM, ITSM and data warehouse integrations, command-line checks give the fastest first answer, while a monitoring suite supplies history, alerting and topology. Our related guide on network diagnostic tools compares broader options, and the Linux network monitoring software guide goes deeper on continuous monitoring.

1. ping: Test Reachability and Latency First

Ping sends ICMP echo requests and reports round-trip time and packet loss. It is the quickest way to learn whether a host answers at all, and whether latency is steady. A failed ping does not prove an outage, because firewalls often drop ICMP.

• Run ping -c 5 10.0.0.1 to send five probes and read the loss percentage and min/avg/max times.
• Test the gateway first, then a remote IP such as a public resolver, then a hostname. Each step isolates local network, upstream path and DNS in turn.
• Use ping -M do -s 1472 to test path MTU by forbidding fragmentation, a common cause of stalled VPN and API traffic.

2. ip: Inspect Interfaces, Addresses and Routes

The ip command from iproute2 replaces ifconfig, route and arp on modern distributions. It shows whether an interface is up, which addresses it holds, and which route the kernel will pick for a destination, which answers most "why can't it reach X" questions.

• ip -br addr prints a compact table of interfaces and addresses; ip -s link adds RX/TX error and drop counters.
• ip route get 8.8.8.8 shows exactly which interface and gateway the kernel selects for that destination.
• ip neigh lists the ARP and NDP cache, so you can spot an incomplete or failed neighbor entry for the gateway.

3. ss: See Which Ports and Sockets Are Open

The ss utility lists sockets straight from the kernel and is faster than the older netstat. Use it to confirm a service is actually listening on the expected address and port, and to count connections by state when a server seems saturated.

• ss -tulpn shows listening TCP and UDP sockets with the owning process.
• ss -s summarizes totals by state; a large TIME-WAIT or SYN-RECV count points to connection churn or a SYN flood.
• ss -ti dst 10.0.0.5 exposes per-connection TCP details such as RTT, retransmits and congestion window.

4. traceroute and mtr: Find Where the Path Breaks

Traceroute maps each router hop between you and a destination by raising the IP time-to-live value, while mtr combines traceroute and ping in a live view. Together they show where latency jumps or packets disappear along the path.

• mtr -rwzc 50 example.com produces a 50-cycle report with AS numbers and per-hop loss.
• Loss that appears on one hop but not on later hops is usually ICMP rate limiting on that router, not real loss.
• Use traceroute -T -p 443 to probe with TCP when ICMP or UDP probes are filtered.

5. dig: Debug DNS Resolution

Dig queries DNS servers directly and prints the full response, including answer records, TTLs, status codes and the responding server. When an application "cannot connect" but the IP works, dig is usually the next command to run.

• dig example.com +short gives a quick answer; dig @1.1.1.1 example.com tests a specific resolver against your default one.
• dig +trace example.com walks the delegation from the root servers, revealing broken NS records.
• Check the status field: NXDOMAIN means the name does not exist, while SERVFAIL points to a resolver or DNSSEC problem.

6. tcpdump: Capture Packets When Logs Run Out

Tcpdump captures packets on an interface using BPF filters. It is the ground truth tool: if a packet never appears in the capture, no application log can explain it. Use narrow filters to keep captures small and avoid capturing sensitive payloads.

• tcpdump -ni eth0 host 10.0.0.5 and port 443 limits output to one conversation.
• tcpdump -w trace.pcap saves a file you can open in a protocol analyzer later.
• Look for repeated SYN packets without SYN-ACK (blocked or dropped), RST packets (refused), and retransmissions (loss).

7. ethtool: Check Link Speed, Duplex and NIC Errors

Ethtool reads and configures network interface hardware settings. A port that negotiated 100 Mb/s instead of 1 Gb/s, or reports CRC and drop counters, explains slow transfers that no software setting can fix. Always check the physical layer before blaming the application.

• ethtool eth0 shows negotiated speed, duplex and link detection.
• ethtool -S eth0 prints driver statistics such as rx_crc_errors and rx_missed_errors.
• The kernel documents its ethtool interface in the Linux networking documentation, which is worth reading before changing offload or ring settings in production.

8. curl: Test HTTP, TLS and API Endpoints

Curl tests the application layer: it shows HTTP status codes, redirects, TLS handshake details and timing for each phase of a request. It separates DNS, connect, TLS and server time, which tells you whether the network or the application is slow.

• curl -sv https://example.com -o /dev/null prints the TLS handshake, certificate details and response headers.
• curl -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} total:%{time_total}\n" -o /dev/null -s URL breaks timing into phases.
• --resolve host:443:IP pins a hostname to a specific server, handy for testing one node behind a load balancer.

9. nmap: Verify Ports From the Outside

Nmap scans hosts for open ports and service versions. Run it from another machine to confirm what a firewall actually exposes, which often differs from what ss reports locally. Scan only systems you own or have written permission to test.

• nmap -p 22,80,443 10.0.0.5 checks specific ports; -sV adds service version detection.
• Compare results from inside and outside the firewall to find security group or NAT rule mistakes.
• Schedule periodic scans of production ranges and diff the output to detect unexpected new listeners.

10. iw: Diagnose Wi-Fi Signal and Association

The iw command replaces the legacy iwconfig for wireless interfaces. It shows the connected access point, signal strength, bit rate and channel, which helps with laptops, edge devices and warehouse hardware that drop off the network intermittently.

• iw dev wlan0 link prints the associated SSID, signal level and TX bitrate.
• iw dev wlan0 scan lists nearby access points, useful for spotting channel overlap.
• Signal weaker than about -70 dBm commonly produces retransmissions, so move the device or add an access point.

When to Add a Monitoring Platform

Command-line tools tell you what is wrong right now, but they cannot tell you what changed last Tuesday. Monitoring platforms add polling, SNMP, flow data, topology maps and alerting, so you catch the fault before users report it. Six platforms from the SaaSPodium catalog follow.

How we chose: we picked tools from the SaaSPodium Network Monitoring Software category and used only catalog data such as pricing type and deployment options. Ratings and review counts were not yet populated for these listings, so we do not rank by score.

Zabbix: Open Source Monitoring With Deep Customization

Zabbix is an open source monitoring platform that collects metrics through agents, SNMP, ICMP and custom scripts. It suits Linux-heavy teams that want full control and are willing to invest in setup. See the Zabbix profile on SaaSPodium, or visit the official Zabbix site.

• Architecture: server, proxies and agents, which lets distributed sites report through a local proxy.
• Integrations: templates for SNMP devices, plus webhooks for ticketing and chat alerts.
• Pricing model: the software is free to use; commercial support is sold separately by the vendor.

Nagios XI: Check-Based Monitoring for Linux Servers

Nagios XI builds on the long-running Nagios Core plugin model, where small check scripts report OK, warning or critical states. It fits operations teams that already think in terms of host and service checks. See Nagios XI on SaaSPodium.

• Architecture: plugin-based checks with a web configuration layer and wizards.
• Deployment: SaaSPodium lists it as paid, with web and desktop access.
• Fit: sysadmins who want to reuse existing check scripts from command-line troubleshooting.

Paessler PRTG Network Monitor: Sensor-Based Visibility

PRTG uses sensors to monitor bandwidth, uptime, SNMP devices and services from one console, with maps and dashboards. It suits small and mid-size IT teams that want quick setup over scripting flexibility. See PRTG Network Monitor.

• Architecture: a core server with remote probes for other sites.
• Protocols: SNMP, WMI, NetFlow and packet sniffing sensors are part of the product family.
• Pricing model: sold by sensor count; check the vendor for current tiers.

ManageEngine OpManager: Network and Server Fault Management

OpManager combines network discovery, performance monitoring, topology maps and alerting for routers, switches and servers. It targets enterprise IT teams that need fault management and workflow. See ManageEngine OpManager.

• Architecture: SNMP, CLI and WMI based discovery with automatic device classification.
• Integrations: connects with service desk tools through the ManageEngine ecosystem.
• Pricing model: edition-based; confirm current pricing with the vendor.

Progress WhatsUp Gold: Discovery and Mapping With a Free Tier

WhatsUp Gold discovers devices, draws interactive network maps and alerts on outages. SaaSPodium lists its pricing type as freemium, making it a low-risk pilot for small teams. See Progress WhatsUp Gold.

• Architecture: automated layer 2 and layer 3 discovery that builds topology maps.
• Deployment: listed with cloud, web and desktop access.
• Fit: teams that want visual maps without writing configuration files.

SolarWinds Network Performance Monitor: Enterprise Path Analysis

SolarWinds NPM monitors availability and performance across multi-vendor networks and visualizes critical paths between nodes. It targets larger enterprises with complex topologies. See SolarWinds Network Performance Monitor.

• Architecture: SNMP, flow data and topology awareness on a polling engine.
• Integrations: part of a wider SolarWinds platform for server, log and database monitoring.
• Pricing model: licensed by monitored elements; request a quote from the vendor.

A Repeatable Troubleshooting Workflow

A reliable workflow moves from the physical layer upward and changes one thing at a time. Following the same order each incident shortens diagnosis, and it gives junior engineers a runbook they can execute without escalating.

• Link: run ip link and ethtool to confirm the interface is up with no error counters climbing.
• Address and route: run ip addr and ip route get to confirm the right address and gateway.
• Reachability: ping the gateway, then a remote IP, then a hostname to separate local, upstream and DNS faults.
• Path: use mtr to find the failing hop.
• Name and service: use dig for DNS, ss for listeners, curl for the application response.
• Evidence: capture with tcpdump only when the earlier steps do not explain the symptom.

How Monitoring Reduces Time to Resolution

Monitoring shortens mean time to repair by detecting a fault sooner and attaching context. You can estimate the value with a simple formula, using your own incident data rather than industry averages.

Total Repair Time is the sum of hours from detection to resolution across a period, and Number of Incidents is the count in that same period. Track MTTR before and after adding monitoring to see whether alerting and topology maps actually cut diagnosis time. For the broader category, browse Network Monitoring Software on SaaSPodium.

Frequently Asked Questions

Which Linux command should I run first when the network is down?
Start with ip -br addr and ip route get to confirm the interface has an address and a route, then ping the gateway. This separates local configuration faults from upstream or DNS problems in under a minute.

Do I still need ifconfig, netstat and route?
Not on modern distributions. The iproute2 tools ip and ss replace ifconfig, route, arp and netstat, and the older net-tools package is often not installed by default. Learn the newer commands because they are maintained and show more detail.

When is a monitoring platform worth buying over command-line tools?
Add one when you manage more than a handful of devices, need alerts before users complain, or must show historical trends. Pilot a free or open source option such as Zabbix or a freemium tier like WhatsUp Gold before committing to paid licenses.