Install tracepath on Debian from the iputils-tracepath package, then point it at a host and read the output – no root, no sudo, no fuss. That is the whole reason to reach for it: tracepath debian gets you hop-by-hop tracing plus path MTU discovery from a locked-down user account where traceroute would demand elevated rights. It answers two questions at once. Where does the path break, and where does the maximum packet size shrink. This guide gets you from question to clear evidence in minutes.

Last updated: 2026-07-21

What tracepath is and why it exists

tracepath traces the route to a host and measures the path MTU at the same time. It ships as part of the iputils toolkit, the same family as ping and arping. The design goal was simple: give ordinary users a route tracer that needs no special privileges.

That last point is the whole story. Classic traceroute crafts raw packets, which needs root or a setuid binary. tracepath uses ordinary datagram sockets and the kernel's own MTU machinery instead. So it runs fine from any account, and it reports the smallest MTU it found along the way. tracepath can detect the MTU size along the path, which is the number you want when large transfers stall but small pings sail through.

So it is not a stripped-down traceroute. It trades a pile of protocol options for the one thing traceroute does not do out of the box: tell you where your packets get too big to pass.

Installing tracepath on Debian and Ubuntu

Run this first:

sudo apt install iputils-tracepath

On modern Debian and Ubuntu the binary lives in the iputils-tracepath package. Older muscle memory says tracepath is always preinstalled, and often it is, but on a minimal server image or a container it frequently is not. Do not assume – check.

Confirm it landed and works:

which tracepath
tracepath -V

The first prints the path to the binary, usually /usr/bin/tracepath. The second prints the iputils version, which tells you the build is functional and not a dangling symlink. If which comes back empty, the package did not install; read the apt output instead of retrying blindly. The official iputils project is where the source and the current option set actually live if you want to confirm what your build supports.

One quick sanity run proves the whole thing:

tracepath 1.1.1.1

If you get hop lines and a Resume: summary at the bottom, you are done. No root required, which is the point.

How the probes actually work

tracepath sends UDP probes with a stepping TTL and reads the ICMP errors that come back. The first probe goes out with a Time To Live of one. The first router decrements the TTL to zero, drops the packet, and returns an ICMP "time exceeded" message. That message carries the router's address, so you learn hop one.

Then tracepath raises the TTL by one and repeats, learning each next hop until the probes reach the destination. So far this is the same TTL trick every route tracer uses.

The MTU part is where tracepath differs. It sets the "don't fragment" bit on its probes. When a link along the path has a smaller MTU than the packet, the router that cannot pass it returns an ICMP "fragmentation needed" message stating the MTU it can handle. tracepath reads that number, shrinks its probe to fit, and keeps going. That is real path MTU discovery driven by the kernel, not a guess. Every place the reported MTU drops is a link you may need to account for.

The command-line options worth knowing

tracepath keeps a short option list, and each flag earns its place. Reach for each one by intent:

The -n flag is the one I use most, because a stalled DNS lookup makes a trace crawl and hides the real timing. If you want speed and a clean address list, -n is the answer. Use -b when you need both, for example when writing up a ticket for an ISP that wants the hostname and the IP side by side.

There is no -q on tracepath for query count – that is a traceroute flag. Do not copy it over from a traceroute cheat sheet and wonder why it errors.

Reading the output column by column

Read the pmtu values and the Resume: line first, then worry about individual hops. A typical run looks like this:

 1?: [LOCALHOST] pmtu 1500
 1: gateway 1.204ms
 2: 10.0.0.1 3.457ms asymm 3
 3: no reply
 4: 192.0.2.9 9.881ms pmtu 1480
...
 Resume: pmtu 1480 hops 12 back 11

Each line gives you the hop number, then the host or address, then the round-trip time. Three extra fields matter:

• pmtu shows the path MTU at that point. When it drops, as it did from 1500 to 1480 above, that hop introduced a smaller-MTU link. That drop is the headline finding for most MTU problems.
• asymm N means the reply came back over a path with a different hop count than the probe went out on. Read it as a hint about asymmetric routing, not a fault.
• no reply means the hop did not answer within the timeout. The router is staying quiet; the path past it can be fine.

The Resume: line summarizes it: the final path MTU, hops out, and hops back. If hops and back differ, your traffic takes different routes each way. Read that summary line before you start theorizing about any single hop.

What is the difference between tracepath and traceroute?

Privileges and MTU awareness are the real dividing line. tracepath runs without root and reports path MTU; traceroute needs elevated rights for its interesting modes but hands you far more protocol control. Pick by what you actually need.

Use tracepath when you are on a hardened box, you cannot get sudo, or you suspect an MTU black hole. Reach for traceroute when you need to probe a specific TCP service, force ICMP to dodge UDP filtering, or run the fuller option set. I keep both installed and switch based on the question in front of me. For a broader routine, this fits into how I work up a network problem layer by layer.

Tracing over IPv4 and IPv6

Modern iputils folds both families into one binary with -4 and -6. On current Debian and Ubuntu, tracepath -6 <host> traces over IPv6 and tracepath -4 <host> pins IPv4. Older systems shipped a separate tracepath6 command for the v6 path; if -6 is not recognized, that split binary is your fallback.

IPv6 changes the MTU story in a way worth knowing. IPv6 routers never fragment packets, so the sending host must handle path MTU discovery itself. The ICMPv6 "packet too big" messages tracepath relies on are not optional niceties; they are how the whole thing is supposed to work. If a firewall filters ICMPv6, IPv6 PMTUD breaks harder than the IPv4 equivalent, and large transfers hang while small ones succeed. tracepath over IPv6 is a clean way to spot exactly that.

Can tracepath use TCP instead of UDP?

No, and do not go hunting for a tracepath-tcp binary – it does not exist. tracepath speaks UDP only. That is a deliberate limit of the tool, not a flag you are missing.

When you need TCP probes, that is traceroute's job. Run traceroute -T -p 443 <host> to send TCP SYN packets at a real service port. TCP mode matters because plenty of firewalls drop UDP and ICMP while happily passing TCP to port 443 or 80. In that case UDP-based tracepath dies at the firewall, but a TCP trace walks straight through and shows you the hops beyond it. So the honest answer is: tracepath for MTU and quick non-root checks, traceroute -T when a firewall only tolerates TCP.

Why does tracepath stop early or show asymmetric paths?

An early stop almost always means a router stopped answering, not that the network is down. Three causes cover most of it.

First, ICMP filtering. Many routers and firewalls drop or rate-limit the ICMP replies tracepath depends on. When that happens you see no reply lines, and the trace may stall at that hop. The path past it can be perfectly healthy; the device just refuses to identify itself. Do not read silence as failure.

Second, asymmetric routing. The asymm field flags hops where the return path differs from the outbound path. This is normal on the wider internet, where traffic often leaves by one route and comes back by another. It skews the round-trip times but does not mean anything is broken.

Third, a PMTU black hole. If the path MTU keeps dropping and then probes vanish entirely at a certain size, a router is silently discarding oversized packets without sending the "fragmentation needed" message it should. That is the exact failure tracepath was built to expose. The pmtu column freezes, larger probes disappear, and now you know which link to fix. If you want to watch those discards from the kernel side, pair the trace with a look at where packets actually get dropped.

FAQ

Does tracepath need root on Debian?

No. It opens ordinary datagram sockets and leans on the kernel's own MTU discovery, so any unprivileged shell account runs it fine. That is exactly what the raw-packet modes of traceroute cannot claim; those still want root or a setuid binary. When a trace fails on Debian, look at DNS and firewall filtering long before you reach for sudo.

What does asymm mean in tracepath output?

It marks a hop whose reply came back across a different number of hops than the probe took going out. On the public internet that mismatch is routine and rarely a problem on its own. It does throw off the round-trip timing for that hop, so read those milliseconds with a grain of salt. Treat the flag as context about the route, not a red alert.

How is tracepath different from Windows tracert?

Windows tracert lines up with Linux traceroute, not with tracepath. tracert fires ICMP echo probes by default and stops after a maximum of 30 hops, where the Linux tools default to UDP. Neither Windows tool measures path MTU the way tracepath does, so there is no Windows command that gives you the MTU number out of the box.

Why do I see asterisks or "no reply" in a trace?

They mean no expected response was received for those probes within the timeout period. Nine times out of ten the path is still fine and one router just declines to answer. Check whether the hops after the quiet one keep responding before you blame that link.

Can I limit how many hops tracepath probes?

Yes. Pass -m with a hop count, for example tracepath -m 15 host, and the trace stops there. That keeps the output short when you only care about the first few hops near you. Pair it with -n to skip the DNS lookups and you get fast, raw-address results, which is what you want on an on-call check.

Related on this blog

• Track System Call Latency