In case Ping is success.
When Ping is successful, it is displayed as follows.
Pinging 192.168.179.1 with 32 bytes of data:
Reply from 192.168.179.1: bytes=32 time=9ms TTL=64
Reply from 192.168.179.1: bytes=32 time=3ms TTL=64
Reply from 192.168.179.1: bytes=32 time=7ms TTL=64
Reply from 192.168.179.1: bytes=32 time=4ms TTL=64
Ping statistics for 192.168.179.1:Packets: Sent = 4、Received = 4、Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 3ms, Maximum = 9ms, Average = 5ms
If you sent "ICMP Echo Request" to dst IP and are received "ICMP Echo Reply" from the IP, it is displayed as above regarded as success.
"Lost = 0" means "In response to ICMP Echo Request transmitted multiple times (default 4 times in the above example), any kind of ICMP packet was received each time". I will describe it later, Even if it is not the ICMP Echo Reply from the destination IP (even in Destination Unreachable), if any ICMP packet is received, it will not be counted as a loss.
In case Ping is failed
The cause depends on the displayed result. If you can not understand below, please learn about the following two about ICMP.
about ICMP and ICMP type and codes
Request timed out
If this message is shown, it means "Although ICMP Echo Request was sent to the destination IP, the ICMP Echo Reply did not return for the timeout (default 3 seconds) elapsed"
In this state, it can not be determined whether ICMP Echo Request is packet loss in the middle of the route or ICMP Echo Reply is packet loss.
It is because there is a part where communication does not pass through the firewall etc of the NW device, or the ICMP is stopped by Windows firewall, firewalld, security software on the opposite host side.
Exceptionally, in the case of Ping within the same segment, it is displayed like this even if there is no ARP response from the destination host.
Destination Host Unreachable
If this message is shown, it means "Although ICMP Echo Request was sent to the destination IP, but the "Host Unreachable" code in "ICMP Destination Unreachable" is returned from the NW device in the middle of the route (instead of returning the ICMP Echo Reply packet from the destination IP).
Pinging 10.1.1.1 with 32 bytes of data:
Reply from 192.168.179.1: Destination Host Unreachable.
Reply from 192.168.179.1: Destination Host Unreachable.
Reply from 192.168.179.1: Destination Host Unreachable.
Reply from 192.168.179.1: Destination Host Unreachable.
Ping statistics for 10.1.1.1:
Packets: Sent = 4, Received = , Lost = 0 (0% loss)
Please pay attention to "Loss = 0". This is a problem of Windows expression, as mentioned above, it seems that it counts as reception if ICMP is returned and it is not counted as loss.
An exception is the case where "Reply from" is its own IP in Ping within the same segment, except when the timeout (1 second) of the ARP Request is before the Ping timeout Internally ICMP Destination Unreachable is generated for itself, and it seems that the above display is done.
If you add the option of -w 1001 (Ping timeout 1001 ms) to ping, "Request timed out" and "Destination host can not be reached" are seen alternately.
Pinging 192.168.179.15 with 32 bytes of data:
Request timed out.
Reply from 192.168.179.4: Destination Host Unreachable.
Request timed out.
Reply from 192.168.179.4: Destination Host Unreachable.
Ping statistics for 192.168.179.15:
Packets: Sent = 4, Received = 2, Lost = 2 (50% loss)
transmit failed. General Failure.
This is displayed when Windows can not send an ICMP Echo Request, but the reason is unknown. Whether timing problems or applications of security software were suppressing transmission, there are a variety of causes.
As an example, it will be displayed if
you change the IP of the interface while pinging with ping -t.
TTL expired in transit
When routing, decrease the value of TTL field of IP header by one. When a TTL = 1 packet arrives at the router and further routing is required (when the destination IP address is not the NW address connected to the NW device), TTL = 0, and the packet is discarded at the NW device It will be. At the time when it is discarded, ICMP Time Exceeded is notified to the source IP address from the NW device.
The cause of this case is usually a routing loop occurring somewhere. There is a possibility that "There are too many NW devices to go through", but now it is a good level to think that it is impossible.
If you want to check the occurrence of the routing loop, use tracert to investigate.
In case Ping response time is long
It does not take up to 3 seconds of timeout, but something is wrong when "ICMP Echo Reply returns over 1 second". It is a good idea to check which IP on the route is slow response
pathping, which Windows install default, is useful tool.
Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:
0 Host-A [192.168.179.4]
1 192.168.179.1
2 * * *
Computing statistics for 25 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 Host-A [192.168.179.4]
0/ 100 = 0% |
1 8ms 0/ 100 = 0% 0/ 100 = 0% 192.168.179.1
Trace complete.
コメント