Informazioni importanti sui comandi di debug

Aggiornato:24 agosto 2023
ID documento:10374

Linguaggio senza pregiudizi

La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.

Informazioni su questa traduzione

Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).

    Introduzione

    Questo documento descrive le linee guida generali per l'utilizzo debug comandi tra cui  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.

    Convenzioni

    Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

    Premesse

    Questa pagina fornisce alcune linee guida generali sull'uso dei debug disponibili sulle piattaforme Cisco IOS e alcuni esempi per un uso corretto del debug ip packet e il debug condizionale.

    note-icon

    Nota: questo documento non spiega come usare e interpretare comandi e output di debug specifici. Per informazioni su comandi di debug specifici, consultare la documentazione di riferimento dei comandi di debug di Cisco.

    L'output da debug i comandi in modalità di esecuzione privilegiata forniscono informazioni diagnostiche che includono una varietà di eventi di internetworking relativi allo stato del protocollo e all'attività di rete in generale.

    Avvisi

    Utilizzo debug con cautela. In generale, si consiglia di utilizzare questi comandi solo sotto la direzione del rappresentante del supporto tecnico del router per la risoluzione di problemi specifici.

    L'attivazione del debug può interrompere il funzionamento del router quando nelle reti interne si verificano condizioni di carico elevato. Pertanto, se la registrazione è abilitata, il server di accesso può bloccarsi in modo intermittente non appena la porta della console è sovraccarica di messaggi di registro.

    Prima di avviare un debug tenere sempre in considerazione l'output che questo comando può generare e il tempo necessario per l'esecuzione di questa operazione. Ad esempio, se si dispone di un router con una BRI (Basic Rate Interface), debug isdn q931 probabilmente non danneggia il sistema. Tuttavia, eseguire lo stesso debug su un AS5800 con configurazione E1 completa potrebbe generare un input talmente elevato da bloccarsi e non rispondere più.

    Prima di eseguire il debug, esaminare il carico della CPU con show processes cpu Prima di iniziare il debug, verificare di avere a disposizione un'ampia CPU. per ulteriori informazioni su come gestire carichi elevati della CPU, fare riferimento a Risoluzione dei problemi di utilizzo elevato della CPU sui router Cisco. Ad esempio, se si ha un router Cisco 7200 con un'interfaccia ATM che esegue il bridging, a seconda della quantità di sottointerfacce configurate, il riavvio del router può usare molta della sua CPU. Il motivo è che, per ogni circuito virtuale (VC), è necessario generare un pacchetto BDPU (Bridge Protocol Data Unit). L'avvio dei debug in un momento critico di questo tipo può causare un aumento significativo dell'utilizzo della CPU con conseguente blocco o perdita della connettività di rete.

    note-icon

    Nota: quando i debug sono in esecuzione, in genere il prompt del router non viene visualizzato, specialmente quando il debug richiede molte risorse. Tuttavia, nella maggior parte dei casi, è possibile usare i comandi no debug all o undebug all per interrompere i debug. per ulteriori informazioni sull'uso sicuro dei debug, consultare la sezione Come ottenere gli output di debug.

    Prima del debug

    Oltre ai punti citati in precedenza, accertarsi di aver compreso l'impatto dei debug sulla stabilità della piattaforma. È inoltre necessario stabilire a quale interfaccia del router connettersi. Questa sezione contiene alcune linee guida.

    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. Le istruzioni e le avvertenze relative a ciascun metodo sono illustrate di seguito:

    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. Ma, assicurarsi che logging console level è impostato come desiderato e la registrazione non è stata disattivata con il no logging console

    warning-icon

    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. Pertanto, se il router sta elaborando un output di debug di grandi dimensioni sulla porta della console, può bloccarsi. Pertanto, se l'output del debug è eccessivo, usare le porte vty (telnet) o i buffer di registro per ottenere i debug. Di seguito vengono fornite ulteriori informazioni.

    note-icon

    Nota: per impostazione predefinita, la registrazione è abilitata sulla porta della console. Pertanto, la porta della console elabora sempre l'output del debug anche se si sta effettivamente utilizzando un'altra porta o metodo (ad esempio Aux, vty o buffer) per acquisire l'output. Pertanto, Cisco consiglia di avere sempre il comando no logging console abilitato in condizioni operative normali e di utilizzare altri metodi per acquisire i debug. Se è necessario utilizzare la console, riaccenderla temporaneamente.

    Porta ausiliaria

    Se si è connessi tramite una porta ausiliaria, digitare il comando terminal monitor Verificare inoltre che il no logging on il comando non è stato attivato sul router.

    note-icon

    Nota: se si usa 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 tramite telnet, digitare il comando terminal monitor Verificare inoltre che il no logging on non è stato utilizzato.

    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, utilizzare logging buffered router configuration. La sintassi completa del comando è:

    logging buffered
no logging buffered

    OSPF (Open Shortest Path First) logging buffered I messaggi di log vengono copiati in un buffer interno anziché essere scritti nella console. Poiché il buffer è di natura circolare, i messaggi più recenti sovrascrivono quelli meno recenti. Per visualizzare i messaggi registrati nel buffer, utilizzare il comando EXEC privilegiato show logging . 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.

    note-icon

    Nota: prima di immettere le dimensioni del buffer, assicurarsi che nella casella sia disponibile una quantità di memoria sufficiente. Uso di Cisco IOS  show proc mem   per visualizzare la memoria disponibile.

    OSPF (Open Shortest Path First) no logging buffered annulla l'utilizzo del buffer e scrive i messaggi nella console (impostazione predefinita).

    Registrazione dei messaggi in un server Syslog UNIX

    Per registrare i messaggi sull'host del server syslog, usare il comando di configurazione del router di log. Di seguito è riportata la sintassi completa del comando:

     logging  
     
no logging

    OSPF (Open Shortest Path First)loggingidentifica un host del server syslog per la ricezione dei 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 messaggi di registrazione.

    OSPF (Open Shortest Path First) no logging Il comando elimina il server syslog con l'indirizzo specificato dall'elenco di syslog.

    Altre attività pre-debug

    1. Configurare il software dell'emulatore di terminale (ad esempio, HyperTerminal) in modo che possa acquisire l'output di debug in un file. Ad esempio, in HyperTerminal fare clic suTransfer, quindi scegliere Capture Text e scegliere le opzioni appropriate. Per ulteriori informazioni, consultare il documento sulla cattura dell'output di testo da Hyperterminal. Per altri software di emulatori di terminale, consultare la documentazione del software.

    2. Abilita timestamp in millisecondi (msec) tramite service timestamps comando:

       router(config)#service timestamps debug datetime msec 
      router(config)#service timestamps log datetime msec

    Questi comandi aggiungono ai debug timestamp 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 probabilmente la data e l'ora non sono corrette.

    In genere, è consigliabile configurare l'indicatore orario in millisecondi, in quanto fornisce un elevato livello di chiarezza quando si esaminano gli output del 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 può stabilire una correlazione con i tempi effettivi dell'evento. Ad esempio, se si attiva debug x25 il tutto su una confezione con 200 VC e l'output viene registrato nel buffer (utilizzando no logging console e logging buffered ), l'indicatore orario visualizzato nell'output di debug (all'interno del buffer) non può essere l'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.

    Per interrompere il debug

    Per interrompere un debug, utilizzare il comandono debug alloundebug allcomandi. Verificare che i debug siano stati disattivati utilizzando il comandoshow debug.

    Tenere presente che i comandi no logging console e terminal no monitor impedire solo l'output sulla console, Aux o vty rispettivamente. Non interrompe il debug e pertanto utilizza le risorse del router.

    Uso del comando debug ip packet

    OSPF (Open Shortest Path First) debug ip packet produce informazioni sui pacchetti non commutati rapidamente dal router. Tuttavia, poiché genera un output per ogni pacchetto, l'output può essere esteso e causare il blocco del router. Per questo motivo, utilizzare solo debug ip packet sotto i controlli più rigorosi descritti nella presente sezione.

    Il modo migliore per limitare l'output di debug ip packet consiste nel creare un elenco degli accessi collegato al comando debug. Solo i pacchetti che soddisfano i criteri dell'elenco degli accessi possono essere soggetti a debug ip packet . Non è necessario applicare questo elenco degli accessi a un'interfaccia, bensì all'operazione di debug.

    Prima dell'utilizzo debugging ip packet Si noti, tuttavia, che per impostazione predefinita il router sta eseguendo la commutazione rapida o, se configurato, può eseguire la commutazione CEF. Ciò significa che, una volta implementate tali tecniche, il pacchetto non viene fornito al processore, quindi il debug non visualizza nulla. Per il corretto funzionamento di questa funzione, è necessario disabilitare l'opzione di commutazione veloce sul router con no ip route-cache (per pacchetti unicast) o no ip mroute-cache (per pacchetti multicast). Deve essere applicata alle interfacce su cui si prevede che il traffico fluisca. Verifica con il show ip route

    Avvisi

    • La disabilitazione dell'opzione di commutazione veloce su un router che gestisce un numero elevato di pacchetti può causare un picco nell'utilizzo della CPU, in modo che la scatola blocchi o perda la connessione con i peer.

    • Non disabilitare l'opzione di commutazione veloce su un router che esegue Multi Protocol Label Switching (MPLS). MPLS viene utilizzato in combinazione con CEF. Pertanto, la disabilitazione dell'opzione di commutazione veloce sull'interfaccia può avere un effetto disastroso.

    Si consideri questo scenario di esempio:

    Router Example

    L'elenco degli accessi configurato sul router_122 è:

    access-list 105 permit icmp host 10.10.10.2 host 10.1.1.1 
access-list 105 permit icmp host 10.1.1.1 host 10.10.10.2

    Questo elenco degli accessi consente a qualsiasi pacchetto ICMP (Internet Control Message Protocol) proveniente dall'host router_121 (con indirizzo IP 10.10.10.2) di ospitare router_123 (con indirizzo IP 10.1.1.1) e nella direzione opposta. È importante autorizzare i pacchetti in entrambe le direzioni, in caso contrario il router può rilasciare il pacchetto ICMP restituito.

    Rimuovere l'opzione di commutazione veloce solo su un'interfaccia sul router_122. Ciò significa che è possibile vedere solo i debug dei pacchetti destinati a quell'interfaccia, dal punto di vista di Cisco IOS che intercetta il pacchetto. Dai debug, tali pacchetti appaiono con "d=". Poiché non è stata ancora disattivata l'opzione di commutazione veloce sull'altra interfaccia, il pacchetto di ritorno non è soggetto a debug ip packet . In questo output viene mostrato come disabilitare l'opzione di commutazione veloce:

    router_122(config)#interface virtual-template 1
router_122(config-if)#no ip route-cache 
router_122(config-if)#end

    A questo punto, è necessario attivare debug ip packet con l'elenco degli accessi definito in precedenza (access-list 105).

    router_122# debug ip packet  detail 105 
IP packet debugging is on (detailed) for access list 105 
router_122# 
00:10:01: IP: s=10.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), 
g=10.10.10.2, len 100, forward 

00:10:01:     ICMP type=0, code=0 

! -- ICMP packet from 10.1.1.1 to 10.10.10.2. 
! -- This packet is displayed because it matches the 
! -- source and destination requirements in access list 105

00:10:01: IP: s=10.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), 
g=10.10.10.2, len 100, forward 
00:10:01:     ICMP type=0, code=0 
00:10:01: IP: s=10.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), 
g=10.10.10.2, len 100, forward 
00:10:01:     ICMP type=0, code=0

    A questo punto, rimuovere l'opzione di commutazione veloce sull'altra interfaccia (sul router_122). Ciò significa che tutti i pacchetti su queste due interfacce sono ora a commutazione di pacchetto (un requisito per debug ip packet 

    router_122(config)#interface serial 3/0 
router_122(config-if)#no ip route-cache 
router_122(config-if)#end    
              
router_122#    
00:11:57:  IP: s=10.10.10.2 (Virtual-Access1), d=10.1.1.1 
(Serial3/0), g=172.16.1.6, len 100, forward 
00:11:57:  ICMP type=8, code=0 

! -- ICMP packet (echo) from 10.10.10.2 to 10.1.1.1

00:11:57: IP: s=10.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), 
g=10.10.10.2, len 100, forward 
00:11:57:  ICMP type=0, code=0

! -- ICMP return packet (echo-reply) from 10.1.1.1 to 10.10.10.2

00:11:57:  IP: s=10.10.10.2 (Virtual-Access1), d=10.1.1.1 (Serial3/0), 
g=172.16.1.6, len 100, forward 
00:11:57:  ICMP type=8, code=0 
00:11:57:  IP: s=10.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), 
g=10.10.10.2, len 100, forward 
00:11:57:  ICMP type=0, code=0

    Notare che l'output del pacchetto ip di debug non mostra pacchetti che non corrispondono ai criteri dell'elenco degli accessi. Per ulteriori informazioni su questa procedura, consultare il documento sulla descrizione dei comandi Ping e Traceroute.

    Per ulteriori informazioni su come creare elenchi degli accessi, vedere Registrazione degli elenchi degli accessi IP standard.

    Debug attivati in base alle condizioni

    Quando la funzionalità 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 utilizzare la normale debug serial interface per osservare i pacchetti keepalive HDLC ricevuti su tutte le interfacce. I pacchetti keepalive possono essere osservati 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 serial 3. Ciò significa che vengono visualizzati solo i debug per l'interfaccia seriale 3. Utilizzare il debug interface <interface_type interface_number >

    traxbol#debug interface serial 3 
Condition 1 set

    Utilizzare il show debug condition per verificare che il debug condizionale sia attivo. Notare che una condizione per interface serial 3 è attiva.

    traxbol#show debug condition 

Condition 1: interface Se3 (1 flags triggered) 
Flags: Se3 
traxbol#

    Notare che ora vengono visualizzati solo i debug per l'interfaccia serial 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

    Utilizzare il 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

    A questo punto, è possibile osservare che il comando debug viene visualizzato sia per l'interfaccia seriale 0 che per l'interfaccia 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
    warning-icon

    Avviso: alcune operazioni di debug sono condizionali. Un esempio è il debug ATM. Con il debug ATM è necessario specificare in modo esplicito l'interfaccia per cui devono essere abilitati i debug, anziché abilitare 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 attivare atm debugging su tutte le interfacce (con una condizione applicata), il router può bloccarsi se dispone di un elevato numero 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 è alto, l'output del comando debug per tutte le interfacce è estremamente alto e il router può bloccarsi.

    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
    3.0
    24-Aug-2023
    Certificazione
    2.0
    29-Apr-2022
    Collegamenti interrotti aggiornati e rimossi.
    1.0
    02-Dec-2013
    Versione iniziale
    TAC Authored

    Contributo dei tecnici Cisco

    Questo documento ti è stato utile?

    FeedbackFeedback

    Contattaci