TCP/IP Troubleshooting
TCP/IP Troubleshooting |
|
The PathPing tool is a route tracing tool that combines features of Ping and Tracert with additional information that neither of those tools provides. PathPing 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 PathPing shows the degree of packet loss at any given router or link, you can pinpoint which routers or links might be causing network problems. A number of switches are available, as shown in Table 3.9.
Table 3.9 PathPing Switches
| Switch | Name | Function |
|---|---|---|
| -n | Host names | Does not resolve addresses to host names. |
| -h <Max hops> | Maximum hops | Maximum number of hops to search for target. |
| -g <destination address> <router IP addresses or NetBIOS names> | Router -list | Use a loose source route along host-list. |
| -p <milliseconds> | Period | Number of milliseconds to wait between pings. |
| -q <Number queries> | Num_queries | Number of queries per hop. |
| -R | RSVP test | Checks to see if 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 -R switch is used to test for Quality of Service (QoS) connectivity. |
| -T | Layer 2 tag | Attaches a layer 2 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 2 priority configured properly. The -T switch is used to test for Quality of Service (QoS) connectivity. |
| -w <milliseconds> | Time-out | Waits this many milliseconds for each reply. |
The default number of hops is 30, and the default wait time before a time-out is three seconds (3000 milliseconds). The default period is 250 milliseconds, and the default number of queries to each router along the path is 100.
Below is a typical PathPing report. Note that the compiled statistics that follow the hop list indicate packet loss at each individual router.
D:\>pathping -n testpc1
Tracing route to testpc1 [7.54.1.196]
over a maximum of 30 hops:
0 172.16.87.35
1 172.16.87.218
2 192.68.52.1
3 192.68.80.1
4 7.54.247.14
5 7.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.68.52.1
0/ 100 = 0% |
3 24ms 13/ 100 = 13% 0/ 100 = 0% 192.68.80.1
0/ 100 = 0% |
4 21ms 14/ 100 = 14% 1/ 100 = 1% 7.54.247.14
0/ 100 = 0% |
5 24ms 13/ 100 = 13% 0/ 100 = 0% 7.54.1.196
Trace complete.
When PathPing is run, the first results you see list the route as it is tested for problems. This is the same path that is shown via Tracert. PathPing then displays a busy message for the next 125 seconds (this time varies by the hop count, requiring 25 seconds per hop). 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=%" and "Address" — contain the most useful information. The link between 172.16.87.218 (hop 1), and 192.68.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 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.
The raw data that PathPing obtains describes how many ICMP Echo Requests are lost between the source and an intermediate router. Figure 3.1 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).
Figure 3.1 Packet Delivery Paths
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.
