The trace tool maps the series of hops for a packet to reach a domain or IP address and shows how long each one takes.
In the text box, enter one of:
- A domain name.
- An IP address in standard form.
- An IP address as a single decimal number, with the “Convert Base-10 to IP” box checked.
Click the “Trace” radio button and then “Go.”
When to use it
There are several uses for a trace:
- Determining why a node is slow or unreachable. If there’s a big jump in time at any hop, then that node is contributing significantly to the delay.
- Finding out who hosts a site or provides its Internet service. If a domain is hosted, the next hop to last will usually be the server that hosts it. If it has its own server, the last few hops will show how it connects to the Internet. They may give an idea of where the server is geographically located.
- Checking the reachability of your own site. If you’ve set up a website and have concerns about its performance, a trace will tell you how traffic gets to it and identify possible bottlenecks.
What it does
An Internet connection to anyone other than your local network or your service provider requires two or more hops, usually many. Using the trace tool will tell you what path a packet follows to reach a given host.
Running the trace tool will return a list of the nodes through which your packet passes. It tries each hop three times, to get a representative sample. For each hop, you’ll see the hop number, three timings in milliseconds, the IP address of the node at that hop, and the domain name if it’s available. If the node doesn’t respond to one or more of the three attempts in a reasonable amount of time, you’ll see “timed out” instead of the time. If all the attempts time out, you won’t see any information about that node.
A timeout doesn’t mean that we’ve lost the connection, but that the node being queried isn’t responding to an ICMP request within the allotted time. Many Internet devices have firewall or configuration settings to ignore such requests. Legitimate sites do that for security or performance reasons, and other sites do it to cloak themselves. Either way, that defeats the trace.
Sometimes a trace will go into a loop, bouncing back and forth among the same set of nodes. This indicates a routing problem that needs fixing.
You can’t enter a path for a specific page or email address. The trace only indicates the path to the servers.
A deeper look
The trace tool works by sending out a UDP packet with a specified TTL (time to live) value. TTL doesn’t actually mean time in this context, but the maximum number of hops allowed. In normal use, TTL values keep a packet from bouncing around the Internet forever. In this case, the TTL value is set at 1 for the first hop, 2 for the second hop, and so on. When a node receives a packet and it isn’t the destination, it decrements the TTL value and passes it on. If the TTL goes to zero, it returns an error message. The trace tool uses the error response to identify the node on that hop.
Sometimes you’ll see timeouts in the middle of a trace, though hops before and after them are reported. Not all nodes send an error message in response to a TTL limitation. They may be trying to hide their identity or just to reduce their overhead. Some hosts have buggy TTL error handling and don’t send back a response that will reach the originator.
The path a trace follows will vary with its starting location. Our server is located in the United States, and the trace starts from our servers. If your computer is in a different part of the world, your route to a server may follow a completely different path.
Packets won’t always follow the same path to the same host. The most interesting ones are the ones near the end, which show how the host connects to the Internet). A domain which uses a content delivery network (CDN) has geographically distributed edge servers, and which one you reach depends on your location. The trace tool will show the path from our server, which may be different from the path from your computer.
A single domain may have multiple IP addresses and use round-robin DNS to choose one. Successive traces may access different IP addresses and follow different routes. It’s not unusual for two requests to a website, one right after the other, to be handled by different machines. Sometimes this will throw the trace off, presenting you with a hybrid of different paths rather than a path that actually exists.
A domain may use different servers for different subdomains. Tracing the base domain might give a completely different path from the subdomain. The “www” prefix is technically a subdomain, so it’s possible though unusual for www.example.com and example.com to follow different paths.
Many domains use separate hosting for email, and a trace won’t show you that. You’ll normally get data for the server which the domain uses for its website, not the mail server.
The original traceroute program was written by Van Jacobson in 1987 and “debugged by a cast of thousands,” according to its documentation