>Many routers deprioritize or drop ICMP to save CPU.
Not exactly.
Most big routers have ASICs (custom silicon) that can handle the bulk of routing decisions, like an interface card will have a chip that can directly determine where a packet needs to go and forwards it there. These are extremely fast, but limited, and are called "fast path".
Aside: Too many ACLs is a common way that packets fall off the fast path, and is why routers on the public Internet will happily forward along bogon traffic that by it's very nature is just wasting bits on the pipes.
There are some things that the fast path cannot handle, and generating ICMP TTL exceeded messages is one of them. Those go over to the router CPU, which historically has been insanely underpowered. Back when I was doing more routing it was common to have host CPUs in the multi-GHz range with multiple cores, but routers of a similar class would have a 100MHz MIPS CPU.
That's why, as the article goes on to explain, "*"s in the traceroute may not indicate a problem. It's not necessarily a literal deprioritization of ICMP.
If you ever see packet loss in a trace at one step but the steps after it aren't showing it, you can ignore that packet loss, it's likely a CPU limitation on a busy router.
> If you ever see packet loss in a trace at one step but the steps after it aren't showing it, you can ignore that packet loss, it's likely a CPU limitation on a busy router.
Trippy now includes [0] forward loss (Floss) and backward loss (Bloss) _heuristics_ to help surface such behaviour.
The idea was inspired by our previous discussion [1] on the topic on HN some time ago!
These columns are experimental and so not shown by default but can be enabled [2].
a blog about traceroute in 2026. imagine that. hard to believe it could possibly be of any interest at all, especially written by someone that only just discovered it. but i'm oh so glad i stopped in, to learn about trippy! it looks amazing.
So these types of routers are typically running at 100% CPU and - likely - not keeping up with packets that are not in the fast path? Ie the operators really only care about the packets in the fast path, all others can be ignored?
Or are there other types of packets in the slow path that do get a delivery guarantee by the router?
I worked on a board (a switch, not a router) with a chip that could saturate all 10 of its GigE ports all day long if you stayed in the fabric. But if you had to pass anything over to the built-in single-core 250 MHz CPU, you were in for a bad time. (Thankfully it also had pins for wiring up your own external CPU.)
Why is it not on the fast path by now? Creating a single packet that doesn't need to be kept tracked of is a basic thing that shouldn't require that much ASIC space.
MTR is a must have tool for any time you need tracert. I personally have used WinMTR for many years. An invaluable tool when you have connectivity issues to diagnose.
Reading the article and the comments reminded me: Every generation -discovers- learns their foundations anew.
I learnt about traceroute, ping and other network setup basics in my very first job (early 90s) as a network admin in a remote building in Bangalore, setting up the very first WAN for some of the earliest tech (now) behemoths, when the latency of the WAN -- over the SEA-ME-WE cables -- exceeded ~1-2 seconds. The satellite hops via EU added more latency. Traceroute and ping where your best friends to diagnose the frequent drops, from the building top microwave antenna to the only ISP (govt approved, of course) that offered a whopping 2x 64 kbps links. And that supported an entire org of 400-500 developers, including state-of-the-art video conf system to NYC, Ottawa, Tokyo.
Curious to figure out how these tools worked, I borrowed copies of the bible (TCP/IP Illustrated - W Richard Stevens [1]), still the most authentic source of all things TCP/IP related.
I'm not one for nostalgia, but fond memories there. Great to see a modern Rust impl though.
ICMP echo request/reply is handy for determining if a route exists at all ...
(reads article - I've got a five digit /. ID and that was after lurking for several years - respond first, ask questions/read article later)
Oh. You now fail to understand networks in Rust instead of C/Python/nicker elastic. sighs in policy based routing tables.
A modern mtr (traceroute is so 90's) should do things like run up and down the stack for each point along a route. It will still probably need to use the TTL field to find each point (IP) but then use ICMP/TCP/UDP/etc to measure that point in some way or perhaps interpolate it from points either side.
When I want to really get to grips with latency and stuff, I start off with a small dedicated box on a customer network and "smoke ping" with all points measurable on the path. I also have several running from our datacentre and a fair few RIPE Atlas probes too.
traceroute is handy but you must be able to decipher what it is telling you. Wearing a stethoscope does not make you a doctor.
Couldn't traceroute run the entire TTL range in parallel, assuming the destination host was reachable and replies are disambiguable? I always hated waiting for traceroutes with lots of non responding routers.
Once upon a time (early 90s) I read a very funny story on traceroute featuring parrots, one named Polly, and shotguns. But I can’t find it. It might have been in a Usenet group. I would love to find it again.
Funny timing of this, just last night I experimented with AI building an "ip intelligence" tool that includes a fast traceroute function and a bunch of IP information (ASN, organization, geolocation, CIDR info, DNSBL, reverse IP... mtr is my go-to for network traces, but (given root permissions) the trace it'll run in less than a second.
tracepath on Linux does not need the CAP_NET_RAW capability (or full root capabilities) during network data processing because it relies on the Linux socket error queue behavior. I assume traceroute on OpenBSD opens all required sockets and immediately drops privileges.
Dude had to rewrite traceroute to discover what the first line of the man page description says.
> traceroute tracks the route packets taken from an IP network on their way to a given host. It utilizes the IP protocol's time to live (TTL) field and attempts to elicit an ICMP TIME_EXCEEDED response from each gateway along the path to the host.
>Many routers deprioritize or drop ICMP to save CPU.
Not exactly.
Most big routers have ASICs (custom silicon) that can handle the bulk of routing decisions, like an interface card will have a chip that can directly determine where a packet needs to go and forwards it there. These are extremely fast, but limited, and are called "fast path".
Aside: Too many ACLs is a common way that packets fall off the fast path, and is why routers on the public Internet will happily forward along bogon traffic that by it's very nature is just wasting bits on the pipes.
There are some things that the fast path cannot handle, and generating ICMP TTL exceeded messages is one of them. Those go over to the router CPU, which historically has been insanely underpowered. Back when I was doing more routing it was common to have host CPUs in the multi-GHz range with multiple cores, but routers of a similar class would have a 100MHz MIPS CPU.
That's why, as the article goes on to explain, "*"s in the traceroute may not indicate a problem. It's not necessarily a literal deprioritization of ICMP.
If you ever see packet loss in a trace at one step but the steps after it aren't showing it, you can ignore that packet loss, it's likely a CPU limitation on a busy router.
> If you ever see packet loss in a trace at one step but the steps after it aren't showing it, you can ignore that packet loss, it's likely a CPU limitation on a busy router.
Trippy now includes [0] forward loss (Floss) and backward loss (Bloss) _heuristics_ to help surface such behaviour.
The idea was inspired by our previous discussion [1] on the topic on HN some time ago!
These columns are experimental and so not shown by default but can be enabled [2].
[0] https://github.com/fujiapple852/trippy/blob/master/RELEASES....
[1] https://news.ycombinator.com/item?id=38591827
[2] https://trippy.rs/reference/column
a blog about traceroute in 2026. imagine that. hard to believe it could possibly be of any interest at all, especially written by someone that only just discovered it. but i'm oh so glad i stopped in, to learn about trippy! it looks amazing.
Trippy looks so cool. I'm glad I wrote this article, if just to find out about Trippy.
So these types of routers are typically running at 100% CPU and - likely - not keeping up with packets that are not in the fast path? Ie the operators really only care about the packets in the fast path, all others can be ignored?
Or are there other types of packets in the slow path that do get a delivery guarantee by the router?
I’m curious how these tradeoffs are made.
I worked on a board (a switch, not a router) with a chip that could saturate all 10 of its GigE ports all day long if you stayed in the fabric. But if you had to pass anything over to the built-in single-core 250 MHz CPU, you were in for a bad time. (Thankfully it also had pins for wiring up your own external CPU.)
Why is it not on the fast path by now? Creating a single packet that doesn't need to be kept tracked of is a basic thing that shouldn't require that much ASIC space.
2002 - Estimating Router ICMP Generation Delays[0]
2015 - Characterizing ICMP Rate Limitation on Routers[1]
[0] https://pages.cs.wisc.edu/~suman/courses/640/papers/govindan...
[1] https://inria.hal.science/hal-01111190/document
I prefer to use mtr these days.
homepage: https://www.bitwizard.nl/mtr/
excellent article on using mtr: https://www.cloudflare.com/learning/network-layer/what-is-mt...
MTR is a must have tool for any time you need tracert. I personally have used WinMTR for many years. An invaluable tool when you have connectivity issues to diagnose.
https://github.com/WinMTR/WinMTR-Official
mtr is spectacular, highly recommended.
Reading the article and the comments reminded me: Every generation -discovers- learns their foundations anew.
I learnt about traceroute, ping and other network setup basics in my very first job (early 90s) as a network admin in a remote building in Bangalore, setting up the very first WAN for some of the earliest tech (now) behemoths, when the latency of the WAN -- over the SEA-ME-WE cables -- exceeded ~1-2 seconds. The satellite hops via EU added more latency. Traceroute and ping where your best friends to diagnose the frequent drops, from the building top microwave antenna to the only ISP (govt approved, of course) that offered a whopping 2x 64 kbps links. And that supported an entire org of 400-500 developers, including state-of-the-art video conf system to NYC, Ottawa, Tokyo.
Curious to figure out how these tools worked, I borrowed copies of the bible (TCP/IP Illustrated - W Richard Stevens [1]), still the most authentic source of all things TCP/IP related.
I'm not one for nostalgia, but fond memories there. Great to see a modern Rust impl though.
[1] https://en.wikipedia.org/wiki/W._Richard_Stevens
This is the only document you need to understand traceroute:
https://archive.nanog.org/meetings/nanog47/presentations/Sun...
I learned everything I need to know about tracert from NextGenHacker101:
https://www.youtube.com/watch?v=SXmv8quf_xM
OMG This is the greatest tech youtube video ever.
Also see, Traceroute isn't real, or: Whoops! Everyone Was Wrong Forever: https://gekk.info/articles/traceroute.htm
ICMP echo request/reply is handy for determining if a route exists at all ...
(reads article - I've got a five digit /. ID and that was after lurking for several years - respond first, ask questions/read article later)
Oh. You now fail to understand networks in Rust instead of C/Python/nicker elastic. sighs in policy based routing tables.
A modern mtr (traceroute is so 90's) should do things like run up and down the stack for each point along a route. It will still probably need to use the TTL field to find each point (IP) but then use ICMP/TCP/UDP/etc to measure that point in some way or perhaps interpolate it from points either side.
When I want to really get to grips with latency and stuff, I start off with a small dedicated box on a customer network and "smoke ping" with all points measurable on the path. I also have several running from our datacentre and a fair few RIPE Atlas probes too.
traceroute is handy but you must be able to decipher what it is telling you. Wearing a stethoscope does not make you a doctor.
Couldn't traceroute run the entire TTL range in parallel, assuming the destination host was reachable and replies are disambiguable? I always hated waiting for traceroutes with lots of non responding routers.
Once upon a time (early 90s) I read a very funny story on traceroute featuring parrots, one named Polly, and shotguns. But I can’t find it. It might have been in a Usenet group. I would love to find it again.
This one? https://www.gumbynet.com/traceroute/trt-parrots.html
Funny timing of this, just last night I experimented with AI building an "ip intelligence" tool that includes a fast traceroute function and a bunch of IP information (ASN, organization, geolocation, CIDR info, DNSBL, reverse IP... mtr is my go-to for network traces, but (given root permissions) the trace it'll run in less than a second.
https://github.com/linsomniac/ipq
Try running traceroute against the bad.horse address for a chuckle.
EDIT: You probably to increase the maximum hop count for it to fully work.
tracepath on Linux does not need the CAP_NET_RAW capability (or full root capabilities) during network data processing because it relies on the Linux socket error queue behavior. I assume traceroute on OpenBSD opens all required sockets and immediately drops privileges.
Dude had to rewrite traceroute to discover what the first line of the man page description says.
> traceroute tracks the route packets taken from an IP network on their way to a given host. It utilizes the IP protocol's time to live (TTL) field and attempts to elicit an ICMP TIME_EXCEEDED response from each gateway along the path to the host.
[dead]