Speed issue for Hungarian Telekom users

I have a test file that is behind Cloudflare:
https://demo.creditpro.hu/test
Customers of a specific ISP experience very slow speeds (around 2-3 megabits per second). This of course applies to every file, I just created this for testing purposes.
So this loads fine for me, but customer on the network of Deutsche Telekom experience the slow speeds.
I asked for a traceroute from them:

Tracing route to demo.creditpro.hu [104.21.17.205]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.0.1
  2     5 ms     4 ms     4 ms  10.231.184.1
  3     6 ms     6 ms     6 ms  145.236.79.194
  4     9 ms    13 ms     8 ms  Te0-9-0-10.core0-dataplex.net.telekom.hu [84.1.66.78]
  5    10 ms     8 ms    11 ms  81.183.0.37
  6    13 ms     9 ms     8 ms  81.183.3.137
  7    14 ms    15 ms    14 ms  80.150.169.205
  8    14 ms    14 ms    14 ms  62.159.61.127
  9     *        *        *     Request timed out.
 10    42 ms    47 ms    49 ms  195.122.183.210
 11    51 ms    49 ms    42 ms  104.21.17.205

Trace complete.

They say that the 9th step always takes a lot of time. 62.159.61.127 is part of Deutsche Telekoms network, I believe that might be the issue, but I’m now sure. Any help would be appreciated.

Thanks!

2 Likes

Unfortunately this issue still persists. Is there any news?

Same here, since July (Telekom ISP → server in Germany behind CloudFlare)…

My problem is that I don’t even know what to do about this. Only thing I can do is to disable Cloudflare proxying…
Is there no way to report issues without a paid account?

Same problem here.
I think we need to contact Hungarian Telekom. They had a problem with the routing to the German OVH datacenter too.

@Interpont
You can write a ticket (here: Cloudflare Help Center , and if you dont get reply for this topic, you can tag here

@MoreHelp

with the ticket ID.

If you don’t receive a reply within 72 hours or if the replies do not answer your question, reply to your own Community post with your ticket number **** and at mention @MoreHelp to bring your post to our attention.

The tag won’t necessarily get you far. The @MVP gang usually pesters the Cloudflare staff who shows up here :wink:

3 Likes

Well, I was able to find the free support center this way and I submitted a new ticket. Hopefully they will be able to answer it sometime soon. Thanks!

The ticket was closed and marked as solved immediately, I believe because I’m on free tier (“Your plan type grants you access to Support via our Cloudflare Community”).
So hereby I summon @MoreHelp with my ticket number: 2243688
Can you help me out on this one?

Thanks!

1 Like

Hi. Same problem here with my site (server is in Hungary). I tried to create a ticketbut the bot immediately switched it to resolved status. How convenient. :slight_smile: My ticket number was 2243684.

The troubleshooting guide told me to test the site with webpagetest.org with CF enabled/paused but from webpagetest.org’s Frankfurt server the site speed is the same each time. My colleague uses Vodafone (UPC) at home and the site speed is flawless for him, from my home Telekom each click is about 30-40sec… The problem only persist at the night timeframe, about 19:00-22:00.

I had to pause CF for now, but I intend to use it when this issue will be solved.

All the best,
Balazs

Same here, Vodafone is fine, Telekom is not. But Telekom had issues all day when we tested it, not just at nights.

Try to contact Hungarian Telekom too by e-mail with your problem [email protected]

I am experiencing really slow network access from Hungary (every site) and high packet loss. Tested with multiple different ISPs (Telekom, Invitel, DIGI), cellular, and landline.

It’s been like this for weeks (or not months). If I pause CF then it works, my website loads in like half a second. With CF it’s anything between 30-90 seconds.

Should I stop using CF altogether? The quality went downhill since I started using it in like 2017.

PING [aranyklinika.hu](https://aranyklinika.hu/) (172.67.214.181): 56 data bytes
64 bytes from 172.67.214.181: icmp_seq=0 ttl=52 time=154.379 ms
Request timeout for icmp_seq 1
64 bytes from 172.67.214.181: icmp_seq=2 ttl=52 time=152.917 ms
64 bytes from 172.67.214.181: icmp_seq=3 ttl=52 time=152.783 ms
64 bytes from 172.67.214.181: icmp_seq=4 ttl=52 time=147.984 ms
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
64 bytes from 172.67.214.181: icmp_seq=7 ttl=52 time=158.112 ms
64 bytes from 172.67.214.181: icmp_seq=8 ttl=52 time=153.548 ms
64 bytes from 172.67.214.181: icmp_seq=9 ttl=52 time=152.462 ms
64 bytes from 172.67.214.181: icmp_seq=10 ttl=52 time=158.883 ms
64 bytes from 172.67.214.181: icmp_seq=11 ttl=52 time=158.054 ms
64 bytes from 172.67.214.181: icmp_seq=12 ttl=52 time=159.272 ms
Request timeout for icmp_seq 13
64 bytes from 172.67.214.181: icmp_seq=14 ttl=52 time=151.545 ms
64 bytes from 172.67.214.181: icmp_seq=15 ttl=52 time=167.505 ms
Request timeout for icmp_seq 16
64 bytes from 172.67.214.181: icmp_seq=17 ttl=52 time=158.502 ms
Request timeout for icmp_seq 18
64 bytes from 172.67.214.181: icmp_seq=19 ttl=52 time=151.408 ms
64 bytes from 172.67.214.181: icmp_seq=20 ttl=52 time=158.911 ms
64 bytes from 172.67.214.181: icmp_seq=21 ttl=52 time=163.802 ms
64 bytes from 172.67.214.181: icmp_seq=22 ttl=52 time=156.680 ms
Request timeout for icmp_seq 23
Request timeout for icmp_seq 24
Request timeout for icmp_seq 25
64 bytes from 172.67.214.181: icmp_seq=26 ttl=52 time=156.224 ms
Request timeout for icmp_seq 27
64 bytes from 172.67.214.181: icmp_seq=28 ttl=52 time=150.468 ms
Request timeout for icmp_seq 29
64 bytes from 172.67.214.181: icmp_seq=30 ttl=52 time=145.397 ms
Request timeout for icmp_seq 31
Request timeout for icmp_seq 32
64 bytes from 172.67.214.181: icmp_seq=33 ttl=52 time=157.800 ms
64 bytes from 172.67.214.181: icmp_seq=34 ttl=52 time=153.549 ms
64 bytes from 172.67.214.181: icmp_seq=35 ttl=52 time=156.867 ms
Request timeout for icmp_seq 36
64 bytes from 172.67.214.181: icmp_seq=37 ttl=52 time=154.083 ms
64 bytes from 172.67.214.181: icmp_seq=38 ttl=52 time=412.154 ms
64 bytes from 172.67.214.181: icmp_seq=39 ttl=52 time=264.665 ms
--- [aranyklinika.hu](https://aranyklinika.hu/) ping statistics ---
40 packets transmitted, 26 packets received, 35.0% packet loss
round-trip min/avg/max/stddev = 145.397/169.537/412.154/53.059 ms
traceroute aranyklinika.hu                                                                                                                                                                                                                                                                                                                                                                                                                                                                          
traceroute to aranyklinika.hu (104.21.23.245), 64 hops max, 52 byte packets
 1  192.168.0.1 (192.168.0.1)  3.597 ms  2.663 ms  2.420 ms
 2  10.230.160.1 (10.230.160.1)  9.384 ms  11.714 ms  9.147 ms
 3  145.236.81.248 (145.236.81.248)  8.974 ms  10.257 ms  10.151 ms
 4  145.236.133.34 (145.236.133.34)  11.341 ms
    145.236.133.96 (145.236.133.96)  18.925 ms  19.133 ms
 5  145.236.133.96 (145.236.133.96)  18.667 ms  17.834 ms  17.090 ms
 6  81.183.3.107 (81.183.3.107)  16.479 ms  18.658 ms
    81.183.3.139 (81.183.3.139)  19.793 ms
 7  80.157.204.37 (80.157.204.37)  25.005 ms  25.102 ms
    80.150.169.205 (80.150.169.205)  24.451 ms
 8  217.239.41.190 (217.239.41.190)  24.540 ms  22.097 ms  22.619 ms
 9  62.159.61.127 (62.159.61.127)  26.062 ms  23.452 ms *
10  * * 195.122.183.210 (195.122.183.210)  153.871 ms
11  195.122.183.210 (195.122.183.210)  161.685 ms  153.677 ms  155.421 ms
12  104.21.23.245 (104.21.23.245)  145.592 ms * *

Hi!

Same for me, I had to pause CF. From Vodafone (UPC) it is fine, though. From Telekom response time is 30-40sec.

I just ran your ping test on my PC:

Ping statistics for 172.67.214.181:
Packets: Sent = 40, Received = 30, Lost = 10 (25% loss)

This is not a Cloudflare issue per se. I’d be even careful pointing at the Hungarian Telecom, as it’s not happening in their network either. This seems to be an issue with the German Telecom and something in their network (close to Cloudflare’s PoP) is off.

Neither posting further traceroutes nor using the tag from before will be useful at this point. It’s best to wait until someone from Cloudflare shows up who could escalate this internally, respectively contact their German Telecom contacts for more information.

If this thread stays civilised and does not turn into yet another Cloudflare is soooo bad complaint orgy :wink: I am sure MVPs will be inclined to notify Cloudflare staff whenever they show up. I, for myself, can say I’ll keep track of his as long as the thread stays civilised.

And as @tpatriksztg already mentioned

Dropping Hungarian Telekom a message might also be a good idea, they’ll certainly also have some leverage with their German peers.

1 Like

I wrote an email to Hungarian Telekom today afternoon. I have attached some traceroute and ping output too. Please write to them, maybe if they receive more problem report, they will fix it (faster).

I have an OVH VPS server, my VPS is located in Germany, and Telekom users experiencing higher ping after 19:00-20:00, so I think this problem not CF releated only.
But this CF connection issue appears all day.

Yeah, I don’t think so either. As far as I can tell the peering between German Telecom and Level 3 has some issues at the moment (and Cloudflare happens to be connected via that). Where Cloudflare could come in is for them to talk nicely to their responsible contacts. Same could go for Hungarian Telecom.

Just opened ticket 2243754 with Cloudflare in an Enterprise context as well :man_shrugging:t2: :slightly_smiling_face:.

3 Likes

I dropped an email to Hungarian Telekom as well. @sandro Can you keep us posted on your Enterprise tickets responses? Thanks mate!

Definitely, but so far nothing really came up. Got a response, but rather of the generic type.

1 Like

Our Net Team made some changes.
Kindly test and revert.

3 Likes