ping, traceroute, pathping, mtr and tracepath

ping asks "are you there and how long does it take"; traceroute asks "which routers are between us". Between them they diagnose most connectivity complaints. The options differ by platform more than people expect.

ping

C:\>ping 1.1.1.1

Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=9ms TTL=57
Reply from 1.1.1.1: bytes=32 time=8ms TTL=57
Reply from 1.1.1.1: bytes=32 time=9ms TTL=57
Reply from 1.1.1.1: bytes=32 time=8ms TTL=57

Ping statistics for 1.1.1.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 8ms, Maximum = 9ms, Average = 8ms

$ ping -c 4 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=8.71 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=8.66 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=9.02 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=8.59 ms

--- 1.1.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 8.590/8.745/9.020/0.166 ms

Reading the numbers

• time / rtt: round trip in milliseconds. Under 1 ms on a LAN, 5 to 20 ms to a nearby CDN on fibre, 20 to 40 ms on cable or VDSL, 30 to 80 ms on 4G/5G, 500+ ms on satellite. Wide variation between packets (jitter, the mdev figure on Linux) hurts calls and games more than a high but steady value.
• TTL / ttl: the hop limit remaining. Replies start at 64 (Linux, macOS, most routers), 128 (Windows) or 255 (Cisco, Solaris), and each router subtracts one. ttl=57 from a host that started at 64 means seven hops away. This is also a crude OS fingerprint.
• Packet loss: anything above 0% on a wired LAN is a fault. On Wi-Fi occasional 1 to 2% is common; sustained loss means interference or weak signal. Loss on the internet path is normally an ISP or peering problem, but some routers rate-limit ICMP so a lossy ping to a router with clean pings through it is not a fault.

Error messages

tracert and traceroute

Both send packets with an increasing TTL (1, 2, 3, …). Each router that decrements the TTL to zero sends back an ICMP "time exceeded" message, revealing itself. Windows tracert uses ICMP echo; Unix traceroute uses UDP to high ports by default, which firewalls treat differently. That is why the two can show different results for the same path.

C:\>tracert -d 1.1.1.1

Tracing route to 1.1.1.1 over a maximum of 30 hops

  1     1 ms     1 ms     1 ms  192.168.1.1
  2    12 ms    11 ms    11 ms  172.16.14.1
  3     *        *        *     Request timed out.
  4    13 ms    12 ms    12 ms  109.159.252.34
  5    14 ms    13 ms    14 ms  195.99.126.190
  6    15 ms    14 ms    14 ms  141.101.71.60
  7     9 ms     9 ms     9 ms  1.1.1.1

Trace complete.

Reading a trace

• Hop 1 is your router. If it does not answer, the problem is on your LAN. If there is a second private-address hop, you have two routers (ISP hub plus your own, or CGNAT).
• A line of asterisks in the middle with later hops answering (hop 3 above) is a router that does not send ICMP time-exceeded. Harmless: the traffic still passes through it.
• Asterisks from some hop to the end mean either the destination filters ICMP (if ping also fails but the service works, this is it) or the path really is broken at that hop. The last responding hop is where to look.
• Latency that jumps and stays up at a hop is a long link (transatlantic cable adds about 70 ms). Latency that jumps at one hop and drops at the next is that router deprioritising ICMP; ignore it.
• The same addresses repeating is a routing loop.
• Timing 30 seconds per hop is name resolution of each hop; use -d or -n.

pathping (Windows)

pathping runs a trace, then pings every hop for 25 seconds each and reports per-hop loss. It takes several minutes but tells you where loss starts, which tracert cannot.

pathping -n 1.1.1.1
pathping -n -q 20 -p 250 1.1.1.1      # 20 queries per hop, 250 ms apart: faster

Computing statistics for 175 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           192.168.1.42
                                0/ 100 =  0%   |
  1    1ms     0/ 100 =  0%     0/ 100 =  0%  192.168.1.1
                                0/ 100 =  0%   |
  2   12ms     0/ 100 =  0%     0/ 100 =  0%  172.16.14.1
                               15/ 100 = 15%   |
  3   35ms    15/ 100 = 15%     0/ 100 =  0%  109.159.252.34

Read the This Node/Link column: loss on the | line between hops is loss on that link; loss at a node that does not carry through to later hops is just that router rate-limiting ICMP.

mtr (macOS, Linux)

mtr combines traceroute and continuous ping into one live display, and is the tool to reach for when a connection is "sometimes slow". Install with brew install mtr, apt install mtr-tiny or dnf install mtr.

sudo mtr 1.1.1.1                 # live display; q to quit
mtr -n 1.1.1.1                   # no DNS
mtr -rwc 100 1.1.1.1             # report mode: 100 cycles, wide, then exit (paste this into tickets)
mtr -T -P 443 example.com        # TCP mode to port 443
mtr -u 1.1.1.1                   # UDP mode
mtr -6 example.com
mtr -b 1.1.1.1                   # show both names and addresses
mtr -z 1.1.1.1                   # show AS numbers per hop

Start: 2026-09-18T10:41:02+0100
HOST: laptop                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                0.0%   100    0.8   0.9   0.6   3.1   0.3
  2.|-- 172.16.14.1                0.0%   100   11.2  11.5  10.8  19.4   1.1
  3.|-- ???                       100.0   100    0.0   0.0   0.0   0.0   0.0
  4.|-- 109.159.252.34             0.0%   100   12.4  12.7  11.9  22.0   1.4
  5.|-- 195.99.126.190             0.0%   100   13.9  14.1  13.2  31.7   2.2
  6.|-- 141.101.71.60              0.0%   100   14.4  14.9  13.8  40.2   3.5
  7.|-- 1.1.1.1                    0.0%   100    9.0   9.1   8.6  12.3   0.4

Interpretation rules are the same as pathping: loss that appears at one hop and persists to the destination is real; loss at one hop only is ICMP rate-limiting. Wrst spikes on the final hop with a low average are bufferbloat or Wi-Fi contention on your side rather than a fault on the path.

tracepath (Linux)

Needs no root and discovers the path MTU as it goes, which makes it the quickest MTU check on Linux.

tracepath 1.1.1.1
tracepath -n 1.1.1.1
tracepath6 2606:4700:4700::1111

 1?: [LOCALHOST]                      pmtu 1500
 1:  192.168.1.1                                           0.812ms
 2:  172.16.14.1                                          11.301ms pmtu 1492
 3:  no reply
 4:  109.159.252.34                                       12.550ms
 ...
     Resume: pmtu 1492 hops 7 back 7

The pmtu 1492 at hop 2 is the PPPoE link dropping the MTU from 1500. If your interface still says 1500, large packets to the internet rely on path MTU discovery working; if that is broken you get the classic half-loading symptoms.

PowerShell equivalents

Test-Connection 1.1.1.1 -Count 4
Test-Connection 1.1.1.1 -Quiet                # True/False
Test-Connection 1.1.1.1 -Repeat               # PowerShell 7: continuous
Test-Connection 1.1.1.1 -Traceroute           # PowerShell 7
Test-Connection 1.1.1.1 -MtuSize              # PowerShell 7: path MTU
Test-NetConnection example.com -TraceRoute
Test-NetConnection example.com -Port 443      # TCP connect test with the route it took
Test-NetConnection example.com -InformationLevel Detailed
1..254 | ForEach-Object -Parallel { if (Test-Connection "192.168.1.$_" -Count 1 -Quiet -TimeoutSeconds 1) { "192.168.1.$_" } }   # PS 7 sweep

Testing a port rather than a host

Test-NetConnection host -Port 443      # PowerShell
nc -zv host 443                        # macOS/Linux netcat
nc -zvu host 53                        # UDP (unreliable: no reply does not mean closed)
curl -v telnet://host:443              # curl as a port tester
timeout 3 bash -c '</dev/tcp/host/443' && echo open   # bash only, no tools needed
telnet host 443                        # if installed; blank screen = open, Ctrl+] then quit
nmap -p 22,80,443 host                 # proper scanner

Related pages

• Troubleshooting playbook
• MTU problems
• nslookup, dig and host
• netstat, ss and ports