I have a tunnel that I use as an alternative to opening ports on my local network, however, there is a lot of latency/ping when going through the tunnel.
I ran a traceroute and saw that it was routing traffic through the USA (Ashburn) even though I am based in Hungary (so is the origin server).
I am aware that the Anycast network is supposed to route to the two closest locations, however it is not working.
Is there a way to select which location traffic goes to? Or any possible fixes?
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 Hungary does not want to peer with Cloudflare within Hungary, and is only peering with Cloudflare in e.g. Ashburn, US, then traffic from that ISP will be sent from Hungary and to Cloudflare’s PoP in Ashburn, US.
Anycast will take you to the closest location based on the network path.
Closest network path isn’t definitive the same as closest physical / geographical distance.
There is no ways for you to control or otherwise influence that.
You can however contact your ISP, and request that they set up a settlement-free peering with Cloudflare within Hungary, or at least, somewhere closer than Ashburn, US (preferably within EU), if locally within Hungary isn’t an option for them.
Not unless your ISP wishes to set up a settlement-free peering with Cloudflare somewhere closer than Ashburn, US.
That said, - what ISP / provider, preferably their AS number are you seeing this from?
The AS number can be found here:
Thank you for your detailed response. It has helped me understand the routing much better.
The AS number of my ISP is AS5483 and on https://bgp.he.net/AS5483#_peers
Cloudflare is listed as a peer, though it does seem to be from the US.
I will look into trying to contact my ISP and see if there is a way to request a local peering, but my hopes are not high.
AS5483 is Magyar Telekom, which is a subsidiary of AS3320 Deutsche Telekom.
The issue(s) with AS3320 Deutsche Telekom has been well-known for years, not only in regards to Cloudflare.
AS3320 Deutsche Telekom seem to refuse to peer directly with Cloudflare (as well as many other networks), which in the end is causing the result that traffic has to go through alternative paths (assuming such alternative paths are available, which they may not always be).
AS3320 Deutsche Telekom have similarly been in the media several times over the years, allegedly for not wanting to ensure proper capacity on their peering links, and so forth, which for example caused AS174 Cogent Communiations to send a lawsuit towards AS3320 Deutsche Telekom some years ago.
With the extended information about your ISP, I’m afraid my hopes aren’t high either.
Can confirm this still occurs, verified on multiple Deutsche Telekom connections in Germany.
Network hops over to NYC and back adding massive latency and slowdowns along the way.
Servers hosted on Hetzner, routed to through CF Free plan.
Upgrading to Pro is the “solution” in this case and I can confirm it works.
However this feels like extortion. CF and DT get your act together, what the â– â– â– â– is this!?
This issue is especially nasty since you can only replicate it from Telekom connections. Good luck discovering this issue if you don’t access to one! Your users are suffering.
