You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today, trippy allow the usage of icmp, udp or tcp for the path discovery.
I would suggest a mode "all" to launch the discovery in parallel to have faster output.
I use this tool today to achieve this : flyingroutes
The text was updated successfully, but these errors were encountered:
to launch the discovery in parallel to have faster output.
Can provide more colour on the motivation here? I'm not sure how running these in parallel would improve performance. Trippy operates in rounds with a default min/max round time of 1s, but you can reduce this if you wish to trace at a faster rate.
For example, to trace with 250ms round times (50ms grace period):
trip -i 250ms -g 50ms -T 250ms example.com
Running ICMP, UDP and TCP tracing in parallel has a challenge in that the latter two provide no simple way to associated the ICMP responses with the motivating packet (this is why Trippy currently only allows multiple tracing for ICMP tracing). I suppose it would work if you limit it to exactly 1x UDP and 1x TCP trace along with the 1x ICMP trace. I haven't studied the project you linked, how do they resolve this issue?
I was too short in my use case description indeed. The interest was mainly in a corporate environment where you may need to switch protocols depending on how the network/firewall is configured. It requires in this case to see which protocol is "working".
Reading the code, the project asynchronously send the differents UDP/TCP/ICMP packets and aggregate the ICMP answers to create the answer graph.
Today, trippy allow the usage of icmp, udp or tcp for the path discovery.
I would suggest a mode "all" to launch the discovery in parallel to have faster output.
I use this tool today to achieve this : flyingroutes
The text was updated successfully, but these errors were encountered: