3 ms·
At NANOG 62, there was a presentation "A practical guide to (correctly) troubleshooting with traceroute", by Richard Steenbergen (slides [pdf]: https://archive.
by mrngm 3y ago
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_steenbergen_troublshootingtraceroute_62.49.pdf https://archive.nanog.org/sites/default/files/tuesday_steenb..., talk [video]: https://www.youtube.com/watch?v=WL0ZTcfSvB4 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 https://blog.benjojo.co.uk/post/ping-with-loss-latency-split), to account for that asymmetry.
Regarding the tool trippy itself: awesome visualizations!
- commandersaki 3y agoYep it's a great presentation. I like to always say that traceroute gives you the approximate path a packet will take, whereas ping is for end to end measurement and loss. I'm personally not a big fan of combining the two tools.
- tptacek 3y agoThis 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.