Traceroute is a powerful tool. Extremely useful when checking the path of a packet through the network. But how does it ACTUALLY work? What is REALLY going on?
Layer3 packets all have a TTL. A Time To Live. If a router receives a packet with a TTL of 1 (and the packet is addresses to a host not directly connected to this router) it will drop the packet. It will also then create an ICMP error packet and send it back to the original source of the packet to let it know that the address was unreachable this time.
If you ping another machine, the OS will generally create a TTL of 255 for sent packets, though it doesn’t HAVE to be 255.
Traceroute will force an ICMP error message so it can get more information from each hop in the path.
As an example, let’s run a quick traceroute to 4.2.2.1 and see what it gives us:
C:\Users\Darren>tracert 4.2.2.1 Tracing route to vnsc-pri.sys.gtei.net [4.2.2.1] over a maximum of 30 hops: 1 1 ms <1 ms <1 ms DD-WRT [10.50.80.1] 2 8 ms 9 ms 8 ms 10.3.280.1 3 8 ms 9 ms 26 ms walt-cam-1a-ge96.network.virginmedia.net [80.1.170.69] 4 18 ms 7 ms 8 ms popl-core-1a-ae2-0.network.virginmedia.net [195.182.175.229] 5 8 ms 6 ms 16 ms popl-bb-1a-as2-0.network.virginmedia.net [213.105.174.234] 6 31 ms 15 ms 15 ms 195.50.91.69 7 12 ms 13 ms 31 ms ae-11-51.car1.London1.Level3.net [4.69.139.66] 8 14 ms 16 ms 22 ms vnsc-pri.sys.gtei.net [4.2.2.1] Trace complete.
I’ve loaded up Wireshark to tell me exactly what’s going on. The very first packet sent from my PC was sent with a destination IP of 4.2.2.1 – but with a TTL of only 1.
When my router (10.50.80.1) received that packet, it noticed that the TTL was 1, but also that 4.2.2.1 was not directly connected to it. It responded to my PC with an ICMP code 11 – Time-to-live exceeded. It also responded with it’s own source address.
Traceroute now knows that the very first hop to 4.2.2.1 happens to be my local router. It also knows that the routers IP is 10.50.80.1 – It send 3 ECHO reply requests with a TTL of 1. This is the reason you see the 3 values in the traceroute output
It doesn’t stop there though. As soon as traceroute knows that 10.50.80.1 is the first hop, it’ll ask 10.50.80.1 what it’s hostname is via a DNS PTR request. The router will respond to my PC with a DNS PTR response letting it know the hostname. Now traceroute knows what the IP address and hostname is for the first hop. Note that not ALL devices on the internet will respond with a PTR record and so you won’t ALWAYS get a hostname.
Traceroute will now start again and send 3 more packets with a TTL of 2. Exactly the same will happen as above, but for the second hop in the path. This will continue to happen until we eventually get to the host, or we run into the maximum hop count.
When we finally get ICMP echo replies from 4.2.2.1 – traceroute knows it’s job is complete.
btw, traceroute attempts to get PTR records from the devices in the path only when it gets a TTL time exceeded reply. The actual host you are trying to get to is different though. As soon as I ran traceroute 4.2.2.1 it immediately tried to get the PTR record of 4.2.2.1 first. Once it had that it started with all of the above.
Nice post. I’m thinking of doing a post about the differences in traceroute in Linux vs Windows. Windows uses ICMP for traceroute but Linux uses UDP.
Hi Daniel.
I don’t think so, as even Unix used ICMP. It would be good to test though. In fact I might just test it today :)
I believe the destination (4.2.2.1) will reply with the ICMP “Port uncreachable” message not with ICMP “Echo reply”.
p.s. Keep the “Protocol fundamentals” coming, i really enjoyed those 2 articles! It’s nice to think about the basics from time to time. ;) Nice work.
errtime – I must admit, normally that would be the case, however when I ran a traceroute to 4.2.2.1 I got an echo reply?
I should check over this again, both on Windows and Linux to see what, if any, differences there really are.
Right, I love how the simplest posts get the most interesting sometimes.
I’ve run a traceroute on Windows 7 with Wireshark running. I’ve also run a traceroute on Ubuntu 10.04 with tcpdump missing and there are indeed differences!
On windows 7 it goes like this:
1 – The OS send a DNS PTR request to 1.2.2.4.in-addr.arpa to get the hostname for 4.2.2.1
2 – I get a DNS PTR response giving me a hostname
3 – The OS send an ICMP ECHO request with a TTL of 1
4 – I get an ICMP TTL Exceeded packet back from my local router
5 – 3 & 4 above happens twice more
6 – The OS send a DNS PTR request to my local router
7 – My local router responds with it’s hostname
8 – The cycle above (3-7) is then repeated with a TTL of 2, then 3 and so on
9 – We finally get to 4.2.2.1 – which sends back an ICMP ECHO reply – Once I get 3 the job is complete.
On Ubuntu 10.04 is goes a little different:
1 – The OS immidiately sent 3 UDP packets with a high port number straight to 4.2.2.1 with a TTL of 1
2 – The local router responded with 3X ICMP TTL Exceeded message
3 – The above (1 & 2) is then repeated until we get to 4.2.2.1
4 – 4.2.2.1 does not generate a ICMP ECHO reply as an ECHO request was not sent. Rather we get 3 ICMP Code 3 (Port unreachable) replies
5 – The OS now throws out 7 DNS PTR request specifically to each IP it determined in the path from above (Including 4.2.2.1 iself!)
6 – As soon as all the replies come, the job is complete.
Note also that not all devices in the path had a PTR record, in which case the output was simply an IP address
What I really need to do now is change this post to reflect the differences above. I think at the end of the day it doesn’t really matter what kind of packet is initially sent out, as long as the TTL is set correctly.
Yes, it doesn’t really matter what packets are sent out and comes back in. Except now i know that traceroute is not THAT straightforward, it is differently implemented in Unix/Windows. nice work ;)
I’d actually be interested to see how IOS handles a traceroute (and other router software)
My guess is that it’ll follow the *nix way of doing things
nice article… I liked it very much.But i want to ask two questions:
1. I am working behind the proxy server.And my college admin has blocked ICMP packets,is there any way that i can do traceroute by UDP packets like we can do traceroute by TCP packets by using tcptraceroute in UNIX.
2. What is the meaning of the “asterisk” which sometimes comes in between while we do traceroute? Does that means that they don’t want to show their IP address and other information.
Hi Pradeep.
1 – There is a problem here. You can’t do this with ordinary tools in Windows. You would need a 3rd party tool to do so (I did a quick google search and came up with this: http://www.r1ch.net/stuff/ftrace/ – But no idea if it even works) – The problem is that even if you’re sending UDP packets out, you still need ICMP port unreachable packets to come back. If these are blocked, there is nothing you can do :/
2 – The asterix merely means no info. More than likely this particular hop is either a firewall/router not responding to UDP/ICMP. These devices will happily send your traffic to the next hop, but won’t actually respond with any information on it’s own.
btw, if you only get 1 asterix, it’s far more likely a packet just got lost. Remember UDP packets are best effort, there is no guarantee the other side will even get that packet