Deutsche Telekom network routes the 104.16.0.0/12 CF subnet to new york
What steps have you taken to resolve the issue?
Contacted the NOC at DT, their answer was that CF advertises this route. But so far only found DT to be plagued by it, other providers correctly route it to the nearest datacenter.
What feature, service or problem is this related to?
I don’t know
What are the steps to reproduce the issue?
traceroute from within DT network (or any subsidiary eg. Magyar Telekom) to an address in that range (eg. 104.21.10.15)
Great. And as I see it, their 3 tier1 ISPs towards DTAG are all US based ones. (TATA GTT Lumen)
Interestingly enough it started acting up only not so long ago, so may we assume sometimes it works correctly?
Also it is quite weird it is not the whole AS only one (or maybe more, dunno) subnets. Reaching 1.1.1.1 for example is fine (as on the screenshot, great forum engine has one file support and that’s not even the latest selected file, but the first…oh well).
I guess then it is what it is.
Thanks for the enlightening. And this is a move only a monopoly can afford, asking money for peering.
All websites I visit from the T-Mobile (Poland) network either do not load
What steps have you taken to resolve the issue?
I am currently in Poland. All sites that are added to cloudflare, and visit from the T-Mobile (Poland) network either do not load or the page opens very slowly (3-5 minutes). I can provide a traceroute.
A more complete list of affected subsidiaries may be:
Cloudflare has previously indicated that they are more than happy to establish a settlement-free peerings with other providers, and I can’t believe that DT is exclusive from that.
However, Cloudflare cannot control DT and their decisions…
&&
Meta (e.g. Facebook, Instagram, WhatsApp) is likely on the way towards alternative paths too, as indicated above:
So it will be fun to see whether Meta (e.g. Facebook, Instagram, WhatsApp) will transit towards other continents as well, or still stay (quite, or perfectly) local, … going forward.
As they are a subsidiary of DT, I wouldn’t put my hopes too high though.
You can maintain two different hostnames, e.g. example.com and/or www.example.com, or even shop.example.com (as shown in the following example) for your website, that are available generally for everyone.
But then create a different sub-domain, that you selectively redirect DT (and it’s subsidiaries) over to, such as e.g. something like shop-dtag, as shown in the following example, which I made back in May:
Every website that is behind Cloudflare, loads very slow from Hungarian Telekom, and it is very frustrating. Please solve this issue finally with Deutsche and Hungarian Telekom.
Request timeout for icmp_seq 0
64 bytes from 104.21.22.220: icmp_seq=1 ttl=52 time=140.810 ms
64 bytes from 104.21.22.220: icmp_seq=2 ttl=52 time=139.481 ms
64 bytes from 104.21.22.220: icmp_seq=3 ttl=52 time=141.241 ms
64 bytes from 104.21.22.220: icmp_seq=4 ttl=52 time=145.179 ms
64 bytes from 104.21.22.220: icmp_seq=5 ttl=52 time=147.147 ms
64 bytes from 104.21.22.220: icmp_seq=6 ttl=52 time=138.837 ms
Request timeout for icmp_seq 7
64 bytes from 104.21.22.220: icmp_seq=8 ttl=52 time=142.316 ms
^C
— censored.com ping statistics —
10 packets transmitted, 7 packets received, 30.0% packet loss
round-trip min/avg/max/stddev = 138.837/142.144/147.147/2.800 ms
What are the steps to reproduce the issue?
Visit a website that is behind Cloudflare from Hungarian or Deutsche Telekom…
Hi @tpatriksztg, I am sorry to hear this. I’ve moved your post here since it’s related to the same thing as other users, including myself, are posting, even since before about Telekom issue. Thank you for understanding. Feel free to use of these Forums to find more information and hopefully a solution for your case, since the story has quite large feedback already ongoing with Telekom within multiple countries. Thank you.