Test Network Connection with Ping and PathPing
Ping is a tool that helps to verify IP-level connectivity; PathPing is a tool that detects packet loss over multiple-hop trips. When troubleshooting, the ping command is used to send an ICMP Echo Request to a target host name or IP address. Use Ping whenever you want to verify that a host computer can send IP packets to a destination host. You can also use the Ping tool to isolate network hardware problems and incompatible configurations.
If you call ipconfig /all and receive a response, there is no need to ping the loopback address and your own IP address — Ipconfig has already done so in order to generate the report.
It is best to verify that a route exists between the local computer and a network host by first using ping and the IP address of the network host to which you want to connect. The command syntax is:
ping < IP address >
Perform the following steps when using Ping:
Ping the loopback address to verify that TCP/IP is installed and configured correctly on the local computer.
If the loopback step fails, the IP stack is not responding. This might be because the TCP drivers are corrupted, the network adapter might not be working, or another service is interfering with IP.
Ping the IP address of the local computer to verify that it was added to the network correctly. Note that if the routing table is correct, this simply forwards the packet to the loopback address of 127.0.0.1.
ping < IP address of local host >
Ping the IP address of the default gateway to verify that the default gateway is functioning and that you can communicate with a local host on the local network.
ping < IP address of default gateway >
Ping the IP address of a remote host to verify that you can communicate through a router.
ping < IP address of remote host >
Ping the host name of a remote host to verify that you can resolve a remote host name.
ping < Host name of remote host >
Run a PathPing analysis to a remote host to verify that the routers on the way to the destination are operating correctly.
pathping < IP address of remote host >
If your local address is returned as 169.254.y.z, you have been assigned an IP address by the Automatic Private IP Addressing (APIPA) feature of Windows 2000. This means that the local DHCP server is not configured properly or cannot be reached from your computer, and an IP address has been assigned automatically with a subnet mask of 255.255.0.0. Enable or correct the DHCP server, restart the local computer, and see if the networking problem persists.
If your local address is returned as 0.0.0.0, the Microsoft MediaSense software override started because the network adapter detects that it is not connected to a network. To correct this problem, turn off MediaSense by making sure that the network adapter and network cable are connected to a hub. If the connection is solid, reinstall the network adapter's drivers or a new network adapter.
Ping uses host name resolution to resolve a computer name to an IP address, so if pinging by address succeeds, but fails by name, then the problem lies in host name resolution, not network connectivity. For more information about troubleshooting host name resolution, see "Unable to Reach a Host or NetBIOS Name" earlier in this chapter.
If you cannot use Ping successfully at any point, check the following:
The local computer's IP address is valid and appears correctly in the IP Address tab of the Internet Protocol ( TCP/IP) Properties dialog box or when using the Ipconfig tool.
A default gateway is configured and the link between the host and the default gateway is operational. For troubleshooting purposes, make sure that only one default gateway is configured. While it is possible to configure more than one default gateway, gateways beyond the first are only used if the IP stack determines that the original gateway is not functioning. Since the point of troubleshooting is to determine the status of the first configured gateway, delete all others to simplify your troubleshooting.
If the remote system being pinged is across a high-delay link such as a satellite link, responses might take longer to be returned. The -w (wait) switch can be used to specify a longer time-out. The following example shows a set of two pings, each 1450 bytes in size, that wait two seconds (2000 milliseconds) for a response before timing out.
C:\>ping -w 2000 -n 2 -l 1450 172.16.48.10
Pinging 172.16.48.10 with 1450 bytes of data:
Reply from 172.16.48.10: bytes=1450 time=1542ms TTL=32
Reply from 172.16.48.10: bytes=1450 time=1787ms TTL=32
Ping statistics for 172.16.48.10:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 10ms, Average = 1664ms
Clear ARP Cache
If you can ping both the loopback address and your own IP address, the next step is to clear out the ARP cache and reload it. This can be done by using the Arp utility, first to display the cache entries with arp -a or arp -g . Delete the entries with arp -d < IP address >.
Verify Default Gateway
Next, look at the default gateway. The gateway address must be on the same network as the local host; if not, no messages from the host computer can be forwarded to any location outside the local network. Next, check to make sure that the default gateway address is correct as entered. Finally, check to see that the default gateway is a router, not just a host, and that it is enabled to forward IP datagrams.
Ping Remote Host
If the default gateway responds correctly, ping a remote host to ensure that network-to-network communications are operating as expected. If this fails, use Tracert to examine the path to the destination. For IP routers that are Windows NT or Windows 2000 computers, use the route utility or the Routing and Remote Access administrative tool on those computers to examine the IP routing table. For IP routers that are not Windows NT or Windows 2000 computers, use the appropriate utility or facility to examine the IP routing table.
Four error messages are commonly returned by Ping during troubleshooting. They are:
TTL Expired in Transit
The number of hops required to reach the destination exceeds the TTL set by the sending host to forward the packets. The default TTL value for ICMP Echo Requests sent by Ping is 32. In some cases, this is not enough to travel the required number of links to a destination. You can increase the TTL using the -i switch, up to a maximum of 255 links.
If increasing the TTL value fails to resolve the problem, the packets are being forwarded in a routing loop, a circular path among routers. Use Tracert to track down the source of the routing loop, which appears as a repeated series of the same IP addresses in the Tracert report. Next, make an appropriate change to the routing tables, or inform the administrator of a remote router of the problem.
Destination Host Unreachable
This message indicates one of two problems: either the local system has no route to the desired destination, or a remote router reports that it has no route to the destination. The two problems can be distinguished by the form of the message. If the message is simply "Destination Host Unreachable," then there is no route from the local system, and the packets to be sent were never put on the wire. Use the Route utility to check the local routing table.
If the message is "Reply From < IP address >: Destination Host Unreachable," then the routing problem occurred at a remote router, whose address is indicated by the "< IP address >" field. Use the appropriate utility or facility to check the IP routing table of the router assigned the IP address of < IP address >.
If you pinged using an IP address, retry it with a host name to ensure that the IP address you tried is correct.
Request Timed Out
This message indicates that no Echo Reply messages were received within the default time of 1 second. This can be due to many different causes; the most common include network congestion, failure of the ARP request, packet filtering, routing error, or a silent discard. Most often, it means that a route back to the sending host has failed. This might be because the destination host does not know the route back to the sending host, or one of the intermediary routers does not know the route back, or even that the destination host's default gateway does not know the route back. Check the routing table of the destination host to see whether it has a route to the sending host before checking tables at the routers.
If the remote routing tables are correct and contain a valid route back to the sending host, to see if the ARP cache lacks the proper address, use the arp -a command to print the contents of the ARP cache. Also, check the subnet mask to be sure that a remote address has not been interpreted as local.
Next, use Tracert to follow the route to the destination. While Tracert does not record the address of the last hop or the path that the packet followed on the return path, it might show that the packet made it to the destination. If this is the case, the problem is probably a routing issue on the return path. If the trace doesn't quite reach the destination, it might be because the target host is protected by a firewall. When a firewall protects the destination, ICMP packet filtering prevents the ping packets—or any other ICMP messages—from crossing the firewall and reaching their destination.
To check for network congestion, simply increase the allowed latency by setting a higher wait time with the -w switch, such as 5000 milliseconds. Try to ping the destination again. If the request still times out, congestion is not the problem; an address resolution problem or routing error is a more likely issue.
This error message indicates that the requested host name cannot be resolved to its IP address; check that the name is entered correctly and that the DNS servers can resolve it.