Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

  • yahoo.com
  • amazon.com
  • ebay.com

Questions

  • 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 ebay.com

$ traceroute ebay.com
traceroute: Warning: ebay.com has multiple addresses; using 66.135.205.13
traceroute to ebay.com (66.135.205.13), 64 hops max, 52 byte packets
 1  10.10.100.1 (10.10.100.1)  56.518 ms  2.390 ms  2.082 ms
 2  mo-69-34-118-1.sta.embarqhsd.net (69.34.118.1)  9.943 ms  10.007 ms  10.177 ms
 3  mo-69-68-209-249.dyn.embarqhsd.net (69.68.209.249)  10.976 ms  21.159 ms  10.015 ms
 4  ge-6-20.car1.stlouis1.level3.net (4.53.160.13)  26.562 ms  26.278 ms  25.818 ms
 5  ae-11-11.car2.stlouis1.level3.net (4.69.132.186)  26.393 ms  26.519 ms  79.884 ms
 6  ae-4-4.ebr2.chicago1.level3.net (4.69.132.190)  32.965 ms  26.123 ms  48.123 ms
 7  ae-5-5.ebr2.chicago2.level3.net (4.69.140.194)  27.308 ms  26.784 ms  26.693 ms
 8  ae-2-52.edge4.chicago3.level3.net (4.69.138.166)  27.137 ms  26.473 ms  27.047 ms
 9  chp-brdr-03.inet.qwest.net (63.146.27.17)  26.315 ms  26.329 ms  26.449 ms
10  dvr-edge-13.inet.qwest.net (67.14.24.89)  51.270 ms  51.355 ms  51.134 ms
11  * * *
12  * * *
. . . . .
33  * * *
34  * *^C
share|improve this question
add comment

3 Answers 3

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 yahoo.com or traceroute -T yahoo.com you should see different results (yahoo.com 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
add comment

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
add comment

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
add comment

Your Answer

 
discard

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.