Share via


Using the pathping command

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Using the pathping command

The pathping command is a route tracing tool that combines features of the ping and tracert commands with additional information that neither of those tools provides. The pathping command sends packets to each router on the way to a final destination over a period of time, and then computes results based on the packets returned from each hop. Since the command shows the degree of packet loss at any given router or link, it is easy to determine which routers or links might be causing network problems. A number of switches are available, as shown in the following table.

Switch Name Function

-n

Hostnames

Does not resolve addresses to host names.

-h

Maximum hops

Maximum number of hops to search for target.

-g

Host-list

Loose source route along host list.

-p

Period

Number of milliseconds to wait between pings.

-q

Num_queries

Number of queries per hop.

-w

Timeout

Waits this many milliseconds for each reply.

-T

Layer Two tag

Attaches a Layer Two priority tag (for example, for IEEE 802.1p) to the packets and sends it to each of the network devices in the path. This helps in identifying the network devices that do not have Layer Two priority configured properly. The -T switch is used to test for Quality of Service (QoS) connectivity.

-R

RSVP test

Checks to determine whether each router in the path supports the Resource Reservation Protocol (RSVP), which allows the host computer to reserve a certain amount of bandwidth for a data stream.

The default number of hops is 30, and the default wait time before a time-out is 3 seconds. The default period is 250 milliseconds, and the default number of queries to each router along the path is 100.

The following is a typical pathping report. The compiled statistics that follow the hop list indicate packet loss at each individual router.

D:\>pathping -n microsoft

Tracing route to microsoft [157.54.1.196]
over a maximum of 30 hops:
  0  172.16.87.35
  1  172.16.87.218
  2  192.168.52.1
  3  192.168.80.1
  4  157.54.247.14
  5  157.54.1.196

Computing statistics for 125 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           172.16.87.35
                                0/ 100 =  0%   |
  1   41ms     0/ 100 =  0%     0/ 100 =  0%  172.16.87.218
                               13/ 100 = 13%   |
  2   22ms    16/ 100 = 16%     3/ 100 =  3%  192.168.52.1
                                0/ 100 =  0%   |
  3   24ms    13/ 100 = 13%     0/ 100 =  0%  192.168.80.1
                                0/ 100 =  0%   |
  4   21ms    14/ 100 = 14%     1/ 100 =  1%  157.54.247.14
                                0/ 100 =  0%   |
  5   24ms    13/ 100 = 13%     0/ 100 =  0%  157.54.1.196

Trace complete.

When pathping is run, you first see the results for the route as it is tested for problems. This is the same path that is shown by the tracert command. The pathping command then displays a busy message for the next 125 seconds (this time varies by the hop count). During this time, pathping gathers 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=Pct and Address--contain the most useful information. The link between 172.16.87.218 (hop 1), and 192.168.52.1 (hop 2) is dropping 13 percent of the packets. All other links are working normally. The routers at hops 2 and 4 also drop packets addressed to them (as shown in the This Node/Link column), but this loss does not affect their forwarding path.

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 might be overloaded. These congested routers might also be a factor in end-to-end problems, especially if packets are forwarded by software routers.