2

I used following command -

traceroute -m 255 www.bbc.com

and result is an endless loop. I also tried on some other http sites, same result. I also used online traceroute service like monitis which gave similar output till 30 hops. But it does not happens with https sites. Can someone confirm and explain this?

Improve this question
1
  • If you like to debug/troubleshoot HTTP issues do a TCP traceroute towards port 80 (or 443 as appropriate). Bare traceroute tests something else using different means that will get different results. It is almost always the wrong tool to use to debug anything on the Internet (where the majority of user facing stuff uses TCP).
    – Patrick Mevzek
    Commented Feb 28, 2018 at 15:31

1 Answer 1

Reset to default
1

You are trying to run traceroute across the public Internet. Some ISPs will reroute traceroute to keep you from actually discovering their internal networks.

Traceroute is a useful tool on your own network, where you can compare the actual results to expected results, but it can be completely misleading on the public Internet, or across any network you do not control.

Improve this answer
3
  • Bare traceroute (using UDP probes) is for me never the appropriate tool, including on internal networks. I believe one should use a tool mimicking the real traffic that you want to test, otherwise you will get different results, especially since UDP is so less known/used/understood than TCP. If one wants to troubleshoot website access issues, traceroute with the correct options to use TCP probes on the 80 or 443 port is the correct way to do it, that will work everywhere.
    – Patrick Mevzek
    Commented Feb 28, 2018 at 15:54
  • @PatrickMevzek, you may find some ISPs actually looking at the TTL on the packets to identify traceroute traffic, especially if the TTL is less than 10.
    – Ron Maupin ♦
    Commented Feb 28, 2018 at 16:04
  • Yes, no tool is perfect, but your remark applies as well in default traceroute case. I still stand by the idea that you will have less false results, when investigating HTTP issues for example, by using TCP traceroute than default traceroute (which uses UDP typically). I posit that there are far more cases (as it involves less skills) where UDP packets used by traceroute are filtered/munged along the path (or routed differently than TCP ones) than filtering based on TTL in "normal" application TCP packets. For the same reasons, I never recommend ping for this kind of troubleshooting.
    – Patrick Mevzek
    Commented Feb 28, 2018 at 16:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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