Pathping is one of two network utilities I am aware of that produces network path-loss statistics. The other one is mtr which is available for both Windows and Linux. The two utilities are very similar, and here we’ll talk about pathping.
Pathping is developed and maintained by Microsoft, and it’s built into Windows. As the name implies, it’s a combination of tracepath (or traceroute) and ping. Both are based on ICMP packets. Tracerpath gives you the hop-by-hop information between two hosts. Ping gives you statistics when you send ICMP requests to a specific host. Pathping gives you the hop-by-hop information as well as statistics for each hop.
Usage
Pathping is preinstalled on Windows. I think this is a significant difference with mtr, that you’d need to compile under Cygwin, which is kind of a hassle.
Here is the output of the help menu:
netbeez> pathping --help
--help is not a valid command option.
Usage: pathping [-g host-list] [-h maximum_hops] [-i address] [-n]
[-p period] [-q num_queries] [-w timeout]
[-4] [-6] target_name
Options:
-g host-list Loose source route along host-list.
-h maximum_hops Maximum number of hops to search for target.
-i address Use the specified source address.
-n Do not resolve addresses to hostnames.
-p period Wait period milliseconds between pings.
-q num_queries Number of queries per hop.
-w timeout Wait timeout milliseconds for each reply.
-4 Force using IPv4.
-6 Force using IPv6.
The options are pretty self explanatory.
Another significant different with mtr is that mtr is more feature rich if we judge from mtr’s available options:
netbeez> mtr.exe --help
Usage:
mtr [options] hostname
-F, --filename FILE read hostname(s) from a file
-4 use IPv4 only
-6 use IPv6 only
-u, --udp use UDP instead of ICMP echo
-T, --tcp use TCP instead of ICMP echo
-I, --interface NAME use named network interface
-a, --address ADDRESS bind the outgoing socket to ADDRESS
-f, --first-ttl NUMBER set what TTL to start
-m, --max-ttl NUMBER maximum number of hops
-U, --max-unknown NUMBER maximum unknown host
-P, --port PORT target port number for TCP, SCTP, or UDP
-L, --localport LOCALPORT source port number for UDP
-s, --psize PACKETSIZE set the packet size used for probing
-B, --bitpattern NUMBER set bit pattern to use in payload
-i, --interval SECONDS ICMP echo request interval
-G, --gracetime SECONDS number of seconds to wait for responses
-Q, --tos NUMBER type of service field in IP header
-e, --mpls display information from ICMP extensions
-Z, --timeout SECONDS seconds to keep probe sockets open
-r, --report output using report mode
-w, --report-wide output wide report
-c, --report-cycles COUNT set the number of pings sent
-j, --json output json
-x, --xml output xml
-C, --csv output comma separated values
-l, --raw output raw format
-p, --split split output
-t, --curses use curses terminal interface
--displaymode MODE select initial display mode
-n, --no-dns do not resolve host names
-b, --show-ips show IP numbers and host names
-o, --order FIELDS select output fields
-y, --ipinfo NUMBER select IP information in output
-z, --aslookup display AS number
-h, --help display this help and exit
-v, --version output version information and exit
A more rigorous comparison between the two might be a topic for another blog post…
Let’s look at an example of a pathping run:
netbeez> pathping google.com
Tracing route to google.com [142.250.191.46]
over a maximum of 30 hops:
0 host.docker.internal [172.31.0.222]
1 172.31.0.1
2 192.168.1.254
3 * 108-193-0-1.lightspeed.sntcca.sbcglobal.net [108.193.0.1]
4 71.148.135.196
5 cr2.sffca.ip.att.net [12.123.15.186]
6 sffca22crs.ip.att.net [12.122.3.70]
7 12.122.163.61
8 12.255.10.232
9 216.239.40.18
10 142.251.65.129
11 nuq04s42-in-f14.1e100.net [142.250.191.46]
Computing statistics for 275 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 host.docker.internal [172.31.0.222]
0/ 100 = 0% |
1 0ms 0/ 100 = 0% 0/ 100 = 0% 172.31.0.1
0/ 100 = 0% |
2 1ms 0/ 100 = 0% 0/ 100 = 0% 192.168.1.254
0/ 100 = 0% |
3 2ms 24/ 100 = 24% 24/ 100 = 24% 108-193-0-1.lightspeed.sntcca.sbcglobal.net [108.193.0.1]
0/ 100 = 0% |
4 2ms 24/ 100 = 24% 24/ 100 = 24% 71.148.135.196
0/ 100 = 0% |
5 --- 100/ 100 =100% 100/ 100 =100% cr2.sffca.ip.att.net [12.123.15.186]
0/ 100 = 0% |
6 --- 100/ 100 =100% 100/ 100 =100% sffca22crs.ip.att.net [12.122.3.70]
0/ 100 = 0% |
7 --- 100/ 100 =100% 100/ 100 =100% 12.122.163.61
0/ 100 = 0% |
8 --- 100/ 100 =100% 100/ 100 =100% 12.255.10.232
0/ 100 = 0% |
9 7ms 0/ 100 = 0% 0/ 100 = 0% 216.239.40.18
5/ 100 = 5% |
10 --- 100/ 100 =100% 95/ 100 = 95% 142.251.65.129
0/ 100 = 0% |
11 6ms 5/ 100 = 5% 0/ 100 = 0% nuq04s42-in-f14.1e100.net [142.250.191.46]
Trace complete.
Pathping first runs a tracepath to get the hop-by-hop IP information between my laptop and google.com. Then for each hop, it sends 100 packets with 250 milliseconds interval to calculate statistics. This amounts to 25 seconds per hop and a total of 275 seconds for 11 hops. As you can see, it might take a while for pathping to finish its run, but all these parameters are configurable (-p for period and -q for number of queries per hop), as you can see from the options in the help menu.
As you can see for each hop, you have statistics on latency and on how many packets were dropped out of the 100 that were sent. This can be very useful when troubleshooting performance issues, and can help identify specific hops along your route that might be causing the overall issue.
All in all, I think pathping is a very useful tool, it comes for free on Windows, and it’s on par with its Linux equivalent mtr.