IPv4 anycast from India (RailTel AS24186 → Airtel AS9498) lands on AMS edge instead of SIN; IPv6 correctly lands on SIN

General
1

Hi all,

My app runs in sin, but from India my IPv4 traffic to Fly’s anycast is routed to the Amsterdam edge and then backhauled to Singapore. Over IPv6 from the same machine and connection, traffic reaches the Singapore edge directly. That makes IPv4 roughly 3× slower and adds ~300 ms per request round trip.

Setup

  • Location: India
  • ISP: RailTel (AS24186). Its IPv4 upstream is Bharti Airtel (AS9498), and its IPv6 upstream is Reliance Jio (AS55836).
  • App region: sin
  • Fly IPv4 (shared): 66.241.125.98
  • Fly IPv6: 2a09:8280:1::b7:fdd6:0
  • Tested: 2026-10-25, ~08:20–08:40 UTC

IPv4 → AMS edge

$ mtr -n -r -c 10 -w 66.241.125.98
HOST: fedora          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1      0.0%    10    1.4   1.5   1.4   1.7   0.1
  2.|-- ???             100.0    10    0.0   0.0   0.0   0.0   0.0
  ...
  6.|-- 122.185.147.169 90.0%    10   10.1  10.1  10.1  10.1   0.0   # Airtel AS9498
  7.|-- 116.119.33.228   0.0%    10  108.0 107.9 107.0 111.1   1.2   # Airtel AS9498
  8.|-- 185.1.226.199    0.0%    10  137.5 137.6 137.2 138.2   0.3   # as57463.226.199.netix.net
  9.|-- 185.1.222.47     0.0%    10  144.7 144.7 144.2 145.3   0.4   # speed-ix.cdn77.com (NL)
 10.|-- 169.150.194.34   0.0%    10  145.0 144.9 144.5 145.3   0.2   # vl232.ams-eq6-core-2.cdn77.com
 11.|-- 79.127.194.83    0.0%    10  137.9 137.7 137.0 138.7   0.5   # vl221.ams-eq6-dist-1.cdn77.com
 12.|-- 66.241.125.98    0.0%    10  142.1 142.2 141.6 142.9   0.5

The response headers confirm the AMS edge:

$ curl -sI http://66.241.125.98/
via: 2 fly.io, 2 fly.io
fly-request-id: 01M5S2D0XKTAV10ASTPCZJRPCS-ams

More IPv4 request IDs, all -ams:

  • 01M5S31V4A4EPWTTFK77R5RCXX-ams
  • 01M5S31VYNVQB4SZV3WBBB9MJ0-ams
  • 01M5S31WQD1WQJWBSBWN32C7EC-ams

TCP connect time over IPv4 is about 156 ms.

IPv6 → SIN edge (expected)

$ mtr -6 -n -r -c 10 -w 2a09:8280:1::b7:fdd6:0
  1.|-- <home router>                            0.0%    10    1.5   1.5   1.4   1.6   0.1
  2.|-- 2401:b200:2060:8::1                      0.0%    10    3.9   4.0   3.3   5.3   0.5   # RailTel AS24186
  ...
  7.|-- 2405:203:881::3a9                        0.0%    10   10.0  10.4   9.4  13.4   1.1   # Jio AS55836
 10.|-- 2001:de8:4::6:68:1                       0.0%    10   58.5  59.2  58.5  61.2   0.8   # 60068.sgw.equinix.com
 12.|-- 2a02:6ea0:1:5::33                       30.0%    10   59.4  86.3  59.4 127.4  24.8
 13.|-- 2a09:8280:1::b7:fdd6:0                   0.0%    10   60.8  59.6  59.0  60.8   0.5

fly-request-id: 01M5S32FVRKN3TA0C64SG52QT2-sin

TCP connect time over IPv6 is about 61 ms.

It’s not just my IP

Other Fly IPv4 anycast addresses also go to AMS from this network. debug.fly.dev behaves the same way:

Address Edge TCP connect
77.83.140.164 (v4) ams 146 ms
37.16.16.7 (v4) ams 148 ms
37.16.21.10 (v4) ams 148 ms
2a09:8280:1::1:2 (v6) sin 61 ms

All IPv4 paths exit Airtel and enter CDN77/Datacamp (AS60068) in Amsterdam, through NetIX and Speed-IX. The IPv6 path enters the same AS60068 at Equinix Singapore. So it looks like Airtel AS9498 prefers a European path to Fly’s IPv4 prefixes, possibly because of how they’re announced or prepended toward Airtel in Asia.

Impact

For each uncached request, the round trip is India → AMS → SIN → AMS → India, about 300+ ms, compared with about 60 ms when routed correctly. I run a DNS-over-TLS resolver on Fly, so every uncached lookup takes about 320 ms over IPv4.

Could someone on the networking side look at how Fly’s IPv4 anycast prefixes are announced to or received by Airtel (AS9498) in Asia? I’m happy to run more tests (mtr, traceroutes to specific prefixes, etc.) if that helps.

Thanks!