18

I am able to load www.cnn.com in Chrome, yet when I do a traceroute from the command line (OSX), it times out at level3.net

I used this Chrome extension to verify the IP that Chrome is using for www.cnn.com (I can't find a way with Chrome debugger to view IP addresses): https://chrome.google.com/webstore/detail/ipvfoo/ecanpcehffngcegjmadlcijfolapggal

And when I use the CLI to traceroute to the same IP address, it times out??

Are there any diagnostics to figure out or understand why traceroute is timing out in this case? I thought both traceroute and browsers are using the same OS network layer to route TCP/IP traffic?

jpeskin
  • 2,801
  • 4
  • 28
  • 27
  • 6
    It turns out that OSX uses UDP by default for traceroutes, and apparently many routers block UDP-based traceroutes. By using: "traceroute -I www.site.com", you can use ICMP outbound packets, which are not blocked (or at least less likely to be blocked). Once I started using -I almost all of my traceroutes would go through without timing out. – jpeskin May 31 '13 at 03:27
  • -l does not work for me : Usage: traceroute [-adDeFInrSvx] [-A as_server] [-f first_ttl] [-g gateway] [-i iface] [-M first_ttl] [-m max_ttl] [-p port] [-P proto] [-q nqueries] [-s src_addr] [-t tos] [-w waittime] [-z pausemsecs] host [packetlen] – Koray Tugay Jun 10 '15 at 18:10
  • 6
    @KorayTugay The flag is an uppercase "i", not a lowercase "L" – Tur1ng Sep 22 '15 at 18:24

2 Answers2

57

If a router along the way decides to not send the ICMP time exceeded (i.e. TTL reached en-route) or destination unreachable message (i.e. UDP-packet reached final host but port closed, proper behaviour though), you will get a timeout at that point in the traceroute.

In short, if you are running a traceroute xyz you are doing what is called an UDP-based traceroute, that is sending UDP-packets with a low TTL, starting from 1, and increasing by 1 per step. If you packet dies at a router, i.e. TTL becomes 0, that router should, according to RFC 792 and some others, send an ICMP "time exceeded" message, ergo saying that we could not deliver the package within the timeframe, but at least we tell you that your package died.

There are two other methods for doing a traceroute, I'd recommend the a man-page for help, such as this one, if you want to understand the differences better. But in short you can also send ICMP Echo packets or TCP SYN packets. To summarise, there are three methods all based on an ever increasing TTL to map the "hosts" along the route:

  • UDP to random port (usually 33434 + 100) at host with low TTL
    • In my experience the default for all command line tools, such as traceroute and tracert
  • ICMP Echo to host with low TTL
    • I've encountered this in a couple of graphical tools, also as an option for most command line tools.
  • TCP SYN, often to port 80, that way the traffic is "kinda" masked as http-traffic is passes by many routers which normally drop ICMP Echoes and UDP-packets to weird ports.
    • Neat trick and "new" method, although unorthodox, for finding a route to a host. Unorthodox in that you are in a way missusing Internet-standards. Exists as an option for most command line tools.

The router may pass on normal traffic, thus allowing your TCP-based http request to complete, but it may silently drop UDP to weird ports, half open TCP to weird ports or ICMP pings with low TTL, leaving your local traceroute process waiting and then timing out on that stop.

flindeberg
  • 4,887
  • 1
  • 24
  • 37
Lasse V. Karlsen
  • 380,855
  • 102
  • 628
  • 825
  • 2
    +1 for the real answer. – Grady Player May 11 '13 at 17:34
  • could write about trace route using icmp timeouts, and how repeating could get a different route and a different result... – Grady Player May 11 '13 at 17:35
  • There's *tons* of information to write or read about if you want to know how and why traceroute works, and I am no expert on any of it, feel free to either edit my answer to provide that information, or write up an answer of your own. I'm afraid the exact details is out of my league. – Lasse V. Karlsen May 11 '13 at 17:47
  • This seems like really bad etiquette for a router to not return ICMP messages. It basically kills the ability to diagnose the source of a routing problem. This is Level3 that is not returning ICMPs. If major ISPs like this stop returning ICMPs (for security reasons?) that would kill traceroute as a diagnostic, no? – jpeskin May 11 '13 at 19:36
  • So is there a workaround when tracert is not reliable? – CMCDragonkai Jun 16 '14 at 08:57
  • 1
    No, there is no workaround. The whole concept of routing data on the network is prone to changes due to load balancing, routers coming online or going offline, traffic shaping, and configuration done by 3rd party system administrators that may not care about your tracert at all. In short, it's magic. – Lasse V. Karlsen Jun 16 '14 at 09:36
  • @LasseVågsætherKarlsen I found this answer by chance, I hope you don't begrudge that I added two more methods and made the answer a bit more technically correct! – flindeberg Mar 13 '18 at 16:34
  • If you searched this with a client-side perspective in mind you can do this with the -w command so it would be "tracert -w time-in-miliseconds domain " so for example tracert -w 100 google.com – thesonyman101 Jun 18 '22 at 06:57
-1

Traceroute relies on webservers to return a response as your data resolves the path. These servers are not obligated to provide you with a response, or respond to your traceroute. Thus, your traceroute is stuck waiting for a response that doesn't come, even though your data got to where it was going.

If a server between you and cnn.com decides not to send a response for your traceroute, it can truncate the remaining responses.

Senjai
  • 1,811
  • 3
  • 20
  • 40