1

What does it mean when tracert always shows a single long jump? The route below is always the same except the last hop goes directly to any destination IP address that I choose.

And, how does the second-to-last point spoof this? Is the 202.151.252.202 router/firewall increasing the ICMP TTL to accomplish this?

>>> tracert 198.7.59.119

Tracing route to ping-test.net [198.7.59.119]
over a maximum of 30 hops:

  1     3 ms     2 ms     3 ms  4GRouter.com [192.168.1.1]
  2     *        *        *     Request timed out.
  3    72 ms    29 ms    24 ms  10.214.147.54
  4     *        *        *     Request timed out.
  5    58 ms    22 ms    25 ms  10.214.148.169
  6    33 ms    28 ms    31 ms  10.214.147.218
  7    24 ms    27 ms    29 ms  202.151.252.202
  8   278 ms   273 ms   267 ms  ping-test.net [198.7.59.119]

Trace complete.
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Feb 21 '18 at 18:11
1

Is the 202.151.252.202 router/firewall increasing the ICMP TTL to accomplish this?

Most likely, yes. It seems to increment TTL to a value that allows any destination to be reached. tracert is useless here.

0

Tunnels are a single hop. A tunnel wraps the original packet inside an outer packet, and the hops decrement the TTL on the outer packet, not the inner packet.

In essence, the tunnel is a point-to-point link between the tunnel endpoints. The inner packet has no idea what goes on outside the tunnel.

  • Can you speculate about why 202.151.252.202 is doing this? I think it's a Malaysia-to-world firewall/censor, but why mess with ICMP packets? – bobuhito Jan 24 '18 at 0:54
  • Unfortunately, questions about networks not under your direct control are explicitly off-topic here. Using traceroute on the public Internet is very misleading. Many ISPs look for it and will reroute traffic in order to prevent you from casually discovering their internal networks. I recently saw a question on Stack Overflow where the ISP sent the traceroute in a loop. – Ron Maupin Jan 24 '18 at 0:57
  • @bobuhito, the path shown by traceroute in a network you do not control may bear no resemblance to the path taken by your production traffic. – Ron Maupin Jan 24 '18 at 0:58
  • Thanks. By the way, I am ultimately trying to understand why this 4G routing from a USA video server is so much more stable than DSL routing even though the 4G ping and jitter (though I got 278/273/267 above, I usually see far more variation: four pings just now gave 302/281/539/480) seems so much worse than the DSL ping and jitter (215/226/219/216). 4G also easily loses pure speed tests. So, it's weird that 4G is better for video stability...if you have any insight here, I'd like to hear it. – bobuhito Jan 24 '18 at 1:24
  • 1
    Not across the public Internet it is not. Ping and traceroute are good tools for troubleshooting your own network, where you know what to expect, but they can be completely misleading when used across networks that you do not control or know anything about. – Ron Maupin Jan 24 '18 at 6:29
0

Before anyone starts using textbook definitions and telling us what the spec says, remember: it's just code and we can do whatever we want with packets. And that is exactly what happened here - You sent the packet with a TTL of 8 but your last router .202 re-wrote the packet with a new larger TTL (probably 255) and it made it all the way to the destination. Tracert doesn't show the TTL of the incoming packets, but if you ping you will see the TTL of the incoming packets. Default TTLs are 255, 128 (Windows), 64 (many routers and Linux), 60 (AIX? don't see this much anymore). Probably a CISCO ASA, they do all sorts of tricks...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.