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 []
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms
  2    17 ms     *       16 ms  [redacted]
  3    17 ms    16 ms    17 ms  [redacted]
  4    34 ms    34 ms    34 ms
  5    35 ms    43 ms    33 ms
  6    33 ms    33 ms    33 ms
  7    31 ms    31 ms    31 ms
  8    33 ms    33 ms    38 ms

Trace complete.

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


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

Ping statistics for
    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?

  • 3
    It could simply be that ICMP ECHO is blocked. Jan 11, 2015 at 5:29

3 Answers 3


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.

  • 13
    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 ... Jan 10, 2015 at 13:24
  • @HagenvonEitzen That'd make a decent answer on its own (the best, IMO!) Jan 10, 2015 at 17:54
  • 4
    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. Jan 11, 2015 at 4:35
  • 1
    @DigitalTrauma Wireshark says tracert on Windows 7 sends ICMP Echo requests.
    – Bob
    Jan 11, 2015 at 22:47

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

When you see on the route towards, you might assume that packets with the destination address 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 to be longer than the one to 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, it is possible that 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.


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.

  • 6
    This doesn't really answer the question. The question is why, if both traceroute and ping use ICMP, does ping fail and traceroute succeed.
    – MaQleod
    Jan 10, 2015 at 8:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .