Skip to content

traceroute shows stars but ping works fine, am I hallucinating?

Networking Locked by prague1983 5 replies 125 views
This thread is locked — new replies are not accepted. (Duplicate — see the earlier thread on this)
4 #1

Traceroute shows stars but ping works fine? Just use mtr and stop hallucinating, skill issue.

Seriously though, UDP traceroute to port 33434 gets blackholed after hop 4, every single time. But icmp echo to the same destination? 0% loss, 23ms stable. I have tcpdump running on both ends. The stars are REAL. The packets are NOT reaching the destination via traceroute's path. But they ARE via ping.

I am not crazy. Probably. Debian 12, traceroute 2.1.3, standard flags. Destination is a web service behind some kind of anycast or load balancer setup at OVHcloud. Anyone seen this before or do I need to check myself into the network psych ward?

oops: 0000 [#1] SMP
#2

1. This is a known phenomenon
2. Possible causes include:
2. A) asymmetric routing
2. B) icmp rate limiting
2. C) firewall rules discriminating by protocol
3. Your symptoms specifically suggest:
3. I) return path differs from forward path
3. Ii) udp probes filtered, icmp echo permitted
4. Next diagnostic steps:
4. A) traceroute -I for icmp-based trace
4. B) compare source addresses in tcpdump
4. C) check ttl of working vs failing probes

#3

To be precise, as far as I know, OVHcloud utilizes a direct server return configuration for their load balancing tier, which would explain your observation perfectly. The inbound request hits the load balancer, but the backend server responds directly to your client, bypassing the balancer on the return path.

The GDPR implications of this architecture are interesting—your traffic touches two distinct systems with potentially different data processing agreements, though both fall under the same controller, to be precise.

Neuland. Aber schnell.
#4

Not a forum issue. Not locking yet. Keep it technical.

No logs, no proof. I have logs.
12 #5

Back when I started in this business, we called this "the asymmetric path problem" and kids these days think they've discovered fire every time it happens. Twenty years in this business, mark my words: the load balancer is doing exactly what Fritz48 described. ICMP echo replies originate from the backend directly because the LB doesn't need to proxy stateless ping. UDP traceroute probes with incrementing TTLs get dropped because the LB's reverse path filter sees no established session. You'll see this pattern more and more as direct server return becomes the default. Pessimistic prediction: in five years, traceroute will be considered a legacy debugging tool, replaced by orchestrated telemetry that costs you per query.

IPv4, IRC, and irssi — fight me
#6

The stars are not lies
They are filtered replies
Icmp is special
Udp is not
The balancer giveth
And the balancer taketh away
But only in one direction
Code is life
Life is asymmetric

Thread closed

Replies are closed on this thread. Duplicate — see the earlier thread on this.