[HN Gopher] Trippy - A Network Diagnostic Tool
___________________________________________________________________
Trippy - A Network Diagnostic Tool
Author : night-rider
Score : 229 points
Date : 2023-12-10 03:46 UTC (19 hours ago)
(HTM) web link (trippy.cli.rs)
(TXT) w3m dump (trippy.cli.rs)
| FujiApple wrote:
| Author here, thanks for posting this (i'd meant to do a show HN
| post at some point).
|
| Trippy is a modern, cross platform, feature rich alternative to
| MTR with a fancy TUI. And yes, it's written in Rust.
|
| https://github.com/fujiapple852/trippy
| spacecadet wrote:
| Super cool, inspiring me to finish my rust book...
| booboofixer wrote:
| Wondering if you took a look at or took some inspiration from
| the packet structures for TWAMP/TWAMP-LITE/SDLM RFCs for round
| trip times/packet loss measurements or if you sort of winged it
| and came up with your own. I've been meaning to learn rust by
| implementing those protocols.
| bastard_op wrote:
| As a network engineer, it's a neat tool, I installed it on arch,
| and had the mmdb to point at for geo, so that was cool, but
| mostly unrealistic. My customer in nyc from phoenix says goes via
| switzerland, but at least I know better. I sent out to my current
| customers slack channel to check out, it's at least prettier than
| mtr.
| FujiApple wrote:
| Yes, in my experience GeoIp is _highly_ unreliable, alas Trippy
| can do no more than report the location from the provided mmdb
| file.
|
| I'm aware of some interesting techniques which use timing
| measurements from multiple locations to try and triangulate a
| more accurate location. In fact somebody raised a request for
| supporting JA4L [0] to me just this morning.
|
| [0] https://github.com/fujiapple852/trippy/issues/856
| tecleandor wrote:
| Free geoip database is very so-so, at least for residential
| addresses. For example, my ISP is of Romanian ownership
| (Digi), and although I'm Spanish, located in Spain, and using
| a Spanish contract (not roaming at all) for years (not a
| recently arrived ISP), I'm still very frequently shown
| Romanian versions of ecommerce sites I visit from my phone or
| home connection.
|
| But I wonder: shouldn't at least intermediate
| router/exchanges locations be better pinpointed through their
| who is information? Isn't that database updated?
|
| I wonder how reliable is JA4L once you start adding hops in
| the middle of the trace, I guess it takes in account the
| timing of the intermediate points.
|
| A little time ago (1 month? 2? I'm so bad with dates)
| somebody showed their IP location service that was built
| using a similar technique, but measuring from multiple
| different locations, and I think they had a free version of
| the database. I'll try to find it later.
| tecleandor wrote:
| I think I might've mixed a bunch of different stuff in my
| comment, but the provider I was talking about was IPInfo.
| They do distributed JA4L-like location guessing and have a
| free IP-to-country DB:
|
| https://ipinfo.io/blog/verifying-ip-address-accuracy/
| FujiApple wrote:
| That looks great, seems like they've raised the bar for
| GeoIp accuracy, kudos to them.
|
| It looks like they provide mmdb files (for a fee) which
| should be compatible with Trippy. I'd love to be able to
| test it out, the sample [0] they provide is rather
| limited but I guess enough to test compatibility.
|
| [0] https://github.com/ipinfo/sample-
| database/blob/main/IP%20Geo...
| Operyl wrote:
| Reach out to them, they're awesome folk and were willing
| to sponsor a 501(c)3 I worked on.
| mrngm wrote:
| You might also be interested in "geofeed" attributes in the
| WHOIS databases, in some database they can be found in a
| "remarks" field).
|
| This record usually leads to an RFC 8805 formatted document
| that shows a mapping between IP address ranges and their
| (approximate) location. In RFC 9092, efforts were made to
| make this a more structural field.
| FujiApple wrote:
| Thank you, I'll look into those RFCs.
| logbiscuitswave wrote:
| As soon as I saw the screenshots of it running in a terminal
| window, I was in love.
| FujiApple wrote:
| The TUI is built with the _awesome_ Ratatui [0] library
| (formerly tui-rs [1]). UX is certainly not my area of expertise
| and I would not have been able to create Trippy without this
| library.
|
| [0] https://github.com/ratatui-org/ratatui
|
| [1] https://github.com/fdehau/tui-rs
| commandersaki wrote:
| 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.
| FujiApple wrote:
| You are right that showing packet loss for intermediate hops is
| a frequent source of confusion.
|
| Rather than leave it out, I added a status column which shows
| different statuses for intermediate hops (blue if the hop
| responds to less than 100% of probes and brown if it responds
| to 0%) vs the target hop (which show amber and red
| respectively).
|
| Where this breaks down is when dealing with ECMP for UDP & TCP
| tracing, as a given hop (ttl) may represent the target for a
| given round of tracing but not for the next. The mistake, imho,
| is to associate _any_ data with a hop (ttl) rather than the hop
| in the context of a tracing flow.
|
| That is why Trippy had a number of features aimed at helping
| with ECMP, such as Paris and Dublin tracing, and the ability to
| filter tracing by unique flow id. I've covered these quite a
| bit in the 0.8.0 [0] and 0.9.0 [1] release notes if you want to
| know more.
|
| [0] https://github.com/fujiapple852/trippy/releases/tag/0.8.0
|
| [1] https://github.com/fujiapple852/trippy/releases/tag/0.9.0
| lathiat wrote:
| That is not entirely true. Sure it's not a 100% reliable signal
| as routing is asymmetric but it also often isn't and also gives
| you an idea of which point to ask first at least.
|
| If the packet loss starts at your wifi router, or your ISPs
| router. Or the next hop after you ISP. That all gives you a bit
| of an idea where the problem likely is. I solve problems like
| that all the time.
| commandersaki wrote:
| I was a network engineer for over a decade in hosting
| datacenter environments and would get false reports of packet
| loss to various destinations because people would use MTR and
| say they see loss on the path. If a packet takes the path A
| -> B -> C and pings to B have 50% loss but pings to C have 0%
| loss, then the path is perfectly fine.
|
| The only way to reliably isolate packet loss to a hop on the
| path is to have a destination for testing where packets pass
| through that hop and is in its bailiwick which doesn't
| perform rate limiting or policing of ICMP traffic.
| FujiApple wrote:
| Something I intend to add to Trippy, but have not got
| around to it yet; is to codify the "If a packet takes the
| path A -> B -> C and pings to B have 50% loss but pings to
| C have 0% loss, then the path is perfectly fine" idea and
| use that to produce more meaningful headline status
| information to the user. How would you codify this?
| commandersaki wrote:
| I would love for there to be a useful indicator to the
| user to say if loss or latency is an issue.
|
| Being able to indicate cascading loss (e.g. path
| A->B->C->D) shows loss at B, C, and D, is worth bubbling
| up to the user to say there might be real issues. Also
| any indication of loss at D is also an issue. Trying to
| reconcile these scenarios with the UI matters, but I
| don't think there's an easy way. What I think is more
| important than UI that is sorely needed is documentation
| / users guide explaining how to read and understand these
| indicators. I know documentation is usually overlooked by
| users first trying out a program, but having it
| documented and explained can be used as a reference to
| point to a user that is misunderstanding the tool. I
| found that MTR didn't have this much needed documentation
| / reference that people would easily misunderstand the
| tool and it was a herculean effort to correct them.
|
| I would also like to point out that a 0% loss indicator
| at the destination isn't reliable either if the packets
| are spaced out with enough slack. One of my goto when
| testing packet loss of a link I've brought up is to smash
| a destination host with a ping flood, e.g. ping -c 100 -f
| 1.1.1.1. By inundating the link it helps provide a clear
| indicator if there is loss somewhere on the path (usually
| the first mile or the last). Cloudflare speedtest now has
| a packet loss tester that floods 1000 packets, although
| I'm not sure if it does it over an unreliable transport
| or not.
| FujiApple wrote:
| I agree regarding documentation. There was a request [0]
| for something similar, though not specifically covering
| this important point.
|
| Regarding sending a ping flood, Trippy allow you to
| reduce the minimum and maximum round time (and grace
| period) to send packets almost as fast as you like. For
| example, to send at 50ms intervals (with a 10ms grace
| period):
|
| > trip example.com -i 50ms -T 50ms -g 10ms
|
| [0] https://github.com/fujiapple852/trippy/issues/853
| linsomniac wrote:
| It's probably tricky but if there's loss at D, maybe only
| then materialize the display of the loss backwards until
| there is no loss: C? B? A? It gets tricky though where
| maybe there is a small loss at D, but say that C and B
| have chronic loss because of throttling in the slow path
| responses.
|
| If D has 1% loss and B and C have 50%, is it fair to say
| A=0, B=1%, C=1%, D=1%?
|
| MTR display of loss is indeed confusing, but when weird
| things are going on it can be helpful just stare at it a
| while to see what's going on. Trippy looks fantastic, and
| I need to play with it, but there are cases where I just
| want to stare at the path loss for a while.
|
| There's no way to influence the TTL on TTL timed-out
| responses, is there? That'd be pretty cool if there were
| some way to get the return path of the intermediaries to
| reply.
| mrngm wrote:
| 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/defa
| ult/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!
| commandersaki wrote:
| Yep 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 wrote:
| 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.
| jph wrote:
| Nice app! I'm curious, how did you accomplish all the package
| managers?
|
| I added Trippy to my list of Rust favorites:
| https://github.com/sixarm/cargo-install-favorites
| FujiApple wrote:
| Thank you for adding Trippy to your list.
|
| > how did you accomplish all the package managers?
|
| In most cases I didn't do anything! I've discovered that there
| are many kind souls out there who are willing to give up their
| free time to package and maintain 3rd party applications for a
| variety of systems they wish to support. It's tedious and, I
| suspect, usually thankless work. I am very grateful to all of
| those who have helped with this for Trippy.
| jay-barronville wrote:
| Open-source FTW! Great work, by the way! I'm playing with
| Trippy right now.
___________________________________________________________________
(page generated 2023-12-10 23:01 UTC)