Tigris/Fly anycast routing to ORD from Virginia (OVH)

Questions / Help
1

I’m on an OVH bare metal server in Vint Hill, VA (AS16276) and noticed my requests to t3.storage.dev are landing in ORD instead of IAD. My Tigris bucket is in IAD and the server is
basically next door to Ashburn, so this seems like a peering/BGP thing.

The endpoint resolves to 137.174.147.59 which geolocates to Chicago (Equinix). The X-Tigris-Served-From header does say iad, so the data is coming from the right place, but the
connection itself is going through ORD which adds unnecessary latency.

$ curl -s https://ipinfo.io | jq ‘{city, region, org}’
{
“city”: “Washington”,
“region”: “District of Columbia”,
“org”: “AS16276 OVH SAS”
}

$ getent hosts t3.storage.dev
137.174.147.59 t3.storage.dev

$ curl -s 137.174.147.59 | Chicago, AS15830, & VPN Not Detected - IPinfo.io | jq ‘{city, org}’
{
“city”: “Chicago”,
“org”: “AS15830 Equinix (EMEA) Acquisition Enterprises B.V.”
}

$ curl -so /dev/null -w “Connect: %{time_connect}s | TLS: %{time_appconnect}s | Total: %{time_total}s\n” https://t3.storage.dev/
Connect: 0.021s | TLS: 0.046s | Total: 0.067s

Connect time is ~21ms which checks out for a VA->Chicago hop. Should be <5ms if it hit IAD directly.

I saw a couple older threads where similar issues were fixed by adjusting peering ( Anycast routing Denver to Chicago ,
wrong coast bad routing/peering to anycast Fly on Charter/Spectrum ). Is this something that can be looked at for OVH’s VA presence?

2

Hi,

Thanks for bringing this up, such issue usually occurs due to the inaccurate geoIP database our provider hosts. Can you share the public IP where the request is initiated? We’ll investigate the GeoIP accuracy upon that.

3

Sure, the public IP is 40.160.19.39

4

thanks, in addition that. can you also provide the public resolver IP?

you can get the IP two ways:

UI: https://info.resolver.nsone.net/
Cli: dig TXT o-o.myaddr.google.com +short

can you provide both?

thanks

Bo

5

Here you go

CLI (host command, equivalent to dig TXT):

  • Public resolver IP: 135.148.217.13
  • EDNS client subnet: 40.160.19.0/24

Web (ip-api.com, since the NS1 page requires JavaScript):

  • DNS resolver IP: 135.148.217.13 (OVH US LLC, United States)
6

dig TXT o-o.myaddr.google.com +short: 2604:2dc0:117:d900::e
host -t TXT o-o.myaddr.google.com: 135.148.217.13
Web (ip-api.com): 135.148.217.13

7

thanks for providing the DNS resolver, the DNS resolver you’re using are reported in Chicago region, that’s why your request is routed to Chicago.

We’re investigating to see if this is incorrect geoIP info, and will get back to you soon

8

Hi Victor,

I’ve made a workaround about the geoIP location issue while we’re reporting the incorrect the Maxmind IP database.

Please let us know if you’re seeing performance improvement.

9

It really made a massive difference, thank you!

10

Glad to hear that, hope you enjoy our services and supports. Have a wonderful day.