Not Everyday but close to it, my ISP is having problem with Cloudflare related services during the night.
Magenta Telekom ([AS8412]) is my ISP, below is a tracert to 1.1.1.1 i just did.
1 2 ms 2 ms 2 ms 192.168.0.1
2 11 ms 11 ms 11 ms at-vie09c-rt01.as8412. net [217.25.120.3]
3 10 ms 10 ms 11 ms at-vie09c-rc01.as8412. net [217.25.122.250]
4 12 ms 12 ms 14 ms at-vie09c-ri01.as8412. net [217.25.123.5]
5 * * * Request timed out .
6 183 ms 178 ms 199 ms one.one.one.one [1.1.1.1]
This high ping is not only to 1.1.1.1, if any content is hosted on cloudflare, it becomes impossible to load said content.
The timeframe this happens is between 19:00 to 23:00, never outside of this timeframe did the problem occur. This is behind month of me tracking the ping to 1.1.1.1.
I’ve contacted my ISP about this, and they said there’re is nothing they can do and its a Problem on Cloudflares end which can’t be true.
Below is a tracert to google dns 8.8.8.8, this shows that it is purely a routing problem from my ISP to Cloudflare, but my ISP is refusing to fix this problem, I talked to them about it over MONTH but still nothing changes.
Is Cloudflare able to see anything on its end? Can Cloudflare contact the ISP and ask them for a comment? I’ve really exhausted all my options at this point. pls help me
1 2 ms 2 ms 1 ms 192.168.0.1
2 16 ms 12 ms 23 ms at-vie09c-rt01.as8412. net [217.25.120.3]
3 12 ms 13 ms 11 ms at-vie09c-rc01.as8412. net [217.25.122.250]
4 12 ms 13 ms 12 ms 217-25-123-45.static.upcbusiness. at [217.25.123.45]
5 * * * Request timed out.
6 19 ms 18 ms 18 ms 216.239.48.237
7 17 ms 23 ms 18 ms 108.170.228.33
8 17 ms 17 ms 18 ms dns.google [8.8.8.8]
ping statistics from a whole day to 1.1.1.1
This spike can be found in 90% of the days, once or twice out of the blue moon its normal for the whole day. But this is whats standart for AS8412.
I’ve also made contacted with multiple ppl around my area with the same Provider, they too can confirm this high ping with cloudflare everyday during the night.
Pls let me know if you’re looking into this.
Hi, is it still ongoing? I don’t see any issues on return path (should be in the time frame local time), it goes through VIX. There has been planned maintenance in the Vienna colo, so you might be connected to a different place. Can you confirm when did the issue start and if you’re still experiencing it? If you go to https://1.1.1.1/help it should show you where you are connected to + reachability issues.
https://1.1.1.1/help#eyJpc0NmIjoiTm8iLCJpc0RvdCI6Ik5vIiwiaXNEb2giOiJObyIsInJlc29sdmVySXAtMS4xLjEuMSI6IlllcyIsInJlc29sdmVySXAtMS4wLjAuMSI6IlllcyIsInJlc29sdmVySXAtMjYwNjo0NzAwOjQ3MDA6OjExMTEiOiJZZXMiLCJyZXNvbHZlcklwLTI2MDY6NDcwMDo0NzAwOjoxMDAxIjoiWWVzIiwiZGF0YWNlbnRlckxvY2F0aW9uIjoiVklFIiwiaXNXYXJwIjoiTm8iLCJpc3BOYW1lIjoiTWFnZW50YSBUZWxla29tIiwiaXNwQXNuIjoiODQxMiJ9
Yes, this is still on going. This problem first appeard back in december 2022, it was discussed in an austria forum between the same ISP users. Thus it has little relevance with the maintenance.
We thought this would be a temporary issue or the isp itself will resolve this, but after such a long time we still see a consistent latency increase at nighttime everyday.
I’ve attached a pingplotter result from 1.1.1.1 just now local time 21:30 CEST Semptember 8th
Again I’ll mention this is a long time running issue and only to cloudflare. 8.8.8.8 or 9.9.9.9 both show normal 15ms
The timeframe I mentioned is not an absoulute timeframe, usually it resolves itself at around 22:00 CEST and the ping spike starts late 20:00 CEST but it sometimes starts early or ends late.
We also have another User’s tracert result, this is from Wednesday the September 6th at around 21:00 CEST
1 <1 ms <1 ms <1 ms 192.168.0.1
2 11 ms 11 ms 11 ms at-vie03c-rt01.as8412. net
3 10 ms 10 ms 11 ms at-vie03c-rc01.as8412. net
4 12 ms 12 ms 14 ms .static.upcbusiness.at
5 * * * Request timed out .
6 205 ms 192 ms 180 ms 172.68.48.12
6 201 ms 185 ms 193 ms one.one.one.one [1.1.1.1]
We noticed the addition of the 6th path, we dont know how relevant this is since the problem begann before this extra path was present. The 5th path is assumed to be Deutsche Telekom’s private node which we normal users can’t see.
Let me know if you need further info from us, I’ll still be monitoring the latency for the upcoming days.
Oh and another thing I remembered.
You say from return path it goes through VIX.
But on our view we can’t see any path with VIX.
However, we have some people with 5G Magenta internet that helped us with tracert showing that their path does indeed go through VIX.
This problem is also only for cable internet users, People on the same ISP with 5G or DSL doesnt have this issue as they seem to have a different routing path than us.
Hi! I was wrong, the source network you shared does go through VIX but transits via AS1299 and there seems to be congestion somewhere between AS1299 and DTAG/AS8412.
Some AS8412 prefixes go through VIX, but not the ones you sent. AS8412 doesn’t announce your network prefix at VIX so we can’t send it through there. If you’re a AS8412 customer, can you ask them to send prefixes including your network at the peering in VIX? It’s possible it’s a capacity issue at VIX. We’ll try to transit through somewhere else to see if it helps, but it could get congested somewhere else.
