I can tracert to an IP address, but not ping it
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.