ARGOMENTO:

Salve,
ho problemi a fnire l'esercizio, ritengo di aver fatto bene ma non capisco perche' non funziona, qui lo show run con in grassetto le parti da me cofigurate:
R2#sh run
Building configuration...

Current configuration : 1431 bytes
!
version 12.3
no service timestamps log datetime msec
no service timestamps debug datetime msec
no service password-encryption
!
hostname R2
!
!
!
!
!
!
!
!
ip cef
no ipv6 cef
!
!
!
!
!
!
!
!
!
!
ip ssh version 1
!
!
spanning-tree mode pvst
!
!
!
!
!
!
interface FastEthernet0/0
ip address 192.168.20.1 255.255.255.0
ip nat inside
duplex auto
speed auto
!
interface FastEthernet0/1
no ip address
duplex auto
speed auto
shutdown
!
interface Serial0/0/0
ip address 10.1.1.2 255.255.255.252
ip nat inside
!
interface Serial0/0/1
ip address 10.2.2.1 255.255.255.252
ip nat inside
clock rate 64000
!
interface Serial0/1/0
ip address 209.165.200.225 255.255.255.224
ip nat outside
!
interface Serial0/1/1
no ip address
clock rate 2000000
shutdown
!
interface Vlan1
no ip address
shutdown
!
router rip
version 2
passive-interface Serial0/1/0
network 10.0.0.0
default-information originate
no auto-summary
!
ip nat pool R2POOL 209.165.202.128 209.165.202.129 netmask 255.255.255.254
ip nat inside source list R2NAT pool R2POOL overload
ip nat inside source static 192.168.20.254 209.165.200.130
ip classless
ip route 0.0.0.0 0.0.0.0 Serial0/1/0
!
ip flow-export version 9
!
!
ip access-list standard R2NAT
permit 192.168.10.0 0.0.0.255
permit 192.168.20.0 0.0.0.255
permit 192.168.30.0 0.0.0.255
!
banner motd ^CAUTHORIZED ACCESS ONLY!^C
!
!
!
!
line con 0
login
!
line aux 0
!
line vty 0 4
login
!
!
!
end
comunque dall'esercizio nase una considerazion che si collega all'altro topic e che a mio parere "collide" con alcune considerazioni che ha fatto Spaziani, e cioe' che l'associazione accoppiata acl-pool con le interfaccie avviene (se numerose le acl e le interfaccie) per match tra le cl e le reti sottese dalle interfaccie, ed in questo esempio cio' non e' vero difatti due interfaccie del router R2 hanno ip che con le reti sottese nelle acl non matcheno per nulla eppure evidentemente dovrebbe funzionare tutto perche' evidentemente il match avviene sugi indirizzi sorgenti presenti nei mesaggli "local", io dopo la spiegazione che gentilmente mi ha dato Spaziani ho iepilogato sbagliando e non mi e' stato detto nulla, adesso delle due una, quale?
Grazie anticipatamente delle risposte che mi saprete dare.

qui un chiarimento sull'ultima parte del precedente messaggio di questo topic, nell'altro topic leggo
che per togliere l'indeterminazione cusata dalla coesistenza di un numero maggiore di accoppiate acl<-bind->pool e quindi associarle alle giuste interfacie inside outside (che sono maggiori di due) allora il criterio pareva essere quello indicato nelle frasi che seguono:
"ip nat inside source ACL1 pool POOL1 overload (dove la ACL1 fa match solo del traffico della LAN1 e viene tradotto sul POOL1 )
ip nat inside source ACL2 pool POOL2 overload (dove la ACL2 fa match solo del traffico della LAN2 e viene tradotto sul POOL2 )" ma nell'esercizio col packet tracer su due interfaccie le acl configurate non fanno match con gli indirizzi lan sottesi e quindi non possono indicare una interfaccia, oppure (adesso che leggo con piu' attenzione) match COL TRAFFICO significa che comunque le acl sono attive su tutte le lan dfinite inside ed intercettano iltraffico secondo quanto determinato dalle acl, cioe' le acl applicate a tulle le interfaccie inside generano il flusso dati su cui opera il processo NAT.
Bene e' cosi,o mi sbaglio?

Quello che puoi fare, ed è ciò proposto nell'esercizio, è scrivere un'unica ACL.

In questo modo tutto il traffico che passa sulle interfacce inside viene confrontato con l'acl.
Il punto è che se scrivi una ACL sola, stai dicendo che tutto il traffico proveniente da tutte le lan verrà trattato con lo stesso POOL (che è il caso più tipico)

I miei esempi erano invece più sofisticati, e cioè decidere quale traffico viene tradotto su quale pool (o interfaccia), in questi casi hai bisogno di acl distinte.

Magari dimmi qual'è la frase di ricapitolo che ti è stata confermata e che non ti torna, questa è corretta "configurando due bind della stessa acl su due interfaccie differenti verra' comunque utilizzata come inside global sempre nell'ordine la prima configurata"

oops dove ho scritto cosi:"oppure (adesso che leggo con piu' attenzione) match COL TRAFFICO significa che comunque le acl sono attive su tutte le lan dfinite inside ed intercettano iltraffico secondo quanto determinato dalle acl, cioe' le acl applicate a tulle le interfaccie inside generano il flusso dati su cui opera il processo NAT.
Bene e' cosi,o mi sbaglio? "
intendevo invece scrivere:"oppure (adesso che leggo con piu' attenzione) match COL TRAFFICO significa che comunque le acl sono attive su tutte le interfacice configurate inside ed intercettano il traffico secondo quanto stabilito dlle acl e passano quanto permesso (permit) dalle acl al processo NAT nat senza che l'indirizzo configurato sulla interfaccie e la sotterete definita su di essa abbia nessuna influenza, in pratica ad ogni interfaccia definita inside si applicano tutte la acl e la prima configurata che matcha un permit fa si che il processo nat tratti il messaggio secondo le indicazioni restanti." questo un primo chiarimento che il mio messaggio precedente non evidenziava con chiarezza, questa considerazine viene dall'analisi del'esercizio.
Continuo in un messaggio che segue.

Io ho capito cio' che scrivero' (un giro in bici di questa mattina mi ha aiutato a cercare una sintesi) e cerchero' di ridurre generalizzando tutto il discorso in questi termini: le varie acl scritte vengono applicate a tutti i messaggi che fluicono entrando (incoming) nelle interfaccie definite inside, i messaggi che matchano almeno una acl vengono trattati cosi come definito negli altri parametri di configurazione (i.e. pool associato all'acl e overload eventuale).
questa in neretto e' la generalizzazione che dovrebbe completamente semplificare grande parte del discorso (spero almeno la parte a noi rivelata nel corso), per quanto ho letto io sulle acl e tutto cio' che ho studiato fino adesso va daccordo con questa generalizzazione che e' molto semplice (e' un mio parere), se c'e qualcosa a me sconosciuto che contrasta con quanto in neretto ti prego di dirmelo perche' io sto consolidando questa generalizzazione, e mi pare che ogni altra cosa sia un caso particolare di quanto esposto in neretto.
E' cosi?
p.s. io non faccio il bit a 4 ma cerco una logica semplice che definisca tutto il contesto, pero' per trovare la logica semplice succede di dover spaccare il bit in quattro ed anche in otto ,( e qui a seguire scherzo un po) del resto le tecniche di spread (viterbi) intese come sparpagliamento di un bit non su quatro o su otto ma su un numero anche maggiore e' la modalita' attraverso la quale operano le tecniche d trasmissione per irrobustire il protocollo a livello basso e quindi resistere agli errori.
Attendo chiarimenti anche n relazione all'esercizio, che e' la prima domanda nel primo messaggio.

roberto ulisse ha scritto: I<strong>le varie acl scritte vengono applicate a tutti i messaggi che fluicono entrando (incoming) nelle interfaccie definite inside, i messaggi che matchano almeno una acl vengono trattati cosi come definito negli altri parametri di configurazione (i.e. pool associato all'acl e overload eventuale).</strong>

Perfetto, aggiungo anche se abbastanza scontato, che il traffico che non matcha queste acl non viene scartato, semplicemente non viene trattato dal processo NAT.

Come dissi anche a lezione, le ACL selezionanto traffico, questo traffico può essere filtrato se utilizziamo le ACL con ip access-group, può essere nattato e tanto altro ancora.

Riguardo il PT, mi sai dire esattamente cosa non funziona?

nell'esrcizio sono richieste queste verifiche:
Step 1: Access services across the Internet.

a. From the web browser of PC1, or PC3, access the web page for cisco.pka.

b. From the web browser for PC4, access the web page for local.pka.
e non si riesce a vedere le agine web, poi se vedo il check results mi da errore sul pool name, ma a me pare corretto, e poi mi da errore sul' inside source static ed a me pare cio' che vedo scritto e che sta nelloshow run cioe:ip nat inside source static 192.168.20.254 209.165.200.130 .....
Ho capito, avevo interpretato male le indicazioni e cioe' la frase: "Configure R2 with a NAT pool named R2POOL that uses the first address in the 209.165.202.128/30 address space. The second address is used for static NAT later in Part 2." io l'ho interpretata nel senso di dividere in due lo spazio /30 invece diceva solu il .128 sul pat e solo il .129 sul nat statico, comunque questo errore non avrebbe dovuto implicare malfunzionamenti e tutto (anche se diversamente da come indicato e richiesto)e quindi i test sarebbero dovuti andare a termine, questo non me lo spiego, non riesco a capire.

Chiuso un fronte (quello sulle inside) se ne apre un'altro (sulle outside) e cioe' nel caso che le interfaccie configurate come outside siano piu' di una e quindi su come, una volta' matchata l'acl, e quindi individuato il pool si individui l'interfaccia di uscita dalla quale inviare il messaggio opportunamente modificato. Certo e' che se il bind viene definito attraverso l'esplicita indicazione dell'interfaccia allora non c'e' problema ma se il bind punta ad un pool che ha indirizzi ip completamente scollegati e non correlati alle sottoreti sottese dalle interfaccie outside non riesco a capire quale possa essere la via attraverso la quale il processo nat possa decidere su quale interfaccia outside forwardare il messaggio.
Altro problema ancora piu' grosso che ritengo, allo stato attuale, non definito e questo: per quanto concerne la pubblicita' che eventuali protocolli di routing fanno delle network raggiungibili e che consentono, come sappiamo, alla rete di sapere che certi indirizzi sono raggiungibili attraverso il router in questione, e quindi nel caso che il inside global scelto per il nat o pat non sia tra quelli pubblicizzati intercettati dal comando network, come fa il processo di routing a sapere di dover pubblicizzare tale destinazione?

Se ho ben capito l'esercizio PT sei riuscito a trovare l'errore.

Per le altre tue domande, il router capisce dove inoltrare il traffico guardando la tabella di routing.
Quindi la cosa funziona in questo modo,
ip nat inside source ACL pool MY_POOL dice che certo traffico viene tradotto in un certo modo
ip nat inside e ip nat outside ti danno la direzione della traduzione
il routing decide su quale interfaccia viene inoltrato il pacchetto.

In un mio precedente post dicevo proprio questo, con questa tecnica di nat non puoi assegnare pool differenti a interfacce differenti, un certo tipo di traffico (ACL) viene tradotto sempre allo stesso modo a prescindere dall'interfaccia di uscita, a meno di nat overload

Comunque fammi fare una considerazione, se come dovrebbe l'obiettivo del corso è anche la certificazione CCNA, direi che sul nat sei ad un livello molto più alto di quanto richiesto, ti consiglio di passare alla preparazione dell'esame di certificazione CCENT. Una volta passato, tornerai sugli argomenti che vuoi approfondire, ma intanto porti a casa un risultato che magari può esserti utile.

Forse potresti procedere allo stesso modo per gli argomenti della CCNA4 e CCNA5 allo scopo di certificarsi in breve tempo, ad approfondire si fa sempre in tempo.

L'esercizio melo ero dimenticaato completamente, adesso provo a riguardarlo cosi vedo se riesco a capire il problema, per quanto concerne le considerazioni sul fatto che sto andando un po troppo in profondita' concordo e ritengo meglio dediacarmi ad ottenere risultati "tangibili" prendendo spero una certificazione perche' ho seria esigenza di averla, ma sai come succede non riuscivo piu a mollare ed una cosa tira l'altra e cosi non si finice piu' di dover definie le cose, comunque penso di avere meglio definito le cose grazie sopratutto all'iterazione con voi istruttori, ed ho ottenuto una parte del mio obiettivo che e' avere una visione piu chiara e coerente delle questioni.
Io comunque per il discorso di pubblicizzare un'indirizzo (o un pool) associato col nat di una inside global che non e' compresa nelle network normalmente dichiarate ritengo, e cosi farei in condizioni reali, che questo indirizo o pool debba essere configurato col comando network in modo che il processo di routing possa far conoscere al resto della rete la raggiungibilita' di quegli indirizzi attraverso il router stesso, dimmi se e' esatta questa ultima considerazione.
Grazie delle rispote che mi hai saputo dare.

figurati
Scusa avevo dimenticato di risponderti a questo.

La cosa che dici relativamente al comando network è logica, ma non funziona così, esiste un'altro modo per iniettare il pool nel protocollo, sostanzialmente scrivi una statica fittizia e poi la inietti nel protocollo.

Per la certifica sono certo che tu sia molto molto vicino

Spaziani,
su quest'ultima cosa forse e' meglio se mi fai un'esempio, non ho capito il metodo.

Per una serie di problemi ultimamente non mi sono potuto dedicare allo studio e rileggendo e rifettendo su quento discusso fin'ora ho notato delle cose in parte sbagliate e/o poco precise, per esempio dove ho scritto:" le varie acl scritte vengono applicate a tutti i messaggi che fluicono entrando (incoming) nelle interfaccie definite inside, i messaggi che matchano almeno una acl vengono trattati cosi come definito negli altri parametri di configurazione (i.e. pool associato all'acl e overload eventuale). " invece avrei dovuto scrivere: " le varie acl scritte vengono applicate a tutti i messaggi che VENGONO RUOTATI DAL PROCESSO DI SWITCHING VERSO LE INTERFACCIE DEFINITE DI OUTSIDE E CHE ENTRANO DALLE INTERFACCIE DEFINITE INSIDE, QUINDI i messaggi COSI INDIVIDUATI VENGONO SOTTOPOSTI AL PRCESSO DI "NATTING" cosi come definito negli altri parametri di configurazione (i.e. pool associato all'acl e overload eventuale)." cioe' fondametalmente andava aggiunta la condizione riguardante il ransito del messaggio sulla interfacia di outside, mi confermate quento da me ipotizzato?
C'e' un'altra importantissima questione connessa all'interazione tra acl e nat che postero' in un nuovo topic in questa stessa sezione dedicata al nat. (interazione tra acl e nat chi prima e chi dopo, e come?)

Vero, tra due interfacce inside non si innesca il nat, così come tra due interfacce outside, o tra interfacce inside e senza configurazione nat o tra interfacce outside e senza configurazione nat. Più dettagli su questo nella risposta al secondo post che hai inserito.

Riguardo alle soluzioni per iniettare il pool nel protocollo di routing mi è difficile andare nel dettaglio perchè di solito si utilizza il BGP che è fuori dagli argomenti trattati nel corso.

Però se vuoi qui c'è un post molto utile su Cisco dove la cosa viene spiegata abbastanza bene
learningnetwork.cisco.com/thread/13828