Your friend traceroute

I'm in one of those information spreading moods, and I wanted to cover a newbie topic, so I've chosen traceroute.

Most of you have probably used traceroute to troubleshoot a network problem, but you may not understand how it works. Here we go.

Every IP packet contains a little 1 byte field called the 'Time To Live' or TTL field. The idea of this field is very simple, as an IP packet is routed around the internet, each router that passes it will decrease the TTL by 1.. if the TTL of a packet reaches 0, the router will use an internal combustion mechanism to explode the packet and blow the remains out of the cooling fan. It will also send an message back to you saying 'Game over mate'.

The reason we do this is to stop a packet from getting routed endlessly in a loop.

Now what traceroute does is very simple, it attempts to show you the route your packet takes to the destination. It first sends a packet with a TTL of 1.. the first router will recieve this and decrement it.. the packet expires and you get a message back saying 'Game over, I'm router1 and I killed your packet'.

Then traceroute sends out another packet with a TTL of 2.. it passes router1, ttl decrements to 1.. it reaches router2... ttl decrements to 0.. router2 messages to tell you your packet is RIP.

This goes on over as many hops as you specify (default 30 in windows). Now you might traceroute a host and in the middle get something like this :

Tracing route to www.google.com [216.239.57.99]
over a maximum of 30 hops

1 1745 ms 1309 ms 1299 ms 192.168.0.1
2 * * * [unknown]

No this does NOT mean google is dead. It just means that somewhere along the route, some administrator decided he didn't want you mapping the route and so he told the router to just stamp your packet out and not reply to you... simple.

There is a difference in the way UNIX and windows do a traceroute.. UNIX does it the correct way by sending a UDP packet to a high number packet..
Windows on the other hand sends ICMP echo requests. This explains why sometimes you'll find a unix traceroute wont give you the * symbols.. the firewall might be dropping the ICMP (very common).

There now my download is complete and my post count has gone up by one .

Oh yeah last bit of interesting info.. most operating systems start with a default initial TTL of either 32, 64, 128 or 256.. Windows uses 128. So if you ever see a packet with a nice round TTL number, you know its from your local segment and never touched a router...
check it out, ping 127.0.0.1.

This also means you can determine how far away from you a host is.. if you see a packet with TTL of 54 you can safely assume that its 64 - 45 = 10 hops away.

There ! you're now 0.01% closer to becoming Chris Partsenidis

Cheers,

This is an addendum to Sahirhs lesson and is also a lesson in routers.

One of the misconceptions is that the speed is how long it takes to get to the destionation. Not so. It is the round trip speed. You may think is not very important. It can be.

What you might be run into if you do large traces is a problem I ran into years ago and had a big war with PSI (large network provider) and @home.com (which was my Cable modem provider) on where we were having a speed problem.

Normally I have a round trip speed of around 90 ms from California to my computers in New York. The route would typically go from LA (southern California) to Mae-West in San Jose (Northern California) then across the country to New York.

I was experiencing a rediculous amount of slow downs where web pages wouldn't complete, my PCAnywhere connections would drop. It was driving me crazy. So I did a Tracert and got the following results:

[code:1]
C:\WINDOWS>tracert sqlserver3

Tracing route to sqlserver3 [38.246.19.43]
over a maximum of 30 hops:

1 10 ms 29 ms 14 ms cr1-hfc1.irvn1.occa.home.net [24.1.185.1]
2 10 ms 7 ms 7 ms r1-fe0-0-100bt.irvn1.occa.home.net [24.1.184.1]

3 15 ms 20 ms 9 ms 10.0.242.33
4 16 ms 6 ms 12 ms 10.0.240.9
5 14 ms 15 ms 23 ms c1-pos5-0.anhmca1.home.net [24.7.72.9]
6 18 ms 16 ms 16 ms 24.7.65.165
7 15 ms 16 ms 18 ms bb3-pos2-0-0.mae-w.nap.home.net [24.7.72.26]
8 27 ms 23 ms 21 ms 172.16.1.97
9 23 ms 23 ms 22 ms nw4-ext.sc.psi.net [198.32.136.132]
10 * 319 ms 356 ms leaf.net211.psi.net [38.1.10.1]
11 328 ms 325 ms 322 ms rc4.ne.us.psi.net [38.1.21.196]
12 * 336 ms * 38.1.41.196
13 343 ms 333 ms * 38.2.218.142
14 349 ms 351 ms * sqlserver3 [38.246.19.43]
15 372 ms 344 ms 350 ms sqlserver3 [38.246.19.43]
[/code:1]

Now if you look at where the speed goes to 300+ and "*" (where there was no response), this is where the problem appears to be. You will notice line 7 Mae-west (if you look at the name it has mae-w in it.). At this point I have been in the @home network (easily discernable if you look at the name).

Now I get handed off to PSI (may have been at line 8, was definately at line 9). Line 10 was where the problem starts.

Now I am having a "conversation" with level 2 networking engineers (level 1 as usual is useless) at @home and they are telling me that the problem was with PSI. I do the same with PSI and they say the problem was with @home. So I go to my machine in New York (via PCAnywhere) and I do a trace to my computer in California.

Guess what.

I get just the opposite results and it follows a different path. The problem is that the results show that I am now getting the speed slowdown in the @home network.

I have much discussion with the creton at @home who says he doesn't care about the trace from New York as the our trace shows the problem doesn't happen on their network.

Here is the lesson. Traceroute, while it shows the path it took to get to each destination, does not show what the path is that the ICMP response took getting back. And we don't know if the slowdown is caused by a device on the outward direction or the inward direction. I could not get this across the Network Tech. Nobody teaches this. I found out by accident.

You have to remember that routers route packets by different metrics (hops, delay, throughput, reliability, etc.). A packet going in one direction could be sent by a router up through Canada to get to New York from California and another router could send the return packet back through Texas on the return ICMP trip (large packets can get split up and go in different paths to get to the same destination).

Traceroute cannot tell you what the return path is, only the outward path and the round trip time.

Isn't networking fun !!!!!

That is such a good point ! its very easy to get confused. Btw for those of you who want to merge ping and traceroute you can use the windows command pathping.


Cheers,

Hey,

I like that one.

Never saw it before. Works great for traces where you only want to see the path and don't care about the speed as it the path is back in under a second and you can kill the rest.

Cool.

Yeah thats precisely what I've been using it for
if you want a slightly more powerful tool, check out a program called 'trout' its really small, multithreaded traceroute (damn fast) with built in whois etc. Or read my review of neotrace in cool software.


Cheers