Problema di instradamento, a chi compete?

[Shizou]

Saluti a tutti.

Breve riassunto della vicenda:
paesino in provincia di Udine in piena zona anti-digital-divide.
Dopo tre anni di schifo telecom finalmente compaiono i primi fornitori wimax.
Ne scelgo uno molto popolare che generalmente riceve recensioni molto positive e attivo.
Tutto bene per nove mesi, poi comincia lo schifo pure con loro.

Io uso la connessione principalmente per videogiochi online e chat voip, seguiti da navigazione/video. Download poca roba.
Quindi le mie priorità sono ping e perdita dati.
Un mesetto fa comincio a notare gravi problemi di lag e rubberbanding giocando a battlefield 4 e, pur essendo piuttosto ignorante in materia, almeno sono in grado di fare qualche test con pingplotter.

Il risultato lascia pochi dubbi:


Le colonnine rosse nel grafico orizzontale in basso indicano time-out e perdita dati completa sul secondo nodo (10.40.8.69). Rilevo inoltre una perdita dati costante, sullo stesso nodo, del 10-20%.
L'immagine allegata è un test fatto su google.it per mezzora con invio ping ogni 5 secondi. I risultati sono uguali con qualsiasi altra destinazione: il problema è sempre sul secondo passaggio.

Ovviamente chiamo l'assistenza e, dopo un mese di boiate "per noi è tutto a posto, ping perfetto, perdita dati nulla", finalmente un tecnico (ridicolo definirli tecnici) mi dice che quel passaggio è un server internazionale su una tratta non di loro competenza. Non mi è dato sapere dove.

In pratica, i test che loro fanno verso di me non passano da lì e risulta tutto a posto. La mia connessione, invece, verso OVUNQUE, passa sempre da quell'ip, perdendo continuamente dati.

Veniamo alle domande:
-perchè tutti i miei dati passano di la?
-come faccio a capire dov'è quell'ip?
-perchè la mia connessione viene dirottata chissà dove, nel passaggio immediatamente successivo alla tratta di competenza del fornitore?
-se il problema non dipende da me e non dipende dal fornitore, da chi dipende?
-come lo risolvo?
-è normale una cosa del genere?

Grazie a tutti

[lorenzo.c]

10.40.8.69 e' un IP privato che collega il primo hop al secondo (il gateway di Eolo all'internet exchange), e' una pratica che si utilizza per non sprecare IP pubblici sui transiti. Non puoi intervenire per risolvere, quel che viene dopo "eolo-gw.net.ngi.it" non e' di competenza tua ma del provider.

[Shizou]

Loro dicono che non è loro competenza e che è un ip internazionale.
Mi pare abbastanza evidente che sia una boiata colossale, dato che anche il ping sul loro server di test (tre passaggi totali) passa di la.

Come faccio a farglielo capire?
Mi stanno prendendo in giro?

[Wolfhwk]

Originariamente inviato da Shizou

Loro dicono che non è loro competenza e che è un ip internazionale.
Mi pare abbastanza evidente che sia una boiata colossale, dato che anche il ping sul loro server di test (tre passaggi totali) passa di la.

Come faccio a farglielo capire?
Mi stanno prendendo in giro?

ip internazionale?

Più che farglielo capire (spiegare ad un ISP come funziona il routing, paradossale), ti tocca "alzare i toni" e dargli un ultimatum, che se il problema non viene risolto, passerai alla concorrenza. Mandagli tutti i rilevamenti che hai effettuato e un resoconto dettagliato del disagio provocato.

[Shizou]

Tanto per chiarire se ho capito bene io. Correggetemi se ho capito cazzate.
I primi due ip sono sempre gli stessi, a prescindere dalla destinazione (questo è certo).
Il primo ip è il loro gateway.
Il secondo ip è un loro ip privato di transito (cercando con google mi è addirittura uscito che è nel golfo di guinea ).
Il terzo è un internet exchange e dal terzo a seguire il percorso varia a seconda della destinazione ed è fuori dalla loro competenza.

Cambiando destinazione dei test, è corretto presumere che tutti i passaggi da me al dns primario siano di loro competenza?

Questo è il test verso il dns primario (il terzo è 100% pl fisso perchè è protetto, giusto?):




Quando gli idioti dell'assistenza mi dicono che il test fatto da loro verso di me NON passa per l'ip incriminato (10.40.8.69), mi stanno dicendo una cazzata?

[Wolfhwk]

Quel ip privato...sembra quasi che di transito ci sia la rete di un altro ISP (fastweb?) e il punto in questione risulta congestionato (aka i pacet loss) o semplicemente degradato layer 1/2 (meno probabile). Dato che è un punto di passaggio obbligatorio a quanto sembra, non instraderanno su altri percorsi, o perlomeno non hanno necessità di scomodare il provider di transito (?), a cui potrebbero dover pagare altri punti di transito verso il sistema autonomo di NGI (il suo core).
A parte la supercazzola, il shield con loss 100% sembra il firewall di bordo (edge firewall), dove nel prossimo hop segue il core di NGI ( dove si trova il dns nsr1).
Solo ipotesi, ma se vere, non risolverai il problema nemmeno minacciandoli.

Beh, le strade possono essere diverse, dipende dalle policy che usano lì gli ISP.
Dovrebbero fare il test da te. Altro caso potrebbe essere un NAT sempre configurato a livello ISP e a questo punto a loro risulta un altro indirizzo, che dalla tua parte viene invece tradotto.

Oppure semplicemente l' ip privato è dentro la loro rete e fanno finta di nulla, visto che probabilmente siete in pochi a lamentarvi e loro sicuramente non modificheranno la configurazione per 4 gatti.

[wizard1993]

Originariamente inviato da Shizou

Cambiando destinazione dei test, è corretto presumere che tutti i passaggi da me al dns primario siano di loro competenza?

no. Anzi, assolutamente improbabile. Da Udine a Milano (Dove mi risulta abbia fisicamente sede ngi con i propri server) non credo proprio abbiano le loro dorsali. Al 99% passano da Telecom che seguirà percorsi e politiche di traffico proprie

Originariamente inviato da Shizou

Quando gli idioti dell'assistenza mi dicono che il test fatto da loro verso di me NON passa per l'ip incriminato (10.40.8.69), mi stanno dicendo una cazzata?

Non necessariamente... Può anche essere che il gateway "locale" della tua zona sia connesso a più nodi differenti come bilanciamento del carico o che so io

[lorenzo.c]

Il secondo ip è un loro ip privato di transito (cercando con google mi è addirittura uscito che è nel golfo di guinea ).

E' un IP privato nel senso che non e' pubblicamente indirizzabile. E' un indirizzo di una rete privata, come il tuo 192.168.1.1 per capirci.
Quoto il fatto che sia semplicemente quel link ad essere congestionato, pare anche a me sia su Fastweb (di solito loro usano 10.x.x.x).

Quando gli idioti dell'assistenza mi dicono che il test fatto da loro verso di me NON passa per l'ip incriminato (10.40.8.69), mi stanno dicendo una cazzata?

Non necessariamente, i percorsi per il traffico verso eolo-gw.net.ngi.it possono essere multipli. E comunque piano con gli insulti

[Shizou]

Intanto grazie a tutti. Il terzo hop fisso al 100% non l'ho proprio considerato dato che è sicuramente protetto.

Dopo l'ultimo ticket di ieri sera hanno finalmente ammesso (testuale): "c'è una possibilità che la mia diagnosia sia stata errata".
E mi hanno chiesto di mandargli i risultati dei test fatti verso 8.8.8.8 per ricostruire che giri fa la mia linea.
Sto vedendo ora e mi sembra un dns pubblico di google. Cambia poco, tanto i primi due hop sono sempre gli stessi: gateway e l'ip intasato, che continua ad andare in time-out.

Sono episodi come questo che mi stanno veramente disgustando. Pare che su questo mercato non ci sia niente di regolamentato in modo chiaro e univoco. Impossibile capire da chi dipende un problema. Impossibile avere una garanzia su ping e packet loss, come se la banda fosse l'unica cosa che conta.

Gli insulti se li meritano tutti. Vogliono passare come alternativa "giovane" ai grossi provider mafiosi ma usano esattamente gli stessi metodi.

[wizard1993]

Originariamente inviato da Shizou

Sto vedendo ora e mi sembra un dns pubblico di google. Cambia poco, tanto i primi due hop sono sempre gli stessi: gateway e l'ip intasato, che continua ad andare in time-out.

Non vorrei "smontarti" ma è piuttosto normale che gli apparati non rispondano al ping (e quindi ad un traceroute)... glielo si disabilita volutamente per motivi di sicurezza

[Shizou]

Penso che se fosse una questione di sicurezza mi segnerebbe perdita 100% costante ad ogni ping, come il terzo hop.
Esempio:




Sul secondo invece è casuale. Non è in time-out perenne. A volte passa, a volte perde il 10-20%, a volte va in time-out.

Sbaglio?

[Wolfhwk]

Ci posti le statistiche dopo qualche ora, di mtr?

http://www.bitwizard.nl/mtr/

Sul mio linux -> apt-get install mtr

e poi lanci mtr www.google.it

e lasci andare un paio d'ore.

Poi ci posti lo screenshot.

[Wolfhwk]

Originariamente inviato da Shizou

Sul secondo invece è casuale. Non è in time-out perenne. A volte passa, a volte perde il 10-20%, a volte va in time-out.

Sbaglio?

O link congestionato oppure icmp traffic limiter impostato.

[lorenzo.c]

Sembra anche a me che shield1-ext limiti l'ICMP, questo un traceroute verso maya.ngi.it:

[Wolfhwk]

Thread opener, procuraci i dati anche da http://netalyzr.icsi.berkeley.edu/

Aspetta che completi il test e posta.

[Shizou]

Scusa se sono incapace io, ma non sto capendo cosa devo fare per usare mtr.
Netanalyzr avevo completato il test ma ho chiuso la pagina per sbaglio e ora non mi apre più un razzo.


Intanto l'ultima risposta che ho avuto dal'assistenza NGI (tanto ormai si è capito che sono loro), dopo che gli ho mandato i test fatti verso 8.8.8.8

da verifiche incrociate con i colleghi del reparto di networking è emerso che non vi sono nostre anomalie sulla tratta. In questi giorni si sta verificando una saturazione verso il mix di google che falsa i risultati. Inoltre quello che avevo erroneamente indicato come un ip esterno è l'ip di un nostro apparato che smista le nostre connettività. Quello è il suo compito e il fatto che eseguendo ping o ping flood verso di esso scarti non implica nessun anomalia, semplicemente non è la sua priorità rispondere alle azioni prima citate. La cosa attendibile al momento è semplicemente effettuare un test all'indirizzo http://test.ngi.it e verificarne latenza e prestazioni di banda, ma dovrebbe funzionare correttamente difatti nel grafico che ci ha riportato non vi sono mai packet loss o latenze anomale verso l'indirizzo finale 88.149.128.130

Mi sa tanto di presa per il culo, ma ditemi se sto capendo male io.

Prima parte:
prima mi fanno fare un test verso un dns google, poi mi dicono che guarda caso questi giorni il mix di google ha problemi.
Questo è il test:

Spoiler:

Qua le cagate mi sembrano due, e belle grosse:
1- sul mix di google rilevo problemi molto sporadici
2- la mia connesione fa schifo verso ovunque, non solo google


Seconda parte:
intanto ammettono di avermi rifilato una cazzata (l'ip internazionale). Poi praticamente vogliono farmi credere che gli unici problemi seri che rilevo sono su roba loro, ma i test non sono attendili perchè non è priorità di quell'apparato rispondere ai ping.
Io posso misurare verso qualsiasi destinazione e rilevare problemi SOLO LI. Ma sono problemi immaginari perchè non è compito di quell'apparato.

Quindi io per quale motivo non riesco a farmi mezzo round di battlefield senza farmi venire la nausea?

[Wolfhwk]

Io ho bisogno dei dati che ti ho chiesto.

Rifai il netalyzer con altro browser/su altro dispositivo e posta la pagina.

Per mtr. Sei su linux, mac o windows?

Per windows qui http://winmtr.net/

Comunque è realistico ciò che dicono a proposito del router 10.x.x.x
Non è proprio tenuto a rispondere a tutti i ping, aka, applicano il QoS dando priorità ad altro traffico e limitando di conseguenza ICMP.

Poi dimenticavo, per le domande:

1. Infatti. Mi sembra normale.
2. Probabilmente fa schifo verso ovunque. Ma è da testare.

[Wolfhwk]

Originariamente inviato da Shizou

Inoltre quello che avevo erroneamente indicato come un ip esterno è l'ip di un nostro apparato che smista le nostre connettività.

Intanto mi rifaccio due risate

[Shizou]

Windows, scaricato.
Verso dove vuoi che misuro con mtr?

L'altro vedo di rifarlo.

[Wolfhwk]

www.garr.it