ping, traceroute, mtr, dig, nslookup, arp, and ip are not just standalone commands — together they form a systematic toolkit for finding exactly where and why a network problem is happening. This article walks through real-world scenarios showing which tool to use, in what order, and what to look for in the output.

ping · traceroute · mtr · dig · nslookup · arp · ip / ifconfig / ipconfig
01 — The Mental Model: Work Down the Stack

Every network problem lives somewhere in the stack. A disciplined approach starts at the physical/link layer and works up — otherwise you waste time checking DNS when the gateway isn't even reachable.

LayerQuestionTool
Layer 2 — LinkIs the interface up? Do I have a MAC/ARP entry for the gateway?ip link, arp / ip neigh
Layer 3 — IPDo I have an IP address? Is the gateway reachable?ip addr, ip route, ping
Layer 3 — PathWhere along the path does traffic stop or slow down?traceroute, mtr
Layer 7 — DNSDoes the domain resolve? Is the right server answering?dig, nslookup
Layer 7 — AppIs the service actually listening on the expected port?curl, telnet, nc
Always confirm lower layers are healthy before blaming higher ones. Chasing a DNS problem when the network cable is unplugged wastes everyone's time.
02 — Quick Diagnostic Checklist

Run these commands in order. Stop when you find the fault — that's the layer to investigate.

# Step 1 — Is my interface up and do I have an IP? ip addr show # Linux ifconfig # macOS ipconfig /all # Windows # Step 2 — Do I have a default route? ip route show # Linux / macOS route print # Windows # Step 3 — Can I reach my gateway? ping -c 4 <gateway_ip> # Step 4 — Can I reach a known public IP? ping -c 4 8.8.8.8 # Step 5 — Can I resolve DNS? nslookup google.com dig google.com +short # Step 6 — Where does the path break? traceroute 8.8.8.8 # Linux / macOS tracert 8.8.8.8 # Windows # Step 7 — Is it intermittent? Collect live stats mtr -r -c 100 8.8.8.8
ℹ  If Step 3 fails but Step 1 and 2 pass, the problem is your router or switch — not your machine. If Step 4 fails but Step 3 passes, the problem is beyond your gateway (ISP). If Step 5 fails but Step 4 passes, it's a DNS problem only.
03 — Scenario Walkthroughs
SCENARIO 01 "The website is down" — but is it really?
1
Ping the domain
First, check if the host responds at all.
ping -c 4 example.com
✓ If ping succeeds — the host is up and reachable. The problem is at the application layer (HTTP, port 443), not the network. Try curl or your browser's developer tools.
✗ If ping fails — either the host is down, ICMP is blocked, or DNS isn't resolving. Continue below.
2
Check if DNS resolves
Ping by IP to separate the DNS question from the routing question.
dig example.com +short # or nslookup example.com
✗ If dig returns nothing or NXDOMAIN — it's a DNS failure. Test against a known-good resolver: dig @8.8.8.8 example.com +short. If that works, your local DNS server is the problem.
3
Ping the IP directly
Once you have the IP from dig, ping it directly.
ping -c 4 93.184.216.34
✓ IP ping succeeds, domain ping failed → pure DNS issue.
✗ IP ping also fails → the host is unreachable or ICMP is blocked. Run mtr to see where the path breaks.
4
Trace the path
Find exactly where packets stop.
mtr -r -c 50 93.184.216.34
Look for: the last hop that responds before all ??? rows. That's where the problem is. If the last responding hop is inside your ISP, call them.
SCENARIO 02 Slow connection — finding where the latency is
1
Baseline with ping
Establish current RTT and loss.
ping -c 20 8.8.8.8
Look for: high average RTT, high stddev (jitter), or any packet loss. If RTT to 8.8.8.8 is above 100 ms and you're on a local network, something is wrong before you reach the internet.
2
Narrow it down with mtr
Run a live trace with enough cycles to catch intermittent issues.
mtr -r -c 200 -n 8.8.8.8
HOST: myhost Loss% Snt Avg StDev 1.|-- 192.168.1.1 0.0% 200 1.1 0.2 ← gateway: fine 2.|-- 10.20.0.1 0.0% 200 2.3 0.3 ← ISP edge: fine 3.|-- 62.40.0.1 18.0% 200 94.2 38.1 ← PROBLEM HERE 4.|-- 8.8.8.8 18.0% 200 96.1 39.4
Look for: the hop where Loss% first appears and where StDev spikes. In this example, hop 3 (62.40.0.1) is the culprit — 18% loss and 38 ms jitter. Everything after inherits that problem. This is an ISP issue.
3
Rule out your own network
If hop 1 (your gateway) shows loss or high RTT, the problem is inside your LAN.
# Check your gateway RTT ping -c 20 192.168.1.1 # Check for ARP issues to the gateway ip neigh show | grep 192.168.1.1
Look for: STALE or FAILED state on the gateway ARP entry, or RTT above 5 ms to the gateway (which should be sub-millisecond on a wired LAN).
SCENARIO 03 Email not delivering — diagnosing DNS mail records
1
Check MX records
Verify the domain's mail servers are correctly configured.
dig example.com MX +short # or nslookup -type=MX example.com
Look for: MX records pointing to the correct mail server. Missing MX records mean no mail server is configured. Multiple MX records should have correct priority values (lower = higher priority).
# Expected output 10 mail.example.com. 20 mail2.example.com.
2
Verify SPF record
A missing or wrong SPF record causes receiving servers to reject or spam-flag your email.
dig example.com TXT +short | grep spf
# Healthy SPF record looks like: "v=spf1 include:_spf.google.com ~all"
✗ No SPF record, or one that doesn't include your sending server → your outbound mail will fail SPF checks and likely land in spam.
3
Check DMARC
DMARC tells receivers what to do with SPF/DKIM failures.
dig _dmarc.example.com TXT +short
Look for: a record starting with v=DMARC1. If it's missing, receiving servers have no policy guidance and may handle failures inconsistently.
4
Confirm MX host resolves and is reachable
The MX hostname must have an A record, and port 25 must be open.
dig mail.example.com A +short ping -c 3 mail.example.com
SCENARIO 04 Two devices can't talk on the same LAN
1
Confirm both have IPs on the same subnet
# On each machine ip addr show # Linux ifconfig # macOS ipconfig # Windows
Look for: both IPs should be in the same subnet (e.g. 192.168.1.x/24). If one is 169.254.x.x it has a self-assigned APIPA address — DHCP failed on that machine.
2
Check for ARP entry
If there's no ARP entry, the machines aren't communicating at Layer 2 at all.
# Try to ping first to trigger ARP ping -c 2 192.168.1.20 # Then check the ARP table ip neigh show arp -a # macOS / Windows
Look for: an entry for the target IP. If it shows FAILED or is completely absent, the Layer 2 path is broken — check switch port, VLAN membership, or cable.
3
Check for IP conflicts with arping
Two devices on the same IP will cause random connectivity failures.
sudo arping -c 5 192.168.1.20
Look for: if you see two different MAC addresses replying to the same IP, you have an IP conflict. One of the devices must be reconfigured.
# Conflict output example: ARPING 192.168.1.20 60 bytes from aa:bb:cc:11:22:33 (192.168.1.20) 60 bytes from dd:ee:ff:44:55:66 (192.168.1.20) ← CONFLICT!
4
Flush stale ARP and retry
sudo ip neigh flush all # Linux netsh interface ip delete arpcache # Windows
Then ping again. Stale ARP entries pointing to a wrong or old MAC address can block communication even when everything else is fine.
SCENARIO 05 Intermittent drops — ruling out each layer
1
Long-running ping to your gateway
Run this for several minutes while the issue occurs.
ping -i 0.5 192.168.1.1 | tee /tmp/ping_gw.log
Look for: any Request timeout lines. If you see drops to your own gateway, the problem is your local network or device — not the internet. Check Wi-Fi signal, cable, or the gateway itself.
2
Simultaneous ping to gateway AND internet
Run both at the same time in separate terminals.
# Terminal 1 — local gateway ping -i 1 192.168.1.1 # Terminal 2 — internet ping -i 1 8.8.8.8
Look for: if drops happen on internet but not on gateway → ISP problem. If drops happen on both → your LAN or gateway is the fault.
3
Confirm with mtr over time
mtr -r -c 500 -n 8.8.8.8
Look for: any hop with Loss% above 0. Cross-reference with the gateway ping — if your gateway is clean but a specific ISP hop shows loss, you have solid evidence to present to your ISP.
4
Test for DNS-specific drops
Sometimes connectivity drops are actually DNS timeouts, not network drops.
# Time a DNS query — should be under 50ms time dig google.com @8.8.8.8 +short # Compare against your default resolver time dig google.com +short
Look for: if the query to 8.8.8.8 is fast but your default resolver is slow or times out, switch your DNS server. On Linux edit /etc/resolv.conf; on Windows use ipconfig /flushdns after changing DNS in adapter settings.
SCENARIO 06 No internet after network change / reconfiguration
1
Check interface is up and has an IP
ip addr show # Linux ipconfig /all # Windows
Look for: a valid IP (not 169.254.x.x). If missing, DHCP failed — try renewing: sudo dhclient eth0 (Linux) or ipconfig /renew (Windows).
2
Check the default route
ip route show # Linux / macOS route print # Windows
Look for: a line starting with default via pointing to your gateway IP. If it's missing entirely, you have no default route — traffic has nowhere to go. Add it temporarily: sudo ip route add default via 192.168.1.1
3
Verify which route would be taken
ip route get 8.8.8.8
# Expected output 8.8.8.8 via 192.168.1.1 dev eth0 src 192.168.1.50
Look for: the correct gateway and interface. If it shows a wrong interface or gateway, you have a stale or misconfigured route — delete and re-add the default route.
4
Flush DNS cache after reconfiguration
ipconfig /flushdns # Windows sudo systemd-resolve --flush-caches # Linux (systemd) sudo dscacheutil -flushcache # macOS
After any IP or DNS change, always flush the local DNS cache. Stale entries can make it appear that sites are still unreachable even after the network is fixed.
04 — Tool Summary: What to Reach For
SymptomFirst toolFollow up with
Can't reach any siteping gatewayip addr, ip route, traceroute
Can reach IP, not domaindig / nslookupdig @8.8.8.8 to isolate resolver
Slow or laggy connectionping 8.8.8.8mtr -r -c 100
Intermittent dropsmtr -r -c 200Parallel pings to gateway + internet
Two LAN hosts can't talkip addr (check subnets)arp / arping for Layer 2
Email delivery failuredig MXdig TXT (SPF/DKIM/DMARC)
No internet after reconfigipconfig / ip addrip route, ipconfig /renew
Suspected IP conflictarping -c 5 <ip>Check for two MAC replies
DNS slow / timing outtime dig @8.8.8.8Compare default vs public resolver
Path breaks at specific hoptraceroute -nmtr for sustained statistics
ℹ  Golden rule: always test with a known-good reference. Ping 8.8.8.8 (not just a domain) to separate IP routing from DNS. Query @8.8.8.8 directly to separate resolver problems from DNS record problems. Compare your results against a second machine on the same network.