Si è parlato, in precedenza, dei comandi che ci facilitano le fasi di toubleshooting; tra questi si annovera debug. Il comando fornisce un flusso di informazioni su traffico passante in un'interfaccia, su messaggi di errore generati da un nodo di rete, su diagnosi specifica di un protocollo di rete e molto altro relativo a dati real-time. Un esempio potrebbe essere vedere il flusso di pacchetti e come questi vengono instradati con il CEF ( Cisco Express Forwarding ).
Si raccomanda l'uso di debug esclusivamente per isolare i problemi, e mai per monitorare la rete o le operazioni dell'apparato; questo perchè il comando potrebbe utilizzare molta potenza di calcolo della CPU. Indichiamo si seguito cosa tenere in mente quando si usa debug:
- il comando può generare un'enorme mole di dati che risulterebbe inutile per problemi specifici;
- può generare un grande overhead della CPU risultando in cattive operazioni di rete, pertanto va utilizzato per traffico specifico e problemi ben definiti
- l'output generato varia in base ai protocolli;
- ogni comando debug è diverso dall'altro nella quantità di dati e nella forma dell'output;
- il comando può ottenere informazioni sullo stato di rete ed apparati

Esempio: comprendere come vengono traslati gli IP su NAT


Per far terminare un debug si può utilizzare la classica negazione no. Dall'esempio precedente avremmo no debug ip nat. Oppure si può usare undebug che con l'opzione all disabilita tutti i debug attivi ( undebug all ); conseguentemente debug all abilita tutti i debug...mi raccomando mai attivarlo, potrebbe portare ad un crash del sistema.

_________________
Una volta deciso che la cosa può e deve essere fatta, bisogna solo trovare il modo.
Abraham Lincoln
il Webmaster di NetworkAdministrator.it ringrazia tutta la community