Informazioni importanti sui comandi di debug

Opzioni per il download

PDF (289.0 KB)
Visualizza con Adobe Reader su diversi dispositivi
ePub (89.2 KB)
Visualizza in diverse app su iPhone, iPad, Android, Sony Reader o Windows Phone
Mobi (Kindle) (91.3 KB)
Visualizza su dispositivo Kindle o tramite app Kindle su più dispositivi

Aggiornato:19 agosto 2024

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).

Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Premesse

Avvisi

Prima del debug

Recupero degli output di debug

Porta della console

Porta ausiliaria

Porte VTY

Registrazione dei messaggi in un buffer interno

Registrazione dei messaggi in un server Syslog UNIX

Altre attività pre-debug

Per interrompere il debug

Uso del comando debug ip packet

Avvisi

Debug attivati in base alle condizioni

Informazioni correlate

Introduzione

Questo documento descrive le linee guida generali sull'uso dei debug comandi, incluso debug ip packet il comando 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`

In questa pagina vengono fornite alcune linee guida generali sull'utilizzo dei debug disponibili sulle piattaforme Cisco IOS e alcuni esempi per un utilizzo corretto debug ip packet del comando e del debug condizionale.

 
       
       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 debug dei comandi in modalità di esecuzione privilegiata fornisce informazioni diagnostiche che includono una varietà di eventi di internetworking relativi allo stato del protocollo e all'attività di rete in generale.

`Avvisi`

debug Utilizzare i comandi 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 comando, considerare sempre l'output che questo comando può generare e la quantità di tempo che può richiedere.

Ad esempio, se si dispone di un router con una BRI (Basic Rate Interface), è debug isdn q931 probabile che non danneggi il sistema.

In tutti i casi, eseguire lo stesso debug su un AS5800 con configurazione E1 completa può generare così tanto input da bloccarsi e interrompere la risposta.

Prima di eseguire il debug, esaminare il carico della CPU con show processes cpu il comando. 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.

 
       
       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.

Accertarsi tuttavia che logging console level le impostazioni siano corrette e che la registrazione non sia stata disabilitata con no logging console il comando.

 
       
       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.

  
       
       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 terminal monitor il comando. Verificare inoltre che no logging on il comando non sia stato attivato sul router.

 
       
       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 terminal monitor il comando. Verificare inoltre che no logging on il comando non sia 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 il comando di configurazione logging buffered del router. La sintassi completa del comando è:

logging buffered no logging buffered

logging buffered I messaggi di registro 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 show logging EXEC privilegiato. 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. Per verificare la memoria disponibile, usare il comando Cisco IOS show proc mem .

no logging buffered Il comando 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 <ip-address> no logging <ip-address>

loggingIl comando identifica un host del server syslog per la ricezione dei messaggi di log. 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.

no logging Il comando elimina il server syslog con l'indirizzo specificato dall'elenco di syslog.

`Altre attività pre-debug`

  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 clicTransfer su, quindi su 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.
 
  Abilitare i timestamp in millisecondi (msec) utilizzando  service timestamps il 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 debug x25 abilita tutto su una confezione con 200 VC e l'output viene registrato nel buffer (usando i comandi no logging console logging buffered and), 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 i no debug allundebug allcomandi teorici. Verificare che i debug siano stati disattivati utilizzando il comandoshow debug.

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

`Uso del comando debug ip packet`

debug ip packet Il comando produce informazioni sui pacchetti che non sono commutati rapidamente dal router. Tuttavia, poiché genera un output per ogni pacchetto, l'output può essere esteso e causare quindi il blocco del router. Per questo motivo, debug ip packet usare solo sotto i controlli più rigorosi descritti in questa sezione.

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

Prima di usare debugging ip packet il router sta eseguendo la commutazione rapida per impostazione predefinita, oppure può eseguire la commutazione CEF se è stata configurata per eseguire questa operazione. Ciò significa che, una volta implementate tali tecniche, il pacchetto non viene fornito al processore, quindi il debug non visualizza nulla. A tale scopo, è necessario disabilitare l'opzione di commutazione veloce sul router con no ip route-cache (per pacchetti unicast) o con no ip mroute-cache (per pacchetti multicast). Deve essere applicata alle interfacce su cui si prevede che il traffico fluisca. Verificare questa condizione con show ip route il comando.

`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:

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 debug ip packet a. 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 debug ip packet attivare 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 usare il comando debug serial interface normal 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 debug interface <interface_type interface_number >il comando.

traxbol#debug interface serial 3 Condition 1 set

Per verificare che show debug condition il debug condizionale sia attivo, usare il comando. 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

Usare undebug interface <interface_type interface_number> il comando 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

 
       
       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 atm debugging abilitare 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`

 Supporto della tecnologia Dial and Access
 Supporto tecnico Cisco e download

Cronologia delle revisioni

Revisione	Data di pubblicazione	Commenti
4.0	19-Aug-2024	Certificazione
2.0	29-Apr-2022	Collegamenti interrotti aggiornati e rimossi.
1.0	02-Dec-2013	Versione iniziale

Contributo dei tecnici Cisco

Questo documento ti è stato utile?

Feedback

Contattaci

Apri una richiesta di assistenza
(Occorre un contratto di servizio Cisco)