Tutorials · Troubleshooting

How to Troubleshoot Network Problems With Ping, Traceroute and MTR

Find where a connection breaks or slows down in minutes. Use ping for reachability and loss, traceroute for the path, and MTR to see loss and latency on every hop at once.

Beginner12 min7 steps

Before you start

  • A laptop or server on the affected network
  • Windows, macOS or Linux (MTR: apt install mtr-tiny, or WinMTR on Windows)
  • The IP address or hostname that users cannot reach

Step by step

  1. Start from the inside out

    Test in this order: your own gateway, a server in the same building, a server at another site, then an Internet address. The first test that fails tells you which part of the network to look at.

    ping -c 20 10.1.10.1      # default gateway
ping -c 20 10.1.20.15     # local server
ping -c 20 10.2.10.1      # remote site gateway
ping -c 20 1.1.1.1        # Internet

  2. Read loss and latency, not just 'reply'

    Look at the summary line. On a wired LAN, expect 0% loss and under 1 ms. Over Wi-Fi expect 1–5 ms. Loss of 1% or more, or jitter (big differences between min and max), points to a problem even when the ping 'works'.

    --- 10.1.20.15 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss
rtt min/avg/max/mdev = 0.312/0.401/0.622/0.071 ms

  3. Follow the path with traceroute

    Traceroute lists every router between you and the target. -n skips name lookups so it runs faster. On Windows the command is tracert -d.

    traceroute -n 10.2.30.40
# Windows:
tracert -d 10.2.30.40

  4. Use MTR for the full picture

    MTR repeats traceroute continuously and shows loss and latency for each hop. Run at least 100 cycles in report mode and save the output for your ticket or ISP.

    mtr -rwzbc 100 10.2.30.40
# -r report  -w wide  -z AS numbers  -b names+IPs  -c 100 cycles

  5. Read the MTR report correctly

    Loss that appears on one hop but NOT on the hops after it is usually only that router limiting ICMP replies: ignore it. Loss that starts at one hop and continues to the final destination is real, and it begins at that hop or the link just before it.

  6. Test with the real protocol

    Some firewalls block ICMP but allow the application. Test the actual TCP port so you know whether the service itself answers.

    nc -vz 10.2.30.40 443
# Windows PowerShell:
Test-NetConnection 10.2.30.40 -Port 443

  7. Write down what you found

    Record the time, source, destination, loss % and the hop where problems start. That turns 'the network is slow' into a fault you can fix or send to the ISP.

Commands are generic, industry-standard examples. Exact syntax and menu names vary by model and firmware; check your device's manual on the Documentation page.

Pro tips

  • Run tests in both directions: a problem on the return path does not show up in a one-way traceroute.
  • Ping with a large packet (ping -s 1400) to reveal problems that small packets hide.
  • Keep a baseline: save an MTR to key sites when everything works, so you can compare during an outage.

FAQ

Frequently asked questions

Why do I see * * * in traceroute?

That hop did not answer the probe, often because of a firewall or ICMP rate limit. If later hops answer, the path is fine.

Ping works but the application is slow. Why?

Ping only proves basic reachability. Check the real port with nc or Test-NetConnection, then look at DNS, server load and packet loss under load (iperf3).

Keep learning

Related guides

Test network speed with iperf3

Read more →

Find why the network is slow

Read more →

Port mirroring for troubleshooting

Read more →

How to Capture and Read Network Traffic With Wireshark and tcpdump

When logs are not enough, look at the packets. Capture traffic with tcpdump or Wireshark, filter it down to the problem, and spot retransmissions, DNS failures, DHCP issues and TLS errors.

Read more →

How to Test Network Speed Between Two Points With iperf3

Internet speed tests do not tell you how fast your LAN, Wi-Fi or site-to-site link really is. iperf3 measures throughput, loss and jitter between two machines you control.

Read more →

How to Troubleshoot DNS Problems With dig and nslookup

'The Internet is down' is often DNS. Learn to check which DNS server a device uses, query records directly, compare answers and clear caches.

Read more →

Stuck on a step?

Ask Navijin technical support or an authorised partner for help with your configuration.

Contact technical supportAll tutorials