Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

While troubleshooting performance issues on our network, I ran traceroute on various websites. The following websites would repeatedly not complete traceroute:



  • Are these sites protecting their network such that traceroute is not able to complete?
  • I assume that this is based on these websites' networks and is unrelated to our network performance issues. Is that a safe assumption to make?

Example Traceroute for

$ traceroute
traceroute: Warning: has multiple addresses; using
traceroute to (, 64 hops max, 52 byte packets
 1 (  56.518 ms  2.390 ms  2.082 ms
 2 (  9.943 ms  10.007 ms  10.177 ms
 3 (  10.976 ms  21.159 ms  10.015 ms
 4 (  26.562 ms  26.278 ms  25.818 ms
 5 (  26.393 ms  26.519 ms  79.884 ms
 6 (  32.965 ms  26.123 ms  48.123 ms
 7 (  27.308 ms  26.784 ms  26.693 ms
 8 (  27.137 ms  26.473 ms  27.047 ms
 9 (  26.315 ms  26.329 ms  26.449 ms
10 (  51.270 ms  51.355 ms  51.134 ms
11  * * *
12  * * *
. . . . .
33  * * *
34  * *^C
share|improve this question
up vote 16 down vote accepted

If you block some ICMP traffic, for firewalling or whatever reason, then traceroutes don't fully work. They're a mixture of UDP (the DNS lookups) and ICMP usually.

If you run traceroute -I or traceroute -T you should see different results ( completes for me). This uses ICMP echo and TCP SYNs.

From the traceroute command's man page on Linux:

In the modern network environment the traditional traceroute methods can not be always applicable, because of widespread use of firewalls. Such firewalls filter the "unlikely" UDP ports, or even ICMP echoes. To solve this, some additional tracerouting methods are implemented (including tcp), see LIST OF AVAILABLE METHODS below. Such methods try to use particular protocol and source/destination port, in order to bypass firewalls (to be seen by firewalls just as a start of allowed type of a network session).

share|improve this answer
Some versions of traceroute may not support the -T flag, however many support the -P [protocol] flag. On FreeBSD 8 traceroute understands UDP, TCP, GRE amd ICMP (and can set the protocol field for any valid IP protocol, though packet contents may not be useful/sane.) – voretaq7 Apr 6 '11 at 21:19

Traceroute uses groups of ICMP messages. each has 3 ICMP messages. (HOP count increment by one in each group of messages).

Usually admins block ICMP packets to "protect" their network. (mostly to obscure the structure of network and DoS).

That's why you get stars.

share|improve this answer

Tracert isn't a tool for analyzing performance problems, it's a tool for discovering the path to a particular host. Running tracert against an external host tells you nothing about your own network.

Start by looking at your internal network by measuring latency and packet loss between two internal hosts. Then run a packet capture on your workstation and look for evidence of network congestion like ARP flooding, broadcast storms, TCP retransmissions, and duplicate Acknowledgements.

share|improve this answer
Thanks for the info. I should have clarified that our performance issues are mainly related to accessing external websites. I say "mainly" because we have multiple network-related problems. I've eliminated our one, large collision domain due to using hubs by swapping 3 or 4 hubs out with switches. Our DSL provider admitted that there isn't enough copper in our area given the customer demand (we're in a small town and their our the only viable-ISP option). So I'm trying to improve our internal network, while also gathering data to prove to the ISP that they have an issue. – Matthew Rankin Apr 6 '11 at 12:03
OK, but again, tracert isn't the right tool and tracing to Google and such isn't going to help much because once the traffic leaves your ISP there isn't anything they can do about it. You should be concerned with the connection between you and the ISP. Log into your DSL modem, find out what it's DG is and run pathping from you to there. Then run tracert to Google to determine the last hop in your ISP network and run pathping from you to there. Provide those results to your ISP and see what they have to say. – joeqwerty Apr 7 '11 at 14:26
Many thanks for your recommendation. – Matthew Rankin Apr 8 '11 at 15:55

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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