Traffic from my AT&T residential connection in the Atlanta, GA metro to Fly’s anycast IPv4 is being routed to the NRT (Tokyo) edge instead of ATL (or any US edge), adding ~150ms to every request. My app is latency-sensitive (terminal streaming over WebSockets), so this makes it unusable from my home connection.
Details:
- App:
exoterm (dedicated IPv4 66.241.124.158), single machine in dfw
- Source IP:
99.48.55.165 — AT&T (AS7018), 99.48.0.0/13, Cumming, GA (Atlanta metro)
- Observed edge:
nrt — e.g. fly-request-id: 01KX78GVEYCCF9A9W2ECHW3JA4-nrt (2026-07-11 00:16 UTC)
- Ping to
66.241.124.158: 157ms avg (steady, 0% loss). Ping to 8.8.8.8 from the same connection: <10ms, so this is specific to Fly’s prefix.
Traceroute (AT&T hands off to Tata AS6453, which carries it across the Pacific):
traceroute to 66.241.124.158, 20 hops max
1 192.168.42.1 4.713 ms
2 192.168.1.254 4.130 ms
3 104.177.180.1 4.912 ms <- AT&T
4 107.212.168.180 15.491 ms <- AT&T
8 64.86.9.66 177.129 ms <- Tata (AS6453)
11 64.86.252.33 177.779 ms <- Tata
14 209.58.61.98 175.944 ms <- Tata
(remaining hops filtered)
Control test: From AT&T cellular (AT&T Mobility, separate ASN from wireline AS7018) at the same location, I land on the iad edge — a reasonable US path. The Tokyo routing only happens on the AT&T wireline (AS7018) → Tata (AS6453) path.
Could you look at the announcement/localpref for this prefix as seen by Tata from AS7018 wireline paths? AT&T Mobility reaches you fine; it’s specifically the AS7018 → Tata route that prefers your Asia edges. Happy to run more traceroutes/MTRs on request.
can you post the full traceroute without the remaining hops filtered please?
Hey, thanks for the quick response!
Full traceroute below (ICMP, 3 probes/hop, hostnames resolved). UDP traceroute takes the identical path.
traceroute to 66.241.124.158 (66.241.124.158), 20 hops max, 48 byte packets
1 192.168.42.1 (192.168.42.1) 3.691 ms 2.668 ms 2.629 ms
2 192.168.1.254 (192.168.1.254) 4.719 ms 3.471 ms 3.451 ms
3 104-177-180-1.lightspeed.tukrga.sbcglobal.net (104.177.180.1) 4.567 ms 4.824 ms 6.284 ms
4 107.212.168.180 (107.212.168.180) 4.568 ms 4.536 ms 6.581 ms
5 * * *
6 * * *
7 * * *
8 if-bundle-2-2.qcore1.a56-atlanta.as6453.net (64.86.9.66) 178.288 ms 177.338 ms 177.119 ms
9 if-bundle-27-2.qcore1.dt8-dallas.as6453.net (64.86.113.6) 177.678 ms 178.232 ms *
10 * * *
11 * * *
12 if-ae-59-2.tcore1.av3-toyohashi.as6453.net (180.87.149.4) 176.621 ms 177.398 ms *
13 if-bundle-58-2.qcore2.tv2-tokyo.as6453.net (180.87.180.153) 185.212 ms 177.312 ms *
14 if-ae-56-2.tcore2.tv2-tokyo.as6453.net (209.58.61.98) 176.244 ms 176.739 ms 186.274 ms
15 180.87.181.82 (180.87.181.82) 160.447 ms 160.221 ms 160.723 ms
16 * * *
17 ip-66-241-124-158.shared.customer.flyio.net (66.241.124.158) 156.947 ms 158.611 ms 156.686 ms
So the path is: AT&T (Atlanta) → Tata Atlanta (a56-atlanta) → Tata Dallas (dt8-dallas) → Tata Toyohashi (av3-toyohashi) → Tata Tokyo (tv2-tokyo) → Fly NRT edge.
Note hop 9: the packet transits Tata’s Dallas core — the same metro as your DFW edge (and my app’s machine) — and Tata still carries it across the Pacific to NRT. So Tata appears to only be picking up your anycast announcement in Asia, not from any of your US PoPs.
(Tata hops all show ~177ms including the Atlanta one, so the ICMP return path from inside AS6453 is also coming back via Asia — consistent with Tata simply not having a US route for this prefix.)
thanks, should be fixed now.
You are amazing! I owe you a beverage of your choice. Cheers, mate!