I can tracert to an IP address, but not ping it

Question

On Windows, if I tracert to Google I get the following;

C:\Users\Dave>tracert -d -w 100 www.google.com

Tracing route to www.google.com [216.58.220.100]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2    17 ms     *       16 ms  [redacted]
  3    17 ms    16 ms    17 ms  [redacted]
  4    34 ms    34 ms    34 ms  150.101.33.18
  5    35 ms    43 ms    33 ms  72.14.221.174
  6    33 ms    33 ms    33 ms  66.249.95.234
  7    31 ms    31 ms    31 ms  209.85.142.11
  8    33 ms    33 ms    38 ms  216.58.220.100

Trace complete.

Now, if I ping the third last IP address of 66.249.95.234, I get this...

C:\Users\Dave>ping 66.249.95.234

Pinging 66.249.95.234 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 66.249.95.234:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

How is it that the 'ping' internal to tracert somehow works differently to that of the real ping? How are they different? What do I need to do to get ping to work like tracert?

Answer 1

It all has to do with how tracert works. Ping is straight ICMP from point A to point B, that traverses networks via routing rules. Tracert works very different, even though it uses ICMP.

Tracert works by targeting the final hop, but limiting the TTL and waiting for a time exceeded message, and then increasing it by one for the next iteration. Therefore, the response it gets is not an ICMP echo reply to the ICMP echo request from the host along the way, but a time exceeded message from that host - so even though it is using ICMP, it is using it in a very different way.

You can read more detail about it here.

Answer 2

First of all your two commands are sending packets with different destination IP addresses. That means they may take different routes.

When you see 66.249.95.234 on the route towards 216.58.220.100, you might assume that packets with the destination address 66.249.95.234 would be using the same route until reaching that point. That is however not a valid assumption.

It is entirely valid for the route to 66.249.95.234 to be longer than the one to 216.58.220.100. Sometimes it even happens that there is no route which could take your packets to that intermediate router, but it would not be a well designed network, if that was the case.

I don't know if the tracert and ping commands you are using both use the same protocol. Most ping implementations use ICMP echo request packets. However traceroute implementations exist supporting a wide range of protocols including ICMP echo request, TCP SYN, and UDP packets. If the two happens to be using different protocols, that could be a contributing factor to seeing different results.

Finally it even if all of the packets were to reach 66.249.95.234, it is possible that 66.249.95.234 would behave wildly different depending on whether it needs to:

• Forward the packet
• Produce an ICMP error on a packet addressed to itself
• Produce an ICMP error on a packet addressed to somebody else

Choosing to silently drop packets in just one of the three cases is obviously going to break lots of network diagnostics tools, that however doesn't stop some system administrators from doing so anyway.

Answer 3

As security on the network has been steadily increasing, one easy thing that many people do now is to basically disable aspects of ICMP protocol. This prevents responding to traceroutes and returning the FQDN from the hop. Sometimes administrators lock things down do tight that even a ping does not work. This is a decision of the administrator of the system involved.

There is also the possibility that the system is handling an extensive networking load, ICMP is generally very low in priority in being processed compared to real data.