Ping instabile Fastweb 2.5 FTTH

speromihittiuntram

Passato l'altro giorno (27/04) da TIM a Fastweb (FiberCop) - dal momento dell'attivazione della linea Fastweb ho notato che il ping è fuori di testa: ogni circa cinque secondi, pingando per esempio 1.1.1.1 oppure 8.8.8.8, così come 192.168.1.254, dai normali 5/6ms mi arriva una botta di un numero a caso compreso tra 40 e 200.

Il router è un Fastweb Seven, non sono connesso in wifi ma col cavo.

Lascio due screen
Pinging 1.1.1.1 with 32 bytes of data: Reply from 1.1.1.1: bytes=32 time=5ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=5ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=4ms TTL=56 Reply from 1.1.1.1: bytes=32 time=62ms TTL=56 Reply from 1.1.1.1: bytes=32 time=5ms TTL=56 Reply from 1.1.1.1: bytes=32 time=10ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=7ms TTL=56 Reply from 1.1.1.1: bytes=32 time=86ms TTL=56 Reply from 1.1.1.1: bytes=32 time=5ms TTL=56 Reply from 1.1.1.1: bytes=32 time=7ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=10ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=117ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=5ms TTL=56 Reply from 1.1.1.1: bytes=32 time=8ms TTL=56 Reply from 1.1.1.1: bytes=32 time=5ms TTL=56 Reply from 1.1.1.1: bytes=32 time=4ms TTL=56 Reply from 1.1.1.1: bytes=32 time=65ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=4ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=93ms TTL=56 Reply from 1.1.1.1: bytes=32 time=5ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=5ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=58ms TTL=56 Reply from 1.1.1.1: bytes=32 time=5ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=5ms TTL=56 Reply from 1.1.1.1: bytes=32 time=5ms TTL=56 Reply from 1.1.1.1: bytes=32 time=7ms TTL=56 Reply from 1.1.1.1: bytes=32 time=72ms TTL=56 Reply from 1.1.1.1: bytes=32 time=4ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=5ms TTL=56 Reply from 1.1.1.1: bytes=32 time=117ms TTL=56 Reply from 1.1.1.1: bytes=32 time=5ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=5ms TTL=56 Reply from 1.1.1.1: bytes=32 time=66ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=5ms TTL=56 Reply from 1.1.1.1: bytes=32 time=5ms TTL=56 Reply from 1.1.1.1: bytes=32 time=5ms TTL=56 Reply from 1.1.1.1: bytes=32 time=5ms TTL=56 Reply from 1.1.1.1: bytes=32 time=85ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=4ms TTL=56 Reply from 1.1.1.1: bytes=32 time=5ms TTL=56 Reply from 1.1.1.1: bytes=32 time=5ms TTL=56 Reply from 1.1.1.1: bytes=32 time=33ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=4ms TTL=56 Reply from 1.1.1.1: bytes=32 time=7ms TTL=56 Reply from 1.1.1.1: bytes=32 time=5ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=7ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=7ms TTL=56 Reply from 1.1.1.1: bytes=32 time=5ms TTL=56 Reply from 1.1.1.1: bytes=32 time=146ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=7ms TTL=56 Reply from 1.1.1.1: bytes=32 time=5ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=7ms TTL=56 Reply from 1.1.1.1: bytes=32 time=67ms TTL=56 Reply from 1.1.1.1: bytes=32 time=6ms TTL=56 Reply from 1.1.1.1: bytes=32 time=7ms TTL=56

Ad oggi Fastweb (quando per miracolo riesco a contattarli) mi risponde che la linea funziona benissimo e che non gli risulta nessun problema di latenza.

Mi trovo di fronte ad un bivio e chiedo a voi, che sicuramente ne sapete più del sottoscritto:

Tento la fortuna e (molto probabilmente) regalo a Fastweb 35€ per mandarmi un tecnico e sentirmi dire che la linea continua a funzionare benissimo?
Cambiare operatore, dato che sto ancora dentro i 14 giorni?

Nel caso dell'opzione n. 2: quale operatore? Degli amici (che abitano dall'altra parte dell'Italia, quindi non so quanto possa andar bene per dove abito) mi hanno consigliato Dimensione.

Informazioni aggiuntive magari omesse:
Ho provato con più device, più cavi, sia ethernet che in wifi, stessa cosa;
Con TIM non avevo sto problema, il ping era ottimo;
La zona è Velletri - provincia di Roma

Qualche idea?

TheMarsican

speromihittiuntram
Ma sei in WIFI? Perchè già sul router hai una risposta molto alta mediamente.

LucaPerazzolo

speromihittiuntram io ipotizzo problema di router perchè pl cosi alto dentro alla rete locale è grave
riesci a fare un winmtr in loop?

speromihittiuntram

TheMarsican No. Ethernet.

TheMarsican

speromihittiuntram
Hai la possibilità di collegare un altro router, magari clonando il MAC Address del Nexxt così da non dover richiedere a Fastweb modem libero, se hai ONT esterno?

E magari provare pure con una Distro Linux Live a vedere se succede la stessa cosa?

speromihittiuntram

TheMarsican L'avevo scritto in basso quindi magari è scappato (adesso ho modificato) ma il router è un Seven. Non ho possibilità di provare altri router - pensi possa essere questo (cioè magari un router difettoso) il problema?

Per l'OS potrei provarci ma non nell'immediato, se può interessare il problema l'ho riscontrato sia su Windows (su tre pc diversi, due w11 e un w10) che su MacOS.

stefeda

TheMarsican non può clonare il Mac address del router sulla scheda di rete del pc e instaurare una connessione ppoe e fare le prove cosi da capire se è il router il collo di bottiglia?

TheMarsican

speromihittiuntram L'avevo scritto in basso quindi magari è scappato (adesso ho modificato) ma il router è un Seven.

Sisi, questo l'avevo visto.

speromihittiuntram Non ho possibilità di provare altri router - pensi possa essere questo il problema?

Il Seven non è che sia tutto questo granchè, prima di dare la colpa a Fastweb ed alla sua rete IP partirei dal locale con altro router.
Anche perchè quelle latenze così alte, soprattutto se sei via cavo, al primo HOP (il router) mi sembrano un po' strane.

speromihittiuntram Per l'OS potrei provarci ma non nell'immediato, se può interessare il problema l'ho riscontrato sia su Windows (su tre pc diversi, due w11 e un w10) che su MacOS.

È giusto per fare una ulteriore prova.

speromihittiuntram

TheMarsican È giusto per fare una ulteriore prova.

Ho installato Ubuntu su uno scassone che avevo dentro un cassetto e diciamo che è più o meno lo stesso anche con questo

nyhilium 192.168.1.254 -t e vedi come si comporta.

Pinging 192.168.1.254 with 32 bytes of data: Reply from 192.168.1.254: bytes=32 time<1ms TTL=64 Reply from 192.168.1.254: bytes=32 time<1ms TTL=64 Reply from 192.168.1.254: bytes=32 time<1ms TTL=64 Reply from 192.168.1.254: bytes=32 time<1ms TTL=64 Reply from 192.168.1.254: bytes=32 time<1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=126ms TTL=64 Reply from 192.168.1.254: bytes=32 time<1ms TTL=64 Reply from 192.168.1.254: bytes=32 time<1ms TTL=64 Reply from 192.168.1.254: bytes=32 time<1ms TTL=64 Reply from 192.168.1.254: bytes=32 time<1ms TTL=64 Reply from 192.168.1.254: bytes=32 time<1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=141ms TTL=64 Reply from 192.168.1.254: bytes=32 time<1ms TTL=64 Reply from 192.168.1.254: bytes=32 time<1ms TTL=64 Reply from 192.168.1.254: bytes=32 time<1ms TTL=64 Reply from 192.168.1.254: bytes=32 time<1ms TTL=64 Reply from 192.168.1.254: bytes=32 time<1ms TTL=64 Reply from 192.168.1.254: bytes=32 time<1ms TTL=64 Reply from 192.168.1.254: bytes=32 time<1ms TTL=64 Reply from 192.168.1.254: bytes=32 time<1ms TTL=64 Reply from 192.168.1.254: bytes=32 time<1ms TTL=64 Reply from 192.168.1.254: bytes=32 time<1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=2ms TTL=64 Reply from 192.168.1.254: bytes=32 time=107ms TTL=64 Reply from 192.168.1.254: bytes=32 time<1ms TTL=64

nyhilium

Se già pingando il router hai un ping alto, non è la linea il problema ma il dispositivo stesso...
fai ping 192.168.1.254 -t e vedi come si comporta.

Come seconda prova potresti anche provare con la modalità provvisoria (solo driver di rete). Ma dubito che cambia qualcosa se hai provato con altre macchine ottenendo lo stesso risultato

TheMarsican

speromihittiuntram
Ogni tanto tira certe botte proprio il router, anche se nella maggior parte dei ping è normale.

E quegli spike che vedi anche pingando 1.1.1.1 sembrano avere lo stesso pattern di quando è il router a dare delle botte di latenza alta.

TheMarsican

stefeda non può clonare il Mac address del router sulla scheda di rete del pc e instaurare una connessione ppoe e fare le prove cosi da capire se è il router il collo di bottiglia?

A parte che Fastweb è in IPoE (DHCP), altrimenti a cosa servirebbe il MAC Address 😉

Comunque volendo può provarci, magari con Linux così ha la piena possibilità di farlo tramite CLI, instaurando la sessione IPoE e ricordando di taggare la VLAN.

Non ci avevo pensato, dovrebbe essere fattibile.

LucaPerazzolo pl cosi alto dentro alla rete locale è grave

Il Seven droppa ICMP come se non ci fosse un domani, è un suo normale comportamento.

Mi verrebbe da pensare pure di provare in UDP a pingare router e qualcosa in internet, per vedere se c'è lo stesso comportamento.

speromihittiuntram

LucaPerazzolo lasciato per qualche minuto

Tralasciando che in sto momento sta proprio morendo, dai 5/6ms sono passato ai 30 di base

ThePlanL

TheMarsican Scusami ma se droppasse dovresti avere richiesta scaduta

attackment

speromihittiuntram consiglio personale, cambia host, usa Google piuttosto, ma non Cloudflare, sta dando problemi sia ieri che oggi con picchi di latenza anche ben piu gravi di questi, faticavo a vedere questo forum e un altro poggiati proprio su Cloudflare, il resto tutto ok

LucaPerazzolo

speromihittiuntram prova su 8.8.8.8 invece di cf che non è al massimo della forma in sti giorni
comunque 70% sul router qualcosa non va, proverei in udp come detto da themarsican a vedere come si comporta

speromihittiuntram

attackment usa Google piuttosto

Sinceramente di sta roba non ci capisco un tubo. Mi sa che, dato che sono ancora in tempo, taglio la testa al toro e provo a cambiare direttamente operatore.

ellegi71

Ho la stessa identica situazione col Seven in area bianca con linea 2500/1000 , nell'uso normale non mi accorgo di nulla, ho notato la situazione facendo speedtest su nperf, più tardi posto screenshot, a questo punto l'imputato credo sia il Seven, nel mio caso Vantiva.

ThePlanL

Buongiorno a tutti,
io ho lo stesso problema, basta pingare il gateway non c'è bisogno di pingare Google.
Ho provato sia WiFi che Ethernet, sia dal PC fisso che notebook.

Qualcuno ha idea sul perchè accada una cosa simile ?

torinese

Idem anch'io, ho Seven Vantiva, ping balla da 12 a 73 ms

TheMarsican

ThePlanL Scusami ma se droppasse dovresti avere richiesta scaduta

Le protezioni contro ICMP non droppano tutto a prescindere, qualche pacchetto lo lasciano passare sempre ed a volte con tempi di elaborazione alti.

Anche la mia IliadBox se pingo 1 pacchetto al secondo lascia passare e solo ogni tanto droppa, se pingo 2 pacchetti al secondo inizia a droppare come se non ci fosse un domani ma qualche pacchetto passa sempre.

Comunque è ormai appurato che è il Seven ad avere questo comportamento. Nulla di fastidioso o riscontrabile nella realtà visto che il normale traffico effettuato non è ICMP.

Diversa la situazione di OP con l'ultimo MTR verso i DNS Google, questa:

Qui sembra che il PL se lo porti dietro fino a destinazione, cosa non buona.

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