[Thread ufficiale][FTTH] Pianeta Fibra - Pre-installazione linea

[matteo-rock]

Originariamente inviato da mcrs969

Faccio delle domande sul metodo, che, al di la del campo in cui viene applicato, deve essere corretto e validato.

Non avresti potuto spiegare meglio il mio pensiero

Originariamente inviato da kkaarlo

Da Bologna: Tecnico appena andato via e questa la linea

Speedtest by Ookla

Server: Vodafone IT - Milan (id = 4302)
ISP: Pianeta Fibra
Latency: 7.36 ms (0.34 ms jitter)
Download: 949.95 Mbps (data used: 1.1 GB)
Upload: 283.26 Mbps (data used: 246.9 MB)
Packet Loss: 0.0%
Result URL: https://www.speedtest.net/result/c/f...8-cc49674fc540
Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.

[Processo completato]

traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 52 byte packets
1 fritz.box (192.168.200.1) 1.466 ms 0.753 ms 0.554 ms
2 100.103.108.0 (100.103.108.0) 7.735 ms 7.704 ms 7.916 ms
3 10.0.0.1 (10.0.0.1) 8.124 ms 8.395 ms 7.876 ms
4 10.0.0.18 (10.0.0.18) 8.869 ms 8.771 ms 8.405 ms
5 cloudflare.minap.it (185.1.114.25) 8.709 ms 9.001 ms 8.404 ms
6 188.114.100.5 (188.114.100.5) 8.925 ms 9.269 ms 8.850 ms
7 one.one.one.one (1.1.1.1) 8.453 ms 8.759 ms 7.585 ms

% traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
1 fritz.box (192.168.200.1) 1.358 ms 0.603 ms 0.597 ms
2 100.103.108.0 (100.103.108.0) 7.507 ms 7.256 ms 7.291 ms
3 10.0.0.1 (10.0.0.1) 8.381 ms 7.913 ms 7.660 ms
4 10.0.0.18 (10.0.0.18) 10.590 ms 8.476 ms 8.632 ms
5 google.mi11-ca.ae1.seflow.it (94.198.103.150) 7.562 ms 8.269 ms 8.527 ms
6 108.170.245.65 (108.170.245.65) 9.455 ms
74.125.245.241 (74.125.245.241) 8.969 ms 8.689 ms
7 216.239.49.181 (216.239.49.181) 8.506 ms
216.239.42.9 (216.239.42.9) 8.167 ms
142.250.211.27 (142.250.211.27) 8.680 ms
8 dns.google (8.8.8.8) 8.722 ms 8.351 ms 7.649 ms

Bene bene, se hai idee, hai notato mancanze o quant'altro sul processo di attivazione o sul servizio riportamelo così lo metto nei feedback interni per le procedure

Originariamente inviato da MiloZ

Assolutamente no.
La latenza si alza prima su di un nodo di Sparkle a 125ms poi si riabbassa e poi si rialza, è Ti Sparkle il problema , anche se il comportamento della latenza sui vari hop può trarre in inganno (pure su altri server succede così). Mi sembra abbastanza sorprendente che ti tu ostini a negarlo soprattutto essendo anche molto esperto e competente in networking.
La sfortuna forse è che non eri presente in tempo reale quando si è verificato l'aumento (a differenza di quando è accaduto per

MiloZ ma cosa stai dicendo??? Se posso migliorare la rete, certo che lo faccio, andrebbe contro i miei interessi, ma capisci che quello che dici non ha senso?

Prendi la clessidra, il funzionamento è lo stesso, la strozzatura a metà fa si che dall' altro lato arrivi al MASSIMO la portata della strozzatura. Secondo il tuo ragionamento invece il flusso di sabbia diminuisce a metà, a 3/4 riaumenta e alla fine ridiminuisce, ma ti sembra una cosa coerente? E' su quello che mi baso per dirti che ormai sei fissato che sparkle sia il demonio.

Per carità sei liberissimo di non credermi, ma credo di avere una leggere esperienza in reti per almeno saper leggere un traceroute.

Ma se fosse come dici tu, avendo già NTT nei miei fornitori, cosa mi costerebbe spostare più traffico da loro? Anche per microsoft, ti riporto articoli indipendenti che ne parlano, ti dico che han dovuto rimuovere rotte dagli IX, ma niente, non mi credi.

Non è un cambio di rotta, con battle c'era la possibilità di avere dei miglioramenti e l'ho fatto subito.

Verso godaddy ti ho spiegato perchè non è un problema di sparkle e ti ho messo davanti all' evidenza, non mi credi eh pace, mica posso costringerti con la forza. Ci metterei un secondo a switcharlo su ntt o cogent, ma il problema sta tra godaddy e ipconnect.de, significa che godaddy sta soffrendo di saturazioni.

[ZioMatt]

Originariamente inviato da MiloZ

Assolutamente no.
La latenza si alza prima su di un nodo di Sparkle a 125ms poi si riabbassa e poi si rialza, è Ti Sparkle il problema , anche se il comportamento della latenza sui vari hop può trarre in inganno (pure su altri server succede così). Mi sembra abbastanza sorprendente che ti tu ostini a negarlo soprattutto essendo anche molto esperto e competente in networking.

No Milo, ha ragione Matteo. Quel che tu vedi in un punto intermedio di un trace è il tempo di risposta di quel router, che non vive per rispondere agli errori di TTL Expired, ma per inoltrare pacchetti (in hardware, mentre gli errori passano alla gestione via CPU).
Se la latenza "di tratta" aumenta in quel nodo non puoi avere ad un passo successivo una latenza minore, vuol dire che dal tuo router problematico al successivo ha impiegato un "tempo negativo" (sento già le bestemmie dei miei ex-prof a scrivere quelle due parole insieme)?

Posto che in casi estremi il routing di errori o messaggi ICMP all'interno di un provider può seguire giri completamente diversi rispetto al flusso di traffico normale (che può non essere assolutamente lo stesso tra andata e ritorno dei pacchetti), ed impiegare così tempi assurdi. Esempio: per qualche motivo l'errore di un router intermedio passa per la rete di management, in uscita in America, che poi rientra via peering diversi al tuo provider; hai il flusso di traffico che magari fa la direttrice Milano-Amsterdam, e la risposta alla trace che gira mezzo mondo. Capita sovente per i nodi che hanno IP "privato" e che quindi non generano pacchetti direttamente ruotabili.

Originariamente inviato da MiloZ

Ieri hai modificato il routing verso due server perchè TI Sparkle era in palese saturazione, mi sembra che non ce lo siamo sognati.

Attenzione che le modifiche di routing che fa Matteo spesso e volentieri sono asimmetriche. Un provider ha il controllo su dove i pacchetti escono, ma non dove entrano, a meno di tagliare o abbassare la preference a tutto un transito, o (per chi è in CG-NAT) mascherarvi dietro un IP di una /24 diversa annunciata con pesi diversi.

[matteo-rock]

Originariamente inviato da ZioMatt

No Milo, ha ragione Matteo. Quel che tu vedi in un punto intermedio di un trace è il tempo di risposta di quel router, che non vive per rispondere agli errori di TTL Expired, ma per inoltrare pacchetti (in hardware, mentre gli errori passano alla gestione via CPU).
Se la latenza "di tratta" aumenta in quel nodo non puoi avere ad un passo successivo una latenza minore, vuol dire che dal tuo router problematico al successivo ha impiegato un "tempo negativo" (sento già le bestemmie dei miei ex-prof a scrivere quelle due parole insieme)?

Posto che in casi estremi il routing di errori o messaggi ICMP all'interno di un provider può seguire giri completamente diversi rispetto al flusso di traffico normale (che può non essere assolutamente lo stesso tra andata e ritorno dei pacchetti), ed impiegare così tempi assurdi. Esempio: per qualche motivo l'errore di un router intermedio passa per la rete di management, in uscita in America, che poi rientra via peering diversi al tuo provider; hai il flusso di traffico che magari fa la direttrice Milano-Amsterdam, e la risposta alla trace che gira mezzo mondo. Capita sovente per i nodi che hanno IP "privato" e che quindi non generano pacchetti direttamente ruotabili.



Attenzione che le modifiche di routing che fa Matteo spesso e volentieri sono asimmetriche. Un provider ha il controllo su dove i pacchetti escono, ma non dove entrano, a meno di tagliare o abbassare la preference a tutto un transito, o (per chi è in CG-NAT) mascherarvi dietro un IP di una /24 diversa annunciata con pesi diversi.

Quoto in toto. Soprattutto per il secondo punto è stato possibile perchè abbiamo fatto un agreement con battle per il peer temporaneo al mix aspettando di mettere online la PNI. In questo modo il beneficio è bidirezionale perchè è stato impostato un peering. Ma sui rerouting da un uplink ad altro è solo in uscita, in ingresso decide l' altro operatore. Si può forzare con le community, ma fino ad un certo punto

[MiloZ]

Originariamente inviato da matteo-rock

MiloZ ma cosa stai dicendo??? Se posso migliorare la rete, certo che lo faccio, andrebbe contro i miei interessi, ma capisci che quello che dici non ha senso?

Prendi la clessidra, il funzionamento è lo stesso, la strozzatura a metà fa si che dall' altro lato arrivi al MASSIMO la portata della strozzatura. Secondo il tuo ragionamento invece il flusso di sabbia diminuisce a metà, a 3/4 riaumenta e alla fine ridiminuisce, ma ti sembra una cosa coerente? E' su quello che mi baso per dirti che ormai sei fissato che sparkle sia il demonio.

E' successo molte volte quello che ti sto dicendo (non con la vostra linea che è nuova, dico in generale in caso si saturazioni), forse non ti è mai capitato di notare comportamenti di questo tipo quando si tenta di interpretare i traceroute per ricercare la causa dei problemi.

Ma se fosse come dici tu, avendo già NTT nei miei fornitori, cosa mi costerebbe spostare più traffico da loro? Anche per microsoft, ti riporto articoli indipendenti che ne parlano, ti dico che han dovuto rimuovere rotte dagli IX, ma niente, non mi credi.

Non è un cambio di rotta, con battle c'era la possibilità di avere dei miglioramenti e l'ho fatto subito.

Quali miglioramenti scusami? Se non ci fosse stato il problema della saturazione verso battle.net la latenza era la stessa di adesso e non ci sarebbe stato bisogno di apportare alcuna modifica, tant'è che tu stesso sull'altro forum hai scitto:

"ti confermo che Sparkle rimane la rotta migliore.

Al mix hanno 1% di Packet loss circa
NTT nessun packet loss, ma la latenza sale di 2ms
CogentCo è oscena andando oltre i 30ms

Sparkle invece mi sembra ottimo 0% di PL e latenze a 22ms."

Quindi in assenza di saturazione Sparkle era perfetto verso Blizzard.

Verso godaddy ti ho spiegato perchè non è un problema di sparkle e ti ho messo davanti all' evidenza, non mi credi eh pace, mica posso costringerti con la forza. Ci metterei un secondo a switcharlo su ntt o cogent, ma il problema sta tra godaddy e ipconnect.de, significa che godaddy sta soffrendo di saturazioni.

Ma scusami, se non dipende da Ti Sparkle, mi spieghi come mai altre connessioni sullo stesso server non presentavano nessun aumento di latenza?
Questo è l'instradamento con Telia:

Traccia instradamento verso intergenia.de [85.25.0.17]
su un massimo di 30 punti di passaggio:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     7 ms     7 ms     6 ms  100.76.0.1
  3     7 ms     6 ms     7 ms  2.57.32.1
  4     7 ms     *        8 ms  10.248.0.37
  5     9 ms     7 ms     8 ms  mno-b3-link.ip.twelve99.net [62.115.174.40]
  6    17 ms    17 ms    18 ms  ffm-bb2-link.ip.twelve99.net [62.115.116.172]
  7    25 ms    17 ms    18 ms  ffm-b1-link.ip.twelve99.net [62.115.120.217]
  8    17 ms    17 ms    16 ms  ae2.cr-nunki.sxb1.bb.godaddy.com [62.115.144.9]
  9    17 ms    19 ms    17 ms  ae0.100.sr-sol.sxb1.dcnet-emea.godaddy.com [87.230.112.3]
 10    17 ms    16 ms    17 ms  ae1.100.sr-helios.sxb1.dcnet-emea.godaddy.com [62.138.129.2]
 11    17 ms    16 ms    25 ms  ae0.sr-f1-3.sxb1.dcnet-emea.godaddy.com [92.204.12.11]
 12    17 ms    16 ms    16 ms  static-ip-85-25-0-17.inaddr.ip-pool.com [85.25.0.17]

Traccia completata.

E in quello stesso frangente non c'era nessun aumento ieri, mentre con la vostra connessione il ping oscillava di continuo fino a 150ms per poi riscendere e risalire, uguale succedeva i giorni precedenti su battle.net

Aggiungo: con TIM ieri (e non solo ieri) si alzava la latenza su hetzner.de durante le ore di punta, se guardi il traceroute che ho postato, il ping aumenta sugli hop tedeschi (lo riporto nuovamente):

Traccia instradamento verso hetzner.de [88.198.255.177]
su un massimo di 30 punti di passaggio:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     *        *        *     Richiesta scaduta.
  3     4 ms     4 ms     4 ms  172.17.107.164
  4     6 ms     7 ms     6 ms  172.17.104.100
  5     9 ms     8 ms     8 ms  172.19.184.66
  6    10 ms     9 ms     9 ms  172.19.177.14
  7    10 ms     9 ms     9 ms  195.22.205.116
  8    18 ms    31 ms    17 ms  195.22.196.71
  9     9 ms     9 ms     9 ms  ae-8.r00.mlanit02.it.bb.gin.ntt.net [129.250.9.41]
 10    11 ms    14 ms    10 ms  ae-1.r21.mlanit02.it.bb.gin.ntt.net [129.250.3.160]
 11     *        *        *     Richiesta scaduta.
 12    21 ms    21 ms    20 ms  ae-8.r01.frnkge13.de.bb.gin.ntt.net [129.250.6.51]
 13    25 ms     *       25 ms  213.198.82.130
 14    69 ms    83 ms    70 ms  core11.nbg1.hetzner.com [213.239.252.22]
 15    27 ms    26 ms    26 ms  ddos-mitigation.dc1.nbg1.hetzner.com [88.198.247.253]
 16    97 ms    83 ms    85 ms  ex9k2.dc1.nbg1.hetzner.com [213.239.203.214]
 17    91 ms    90 ms    97 ms  static.88.198.255.177.clients.your-server.de [88.198.255.177]

Traccia completata.

Quindi secondo il tuo ragionamento espresso sopra, neppure in quel caso doveva essere colpa di Sparkle?
Però curiosamente, con Seflow, pur passando dallo stesso percorso con NTT, la latenza NON si alzava minimamente verso quello stesso server, quindi il problema era dovuto in qualche modo a TI Sparkle, come verosimilmente lo era sui server che ti ho indicato io.
Oltretutto a riprova di ciò, nel mentre aumentava la latenza su hetzner (con TIM), anche altri server esteri venivano impattati nello stesso identico modo in contemporanea, pur facendo percorsi anche completamente diversi (senza transitare da NTT).
Sarebbe una coincidenza davvero bizzara se non fosse colpa di Sparkle.

Comunque, ammettiamo che su quei due server segnalati da me sopra, con Seflow, si sia trattato di un evento occasionale (nessuno può escluderlo a priori).
Se la cosa dovesse ripresentarsi altre volte nello stesso modo, potreste intervenire per porvi rimedio?

[MiloZ]

Originariamente inviato da ZioMatt

No Milo, ha ragione Matteo. Quel che tu vedi in un punto intermedio di un trace è il tempo di risposta di quel router, che non vive per rispondere agli errori di TTL Expired, ma per inoltrare pacchetti (in hardware, mentre gli errori passano alla gestione via CPU).

Certo questo è sottinteso.

Se la latenza "di tratta" aumenta in quel nodo non puoi avere ad un passo successivo una latenza minore, vuol dire che dal tuo router problematico al successivo ha impiegato un "tempo negativo" (sento già le bestemmie dei miei ex-prof a scrivere quelle due parole insieme)?

Non ti seguo, o meglio, ti parlo in maniera terra terra, perchè quello che ci interessa è l'effettivo funzionamento della connessione più che una lezione di networking, e contestualmente cercare di capire se TI Sparkle abbia dei problemi oppure i problemi siano dei server specifici.
Io propendo per la prima e sto cercando di spiegarne i motivi, ma sono pronto a cambiare idea se leggessi qualche spiegazione plausibile a dimostrazione del contrario.

Il fatto che ad un certo hop si possa alzare la latenza ed ai successivi possa riabbassarsi capita di continuo.
Quando c'erano i BRAS TIM saturi, tanto per farti un esempio, era tutto un: 100ms in primo hop, 10ms il secondo, 100ms il terzo hop, 10ms il quarto, e così via, poi a seconda dell'IP della connessione in quel momento, si arrivava a destinazione o con 10ms o con 100ms. Il problema era comunque la rete TIM.

E' similmente quello che accade verso quel server preso in esame sopra (intergenia.de): nel traceroute si vede che si alza a 125ms la latenza su Sparkle (non per uno sbalzo ICMP ma perchè c'è congestione), per poi riabbassarsi e riazarsi successivamente, segno che è da Sparkle che parte la saturazione.
Con TIM cambiando IP si può ovviare questa situazione, cioè fare in modo che nonostante alcuni router\hop di intermezzo alzino la latenza , alla fine si riesca ad arrivare a destinazione con una ping basso (per i server verso i quali si verifica il problema intendo).
Fermo restando che in assenza di saturazioni non c'è necessità di adottare queste precauzioni.

Voglio dire, tecnicamente non metto in dubbio le tue spiegazioni o quelle di matteo, io ti parlo solo di quello che rilevano ad un punto di vista pratico, e non mi pare di aver visto niente di particolarmente anomalo in questi eventi di cui stiamo parlando, mi sembra molto evidente quale sia la causa del problema.

Attenzione che le modifiche di routing che fa Matteo spesso e volentieri sono asimmetriche. Un provider ha il controllo su dove i pacchetti escono, ma non dove entrano, a meno di tagliare o abbassare la preference a tutto un transito, o (per chi è in CG-NAT) mascherarvi dietro un IP di una /24 diversa annunciata con pesi diversi.

Certo, fin'ora queste modifiche lato Seflow hanno sempre risolto il problema comunque, nel senso che sono state sufficienti.

[Gippe]

@Matteo/Webmaster ma nell’area clienti non è prevista la possibilità di modificare la password di accesso? Quella assegnata in automatico non è molto facile da memorizzare


Inviato dal mio iPhone utilizzando Tapatalk

[ZioMatt]

Originariamente inviato da MiloZ

Non ti seguo, o meglio, ti parlo in maniera terra terra, perchè quello che ci interessa è l'effettivo funzionamento della connessione più che una lezione di networking, e contestualmente cercare di capire se TI Sparkle abbia dei problemi oppure i problemi siano dei server specifici.

Bene, dimentica Sparkle, tracert, hop e routing. Fai un treno di ping (in mancanza di altre metriche di protocollo più raffinate, ad esempio quello che alcuni giochi rilevano) e guarda loss e latenza. Sono stabili? Sì => ticket chiuso.

Se invece vuoi leggere i tracert vanno capiti, altrimenti è come piantare una vite con un martello. E qui un minimo di teoria delle reti e di come funzioni il routing tra AS è indispensabile.

Originariamente inviato da MiloZ

Il fatto che ad un certo hop si possa alzare la latenza ed ai successivi possa riabbassarsi capita di continuo.
Quando c'erano i BRAS TIM saturi, tanto per farti un esempio, era tutto un: 100ms in primo hop, 10ms il secondo, 100ms il terzo hop, 10ms il quarto, e così via, poi a seconda dell'IP della connessione in quel momento, si arrivava a destinazione o con 10ms o con 100ms. Il problema era comunque la rete TIM.

No, confondi causa ed effetto.

Una saturazione o congestione agli hop precedenti influenza inconfutabilmente a salire le latenze sui nodi seguenti, perché il tempo è (da che c'è l'universo, e finché non tiriamo in ballo teorie relativistiche o alterazioni di gravità), monotono crescente.

Originariamente inviato da MiloZ

E' similmente quello che accade verso quel server preso in esame sopra (intergenia.de): nel traceroute si vede che si alza a 125ms la latenza su Sparkle (non per uno sbalzo ICMP ma perchè c'è congestione), per poi riabbassarsi e riazarsi successivamente, segno che è da Sparkle che parte la saturazione.

NO. Quel che vedi è che la RISPOSTA al fault (TTL Expired) di quel router ti arriva dopo 140+ ms (a memoria, son pigro). Il nodo successivo ti risponde sempre (e deve attraversare il punto problematico) in 17ms. Capisci che se parto in macchina da Milano e devo andare a Venezia, non posso metterci più tempo ad arrivare a Brescia che a Verona, perché è "di strada"...

Facciamo la traduzione in un esempio comprensibile con la vita reale (anche se stupido...) di cosa sia un traceroute. Voglio scoprire sperimentalmente quanta benzina (finché ci sono auto a motore termico...) mi serve per andare dal punto A al punto Z, e quanto tempo impiego a bruciarla. Parto con 1L nel serbatoio, e arrivo al paese B; qui chiamo il carroattrezzi e mi faccio riportare a casa, per riprovare con 2L (e arrivo a C), 3L... e così via, misurando anche quanto tempo mi occorre per il giro completo da casa a casa.
Bene, ti muore la macchina al punto C che è in autostrada, e chiami il soccorso; il carroattrezzi ti viene a prendere dopo che ha finito di far colazione e bersi il cappuccino (latenza ASIC-CPU), deve farsi tutta l'autostrada fino all'uscita successiva, e tornare per paesi e paesini sparsi per le montagne (routing inverso). Ci impiega 4h. Al tentativo successivo ti muore l'auto dopo 1h di autostrada al punto D appena fuori dal casello, il soccorso ACI è lì vicino, e a tornare a casa si rifà l'autostrada al contrario deserta, impiegando 2.3H in totale (andata e ritorno). Concludi che per arrivare al punto C all'autogrill ci si impiega più tempo che giungere al casello d'uscita D? No, perché hai messo meno benzina e hai seguito la stessa strada, semplicemente ci ha messo più tempo il carroattrezzi a riportarti a casa.

(Giuro che non ho bevuto nulla di alcolico, e in ogni caso sono Veneto e quindi scusato a prescindere).

[matteo-rock]

Originariamente inviato da Gippe

@Matteo/Webmaster ma nell’area clienti non è prevista la possibilità di modificare la password di accesso? Quella assegnata in automatico non è molto facile da memorizzare

No al momento non c'è, ma l'ho richiesta come feature qualche giorno fa. Tra l' altro stiamo espandendo il pannello per aggiungere nuove funzionalità. Il prossimo passo sarà la consultazione dello stato di avanzamento dell' attivazione direttamente online. Sarà disponibile a giorni.

Originariamente inviato da ZioMatt

Facciamo la traduzione in un esempio comprensibile con la vita reale (anche se stupido...) di cosa sia un traceroute. Voglio scoprire sperimentalmente quanta benzina (finché ci sono auto a motore termico...) mi serve per andare dal punto A al punto Z, e quanto tempo impiego a bruciarla. Parto con 1L nel serbatoio, e arrivo al paese B; qui chiamo il carroattrezzi e mi faccio riportare a casa, per riprovare con 2L (e arrivo a C), 3L... e così via, misurando anche quanto tempo mi occorre per il giro completo da casa a casa.
Bene, ti muore la macchina al punto C che è in autostrada, e chiami il soccorso; il carroattrezzi ti viene a prendere dopo che ha finito di far colazione e bersi il cappuccino (latenza ASIC-CPU), deve farsi tutta l'autostrada fino all'uscita successiva, e tornare per paesi e paesini sparsi per le montagne (routing inverso). Ci impiega 4h. Al tentativo successivo ti muore l'auto dopo 1h di autostrada al punto D appena fuori dal casello, il soccorso ACI è lì vicino, e a tornare a casa si rifà l'autostrada al contrario deserta, impiegando 2.3H in totale (andata e ritorno). Concludi che per arrivare al punto C all'autogrill ci si impiega più tempo che giungere al casello d'uscita D? No, perché hai messo meno benzina e hai seguito la stessa strada, semplicemente ci ha messo più tempo il carroattrezzi a riportarti a casa.

(Giuro che non ho bevuto nulla di alcolico, e in ogni caso sono Veneto e quindi scusato a prescindere).

Quoto in toto il tuo intervento, ma l' esempio che hai fatto mi ha costretto a prender un moment ahhaah

Originariamente inviato da MiloZ

Ma scusami, se non dipende da Ti Sparkle, mi spieghi come mai altre connessioni sullo stesso server non presentavano nessun aumento di latenza?
Questo è l'instradamento con Telia:

Traccia instradamento verso intergenia.de [85.25.0.17]
su un massimo di 30 punti di passaggio:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     7 ms     7 ms     6 ms  100.76.0.1
  3     7 ms     6 ms     7 ms  2.57.32.1
  4     7 ms     *        8 ms  10.248.0.37
  5     9 ms     7 ms     8 ms  mno-b3-link.ip.twelve99.net [62.115.174.40]
  6    17 ms    17 ms    18 ms  ffm-bb2-link.ip.twelve99.net [62.115.116.172]
  7    25 ms    17 ms    18 ms  ffm-b1-link.ip.twelve99.net [62.115.120.217]
  8    17 ms    17 ms    16 ms  ae2.cr-nunki.sxb1.bb.godaddy.com [62.115.144.9]
  9    17 ms    19 ms    17 ms  ae0.100.sr-sol.sxb1.dcnet-emea.godaddy.com [87.230.112.3]
 10    17 ms    16 ms    17 ms  ae1.100.sr-helios.sxb1.dcnet-emea.godaddy.com [62.138.129.2]
 11    17 ms    16 ms    25 ms  ae0.sr-f1-3.sxb1.dcnet-emea.godaddy.com [92.204.12.11]
 12    17 ms    16 ms    16 ms  static-ip-85-25-0-17.inaddr.ip-pool.com [85.25.0.17]

Traccia completata.

Per quasi tutto ti ha risposto ZioMatt, comunque con telia non hai notato il ping alterato perchè non usano ipconnect.de per raggiungerli, ma twelve99. Come mostrato dai traceroute (che non mi credi), il problema è tra ipconnect e godaddy. Bypassando quel loro collegamento eviti la problematica.

Capisco però che se ci mettiamo anche a guardare gli inalzamenti di ping di operatori che stanno nel mezzo non ne vieni più fuori perchè puoi fare tutte le modifiche del caso, poi salta fuori che twelve99 decide di girare tutto su ipconnect.de o lei stessa satura e tu torni al punto di partenza.

[MiloZ]

Originariamente inviato da ZioMatt

Una saturazione o congestione agli hop precedenti influenza inconfutabilmente a salire le latenze sui nodi seguenti, perché il tempo è (da che c'è l'universo, e finché non tiriamo in ballo teorie relativistiche o alterazioni di gravità), monotono crescente.

No, non è proprio cosi' (se la tua asserzione è assolutistica) almeno da un punto di vista "visivo" per quel che se ne può dedurre da un traceroute, ti ho fatto un'esempio pratico sopra.

NO. Quel che vedi è che la RISPOSTA al fault (TTL Expired) di quel router ti arriva dopo 140+ ms (a memoria, son pigro). Il nodo successivo ti risponde sempre (e deve attraversare il punto problematico) in 17ms. Capisci che se parto in macchina da Milano e devo andare a Venezia, non posso metterci più tempo ad arrivare a Brescia che a Verona, perché è "di strada"..

No stesso discorso di prima, negli hop successivi la latenza si rialza a livello di quello che tu chiami "fault" perchè c'è congestione.
E' successo anche con Wind su Telia una cosa simile, si alzava la latenza a 100ms sui nodi tedeschi di Telia, ma il problema era Wind (confermato anche da @gandalf2016), poi a seconda del server o dell'IP della connessione, si arrivava a destinazione a volte con 100ms a volte con 20ms (o comunque con la latenza "buona").
Qualche link a riguardo:

1 - https://www.hwupgrade.it/forum/showp...postcount=9987
2 - https://www.hwupgrade.it/forum/showp...postcount=9988
3 - https://www.hwupgrade.it/forum/showp...postcount=9989
4 - https://www.hwupgrade.it/forum/showp...postcount=9993
5 - https://www.hwupgrade.it/forum/showp...ostcount=10009
6 - https://www.hwupgrade.it/forum/showp...ostcount=10016
7 - https://www.hwupgrade.it/forum/showp...ostcount=10031

----------------------------------------------------------------------------------------------------------------------------------------------

Comunque ragazzi, forse la stiamo facendo troppo lunga, colpa anche mia, oggi quei due server con Seflow tutto ok.
Con TIM saturazione solita verso i server raggiunti tramite GTT con latenza sui 70ms e pacchetti persi a raffica (non ho provato a fare il giochino del cambio IP per vedere se cambiasse qualcosa): https://i.imgur.com/bAqWCKw.png
I due tedeschi che ieri andavano in saturazione con TIM, oggi regolari.
Speriamo sia stato un'avvenimento temporeneo.

Apprezzo sempre la buona volonta e pazienza di @ZioMatt e @matteo-rock e tutti gli altri che masticano bene di networking a fornire spiegazioni utili e preziose, ma da utenti vorremmo sempre la perfezione anche se magari in certi casi, ed in alcune circostanze, occorre un pizzico di pazienza in più.

Io però quando leggo quegli IP che iniziano con 195. per uscire all'estero...mi viene spontaneo farmi il segno della croce

[Cla.78]

@Miloz conserva un poco di banda anche per me, tra poco sarò dei vostri e sotto con dei test in gaming!

Devo bombardare ora di pec, email, ticket, telefonate e piccioni viaggiatori, per farmi mollare dall'altro ISP!

Comunque ho da fare i miei ringraziamenti al guru di pianetafibra, matteo-rock, una persona super disponibile, risponde puntualmente a tutte le mail, in modo sopratutto professionale e affabile, davvero altro "pianeta" questo ISP.

[ZioMatt]

Originariamente inviato da MiloZ

No, non è proprio cosi' (se la tua asserzione è assolutistica) almeno da un punto di vista "visivo" per quel che se ne può dedurre da un traceroute, ti ho fatto un'esempio pratico sopra.

Dipende da caso a caso. Uno spike di latenza su un nodo, seguito da uno a latenza inferiore non rappresenta saturazione. Lo è (o può esserlo) solo quando i ritardi aumentano di passo in passo.
Se hai il 6° hop a 140ms e il 7° a 20, non c'è congestione, semplicemente il sesto a risponderti se l'è presa comoda.

Originariamente inviato da MiloZ

a seconda del server o dell'IP della connessione, si arrivava a destinazione a volte con 100ms a volte con 20ms (o comunque con la latenza "buona").

In questo caso può esserci un load balancing/ECMP tra due percorsi con carico diverso, certamente.

Originariamente inviato da MiloZ

Io però quando leggo quegli IP che iniziano con 195. per uscire all'estero...mi viene spontaneo farmi il segno della croce

Sì però così perdonami, ma "vivi male" preoccupati quando vedi effetti tangibili... 25, 30 o 50ms non cambiano assolutissimamente nulla nella user experience, il resto prendilo come curiosità.
Stiamo pur sempre parlando di connessioni residenziali da 25€ o giù di lì al mese, non una linea dedicata con SLA e percorsi staticamente assegnati

[MiloZ]

Originariamente inviato da matteo-rock

Per quasi tutto ti ha risposto ZioMatt, comunque con telia non hai notato il ping alterato perchè non usano ipconnect.de per raggiungerli, ma twelve99. Come mostrato dai traceroute (che non mi credi), il problema è tra ipconnect e godaddy. Bypassando quel loro collegamento eviti la problematica.

Capisco però che se ci mettiamo anche a guardare gli inalzamenti di ping di operatori che stanno nel mezzo non ne vieni più fuori perchè puoi fare tutte le modifiche del caso, poi salta fuori che twelve99 decide di girare tutto su ipconnect.de o lei stessa satura e tu torni al punto di partenza.

C'avevo pensato anche io che l'unica altra spiegazione potesse essere una congestione tra Deutsche Telekom e godaddy , anche se rimango dell'idea che la causa principale fosse Sparkle (non perchè mi sono fissato ) perchè la saturazione ha impattato in contemporanea anche altri server allo stesso modo dallo stesso momento (anche alcuni tedesci con linea TIM, raggiunti tramite percorsi diversi).

Comunque per adesso il problema pare rientrato, questo credo sia l'importante.

P.S: NTT avrebbe agganciato Level3\Telia bypassando eventualmente quel tratto con DT, quindi potenzialmente risolvendo la questione.

[MiloZ]

Originariamente inviato da ZioMatt

Sì però così perdonami, ma "vivi male" preoccupati quando vedi effetti tangibili... 25, 30 o 50ms non cambiano assolutissimamente nulla nella user experience, il resto prendilo come curiosità.
Stiamo pur sempre parlando di connessioni residenziali da 25€ o giù di lì al mese, non una linea dedicata con SLA e percorsi staticamente assegnati

Bhe certo sono perfettamente d'accordo che parliamo di connessioni consumer, ma se è possibile mantenere un certo livello di qualità e c'è la volontà\competenze per fornire un servizio quantomeno superiore alla media, è sempre meglio no?
Poi se vogliamo omologare tutti gli ISP allo stesso livello solo perchè costano 30€, non parliamo neppure più di prestazioni e facciamo Tiscali o FibraCity.

Oltretutto se in caso di saturazioni\aumenti di latenza si aggiungono anche perdite di pacchetti (cosa che capita di frequente quando il link è congestionato), il collegamento comincia a degradare abbastanza, quindi l'user experience un pò cambia.

[matteo-rock]

Originariamente inviato da MiloZ

P.S: NTT avrebbe agganciato Level3\Telia bypassando eventualmente quel tratto con DT, quindi potenzialmente risolvendo la questione.

Mi faranno santo.... ritesta ora i tuoi link

[Yramrag]

Dai che forse ho convinto il boss a fare una fibra "di backup" con Pianeta Fibra...

[matteo-rock]

Originariamente inviato da Yramrag

Dai che forse ho convinto il boss a fare una fibra "di backup" con Pianeta Fibra...

C'è un problema... dopo che l'avrai provata non sarà più solo di backup

[Yramrag]

Originariamente inviato da matteo-rock

C'è un problema... dopo che l'avrai provata non sarà più solo di backup

E' quello che spero

[MiloZ]

Originariamente inviato da matteo-rock

Mi faranno santo.... ritesta ora i tuoi link

Je n'y crois pas! Eccezionale!

Traccia instradamento verso intergenia.de [85.25.0.17]
su un massimo di 30 punti di passaggio:

  1    <1 ms    <1 ms    <1 ms  192.168.0.1
  2     7 ms     7 ms     6 ms  host-32-108-136-83.retail.pianetafibra.it [83.136.108.32]
  3     7 ms     6 ms     7 ms  10.0.0.1
  4     7 ms     7 ms     7 ms  10.0.0.26
  5     7 ms     7 ms     7 ms  81.25.202.164
  6     7 ms     7 ms     7 ms  mno-b3-link.ip.twelve99.net [62.115.144.98]
  7    16 ms    15 ms    16 ms  ffm-bb2-link.ip.twelve99.net [62.115.116.172]
  8    16 ms    15 ms    17 ms  ffm-b1-link.ip.twelve99.net [62.115.121.11]
  9    16 ms    16 ms    15 ms  ae2.cr-nunki.sxb1.bb.godaddy.com [62.115.144.9]
 10    15 ms    15 ms    15 ms  ae0.100.sr-sol.sxb1.dcnet-emea.godaddy.com [87.230.112.3]
 11    24 ms    17 ms    24 ms  ae1.100.sr-helios.sxb1.dcnet-emea.godaddy.com [62.138.129.2]
 12    23 ms    24 ms    16 ms  ae0.sr-f1-3.sxb1.dcnet-emea.godaddy.com [92.204.12.11]
 13    15 ms    16 ms    16 ms  static-ip-85-25-0-17.inaddr.ip-pool.com [85.25.0.17]

Traccia completata.

Traccia instradamento verso e9333.g.akamaiedge.net [2.22.21.22]
su un massimo di 30 punti di passaggio:

  1    <1 ms    <1 ms    <1 ms  192.168.0.1
  2     9 ms     6 ms     6 ms  host-32-108-136-83.retail.pianetafibra.it [83.136.108.32]
  3     7 ms     7 ms     7 ms  10.0.0.1
  4     7 ms     6 ms     6 ms  10.0.0.26
  5     8 ms     7 ms     8 ms  81.25.202.164
  6    15 ms    20 ms     9 ms  ae-0.telecom-italia.mlanit02.it.bb.gin.ntt.net [129.250.9.42]
  7     6 ms     7 ms     7 ms  195.22.196.213
  8     8 ms     7 ms     7 ms  a2-22-21-22.deploy.static.akamaitechnologies.com [2.22.21.22]

Traccia completata.

Nel secondo caso si ricasca su Sparkle comunque o sbaglio?
Sbirciando il looking glass mi pareva che fino a poco fa si transitasse sul MINAP per arrivarci.

[matteo-rock]

akamai non annuncia tutto ovunque. Dipende su che loro POP finisci. Per alcune cose passerai dal Minap, altre dal mix e altre dai transiti.

In aggiunta gli annunci continuano a cambiare, quindi quello che vedi oggi, domani non vale più.

Le CDN fanno così spesso, loro, cloudfront, cloudflare etc.. tutte uguali

Originariamente inviato da MiloZ

Je n'y crois pas! Eccezionale!

Traccia instradamento verso intergenia.de [85.25.0.17]
su un massimo di 30 punti di passaggio:

  1    <1 ms    <1 ms    <1 ms  192.168.0.1
  2     7 ms     7 ms     6 ms  host-32-108-136-83.retail.pianetafibra.it [83.136.108.32]
  3     7 ms     6 ms     7 ms  10.0.0.1
  4     7 ms     7 ms     7 ms  10.0.0.26
  5     7 ms     7 ms     7 ms  81.25.202.164
  6     7 ms     7 ms     7 ms  mno-b3-link.ip.twelve99.net [62.115.144.98]
  7    16 ms    15 ms    16 ms  ffm-bb2-link.ip.twelve99.net [62.115.116.172]
  8    16 ms    15 ms    17 ms  ffm-b1-link.ip.twelve99.net [62.115.121.11]
  9    16 ms    16 ms    15 ms  ae2.cr-nunki.sxb1.bb.godaddy.com [62.115.144.9]
 10    15 ms    15 ms    15 ms  ae0.100.sr-sol.sxb1.dcnet-emea.godaddy.com [87.230.112.3]
 11    24 ms    17 ms    24 ms  ae1.100.sr-helios.sxb1.dcnet-emea.godaddy.com [62.138.129.2]
 12    23 ms    24 ms    16 ms  ae0.sr-f1-3.sxb1.dcnet-emea.godaddy.com [92.204.12.11]
 13    15 ms    16 ms    16 ms  static-ip-85-25-0-17.inaddr.ip-pool.com [85.25.0.17]

Traccia completata.

Traccia instradamento verso e9333.g.akamaiedge.net [2.22.21.22]
su un massimo di 30 punti di passaggio:

  1    <1 ms    <1 ms    <1 ms  192.168.0.1
  2     9 ms     6 ms     6 ms  host-32-108-136-83.retail.pianetafibra.it [83.136.108.32]
  3     7 ms     7 ms     7 ms  10.0.0.1
  4     7 ms     6 ms     6 ms  10.0.0.26
  5     8 ms     7 ms     8 ms  81.25.202.164
  6    15 ms    20 ms     9 ms  ae-0.telecom-italia.mlanit02.it.bb.gin.ntt.net [129.250.9.42]
  7     6 ms     7 ms     7 ms  195.22.196.213
  8     8 ms     7 ms     7 ms  a2-22-21-22.deploy.static.akamaitechnologies.com [2.22.21.22]

Traccia completata.

Nel secondo caso si ricasca su Sparkle comunque o sbaglio?
Sbirciando il looking glass mi pareva che fino a poco fa si transitasse sul MINAP per arrivarci.

[MiloZ]

Ok chiaro, presumevo potesse dipendere da qualcosa del genere.
Grazie mille comunque per l'interessamento a riguardo.

Curioso il fatto che verso quel server tedesco sopra, NTT dal Looking Glass passa da Level3, mentre dalla nostre connessioni aggancia Telia:

Tracing the route to 85.25.0.17

 1  ae-0.level3.mlanit02.it.bb.gin.ntt.net (129.250.9.234) 1 msec  2 msec  1 msec 
 2   *  *  * 
 3  ae19.cr-vega.sxb1.bb.godaddy.com (213.242.120.246) 24 msec  23 msec  23 msec 
 4  ae0.100.sr-helios.sxb1.dcnet-emea.godaddy.com (87.230.112.5) 28 msec  25 msec  24 msec 
 5  ae0.sr-f1-3.sxb1.dcnet-emea.godaddy.com (92.204.12.11) 23 msec  24 msec  23 msec 
 6   *  *  * 
 7   *  *  * 
 8   *  *  *

Io ci faccio subito la firma per Telia.