Ciao, allora non sono l'unico!
Ho fatto qualche ulteriore test che vi posso condividere
Ho notato che da qualche giorno ho circa 140ms di RTT verso un IP del mio ufficio (sempre qui nei pressi di Roma), su rete Unidata. Occupandomi io di gestire la rete aziendale, ho la possibilità di fare alcuni test:
Questo primo MTR è da rete Dimensione verso un IP del mio ufficio
HOST: marco-desktop Loss% Snt Last Avg Best Wrst StDev
1.|-- _gateway 0.0% 60 0.6 0.6 0.3 3.0 0.3
2.|-- 100.64.255.255 0.0% 60 2.9 3.0 2.7 4.6 0.3
3.|-- host13-110-32-195.dimensi 0.0% 60 3.1 3.1 2.4 20.9 2.3
4.|-- ??? 100.0 60 0.0 0.0 0.0 0.0 0.0
5.|-- e1-1.b.gem.uni.net 0.0% 60 125.1 125.1 124.7 129.8 0.7
6.|-- 10g-mlx4-bras2.gemelli.un 0.0% 60 122.4 122.5 122.0 122.8 0.2
7.|-- 213.233.18.### 0.0% 60 13.3 13.0 12.4 13.8 0.3
8.|-- 195.94.###.### 0.0% 60 137.8 138.2 137.4 139.3 0.4
(perdonate la censura degli ultimi due hop, sono entrambi IP di nostri router, in quanto in ufficio abbiamo una subnet IPv4)
Fino al penultimo hop la latenza è abbastanza buona (anche se comunque leggermente elevata rispetto a quanto mi aspetterei, considerando che è da Roma a Roma, ma nulla di particolarmente problematico), e solo dall'ultimo hop la latenza peggiora notevolmente.
La causa in questi casi è spesso il routing asimmetrico (i pacchetti tornando indietro seguono un percorso diverso).
Per cui, per confermare la mia teoria ho fatto un traceroute anche dal mio ufficio (dallo stesso IP dell'hop 8) verso il mio router di casa con Dimensione:
3.|-- bras2.gemelli.uni.net 0.0% 10 1.8 2.1 1.6 2.6 0.3
4.|-- 10g-bras2-mlx4.gemelli.un 0.0% 10 2.0 2.2 1.8 2.6 0.3
5.|-- e5-4.a.nam.uni.net 0.0% 10 4.5 91.8 2.5 197.9 83.0
6.|-- 194-183-16-218.uni.it 0.0% 10 13.4 5.3 2.5 13.4 4.2
7.|-- ge-0-1-6-200.rom22.ip4.ti 0.0% 10 3.4 20.8 3.0 110.7 36.5
8.|-- ae2.cr6-mil2.ip4.gtt.net 0.0% 10 11.5 11.9 11.4 12.6 0.4
9.|-- ip4.gtt.net 0.0% 10 11.7 11.8 11.5 12.5 0.3
10.|-- 195.22.197.11 0.0% 10 112.5 112.4 112.1 112.6 0.2
11.|-- 195.22.197.10 0.0% 10 138.2 140.6 138.0 143.7 1.7
12.|-- 89.221.32.130 0.0% 10 158.0 160.7 148.1 184.1 12.1
13.|-- 5-178-46-11.des.seabone.n 0.0% 10 138.8 139.0 138.5 139.5 0.4
14.|-- host26-110-32-195.dimensi 0.0% 10 145.3 139.9 139.0 145.3 1.9
15.|-- host##-6-32-195.dimension 0.0% 10 141.3 140.7 140.1 141.3 0.4
Ed effettivamente il percorso è totalmente diverso!
La causa del RTT elevato sembra essere Sparkle, transito che Dimensione ha iniziato a utilizzare di recente (e che, da un test che ho fatto con RIPE ATLAS, al momento sembra essere usato quasi esclusivamente).
Ciò che non mi spiego è perché, se Unidata e Dimensione sono entrambi nella LAN pubblica del Namex, questo non venga scelto come transito.
Potrei pensare che sia a causa una policy di Unidata, ma in realtà lo stesso succede con diversi (ma non tutti) provider che partecipano alla LAN pubblica del Namex con cui ho avuto modo di testare (per nominarne uno, lo stesso succede con WindTre).
Inoltre, ripetendo i test dalla linea di un altro utente (Dimensione) del forum, sempre raccolto a Roma, non riscontra nessun problema di questo tipo (e facendo un traceroute da Unidata verso il suo IP, in questo caso passa per namex, non per GTT e Sparkle).
Anche eseguendo le stesse query dal looking glass di Dimensione, il ping verso quell'IP del mio ufficio ad es. è di 3ms.
Penso quindi ci siano sia problemi lato Sparkle, sia forse riguardo come la subnet del mio IPv4 venga annunciata (?).
Ho inviato un paio di mail al buon @giusgius con tutti i traceroute (questi due più diversi altri), che il team di Dimensione potrà analizzare nel tentativo di risolvere al meglio la problematica.
Anzi, mi scuso con Giuseppe per non aver incluso tutto in una mail unica