Same hop count for different destinations in traceroute

Question

When I use traceroute (actually tracert command for Windows) for different destination addresses, I always get same hop counts.

For example: For superuser.com, I get:

Tracing route to superuser.com [151.101.1.69]
over a maximum of 30 hops:

  1     6 ms     1 ms     1 ms  192.168.0.1
  2     2 ms     3 ms     3 ms  10.201.0.1
  3     4 ms     2 ms     2 ms  angeldropsltd.com [103.242.217.37]
  4     8 ms     4 ms     4 ms  151.101.1.69

Trace complete.

For microsoft.com, I get:

Tracing route to microsoft.com [23.100.122.175]
over a maximum of 30 hops:

  1     3 ms     3 ms     1 ms  192.168.0.1
  2     5 ms     2 ms     2 ms  10.201.0.1
  3     4 ms     2 ms     2 ms  angeldropsltd.com [103.242.217.37]
  4     7 ms     4 ms     4 ms  23.100.122.175

Trace complete.

It is similar for all other sites I have tried so far.

I want to know the possible reasons why this is happening. I have some brief knowledge how traceroute works. Different destinations should have different hop counts. My ISP (AngelDrops) might not have all the destination servers directly connected. I think, my ISP is doing something here. So what are the reasons for this happening?

Answer 1

I'm going to give you my best shot at explaining this. But, I don't know why your ISP is doing it.

First, it's important to understand how Traceroute works. Traceroute works by settings the TTL (Time To Live) value in the IP packets that it sends out. Each hop your packet takes along the way will decrement the TTL by 1. When TTL reaches 0, if your packet has not reached it's intended destination then a ICMP Unreachable message is sent back containing the IP address of the last router reached.

So, when you issue the tracert command, Windows sends out a series of ICMP packets with incrementing TTL values. The first packet goes out with TTL 1, the next packet with TTL 2, and so on. In this manner, each router along the path to your destination can be discovered - if it replies with ICMP unreachable. If it just drops the packet, you get the * * * response from tracert and no information.

So, what appears to be happening here is that your ISP (AngelDrops) is not honoring the TTL setting. Instead, it appears they are stripping or filtering that information from the packet when it reaches them. Because of that, once the packet reaches AngelDrops they are forwarding it along to it's destination with a much higher "default" TTL. This causes the packet to traverse all the way to it's destination and the final response you see is from the destination.

TTL in an IP packet is really designed to prevent network loops where a packet continues to bounce around inside the network in a circle forever.

I hope that makes sense. Now, why does your ISP do that? I'm not particularly sure, but it could be that they see tampering with the TTL as a possible security risk to their network and thus they filter it. Honoring your TTL data is not really necessary for the proper operation of the network.

Being that I don't know anything about AngelDrops, it could be there is something non-standard about this ISP, maybe it is wireless, or a VPN service, or something like that. There are a number of possible technicalities why things get weird with them.

Based on what I see in your traceroute it appears you are on some kind of shared internet service. You aren't getting a real public IP, so you are probably behind some kind of NATted network where you are sharing the same public IP with multiple users. This would explain everything.