Tracert Request Timed Out: What It Means And How To Fix It

Tracert is a Windows tool used to examine the route a packet takes when connecting to a certain IP address. It’s very useful in identifying why exactly you’re unable to connect to a website or service. Since it’s a Windows tool, the same command doesn’t exist in Linux, but there are equivalents like traceroute and tracert6. I’ll discuss some of the alternatives below, but this article will primarily focus on the error message “tracert request timed out”, what it means, how to replicate it, and how we can diagnose and fix the problem.

But first, let’s look at the output of a regular tracert command and see what a normal response looks like.

The Anatomy of a tracert Command

For this test, I’m going to connect to my website wp-tweaks.com from my Windows PC and share the output. The syntax of the command is simple:

tracert wp-tweaks.com

This gives me the following output:

Let’s break this down piece by piece.

The first line resolves the domain name wp-tweaks.com to 172.66.40.200. This is all public information, so I’m not revealing anything sensitive here. The next line tells us that tracert will only try and retrieve a maximum of 30 “hops”. Based on the output you see in the above screenshot, I’m sure you’ll agree that 30 hops is more than sufficient!

Each following line represents a single “hop” from one network endpoint to another.

Hop 1: The first hop is from my local computer within the private network. You can see from the IP address 172.27.235.129, that it’s a private address because it falls within the 172.16.0.0 to 172.31.255.255 range specified by the Internet Assigned Numbers Authority (IANA). Tracert sends three packets to each endpoint and records the latency for each. Here you can see that all the packets arrive consistently and quickly – which makes sense since it’s the local network.

Hop 2: The second hop is the first publicly accessible internet node. This is likely a router managed by my Internet service provider (ISP). The domain name indicates that it’s associated with SirsteveHQ, which makes sense because my website wp-tweaks.com is hosted on SirsteveHQ.

Hop3: Nothing special here

Hop 4: I made the initial request in Canada, and this is the first indication that we’re now in the United States, where my site’s servers are located. The domain name xe-11-2-1.bar1.KansasCity1.Level3.net indicates that it’s part of Level3’s network – a major ISP, and the name further indicates that the location is Kansas City.

Hop 5: Again, nothing special other than the fact that the third packet had a higher latency than the other two.

Hop 6: The packet arrives at the final destination, as can be judged by the IP address to which tracert resolved earlier in the very first step.

Overall, this was a very uneventful tracert command. The connection times were stable and consistent, and it only took six hops to reach the final destination. Now that we’ve seen what a normal connection looks like, it’s time to analyze the reasons why this could fail, and why tracert could generate a “request timed out” error.

Causes of the “Request Timed Out” Command in Tracert

Here are all the reasons why a tracert command could generate the “request timed out” error.

Network Congestion

This used to be a far more common error than it is today. Outside of an artificial influence like a DDoS attack, regular Internet nodes shouldn’t be facing network congestion. But if it is, then the packets that tracert sends to the network nodes could get delayed beyond a certain limit and generate a timeout.

However, if while running the tracert command, you see that the time out is occurring at a node inside your private network, then it indicates a problem with your network configuration, or that you have extremely high network demands. Similarly, if the timeout occurs inside the private network of the destination, then the receiving service’s network could be the cause of the issue.

One thing to keep in mind is that if you have a congestion problem in your private network, it’s possible that the service itself is fine and accessible by everyone else, but you. That could be a good thing, depending on your point of view!

Firewall Problems

One of the most common problems that cause the “tracert timed out” error message is a configuration problem with the firewall. Or it might not be the configuration, but related to the rate of requests coming from the source.

Firewalls often reject packets without providing a response, meaning that the originating server – the tracert program – doesn’t know what happened, and can’t determine the cause of why the packet didn’t reach, and it’s left waiting for a response forever. To debug this, you could dig into your firewall logs and see why the packets were rejected. But for this, you’d need to have access to the network of the destination.

On Windows, you can simulate a tracert error by creating a firewall rule that blocks ICMP (Internet Control Message Protocol) packets. Here’s a screenshot of how I achieved this on my local computer:

You can do the same thing on Linux. And on the other end as well. This experiment can help you simulate the log output that the server generates so you know what to look for.

Routers or Networks Blocking ICMP Packets

Tracert critically depends on ICMP packets to function. These are special “Echo Requests” that the tool uses to determine the route the packet takes as well as the time it takes for them to reach their destination. Unfortunately, ICMP packets can also be used for malicious purposes. For example, ICMP flood attacks are a common type of DDoS attack, and this causes network administrators to often block ICMP packets outright. Or at least, the kinds of packets that tracert uses.

ICMP packets are also used for reconnaissance by attackers to probe for vulnerabilities in a network’s security architecture. Because of reasons like this, it’s possible that a tracert request would fail with a timeout message if any of the intermediate hops to the destination are configured to drop ICMP packets.

Rate Limiting

While a single tracert request is unlikely to trigger rate limitations, some automated tools – especially from multiple locations – can cause network equipment to detect a large number of ICMP packets and block them based on their frequency. Debugging this is hard, because you need to be aware of all the sources of the ICMP packets, and you might not be in a position to do so.

Censorship or Network Policy. Or a VPN

While not a tech issue, it’s possible for some organizations to implement content policies that require a rerouting or wholesale blocking of certain types of content. If the rerouting process takes too long, the tracert tool can report a timeout. You might notice this if you’re using a VPN that routes traffic along sub-optimal routes to the extent that the ICMP packets never reach their intended destination.

Conclusion

As you can see, a host of issues can cause the tracert “request timed out” message. The key is not so much as what caused it, but finding out where it’s happening, and what you can do about it. Sometimes the problem is within your control, and at other times, there’s nothing you can do, particularly if some network nodes are actively blocking ICMP requests. Firewall logs for those nodes over which you do have control are very useful, and you should use them to diagnose the errors if you can.