- Modificato
marco89ct ma infatti sto cercando di capire .... semplicemnte perchè nelle due linee che ho tutte e due hanno il ping raddoppiato. e visto che il titolo è strano aumento ping sto cercando di capire se il mio è temporaneo o no....
Strano aumento di ping
Tengo monitorato vari ip tra cui 100.64… il primo ip dei traceroute di dimensione. Oggi verso le 18 tutti gli ip monitorati sono aumentati di circa 2ms, tra cui 100.64… senza aver cambiato ip, riavviato o una nuova sessione ppp. È sempre stato stabile nell’ultimo mese, da quando ho riavviato l’ultima volta.
marco89ct Se becco un IP che mi fa pingare un server di Roma 12ms continuerò sempre a pingarlo 12ms fino a quando non chiedo al mio ISP di cambiarmi IP.
prova con un mtr -T, se ti cambia la latenza su ookla senza cambiare IP, probabilmente la vedrai cambiare anche qui
Usi Docker e fai girare quello che vuoi; esempio di applicazione che fa uptime monitoring https://github.com/louislam/uptime-kuma
- Modificato
Se cambia la latenza al primo step e' dovuto ad OF e di conseguenza aumenta il ping su tutto cio' che viene dopo.
Questo e' probabilmente un rerouting dovuto al load balancing della rete
No non cambia. 8.8.8.8 pingo sempre 28ms mentre 8.8.4.4 sempre 20ms indipendemente dagli speed test.
Forse questo non e' chiaro, la latenza non varia casualmente. Ci sono delle destinazioni predefinite che prendono sempre la strada OF piu' lunga ed altre destinazioni predefinite che prendono sempre la strada piu' corta.
Quando faccio partire uno speed test per esempio su Vodafone Roma, probabilmente hanno due macchine per fare lo speed test. Ed una macchina passa per il routing OF piu' lungo mentre l'altra per il routing OF piu' corto.
Indipendentemente da 8.8.8.8 che prende sempre la strada piu' lunga mentre 8.8.4.4 prende la strada piu' corta.
marco89ct Se cambia la latenza al primo step e' dovuto ad OF e di conseguenza aumenta il ping su tutto cio' che viene dopo.
Questo e' probabilmente un rerouting dovuto al load balancing della rete
Si, era per far vedere che sono cose che capitano anche senza riavviare il modem. Chissà che giro fa per arrivare il pacchetto a Milano, nel mio caso.
- Modificato
marco89ct No non cambia. 8.8.8.8 pingo sempre 28ms mentre 8.8.4.4 sempre 20ms indipendemente dagli speed test.
Forse questo non e' chiaro, la latenza non varia casualmente. Ci sono delle destinazioni predefinite che prendono sempre la strada OF piu' lunga ed altre destinazioni predefinite che prendono sempre la strada piu' corta.Quando faccio partire uno speed test per esempio su Vodafone Roma, probabilmente hanno due macchine per fare lo speed test. Ed una macchina passa per il routing OF piu' lungo mentre l'altra per il routing OF piu' corto.
Indipendentemente da 8.8.8.8 che prende sempre la strada piu' lunga mentre 8.8.4.4 prende la strada piu' corta.
Credo che quello che ti voglia far provare lui sia vedere se ci sono degli hop "sfasati" nell'MTR.
Un pacchetto verso 8.8.8.8 (assumento costanti MAC_SRC, IP_SRC) prende un percorso A in virtù della sua destinazione ma, siccome comunque la rete è L2 (anche se prende decisioni L3!) attraversa gli stessi N hop di un altro pacchetto verso 1.1.1.1 (IP buttato a caso) che prende il percorso B.
Facendo un MTR e quindi generando N pacchetti (ognuno con la propria destinazione IP e quindi ognuno libero di prendere la strada A o quella B) dovresti vedere che questi vanno al 50% per il percorso "veloce" e al 50% per quello "lento".
(Ho fatto l'assunzione che i percorsi siano solo 2 e siano equiprobabili ma probabilmente non sarà così; nella pratica vedi un traceroute dove la latenza non è strettamente crescente)
@gandalf2016 Sai cosa sarebbe divertente? Siccome, è su rete FiberTelecom e ha IPv6, prendere una VPS a Milano e assegnarci 100 IP(v6) a caso e loggare il ping time.
Lorenzo1635 prendere una VPS a Milano e assegnarci 100 IP(v6) a caso e loggare il ping time.
Esatto, li avresti dei bei dati
marco89ct Vodafone Roma
L’IPv4 è unico, però ha anche un IPv6 sempre unico.
Quindi magari dipenderà se ti colleghi in v4 o v6?
Se hai abilitato v6, dovrebbe andare solo in v6 per happy eyeballs
gandalf2016 Se hai abilitato v6, dovrebbe andare solo in v6 per happy eyeballs
Ookla preferisce V4 by-default e gli host V6 hanno ID diversi (https://ipv6.speedtest.net/)
- Modificato
Un pacchetto verso 8.8.8.8 (assumento costanti MAC_SRC, IP_SRC) prende un percorso A in virtù della sua destinazione ma, siccome comunque la rete è L2 (anche se prende decisioni L3!) attraversa gli stessi N hop di un altro pacchetto verso 1.1.1.1 (IP buttato a caso) che prende il percorso B. Facendo un MTR e quindi generando N pacchetti (ognuno con la propria destinazione IP e quindi ognuno libero di prendere la strada A o quella B) dovresti vedere che questi vanno al 50% per il percorso "veloce" e al 50% per quello "lento".
Confermo anche questo.
Tra le mille mille prove che ho fatto mi era successo una volta che buttando in contemporanea 6 ping test su 6 server che sapevo usassero sia il percorso A che il percorso B nella rete Open Fiber, appena lanciavo il test sul percorso lungo, il test che invece prendeva il percorso corto veniva influenzato ed i pacchetti di un singolo test iniziavano ad prendere sia il percorso A che il percorso B.
Quindi se per esempio singolarmente pingavo 8.8.8.8 28ms mentre 8.8.4.4 20ms se li lanciavo insieme, anche 8.8.4.4 iniziava a pingare 28ms.
Questo mi era successo con Dimensione mi ricordo, perche' nel loro caso ero sul BRAS di Milano e se lo pingavo mi dava 28ms. Ma se pingavo 8.8.8.8 pingavo 22ms. Paradossalmente pingavo il BRAS piu' delle destinazioni successive (riportato in passato da me in vari topic).
In questo caso se lasciavo il ping sul BRAS ed iniziavo a pingare altri server che avrebbero dovuto prendere la strada breve, la latenza iniziava ad essere ballerina, come se i pacchetti prendessero entrambe le strade.
A questo punto si può davvero provare a dare a un pezzo di ferro a Milano un sacco di indirizzi (ovviamente in IPv6, in IPv4 è infattibile come cosa) e plottare il ping count.
Nel grafico che viene fuori si dovrebbero vedere due gaussiane una per percorso.
Ovviamente se poi hai modo di segnalare la cosa a FiberTelecom con i dati in mano.
- Modificato
Lorenzo1635 Ovviamente se poi hai modo di segnalare la cosa a FiberTelecom con i dati in mano.
Si gia' fatto, sia con FT che con Dimensione mesi fa.. i ragazzi di Dimensione mi avevano cambiato BRAS 3 volte e IP circa 20 volte. Ma ovviamente loro non possono far niente. E' OF che modifica il percorso nella tratta di loro competenza.
FT attendo risposta, ma la cosa divertente e' che lo stesso Raffaele di Klik ha fatto qualche test sulla sua linea FT da Napoli ed abbiamo visto che anche lui aveva la stessa stranezza 
marco89ct E' OF che modifica il percorso nella tratta di loro competenza.
Infatti, stesso Ping stessa destinazione del mio messaggio precedente, senza riavvii senza fare nulla
Si ok ma il suo è un problema diverso: in base a cosa pinga (anche se magari sono lo stesso pezzo di ferraglia) la latenza gli cambia (anche di un +40% in più).
Tu stai pingando il tuo BRAS e ti hanno cambiato l'instradamento perchè avevano lavori da fare ma impatta tutto,
normale routine.
Lorenzo1635 non lo ritenevo un problema il mio, fa nulla
- ConnectLife
- Modificato
Buongiorno a tutti, oggi ho fatto una chiamata con un mio caro amico che lavora nel reparto IT di OF.
Mi conferma quanto indicato da Marco, quindi @marco89ct devo darti ragione 
Nello specifico, l'accesso viene raccolto al PCN e trasportato fino al POP del cluster A/B. Sull'OLT non fanno alcuna manipolazione (tralasciando le CVLAN ecc), solo raccolta e trasporto al primo POP di provincia.
Dal POP A/B (esempio nel mio caso VR_02) viene poi trasportato su MIH_0x (nel caso di Milano)
Sui POP di raccolta MIH_0x ci sono vari collegamenti verso il MIX con percorsi più lunghi rispetto ad altri. Quindi fanno LB distribuendo il carico tra i vari link disponibili.
Il tutto viene gestito con OSPF e metriche
Se non ho capito male LB viene gestito mediante SRC_MACADDRESS > DEST_IP_ADDRESS
Questo spiega il motivo per la quale su alcuni link avete latenze più alte..
Mi dice però che è strano un aumento del doppio, un link rispetto ad un altro dovrebbe aggiungere solo qualche ms in più e non il doppio..
Nei test che ho effettuato da PCN VRDRA (CD), trasportato su VR_02 (AB) e successivamente a MIH_04 per poi finalmente arrivare sui nostri BNG al MIX vedo:
SEQ HOST SIZE TTL TIME STATUS
0 8.8.4.4 56 120 12ms119us
1 8.8.4.4 56 120 11ms956us
2 8.8.4.4 56 120 11ms933us
3 8.8.4.4 56 120 11ms748us
4 8.8.4.4 56 120 11ms669us
5 8.8.4.4 56 120 11ms768us
6 8.8.4.4 56 120 11ms709us
7 8.8.4.4 56 120 11ms964us
8 8.8.4.4 56 120 11ms936us
9 8.8.4.4 56 120 11ms779us
10 8.8.4.4 56 120 11ms697us
SEQ HOST SIZE TTL TIME STATUS
0 8.8.8.8 56 119 11ms618us
1 8.8.8.8 56 119 12ms5us
2 8.8.8.8 56 119 12ms51us
3 8.8.8.8 56 119 11ms350us
4 8.8.8.8 56 119 11ms312us
5 8.8.8.8 56 119 11ms396us
6 8.8.8.8 56 119 12ms71us
7 8.8.8.8 56 119 11ms706us
8 8.8.8.8 56 119 11ms828us
9 8.8.8.8 56 119 11ms379us
10 8.8.8.8 56 119 11ms747us
8.8.4.4 e 8.8.8.8 hanno la medesima latenza, potrebbe quindi essere che per gli utenti del SUD Italia fanno LB anche al Namex e se beccate un link più lungo/saturo avete le latenze indicate. Ovviamente sono solo mie considerazione che magari avrò il piacere di farmi confermare dall'amico in OF appena avrò altra occasione di sentirlo
Probabilmente il tratto che facciamo noi in Veneto non soffre del problema
Spero di aver fatto chiarezza
Ciao a tutti
- Modificato
danny20091989 Sui POP di raccolta MIH_0x ci sono vari collegamenti verso il MIX con percorsi più lunghi rispetto ad altri. Quindi fanno LB distribuendo il carico tra i vari link disponibili.
8.8.4.4 e 8.8.8.8 hanno la medesima latenza, potrebbe quindi essere che per gli utenti del SUD Italia fanno LB anche al Namex e se beccate un link più lungo/saturo avete le latenze indicate. Ovviamente sono solo mie considerazione che magari avrò il piacere di farmi confermare dall'amico in OF appena avrò altra occasione di sentirlo
Intanto grazie del tuo interessamento che è sempre utile capirne di più. 
Probabile quindi che lo facciano anche in altre zone questo tipo di bilanciamento, solo che magari i link in LB in certi casi hanno la medesima latenza e l'utente non se ne accorge.
