Linea TIM FTTH: problemi su seabone?

MircoT

da ieri sera sto notando lentezza a raggiungere i miei server su hetzner.
in effetti il ping verso quei server è molto alto, ma anche verso il server del sito hetzner.
allego un paio di immagini con l'mtr verso hetzner.com e il grafico del ping verso uno dei miei server nelle ultime 24 ore:

un ping appena fatto verso hetzner.com:

PING hetzner.com (213.133.116.44): 56 data bytes
64 bytes from 213.133.116.44: icmp_seq=0 ttl=53 time=456.730 ms
64 bytes from 213.133.116.44: icmp_seq=1 ttl=53 time=445.876 ms
64 bytes from 213.133.116.44: icmp_seq=2 ttl=53 time=436.937 ms
64 bytes from 213.133.116.44: icmp_seq=3 ttl=53 time=454.719 ms
64 bytes from 213.133.116.44: icmp_seq=4 ttl=53 time=429.829 ms
64 bytes from 213.133.116.44: icmp_seq=5 ttl=53 time=454.909 ms
64 bytes from 213.133.116.44: icmp_seq=6 ttl=53 time=397.572 ms
^C
--- hetzner.com ping statistics ---
7 packets transmitted, 7 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 397.572/439.510/456.730/19.511 ms

ho provato a pingare gli stessi server dalle linee di un paio di clienti (che non sono tim) e i tempi di risposta sono normali.

guardando l'mtr il problema pare sia su seabone a Milano.

qualcuno riscontra lo stesso problema da linea tim?

astrolabio

MircoT
FTTH TIM ho lo stesso problema.
Se stacco il Wi-Fi con 5G Wind sta sui 60 ms

walt

MircoT packet loss e banda subottimale TIM -> Hetzner è oramai una costante ma in effetti non mi ero reso conto del dramma odierno poiché di base utilizzo la linea Dimensione...

MircoT

astrolabio grazie del riscontro.

morris2003 Sembra saturo il nodo ae0.franco74.fra.seabone.net

oltre a essere saturo perde anche molti pacchetti, o forse ne è la conseguenza.

walt mah, in realtà è la prima volta che mi capita. ho dei server su hetzner da parecchi mesi e fino ad ora non ho avuto problemi.
qui il grafico dell'ultima settimana:

a parte qualche spike in corrispondenza del backup che faccio nel cloud, la latenza verso quei server è piuttosto costante e buona.
deve essere il nodo ae0.franco74.fra.seabone.net che sta andando a donnine. magari corriponde ad un cluster e i suoi compagni diavventure sono andati in ferie ed è rimasto da solo, impiccandosi.

da quello che vedo, saltuariamente anche il dns di cloudflare (1.1.1.1) risponde in ritardo, ma in modo sporadico.

vabbeh, speriamo che risolvano presto.

morris2003

Sembra saturo il nodo aeo.franco74.fra.seabone.net
Spero sia momentaneo e in risoluzione.

Qui sotto 2 tracert da linea FTTH Dimensione e FTTH TIM Business che ho in ufficio.
Su linea TIM passo per ae1.franco74.fra.seabone.net invece di aeo.franco74.fra.seabone.net (come te), e non ho il problema.

Linea Dimensione

C:\Users\>tracert 213.133.116.44
Traccia instradamento verso static.213-133-116-44.clients.your-server.de [213.133.116.44]
su un massimo di 30 punti di passaggio:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2    <1 ms    <1 ms    <1 ms  192.168.45.1
  3    15 ms    16 ms    14 ms  100.64.255.255
  4    16 ms    16 ms    14 ms  net233-27-32-195.dimensionesrl.eu [195.32.27.233]
  5    19 ms    20 ms    20 ms  corebackbone-AS33891.mix-it.net [217.29.66.10]
  6    27 ms    26 ms    26 ms  ae6-2011.nbg40.core-backbone.com [80.255.14.246]
  7    28 ms    25 ms    48 ms  core-backbone.hetzner.com [5.56.20.254]
  8    27 ms    48 ms    36 ms  core12.nbg1.hetzner.com [213.239.245.25]
  9     *        *        *     Richiesta scaduta.
 10    26 ms    27 ms    26 ms  static.213-133-116-44.clients.your-server.de [213.133.116.44]
Traccia completata.

Linea TIM Business

C:\Users\>tracert 213.133.116.44
Traccia instradamento verso static.213-133-116-44.clients.your-server.de [213.133.116.44]
su un massimo di 30 punti di passaggio:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2    <1 ms    <1 ms    <1 ms  host-94-95-187-209.business.telecomitalia.it [94.95.187.209]
  3     4 ms     8 ms    10 ms  host-94-84-146-176.business.telecomitalia.it [94.84.146.176]
  4     *        *        *     Richiesta scaduta.
  5     *        *        *     Richiesta scaduta.
  6     *        *        *     Richiesta scaduta.
  7    13 ms    12 ms    13 ms  195.22.196.170
  8    33 ms     *        *     ae1.franco74.fra.seabone.net [195.22.211.209]
  9    32 ms    31 ms    30 ms  213.144.184.91
 10    40 ms    40 ms    41 ms  core12.nbg1.hetzner.com [213.239.224.237]
 11     *        *        *     Richiesta scaduta.
 12    35 ms    35 ms    34 ms  static.213-133-116-44.clients.your-server.de [213.133.116.44]
Traccia completata.

Ping da linea TIM Business

Esecuzione di Ping 213.133.116.44 con 32 byte di dati:
Risposta da 213.133.116.44: byte=32 durata=36ms TTL=53
Risposta da 213.133.116.44: byte=32 durata=35ms TTL=53
Risposta da 213.133.116.44: byte=32 durata=34ms TTL=53
Risposta da 213.133.116.44: byte=32 durata=35ms TTL=53

walt

MircoT è la prima volta che mi capita.

Meglio per te...sulla mia linea i pl anche piuttosto sostanziosi sono all'ordine del giorno da settimane 😶

MircoT

adesso si è calmato:

quel nodo perde ancora pacchetti, ma almeno la latenza è decente rispetto a prima.

vediamo domani se si incastra di nuovo.

walt

                                                                                   My traceroute  [v0.95]
***.*** (94.130.***.***) -> vpn.***.it (80.180.***.***)                                                                                                      2024-09-04T06:08:27+0000
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                                                                                                   Packets               Pings
 Host                                                                                                                                            Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 172.31.1.1                                                                                                                                    0.0%    26    2.6   3.0   1.7   5.1   0.9
 2. 12055.your-cloud.host                                                                                                                         0.0%    26    0.3   0.2   0.1   0.6   0.1
 3. (waiting for reply)
 4. spine1.cloud1.nbg1.hetzner.com                                                                                                                0.0%    26    1.1   3.9   0.8  42.4   9.6
 5. spine15.cloud1.nbg1.hetzner.com                                                                                                               0.0%    26    0.3   0.5   0.3   4.9   0.9
 6. core12.nbg1.hetzner.com                                                                                                                       0.0%    26    0.5   0.5   0.4   1.0   0.1
 7. core5.fra.hetzner.com                                                                                                                         0.0%    25    3.7   3.6   3.5   4.0   0.1
 8. 213.144.184.90                                                                                                                               48.0%    25    4.1   4.1   4.0   4.5   0.1
 9. ae33.milano50.mil.seabone.net                                                                                                                28.0%    25   13.4  13.5  13.3  14.3   0.2
10. 195.22.196.171                                                                                                                               24.0%    25   14.5  14.3  14.1  14.7   0.2
11. (waiting for reply)
12. (waiting for reply)
13. (waiting for reply)
14. host-80-180-***-***.retail.telecomitalia.it                                                                                                   44.0%    25   24.1  23.9  23.2  24.5   0.4

MircoT

walt ho visto.
nel mio caso è sempre l'host ae0.franco74.fra.seabone.net che perde pacchetti facendo l'mtr.
ma i tempi totali per arrivare ai server hetzner sono ragionevoli.
per altro quell'host potrebbe di proposito ignorare i pacchetti icmp per "non perdere tempo"

gandalf2016

walt e le connessioni TCP verso hetzner a quanto vanno? Immagino qualche KB/s 💀

walt

MircoT i tempi totali per arrivare ai server hetzner sono ragionevoli

Vero.

MircoT quell'host potrebbe di proposito ignorare i pacchetti icmp per "non perdere tempo"

Non lo faceva quindi o è un disservizio oppure hanno modificato le impostazioni del nodo 🤓

gandalf2016 in realtà in termini di banda passante il risultato non risulta degradato in maniera sensibile rispetto allo scenario con assenza di packet loss, la media è rimasta sui 25/30 MBps (ovviamente con transiti seri come quelli di Dimensione saturo senza problemi il gigabit del mio root server ma questo discorso esula dal packet loss).

Nel mio scenario d'uso il disservizio incide più che altro sulle sonde attive verso le mie due linee TIM (una marea di falsi negativi...) e sui servizi RDP/videocall.

gandalf2016

walt ah ok, allora mi fa pensare più a un rate limit su traffico UDP/ICMP.

Con quel packetloss in TCP sarebbe difficile arrivare a 30 MB/s
Prova a forzare RDP su TCP e vedere se si risolve il problema

walt

gandalf2016 mi fa pensare più a un rate limit su traffico UDP/ICMP.

Sì in effetti col senno di poi inizio a pensarlo anche io...però degrado di qualità nel complesso è avvertibile nell'operatività quotidiana.

gandalf2016 Prova a forzare RDP su TCP

Usando Guacamole come proxy di fatto lo è già 👀

giuliovale

Riprendo questa discussione, anche io problemi con seabone passando per ae1.franco74.fra.seabone.net come si può arrivare a segnalare il problema a TIM ?

MircoT

giuliovale difficile. o meglio, dubito che gli interessi..
ogni tanto quel nodo aumenta la latenza in modo irragionevole (200 - 300ms), dopo qualche ora smette.

giuliovale

MircoT SI immagino che non gli freghi niente del mio problema, intanto è almeno una settimana che mi sta facendo dannare, ho diversi server su Hetzner che i alcuni momenti diventano ingestibili.
Altri siti vengano navigati a metà o con latenze assurde perfino Netflix a volte impiega tempo.
In un test disperato ho comprato una vpn e così riesco a gestirli.
Grazie della risposta comunque

ilboy95

MircoT scappare da Sparkle (ero in easyip) é stata la scelta migliore che potessi fare in ambito ftth.

giuliovale

ilboy95 E su quale operatore sei adesso?

19Andrea87

Presente.

Verso Hetzner, linea tim FTTC, oltre 300ms sempre su quell'host. Indirizzo pubblico nella subnet 79.54.0.0

Ho appena riavviato la PPPoE, nuovo range IP (82.53.0.0) ed instradamento totalmente differente, passo sempre per ae0.franco74.fra.seabone.net ma con un altro IP, stavolta apparentement senza problemi di ping, solo un po' di perdita di pacchetti sul singolo host ma è ICMP quindi...:

Non vedo l'ora di togliermi Telecom ed i suoi transiti su Sparkle.

ilboy95

19Andrea87 sui transiti Telia, mai saturato. Con Poste easyip invece in inverno era spesso problematica la situazione verso destinazioni fuori Italia, in genere la sera.

Cambiare operatore in questi casi é risolutivo.

Pagina successiva »

Informativa privacy - Informativa cookie - Termini e condizioni - Regolamento - Disclaimer - 🏳️‍🌈 🇵🇸
P.I. IT16712091004 - info@fibraclick.it

♻️ Il server di questo sito è alimentato al 100% con energia rinnovabile