Informazioni importanti sui comandi di debug
Sommario
Introduzione
In questo documento vengono descritte le linee guida generali per l'uso dei comandi di debug, tra cui il comando debug ip packet disponibile sulle piattaforme Cisco IOS®.
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza dei seguenti argomenti:
-
Collegamento al router tramite le porte console, aux e vty.
-
Problemi generali di configurazione di Cisco IOS.
-
Interpretazione degli output di debug di Cisco IOS.
Componenti usati
Il documento può essere consultato per tutte le versioni software o hardware.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Premesse
Questo documento offre linee guida generali per l'uso dei comandi di debug sulle piattaforme Cisco IOS®. Sono inoltre inclusi esempi e una panoramica del debug condizionale.
I comandi debug in modalità di esecuzione privilegiata forniscono informazioni diagnostiche sugli eventi di rete, lo stato del protocollo, l'elaborazione dei pacchetti e l'attività generale della rete. Questi comandi consentono di identificare la causa di problemi specifici durante la risoluzione dei problemi.
Tuttavia, i comandi debug possono generare una grande quantità di informazioni di output e influire sulle prestazioni del dispositivo, in particolare sui router che stanno già gestendo un traffico elevato o un elevato utilizzo della CPU. Per questo motivo, eseguire i comandi di debug con attenzione e solo quando necessario per la risoluzione dei problemi.
Nota: In questo documento non viene spiegato come usare o interpretare comandi di debug specifici e il relativo output. Per i dettagli sui singoli comandi di debug, consultare la documentazione di riferimento dei comandi di debug di Cisco.
Avvisi
Eseguire i comandi debug con cautela. In generale, utilizzare questi comandi solo sotto la direzione del rappresentante del supporto tecnico per la risoluzione di problemi specifici.
L'attivazione del debug può interrompere il funzionamento del router, in particolare quando la rete è sottoposta a un carico di lavoro elevato. Se la registrazione è attivata, il server di accesso può bloccarsi in modo intermittente quando la porta della console è sovraccarica di messaggi di registro.
Prima di eseguire un comando di debug, considerare la quantità di output che il comando può generare e la durata della sessione di debug che può essere eseguita.
Ad esempio, su un router con una Basic Rate Interface, è improbabile che il debug isdn q931 influisca sul sistema. Tuttavia, l'esecuzione dello stesso comando debug su un AS5800 con una configurazione E1 completa può generare un output sufficiente per bloccare o arrestare il dispositivo.
Prima di eseguire il debug, controllare il carico della CPU eseguendo il comando show processes cpu. Verificare che la capacità della CPU sia sufficiente prima di attivare il debug.
Ad esempio, se un router Cisco 7200 con interfaccia ATM sta eseguendo il bridging, il riavvio del router può richiedere molte risorse CPU, a seconda del numero di sottointerfacce configurate. Per ogni circuito virtuale (VC), deve essere generato un pacchetto BDPU (Bridge Protocol Data Unit). L'attivazione del debug durante questo periodo critico può causare un aumento significativo dell'utilizzo della CPU, con conseguente blocco del dispositivo o perdita della connettività di rete.
Nota: quando i debug sono in esecuzione, in genere il prompt del router non viene visualizzato, in particolare quando il debug richiede molte risorse. Tuttavia, nella maggior parte dei casi, è possibile eseguire il comando no debug all o undebug all per interrompere i debug.
Prima del debug
Oltre ai punti citati in precedenza, accertarsi di comprendere l'impatto dei debug sulla stabilità della piattaforma. Inoltre, occorre considerare quale interfaccia sul router si deve connettere prima di abilitare qualsiasi comando di debug.
Recupero degli output di debug
I router possono visualizzare gli output di debug su diverse interfacce, incluse le porte console, aux e vty. I router possono inoltre registrare i messaggi in un buffer interno in un server unix syslog esterno.
Porta della console
Se si è connessi alla console in configurazioni normali, non è necessario eseguire altre operazioni. L'output del comando debug deve essere visualizzato automaticamente. Verificare tuttavia che il livello della console di registrazione sia impostato come desiderato e che la registrazione non sia stata disabilitata con il comando no logging.
Avviso: Un numero eccessivo di debug sulla porta console di un router può bloccarlo. Infatti, il router assegna automaticamente la priorità all'output della console rispetto alle altre funzioni del router. Se il router sta elaborando un output di debug di grandi dimensioni sulla porta della console, può bloccarsi. Se l'output del debug è eccessivo, usare le porte vty (telnet) o i buffer di registro per ottenere i debug.
Nota: Per impostazione predefinita, la registrazione è abilitata sulla porta della console. La porta della console elabora sempre l'output del debug anche se si utilizza un'altra porta o metodo (ad esempio aux, vty o buffer) per acquisire l'output. In condizioni operative normali, Cisco consiglia di eseguire il comando della console no logging, che è sempre abilitato e di utilizzare altri metodi per acquisire i debug. Nei casi in cui è necessario utilizzare la console, riaccenderla temporaneamente.
Porta ausiliaria
Se si è connessi tramite una porta ausiliaria, eseguire il comando terminal monitor. Verificare inoltre che il comando no login non sia attivato sul router.
Nota: Se si utilizza la porta AUX per monitorare il router, tenere presente che quando il router viene riavviato, la porta AUX non visualizza l'output della sequenza di avvio. Collegarsi alla porta della console per visualizzare la sequenza di avvio.
Porte VTY
Se si è connessi tramite una porta ausiliaria o via telnet, digitare il comando terminal monitor. Verificare inoltre che il comando no logging on non sia in uso.
Registrazione dei messaggi in un buffer interno
Il dispositivo di registrazione predefinito è la console; tutti i messaggi vengono visualizzati sulla console se non diversamente specificato.
Per registrare i messaggi in un buffer interno, eseguire il comando di configurazione del router con buffer di registrazione. La sintassi completa del comando è:
logging buffered no logging buffered
Il comando log nel buffer copia i messaggi di log in un buffer interno anziché scriverli sulla console. Poiché il buffer è di natura circolare, i messaggi più recenti sovrascrivono quelli meno recenti.
Per visualizzare i messaggi registrati nel buffer, usare il comando in modalità di esecuzione privilegiata show log. Il primo messaggio visualizzato è il messaggio meno recente presente nel buffer. È possibile specificare le dimensioni del buffer e il livello di gravità dei messaggi da registrare.
Nota: Prima di immettere le dimensioni del buffer, assicurarsi che nella casella sia disponibile una quantità di memoria sufficiente. Utilizzare il comando show proc mem per verificare la memoria disponibile.
Il comando no logging buffered annulla l'uso del buffer e scrive i messaggi sulla console (impostazione predefinita).
Registrazione dei messaggi in un server Syslog UNIX
Per registrare i messaggi sull'host del server syslog, eseguire il comando di configurazione del router di log. Visualizzare la sintassi completa del comando:
loggingno logging
Il comando logging identifica un host del server syslog per la ricezione di messaggi di logging. L'argomento <ip-address> è l'indirizzo IP dell'host. Emettendo questo comando più di una volta, si crea un elenco di server syslog che ricevono i messaggi di registrazione.
Il comando no logging elimina il server syslog con l'indirizzo specificato dall'elenco dei syslog.
Altre attività pre-debug
-
Configurare il software dell'emulatore di terminale in modo che acquisisca l'output di debug in un file. Fare riferimento alla documentazione dell'emulatore di terminale software.
-
Abilita timestamp in millisecondi (msec) che eseguono il comando timestamp del servizio:
router(config)#service timestamps debug datetime msec router(config)#service timestamps log datetime msec
Questi comandi aggiungono timestamp ai debug nel formato MMM GG HH:MM:SS, indicando la data e l'ora in base all'orologio di sistema. Se l'orologio di sistema non è stato impostato, la data e l'ora sono precedute da un asterisco (*) per indicare che la data e l'ora sono probabilmente errate.
In genere, è consigliabile configurare l'indicatore orario in millisecondi, in quanto fornisce un elevato livello di chiarezza durante la revisione degli output di debug. I timestamp in millisecondi forniscono una migliore indicazione dei tempi dei vari eventi di debug l'uno rispetto all'altro. Tuttavia, quando la porta della console genera molti messaggi, non è possibile stabilire una correlazione con il tempo effettivo dell'evento.
Ad esempio, se si abilita debug x25all su una confezione con 200 VC e l'output viene registrato nel buffer (eseguendo la console di registrazione e registrando i comandi nel buffer), l'indicatore orario visualizzato nell'output del debug (all'interno del buffer) non può corrispondere all'ora esatta in cui il pacchetto passa attraverso l'interfaccia. Pertanto, non utilizzare timestamp msec per provare i problemi di prestazioni, ma per ottenere informazioni relative sul momento in cui si verificano gli eventi.
Interrompi debug
Per interrompere un debug, usare i comandi no debug all o undebug all. Verificare che i debug siano stati disattivati con il comando show debug.
Tenere presente che i comandi no logging console e terminal no monitor impediscono solo l'output sulla console, aux o vty rispettivamente. Non interrompe il debug e utilizza le risorse del router.
Uso del comando debug ip packet
Sui router Cisco IOS® classici, il pacchetto ip di debug rileva principalmente il traffico a commutazione di contesto. Il traffico inoltrato tramite Fast Switching o CEF non viene visualizzato a meno che l'inoltro non venga forzato nel percorso di commutazione di contesto. Tuttavia, poiché genera un output per ogni pacchetto, l'output può essere esteso e causare il blocco del router. Per questo motivo, eseguire il pacchetto ip di debug solo con i controlli più severi, come descritto in questa sezione.
Il modo migliore per limitare l'output del pacchetto ip di debug è creare un elenco degli accessi collegato al pacchetto di debug. Solo i pacchetti che soddisfano i criteri dell'elenco degli accessi possono essere soggetti al pacchetto ip di debug. Non è necessario applicare questo elenco degli accessi a un'interfaccia, bensì all'operazione di debug.
Prima di eseguire il pacchetto ip di debug, notare che il router sta utilizzando la commutazione veloce per impostazione predefinita o può usare la commutazione CEF, se configurata a tal fine. Ciò significa che, una volta che tali tecniche sono in atto, il pacchetto non viene fornito al processore, il debug non mostra nulla. Per risolvere questo problema, è necessario disabilitare l'opzione di commutazione veloce sul router senza ip route-cache (per pacchetti unicast) o senza ip route-cache (per pacchetti multicast). Deve essere applicata alle interfacce su cui si prevede che il traffico fluisca. Verificare questa condizione con il comando show ip route.
Nota: Sulle piattaforme più recenti, l'inoltro è in genere gestito dal CEF o dalla commutazione basata su hardware, pertanto la disabilitazione della commutazione veloce non è più applicabile o consigliata. Di conseguenza, il pacchetto ip di debug può non essere in grado di visualizzare il traffico di transito in modo affidabile e la risoluzione dei problemi moderna si basa generalmente sull'acquisizione specifica della piattaforma o su strumenti hardware.
Debug attivati in base alle condizioni
Quando la funzione Debug attivato a condizione è abilitata, il router genera messaggi di debug per i pacchetti in entrata o in uscita dal router su un'interfaccia specificata; il router non genera output di debug per i pacchetti in entrata o in uscita da un'interfaccia diversa.
Esaminare una semplice implementazione dei debug condizionali. Considerare questo scenario: il router mostrato di seguito (trabol) ha due interfacce (seriale 0 e seriale 3) entrambe con incapsulamento HDLC.
È possibile eseguire il comando normal debug serial interface per verificare i pacchetti keepalive HDLC ricevuti su tutte le interfacce. È possibile osservare i pacchetti keepalive su entrambe le interfacce:
traxbol#debug serial interface Serial network interface debugging is on traxbol# *Mar 8 09:42:34.851: Serial0: HDLC myseq 28, mineseen 28*, yourseen 41, line up ! -- HDLC keeplaive on interface Serial 0 *Mar 8 09:42:34.855: Serial3: HDLC myseq 26, mineseen 26*, yourseen 27, line up ! -- HDLC keeplaive on interface Serial 3 *Mar 8 09:42:44.851: Serial0: HDLC myseq 29, mineseen 29*, yourseen 42, line up *Mar 8 09:42:44.855: Serial3: HDLC myseq 27, mineseen 27*, yourseen 28, line up
Abilitare i debug condizionali per l'interfaccia seriale 3, ossia vengono visualizzati solo i debug per l'interfaccia seriale 3. Eseguire il comando debug interface <interface_type interface_number >:
traxbol#debug interface serial 3 Condition 1 set
Eseguire il comando show debug condition per verificare che il debug condizionale sia attivo (una condizione per interface serial 3 è attiva):
traxbol#show debug condition Condition 1: interface Se3 (1 flags triggered) Flags: Se3 traxbol#
Ora vengono visualizzati solo i debug per l'interfaccia seriale 3:
*Mar 8 09:43:04.855: Serial3: HDLC myseq 29, mineseen 29*, yourseen 30, line up *Mar 8 09:43:14.855: Serial3: HDLC myseq 30, mineseen 30*, yourseen 31, line up
Eseguire il comando undebug interface <interface_type_interface_number> per rimuovere il debug condizionale. Prima di rimuovere il trigger condizionale, si consiglia di disattivare i debug (ad esempio, utilizzando undebug all). In questo modo, si evita un diluvio degli output di debug quando la condizione viene rimossa.
traxbol#undebug interface serial 3 This condition is the last interface condition set. Removing all conditions can cause a flood of debugging messages to result, unless specific debugging flags are first removed. Proceed with removal? [yes/no]: y Condition 1 has been removed traxbol
È possibile osservare il debug sia sull'interfaccia seriale 0 che su quella seriale 3:
*Mar 8 09:43:34.927: Serial3: HDLC myseq 32, mineseen 32*, yourseen 33, line up *Mar 8 09:43:44.923: Serial0: HDLC myseq 35, mineseen 35*, yourseen 48, line up
Avviso: Alcune operazioni di debug sono condizionali. Un esempio è il debug ATM, con il debug ATM è necessario specificare in modo esplicito l'interfaccia per la quale devono essere attivati i debug, invece di attivare i debug su tutte le interfacce ATM e specificare una condizione.
In questa sezione viene illustrato il modo corretto per limitare il debug dei pacchetti ATM a una sottointerfaccia:
arielle-nrp2#debug atm packet interface atm 0/0/0.1 !--- Note that you explicitly specify the sub-interface to be used for debugging ATM packets debugging is on Displaying packets on interface ATM0/0/0.1 only arielle-nrp2# *Dec 21 10:16:51.891: ATM0/0/0.1(O): VCD:0x1 VPI:0x1 VCI:0x21 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:0007 Length:0x278 *Dec 21 10:16:51.891: 0000 FFFF FFFF FFFF 0010 7BB9 BDC4 0800 4500 025C 01FE 0000 FF11 61C8 0A30 *Dec 21 10:16:51.891: 4B9B FFFF FFFF 0044 0043 0248 0000 0101 0600 0015 23B7 0000 8000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0010 7BB9 BDC3 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.895: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.895: arielle-nrp2#
Se si tenta di abilitare il debug ATM su tutte le interfacce (con una condizione applicata), il router può bloccarsi se dispone di un numero elevato di sottointerfacce ATM. Viene mostrato un esempio del metodo errato per il debug ATM.
In questo caso è possibile verificare che una condizione è applicata, ma è anche evidente che non ha alcun effetto. Il pacchetto può ancora essere visualizzato dall'altra interfaccia.
In questo scenario di laboratorio sono disponibili solo due interfacce e un traffico ridotto. Se il numero di interfacce è elevato, anche l'output di debug per tutte le interfacce è estremamente elevato e può causare il blocco del router:
arielle-nrp2#show debugging condition Condition 1: interface AT0/0/0.1 (1 flags triggered) Flags: AT0/0/0.1 ! -- A condition for a specific interface. arielle-nrp2#debug atm packet ATM packets debugging is on Displaying all ATM packets arielle-nrp2# *Dec 21 10:22:06.727: ATM0/0/0.2(O): ! -- You see debugs from interface ATM0/0/0/.2, even though the condition ! -- specified ONLY AT0/0/0.1 VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:06.727: 0000 0000 0180 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:06.727: 0002 000F 0000 *Dec 21 10:22:06.727: un a *Dec 21 10:22:08.727: ATM0/0/0.2(O): VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:08.727: 0000 0000 0180 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:08.727: 0002 000F 0000 *Dec 21 10:22:08.727: ll *Dec 21 10:22:10.727: ATM0/0/0.2(O): VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:10.727: 0000 0000 0080 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:10.727: 0002 000F 0000 *Dec 21 10:22:10.727: *Dec 21 10:22:12.727: ATM0/0/0.2(O): VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:12.727: 0000 0000 0080 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:12.727: 0002 000F 0000 *Dec 21 10:22:12.727: *Dec 21 10:22:13.931: ATM0/0/0.1(O): !--- You also see debugs for interface ATM0/0/0.1 as you wanted. VCD:0x1 VPI:0x1 VCI:0x21 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:0007 Length:0x278 *Dec 21 10:22:13.931: 0000 FFFF FFFF FFFF 0010 7BB9 BDC4 0800 4500 025C 027F 0000 FF11 6147 0A30 *Dec 21 10:22:13.931: 4B9B FFFF FFFF 0044 0043 0248 0000 0101 0600 001A 4481 0000 8000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0010 7BB9 BDC3 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.935: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Informazioni correlate
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
5.0 |
22-Jun-2026
|
Spaziatura di introduzione aggiornata, altre spaziature all'interno dell'articolo, grammatica, ortografia, rientro. |
4.0 |
19-Aug-2024
|
Certificazione |
2.0 |
29-Apr-2022
|
Collegamenti interrotti aggiornati e rimossi. |
1.0 |
02-Dec-2013
|
Versione iniziale |
Feedback