Newsgroup: it.comp.reti.cisco
Titolo: Problema di routing

ciao,
sono hunter e da poco lavoro nel settore networking. Sto ancora studiando e
facendo un pò di esperienza pratica sul lavoro e per curiosità sto cercando
di aiutare un amico che ha dei problemi all'interno della sua rete.
Purtroppo però non riesco a trovare ancora una soluzione e riesco a capire
cosa può ancora mancare.
Provo ad esporre la sua architettura di rete sperando di fornire
informazioni corrette (uso degli IP inventati).
Dunque la sua Lan con IP privato 192.168.0.0 255.255.255.0 fa un NAT con
l'IP 
165.10.5.187/28
 fornitogli dalla Sede centrale per permettergli di
accedere ad un Server con un'applicazione centralizzata attraverso questa
rete.
In questa Lan c'è una macchina con due schede di rete una con IP
192.168.0.10 e l'altro con IP 172.16.0.2, in questo modo la classe
192.168.0.10 può navigare su internet passando da questa scheda  di rete
fino ad arrivare al router adsl la cui Eth.
appartiene a questa classe, instradandola sul collegamento di un altro
provider Italiano.
Allo stesso tempo attraverso la classe 172.16.0.2 la sua LAN usa questo
Proxy per arrivare al server centralizzato e con IP 165.10.25.133 passando
attraverso un altro router, ovvero un 1720 situato sempre nel suo ufficio di
Roma e gestito dalla Sede Centrale (chiuso quindi a ns. interventi) con e
con IP 172.16.0.1
Ora al posto del proxy e del precedente router hanno acquistato un 827
configurando la sua Eth. con i due IP:
192.168.0.10 secondary (verso LAN)
172.16.0.2 (verso 1720 in sede)
In questo modo 827 pinga 172.16.0.2 e nella sua tabella di ARP vede entrambi
i segmenti di rete pingando tutti gli host.
Se però da qui prova a pingare l'host finale 165.10.25.133 non ci riesce.
Così gli ho suggerito di configurare la seguente route:
ip route 165.10.25.133 255.255.255.255 172.16.0.1
pensando che in questo modo 827 capisse che x raggiungere quell'host deve
usare il 1720 appunto.
Il risultato però non è positivo perchè ancora non è raggiungibile ed allora
gli ho fatto inserire altre due route:
ip route 165.10.100.71 255.255.255.255 172.16.0.1
ip route 165.10.100.66 255.255.255.255 172.16.0.1
che dal suo schema risultano essere due punti di attraversamento prima di un
FW dietro al quale c'è questo benedetto host finale.
Fatto questo il ping ci da "U.U.U.U" perciò ho pensato che ci fosse una
chiusura ICMP verso di loro ma di fatto neanche stavolta l'ho azzeccata.
potete indicarmi una valida soluzione per far sì che il mio amico non sia
costretto ad usare il Proxy con doppia Ethernet e possa invece usare l'827
come nelle sue intenzioni??
Se avete delle domande da fare su qualcosa che potrei aver omesso vedrò di
farmi dare dettagli.
vi ringrazio in anticipo e saluti
Hunter

 wrote in message
news:asq3hr$5d24$1...@stargate1.inet.it...


ciao,
dunque provo a rispiegare da capo forse č meglio, o almeno spero:
1) esiste una sola lan fisica ( unico dominio di broadcast) su cui i pc sono
configurati  con 192.168.0.0, questi client convogliano verso un HUB che li
collega ad 827 (con Ethernet 10 e atm)
2) cisco 827 ha Ethernet con due IP differenti 192.168.0.x che gli permette
di collegare a internet con questo indirizzo ( che fa NAT) tutti i client di
questa rete;  e l'altro IP 172.16.0.2 (che non fa nat) che lo collega al
1720 perchč dovrebbe indirizzare sempre gli stessi client (192.168.0.0)
verso perň l'host remoto 165.10.25.133. Queste almeno le ns. intenzioni.
3) cisco 1720 ha FastEth. 10/10 con IP 172.16.0.1 che lo mette in
comunicazione con 827H (direttamente connesso ad una delle porte hub di 827
stesso) ed il resto della conf. non lo sappiamo ma cmq punta verso
quell'host remoto 165.10.25.133.
Ora dopo aver sentito i tecnici che gestiscono il 1720, questi hanno fatto
delle modifiche alla NAT di questo router e quindi 827 e 1720 si pingano
reciprocamente. Inoltre se provo a fare una sessione telnet all'ip
165.10.25.133 sulla porta 80 vado a segno e la sessione risulta OPEN con i
vari msg http. Quindi 827 ora raggiunge l'host remoto con successo perciň
conosce la strada giusta.
Purtroppo perň il problema non č finito.
Se dai client 192.168.0.0 col browser provo a puntare verso 165.10.25.133,
l'indirizzo non č raggiungibile forse perchč 827 non sa che le richieste
fatte da questa LAN che puntano verso quell'host devono prima passare per
l'IP 172.16.0.2 della sua Ethernet per buttarlo sul 1720 e quindi passando
per IP 172.16.0.1
Avevo per questo messo la route che dicevo:
ip route 165.10.25.133 255.255.255.255 172.16.0.1
perchč credevo in questo modo che fosse comprensibile a 827 che tutte le
richieste che dalla lan 192.168.0.0 vanno verso 165.10.25.133 devono per
forza attraversare quel piccolo segmento di rete in classe 172.16.0.0 /30
che unisce appunto 827 e 1720.
Ma la cosa non funziona. Possibile che si possa usare solo un proxy per fare
quel che ci serve oppure c'č una maniera di agire (sui singoli client e/o
827) per risolvere allo stesso modo???
sto perdendo la speranza.........spero almeno di aver fatto maggior
chiarezza
grz hunter

 quel che ci serve oppure c'è una maniera di agire (sui singoli client e/o


Mi sorge una domanda, forse non sarebbe meglio evitare il fai da te e
chiamare qualcuno?
Secondo me, essere un buon tecnico, vuol dire anche riconoscere i propri
limiti e mettersi
da parte quando non si è all'altezza, cosa che faccio anche io, visto che
sono agli inizi.
Ciao
Roberto

 wrote in message
at48p2$104uq5$1...@ID-113949.news.dfncis.de...


 wrote in
news:at72fh$5hsm$
1...@stargate1.inet.it
: 

fai controllare sul 1720 che non ci sia qualche access-list che ti blocca
facci sapere
hanniball

 wrote in message
news:at2aaj$5u9s$1...@stargate1.inet.it...


ciao,
pare che tutto si sia finalmente risolto.
Le persone che hanno in gestione il 1720 e quindi il server remoto, hanno
detto che sul loro router mancavano le traslation di ritorno nella NAT e
quindi quando ricevevano delle richieste da parte del router 827 non
riuscivano a rimandargli il pacchetto di ritorno.
Io non ho ben capito la spiegazione però, e stavo pensando così:
anche questo 1720 ha configurato NAT e quindi deduco che se riceve richieste
lato ns. sul suo IP privato, le fa uscire poi verso un IP pubblico (forse
staticamente) buttandole al server remoto.
Quindi avrà un "ip nat inside" sulla Eth. ed immagino un "ip nat outside"
sulla ATM.
Viceversa quando il server remoto manda le sue risposte indietro, l'IP
pubblico del 1720 le deve rigirare sull'IP privato (di classe 172.x.x.x) per
farle arrivare ad 827 e soprattutto ai suoi client. Ma se la nat è
configurato come dicevo sopra cosa vuol dire che le traslation non erano
corrette???
hunter


 wrote in message
news:at7sq2$35u4$1...@stargate1.inet.it...
