Newsgroup: it.comp.reti.cisco
Titolo: applicativi in timeout su  vpn lan to lan con adsl

Ciao a tutti.
forse e' un po' OT ma sono nella m***
ho un problema con una VPN lan to lan:
ci sono due sedi distinte collegate ad internet tramite adsl di T.I.
Entrambe le sedi montano dei cisco
1701 con adsl e isdn, IOS ha capacita' di FW/VPN. Ho configurato la vpn
lan-to-lan con la adsl e tutto 
sembrava funzionare (i ping passano e dalle macchina della lanA pingo
quelle della lanB e viceversa).
Ora si e' passati a fare dei test un po' piu' seri e sono arrivate le
brutte sorprese: usando 2 macchine windows
non si riesce a fare terminal server da una verso l'altra, la finestra di
connessione sta un po' li' e poi va in timeout.
Ho provato anche a visitare un sito web interno alla lanB (la GUI di
gestione dell'antivirus)con il browser da una macchina
della lanA e la connessione anche qui va in time out dovo aver presentato
a lungo la finestra del browser vuota.
Poiche' i ping passano e non ci sono access list applicate alle
interfaccie, io tenderei ad escludere un errore sulla config 
della vpn, pero' vi chiederei se c'e' quelcuno disposto a dare un occhiata
veloce alle configurazioni dei due router.
Inoltre vi chiedo un parere sulla diagnosi: la navigazione in Internet
funziona ed e' abbastanza veloce quindi io credo che il 
problema sia dovuto al fatto che nel lan-to-lan entra ovviamente in gioco
l'asimmentricita' della adsl e quindi la macchina 
che viene chiamata si ritrova a fare un upload verso internet per parlare
con il chiamante, se la banda in upload fosse poca 
(queste adsl hanno avuto parecchi problemi da quando sono state
installate) potrebbe capitare che sia proprio l'applicativo 
del chiamante (nel caso delle mie due prove il browser o il client del
terminal server) ad andare in timeout? 
Potrebbe essere corretta questa diagnosi secondo voi? 
grazie in anticipo
bebe 
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


Potrebbe essere un problema di upload, ma faccio il tifo x un problema di
mtu.
Ciao,
        Tosh.

         Tosh.
Potresti dettagliarmi meglio la tua ipotesi, per favore?
So che cos'e' l'MTU ma non ho mai affrontato problei del genere fino ad
ora.
Le macchina, sia in una lan che nell'altra sono tutte windows, varie
versioni, sia client che server.
Come posso risolvere/diagnosticare?
grazie


         Tosh.
Potresti dettagliarmi meglio la tua ipotesi, per favore?
So che cos'e' l'MTU ma non ho mai affrontato problei del genere fino ad
ora.
Le macchina, sia in una lan che nell'altra sono tutte windows, varie
versioni, sia client che server.
Come posso risolvere/diagnosticare?
grazie



Non per scortesia, ma questo argomento è stato trattato diverse altre volte
su questo ng, se fai qualche ricerca sull'archivio, magari integrandola con
ricerche su google e su cisco, trovi tutte le risposte che cerchi.
Ciao,
        Tosh.

 forse e' un po' OT ma sono nella m***
prima di passare a problemi piu'  seri (vedi MTU....), proverei ad 
escludere le banalita' che a volte sfuggono....
le prove le hai effettuate con IP non con i nomi vero (DNS...).
i ping che tu hai utilizzato per effettuare le prove tu dici che 
"funzionano".
ma hai verificato i tempi di risposta  ed eventuali packet loss ?

Allora...
Ho letto di ipotesi "serie"... come la variazione dell'MTU.
Io tralascerei.
Solitamente sono casi rari, e quando capita sono "volatili per diabetici".
Io rivolgerei l'attenzione più su problemi "semplici" (come suggerisce
qualcuno).
E' probabilissimo che la banda in upload sia scarsa, per esempio.
Prima cosa da fare... è effettuare i test quando le due LAN sono "idle",
magari dopo l'orario di lavoro.
In questo modo sai che hai tutta la banda a disposizione.
Da un PC-A fai un ping su un PC-B... funziona
Fai la stessa cosa usando il NOME di PC-B... funziona
Fai un telnet da un PC-A su un Web server "B" sulla porta 80... funziona
Fai la stessa cosa usando il NOME del web server... funziona
A questo punto apri il browser e apri una pagina sullo stesso WEB server...
NON funziona.
Che fare?
Se ti trovi in questa situazione, la prima cosa che farei è controllare la
configurazione del browser.
Se "telnet su 80" funzia e "Internet Explorer" no, vuol dire che al 90% il
difetto sta nella configurazione del browser
Magari vedi se è impostato per usare un proxy aziendale.
Se la conf del browser ti sembra a posto... e sui router non ci sono ACL
"gruppate" sulle interfacce... allora controlla la "route-map".
Se non hai altri "peer" oltre a quello a cui accenni, ti suggerisco una cosa
del tipo (sul router "A"):
!
access-list 101 deny ip subnetA wildcardA subnetB wildcardB
access-list 101 permit ip any any
!
Quella di router "B" ovviamente avrà la prima riga "invertita" (src e dest).
Una cosa importante: NON USARE le "NAMED" ACL!
Usa solo le "numbered".
Ci siamo stati dietro una settimana (sempre router-to-router IPsec tunnel)
senza capire perchè non funzionasse... incredibilmente dipende da un difetto
di gestione delle "named".
Prova un po...
Ciao,
JO
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Solitamente sono casi rari, e quando capita sono "volatili per diabetici".
Rispetto le idee di chiunque, anche se le mie esperienze mi suggeriscono
altre casistiche, quello che mi incuriosisce è il significato della tua
frase tra apici, dal momento che è la prima volta che la sento.
Ciao,
        Tosh.



letteralmente "ca**i amari "  dove * e' una qualsiasi ultima lettera
dell'alfabeto ;)
ps...  tifo pure il per l'mtu...  ho avuto un problema del genere in
un tunnel messo su pochi giorni fa...  cambiato l'mtu del  int  tunnel
e tutto si e' risolto...

 mtu.
sottoscrivo..alla M$ il flag DF sembra fosse un must e il PMTUD un
dogma..bah..cmq verifica che il PMTUD funzioni end-to-end se come dici non
filtri nessun icmp e che le crypto acl siano ok.. prova un debug icmp e a
pingare end-to-end con DF settato e size a scalare da 1500 (def. per winzoz
troppo per pppoe f.e. =)
potresti anche fissare statica l'mtu lato server(s) specie se il router
mostra un certo carico dovuto alla reassembling.. o meglio usare la
preframmentazione come da art. seguente
http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_gui
de09186a0080115533.html
vedi un po' te'.. cmq non ho capito se stai usando il TS per scopi
amministrativi o applicativi se e' la seconda fai bene i tuoi conti perche'
se non ricordo male (il che e' sicuro c'ho una memoria alla "Memento") RDP
si mangia un 25k nella versione piu' efficente 5.x (Winzoz2003) e con una
ADSL senza un minimo di banda garantita..ummm qualcuno ha gia postato
qualcosa sui volatili...
bye

 dell'alfabeto ;)
In fondo era facile, solo un tonto come me non ci sarebbe arrivato.
Tnx,
       Tosh.

Tosh ha scritto:
allora, riporto la situazione attuale sperando che qualcuno voglia darmi
una mano:
ho fatto un po' di compiti a casa, ovvero mi sono studiato il problema
dell'MTu eho guardato come funziona l'MTU discovery. Ho abilitato gli icmp
unreacheble su tutte le interfaccie dei router coinvolti (lo erano gia'
tranne su una)e ho questa situazione
usando ping -l xxx (dove xxx e' il carico del ping a cui vanno aggiunti
gli 8 byte dell'header icmp e i 20 byte di IP) da una macchina su una lan
verso una macchina dell'altra lan succede che
se xxx<= (minore o uguale) 1398 i pkt passano senza essere frammentati
(infatti passano anche se ho df=1)
se 1398 < xxx < 1410 i pkt passano ma sono frammentati (infatti se metto
df=1 mi torna indietro l'icmp dal primo router che mi dice che la MTU
nuova e' 1426 e il router logga un mess dove dice che doveva framm ma non
ha potuto)
ora la cosa che non capisco
se xxx < 1410 i pkt non passano in nessun caso (ne' con df=0 ne' con df=1)
e il router non torna indietro niente e non logga niente.
quest' ultima cosa non mi torna; nel frattempo terminal server countinua
ad andare in timeout, notare che prima (collegando le due lan direttam tra
loro attraverso una chiamata isdn tutto funzionava e ritornando ad usare
l'isdn tutto torna a funzionare, quindi escluderei probl sulla macchina
collegati ai livelli applicativi). Semmai penserei a probl di MTU, come ha
detto Tosh, ma nn mi spiego la situaz che ho descritto sopra.qualcuno ha
qualche idea e ha voglia d darmi una dritta??
grazie in anticipo


 e il router non torna indietro niente e non logga niente.
ovviamnte ho sbagliato a scrivere, quest'ultima situaz (quella chenn mi e'
chiara) si verifica quando  xxx > 1410.
quindi con ping -l 1411 (ad esempio) i pkt non passano ne' con df=1 ne'
con df=0 e il router non torna niente e non logga niente.
Questo problema si ha indipendentemente dalla macchina che io pingo.


 dell'MTu eho guardato come funziona l'MTU >discovery.............
Devi tenere conto del fatto i tuoi dati "tunnellati" attraversano diversi
router durante il percorso, ciascuno potrebbe avere una mtu diversa
dall'altro e ancora peggio potrebbe essercene uno che non invia indietro i
pacchetti icmp per segnalare la necessità della frammentazione o potrebbe
addirittura bloccare quelli generati dai router a monte; questo spiega
perchè ti ritrovi un comportamento apparentemente bizzarro (in realtà è solo
frutto di mala gestione) e perchè l'mtu discovery potrebbe non funzionare
bene.
Questo documento cisco spiega il problema e come risolverlo.
http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml
Ciao,
        Tosh.

 In fondo era facile, solo un tonto come me non ci sarebbe arrivato.
puro, si dice puro.
un mayhem ed il lato positivo
-- 
 Lo scetticismo e' l'inizio della fede. OW 
 Cisco  FAQ: 
http://mayhem.oltrelinux.com/icrc
 SPP  wpage: 
http://www.spippolatori.org
 Key on 
pgp.mit.edu
 ID B88FE057

         Tosh.
Grazie per la risposta:
il problema e' un problema di MTU, probabilmente collegato a win
2000server sp3. 
Sono abb sicuro che dipenda dal sistema operativo poiche' ho scoperto ieri
sera che tra due macchine XP una in lanA e l' altra in lanB il problema
non si pone (si sfogliano le directory da una macchina all'altra), ma sui
server non ci si collegava (stessa situaz dei post precedenti)e si e'
risolto (per ora) diminuendo a mano l'MTU nel registry dei server.
Ovviamente fatto cio' tutto ha funzionato perfettamente, quindi la tua
diagnosi era esatta, complimenti :-))
Ora mi sto studiando il doc che mi ha isegnalato in modo da capire bene le
soluz proposte da cisco e poter implementare una soluz piu' "pulita" senza
bisogna di intervenire sul registry delle macchine.
Mi succede pero' un altra cosa strana: facendo delle prove per assicurarmi
che i router sotto il mio controllo inviino i pkt icmp per la pmtud ho
diminuito l'mtu della ethernet del router con ip mtu 1300, dopodiche'
pingo il router da una macchina sulla sua stessa lan con ping -l 1400 -f
ip_del_router, il ping ovviamente va a vuoto (non c'e' risposta) ma
abilitando debug ip icmp e vedendo il buffer il router dice di aver
inviato gli icmp echo reply!! ho ripetuto la prova catturando dalla lan
con ethereal e ovviamente le risposte ai ping non ci sono ma il router, a
quanto sembra, "crede" di averle inviate. Magari la questione e' banale ma
tu hai mai visto un comportamento cosi'? Sai per caso da cosa dipende?
grazie bebe


> diminuito l'mtu della ethernet del router con ip mtu 1300, >
Non devi diminuire la mtu della ethernet, in questo modo dici al router di
non trasmettere pacchetti più grandi di 1300 bytes, cosa che non ha senso
dal momento che hai una ethernet da 1500 bytes, ma non influisci minimamente
sul comportamento dei client.
Se proprio non resisti a "truccare" una mtu rivolgiti alla interfaccia wan,
ma il comando più corretto è un'altro ..... nella doc che ti ho indicato
trovi tutto quello che ti serve.
Un Tosh che gioca al cane e al gatto (scusa mayehm se per una volta ti rubo
le citazioni).

 le citazioni).
mi scuso anche io e mi aggrego: un bebe che ha la casa circondata da gatti
perche' la sua gatta fa...la gatta morta. 



Immagino che il processo icmp che stai loggando spedisca veramente il
pacchetto indietro, che perņ viene bloccato dalla interfaccia alla quale hai
detto di non far uscire pacchetti superiori a 1300 bytes.
E' solo uno dei danni di quel comando.
Ciao,
        Tosh.

         Tosh.
ok, ricevuto. Non lo faccio piu' :-))
Ho finito il paper che mi hai detto. Se il 1701, con l'ios che ho,
supporta la pre-frammentazione IPSec andro' con quella, altrimenti usero'
una delle tecniche illustrate nel doc che mi hai segnalato.
1000 grazie per tutto l'aiuto. ciao
bebe


 una delle tecniche illustrate nel doc che mi hai segnalato.
io di solito uso la route-map che setta DF a 0 e non ho mai avuto sorta di
problema.
un mayhem e la tosse



Perchč vuoi far lavorare il router per niente?
Se usi "ip tcp adjust-mss xxxx" indichi al router di limitarsi ad "invitare"
i client a non inviare segmenti tcp maggiori di xxxx , cosě nessuno deve
fare lavoro inutile.
Se non dovesse funzionare perchč hai dei pc cocciuti allora puoi passare ad
altre tecniche piů invasive.
Ciao,
        Tosh.