TRACERT Issues, Consistently timing out on specific steps

Disclaimer: I'm not an expert at this, so… please point out any nonsense I wrote.

But, yes, that's quite possible, because the packets these diagnostic tools sends & expects aren't exactly the same thing as your regular data packets. They don't try to make the same TCP-port-80 connection as your web browser would.

The ping command is simple – it sends ICMP "Echo" packets (dedicated for this purpose), and expects ICMP "Echo Reply" responses from the target. Since ICMP itself is also used for reporting connection errors, most operating systems already have built-in support for answering Echo requests, however...

• There are some other ICMP packets that aren't quite as useful, for example "Redirect" or even the old "Source Quench" (easy to abuse). Even the same Ping/Echo has a history of being used as the Ping of Death against various buggy network stacks.

  As a result, many sysadmins to this day configure a blanket block of all incoming ICMP packets, in the belief that this would make their network more secure.

  Sometimes they block even outgoing ICMP packets, which among other things breaks Traceroute as well as other things like MTU discovery. (I mean, it's obviously their network and their business, but… argh.)

• While Windows isn't used for routers (much), it is still probably the most common example of this – ever since Windows XP SP3, the built-in firewall would, by default, drop all incoming Echo requests.

(Almost any firewall lets you filter TCP & UDP packets selectively, based on things like source address and/or destination port. So there's no surprise that firewalls can pass TCP but block ICMP, for example.)

As for Traceroute, it has no dedicated message or protocol, in fact it relies on error replies. The exact implementation varies – on Windows the tracert command sends ICMP Echo packets, while most variations of the Linux traceroute tool send garbage over UDP instead (although can do ICMP as well). But the common part is that they send the packets with small, increasing "time to live" aka "hop count" limits, expecting each router in the path to reply back with an ICMP "Time-to-live Exceeded" error. Most operating systems do that by default.

But, again, some systems have firewalls set up to silently drop ICMP Echo packets, and as a result they don't send any error message back. (In this case, it seems the filtering only applies to packets that the router itself would handle, but not to packets it merely forwards along.)

Some other systems have firewalls set up to block specifically just outgoing ICMP errors. I've honestly no idea why, but I've seen that happen.

And some routers do have the ICMP error generation itself turned off, perhaps to reduce load or to avoid packets being handled by the slow main CPU when they would otherwise be forwarded by fast dedicated hardware.

So in the end, it's not that "some routers aren't set up to answer", but more that they "are set up not to answer" the traceroute messages.

(I can't really answer why sometimes mtr works but no invocation of traceroute does. At first look, it does use the same approach as traceroute, but I haven't investigated it in depth.)