traceroute weirdness

[bwanaaa]

doing a 'traceroute adblockplus.org' gives a bunch of relays and then blank lines
not a time out but just lines of asterisks
1 192.168.3.1 (192.168.3.1) 1601.665 ms 2.632 ms 2.431 ms
2 l100.bstnma-vfttp-131.verizon-gni.net (173.76.3.1) 8.297 ms 8.512 ms 8.962 ms
3 g0-6-1-0.bstnma-lcr-21.verizon-gni.net (130.81.215.186) 17.027 ms 16.908 ms 20.020 ms
4 ae3-0.bos-bb-rtr1.verizon-gni.net (130.81.151.68) 128.819 ms
so-3-0-0-0.bos-bb-rtr1.verizon-gni.net (130.81.151.218) 12.150 ms 18.055 ms
5 0.xe-10-0-0.br1.nyc1.alter.net (152.63.19.201) 20.254 ms 22.777 ms
0.xe-5-0-0.br1.nyc1.alter.net (152.63.16.61) 19.979 ms
6 * * *
7 vlan51.ebr1.newyork2.level3.net (4.69.138.222) 104.090 ms 105.398 ms 106.949 ms
8 4.69.201.45 (4.69.201.45) 100.921 ms
ae-48-48.ebr2.newyork1.level3.net (4.69.201.49) 107.043 ms
4.69.201.45 (4.69.201.45) 97.070 ms
9 ae-41-41.ebr2.london1.level3.net (4.69.137.65) 107.310 ms 106.356 ms
ae-42-42.ebr2.london1.level3.net (4.69.137.69) 109.625 ms
10 ae-58-223.csw2.london1.level3.net (4.69.153.138) 106.141 ms 103.827 ms
ae-56-221.csw2.london1.level3.net (4.69.153.130) 102.571 ms
11 ae-2-52.edge6.london1.level3.net (4.69.139.108) 101.749 ms 106.408 ms 141.619 ms
12 ae0-3356.lon10.core-backbone.com (212.113.8.42) 103.016 ms 109.153 ms 105.659 ms
13 ae3-2002.nbg20.core-backbone.com (80.255.15.73) 139.153 ms 128.466 ms 127.530 ms
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
31 * * *
32 * * *
33 * * *


I give up. what's going on?

 

[serpretetsky]

doing a 'traceroute adblockplus.org' gives a bunch of relays and then blank lines
not a time out but just lines of asterisks

isn't each asterisk actually a timed out packet?

Traceroutes use the TTL part of a packet (time to live) and gives each packet a lifetime in terms of hops.

If a router recieves a packet, it decrements the TTL by one.
If the TTL is zero, then it discards the packet.

Normally a reply is then sent to the source of the packet saying the TTL expired. Traceroute waits for this response and then records it.

However, some routers will silently discard the packet and not respond. In this case, even though the router is correctly routing everything, from the traceroute perspective, it looks dead for all intents and purposes since it didn't reply that the TTL expired.

So a timeout (which is what it looks like you have) can either be a router configured not to send expired notifications, or an incorrect route/dead router.

 

[serpretetsky]

hmmm.... i see what you are saying. Sometimes there is an "timed out" and sometimes not. Im not really sure what the difference is.

 

[Fardringle]

That's actually not uncommon when Internet routers don't respond to ICMP (ping) packets.

 

[Martin Wilson]

That is a very normal traceroute. The row of astericks in the middle mean that device does not respond to ICMP.

The lines of Astericks at the end intimate that you have reached the last WAN hop, which also does not respond to ICMP

 

[SecurityTheatre]

doing a 'traceroute adblockplus.org' gives a bunch of relays and then blank lines
not a time out but just lines of asterisks
1 192.168.3.1 (192.168.3.1) 1601.665 ms 2.632 ms 2.431 ms
2 l100.bstnma-vfttp-131.verizon-gni.net (173.76.3.1) 8.297 ms 8.512 ms 8.962 ms
3 g0-6-1-0.bstnma-lcr-21.verizon-gni.net (130.81.215.186) 17.027 ms 16.908 ms 20.020 ms
4 ae3-0.bos-bb-rtr1.verizon-gni.net (130.81.151.68) 128.819 ms
so-3-0-0-0.bos-bb-rtr1.verizon-gni.net (130.81.151.218) 12.150 ms 18.055 ms
5 0.xe-10-0-0.br1.nyc1.alter.net (152.63.19.201) 20.254 ms 22.777 ms
0.xe-5-0-0.br1.nyc1.alter.net (152.63.16.61) 19.979 ms
6 * * *
7 vlan51.ebr1.newyork2.level3.net (4.69.138.222) 104.090 ms 105.398 ms 106.949 ms
8 4.69.201.45 (4.69.201.45) 100.921 ms
ae-48-48.ebr2.newyork1.level3.net (4.69.201.49) 107.043 ms
4.69.201.45 (4.69.201.45) 97.070 ms
9 ae-41-41.ebr2.london1.level3.net (4.69.137.65) 107.310 ms 106.356 ms
ae-42-42.ebr2.london1.level3.net (4.69.137.69) 109.625 ms
10 ae-58-223.csw2.london1.level3.net (4.69.153.138) 106.141 ms 103.827 ms
ae-56-221.csw2.london1.level3.net (4.69.153.130) 102.571 ms
11 ae-2-52.edge6.london1.level3.net (4.69.139.108) 101.749 ms 106.408 ms 141.619 ms
12 ae0-3356.lon10.core-backbone.com (212.113.8.42) 103.016 ms 109.153 ms 105.659 ms
13 ae3-2002.nbg20.core-backbone.com (80.255.15.73) 139.153 ms 128.466 ms 127.530 ms
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
31 * * *
32 * * *
33 * * *


I give up. what's going on?

Looks totally normal. There is one router in the middle refusing ICMP packets, and a firewall near the end which doesn't pass ICMP traffic. Since tracert has no way of telling it's an endpoint firewall, or just some hop in the middle refusing ICMP, it will keep trying a longer and longer TTL until it gets to the max (usually 20 or 40), but of course, each of those will be blocked by the same firewall at hop 14.

 

[serpretetsky]

Not a big deal, but I wanted to point out that ICMP echo denial is not the only reason for lack of response during traceroute. More likely the reason for lack of response during traceroute is this:
http://www.cisco.com/web/about/security/intelligence/ttl-expiry.html

The difference is subtle, but many implementations of traceroute actually do not use ICMP. For example, if you are on a mac or linux box, you are most likely sending UDP packets during a traceroute, not ICMP. I do not know what router OS's typically use for traceroute, but I suppose if they are FreeBSD based then they default to UDP packets.

Since many routers are setup to simply drop packets with low TTL values, it is irrevant if the the packet is actually ICMP or TCP or UDP or whatever, the packet will simply be dropped if the TTL value is too low, and no response will ever be generated.

 

[bwanaaa]

...
Since many routers are setup to simply drop packets with low TTL values, it is irrevant if the the packet is actually ICMP or TCP or UDP or whatever, the packet will simply be dropped if the TTL value is too low, and no response will ever be generated.

I get the icmp non response effect but i dont get the low TTL problem. How can a packet have a TTL that's too low? Isnt TTL set by the originating computer to a standard amount?

 

[serpretetsky]

I get the icmp non response effect but i dont get the low TTL problem. How can a packet have a TTL that's too low? Isnt TTL set by the originating computer to a standard amount?

There's a common misconception that traceroute programs somehow "ping" the individual hops and that therefore, it relies on ICMP echos. This is not true.

Traceroute works by setting TTL values on packets, and then listening for the response that a router should send when it discards a TTL packet with a TTL of zero. So, to the find the first hop it will set a TTL of 1. The first hop will recieve the packet, decrement the TTL value, check the value, see that it is zero, discard the packet, and then send a response back to the source that it discarded the packet. Traceroute now recieves this response packet, and can calculate the time it took and see the ip address of the hop. This has been implemented with ICMP packets, but it has also been implemented with TCP and UDP packets as well. ICMP is not necessary for this.

Normally when a router discards this packet it sends back a messsage to the source saying it discarded a packet because the TTL value was zero (this response packet is an ICMP message btw, but this is not important).

Some routers do not send that message back, they silently discard the packet and thats that. I'm not familiar with this process or reasoning for it, but that cisco page I linked points out that the reason for it is to avoid DOS (denial of service) attacks via TTL expiration response packets. It takes routing processing time to generate and send a response packet, so someone could send a ton of packets that happen to expire on the same hop and cause that router to grind to a hault. It takes less processing time to silently discard the packet so they recommend that setup if you think it may be security issue.