PATHPING: An oft overlooked tool for the Networks Guy

There’s a little known tool that’s provided as part of a Windows installation, it’s certainly available under XP and Vista which seems to be overlooked in Network troubleshooting.

Called pathping, it’s a command-line utility that will help you to troubleshoot intermediate hops between your source and a destination host. Something of a combination of ping and tracert (or traceroute for the *Nix users out there).

Tracert will show the intermediate hops between you and a destination, together with the link latency, and packet loss rate. In other words it will very likely show you where a problem lies between two nodes on the network.

The command itself takes some minutes to run, dependant of course on the number of hops between you and a destination host. The below example takes for me 475 seconds to run because Google is 10 hops away, via my corporate internet connection. Sample output is shown below (but of course the IP Addresses have been changed to protect the innocent!)

Usage is simply pathping [destination host or IP]

C:\>pathping www.google.com
Tracing route to www.l.google.com [64.233.183.104] over a maximum of 30 hops:
0  mydesktoppc [192.168.1.10]
1  mydefaultgw [192.168.1.254]
2  internal-local-ce-router-01 [10.0.0.1]
3  service-provider-pe-router-01 [172.16.1.10]
4  internal-remote-ce-router-01 [172.17.24.1]
5  remote-core-switch-01 [192.168.254.254]
6  remote-inner-perimiter-firewall [192.168.0.100]
7  rate-shaping-switch-perimiter [192.168.74.12]
8  remote-outer-perimiter-firewall [192.168.75.6]
9  isp-router
10  unspecified-00.ukcore.bt.net [1.2.3.4]
11  unspecified-01.ukcore.bt.net [2.3.4.5]
12  unspecified-02.ukcore.bt.net [3.4.5.6]
13  195.99.125.82
14  209.85.255.175
15  66.249.95.130
16  64.233.175.246
17  72.14.233.79
18  216.239.43.34
19  nf-in-f104.google.com [64.233.183.104]

Computing statistics for 475 seconds...
Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
0                                           mydesktoppc [192.168.1.10]
0/ 100 =  0%   |
1    0ms     0/ 100 =  0%     0/ 100 =  0%  mydefaultgw [192.168.1.254]
0/ 100 =  0%   |
2    0ms     0/ 100 =  0%     0/ 100 =  0%  internal-local-ce-router-01 [10.0.0.1]
0/ 100 =  0%   |
3    6ms     2/ 100 =  2%     2/ 100 =  2%  service-provider-pe-router-01 [172.16.1.10]
0/ 100 =  0%   |
4   11ms     0/ 100 =  0%     0/ 100 =  0%  internal-remote-ce-router [172.17.24.1]
0/ 100 =  0%   |
5   12ms     0/ 100 =  0%     0/ 100 =  0%  remote-core-switch-01 [192.168.254.254]
0/ 100 =  0%   |
6   12ms     0/ 100 =  0%     0/ 100 =  0%  remote-inner-perimiter-firewall [192.168.0.100]
0/ 100 =  0%   |
7   12ms     0/ 100 =  0%     0/ 100 =  0%  rate-shaping-switch-perimiter [192.168.74.12]
0/ 100 =  0%   |
8   13ms     0/ 100 =  0%     0/ 100 =  0%  remote-outer-perimiter-firewall [192.168.75.6]
0/ 100 =  0%   |
9   22ms     0/ 100 =  0%     0/ 100 =  0%  isp-router
0/ 100 =  0%   |
10   21ms     0/ 100 =  0%     0/ 100 =  0%  unspecified-00.ukcore.bt.net [1.2.3.4]
0/ 100 =  0%   |
11   21ms     0/ 100 =  0%     0/ 100 =  0%  unspecified-01.ukcore.bt.net [2.3.4.5]
0/ 100 =  0%   |
12   22ms     0/ 100 =  0%     0/ 100 =  0%  unspecified-02.ukcore.bt.net [3.4.5.6]
0/ 100 =  0%   |
13   29ms     0/ 100 =  0%     0/ 100 =  0%  195.99.125.82
0/ 100 =  0%   |
14   26ms     0/ 100 =  0%     0/ 100 =  0%  209.85.255.175
0/ 100 =  0%   |
15   26ms     3/ 100 =  3%     3/ 100 =  3%  66.249.95.130
0/ 100 =  0%   |
16   37ms     0/ 100 =  0%     0/ 100 =  0%  64.233.175.246
0/ 100 =  0%   |
17   34ms     0/ 100 =  0%     0/ 100 =  0%  72.14.233.79
0/ 100 =  0%   |
18   39ms     0/ 100 =  0%     0/ 100 =  0%  216.239.43.34
1/ 100 =  1%   |
19   35ms     1/ 100 =  1%     0/ 100 =  0%  nf-in-f104.google.com [64.233.183.104]
Trace complete.

So what is the output showing?

In this case I’m loosing 2% of packets getting to my service-provider-pe-router-01 and a further 3% at one of the later hops (probably a network interconnect) later down the chain.

When PathPing is executed, first section shows the route for the traffic, as would be shown by Tracert.

PathPing then displays a busy message which will vary based on 25 seconds per hop to the destination, during which time it will gather information from all the routers previously listed and from the links between them. At the end of this period, it displays the test results.

The two rightmost columns — “This Node/Link Lost/Sent=%” and “Address” — contain the most useful information.

The loss rates displayed for the links (marked as a “|” in the rightmost column) indicate losses of packets being forwarded along the path. This loss indicates link congestion. The loss rates displayed for routers (indicated by their IP addresses in the rightmost column) indicate that those routers’ CPUs or packet buffers might be overloaded. These congested routers might also be a factor in end-to-end problems, especially if packets are forwarded by software routers.
Loss Calculation

The raw data that PathPing obtains describes how many ICMP Echo Requests are lost between the source and an intermediate router. The diagram below shows how PathPing estimates the per-hop loss statistics. While at first this calculation might seem trivial, it is complicated by differences between the forwarding code path and the code path taken in responding to ping packets (ICMP Echo Requests/Replies).

The horizontal lines indicate the “fast path” of a router, which is taken by packets that are not sent to or from the local computer. That is, the fast path is the code path taken by transit packets that require no special processing other than forwarding, and is highly optimized for such packets.

In the diagram, the vertical lines indicate the extra processing taken when an ICMP Echo Request is sent to the local computer. This kicks it out of the fast path and delivers it to an ICMP module (often using separate queues and processors). Assuming no packets are dropped due to queue overflows, the ICMP module then generates an ICMP Echo Reply, which is forwarded back to the original sender.

Since packet loss can occur in the path indicated by the vertical lines (but such loss does not necessarily imply loss on the horizontal forwarding path itself), the raw numbers obtained from pings do not by themselves determine end-to-end packet loss. For example, pinging an intermediate router might create a 10 percent loss even though no end-to-end packet loss is occurring. PathPing’s algorithm uses the change in values from hop-to-hop to estimate actual per hop loss rather than losses in the higher-level router components. This actual per hop loss is the result provided in the “This Node/Link” column of the final PathPing report.

Posted on July 4, 2011, in Networking, Technology. Bookmark the permalink. 2 Comments.

  1. How it calculates the This node/link losses? I didn’t got ya very well, I know that it sends icmp echo requests but how do I know that per hop loss ?

    • I believe it does a comparison from source to each hop one after another. If the loss rate jumps up between say the 5th and 6th hops. Not sure how that might affect hops later in the chain tho.

Leave a Reply