Network Diagnostic Commands Beyond Ping

Once basic reachability is known or inconclusive, the investigation must move to better questions:

• Which path is traffic taking?
• Where does the path change or stop?
• Is the problem Layer 2, Layer 3, Layer 4, DNS, TLS, or application behavior?
• Is loss real forwarding loss or only control-plane rate limiting?
• Does the observed failure match the protocol the application actually uses?
• Is the problem on the forward path, return path, resolver path, or server socket?

This article is a command-combination guide for network engineers. It focuses on how tools connect to each other in a troubleshooting sequence.

Tool Selection Matrix

ip route get Before Path Tools

Before running path discovery, confirm what the source host intends to do.

ip route get 203.0.113.10
ip route get 203.0.113.10 from 10.20.1.25
ip rule show
ip addr show

Use this when the host has multiple interfaces, policy routing, VPN routes, containers, VRFs, or overlapping private networks.

Interpretation:

If the source route is wrong, traceroute and transport probes will only confirm the wrong path. Fix route selection first.

arping for Same-Segment Problems

Use arping when the target should be in the same IPv4 broadcast domain.

arping -I eth0 192.168.10.1
arping -c 3 -I eth0 192.168.10.25

It answers Layer 2 questions that routed probes cannot:

• Is the gateway reachable by ARP?
• Is the host present on this VLAN?
• Is there duplicate IP behavior?
• Is the MAC address changing unexpectedly?
• Is ARP blocked, proxied, or answered by the wrong device?

Pair it with:

ip neigh show
ip neigh flush 192.168.10.1

Failure pattern:

traceroute for Path Discovery

traceroute discovers a likely hop sequence by sending probes with increasing TTL or hop limit. Each expired probe should cause an intermediate router to return a time-exceeded response.

Common forms:

traceroute example.com
traceroute -n 203.0.113.10
traceroute -I 203.0.113.10
traceroute -T -p 443 203.0.113.10

Use -n during incidents to avoid DNS delay and misleading reverse names.

Probe mode matters:

Important caveats:

• Asterisks do not always mean forwarding failure.
• Intermediate routers may rate-limit replies to themselves.
• ECMP can show different hops per probe.
• Firewalls may allow the final application port but block traceroute replies.
• MPLS, cloud fabrics, overlays, and SD-WAN can hide or abstract hops.

tracepath for MTU and Path Hints

tracepath is useful on Linux because it can expose Path MTU information without requiring elevated privileges.

tracepath 203.0.113.10
tracepath -n 203.0.113.10

Use it when:

• traffic works for small payloads but fails for larger sessions
• VPN, GRE, IPsec, VXLAN, PPPoE, or cloud tunnels are in the path
• you need quick evidence of a reduced path MTU

Typical interpretation:

Do not stop at tracepath output. Confirm with application behavior and, where possible, firewall rules that allow required ICMP errors.

mtr for Time-Based Path Quality

mtr is the right tool when the failure is intermittent or performance-related.

mtr -n 203.0.113.10
mtr -rwzc 100 203.0.113.10
mtr -T -P 443 -rwzc 100 203.0.113.10

Use report mode for incident evidence:

mtr -rwzc 200 target.example.com

Interpret loss carefully:

fping for Many Targets

fping is for host sets, not deep single-path diagnosis.

fping -a -g 10.10.10.0/24
fping -u -f hosts.txt
fping -c 5 -q -f hosts.txt

Use it for:

• subnet discovery during controlled audits
• checking many infrastructure IPs during a change
• comparing branch devices or access points
• building an initial live/dead host list

Do not use wide sweeps without authorization. Many environments alert on scan-like behavior.

Good workflow:

1. Use fping to identify affected hosts.
2. Use ip route get and traceroute for representative failed hosts.
3. Use mtr if loss is intermittent.
4. Use protocol-specific tools for services on those hosts.

nc for Simple TCP and UDP Reachability

nc is a fast transport-level check.

nc -vz app.example.com 443
nc -vz db.example.com 5432
nc -vzu dns.example.com 53

TCP interpretation:

UDP interpretation is weaker because UDP has no handshake. For UDP services, prefer protocol-aware clients such as dig for DNS, ntpdate or chrony tools for NTP, and packet capture when ambiguity remains.

nping for Controlled TCP, UDP, and ICMP Probes

nping gives more control than nc and clearer statistics for repeated transport probes.

nping --tcp -p 443 app.example.com
nping --tcp -p 443 --flags syn app.example.com
nping --udp -p 53 dns.example.com
nping --rate 5 --count 20 --tcp -p 8443 api.example.com

Use it when:

• ICMP is filtered but TCP service reachability matters
• you need repeatable packet counts
• firewall behavior differs by protocol or port
• you need to compare ports on the same destination

Pair nping with tcpdump on the client or server side to prove whether SYNs leave, SYN-ACKs return, or UDP replies are missing.

hping3 for Packet-Crafting Checks

hping3 is useful when you need to test specific TCP flag behavior, firewall policy, or TCP-based path discovery.

hping3 -S -p 443 target.example.com
hping3 -A -p 443 target.example.com
hping3 -F -p 443 target.example.com
hping3 --traceroute -S -p 443 target.example.com

Use cases:

Operational warning: packet crafting can look hostile. Use only where you are authorized and where monitoring teams know the test window.

dig for DNS Diagnosis

DNS failures often masquerade as network failures. Test resolution directly.

dig example.com A
dig example.com AAAA
dig @8.8.8.8 example.com A
dig +trace example.com
dig +short app.example.com

Check:

• resolver used by the client
• authoritative answer versus recursive resolver answer
• split-horizon DNS behavior
• stale cache
• missing A or AAAA record
• CNAME chains
• DNSSEC-related failures

Useful sequence:

1. Query the same resolver the failing client uses.
2. Query a known external resolver only for comparison.
3. Query authoritative path with +trace when delegation is suspicious.
4. Use curl --resolve or curl --connect-to to separate DNS from HTTP/TLS.

curl for HTTP and API Paths

Use curl when the service is HTTP or HTTPS. It tests DNS, TCP, TLS, HTTP, redirects, headers, proxy behavior, and response timing depending on flags.

curl -v https://app.example.com/
curl -I https://app.example.com/
curl --connect-timeout 5 https://app.example.com/
curl -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' -o /dev/null -s https://app.example.com/

Interpret timing:

Separate DNS from service behavior:

curl --resolve app.example.com:443:203.0.113.10 https://app.example.com/

This forces the target IP while preserving the Host header and TLS SNI.

openssl s_client for TLS

Use openssl s_client when the TCP port opens but TLS fails or clients report certificate problems.

openssl s_client -connect app.example.com:443 -servername app.example.com
openssl s_client -connect 203.0.113.10:443 -servername app.example.com

Check:

• certificate chain
• SNI behavior
• protocol version
• cipher negotiation
• certificate expiry
• mismatch between IP, load balancer, and hostname

If nc succeeds but openssl s_client fails, the network path is probably open and the failure is TLS policy, certificate chain, SNI, or backend service behavior.

swaks for SMTP

SMTP should not be tested with generic TCP checks alone.

swaks --server mail.example.com --port 25
swaks --server mail.example.com --port 587 --tls
swaks --to user@example.com --server mail.example.com

Use it to validate:

• banner response
• STARTTLS support
• relay policy
• authentication behavior
• mail path restrictions

Pair it with DNS checks for MX, SPF, DKIM, and DMARC when the incident is mail delivery, not just socket reachability.

ss for Local Socket Truth

On the server, confirm whether a service is actually listening.

ss -lntp
ss -lnup
ss -tan state syn-recv
ss -tan sport = :443

Use ss to answer:

• Is the process listening on the expected IP and port?
• Is it bound to 127.0.0.1 only?
• Are SYNs arriving but not completing?
• Are many connections stuck in SYN-RECV, ESTAB, FIN-WAIT, or TIME-WAIT?

If clients time out but the server never sees SYNs, focus on path, firewall, NAT, or load balancer. If the server sees SYNs and replies, focus on return path or client-side filtering.

tcpdump for Evidence

Use packet capture when command outputs disagree or when you need proof.

Client side:

sudo tcpdump -ni eth0 host 203.0.113.10
sudo tcpdump -ni eth0 'tcp port 443 and host 203.0.113.10'

Server side:

sudo tcpdump -ni eth0 'tcp port 443'
sudo tcpdump -ni eth0 'udp port 53'

TCP interpretation:

Capture both ends when possible. One-sided packet capture is evidence, not the full story.

Combined Troubleshooting Playbooks

Path Stops Before Destination

Use when users report that a remote service is unreachable and basic host configuration looks correct.

ip route get target
traceroute -n target
traceroute -T -p 443 target
mtr -rwzc 100 target

Decision:

TCP Service Timeout

Use when the target service uses a known TCP port.

nc -vz app.example.com 443
nping --tcp -p 443 --count 10 app.example.com
traceroute -T -p 443 app.example.com
sudo tcpdump -ni eth0 'tcp port 443 and host app.example.com'

Decision:

DNS Works in One Location, Fails in Another

dig app.example.com A
dig app.example.com AAAA
dig @resolver-ip app.example.com A
dig +trace app.example.com
curl --resolve app.example.com:443:203.0.113.10 https://app.example.com/

Decision:

HTTPS Opens But Browser Fails

nc -vz app.example.com 443
openssl s_client -connect app.example.com:443 -servername app.example.com
curl -v https://app.example.com/
curl -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' -o /dev/null -s https://app.example.com/

Decision:

Same VLAN Host Cannot Reach Gateway

ip addr show
ip route get gateway-ip
arping -I eth0 gateway-ip
ip neigh show
sudo tcpdump -ni eth0 arp

Decision:

Intermittent WAN or Cloud Path Degradation

mtr -rwzc 300 target
traceroute -T -p 443 target
curl -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' -o /dev/null -s https://target/

Correlate command output with:

• interface drops and errors
• firewall session drops
• SD-WAN steering events
• cloud route table changes
• NAT gateway metrics
• load balancer target health
• application logs

Do not rely on a single sample. Intermittent failures require time-series evidence.

Command Chain Reference

Use this sequence when you need a compact field workflow:

1. ip route get        -> confirm source, route, interface
2. arping / ip neigh   -> confirm same-segment adjacency if local
3. traceroute          -> map likely routed path
4. tracepath           -> inspect MTU hints
5. mtr                 -> measure path quality over time
6. nc / nping          -> test transport reachability
7. curl / dig / openssl -> test protocol behavior
8. ss                  -> confirm server listener state
9. tcpdump             -> prove packet direction and failure point

The rule is simple: each command should answer one specific question and determine the next command. Random command runs create noise; chained evidence creates a fault domain.