Examples

The following is sample output from the debugclnsesisevents command:

Router# debug clns esis events
ES-IS: ISH from aa00.0400.2c05 (Ethernet1), HT 30
ES-IS: ESH from aa00.0400.9105 (Ethernet1), HT 150
ES-IS: ISH sent to All ESs (Ethernet1): NET 49.0001.AA00.0400.6904.00, HT 299, HLEN 20

The following line indicates that the router received a hello packet ( ISH) from the IS at MAC address aa00.0400.2c05 on Ethernet interface 1. The hold time (or number of seconds to consider this packet valid before deleting it) for this packet is 30 seconds.

ES-IS: ISH from aa00.0400.2c05 (Ethernet1), HT 30

The following line indicates that the router received a hello packet (ESH) from the ES at MAC address aa00.0400.9105 on the Ethernet interface 1. The hold time is 150 seconds.

ES-IS: ESH from aa00.0400.9105 (Ethernet1), HT 150

The following line indicates that the router sent an IS hello packet on the Ethernet interface 0 to all ESs on the network. The network entity title (NET) address of the router is 49.0001.0400.AA00.6904.00; the hold time for this packet is 299 seconds; and the header length of this packet is 20 bytes.

ES-IS: ISH sent to All ESs (Ethernet1): NET 49.0001.AA00.0400.6904.00, HT 299, HLEN 20

Examples

The following is sample output from thedebugclnsesispackets command:

Router# debug clns esis packets
 
ES-IS: ISH sent to All ESs (Ethernet0): NET 
47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00, HT 299, HLEN 33
ES-IS: ISH sent to All ESs (Ethernet1): NET 
47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00, HT 299, HLEN 34
ES-IS: ISH from aa00.0400.6408 (Ethernet0), HT 299
ES-IS: ISH sent to All ESs (Tunnel0): NET 
47.0005.80ff.ef00.0000.0001.5940.1600.O906.4023.00, HT 299, HLEN 34
IS-IS: ESH from 0000.0c00.bda8 (Ethernet0), HT 300

The following line indicates that the router has sent an IS hello packet on Ethernet interface 0 to all ESs on the network. This hello packet indicates that the NET of the router is 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00. The hold time for this packet is 299 seconds. The packet header is 33 bytes in length.

ES-IS: ISH sent to All ESs (Ethernet0): NET 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00, HT 299, HLEN 33

The following line indicates that the router has sent an IS hello packet on Ethernet interface 1 to all ESs on the network. This hello packet indicates that the NET of the router is 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00. The hold time for this packet is 299 seconds. The packet header is 33 bytes in length.

ES-IS: ISH sent to All ESs (Ethernet1): NET 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00, HT 299, HLEN 34

The following line indicates that the router received a hello packet on Ethernet interface 0 from an intermediate system, aa00.0400.6408. The hold time for this packet is 299 seconds.

ES-IS: ISH from aa00.0400.6408 (Ethernet0), HT 299 

The following line indicates that the router has sent an IS hello packet on Tunnel interface 0 to all ESs on the network. This hello packet indicates that the NET of the router is 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00. The hold time for this packet is 299 seconds. The packet header is 33 bytes in length.

ES-IS: ISH sent to All ESs (Tunnel0): NET 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00, HT 299, HLEN 34 

The following line indicates that on Ethernet interface 0, the router received a hello packet from an end system with an SNPA of 0000.0c00.bda8. The hold time for this packet is 300 seconds.

IS-IS: ESH from 0000.0c00.bda8 (Ethernet0), HT 300

Examples

The following is sample output from thedebugclnsevents command:

Router# debug clns events
CLNS: Echo PDU received on Ethernet3 from 39.0001.2222.2222.2222.00!
CLNS: Sending from 39.0001.3333.3333.3333.00 to 39.0001.2222.2222.2222.00
         via 2222.2222.2222 (Ethernet3 0000.0c00.3a18)
CLNS: Forwarding packet size 117
      from 39.0001.2222.2222.2222.00
      to 49.0002.0001.AAAA.AAAA.AAAA.00
      via 49.0002 (Ethernet3 0000.0c00.b5a3)
CLNS: RD Sent on Ethernet3 to 39.0001.2222.2222.2222.00 @ 0000.0c00.3a18,
      redirecting 49.0002.0001.AAAA.AAAA.AAAA.00 to 0000.0c00.b5a3

The following line indicates that the router received an echo protocol data unit (PDU) on Ethernet interface 3 from source network service access point (NSAP) 39.0001.2222.2222.2222.00. The exclamation point at the end of the line has no significance.

CLNS: Echo PDU received on Ethernet3 from 39.0001.2222.2222.2222.00!

The following lines indicate that the router at source NSAP 39.0001.3333.3333.3333.00 is sending a CLNS echo packet to destination NSAP 39.0001.2222.2222.2222.00 via an IS with system ID 2222.2222.2222. The packet is being sent on Ethernet interface 3, with a MAC address of 0000.0c00.3a18.

CLNS: Sending from 39.0001.3333.3333.3333.00 to 39.0001.2222.2222.2222.00
         via 2222.2222.2222 (Ethernet3 0000.0c00.3a18)

The following lines indicate that a CLNS echo packet 117 bytes in size is being sent from source NSAP 39.0001.2222.2222.2222.00 to destination NSAP 49.0002.0001.AAAA.AAAA.AAAA.00 via the router at NSAP 49.0002. The packet is being forwarded on the Ethernet interface 3, with a MAC address of 0000.0c00.b5a3.

CLNS: Forwarding packet size 117
      from 39.0001.2222.2222.2222.00
      to 49.0002.0001.AAAA.AAAA.AAAA.00
      via 49.0002 (Ethernet3 0000.0c00.b5a3)

The following lines indicate that the router sent a redirect packet on the Ethernet interface 3 to the NSAP 39.0001.2222.2222.2222.00 at MAC address 0000.0c00.3a18 to indicate that NSAP 49.0002.0001.AAAA.AAAA.AAAA.00 can be reached at MAC address 0000.0c00.b5a3.

CLNS: RD Sent on Ethernet3 to 39.0001.2222.2222.2222.00 @ 0000.0c00.3a18,
      redirecting 49.0002.0001.AAAA.AAAA.AAAA.00 to 0000.0c00.b5a3 

Examples

The following is sample output from thedebugclnsigrppackets command:

Router# debug clns igrp packets
ISO-IGRP: Hello sent on Ethernet3 for DOMAIN_green1
ISO-IGRP: Received hello from 39.0001.3333.3333.3333.00, (Ethernet3), ht 51
ISO-IGRP: Originating level 1 periodic update
ISO-IGRP: Advertise dest: 2222.2222.2222
ISO-IGRP: Sending update on interface: Ethernet3
ISO-IGRP: Originating level 2 periodic update
ISO-IGRP: Advertise dest: 0001
ISO-IGRP: Sending update on interface: Ethernet3
ISO-IGRP: Received update from 3333.3333.3333 (Ethernet3)
ISO-IGRP: Opcode: area
ISO-IGRP: Received level 2 adv for 0001 metric 1100
ISO-IGRP: Opcode: station
ISO-IGRP: Received level 1 adv for 3333.3333.3333 metric 1100

The following line indicates that the router is sending a hello packet to advertise its existence in the DOMAIN_green1 domain:

ISO-IGRP: Hello sent on Ethernet3 for DOMAIN_green1

The following line indicates that the router received a hello packet from a certain network service access point (NSAP) on Ethernet interface 3. The hold time for this information is 51 seconds.

ISO-IGRP: Received hello from 39.0001.3333.3333.3333.00, (Ethernet3), ht 51

The following lines indicate that the router is generating a Level 1 update to advertise reachability to destination NSAP 2222.2222.2222 and that it is sending that update to all systems that can be reached through Ethernet interface 3:

ISO-IGRP: Originating level 1 periodic update
ISO-IGRP: Advertise dest: 2222.2222.2222
ISO-IGRP: Sending update on interface: Ethernet3

The following lines indicate that the router is generating a Level 2 update to advertise reachability to destination area 1 and that it is sending that update to all systems that can be reached through Ethernet interface 3:

ISO-IGRP: Originating level 2 periodic update
ISO-IGRP: Advertise dest: 0001
ISO-IGRP: Sending update on interface: Ethernet3

The following lines indicate that the router received an update from NSAP 3333.3333.3333 on Ethernet interface 3. This update indicated the area that the router at this NSAP could reach.

ISO-IGRP: Received update from 3333.3333.3333 (Ethernet3)
ISO-IGRP: Opcode: area

The following lines indicate that the router received an update advertising that the source of that update can reach area 1 with a metric of 1100. A station opcode indicates that the update included system addresses.

ISO-IGRP: Received level 2 adv for 0001 metric 1100
ISO-IGRP: Opcode: station

Examples

The following is sample output from thedebugclnspacket command:

Router# debug clns packet
CLNS: Forwarding packet size 157
      from 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.00 STUPI-RBS
      to 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00
      via 1600.8906.4017 (Ethernet0 0000.0c00.bda8)
CLNS: Echo PDU received on Ethernet0 from       47.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00!
CLNS: Sending from 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00 to 
      47.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00
      via 1600.8906.4017 (Ethernet0 0000.0c00.bda8)

In the following lines, the first line indicates that a Connectionless Network Service (CLNS) packet of size 157 bytes is being forwarded. The second line indicates the network service access point ( NSAP) and system name of the source of the packet. The third line indicates the destination NSAP for this packet. The fourth line indicates the next hop system ID, interface, and subnetwork point of attachment (SNPA) of the router interface used to forward this packet.

CLNS: Forwarding packet size 157
      from 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.00 STUPI-RBS
      to 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00
      via 1600.8906.4017 (Ethernet0 0000.0c00.bda8)

In the following lines, the first line indicates that the router received an echo protocol data unit (PDU) on the specified interface from the source NSAP. The second line indicates which source NSAP is used to send a CLNS packet to the destination NSAP, as shown on the third line. The fourth line indicates the next hop system ID, interface, and SNPA of the router interface used to forward this packet.

CLNS: Echo PDU received on Ethernet0 from       47.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00!
CLNS: Sending from 47.0005.80ff.ef00.0000.0001.5940.1600.8906.4023.00 to       47.0005.80ff.ef00.0000.0001.5940.1600.8906.4017.00
      via 1600.8906.4017 (Ethernet0 0000.0c00.bda8)

Examples

The following is sample output from the debugclnsrouting command:

Router# debug clns routing
CLNS-RT: cache increment:17
CLNS-RT: Add 47.0023.0001.0000.0000.0003.0001 to prefix table, next hop 1920.3614.3002
CLNS-RT: Aging cache entry for: 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.06
CLNS-RT: Deleting cache entry for: 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.06

The following line indicates that a change to the routing table has resulted in an addition to the fast-switching cache:

CLNS-RT: cache increment:17

The following line indicates that a specific prefix route was added to the routing table, and indicates the next hop system ID to that prefix route. In other words, when the router receives a packet with the prefix 47.0023.0001.0000.0000.0003.0001 in the destination address of that packet, it forwards that packet to the router with the MAC address 1920.3614.3002.

CLNS-RT: Add 47.0023.0001.0000.0000.0003.0001 to prefix table, next hop 1920.3614.3002

The following lines indicate that the fast-switching cache entry for a certain network service access point (NSAP) has been invalidated and then deleted:

CLNS-RT: Aging cache entry for: 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.06
CLNS-RT: Deleting cache entry for: 47.0023.0001.0000.0000.0003.0001.1920.3614.3002.06

Examples

The following is sample output from thedebugclsmessagecommand. For example, CLS-->DLU indicates the direction of the flow that is described by the status. From CLS to dependent logical unit (DLU), a request was established to the connection endpoint. The header length is 48 bytes, and the data size is 104 bytes.

Router# debug cls message
(FRAS Daemon:CLS-->DLU):
     ID_STN.Ind to uSAP: 0x607044C4 sel: LLC hlen: 40, dlen: 54
(FRAS Daemon:CLS-->DLU):
     ID_STN.Ind to uSAP: 0x6071B054 sel: LLC hlen: 40, dlen: 46
(FRAS Daemon:DLU-->SAP):
     REQ_OPNSTN.Req to pSAP: 0x608021F4 sel: LLC hlen: 48, dlen: 104
(FRAS Daemon:CLS-->DLU):
     REQ_OPNSTN.Cfm(NO_REMOTE_STN) to uCEP: 0x607FFE84 sel: LLC hlen: 48, dlen: 104

The status possibilities include the following: enabled, disabled, request open station, open station, close station, activate SA, deactivate service access point (SAP), XID, exchange identification (XID) station, connect station, signal station, connect, disconnect, connected, data, flow, unnumbered data, modify SAP, test, activate ring, deactivate ring, test station, and unnumbered data station.

Examples

The following messages are sample output from the debugclsvdlc command. In the following scenario, the systems network architecture (SNA) service point--also called nativeservicepoint(NSP)--is setting up two connections through VDLC and data-link switching (DLSw): one from NSP to VDLC and one from DLSw to VDLC. VDLC joins the two.

The NSP initiates a connection from 4000.05d2.0001 as follows:

VDLC: Req Open Stn Req PSap 0x7ACE00, port 0x79DF98      4000.05d2.0001(0C)->4000.1060.1000(04) 

In the next message, VDLC sends a test station request to DLSw for destination address 4000.1060.1000.

VDLC: Send UFrame E3: 4000.05d2.0001(0C)->4000.1060.1000(00)

In the next two messages, DLSw replies with test station response, and NSP goes to a half-open state. NSP is waiting for the DLSw connection to VDLC.

VDLC: Sap to Sap TEST_STN_RSP VSap 0x7B68C0 4000.1060.1000(00)->4000.05d2.0001(0C)
VDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_OPENING->VDLC_HALF_OPEN

The NSP sends an exchange identification (XID) and changes state as follows:

VDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_HALF_OPEN->VDLC_XID_RSP_PENDING
VDLC: CEP to SAP ID_REQ 4000.05d2.0001(0C)->4000.1060.1000(04) via bridging SAP (DLSw)

In the next several messages, DLSw initiates its connection, which matches the half-open connection with NSP:

VDLC: Req Open Stn Req PSap 0x7B68C0, port 0x7992A0      4000.1060.1000(04)->4000.05d2.0001(0C) 
VDLC: two-way connection established
VDLC: 4000.1060.1000(04)->4000.05d2.0001(0C): VDLC_IDLE->VDLC_OPEN

In the following messages, DLSw sends an XID response, and the NSP connection goes from the state XID Response Pending to Open. The XID exchange follows:

VDLC: CEP to CEP ID_RSP 4000.1060.1000(04)->4000.05d2.0001(0C) 
VDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_XID_RSP_PENDING->VDLC_OPEN
VDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_OPEN->VDLC_XID_RSP_PENDING
VDLC: CEP to CEP ID_REQ 4000.05d2.0001(0C)->4000.1060.1000(04) 
VDLC: CEP to CEP ID_RSP 4000.1060.1000(04)->4000.05d2.0001(0C) 
VDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_XID_RSP_PENDING->VDLC_OPEN
VDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_OPEN->VDLC_XID_RSP_PENDING
VDLC: CEP to CEP ID_REQ 4000.05d2.0001(0C)->4000.1060.1000(04) 
VDLC: CEP to CEP ID_RSP 4000.1060.1000(04)->4000.05d2.0001(0C) 
VDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_XID_RSP_PENDING->VDLC_OPEN
VDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_OPEN->VDLC_XID_RSP_PENDING
VDLC: CEP to CEP ID_REQ 4000.05d2.0001(0C)->4000.1060.1000(04) 
VDLC: CEP to CEP ID_RSP 4000.1060.1000(04)->4000.05d2.0001(0C) 
VDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_XID_RSP_PENDING->VDLC_OPEN
VDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_OPEN->VDLC_XID_RSP_PENDING
VDLC: CEP to CEP ID_REQ 4000.05d2.0001(0C)->4000.1060.1000(04) 

When DLSw is ready to connect, the front-end processor (FEP) sends a set asynchronous balanced mode extended (SABME) command as follows:

VDLC: CEP to CEP CONNECT_REQ 4000.1060.1000(04)->4000.05d2.0001(0C) 
VDLC: 4000.05d2.0001(0C)->4000.1060.1000(04): VDLC_XID_RSP_PENDING->VDLC_OPEN

In the following messages, NSP accepts the connection and sends an unnumbered acknowledgment (UA) to the FEP:

VDLC: CEP to CEP CONNECT_RSP 4000.05d2.0001(0C)->4000.1060.1000(04) 
VDLC: FlowReq QUENCH OFF 4000.1060.1000(04)->4000.05d2.0001(0C) 

The following messages show the data flow:

VDLC: DATA 4000.1060.1000(04)->4000.05d2.0001(0C) 
VDLC: DATA 4000.05d2.0001(0C)->4000.1060.1000(04) 
.
.
.
VDLC: DATA 4000.1060.1000(04)->4000.05d2.0001(0C) 
VDLC: DATA 4000.05d2.0001(0C)->4000.1060.1000(04) 

Examples

The following example shows the progress of an XML request that has been sent to Cisco Unified CallManager Express:

Router# debug cme-xml
*Aug 5 06:27:25.727: CME got a raw XML message.
*Aug 5 06:27:25.727: doc 0x63DB85E8, doc->doc_type 3, req 0x655FDCD0
*Aug 5 06:27:25.727: CME extracted a XML document
*Aug 5 06:27:25.727: Response buffer 0x63DCFD58, len = 4096
*Aug 5 06:27:25.727: First Tag ID SOAP_HEADER_TAG_ID 58720257
*Aug 5 06:27:25.727: First Attribute ID SOAP_ENV_ATTR 50331649
*Aug 5 06:27:25.727: cme_xml_process_soap_header
*Aug 5 06:27:25.727: cme_xml_process_soap_body
*Aug 5 06:27:25.731: cme_xml_process_axl
*Aug 5 06:27:25.731: cme_xml_process_request
*Aug 5 06:27:25.731: cme_xml_process_ISgetGlobal
*Aug 5 06:27:25.731: CME XML sent 811 bytes response.

Examples

In the following example, debugging messages are enabled for CNS configuration processes:

Router# debug cns config all

00:04:09: config_id_get: entered
00:04:09: config_id_get: Invoking cns_id_mode_get()
00:04:09: config_id_get: cns_id_mode_get() returned INTERNAL
00:04:09: config_id_get: successful exit cns_config_id=minna1,cns_config_id_len=6
00:04:09: cns_establish_connect_intf(): The device is already connected with the config server
00:04:09: cns_initial_config_agent(): connecting with port 80
00:04:09: pull_config() entered
00:04:09: cns_config_id(): returning config_id=minna1
00:04:09: Message finished 150 readend
00:04:09: %CNS-4-NOTE: SUCCESSFUL_COMPLETION
-Process= "CNS Initial Configuration Agent", ipl= 0, pid= 82
 00:04:10: %SYS-5-CONFIG_I: Configured from console by console

Examples

In the following example, debugging messages about all CNS Events are enabled:

Router# debug cns event all

00:09:14: %CNS-4-NOTE: SUCCESSFUL_COMPLETION
-Process= "CNS Initial Configuration Agent", ipl= 0, pid= 82
00:09:14: event_agent():event_agent starting ..
00:09:14: event_agent_open_connection(): attempting socket connect to Primary Gateway
00:09:14: event_agent_open_connection():cns_socket_connect() succeeded:return_code=0
00:09:14: event_agent_open_connection():timeout_len=1:ka_total_timeout =0:
                   total_timeout=0
00:09:14: event_id_get: entered
00:09:14: event_id_get: Invoking cns_id_mode_get()
00:09:14: event_id_get: cns_id_mode_get() returned INTERNAL
00:09:14: event_id_get: successful exit cns_event_id=test1, cns_event_id_len=5
00:09:14: ea_devid_send(): devid sent DUMP OF DEVID MSG
82C920A0:                   00120000 00010774          .......t
82C920B0: 65737431 00000402 020000             est1.......     
00:09:14: event_agent_get_input(): cli timeout=0: socket:0x0
00:09:14: process_all_event_agent_event_items():process_get_wakeup(&major, &minor)=TRUE: major=0
.
.
.
00:09:14: add_subjectANDhandle_to_subject_table():p_subject_entry=0x82E3EEDC: p_subject_entry_list=0x82619CD8
00:09:14: add_subjectANDhandle_to_subject_table():add 'user_entry' entry succeeded:
user entry =0x82C92AF4:queue_handle=0x82C913FC
00:09:14: %SYS-5-CONFIG_I: Configured from console by console

Examples

The following example shows a debugging message for the CNS exec agent when a response has been posted to HTTP:

Router# debug cns exec agent

4d20h: CNS exec agent: response posted

Examples

In the following example, debugging messages about SNMP- and XML-encapsulated CNS-management events are enabled:

Router# debug cns management snmp
Router# debug cns management xml
Router# show debugging 

CNS Management (SNMP Encapsulation) debugging is on
CNS Management (Encap XML) debugging is on
Router# show running-config | include cns 

cns mib-access encapsulation snmp
cns mib-access encapsulation xml
cns notifications encapsulation snmp
cns notifications encapsulation xml
cns event 10.1.1.1 11011
Router# 
00:12:50: Enqueued a notification in notif_q
00:12:50: ea_produce succeeded Subject:cisco.cns.mibaccess:notification Message Length:385 
00:12:50: Trap sent via CNS Transport Mapping.
Router# 
00:13:31: Response sent via CNS Transport Mapping.
Router# 
00:14:38: Received a request
00:14:38: ea_produce succeeded Subject:cisco.cns.mibaccess:response Message Length:241

Examples

In the following example, debugging messages for the CNS XML parser are enabled:

Router# debug cns xml parser
00:12:05: Registering tag <config-server>
00:12:05: Registering tag <server-info>
00:12:05: Registering tag <ip-address>
00:12:05: Registering tag <web-page>
00:12:05: Registering tag <config-event>
00:12:05: Registering tag <identifier>
00:12:05: Registering tag <config-id>
00:12:05: Registering tag <config-data>
00:12:05: Registering tag <cli>
00:12:05: Registering tag <error-info>
00:12:05: Registering tag <error-message>
00:12:05: Registering tag <line-number>
00:12:05: Registering tag <config-write>
00:12:05: Registering tag <exec-cmd-event>
00:12:05: Registering tag <identifier-exec>
00:12:05: Registering tag <event-response>
00:12:05: Registering tag <reply-subject>
00:12:05: Registering tag <server-response>
00:12:05: Registering tag <ip-address-exec>
00:12:05: Registering tag <port-number>
00:12:05: Registering tag <url>
00:12:05: Registering tag <cli-exec>
00:12:05: Registering tag <config-pwd>
00:12:06: Pushing tag <config-data> on to stack
00:12:06: open tag is <config-data>
00:12:06: Pushing tag <config-id> on to stack
00:12:06: open tag is <config-id>
00:12:06: Popping tag <config-id> off stack
00:12:06: close tag is </config-id>
00:12:06: Pushing tag <cli> on to stack
00:12:06: open tag is <cli>
00:12:06: Popping tag <cli> off stack
00:12:06: close tag is </cli>
00:12:06: Popping tag <config-data> off stack
00:12:06: close tag is </config-data>
00:12:06: %CNS-4-NOTE: SUCCESSFUL_COMPLETION
-Process= "CNS Initial Configuration Agent", ipl= 0, pid= 96

Examples

In the following example, debugging messages for the CNS XML parser are enabled:

Router# debug cns xml-parser

00:12:05: Registering tag <config-server>
00:12:05: Registering tag <server-info>
00:12:05: Registering tag <ip-address>
00:12:05: Registering tag <web-page>
00:12:05: Registering tag <config-event>
00:12:05: Registering tag <identifier>
00:12:05: Registering tag <config-id>
00:12:05: Registering tag <config-data>
00:12:05: Registering tag <cli>
00:12:05: Registering tag <error-info>
00:12:05: Registering tag <error-message>
00:12:05: Registering tag <line-number>
00:12:05: Registering tag <config-write>
00:12:05: Registering tag <exec-cmd-event>
00:12:05: Registering tag <identifier-exec>
00:12:05: Registering tag <event-response>
00:12:05: Registering tag <reply-subject>
00:12:05: Registering tag <server-response>
00:12:05: Registering tag <ip-address-exec>
00:12:05: Registering tag <port-number>
00:12:05: Registering tag <url>
00:12:05: Registering tag <cli-exec>
00:12:05: Registering tag <config-pwd>
00:12:06: Pushing tag <config-data> on to stack
00:12:06: open tag is <config-data>
00:12:06: Pushing tag <config-id> on to stack
00:12:06: open tag is <config-id>
00:12:06: Popping tag <config-id> off stack
00:12:06: close tag is </config-id>
00:12:06: Pushing tag <cli> on to stack
00:12:06: open tag is <cli>
00:12:06: Popping tag <cli> off stack
00:12:06: close tag is </cli>
00:12:06: Popping tag <config-data> off stack
00:12:06: close tag is </config-data>
00:12:06: %CNS-4-NOTE: SUCCESSFUL_COMPLETION
-Process= "CNS Initial Configuration Agent", ipl= 0, pid= 96

Examples

The following example is output from the debugcompress command, which shows that compression is taking place on a Cisco 2600 access router using data compression AIM hardware compression is configured correctly:

Router# debug compress
COMPRESS debugging is on
Router#compr-in:pak:0x810C6B10 npart:0 size:103
pak:0x810C6B10 start:0x02406BD4 size:103 npart:0
compr-out:pak:0x8118C8B8 stat:0x00000000 npart:1 size:71 lcb:0xED
pak:0x8118C8B8 start:0x0259CD3E size:71 npart:1
    mp:0x8118A980 start:0x0259CD3E size:71
decmp-in:pak:0x81128B78 start:0x0255AF44 size:42 npart:1 hdr:0xC035
pak:0x81128B78 start:0x0255AF44 size:42 npart:1
    mp:0x81174480 start:0x0255AF44 size:42
decmp-out:pak:0x8118C8B8 start:0x025B2C42 size:55 npart:1 stat:0
pak:0x8118C8B8 start:0x025B2C42 size:55 npart:1
    mp:0x8118B700 start:0x025B2C42 size:55

The table below describes the significant fields shown in the display.

Examples

Examples

In the following example, the router displays debugging messages only for interfaces that use a username of user1. The condition identifier displayed after the command is entered identifies this particular condition.

Router# debug condition username user1 
Condition 1 set

Examples

The following example specifies that the router should display debugging messages only for VC 1000:

Router# debug condition vcid 1000 
Condition 1 set
01:12:32: 1000 Debug: Condition 1, vcid 1000 triggered, count 1
01:12:32: 1000 Debug: Condition 1, vcid 1000 triggered, count 1

The following example enables other debugging commands. These debugging commands will only display information for VC 1000.

Router# debug mpls l2transport vc event
 
AToM vc event debugging is on

Router# debug mpls l2transport vc fsm
 
AToM vc fsm debugging is on

The following commands shut down the interface on which VC 1000 is established:

Router(config)# interface serial3/1/0
Router(config-if)# shut 

The debugging output shows the change to the interface where VC 1000 is established:

01:15:59: AToM MGR [13.13.13.13, 1000]: Event local down, state changed from established to remote ready 
01:15:59: AToM MGR [13.13.13.13, 1000]: Local end down, vc is down 
01:15:59: AToM SMGR [13.13.13.13, 1000]: Processing imposition update, vc_handle 6227BCF0, update_action 0, remote_vc_label 18 
01:15:59: AToM SMGR [13.13.13.13, 1000]: Imposition Disabled 
01:15:59: AToM SMGR [13.13.13.13, 1000]: Processing disposition update, vc_handle 6227BCF0, update_action 0, local_vc_label 755 
01:16:01:%LINK-5-CHANGED: Interface Serial3/1/0, changed state to administratively down
01:16:02:%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial3/1/0, changed state to down

Examples

The following example disables debugging output for all applications except the myapp1 application, if the <cisco-debug> element is enabled in the VoiceXML documents that are executed by myapp1:

Router# debug condition application voice myapp1

Examples

The following is sample output from the debugconditionglbpcommand:

Router# debug condition glbp fastethernet 0/0 10 1
Condition 1 set
5d23h: Fa0/0 GLBP10.1 Debug: Condition 1, glbp Fa0/0 GLBP10.1 triggered, count 1

Examples

In the following example, only debug command output related to serial interface 1 is displayed. The condition identifier for this command is 1.

Router# debug condition interface serial 1
Condition 1 set

The following example shows how to enable an ATM interface, specifies an IP address for the interface, turns on conditional debugging for that interface with a VPI/VCI pair of 255/62610, and verifies that debugging has been enabled:

Router> enable
Password: 
Router# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# interface atm 2/0
Router(config-if)# ip address 209.165.201.2 255.255.255.0
Router(config-if)# pvc 255/62610
Router(config-if-atm-vc)# no shutdown
Router(config-if)# exit
Router(config)# exit
2w3d: %SYS-5-CONFIG_I: Configured from console by console
Router# debug condition interface atm 2/0 vc 255/62610
Condition 1 set
2w3d: ATM VC Debug: Condition 1, atm-vc 255/62610 AT2/0 triggered, count 1
Router# show debug condition
Condition 1: atm-vc 255/62610 AT2/0 (1 flags triggered)
        Flags: ATM VC

The following example shows how to enable Frame Relay conditional debugging on Frame Relay DLCI 105:

Router# debug condition interface serial 4/3 dlci 105
Router# debug frame-relay packet

The following example shows how to disable the conditional debugging on VC. A warning message is displayed when the last condition is removed.

Router> enable
Router# no debug condition interface atm 1/0 vc 4335
This condition is the last interface condition set.
Removing all conditions may 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

Examples

In this output example, the following configuration was used:

call filter match-list 1 voice
 incoming calling-number 8288807
 incoming called-number 6560729
 incoming port 7/0:D

The following is sample output for the debugconditionmatch-list1 command. The next several lines match the above conditions.

Router# debug condition match-list 1
07:22:19://-1/3C0B9468-15C8-11D4-8013-000A8A389BA8/VTSP:(7/0:D):0:0:0/vtsp_gcfm_incoming_cond_notify: add incoming port cond success: 7/0:D
07:22:19://-1/3C0B9468-15C8-11D4-8013-000A8A389BA8/VTSP:(7/0:D):0:0:0/vtsp_gcfm_incoming_cond_notify: add incoming dialpeer tag success:1
07:22:19://-1/3C0B9468-15C8-11D4-8013-000A8A389BA8/VTSP:(7/0:D):0:0:0/vtsp_update_dsm_stream_mgr_filter_flag: cannot find dsp_stream_mgr_t
07:22:19://-1/3C0B9468-15C8-11D4-8013-000A8A389BA8/VTSP:(7/0:D):0:0:0/vtsp_update_dsm_stream_mgr_filter_flag: update dsp_stream_mgr_t  debug flag
07:22:19: //49/3C0B9468-15C8-11D4-8013-000A8A389BA8/VTSP:(7/0:D):0:0:0/vtsp_insert_cdb: ,cdb 0x6482C518, CallID=49
07:22:19://49/3C0B9468-15C8-11D4-8013-000A8A389BA8/VTSP:(7/0:D):0:0:0/vtsp_do_call_setup_ind: Call ID=98357, guid=3C0B9468-15C8-11D4-8013-000A8A389BA8

The table below describes the significant fields shown in the display.

Examples

In the following example, the router displays debugging messages only for Ethernet interface 0/0 that are part of HSRP group 23:

Router# debug standby
HSRP debugging is on
Router# debug condition standby ethernet0/0 23
Condition 1 set
00:27:39: HSRP: Et0/0 Grp 23 Hello  out 10.0.0.1 Active  pri 100 vIP 172.16.6.5
00:27:42: HSRP: Et0/0 Grp 23 Hello  out 10.0.0.1 Active  pri 100 vIP 172.16.6.5
00:27:45: HSRP: Et0/0 Grp 23 Hello  out 10.0.0.1 Active  pri 100 vIP 172.16.6.5
00:27:48: HSRP: Et0/0 Grp 23 Hello  out 10.0.0.1 Active  pri 100 vIP 172.16.6.5
00:27:51: HSRP: Et0/0 Grp 23 Hello  out 10.0.0.1 Active  pri 100 vIP 172.16.6.5

The following example shows how to remove an HSRP debug condition:

Router# no debug condition standby ethernet0/0 23
This condition is the last hsrp condition set.
Removing all conditions may 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.

Examples

The following example filters debugging output so that output only for ports 2/1 and 2/3 is displayed:

Router# debug condition voice-port 2/1
Condition 1 set
*Mar  1 22:24:15.102:  Debug: Condition 1, voice-port 2/1 triggered, count 1
Router# debug condition voice-port 2/3
Condition 2 set
*Mar  1 22:24:24.794:  Debug: Condition 2, voice-port 2/3 triggered, count 2
Router# show debug
Condition 1: voice-port 2/1 (1 flags triggered)
        Flags: voice-port condition
Condition 2: voice-port 2/3 (1 flags triggered)
        Flags: voice-port condition

Examples

The following example shows how to limit debugging output to VRF red:

Router# debug condition vrf red

Examples

The following example sets filter conditions that allow related debug commands to display debug messages for only the xconnect segment pair specified by the remote peer IP address and the pseudowire VCID:

debug condition xconnect peer 10.0.0.1 vcid 100

The following example sets filter conditions that allow related debug commands to display debug messages for only the xconnect segment pair specified by the serial interface number and DLCI:

debug condition xconnect interface serial 0/0 100 

The following example sets filter conditions that allow related debug commands to display debug messages for only the xconnect segment pair specified by the port mode ATM interface number:

debug condition xconnect interface atm 0/0

The following example sets filter conditions that allow related debug commands to display debug messages for only the xconnect segment pair specified by the VP mode ATM interface number:

debug condition xconnect interface atm 0/0 vp 1

The following example sets filter conditions that allow related debug commands to display debug messages for only the xconnect segment pair specified by the VC mode ATM interface number:

debug condition xconnect interface atm 0/0 vc 1/40

The following example finds the segment ID associated with an L2TPv3 xconnect segment pair and sets filter conditions that allow related debug commands to display debug messages for only that xconnect segment pair:

Router# show ssm id
!
Segment-ID: 8193 Type: L2TPv3[8]
!
Router# debug conditional xconnect segment 8193

Examples

The following is sample output with debugconfigurationlock enabled (assuming that the feature is enabled using the configurationmodeexclusivemanual command in global configuration mode):

Router# debug configuration lock
Session1 from console
==========================
Router# configure terminal lock 
Configuration mode locked exclusively. The lock will be cleared once you exit out of configuration mode using end/exit
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#
Parser : LOCK REQUEST in EXCLUSIVE mode
Parser: <configure terminal lock> - Config. Lock requested by process <3> client <PARSER Client>
Parser: <configure terminal lock> - Config. Lock acquired successfully !
Router(config)#
Session2 VTY (User from session2 is trying to enter single user config (exclusive) config mode)
=================================
Router# c
onfigure terminal lock
 
Configuration mode locked exclusively by user 'unknown' process '3' from terminal '0'. Please try later.
Router#
Session1 from console
=======================
Router(config)#
Parser : LOCK REQUEST in EXCLUSIVE mode
Parser: <configure terminal lock> - Config. Lock requested by process <104> client <PARSER Client>
Parser: <configure terminal lock> - NON_BLOCKING : Config mode locked <EXCLUSIVE> owner <3>
Router(config)#
Router(config)# end
Router#
%SYS-5-CONFIG_I: Configured from console by console
Parser: <Configure terminal> - Config. EXC UnLock requested by user<3>
Parser: <Configure terminal> - Config UNLOCKED !
Router#

Examples

The following is sample output from thedebugconfmodemcommand. In the first three lines, the router is searching for a speed at which it can communicate with the modem. The remaining lines show the actual sending of the modem command.

Router# debug confmodem
TTY4:detection speed(115200) response ------
TTY4:detection speed(57600) response ------
TTY4:detection speed(38400) response ---OK---
TTY4:Modem command: --AT&F&C1&D2S180=3S190=1S0=1--
TTY4: Modem configuration succeeded
TTY4: Done with modem configuration

Examples

The following example shows connection manager debugging output:

Router# debug conn
Connection Manager debugging is on
Router# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# connect conn1 t1 3/0 1 t1 4/0 1
  
 
Router(config-tdm-conn)# exit
*Mar  6 18:30:59:%CONN TDM:Segment attached to dsx1
*Mar  6 18:30:59:%CONN TDM:Parsed segment 1
*Mar  6 18:30:59:%CONN TDM:Segment attached to dsx1
*Mar  6 18:30:59:%CONN TDM:Parsed segment 2
*Mar  6 18:30:59:%CONN:Creating new connection
Router(config)#
*Mar  6 18:31:01:%CONN TDM:Interwork Segments
*Mar  6 18:31:01:CONN TDM:Init Segment @ 61C26980
*Mar  6 18:31:01:CONN TDM:Init Segment @ 61C26A44
*Mar  6 18:31:01:%CONN TDM:Activating Segment @ 61C26980
*Mar  6 18:31:01:%CONN:Segment alarms for conn conn1 are 2
*Mar  6 18:31:01:%CONN TDM:Activating Segment @ 61C26A44
*Mar  6 18:31:01:%CONN:Segment alarms for conn conn1 are 0
*Mar  6 18:31:01:%CONN TDM:Connecting Segments
*Mar  6 18:31:01:%CONN TDM:MAKING CONNECTION
*Mar  6 18:31:01:%CONN:cm_activate_connection, stat = 5
Router(config)#

Examples

The following example shows how to enable extended ACL 149 and the debugging of content scan ACL 149:

Device(config)# ip access-list extended 149
Device(config-ext-nacl)# permit ip host 10.1.0.1
Device(config-ext-nacl)# end
Device# debug content-scan access-list 149
 Content-scan ACL based conditional debugging is on

The following is sample output from the debug content-scan access-list 149 command:

Device# debug content-scan access-list 149

Content-scan ACL based conditional debugging is on

Feb 19 19:01:02.887: CONT-SCAN-PAK-PATH:Checking if it's a web trafficSrc IP:10.1.0.1(3646), Dst IP: 198.51.100.195(80),index:4
Feb 19 19:01:02.887: 
Feb 19 19:01:02.887: CONT-SCAN-PAK-PATH: Populating user/usergroup infoSrc IP:10.1.0.1(3646), Dst IP: 198.51.100.195(80)
Feb 19 19:01:02.887: CONT-SCAN-EVE:Username Received: defpmuser Src IP:10.1.0.1(E3E) Dst IP: 198.51.100.195(50) Pak:2033BCA0
Feb 19 19:01:02.887: CONT-SCAN-EVE:Usergroup from pmap Src IP:10.1.0.1(E3E) Dst IP: 198.51.100.195(50) Pak:2033BCA0
Feb 19 19:01:02.887: CONT-SCAN-PAK-PATH:Protocol not configuredSrc IP:10.1.0.1(3646), Dst IP: 198.51.100.195(80)
Feb 19 19:01:02.887: CONT-SCAN-PAK-PATH:Adding session into HashSrc IP:10.1.0.1(3646), Dst IP: 198.51.100.195(80)
Feb 19 19:01:02.887: CONT-SCAN-PAK-PATH:Free port equals source port for src_ip 10.1.0.1(3646) dst_ip 198.51.100.195(80) 2033BCA0
Feb 19 19:01:02.887: CONT-SCAN-PAK-PATH:session enqueued 21ED1DE0 for src_ip 10.1.0.1(3646) dst_ip 198.51.100.195(80)
Feb 19 19:01:02.887: CONT-SCAN-PAK-PATH:Inserting Ingress session 21ED1DE0 in hash table at 1646 Src IP:10.1.0.1(3646), Dst IP: 198.51.100.195(80)
Feb 19 19:01:02.887: CONT-SCAN-PAK-PATH:Inserting Egress session 21ED1DE0 in hash table at 1629 Src IP:10.1.0.1(3646), Dst IP: 198.51.100.195(80)
Feb 19 19:01:02.887: CONT-SCAN-PAK-PATH:timer wheel started for 21ED1DE0 for src_ip 10.1.0.1(3646)
Feb 19 19:01:02.887: CONT-SCAN-EVE:1 Usergroups from auth proxy Src IP:10.1.0.1(E3E), Dst IP: 198.51.100.195(50), cs_entry:21ED1DE0
Feb 19 19:01:02.887: CONT-SCAN-PAK-PATH:conx 21EE2024 ingress_fd 1073741847
Feb 19 19:01:02.887: CONT-SCAN-PAK-PATH:CONT SCAN: received fd1: 1073741847 and tcp flags = 0x2, payload_len = 0
Feb 19 19:01:02.887: CONT-SCAN-EVE:1 Usergroups found Src IP:10.1.0.1(E3E), Dst IP: 198.51.100.195(50), cs_entry:21ED1DE0 
!
!
!

Examples

The following example show a display from the debugcontrol-plane command:

Router# debug control-plane 
Control-plane infrastructure events debugging is on
Router# cp_receive_classify - marking pak host
 ingress pak marked cef-exception

The following example shows a display from the debugcontrol-plane command using the port-filtering option:

Router# debug control-plane port-filtering
 
TCP/IP Port filtering events debugging is on
Dropped UDP dport 1243 sport 62134 saddr 209.165.200.225 

The table below describes the significant fields shown in the display.

Examples

This first example displays the one-line COPS message summaries, as the router goes through six different events.

Router# debug cops
COPS debugging is on

Examples

The router becomes configured to communicate with a policy server:

Router# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)# ip rsvp policy cops servers 2.0.0.1
Router(config)#
15:13:45:COPS: Opened TCP connection to 2.0.0.1/3288
15:13:45:COPS: ** SENDING MESSAGE ** 
15:13:45:COPS OPN message, Client-type:1, Length:28. Handle:[NONE]
15:13:45:COPS: ** RECEIVED MESSAGE ** 
15:13:45:COPS CAT message, Client-type:1, Length:16. Handle:[NONE]
Router(config)#

Examples

The router receives a Path message:

15:13:53:COPS:** SENDING MESSAGE ** 
15:13:53:COPS REQ message, Client-type:1, Length:216. Handle:[ 00 00 04 01]
15:13:53:COPS:** RECEIVED MESSAGE ** 
15:13:53:COPS DEC message, Client-type:1, Length:104. Handle:[ 00 00 04 01]
Router(config)#

Examples

The router receives a unicast FF Resv message:

15:14:00:COPS:** SENDING MESSAGE ** 
15:14:00:COPS REQ message, Client-type:1, Length:148. Handle:[ 00 00 05 01]
15:14:00:COPS:** RECEIVED MESSAGE ** 
15:14:00:COPS DEC message, Client-type:1, Length:64. Handle:[ 00 00 05 01]
15:14:00:COPS:** SENDING MESSAGE ** 
15:14:00:COPS RPT message, Client-type:1, Length:24. Handle:[ 00 00 05 01]
Router(config)#

Examples

The router receives a Resv tear:

15:14:06:COPS:** SENDING MESSAGE ** 
15:14:06:COPS DRQ message, Client-type:1, Length:24. Handle:[ 00 00 05 01]
Router(config)#

Examples

The router receives a Path tear:

15:14:11:COPS:** SENDING MESSAGE ** 
15:14:11:COPS DRQ message, Client-type:1, Length:24. Handle:[ 00 00 04 01]
Router(config)#

Examples

The router gets configured to cease communicating with the policy server:

Router(config)# no ip rsvp policy cops servers
15:14:23:COPS:** SENDING MESSAGE ** 
15:14:23:COPS CC message, Client-type:1, Length:16. Handle:[NONE]
15:14:23:COPS:Closed TCP connection to 2.0.0.1/3288
Router(config)#

This second example uses the detail keyword to display the contents of the COPS and RSVP messages, and additional debugging information:

Router# debug cops detail
COPS debugging is on
02:13:29:COPS:** SENDING MESSAGE ** 
    COPS HEADER:Version 1, Flags 0, Opcode 1 (REQ), Client-type:1, Length:216
    HANDLE (1/1) object. Length:8.    00 00 21 01
    CONTEXT (2/1) object. Length:8.   R-type:5.     M-type:1
    IN_IF (3/1) object. Length:12.   Address:10.1.2.1.    If_index:4
    OUT_IF (4/1) object. Length:12.   Address:10.33.0.1.    If_index:3
    CLIENT SI (9/1) object. Length:168.   CSI data:
02:13:29: SESSION              type 1 length 12:
02:13:29:      Destination 10.33.0.1, Protocol_Id 17, Don't Police , DstPort 44
02:13:29: HOP                  type 1 length 12:0A010201
02:13:29:                                       :00000000
02:13:29: TIME_VALUES          type 1 length 8 :00007530
02:13:29: SENDER_TEMPLATE      type 1 length 12:
02:13:29:      Source 10.31.0.1, udp_source_port 44
02:13:29: SENDER_TSPEC         type 2 length 36:
02:13:29:      version=0, length in words=7
02:13:29:      Token bucket fragment (service_id=1, length=6 words
02:13:29:          parameter id=127, flags=0, parameter length=5
02:13:29:          average rate=1250 bytes/sec, burst depth=10000 bytes
02:13:29:          peak rate   =1250000 bytes/sec
02:13:29:          min unit=0 bytes, max unit=1514 bytes
02:13:29: ADSPEC               type 2 length 84:
02:13:29: version=0  length in words=19
02:13:29: General Parameters  break bit=0  service length=8
02:13:29:                                            IS Hops:1
02:13:29:                 Minimum Path Bandwidth (bytes/sec):1250000
02:13:29:                        Path Latency (microseconds):0
02:13:29:                                           Path MTU:1500
02:13:29: Guaranteed Service  break bit=0  service length=8
02:13:29:                          Path Delay (microseconds):192000
02:13:29:                         Path Jitter (microseconds):1200
02:13:29:            Path delay since shaping (microseconds):192000
02:13:29:           Path Jitter since shaping (microseconds):1200
02:13:29: Controlled Load Service  break bit=0  service length=0
02:13:29:COPS:Sent 216 bytes on socket, 
02:13:29:COPS:Message event!
02:13:29:COPS:State of TCP is 4
02:13:29:In read function
02:13:29:COPS:Read block of 96 bytes, num=104 (len=104)
02:13:29:COPS:** RECEIVED MESSAGE ** 
    COPS HEADER:Version 1, Flags 1, Opcode 2 (DEC), Client-type:1, Length:104
    HANDLE (1/1) object. Length:8.    00 00 21 01
    CONTEXT (2/1) object. Length:8.   R-type:1.     M-type:1
    DECISION (6/1) object. Length:8.   COMMAND cmd:1, flags:0
    DECISION (6/3) object. Length:56.   REPLACEMENT  00 10 0E 01 61 62 63 64 65 66 67
68 69 6A 6B 6C 00 24 0C 02 00
00 00 07 01 00 00 06 7F 00 00 05 44 9C 40 00 46 1C 40 00 49 98
96 80 00 00 00 C8 00 00 01 C8
    CONTEXT (2/1) object. Length:8.   R-type:4.     M-type:1
    DECISION (6/1) object. Length:8.   COMMAND cmd:1, flags:0
02:13:29:Notifying client (callback code 2)
02:13:29:COPS:** SENDING MESSAGE ** 
    COPS HEADER:Version 1, Flags 1, Opcode 3 (RPT), Client-type:1, Length:24
    HANDLE (1/1) object. Length:8.    00 00 21 01
    REPORT (12/1) object. Length:8.   REPORT type COMMIT (1)
02:13:29:COPS:Sent 24 bytes on socket, 
02:13:29:Timer for connection entry is zero

To see an example where the debugcops command is used along with the debugiprsvppolicy command, refer to the second example of the debugiprsvppolicy command.

Examples

The following is sample output from the debugcotapi command:

Router# debug cot api
COT API debugging is on
08:29:55: cot_request_handler(): CDB@0x60DEDE14, req(COT_CHECK_TONE_ON):
08:29:55:     shelf 0 slot 0 appl_no 1 ds0 1
08:29:55:     freqTX 2010 freqRX 1780 key 0xFFF1 duration 60000

The table below describes the significant fields shown in the display.

The following is sample output from the debugcotdsp command:

Router# debug cot dsp
Router#
00:10:42:COT:DSP (1/1) Allocated
00:10:43:In cot_callback
00:10:43:  returned key 0xFFF1, status = 0
00:10:43:COT:Received DSP Q Event
00:10:43:COT:DSP (1/1) Done
00:10:43:COT:DSP (1/1) De-allocated

The table below describes the significant fields shown in the display.

The following is sample output from the debugcotqueue command:

Router# debug cot queue
Router#
00:11:26:COT(0x60EBB48C):Adding new request (0x61123DBC) to In
Progress Q
00:11:26:COT(0x60EBB48C):Adding COT(0x61123DBC) to the Q head
00:11:27:In cot_callback
00:11:27:  returned key 0xFFF1, status = 0

The table below describes the significant fields shown in the display.

The following is sample output from the debugcotdetail command.

Router# debug cot detail
Router#
00:04:57:cot_request_handler():CDB@0x60EBB48C, req(COT_CHECK_TONE_ON):
00:04:57:    shelf 0 slot 0 appl_no 1 ds0 1
00:04:57:    freqTX 1780 freqRX 2010 key 0xFFF1 duration 1000
00:04:57:COT:DSP (1/0) Allocated
00:04:57:COT:Request Transition to COT_WAIT_TD_ON
00:04:57:COT(0x60EBB48C):Adding new request (0x61123DBC) to In
Progress Q
00:04:57:COT(0x60EBB48C):Adding COT(0x61123DBC) to the Q head
00:04:57:COT:Start Duration Timer for Check Tone Request
00:04:58:COT:Received Timer Event
00:04:58:COT:T24 Timer Expired
00:04:58:COT Request@ 0x61123DBC, CDB@ 0x60EBB48C, Params@0x61123E08
00:04:58:  request type = COT_CHECK_TONE_ON
00:04:58:  shelf 0 slot 0 appl_no 1 ds0 1
00:04:58:  duration 1000 key FFF1 freqTx 1780 freqRx 2010
00:04:58:  state COT_WAIT_TD_ON_CT
00:04:58:  event_proc(0x6093B55C)
00:04:58:Invoke NI2 callback to inform COT request status
00:04:58:In cot_callback
00:04:58:  returned key 0xFFF1, status = 0
00:04:58:Return from NI2 callback
00:04:58:COT:Request Transition to IDLE
00:04:58:COT:Received DSP Q Event
00:04:58:COT:DSP (1/0) Done
00:04:58:COT:DSP (1/0) De-allocated

Because the debugcotdetailcommand is a summary of the debugcotapi, debugcotdsp, and debugcotqueuecommands, the field descriptions are the same.

Examples

One or more of the messages in the table below appear when you use thedebugcppevent command. Each message begins with the short name of the interface the event occurred on (for example, SERIAL0:1 or BRI0:1) and might contain one or more packet sequence numbers or remote site names.

Examples

The following is sample output from the debugcppnegotiation command. In this example, a sample connection is shown.

Router# debug cpp negotiation
%LINK-3-UPDOWN: Interface BRI0: B-Channel 2, changed state to down
%LINK-3-UPDOWN: Interface BRI0, changed state to up
%SYS-5-CONFIG_I: Configured from console by console
%LINK-3-UPDOWN: Interface BRI0: B-Channel 1, changed state to up
BR0:1:(I) NEG packet - len 77
   attempting proto:2
   ether id:0040.f902.c7b4
   port 1 number:5559876
   port 2 number:5559876
   origination port:1
   remote name:berl9
   password is correct

The table below describes the significant fields in the display.

Examples

The following is sample output from the debugcpppacket command. This example shows the interface name, packet type, packet size, and the hexadecimal values of the packet.

Router# debug cpp packet
BR0:1:input packet - len 60
00 00 00 00 00 00 00 40 F9 02 C7 B4 08 0.!6 00 01 
08 00 06 04 00 02 00 40 F9 02 C7 B4 83 6C A1 02!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 64/66/68 ms
BR0:1 output packet - len 116
06 00 00 40 F9 02 C7 B4 00 00 0C 3E 12 3A 08 00 
45 00 00 64 00 01 00 00 FF 01 72 BB 83 6C A1 01 

Examples

The following is sample output showing the credentials service that runs between the Cisco Unified SRST router and Cisco CallManager. The credentials service provides Cisco CallManager with the certificate from the Cisco Unified SRST router.

Router# debug credentials
Credentials server debugging is enabled
Router# 
May 25 12:08:17.944: Credentials service: Start TLS Handshake 1 10.5.43.174 4374
May 25 12:08:17.948: Credentials service: TLS Handshake returns OPSSLReadWouldBlockErr
May 25 12:08:18.948: Credentials service: TLS Handshake returns OPSSLReadWouldBlockErr
May 25 12:08:19.948: Credentials service: TLS Handshake returns OPSSLReadWouldBlockErr
May 25 12:08:20.964: Credentials service: TLS Handshake completes

The table below describes the significant fields shown in the display.

Examples

The following is sample output from the debugcrmall command for an incoming ISDN call on a trunk group:

Router# debug crm all
 
01:21:23: //-1/xxxxxxxxxxxx/CRM/crm_send_periodic_update: 
01:21:23: //-1/xxxxxxxxxxxx/CRM/print_event: 
    RouteLabel=2023, CarrierType=TDM, EventType=Single RouteLabel Update, EventReason=Both Capacity Update,
    Max Capacity mask 0x0000001F, Current Capacity Mask 0x0000001F
01:21:23: //-1/xxxxxxxxxxxx/CRM/crm_call_update: 
    Increment the call count
    CarrierID=2023, TrunkGroupLabel=2023
    Update is for TrunkGroupLabel, Mask=0x00000001
01:21:23: //-1/xxxxxxxxxxxx/CRM/crm_call_update: 
    IncomingVoiceCalls=1
Router#
01:21:48: //-1/xxxxxxxxxxxx/CRM/crm_send_periodic_update: 
01:21:48: //-1/xxxxxxxxxxxx/CRM/print_event: 
    RouteLabel=2023, CarrierType=TDM, EventType=Single RouteLabel Update, EventReason=Both Capacity Update,
    Max Capacity mask 0x0000001F, Current Capacity Mask 0x0000001F
01:22:13: //-1/xxxxxxxxxxxx/CRM/crm_send_periodic_update: 
01:22:13: //-1/xxxxxxxxxxxx/CRM/print_event: 
    RouteLabel=2023, CarrierType=TDM, EventType=Single RouteLabel Update, EventReason=Both Capacity Update,
    Max Capacity mask 0x0000001F, Current Capacity Mask 0x0000001F
Router#
01:22:18: //-1/xxxxxxxxxxxx/CRM/crm_call_update: 
    Decrement the call count
    CarrierID=2023, TrunkGroupLabel=2023
    Update is for TrunkGroupLabel, Mask=0x00000001
01:22:18: //-1/xxxxxxxxxxxx/CRM/crm_call_update: 
    IncomingVoiceCalls=0

The table below describes the significant fields shown in the display.

Examples

The following example enables IPSec VPN SPA debugging for a Blade Failure Group:

Router# debug crypto ace b2b
ACE B2B Failover debugging is on

Examples

The following example enables ACE boot API debugging:

Router# debug crypto ace boot
ACE Boot debugging is on

Examples

The following example enables ACE CFGMON transaction debugging:

Router# debug crypto ace cfgmon
ACE CFGMON Transactions debugging is on

Examples

The following example enables ACE Crypto engine congestion manager debugging:

Router# debug crypto ace congestion-mgr
ACE Crypto Engine Congestion Manager debugging is on

Examples

The following example enables ACE DPD debugging:

Router# debug crypto ace dpd
ACE-DPD debugging is on

Examples

The following example enables error log debugging:

Router# debug crypto ace error
ACE Error logging debugging is on

Examples

The following example enables ACE HAPI transaction debugging:

Router# debug crypto ace hapi
ACE HAPI transactions debugging is on

Examples

The following example enables ACE IKEA transaction debugging:

Router# debug crypto ace ikea
ACE IKEA transactions debugging is on

Examples

The following example enables ACE invalid SPI debugging:

Router# debug crypto ace invspi
ACE Invalid SPI debugging is on

Examples

The following example enables ACE IPD debugging:

Router# debug crypto ace ipd
ACE IPD debugging is on

Examples

The following example enables multi-ACE debugging:

Router# debug crypto ace mace
MULTI-ACE messages debugging is on

Examples

The following example enables ACE PCP transactions debugging:

Router# debug crypto ace pcp
ACE PCP Transactions debugging is on

Examples

The following example enables ACE policy loader debugging:

Router# debug crypto ace polo
ACE Policy Loader debugging is on

Examples

The following example enables ACE propagate configuration debugging:

Router# debug crypto ace propcfg
ACE Propagate Config debugging is on

Examples

The following example enables ACE QoS debugging:

Router# debug crypto ace qos
ACE QoS debugging is on

Examples

The following example enables ACE RCON messages debugging:

Router# debug crypto ace rcon
ACE RCON messages debugging is on

Examples

The following example enables ACE HA debugging:

Router# debug crypto ace redundancy
ACE HA debugging is on

Examples

The following example enables ACE SPI debugging:

Router# debug crypto ace spi
ACE SPI debugging is on

Examples

The following example enables ACE stats module debugging:

Router# debug crypto ace stats
ACE Stats Module debugging is on

Examples

The following example enables ACE syslog messages debugging:

Router# debug crypto ace syslog
ACE Syslog messages debugging is on

Examples

The following example enables ACE TFTP boot debugging:

Router# debug crypto ace tftp
ACE TFTP Boot debugging is on

Examples

The following example enables ACE-TOPN-HELPER debugging:

Router# debug crypto ace topn
ACE-TOPN-HELPER debugging is on

Examples

The following example enables ACE warning log debugging:

Router# debug crypto ace warning 
ACE Warning logging debugging is on

Examples

The following example shows how to enable debug messages for all crypto-related areas:

Router# debug crypto condition unmatched