This is a nice rant, but telling people not to use this tool because it has many flaws isn't very helpful. AFAIK, there's not a better tool out there to use; the alternative is hoping things will get better by magic and the passage of time (which, to be fair, is somewhat effective; but not ideal if you've got things to do)
Yes, traceroute doesn't address it's hard to get in touch with someone who can help. Sure, anything to do with ICMP probably has to deal with rate limiting (and the two people are tracing so the packet loss is 50% effect is real, and frustrating). But when I've had network problems and a contact who is willing to help, they really want a traceroute or mtr to help narrow down where the problem is.
The trick is finding the right settings to get a mtr that shows what you need to show. My big problem that I needed mtrs for was server a talking to server b over several hops with 2 or 4 way aggregation on each hop. Most of the paths are clean and I can see 0% loss, but there's one link in there with say 10% loss. Default settings will not get you anything useful; you've got to test many 5-tuples (dst host, src host, protocol, dst port, src port) to find one that shows loss and one that doesn't, and then send an mtr from those. You may want to run mtrs in the reverse direction too. You'll need to have a slow probe rate for the mtrs you share, to avoid/reduce the rate limiting issues.
If you can't count on the far side destination definitively responding to pings, your mtrs are going to be too messy to share, unfortunately.
If there's MPLS in the loop, there's an extension to get data from that too, and sometimes it works.
Yes, traceroute doesn't address it's hard to get in touch with someone who can help. Sure, anything to do with ICMP probably has to deal with rate limiting (and the two people are tracing so the packet loss is 50% effect is real, and frustrating). But when I've had network problems and a contact who is willing to help, they really want a traceroute or mtr to help narrow down where the problem is.
The trick is finding the right settings to get a mtr that shows what you need to show. My big problem that I needed mtrs for was server a talking to server b over several hops with 2 or 4 way aggregation on each hop. Most of the paths are clean and I can see 0% loss, but there's one link in there with say 10% loss. Default settings will not get you anything useful; you've got to test many 5-tuples (dst host, src host, protocol, dst port, src port) to find one that shows loss and one that doesn't, and then send an mtr from those. You may want to run mtrs in the reverse direction too. You'll need to have a slow probe rate for the mtrs you share, to avoid/reduce the rate limiting issues.
If you can't count on the far side destination definitively responding to pings, your mtrs are going to be too messy to share, unfortunately.
If there's MPLS in the loop, there's an extension to get data from that too, and sometimes it works.