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?

Solution 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.

Solution 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.

Comments

[Burhan Khalid]

It could simply be that ICMP ECHO is blocked.

[MaQleod]

This doesn't really answer the question. The question is why, if both traceroute and ping use ICMP, does ping fail and traceroute succeed.

[Hagen von Eitzen]

To add the final point why pings time out: Apparently the 3rd last 3 host is configured to work as router for traffic through it (which includes sending ICMP TTL EXCEEDED control messages for failures) but to block traffic to it, specifically to not reply to ICMP ECHO REQ. By the way, the traceroute client could send anything with the final hop as destination - it could be ICMP ECHO REQ but it could just as well be some TCP SYN (which might trigger other ICMP messages, esp. when the target jhost is reached. In fact, implementation differs between OSes. And then there's tracepath ...

[Lightness Races in Orbit]

@HagenvonEitzen That'd make a decent answer on its own (the best, IMO!)

[Digital Trauma]

Also worth noting, that many "tracert" implementations don't even send ICMP packets. At least that is the case for traceroute on most Linux, which sends UDP datagrams, though I'm not sure what the windows version does. Intermediate hops should send an ICMP TTL EXCEEDED for any kind of packet, not just ICMP.

[tvdo]

@DigitalTrauma Wireshark says tracert on Windows 7 sends ICMP Echo requests.