CiscoForums.it

Ciao a tutti.

Devo fare una cosa semplicissima, ma probabilmente anche un po' delicata e soprattutto non posso fare molte prove a ca##o perché si tratta di un apparato in produzione.

Il problema: due host che appartengono a due sottoreti molto lontane non si vedono. Siamo in due a doverci occupare di questo problema, uno (io) cura il routing di "andata", l'altro (un alterego di un'altra azienda) cura il percorso di "ritorno".
Ora io sono sicuro (o quasi ) di aver fatto tutte le cosette che andavano fatte, ma ne è sicuro anche lui. Per poter dimostrare che effettivamente uno dei due ha ragione dobbiamo fare un test molto molto semplice: dobbiamo metterci su questo Cisco 6509 e "vedere" se questo apparato riceve pacchetti da un particolare indirizzo su una particolare interfaccia. Secondo me non riceve nulla, perché il problema viene molto prima (io sospetto un ACL su un PIX, ma non è mio e non posso controllare), ma per averne la certezza ci serve questa prova del nove.

Mi sto avventurando nella doc del 6509 sulla parte debug, ma è pieno di alert, nel senso che abilitare l'auditing del debug potrebbe causare rallentamenti o fermi dell'apparato (non sia mai ).

Mi date una mano per questa operazione che dovrebbe essere piuttosto semplice?

Grazie

giaconet

puoi filtrare il debug con le acl e quindi non piantare il Cisco (fidati, il 99.9% delle volte, senza ACL, muore)! Oppure, ancora meglio, usa SPAN o RSPAN! (setta una interfaccia in promiscuo dove puoi connetterti con uno sniffer)

ciao!

ma se devi solo verificare che arrivino i pacchetti puio usare una ACL in permit con "log" alla fine per l'host da cui ti aspetti traffico seguito ovviamente da un permit any

E proprio questo che vorrei capire. Secondo me mi manca un passaggio

Allora la situazione è questa (un'immagine vale più di mille parole):


(in questo schema ci sono 3 aziende diverse)

Ora il 192.168.42.1 deve comunicare con il 10.10.250.30 (gli estremi del disegno).

Se dal 192.168.42.1 faccio un ping verso 10.10.250.30 il mio alterego mi comunica che sul Pix 10.10.60.1 vede il pacchetto arrivare. Il ping fallisce perché il pacchetto non torna: io dico che il problema è sul 2° Pix il 10.10.60.4, mentre lui dice che è sul 6509 (interfaccia 192.168.13.150)

Allora io mi metto sul mio 6500 e faccio Fin qui è ok?

Ora se faccio fare il ping dal 10.10.250.30 al 192.168.42.1, quale comando devo fare per visualizzare i pacchetti?

Grazie

giaconet

dovresti aggiungere anche una access-list 101 permit ip any any

Se sei in telnet dai #terminal monitor
i log dovrebbero arrivarti sul terminale in real time. Se non succede modifica il level con logging monitor. Se vuoi che restino in memoria dai logging buffered

Ma se dal PIX non arriva nulla... niente log

con span o debug filtrato con acl, non fai danni. Sicuramente avrai un log piu' "granulare" e dettagliato. IMHO.

Riassumendo, se quindi facessi: dovrei riuscire a vedere sul terminale se arriva qualche pacchetto verso 192.168.42.0/24?

No, perché io non vedo niente (ma non so se perché non arriva nulla o perché non sto monitorando un kaiser

Grazie

giaconet

no così schianti lo switch
togli l'ultima riga dall'access-list (non avevo capito cosa volevi fare) e per vedere il debugging dai "logging monitor debug"

mmmmhhhh io continuo a non vedere nulla...

Facciamo una cosa, semplifichiamo di molto il problema.

L'interface sicuramente più "sfottuta" di questo Catalyst 6509 è la int vlan 1.
Su questa vlan ci sono la maggiorparte degli host interni alla rete, tra cui anche la postazione dalla quale mi connetto al 6509.

La vlan 1 è 10.10.0.0/16
L'indirizzo dell'interface vlan 1 del 6509 è 10.10.0.101 (/16)
L'indirizzo della mia postazione è 10.10.13.191 (/16)

Immaginiamo di voler vedere il traffico generato dalla mia postazione. Qualunque cosa faccia sulla mia postazione verso il 10.10.0.101, non vedo nulla in terminal...

Sono io vero, ad essere completamente negato?

Grazie cmq

giaconet

e sì, in pratica non hai attivato il debug. Se fai "show debugging" vedi cosa è attivo.
Debug list da solo non basta, invece di complicarti la vita con debug list usa debug ip packet acl. Ma secondo me rischi di innondare la console di messaggi.
Dovresti anche verificare che il logging è abilitato con show logging. Di default è on ma non si sa mai.

blublublu ha scritto:e sì, in pratica non hai attivato il debug. Se fai "show debugging" vedi cosa è attivo.
Debug list da solo non basta, invece di complicarti la vita con debug list usa debug ip packet acl. Ma secondo me rischi di innondare la console di messaggi.
Dovresti anche verificare che il logging è abilitato con show logging. Di default è on ma non si sa mai.

Tutto ok!!!!
show logging mi dice che il logging è abilitato
debug ip packet 102 seguito da terminal monitor mi da i messaggi di log
Per uscire dalla modalità terminal monitor, basta dare un terminal no monitor e tutto si zittisce

Devo dire che anche con l'utilizzo di acl (vabbè la mia era cmq abbastanza "larga") i tempi di risposta dell'ssh si rallentano parecchio (ho subito dato un no debug list 101, no debug list 102 e no debug ip packet 102 ed è tutto tornato velocissimo ;-D), in ogni caso finalmente ho imparato quello che mi serviva.

Perfetto!!

GRAZIE MILLE!!!!!

giaconet

ottimo
per fermare tutti i debug è comodo "undebug all"