Newsgroup: it.tlc.gestori.fastweb
Titolo: ADSL lenta e prova Tracert (un po' lungo)

Da circa un mese ho notato che la mia connessione asdl era un po' + 
lenta del solito, quindi ho deciso di chiamare il 192193.
Io ho una adsl 6Mbit; ho provato a scaricare le solite immagini ISO 
debian: qui la velocità è OK infatti scarico stabilmente a 550 - 
600Kb/sec...
Il problema c'è nella navigazione web che è lenta e quindi si aprono le 
pagine con lentezza che non si addice ad una 6Mbit, almeno fino a circa 
un mese fa era molto più veloce.
Ho contattato un tecnico del 192193 e mi ha fatto fare parecchie prove, 
tra queste mi ha fatto fare il tracert, da finestra dos, su alcuni siti 
italiani e abbiamo notato che sempre al 12° passaggio la mia connessione 
andava a passare per 3 volte su un server dell'Ohio (26.26.26.xx) con 
tempi di risposta alti e quindi il tecnico ha dedotto che la lentezza 
era da imputare a questa anomalia e quindi avrebbe aperto un guasto per 
le verifiche tecniche sui loro apparati in quanto il comportamento sui 2 
pc che ho in casa era lo stesso.
Il giorno dopo mi hanno avvertito con un SMS che il mio problema era 
stato felicemente risolto, ma provato immediatamente sia il tracert che 
la navigazione era sempre ugualmente lenta.
Ho ricontattato il 192193 e mi è stato detto che per loro non esistono 
problemi sulla mia connessione e quindi per loro è tutto OK.
Io vi chiedo se gentilmente avete qualche minuto e potete fare la prova 
con tracert in modo che si possa verificare se il passaggio in Ohio è 
una cosa normale oppure c'è veramente qualcosa che non va.
La sintassi per il tracert è la seguente:
aprire la finestra dos con "cmd"
scrivere: "tracert 
www.google.it
" oppure "tracert 
www.corriere.it
" e 
battere invio
verificare i passaggi.
Vi ringrazio molto per la vs pazienza e per l'aiuto che vorrete darmi,
Giancarlo

 una cosa normale oppure c'è veramente qualcosa che non va.
ADSL Milano, passo anch'io da quei 3 ip ma non ho problemi di lentezza 
nella navigazione.
-- 
E sun che a specià la terza unda e sun che per vedè cume la sarà
e sun pruunt a basà la terza unda e sun pruunt a ciapà tücc i so s'ciàff

 nella navigazione.
ok, ti ringrazio! Allora credo che abbia preso un granchio il tecnico 
fastweb che mi ha riferito che assolutamente i pacchetti non dovrebbero 
passare da quei server... io in tutta sincerità, credo che sia normale 
invece che i pacchetti vadano ad instradarsi (insspiegabilmente) su quei 
server.
Evidentemente la lentezza dipenderà, come al solito, dalla congestione 
degli apparati nella mia zona.
Giancarlo

 pc che ho in casa era lo stesso.
Purtroppo il tecnico con cui hai parlato è incompetente. Il problema è un 
sovraccarico di rete specifico di quel server interno della rete Fastweb.
La classe 
26.0.0.0/24
 è infatti riservata da MILNET ma non è ancora 
annunciata. Fastweb utilizza questa classe di IP (come molte altre) in 
completa violazione degli RFC per la sua rete interna.
Il server menzionato è quindi un server (probabilmente router) interno 
della rete Fastweb, che in questo periodo soffre di sovraccarico generale 
(ci sono altri report al riguardo su Internet). In particolare, in questo 
periodo sono in atto varie sperimentazioni tecnologiche all'interno della 
rete Fastweb che potrebbero causare leggeri disservizi: mi aspetto che il 
tuo tempo di ping sia, per esempio, al massimo raddoppiato, ma non certo 
decuplicato.
Non hai postato un traceroute completo quindi non posso aiutarti oltre, 
ma l'impressione che ho è che se ti sei accorto veramente di un problema 
nella navigazione, questo non può dipendere dal sovraccarico di quel 
singolo router.
Penso in altre parole che il tuo problema sia da cercarsi altrove. La 
prova più semplice in questi casi è staccare tutto dall'HAG, farsi 
prestare un computer da un amico (magari un portatile con Linux, non 
inzuppato di virus) e fare delle prove per vedere se il problema è 
veramente specifico della connessione o no.
-- 
Conte Frobenius

 tecnico ha dedotto che la lentezza era da imputare a questa anomalia
Come ti hanno gia' indicato, gli hop associati agli IP 26.26.26.* sono
interni alla struttura di rete MAN FW = sono associati al sistema IPPU
di gestione autenticazione/instradamento delle sessioni di rete delle
utenze FW in architettura base Hidden/Dynamic NAT M-1 (cioe' nel caso
delle utenze Residenziali/SOHO senza che sia attivo il servizio IP
Pubblico IPPD).
In corrispondenza del passaggio su tali hop non e' comunque inusuale
il riscontro di un aumento nei tempi di risposta, ma per capire se vi
sia associato (o meno) un problema occorre valutarne lo scarto in ms
rispetto all'instradamento su rete FW.
Se riporti l'esito del tuo traceroute e' possibile verificare se vi sia
effettivamente un problema in merito, oppure se l'operatore abbia preso
un'altra 'cantonata'.
-- 
|¯ \/¯ | /¯\ /¯__/¯__|<|> *FAX/Mail Server  : 
+39 - 02700426582
 <|
|¯|\/|¯|/¯_¯\|(__\__ \<|> *Casella Vocale   : 
+39 - 0230312251
  <|
|_|  |_/_/ \_\___|___/<|> *FAQ ITGF 
http://plany.fasthosting.it
 <|
|>- RST - Plany/MACS -<|> *FAQ GCN  
http://faq.news.nic.it/
 ____<|


I server 26.x.x.x. sulla rete fastweb da quello che posso capire/dedurre
sono quelli che si occupano dell'autenticazione utente (radius) e
stabiliscono le modalità di accesso alla rete (consumo o flat). Molte volte
sono poco reattivi ai tracert presentando evidenti segni di sovraccarico.
Detto questo, preciso che sono supposizioni , non ho la certezza che siano
adibiti solo e a quello scopo, ma dovremmo esserci..
A quanto leggo in alcuni forum sono a volte resposabili delle performance di
latenza quando si fa net gaming .

Macs ha scritto:

intanto grazie a tutti!
ecco un esempio di mio tracert:
Rilevazione instradamento verso 
www.repubblica.it
 [213.92.16.171]
su un massimo di 30 punti di passaggio:
   1     8 ms     7 ms     7 ms  5.243.96.1
   2     7 ms     7 ms     7 ms  10.0.232.18
   3     7 ms     7 ms     7 ms  10.251.29.209
   4     8 ms     7 ms     7 ms  10.251.24.36
   5     7 ms     8 ms     7 ms  10.251.25.1
   6     7 ms     7 ms     7 ms  10.251.29.186
   7     7 ms     7 ms     6 ms  10.0.137.229
   8     8 ms     7 ms     7 ms  10.0.128.89
   9    11 ms    11 ms    11 ms  10.254.1.234
  10    11 ms    11 ms    11 ms  10.254.9.198
  11    12 ms    12 ms    11 ms  89.96.200.158
  12    42 ms    27 ms    27 ms  26.26.26.46
  13    27 ms    28 ms    28 ms  26.26.26.169
  14   141 ms   206 ms   212 ms  26.26.26.121
  15    27 ms    27 ms    27 ms  89.96.200.17
  16    26 ms    26 ms    27 ms  
ge4-1.wf1-gsr2.wf.inet.it
 [212.239.110.89]
  17    27 ms    33 ms    28 ms  
ge1-0-12.wf1-kwcore.wf.inet.it
 
[212.239.110.26]
  18    27 ms    26 ms    26 ms  
www.repubblica.it
 [213.92.16.171]
Rilevazione completata.

 stabiliscono le modalit di accesso alla rete (consumo o flat). 
Sì, ha senso demandare l'autorizzazione e l'autenticazione alla stessa 
entità.
Detto questo, se facessero *solo* questi compiti, non dovrebbero 
risultare da un traceroute. Il fatto che invece siano presenti dimostra 
che svolgono anche funzionalità di routing di pacchetti. E in questo 
caso, l'elevato sovraccarico può determinare un ritardo nella risposta e 
di conseguenza una latenza più elevata.
Non c'è nulla di strano: è un server sovraccarico che rallenta di qualche 
manciata di millisecondi (magari anche 20) la latenza. Succede nelle 
migliori reti, e nelle peggiori (come quella ATM di Telecom, solo che 
tramite traceroute non si ha visibilità ovviamente). Mi aspetto che tra 
qualche mese il problema sparirà.
-- 
Conte Frobenius