Empty entries (***) when using traceroute on a PC but not when using traceroute in the router

Question

Today when I try to traceroute www.google.com from both my router and my PC, I saw a weird behavior.

Router's Traceroute

traceroute to www.google.com (173.194.38.176), 30 hops max, 40 byte packets
 1  10.74.128.182 (10.74.128.182)  69.669 ms 10.74.128.178 (10.74.128.178)  36.885 ms 10.74.128.182 (10.74.128.182)  38.042 ms
 2  10.74.128.181 (10.74.128.181)  36.468 ms  37.848 ms  35.048 ms
 3  10.64.7.74 (10.64.7.74)  75.262 ms 10.64.7.86 (10.64.7.86)  44.339 ms  40.346 ms
 4  kph-148-48.tm.net.my (203.106.148.48)  40.021 ms  48.847 ms  39.153 ms
 5  10.64.7.90 (10.64.7.90)  41.705 ms  42.232 ms  40.001 ms
 6  10.55.34.234 (10.55.34.234)  48.969 ms  48.335 ms  49.216 ms
 7  * * 72.14.203.186 (72.14.203.186)  47.921 ms
 8  209.85.242.240 (209.85.242.240)  61.557 ms  61.469 ms  47.117 ms
 9  209.85.242.232 (209.85.242.232)  59.473 ms  61.54 ms  55.777 ms
10  72.14.233.105 (72.14.233.105)  64.806 ms  61.513 ms  59.459 ms
11  sin04s02-in-f16.1e100.net (173.194.38.176)  61.45 ms  56.76 ms  55.513 ms

PC's Traceroute

Tracing route to www.google.com [173.194.38.179] over a maximum of 30 hops:
  1     1 ms    <1 ms     1 ms  router.asus.com [192.168.1.1] 
  2   118 ms    81 ms   118 ms  10.74.128.178 
  3    38 ms    37 ms    39 ms  10.74.128.177 
  4    45 ms    50 ms    72 ms  10.64.7.86 
  5    43 ms    41 ms    41 ms  kph-148-48.tm.net.my [203.106.148.48] 
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  And onwards like that…

  Trace complete.

1. Why are there two different addresses (10.74.128.182 and 10.74.128.178)? Does that mean the packet is routed to 2 different routers at different time? If that's the case why the tracert command on my PC(Windows 7) did not shown it?

2. In the router's traceroute, both the IPs of the first and second trace (10.74.128.178 and 10.74.128.181) are in the same network address since it is class A IP and classified by the first 8 bits which is 10. Therefore I just wonder how a packet can be send to two routers that are in the same network?

3. Why the tracert command on my PC shows empty result * after kph-148-48.tm.net.my [203.106.148.48]whereas full traces were captured by the router tracert command?

4. In the router's traceroute, after line 4 which is a public address (203.106.148.481), the next 2 hops are private addresses (10.64.7.90 and 10.55.34.234). After that it changed back to public address which belongs to google (72.14.203.186). I thought private address suppose to be non-routable on the Internet? When I try to ping that 2 private addresses I did received reply. So I just wonder how is it possible for my pc to be able to reach the IPs at the private networks that come after a public address.

Answer 1

Traceroute works by sending out IP packets with successively higher IP TTL (time to live) values: 1,2,3... Each hop decrements the TTL. When it reaches 0, the packet is not routed, and an ICMP time exceeded message is sent to to the source, which is how the system running traceroute determines the route.

1. This appears to be the traceroute version found on many Linux installations. This traceroute command sends out three packets for each TTL value. So what you are seeing is that two of the packets went to 10.74.128.182 and one went to 10.74.128.178.

2. Since this is the first hop after your router, it is probably the router's gateway address. It is possible that HSRP or similar is in play: there are probably two devices load balancing with a floating IP address. For example: you use the gateway address 10.0.0.1, but behind the scenes this actually points to 10.0.0.2 and 10.0.0.3 which share the load. This is in fact possible using HSRP. Classful routing is not really in use anymore. the 10.0.0.0/8 range is just RFC1918 IP addresses your ISP is using.

3. Different versions of traceroute send different packets out. The Linux version you're using on the router sends UDP packets by default; the windows version on your PC sends pings. It looks like the pings are being blocked between hops 5 and 6, but that's just a guess. Try a different traceroute utility on your PC and I bet you'll get different results.

4. You are right. RFC1918 addresses are not routable on the public internet. So my answer is that even though you see a public IP address at hop 4, you have not left your ISP yet. If you had, you shouldn't be able to get TTL expired messages with private source addresses. The similar IP addressing in hops 3 and 5 suggests this too: they both use addresses in 10.64.7.0/24 (probably not a coincidence). Suffice it to say this: the IP addresses are pretty much arbitrary, and within their own network, your ISP is free to have routers that have interfaces with both public and private interfaces. This is the case with hops 3 and 4. It's also possible for a packet to pass through routers without public IP addresses after leaving your ISPs network; in this case you should not receive a traceroute reply.