Trippy combines repeated route probing, an interactive terminal view and exportable reports. Use it to compare ICMP and TCP observations, then turn the results into useful incident evidence.
Applies to: Linux, including Ubuntu; package availability and privileges depend on the installed release.
Verification: Command options checked against upstream documentation on November 6, 2026. Sample addresses and measurements below are illustrative; these are not captured results from a production network.
What you need
- A Linux machine and permission to probe the destination network.
- Trippy installed, with its
tripexecutable on your path. - The privileges needed to open raw sockets. The examples use
sudoon Linux; a distribution may configure capabilities instead.
No commands in this article were run against the example destinations during publication.
Trippy and MTR: choose the view you need
Trippy is a Rust-based network diagnostic tool inspired by mtr. It combines traceroute-style path discovery with repeated measurements and offers a terminal interface, multipath tracing strategies and machine-readable reports.
Treat Trippy as another tool in your diagnostic kit. This tutorial does not claim that Ubuntu has deprecated or replaced mtr. MTR also supports TCP and UDP probing; changing the protocol is not an exclusive Trippy feature. Check the options supported by the version installed on your host.
Trippy’s practical advantages include an interactive view of changing measurements, configurable tracing strategies, and reports you can attach to incident tickets. Rust provides memory-safety protections, but a tool written in Rust is not automatically free of security bugs.
Install and check your version
First check whether your configured Ubuntu repositories provide the package:
apt-cache policy trippyIf a candidate is available, install it using your normal package-management policy:
sudo apt update
sudo apt install trippy
trip --version
trip --helpIf there is no candidate, consult the upstream installation guide for a method supported by your distribution and release. Do not assume instructions for an older Ubuntu PPA apply to Ubuntu 26.04. Adding a repository is a separate trust decision.
1. Simple: inspect a route interactively
Start with the default ICMP tracing mode:
sudo trip example.comReplace example.com with a destination you are authorized to test. The terminal view refreshes as measurements arrive. The exact columns, layout and key bindings depend on your Trippy version and configuration; use its built-in help for the current bindings.
Illustrative terminal view
This compact, TUI-style excerpt shows the information to look for. It is a teaching example, not a verbatim screenshot or a claim about the live route to example.com. Times are in milliseconds.
Trippy example Target: example.com Protocol: ICMP
Hop Hostname Loss% Snt Last Avg Best Wrst StDev Status
1 gateway (192.168.1.1) 0.0% 60 1.2 1.1 0.9 2.4 0.2 ✔
2 10.0.0.1 0.0% 60 4.1 4.5 3.8 7.9 0.5 ✔
3 transit.example.net 0.0% 60 12.5 13.4 11.2 24.5 2.1 ✔
4 192.0.2.10 1.7% 60 14.1 14.3 13.5 19.8 0.8 ⚠
5 destination.example.com 0.0% 60 13.9 13.8 13.2 14.6 0.2 ✔
[RTT History: illustrative sparkline]
Hop 4 ─── █_▆_██__▆██_█_▆_██__▆██_█_▆_██_Read Snt as probes sent and Loss% as missing probe responses at that hop. Last, Avg, Best and Wrst summarize round-trip time; StDev describes its variation. These are observations of probe responses, not direct measurements of every application’s traffic.
Here, hop 4 misses a response while the destination reports 0% loss. A router may rate-limit or deprioritize replies addressed to itself while continuing to forward traffic normally. Investigate sustained loss that continues to later hops and the destination, then correlate it with application measurements.
2. Intermediate: compare TCP probes toward HTTPS
Suppose a production API intermittently returns HTTP 502 responses. An ICMP trace alone cannot reproduce the behavior of an HTTPS connection. Compare it with TCP probes directed at the service port:
sudo trip production-api.example.net -p tcp -P 443-p tcp selects TCP probing; -P 443 selects the destination port. Replace the hostname with your approved target.
A TCP probe may be treated differently by a firewall from an ICMP probe. It does not bypass access controls, perform an HTTP request, validate TLS, or prove that the application works. A 502 response may originate at a proxy or its upstream service even when the network path looks healthy.
Export a bounded table for a ticket
Add -m pretty for a text table and -C 20 for twenty reporting cycles:
sudo trip production-api.example.net -p tcp -P 443 -m pretty -C 20The following is an illustrative table excerpt. Hostnames use example domains and documentation/private addresses; column selection and table style may differ in your installed version.
+-----+----------------------------------+-------+-----+------+------+------+------+-------+
| Hop | Hostname | Loss% | Snt | Last | Avg | Best | Wrst | StDev |
+-----+----------------------------------+-------+-----+------+------+------+------+-------+
| 1 | core-switch (10.10.0.1) | 0.0% | 20 | 0.4 | 0.5 | 0.3 | 0.9 | 0.1 |
| 2 | edge-firewall (172.16.5.4) | 0.0% | 20 | 1.1 | 1.2 | 1.0 | 1.5 | 0.1 |
| 3 | transit-router (192.0.2.8) | 25.0% | 20 | 18.4 | 22.1 | 17.9 | 45.2 | 6.4 |
| 4 | api-edge (198.51.100.20) | 0.0% | 20 | 19.1 | 19.3 | 18.8 | 20.1 | 0.3 |
+-----+----------------------------------+-------+-----+------+------+------+------+-------+Interpretation: hop 3’s 25% missing responses do not establish 25% loss for the API. The destination reports 0% in this example. Compare repeated captures, destination loss and latency, proxy logs, upstream health, and the timing of the 502s before assigning blame to a carrier.
3. Advanced: produce a Markdown report for automation
A bounded report is useful after a deployment failure, during an approved incident check, or when comparing two network locations:
sudo trip k8s-ingress.example.net -p tcp -P 443 -m markdown -C 10-m markdown selects a Markdown table. -C 10 means ten reporting cycles, not necessarily ten packets in total: tracing can send probes for multiple hops within each cycle.
Illustrative generated report
The fenced example keeps the Markdown source visible so it can be copied into a ticket:
| Hop | Hostname | Loss% | Snt | Last | Avg | Best | Wrst | StDev |
|---|---|---|---|---|---|---|---|---|
| 1 | gateway (192.168.1.1) | 0.0% | 10 | 1.1 | 1.1 | 1.0 | 1.2 | 0.1 |
| 2 | transit (10.200.0.5) | 0.0% | 10 | 3.2 | 3.5 | 3.1 | 4.8 | 0.4 |
| 3 | edge.example.net | 0.0% | 10 | 8.4 | 8.9 | 8.2 | 11.0 | 0.7 |
| 4 | ingress.example.net | 0.0% | 10 | 9.1 | 9.2 | 8.9 | 9.8 | 0.2 |For software that consumes structured data, upstream also provides JSON and CSV modes. Choose the format your incident tooling expects and check the installed version’s output schema before parsing it.
A practical incident-capture script
This Bash script saves a short TCP trace in a private directory. It requires one explicit target, accepts an optional port, and validates inputs before invoking Trippy. It does not contact a webhook or install anything.
#!/usr/bin/env bash
set -euo pipefail
umask 077
if (( $# < 1 || $# > 2 )); then
printf 'Usage: %s HOST [PORT]\n' "$0" >&2
exit 2
fi
target=$1
port=${2:-443}
if [[ ! $target =~ ^[A-Za-z0-9][A-Za-z0-9.-]*$ ]]; then
printf 'Use a hostname or IPv4 address without a scheme or options.\n' >&2
exit 2
fi
if [[ ! $port =~ ^[1-9][0-9]{0,4}$ ]] || (( 10#$port > 65535 )); then
printf 'Port must be an integer from 1 to 65535.\n' >&2
exit 2
fi
command -v trip >/dev/null || { printf 'Trippy is not installed.\n' >&2; exit 1; }
report_dir=$(mktemp -d ./trippy-report.XXXXXX)
report_file="$report_dir/report.md"
# Run only against an approved destination; sudo may prompt interactively.
sudo trip "$target" -p tcp -P "$port" -m markdown -C 10 > "$report_file"
printf 'Saved diagnostic report: %s\n' "$report_file"Review the report before sharing it. Real traces can disclose internal hostnames, addresses and topology. In CI, use your organization’s approved raw-socket/capability policy rather than granting a runner unrestricted passwordless sudo. A report with missing replies is evidence to investigate, not an automatic verdict that a deployment failed.
Verify and troubleshoot
- Permission denied: check how your package grants raw-socket access. See the upstream privileges guide before changing capabilities or running elevated commands.
- Silent intermediate hops: compare later hops and the destination; missing router replies alone do not establish forwarding loss.
- No useful TCP response: confirm DNS, the selected port, the destination’s listener and applicable firewall policy. A trace cannot establish application health by itself.
- Different paths between runs: ECMP, address-family selection and topology changes can affect observations. Review Trippy’s documented multipath strategies before comparing captures as if every probe took one fixed route.
- 502 errors with a healthy trace: investigate the reverse proxy and upstream service as well as network telemetry.
Keep related Linux command examples and the networking and connectivity tutorial nearby when building an incident checklist.