Accesses from UAE are being routed to Europe data centers, instead of UAE data centers
What are the steps to reproduce the issue?
Our websites are massively slow down when being accessed from UAE region, due to requests being routed to Europe, instead of being served by regional data center (e.g Dubai DXB).
https://bgp.tools/
→ The AS number shown under “You are connecting from” like this: “Cloudflare, Inc. (AS13335)”
https://bgp.he.net/
→ The AS number shown like this: “Your ISP is AS13335 (Cloudflare, Inc.)”
Country UAE, … but is there any specific state/region that this happens in?
Some Asian ISP(s) are known to be taking traffic to other continents, such as e.g. to Europe, and pass it on to Cloudflare there, apparently because bandwidth is cheaper in Europe.
Where you are being routed to, depends on your ISP’s decisions, including their peering arrangements with Cloudflare, and whether these peering arrangements (if they have such) are done locally or far away.
If your provider from Asia does not want to peer with Cloudflare within Asia, and is only peering with Cloudflare in e.g. Europe, then traffic from that ISP will be sent from Asia and to Cloudflare’s PoP in Europe.
You can however contact your ISP, and request that they set up a settlement-free peering with Cloudflare within your own country, or at least, somewhere closer than the other continent, if locally within your own country isn’t an option for them.
Both last night when writing the above, as well as right now, I see that specific ISP reaching Cloudflare within 3 ms, which isn’t consistent with being routed all the way to Europe.
All the Cloudflare IP addresses I’m finding in the DNS system for that domain (… regardless where in the world I’m checking from), are all hitting Cloudflare within 3 ms, when the traffic is originating from AS15802Emirates Integrated Telecommunications Company PJSC.
That said, -
What “colo=” do you see when accessing the following?
What a shame, but seems to be quite the same (e.g. limited) in my country.
(Not only in 2024, but also way back in the previous years!)
You’re seeing these routing issues from a residential Internet connection?
Can you open a command prompt / terminal?
On Linux and similar systems, where you have dig, you can run:
dig flowermeister.com
For each IP address you see, e.g. if you see 192.0.2.34 and 198.51.100.200, you run a traceroute to them:
traceroute 192.0.2.34
traceroute 198.51.100.200
traceroute 1.1.1.1
On Windows, - it’ll be like this:
nslookup flowermeister.com
For each IP address you see, e.g. if you see 192.0.2.34 and 198.51.100.200, you run a traceroute to them:
tracert 192.0.2.34
tracert 198.51.100.200
tracert 1.1.1.1
After you have collected these traceroutes (for the IP addresses you see with the dig/nslookup DNS lookup, as well as for 1.1.1.1), please share them.
Putting the output in a code block (e.g. “````”, new line, traceroute output, new line, “```”) may work the best.
Note: 192.0.2.34 and 198.51.100.200 are examples / placeholders, as your ISP could be replying with different IP addresses than the ones that I see from my end.
traceroute to 172.67.133.229 (172.67.133.229), 30 hops max, 60 byte packets
1 _gateway (192.168.100.1) 3.425 ms 4.770 ms 4.760 ms
2 192.168.70.1 (192.168.70.1) 4.755 ms 4.745 ms 4.735 ms
3 * * *
4 10.100.136.66 (10.100.136.66) 9.846 ms 9.838 ms 9.830 ms
5 10.100.137.86 (10.100.137.86) 12.041 ms 12.034 ms 12.026 ms
6 10.141.79.170 (10.141.79.170) 132.809 ms 125.672 ms 125.840 ms
7 * ams-ix.as13335.net (80.249.211.140) 131.854 ms *
8 141.101.65.93 (141.101.65.93) 124.754 ms 141.101.65.113 (141.101.65.113) 129.365 ms 128.461 ms
9 172.67.133.229 (172.67.133.229) 118.102 ms 115.009 ms *
traceroute to 104.21.25.87 (104.21.25.87), 30 hops max, 60 byte packets
1 _gateway (192.168.100.1) 2.369 ms 2.318 ms 2.310 ms
2 192.168.70.1 (192.168.70.1) 2.303 ms 2.295 ms 3.006 ms
3 * * *
4 10.100.136.58 (10.100.136.58) 7.816 ms 7.806 ms 7.799 ms
5 10.100.136.86 (10.100.136.86) 9.113 ms 9.774 ms 9.766 ms
6 10.229.200.177 (10.229.200.177) 125.691 ms 123.284 ms 10.141.79.194 (10.141.79.194) 111.582 ms
7 * * ams-ix.as13335.net (80.249.211.140) 147.076 ms
8 141.101.65.2 (141.101.65.2) 114.324 ms 141.101.65.107 (141.101.65.107) 121.325 ms 141.101.65.103 (141.101.65.103) 130.322 ms
9 104.21.25.87 (104.21.25.87) 111.625 ms 111.618 ms 111.611 ms
As can be seen around hop 5 ↔ 6 in your traces, your ISP takes you all the way to Amsterdam on that trace, to pass the traffic over to Cloudflare at AMS-IX.
However, the same two IP addresses, 172.67.133.229 and 104.21.25.87, when running through RIPE Atlas probes (e.g. triggered via Hurricane Electric’s website), you’re currently reaching the same two IP addresses locally, within 4 ms, from multiple different probes.
I will suggest you to contact your ISP, and ask them to look in to the weird routing for you, and provide an explanation about what happens with their network.