←back to thread

265 points night-rider | 1 comments | | HN request time: 0.258s | source
Show context
commandersaki ◴[] No.38590611[source]
Copying the per-hop loss indicator from mtr is a bad decision in my opinion. It's always been a source of incorrect diagnosis of network issues. The only loss that matters is end to end.
replies(4): >>38590932 #>>38591072 #>>38591120 #>>38591527 #
mrngm ◴[] No.38591527[source]
At NANOG 62, there was a presentation "A practical guide to (correctly) troubleshooting with traceroute", by Richard Steenbergen (slides [pdf]: https://archive.nanog.org/sites/default/files/tuesday_steenb..., talk [video]: https://www.youtube.com/watch?v=WL0ZTcfSvB4).

It also mentions that isolated hops that show increased latency or loss are most likely throttling on the device. However, if that latency or loss persists on further hops, that indicates a problem.

Another issue with traceroutes is that is usually doesn't account for asymmetry in the return path. What I would find interesting to see is something like isoping/splitping (see this blog post https://blog.benjojo.co.uk/post/ping-with-loss-latency-split), to account for that asymmetry.

Regarding the tool trippy itself: awesome visualizations!

replies(2): >>38591836 #>>38593808 #
1. tptacek ◴[] No.38593808[source]
This is a cool talk, thanks for posting it. One cute thing tools like `trippy` could do (from the talk) would be the reverse lookup on the peer /30 address for all the intermediate hops. I don't know if `trippy` does this (I've installed and played with it but not carefully), but you could also color-code latency spikes that persist into future hops.