Very slow navigation from Italian TIM provider to CloudFlare


#1

Hello,
for the last two weeks the navigation from the Italian operator TIM to CloudFlare is very slow during the hours of most traffic.

If I connect to a VPN everything is resolved, even another Italian user says that he view faster through the TOR network.

To load my site I waited 16 seconds, I connected to a VPN and the result fell below 3 seconds.

The problem seems to come from the “Seabone” node of Milan, can you help us?

Thanks
Andrea

DebHUF6WAAE_vOL!


#2

Traceroute:

traceroute: Warning: www.andreadraghetti.it has multiple addresses; using 104.31.86.240
traceroute to www.andreadraghetti.it (104.31.86.240), 64 hops max, 72 byte packets
1 192.168.2.1 (192.168.2.1) 1.491 ms 0.883 ms 1.195 ms
2 * * *
3 172.17.89.210 (172.17.89.210) 5.305 ms 5.683 ms 5.465 ms
4 * 172.17.89.234 (172.17.89.234) 6.937 ms 5.948 ms
5 172.19.177.18 (172.19.177.18) 12.509 ms 12.801 ms 12.472 ms
6 etrunk49.milano50.mil.seabone.net (195.22.205.116) 13.522 ms * 13.521 ms
7 racc.milano50.mil.seabone.net (195.22.208.75) 40.862 ms 40.908 ms 40.268 ms
8 cloudflare.franco71.fra.seabone.net (195.22.214.193) 29.684 ms 29.486 ms 30.534 ms
9 104.31.86.240 (104.31.86.240) 32.351 ms 32.048 ms 32.354 ms


#3

A latency of 32ms is not that bad. So I wouldnt reckon this as the problem.

Is it all sites behind Cloudflare or just a few? Could it be the servers?


#4

The problem is generally in loading the content, not in reaching the site.

The problem occurs when I load websites on at least 3 different servers, one in France, one in Germany and one in Lithuania.


#5

Could you post these URLs?


#6

You can try with my blog: https://www.andreadraghetti.it

The problem is not constant, it only happens at certain times.


#7

About seven seconds. Why could you rule out a problem on the server side?

Maybe post a screenshot of the developer tools’ network tab with the requests.


#8

Hi, I am the other user mentioned by @drego85, I confirm the same behaviour for a static html jekyll website hosted on GitHub Pages (so is quite impossibile that the upstream is slow), and this happens only when using TIM (I have FTTC 100/30 at home) but not, for example, when using Fastweb (at work).

Latency is always fine, the bandwidth is the bottleneck.

This is a traceroute from TIM (bad):

$ traceroute consanpaolino.org
traceroute to consanpaolino.org (104.27.166.106), 30 hops max, 60 byte packets
 1  _gateway (192.168.44.2)  1.793 ms  1.779 ms  2.166 ms
 2  192.168.1.1 (192.168.1.1)  5.648 ms  5.648 ms  5.640 ms
 3  * * *
 4  172.18.33.124 (172.18.33.124)  11.592 ms 172.18.33.210 (172.18.33.210)  12.220 ms  12.222 ms
 5  172.18.34.28 (172.18.34.28)  15.844 ms 172.18.34.44 (172.18.34.44)  14.253 ms 172.18.34.28 (172.18.34.28)  15.828 ms
 6  172.19.241.125 (172.19.241.125)  20.539 ms  18.736 ms  18.714 ms
 7  etrunk39.milano1.mil.seabone.net (195.22.192.178)  18.506 ms  16.218 ms etrunk37.milano50.mil.seabone.net (195.22.196.90)  16.828 ms
 8  et4-0-5-50.franco71.fra.seabone.net (195.22.205.107)  35.221 ms racc.milano50.mil.seabone.net (195.22.208.75)  34.913 ms  35.917 ms
 9  cloudflare.franco71.fra.seabone.net (195.22.214.193)  24.624 ms  23.317 ms  33.496 ms
10  104.27.166.106 (104.27.166.106)  36.814 ms  36.081 ms *

This is a traceroute from Fastweb (good):

~ ❯❯❯  traceroute consanpaolino.org
traceroute to consanpaolino.org (104.27.166.106), 30 hops max, 60 byte packets
 1  fritz.box (192.168.188.1)  1.198 ms  1.516 ms  1.741 ms
 2  93.48.136.1 (93.48.136.1)  8.526 ms  10.141 ms  10.170 ms
 3  10.250.138.2 (10.250.138.2)  8.662 ms 10.250.132.94 (10.250.132.94)  8.940 ms 10.250.132.90 (10.250.132.90)  9.188 ms
 4  10.250.0.27 (10.250.0.27)  8.918 ms  9.489 ms  9.508 ms
 5  10.250.1.1 (10.250.1.1)  9.508 ms  9.638 ms  12.419 ms
 6  10.250.5.186 (10.250.5.186)  12.749 ms  8.948 ms  8.939 ms
 7  10.254.20.201 (10.254.20.201)  12.000 ms  9.697 ms  9.785 ms
 8  93.57.68.98 (93.57.68.98)  10.763 ms  11.959 ms 93.57.68.102 (93.57.68.102)  12.304 ms
 9  89.97.200.34 (89.97.200.34)  13.221 ms  12.653 ms  14.359 ms
10  89.97.200.69 (89.97.200.69)  13.467 ms  13.529 ms 89.97.200.33 (89.97.200.33)  14.497 ms
11  cloudflare-nap.namex.it (193.201.28.33)  14.514 ms  14.856 ms  17.192 ms
12  104.27.166.106 (104.27.166.106)  17.365 ms  17.289 ms  17.208 ms

This happens even if cloudflare is serving the file (cf-cache-status: HIT):
image

A random wget:

$ wget https://consanpaolino.org/images/2018/04/12/events-hero.jpg
--2018-05-30 19:49:55--  https://consanpaolino.org/images/2018/04/12/events-hero.jpg
Resolving consanpaolino.org (consanpaolino.org)... 104.27.167.106, 104.27.166.106, 2400:cb00:2048:1::681b:a76a, ...
Connecting to consanpaolino.org (consanpaolino.org)|104.27.167.106|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 205337 (201K) [image/jpeg]
Saving to: ‘events-hero.jpg’

events-hero.jpg                                    100%[================================================================================================================>] 200,52K  24,5KB/s    in 8,2s    

2018-05-30 19:50:03 (24,5 KB/s) - ‘events-hero.jpg’ saved [205337/205337]

#9

I’m gonna reply to both of you (@drego85, @gionn). Italian user here, replying in English if that’s ok with you as well so @sandro understands.

The issue is most likely with Seabone, as you expected. I heard that there was a fiber cut of almost all the backbone between Frankfurt and Zurich so all the traffic is doing a different route or is being rate limited (depending on various factors, time of day, load, etc.). You are most definitely seeing the former. Unfortunately outside of upgrading the plan to allow the POPs in Italy instead of FRA be the main hubs there is not much you can do, just wait for the fibers to be fixed.

I am currently of Tiscali’s FTTH 1000/300 plan and via Wi-Fi does 1.3s full load time from the FCO (NaMeX, Rome) POP which it appears TIM is not using in your case (you are most likely located in the north of Italy passing through MIX-IT which is for some reason not on the Free plan) while Fastweb is using it.

Fastweb should not be affected by the Seabone problem quite as much, especially towards Cloudflare. Tiscali for example doesn’t use Seabone art all towards FRA, so there would not be issues here.

I would still recommend a reduction of requests (there are >100, it’s a LOT especially given the limited size of the home page).

If you have any additional questions don’t esitate to ask!


#10

Thanks Matteo,
I share with you that we have to wait for Seabone (TIM) to solve the problem.

But I wanted to share the problem, so other users can quickly search for and understand that it’s a general problem.

Andrea


#11

Telecom Italia is a disgrace.
etrunk39.milano50.mil.seabone.net (and others) keep loosing packets for years now.
I see people complaining on online games about lag and they all show the same problem.
I don’t think TIM cares.

The only “solution” for now is use at least a “PRO” plan.
MILANO -> FRANKFURT is broken.-


#12

I can confirm that upgrading from FREE to PRO makes no difference. Yes you hit Milano instead of Frankfurt. But the problem is at Milano.

1 <1 ms <1 ms <1 ms 192.168.1.1
2 * * * Request timed out.
3 5 ms 5 ms 4 ms 172.17.185.102
4 8 ms 7 ms 7 ms 172.17.184.212
5 8 ms 7 ms 7 ms 172.19.244.245
6 7 ms 6 ms * etrunk39.milano50.mil.seabone.net [93.186.128.252]
7 6 ms 6 ms 6 ms ae10.milano58.mil.seabone.net [195.22.208.117]
8 7 ms 7 ms 7 ms cloudflare.milano58.mil.seabone.net [195.22.196.97]
9 21 ms 43 ms 87 ms 104.25.60.35


#13

Well actually Telecom Italia Sparkle is one of the best and most important providers in the world. Unfortunately a fiber cut can take weeks to fix and this seems to be that case.

It will get fixed…


#14

I hope that TIM knows the problem…


#15

The problem should be solved! Sparkle informed me privately.


#16

Of course they did (since you say it has been solved, can’t verify right now), they have continued monitoring and many gigabits if not terabits of bandwidth passing though, which in case of problems gets rerouted. They know the instant it happens just like for every other mass failures on their network, they may miss the small things regarding single connections.


#17

How did you managed to get in touch with Sparkle. There is some kind of communication channel where issues like this get published?


#18

You can contact them on Twitter (@TISparkle) :wink:


#19

This topic was automatically closed after 14 days. New replies are no longer allowed.