Why can a later hop in a traceroute show lower latency than an earlier one?
Show the answer
Say this first
Each hop's time measures something different: the round trip to that router plus the time its control plane took to build the ICMP reply. Transit traffic is forwarded in hardware, but a TTL-expired probe is punted to the CPU and answered at low priority, so a busy router looks slow while the hops behind it look fast. Each router also sends its reply back by its own routing, which may be a different path. Only an increase that persists to every later hop and the destination is real latency.
Go deeper
The reasons
- ICMP generation is slow path. The probe is punted to the CPU, which builds the time exceeded at low priority and often behind CoPP. That delay is added to that hop's line only.
- Different return paths. Hop 5 may reply over a congested link while hop 6 replies over a clean one.
- MPLS cores. A P router that expires the TTL often has no route to your source. Commonly it sends the time exceeded onward along the label switched path to the egress PE, which routes it back. Every core hop then shows about the same time: the trip to the far edge and back.
Real latency looks different
A jump that stays is distance or congestion. Light in fiber covers about 200 km per millisecond, so each 100 km of fiber adds about 1 ms of round trip. A step from 8 ms to 80 ms that holds for every later hop is usually an ocean crossing, not a fault.
How to read it
Judge by the destination's RTT and the trend across hops. A hop whose high time is not carried by the hops after it is a slow responder, not a slow link.
They will ask next
How would you measure the latency users actually feel to a service?
Measure with the application's own protocol: the TCP handshake time in a capture,
curl -wtiming, or a TCP-based probe. ICMP to routers on the way is a weak proxy.
Traps
- Blaming a router because its own hop shows 200 ms while the destination answers in 30 ms.