Protocol fundamentals – Traceroute differences between Windows and Linux

My last post about Traceroute over here: – got some interesting conversation going on in the comments.

Basically there is quite a big difference in the way in which Windows and Linux handle traceroute. I tested on both Windows 7 and Ubuntu 10.04, but my guess is that all Windows follow the same format as do all *nix’s (please let me know if otherwise though!)

I would recommend reading the above post again quickly to get all the basics out the way before we delve into the differences.

Step-wise, this is what happens on Windows:

  1. The OS send a DNS PTR request to to get the hostname for
  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 – which sends back an ICMP ECHO reply – Once I get 3 the job is complete.

Ubuntu does this completely differently though. Step-wise this is what’s going on:

  1. The OS immidiately sent 3 UDP packets with a high port number straight to 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. 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 iself!)
  6. As soon as all the replies come, the job is complete.

The main differences are that Windows will send a DNS PTR request from the start, then send ICMP ECHO requests. At each hop it’ll send a DNS PTR request and then move onto the next hop.
Linux starts with sending UDP packets to a high port number straight away. When it finally gets to the last hop it’ll then send out a mass DNS PTR request to every hop in the path that it has determined.

Protocol fundamentals – Traceroute

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 and see what it gives us:


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

  1   1 ms  <1 ms  <1 ms  DD-WRT []
  2   8 ms   9 ms   8 ms
  3   8 ms   9 ms  26 ms []
  4  18 ms   7 ms   8 ms []
  5   8 ms   6 ms  16 ms []
  6  31 ms  15 ms  15 ms
  7  12 ms  13 ms  31 ms []
  8  14 ms  16 ms  22 ms []

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 – but with a TTL of only 1.

traceroute2When my router ( received that packet, it noticed that the TTL was 1, but also that 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 happens to be my local router. It also knows that the routers IP is – 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 is the first hop, it’ll ask 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 – 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 it immediately tried to get the PTR record of first. Once it had that it started with all of the above.

Protocol fundamentals – ARP

What is ARP and how does it actually work? I’m surprised at the amount of people who don’t know exactly what it does and how important it is.

To illustrate, I’m going to use this extremely simple network:


Both of these systems are really just connected to a home router. Remember that these ports are really just switched ports. The only time they traverse a layer3 port is when they are sending traffic outside the local LAN.

ARP is the Address Resolution Protocol. Essentially all it does is resolve a logical IP address to a physical Hardware (MAC) address.

In the above diagram, if wants to send traffic to, it will move down the IOS layers. It will eventually get down to layer2. The layer2 header needs to have both a source and a destination MAC address. has the layer3 address already, but not layer2. This is where ARP comes into the picture. will send a broadcast out onto the lan asking that whoever holds respond with its MAC address (In that broadcast it’ll let everyone know what the MAC address of is – so they can reply). When get’s that broadcast, it’ll respond with it’s OWN MAC address with a unicast.

Once has received’s MAC address, it will add that mapping to it’s own local ARP cache. As long as that value is in the cache, it’ll know exactly how and where to send traffic bound for

As an example, I’ve run the above through wireshark to see exactly what is happening (Click the image to see the full request and response):


The first ARP packet was a broadcast to the local lan asking for the owner of the address. It also asks to respond to (this ARP request also contains’s own MAC address) – The second packet is a simple unicast back to letting it know that’s MAC address is 00:11:32:06:0c:8a

This can be verified as follows:

C:\Windows\system32>arp -a

Interface: --- 0xb
  Internet Address      Physical Address      Type            00-11-32-06-0c-8a     dynamic

ARP is one of the fundamental parts of TCP/IP – Make sure you know it :)