One of the most valuable troubleshooting tools to check connectivity is ping.
It can quickly tell you whether systems are up and operational and if
you are able to resolve names to IP addresses. The basic syntax is
or
Tip
If the pinged system responds, you know the system
is operational. However, if the pinged system doesn’t respond, it
doesn’t necessarily mean that it is not operational. The remote
system’s firewall, or a firewall between your system and the remote
system, can block ICMP requests.
If you ping the hostname, the first thing that ping
does is resolve the name to an IP address. This can be valuable to
determine whether name resolution works. As an example, consider the
following ping command and its output:
C:\>ping dc1
pinging DC1.Pearson.pub [192.168.1.10] with 32 bytes of data:
Reply from 192.168.1.10: bytes=32 time=1ms TTL=128
Reply from 192.168.1.10: bytes=32 time<1ms TTL=128
Reply from 192.168.1.10: bytes=32 time<1ms TTL=128
Reply from 192.168.1.10: bytes=32 time<1ms TTL=128
ping statistics for 192.168.1.10:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms
Note
Because the system is a member of the pearson.pub
domain, the pearson.pub suffix is appended to the hostname of dc1,
giving a fully qualified domain name (FQDN) of dc1.pearson.pub.
Notice that the first line shows that
DC1.Pearson.pub has been resolved to 192.168.1.10. In this domain, it
is resolved by DNS, but it can also be resolved from the hosts file,
the lmhosts file, WINS, or a broadcast.
You can get a few different errors from ping, as shown in the following table.
| Error | Example | Remarks |
|---|
| Could not find host. | C:\>ping dc99
Ping request could not find host
dc99. Please check the name and
try again.
| Name
resolution methods cannot resolve the name to an IP address. This
commonly means that the name is not known by the DNS server. |
| Request timed out. | C:\>ping 192.168.1.1
pinging 192.168.1.1 with 32 bytes
of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
ping statistics for 192.168.1.1:
Packets: Sent = 4, Received =
0, Lost = 4 (100% loss),
| This
indicates that the system is not responding. It can be because the
system is not operational; however, the ping could also be blocked by a
firewall. |
| Destination host unreachable. | C:\>ping 192.168.3.10
pinging 192.168.3.10 with 32
bytes of data:
Reply from 192.168.1.11:
Destination host unreachable.
Reply from 192.168.1.11:
Destination host unreachable.
Reply from 192.168.1.11:
Destination host unreachable.
Reply from 192.168.1.11:
Destination host unreachable.
ping statistics for 192.168.3.10:
Packets: Sent = 4, Received =
4, Lost = 0 (0% loss),
| This
often indicates that the default gateway on the local system or the
remote system is not configured correctly. The default gateway should
be on the same subnet. |
Note
You might occasionally see the first reply timeout
but other replies succeed. This can be due to delays with routers and
the time it takes for ARP to get the MAC address.
Another error you might read about but rarely see is
TTL Expired in Transit. The TTL value determines the maximum amount of
time an IP packet can live in the network without reaching its
destination. If you have networking problems with routers and routes on
your network, a ping might get caught in a routing loop and expire on
the wire, causing this error.
It’s important to reiterate that a Request Timed Out
error doesn’t necessarily indicate the system is not operational. The
firewall setting might be preventing a ping. You can ensure that the
firewall is allowing ICMP ping requests with netsh, as shown in the following table.
| Enable and Disable ping in the Firewall | Comments |
|---|
C:\>netsh firewall set
icmpsetting 8
IMPORTANT: Command executed successfully.
However, "netsh firewall"
is deprecated;
use "netsh advfirewall
firewall" instead.
| Enables echo requests.
Note
The netsh firewall
commands have been deprecated in Windows Server 2008 R2but not Windows
Server 2008. The system complains to you if you use them, but they do
work.
|
C:\>netsh firewall set
icmpsetting 8 disable
| Disables echo requests. |
C:\>netsh advfirewall
firewall add rule name =
"allow icmp incoming v4
echo request" protocol =
icmpv4:8,any dir = in
action = allow
Ok.
| You can use the netsh advfirewall firewall command to create a rule. This rule also enables echo requests.
Note
This command works on both Windows Server 2008 and Windows Server 2008 R2.
|
C:\>netsh advfirewall
firewall delete rule name
= "allow icmp incoming v4
echo request"
Deleted 1 rule(s).
Ok.
| Deletes the advfirewall rule. |
ping supports several switches, many of which are shown in the following table.
| ping Switches | Comments |
|---|
| You can use the -t switch to have ping continue pinging the specified host until you stop it. You can stop it by pressing Ctrl+C.
While it’s running, you can press the Ctrl+Break keys to view statistics. |
-n
ping name-or-IP-address -n number-of-
echoes
C:\>ping 192.168.1.10 -n 10
| You can specify the number of echo requests to send with the -n switch. By default, four ping echo requests are sent, but you can give a number such as 10 to send 10 instead. |
-a
C:\>ping -a 192.168.1.10
| The -a
switch can be used to resolve addresses to hostnames. This requires a
reverse lookup zone and an associated PTR (pointer) record on the DNS
server, so it won’t always work. |
-l
ping name-or- IP-address -l packet-size
C:\>ping 192.168.1.10 -l 64
| You can change the size of the ping packet with -l (a lowercase “el,” not the number 1). The size is specified in bytes and the default size is 32 bytes. |
-i
ping name-or- IP-address -i new-TTL
C:\>ping 192.168.1.10 -i 10
| You can modify the TTL with the -i switch. The default is 128. |
-4
ping name -4
C:\>ping dc1 -4
| You can use the -4 switch to force ping to use IPv4. |
-6
ping name -6
C:\>ping dc1 -6
| You can use the -6 switch to force ping to use IPv6. |
You can also ping using the IPv6 address. For
example, the following listing shows the output when pinging the IPv6
link-local address of another computer:
C:\>ping fe80::c065:e623:4104:1469
Pinging fe80::c065:e623:4104:1469 from fe80::84e0:3272:e623:21c6%10 with
32 bytes of data:
Reply from fe80::c065:e623:4104:1469: time=7ms
Reply from fe80::c065:e623:4104:1469: time=2ms
Reply from fe80::c065:e623:4104:1469: time=1ms
Reply from fe80::c065:e623:4104:1469: time=3ms
Ping statistics for fe80::c065:e623:4104:1469:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 7ms, Average = 3ms
Tip
You can verify the operation of IPv6 on a remote computer by pinging its link-local address. You can use ipconfig /all on any computer to identify its link-local IPv6 address.
