Distributed Metrics
Traceroute
Debug a disabled traceroute protocol, missing multipath strategies, or failed probes — and verify traceroute works on your network with trippy
Overview
Bitping nodes perform traceroutes using trippy — an open-source, modern traceroute implementation that supports ICMP, UDP, and TCP probes across three different multipath strategies. When your node starts, it probes each strategy independently and reports which ones work on your network.
A traceroute job traces the per-hop path from your node to a target host, capturing each hop’s IP address, hostname, and round-trip latency. To do this reliably across different network paths and load balancers, trippy supports three strategies:
| Strategy | What it does | When it’s used |
|---|---|---|
| Classic | Standard traceroute. Increments TTL on each probe and reads back ICMP TTL-exceeded responses | Default fallback. Works almost everywhere |
| Paris | Holds the flow identifier constant across probes so all packets follow the same ECMP path | Detecting per-hop latency without load-balancer noise |
| Dublin | Enumerates every ECMP path between you and the target by varying the flow identifier deliberately | Mapping multi-path routes (CDNs, anycast networks) |
If your node reports traceroute as enabled but only some strategies are supported, that’s expected on certain networks — see the dropdowns below for what each strategy needs.
Privilege Requirements
Traceroute uses raw network sockets, so it has the same privilege requirements as Ping (ICMP).
Linux — run the node with sudo, or grant the binary CAP_NET_RAW:
sudo setcap cap_net_raw+ep $(which bitpingd)macOS — run with sudo, or install via the Bitping Desktop app (it requests the right permissions at install).
Windows — run the node as Administrator.
A single CAP_NET_RAW capability covers both Ping and Traceroute on Linux.
Multipath Strategies
Classic
The baseline strategy. Sends one probe per TTL and reads ICMP time-exceeded responses to map hops. This is what most traceroute and mtr implementations do by default.
Falls back to unprivileged mode if raw sockets aren’t available. If Classic is the only strategy your node reports as supported, your node is running unprivileged — grant raw socket access (above) to unlock Paris and Dublin.
Common failure — strict outbound ICMP filtering. If a firewall drops all ICMP, Classic over ICMP will show 0 hops. Switching to UDP or TCP probes usually works around this.
Try it locally with trippy:
sudo trip --multipath-strategy classic 1.1.1.1Paris
Keeps the flow identifier (the 5-tuple of source/dest IP, ports, and protocol) constant across probes so every packet hashes to the same path through ECMP routers. Used when you want a stable, repeatable per-hop latency reading.
Requires privileged mode and UDP — there is no unprivileged fallback. If you see “paris not supported” but Classic works, your node is missing raw socket access. Fix that and Paris will light up automatically on the next restart.
Common failure — UDP port 33434 is blocked. Many corporate firewalls and mobile carriers drop outbound traffic to the default traceroute UDP port range.
Try it locally with trippy:
sudo trip --multipath-strategy paris --protocol udp 1.1.1.1Dublin
Like Paris, but deliberately varies the flow identifier to enumerate every ECMP path between your node and the target. This is the strategy that lets Bitping map anycast networks and CDN edge fan-out.
Requires privileged mode and UDP — same as Paris. If Dublin isn’t supported but Classic is, the fix is to grant raw socket access.
Common failure — same as Paris (UDP filtering), plus carrier-grade NAT can collapse multiple paths into one, making Dublin look like Paris.
Try it locally with trippy:
sudo trip --multipath-strategy dublin --protocol udp 1.1.1.1Test Traceroute on Your Network with Trippy
The fastest way to confirm your network actually allows traceroute is to run trippy yourself.
Install trippy:
| Platform | Command |
|---|---|
| macOS | brew install trippy |
| Linux (any) | cargo install trippy |
| Debian/Ubuntu | apt install trippy (24.04+) |
| Arch | pacman -S trippy |
| Windows | winget install trippy |
| Nix | nix-shell -p trippy |
Full install options at trippy.rs.
Then try one command per protocol:
# ICMP — the most common, requires raw sockets
sudo trip --protocol icmp 1.1.1.1
# UDP — needed for Paris and Dublin multipath
sudo trip --protocol udp 1.1.1.1
# TCP — useful when both ICMP and UDP are filtered
sudo trip --protocol tcp --target-port 443 1.1.1.1On macOS you can swap sudo for trippy’s unprivileged mode:
trip --unprivileged 1.1.1.1What to look for:
- Hops reach the target (
1.1.1.1shows up on the last line) → traceroute works on your network for that protocol - 0 hops or
* * *for every row → that protocol is filtered. Try a different--protocolvalue - Hops appear but stop midway → upstream filtering past your ISP. Not something the node can fix, but Bitping jobs that don’t need a full path will still work
If trippy can complete a traceroute on a given protocol from your machine but the Bitping Node reports it as disabled, the most likely cause is that the node is missing raw socket permissions — re-check the Privilege Requirements section above.
IPv4-only Mobile Carriers (NAT64/DNS64)
On IPv4-only mobile networks that use DNS64/NAT64, traceroute will automatically resolve IPv4 targets to synthetic IPv6 addresses (e.g. 1.1.1.1 becomes 64:ff9b::101:101). Seeing IPv6 hops in this case is expected and not a failure.
You can confirm this with trippy:
sudo trip 1.1.1.1
# Hops show 64:ff9b::101:101 instead of 1.1.1.1 — that's NAT64, working as intendedStill Stuck?
If trippy works on your machine but the node still reports traceroute as disabled, reach out at [email protected] or Telegram with:
- Node version and operating system
- Which strategies are disabled and the tooltip error message
- The output of one of the trippy commands above
- The first few lines of
bitpingd runshowing capability checks
See also: Troubleshooting Protocol Failures and Troubleshooting Connectivity.
