19

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?

1
  • 3
    It could simply be that ICMP ECHO is blocked. – Burhan Khalid Jan 11 '15 at 5:29
27

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.

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

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.

0

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.

1
  • 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 '15 at 8:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.