Tuesday, February 15, 2022

Request timed out vs Destination host unreachable!

When we get the output of "Ping" as Request timed out or Destination host unreachable, we often think that the destination is down but the two outputs infer different meanings.

Here, we shall see the difference between the two from a user machine using Wireshark.

Below are the IP Address information from the "ipconfig" output :

When I ping the IP Address 192.168.1.10 which is part of my Wi-Fi Subnet, I get the reply from my Source IP Address, saying "Destination host unreachable".


Ping works on ICMP Echo Request and ICMP Echo Reply.

When we get the response from the same Source IP Address, here 192.168.1.9, it means the ICMP Echo Requests were not sent from that IP Address.

Let's see why did this happen?

If we take a look at Wireshark Capture, we see three ARP requests sent for each Ping utility used. Since there were no successful ARP resolution, the user machine did not forward the ICMP Packet to the destination as it does not know which MAC Address to send to [ARP is a protocol to resolve the destination MAC Address if the program is aware of the IP Address].


Now when I ping the IP Address that is not part of my subnet, say 192.168.56.100, I get "Request timed out" for each of the four ICMP Packets.


Let's check the Wireshark Capture. Here, we see four ICMP Echo Requests sent out but there is no response.
How long will "Ping" utility wait for a response? 
Default timeout for the ping response is 4000 milliseconds in windows machine.


We do not see ARP requests in this case. Why is that so? ARP queries were not sent from local machine as the destination 192.168.2.100 belongs to a different subnet.
When we have destination IP Address which is not part of the same subnet as source IP Address, the destination MAC address is selected that of the default gateway [Default Gateway is the IP Address that is usually configured in a router or any L3 device that forwards the traffic to a different subnet].

Below screenshot has ARP for my default gateway 192.168.1.1 as 1c-18-4a-45-62-00 which can also be seen in the above screenshot Layer-2 information.


There can be different reasons why the response was not received by the user machine.

The ARP queries from the default gateway of 192.168.2.0 subnet were timed out.
The required routes for 192.168.2.0 subnet are configured wrong in the next hop Layer-3 device, that is 192.168.1.1.
If there is a network congestion, ICMP Packets are least preferred in some Layer-3 device and could be discarded.


3 comments:

Traceroute from Linux OS [In-depth analysis using Wireshark]

Here we will see the packets associated with traceroute when run on Linux OS. Below is the output of traceroute to yahoo.com IP Address 74.6...