|
|
Table Of Contents
debug crypto pki server
To enable debugging for a crypto public key infrastructure (PKI) certificate server, use the debug crypto pki server command in privileged EXEC mode. To disable debugging, use the no form of this command.
debug crypto pki server
no debug crypto pki server
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Examples
The following example shows how to enable debugging for a certificate server. This example also contains sample debug messages, which allow users to troubleshoot the various certificate-request-related stages and tasks that are handled by the certificate server.
Router# debug crypto pki serverCrypto PKI Certificate Server debugging is onOct 15 19:50:41.003:CRYPTO_CS:old RA cert flag 0x4Oct 15 19:50:41.003:CRYPTO_CS:new RA cert flag 0x1000COct 15 19:50:41.003:CRYPTO_CS:nvram filesystemOct 15 19:50:41.279:CRYPTO_CS:serial number 0x1 written.Oct 15 19:50:53.383:CRYPTO_CS:created a new serial file.Oct 15 19:50:53.383:CRYPTO_CS:SCEP server startedOct 15 19:50:53.419:%SYS-5-CONFIG_I:Configured from console by consoleOct 15 19:50:53.731:CRYPTO_CS:received a SCEP GetCACert requestOct 15 19:50:53.739:CRYPTO_CS:CA certificate sentOct 15 19:50:54.355:CRYPTO_CS:received a SCEP GetCACert requestOct 15 19:50:54.363:CRYPTO_CS:CA certificate sentOct 15 19:50:57.791:CRYPTO_CS:received a SCEP requestOct 15 19:50:57.795:CRYPTO_CS:read SCEP:registered and bound serviceSCEP_READ_DB_8Oct 15 19:50:57.947:CRYPTO_CS:scep msg type - 19Oct 15 19:50:57.947:CRYPTO_CS:trans id -3673CE2FF0235A4AE6F26242B00A4BB4Oct 15 19:50:58.679:CRYPTO_CS:read SCEP:unregistered and unboundservice SCEP_READ_DB_8Oct 15 19:50:58.683:CRYPTO_CS:received an enrollment requestOct 15 19:50:58.691:CRYPTO_CS:request has been authorized, transactionid=3673CE2FF0235A4AE6F26242B00A4BB4Oct 15 19:50:58.699:CRYPTO_CS:byte 2 in key usage in PKCS#10 is 0x7Oct 15 19:50:58.699:CRYPTO_CS:signatureOct 15 19:50:58.699:CRYPTO_CS:key_usage is 1Oct 15 19:50:58.703:CRYPTO_CS:enrollment request with pendingID 1 sentto the CAOct 15 19:50:58.707:CRYPTO_CS:write SCEP:registered and bound serviceSCEP_WRTE_DB_8Oct 15 19:50:59.531:CRYPTO_CS:write SCEP:unregistered and unboundservice SCEP_WRTE_DB_8.....Oct 15 19:53:08.403:CRYPTO_CS:CS_RA_REQUEST:save cert in dbase,pending id = 2Oct 15 19:53:08.403:CRYPTO_CS:enrollment request 2 grantedOct 15 19:53:08.403:CRYPTO_PKI:All enrollment requests completed fortrustpoint ra.Oct 15 19:53:08.403:%CRYPTO-6-CERTRET:Certificate received fromCertificate AuthorityOct 15 19:53:08.403:CRYPTO_PKI:All enrollment requests completed fortrustpoint ra.Oct 15 19:53:08.403:CRYPTO_PKI:All enrollment requests completed fortrustpoint ra.Oct 15 19:53:08.407:CRYPTO_PKI:All enrollment requests completed fortrustpoint ra.Oct 15 19:53:19.623:IPSEC(key_engine):major = 1Oct 15 19:53:19.623:IPSEC(key_engine):expired_timer:skip ...Oct 15 19:53:35.707:CRYPTO_CS:received a SCEP requestOct 15 19:53:35.711:CRYPTO_CS:read SCEP:registered and bound serviceSCEP_READ_DB_14Oct 15 19:53:35.859:CRYPTO_CS:scep msg type - 20Oct 15 19:53:35.859:CRYPTO_CS:trans id -4D774FFE2F7CA9991A7F6A785E803E77Oct 15 19:53:36.591:CRYPTO_CS:read SCEP:unregistered and unboundservice SCEP_READ_DB_14Oct 15 19:53:36.595:CRYPTO_CS:received an enrollment requestOct 15 19:53:36.595:CRYPTO_CS:write SCEP:registered and bound serviceSCEP_WRTE_DB_14Oct 15 19:53:37.623:CRYPTO_CS:write SCEP:unregistered and unboundservice SCEP_WRTE_DB_14Oct 15 19:53:37.631:CRYPTO_CS:Certificate sent to requestorRelated Commands
crypto pki server
Enables a Cisco IOS certificate server and enters certificate server configuration mode.
debug crypto pki transactions
To display debugging messages for the trace of interaction (message type) between the certification authority (CA) and the router, use the debug crypto pki transactions command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug crypto pki transactions
no debug crypto pki transactions
Syntax Description
This command has no arguments or keywords.
Defaults
Disabled
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the debug crypto pki transactions command to display debugging messages pertaining to public key infrastructure (PKI) certificates. The messages will show status information during certificate enrollment and verification.
You can also use the show crypto ca certificates command to display information about your certificate.
Examples
The following example, which authenticates and enrolls a CA, contains sample output for the debug crypto pki transactions command:
Router(config)# crypto ca authenticate mscaCertificate has the following attributes:Fingerprint:A5DE3C51 AD8B0207 B60BED6D 9356FB00% Do you accept this certificate? [yes/no]:yRouter# debug crypto pki transactions00:44:00:CRYPTO_PKI:Sending CA Certificate Request:GET /certsrv/mscep/mscep.dll/pkiclient.exe?operation=GetCACert&message=msca HTTP/1.000:44:00:CRYPTO_PKI:http connection opened00:44:01:CRYPTO_PKI:HTTP response header:HTTP/1.1 200 OKServer:Microsoft-IIS/5.0Date:Fri, 17 Nov 2000 18:50:59 GMTContent-Length:2693Content-Type:application/x-x509-ca-ra-certContent-Type indicates we have received CA and RA certificates.00:44:01:CRYPTO_PKI:WARNING:A certificate chain could not be constructed while selecting certificate status00:44:01:CRYPTO_PKI:WARNING:A certificate chain could not be constructed while selecting certificate status00:44:01:CRYPTO_PKI:Name:CN = msca-rootRA, O = Cisco System, C = US00:44:01:CRYPTO_PKI:Name:CN = msca-rootRA, O = Cisco System, C = US00:44:01:CRYPTO_PKI:transaction GetCACert completed00:44:01:CRYPTO_PKI:CA certificate received.00:44:01:CRYPTO_PKI:CA certificate received.Router(config)# crypto ca enroll msca%% Start certificate enrollment ..% Create a challenge password. You will need to verbally provide thispassword to the CA Administrator in order to revoke your certificate.For security reasons your password will not be saved in the configuration.Please make a note of it.Password:Re-enter password:% The subject name in the certificate will be:Router.cisco.com% Include the router serial number in the subject name? [yes/no]:n% Include an IP address in the subject name? [yes/no]:nRequest certificate from CA? [yes/no]:y% Certificate request sent to Certificate Authority% The certificate request fingerprint will be displayed.% The 'show crypto ca certificate' command will also show the fingerprint.Router(config)#00:44:29:CRYPTO_PKI:transaction PKCSReq completed00:44:29:CRYPTO_PKI:status:00:44:29:CRYPTO_PKI:http connection opened00:44:29:CRYPTO_PKI: received msg of 1924 bytes00:44:29:CRYPTO_PKI:HTTP response header:HTTP/1.1 200 OKServer:Microsoft-IIS/5.0Date:Fri, 17 Nov 2000 18:51:28 GMTContent-Length:1778Content-Type:application/x-pki-message00:44:29:CRYPTO_PKI:signed attr:pki-message-type:00:44:29:13 01 3300:44:29:CRYPTO_PKI:signed attr:pki-status:00:44:29:13 01 3000:44:29:CRYPTO_PKI:signed attr:pki-recipient-nonce:00:44:29:04 10 B4 C8 2A 12 9C 8A 2A 4A E1 E5 15 DE 22 C2 B4 FD00:44:29:CRYPTO_PKI:signed attr:pki-transaction-id:00:44:29:13 20 34 45 45 41 44 42 36 33 38 43 33 42 42 45 44 45 39 4600:44:29:34 38 44 33 45 36 39 33 45 33 43 37 45 3900:44:29:CRYPTO_PKI:status = 100:certificate is granted00:44:29:CRYPTO__PKI:All enrollment requests completed.00:44:29:%CRYPTO-6-CERTRET:Certificate received from Certificate AuthorityRelated Commands
debug crypto provisioning
To display information about an easy secure device provisioning (SDP) operation, use the debug crypto provisioning command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug crypto provisioning
no debug crypto provisioning
Syntax Description
This command has no arguments or keywords.
Defaults
Debugging is not enabled.
Command Modes
Privileged EXEC
Command History
12.3(8)T
This command was introduced.
12.3(14)T
This command replaced the debug crypto wui command.
Usage Guidelines
For more detailed information about authentication, authorization, and accounting (AAA), use the debug aaa authorization command.
Examples
The following is sample output from the debug crypto provisioning command. The output includes explanations of the process.
Router# debug crypto provisioningPetitioner device! The user starts the Welcome phase.Nov 7 03:15:48.171: CRYPTO_WUI_TTI: received welcome get request.! The router generates a Rivest, Shamir, and Adelman (RSA) keypair for future enrollment.Nov 7 03:15:48.279: CRYPTO_WUI_TTI: keyhash 'A506BE3B83C6F4B4A6EFCEB3D584AACA'! The TTI transaction is completed.Nov 7 03:16:10.607: CRYPTO_WUI_TTI: received completion post request.Registrar device!. During the introduction phase, the browser prompts for login information.06:39:18: CRYPTO_WUI_TTI: received introduction post request.06:39:18: CRYPTO_WUI_TTI: checking AAA authentication (ipsecca_script_aaalist, ttiuser)! This happens if the user types in the wrong username or password.06:39:19: CRYPTO_WUI_TTI: authentication declined by AAA, or AAA server not found - 0x306:39:19: CRYPTO_WUI_TTI: aaa query fails!! The user re-enters login information.06:39:19: CRYPTO_WUI_TTI: received introduction post request.06:39:19: CRYPTO_WUI_TTI: checking AAA authentication (ipsecca_script_aaalist, ttiuser)06:39:20: CRYPTO_WUI_TTI: checking AAA authorization (ipsecca_script_aaalist, ttiuser)! The login attempt succeeds and authorization information is retrieved from the AAA database.06:39:21: CRYPTO_WUI_TTI: aaa query ok!! These attributes are inserted into the configuration template.06:39:21: CRYPTO_WUI_TTI: building TTI av pairs from AAA attributes06:39:21: CRYPTO_WUI_TTI: "subjectname" = "CN=user, O=company, C=country"06:39:21: CRYPTO_WUI_TTI: "$1" = "ntp server 192.0.2.1"06:39:21: CRYPTO_WUI_TTI: "$2" = "hostname user-vpn"! The registrar stores this subject name and overrides the subject name in the subsequent enrollment request.06:39:21: CRYPTO_WUI_TTI: subjectname=CN=user, O=company, C=country! The registrar stores this key information so that it may be used to automatically grant the subsequent enrollment request.06:39:21: CRYPTO_WUI_TTI: key_hash=A506BE3B83C6F4B4A6EFCEB3D584AACARelated Commands
debug crypto sesmgmt
To show connection setup messages and their flow through the router, use the debug crypto sesmgmt command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug crypto sesmgmt
no debug crypto sesmgmt
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
Encryption and authentication are provided by a software service on the router called a crypto engine. The crypto engine performs authentication through Digital Signature Standard (DSS) public and private keys when a connection is set up. DSS is a means of sending a "signature" at the end of a message that positively identifies the author of the message. The signature cannot be forged or duplicated by others, so whoever receives a message with a DSS signature knows exactly who sent the message.
When connections are not completing, use the debug crypto sesmgmt command to follow the progress of connection messages as a first step in diagnosing the problem. You see a record of each connection message as the router discovers it, and can track its progress through the necessary signing, verifying, and encryption session setup operations. Other significant connection setup events, such as the pregeneration of Diffie-Hellman public numbers, are also shown. For information on Diffie-Hellman public numbers, refer to the Cisco IOS Security Configuration Guide.
Also use the show crypto connections command to display additional information on connections.
Examples
The following is sample output from the debug crypto sesmgmt command. The first shows messages from a router that initiates a successful connection. The second shows messages from a router that receives a connection.
Router# debug crypto sesmgmtCRYPTO: Dequeued a message: Inititate_ConnectionCRYPTO: DH gen phase 1 status for conn_id 2 slot 0:OKCRYPTO: Signing done. Status:OKCRYPTO: ICMP message sent: s=172.21.114.163, d=172.21.114.162CRYPTO-SDU: send_nnc_req: NNC Echo Request sentCRYPTO: Dequeued a message: CRMCRYPTO: DH gen phase 2 status for conn_id 2 slot 0:OKCRYPTO: Verify done. Status=OKCRYPTO: Signing done. Status:OKCRYPTO: ICMP message sent: s=172.21.114.163, d=172.21.114.162CRYPTO-SDU: recv_nnc_rpy: NNC Echo Confirm sentCRYPTO: Create encryption key for conn_id 2 slot 0:OKCRYPTO: Replacing -2 in crypto maps with 2 (slot 0)Router# debug crypto sesmgmtCRYPTO: Dequeued a message: CIMCRYPTO: Verify done. Status=OKCRYPTO: DH gen phase 1 status for conn_id 1 slot 0:OKCRYPTO: DH gen phase 2 status for conn_id 1 slot 0:OKCRYPTO: Signing done. Status:OKCRYPTO: ICMP message sent: s=172.21.114.162, d=172.21.114.163CRYPTO-SDU: act_on_nnc_req: NNC Echo Reply sentCRYPTO: Create encryption key for conn_id 1 slot 0:OKCRYPTO: Replacing -2 in crypto maps with 1 (slot 0)CRYPTO: Dequeued a message: CCMCRYPTO: Verify done. Status=OKRelated Commands
debug csm neat
To turn on debugging for all Call Switching Module (CSM) Voice over IP (VoIP) calls, use the debug csm neat command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug csm neat [slot | dspm | dsp | dsp-channel]
no debug csm neat [slot | dspm | dsp | dsp-channel]
Syntax Description
slot | dspm | dsp | dsp-channel
(Optional) Identifies the location of a particular digital signal processor (DSP) channel.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The debug csm neat command turns on debugging for all CSM VoIP calls. If no arguments are specified, debugging is enabled for all voice calls.
Note
The debug csm neat command does not display any information if you try to debug ISDN voice calls. To view debugging information about ISDN calls, use the debug cdapi command.
The no debug cms neat command turns off debugging information for all voice calls.
If the slot, dspm, dsp, or dsp-channel arguments are specified (if the specified DSP channel is engaged in a CSM call), CSM call-related debugging information is turned on for this channel. The no form of this command turns off debugging for that particular channel.
Examples
The following examples show sample output from the debug csm neat command. The following shows that CSM has received an event from ISDN.
Router# debug csm neatMarch 18 04:05:07.052: EVENT_FROM_ISDN::dchan_idb=0x60D7B6B8, call_id=0xCF, ces=0x1bchan=0x0, event=0x1, cause=0x0Table 68 describes the significant fields shown in the display.
The following example shows that CSM has allocated the CSM voice control block for the DSP device on slot 1 port 10 for this call.
March 18 04:05:07.052: VDEV_ALLOCATE: slot 1 and port 10 is allocated.In this example, CSM must first allocate the CSM voice control block to initiate the state machine. After the voice control block has been allocated, CSM obtains from the DSP Resource Manager the actual DSP channel that will be used for the call. At that point, CSM will switch to the actual logical port number. The slot number in this example refers to the physical slot on the Cisco AS5400 access server. The port number is the logical DSP number interpreted as listed in Table 69.
The following example shows that the function csm_vtsp_init_tdm() has been called with a voice control block of address 0x60B8562C. This function will be called only when the call is treated as a voice call.
March 18 04:05:07.052: csm_vtsp_init_tdm (voice_vdev=0x60B8562C)The following example shows that CSM has obtained a DSP channel from the DSP Resource Manager:
March 18 04:05:07.052: csm_vtsp_init_tdm: dsprm_tdm_allocate: tdm slot 1, dspm 2, dsp 5, dsp_channel 1csm_vtsp_init_tdm: dsprm_tdm_allocate: tdm stream 5, channel 9, bank 0, bp_channel 10Table 67 describes the significant fields shown in the DSP channel initialized TDM display.
The following shows that CSM received an incoming call event from ISDN:
March 18 04:05:07.052: EVENT_FROM_ISDN:(00CF): DEV_INCALL at slot 1 and port 20Slot 1, port 20 means the logical DSP channel 20 (mapped to DSPRM 2, DSP 5, DSP channel 1).
The following shows that the DEV_INCALL message been translated into a CSM_EVENT_ISDN_CALL message:
March 18 04:05:07.052: CSM_PROC_IDLE: CSM_EVENT_ISDN_CALL at slot 1, port 20This message is passed to the CSM central state machine while it is in the CSM_IDLE state and is in the CSM_PROC_IDLE procedure. The logical DSP channel port 20 on slot 1 is used to handle this call.
The following shows that CSM has invoked the vtsp_ic_notify() function with a CSM voice call control block 0x60B8562C.
March 18 04:05:07.052: vtsp_ic_notify : (voice_vdev= 0x60B8562C)Inside this function, CSM will send a SETUP INDICATION message to the VTSP. This function will be invoked only if the call is a voice call.
The following shows that CSM received a SETUP INDICATION RESPONSE message from the VTSP as an acknowledgment.
March 18 04:05:07.056: csm_vtsp_call_setup_resp (vdev_info=0x60B8562C, vtsp_cdb=0x60FCA114)This means that the VTSP received the CALL SETUP INDICATION message previously sent and has proceeded to process the call.
•
•
The following shows that CSM received a CALL CONNECT message from the VTSP:
March 18 04:05:07.596: csm_vtsp_call_connect (vtsp_cdb=0x60FCA114, voice_vdev=0x60B8562C)This indicates that the VTSP received a CONNECT message for the call leg initiated to the Internet side.
•
•
The following shows that while CSM is in the CSM_IC2_RING state, it receives a SETUP INDICATION RESPONSE from the VTSP. This message is translated into CSM_EVENT_MODEM_OFFHOOK and passed to the CSM central state machine.
March 18 04:05:07.596: CSM_PROC_IC2_RING: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 20The following shows that CSM received a CONNECT message from ISDN for the call using the logical DSP channel on slot 1 and port 20:
March 18 04:05:07.616: EVENT_FROM_ISDN:(00CF): DEV_CONNECTED at slot 1 and port 20The following shows that CSM translated the CONNECT event from ISDN into the CSM_EVENT_ISDN_CONNECTED message, which is then passed to the CSM central state machine:
March 18 04:05:07.616: CSM_PROC_IC4_WAIT_FOR_CARRIER: CSM_EVENT_ISDN_CONNECTED at slot 1, port 20The following shows that CSM received a CALL SETUP REQUEST from the VTSP:
May 16 12:22:27.580: csm_vtsp_call_setup_request (vtsp_cdb=0x60FCFA20, vtsp_sdb=0x60DFB608)This represents a request to make an outgoing call to the PSTN.
•
•
The following shows that the physical DSP channel has been allocated for this outgoing call:
May 16 12:22:27.580: csm_vtsp_call_setup_request: tdm slot 1, dspm 5, dsp 4, dsp_channel 1The following shows the on-chip and backplane TDM channel assigned to this DSP channel:
May 16 12:22:27.580: csm_vtsp_call_setup_request: tdm stream 5, channel 25, bank 0, bp_channel 27In this sample output, tdm stream 5, channel 25, bank 0, bp_channel 27 indicates the on-chip and backplane TDM channel assigned to this DSP channel. Stream 5, channel 25 gives the on-chip TDM channel mapped to the DSP; bank 0, bp_channel 27 means that the backplane stream 0 and backplane channel 1 are assigned to this DSP.
The following shows the calling number and the called number for this call.
May 16 12:22:27.580: csm_vtsp_call_setup_request: calling number: 10001, called number: 30001The following shows that the CALL SETUP REQUEST from the VTSP has been translated into the ' CSM_EVENT_MODEM_OFFHOOK message and is passed to the CSM central state machine:
May 16 12:22:27.580: CSM_PROC_IDLE: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 54The logical DSP channel number for the DSP (slot 1, port 54) is now displayed, which maps to the physical DSP channel slot 1, dspm 5, dsp 4, dsp_channel 1.
The following shows that CSM collected all the digits for dialing out:
May 16 12:22:27.580: CSM_PROC_OC3_COLLECT_ALL_DIGIT: CSM_EVENT_GET_ALL_DIGITS at slot 1, port 54For PRI and for applications that do not require digit collection of outdialing digits (for example, voice calls), the intermediate digit collection states are omitted and the CSM state machine moves to this state directly, pretending that the digit collection has been done.
The following shows an information message:
March 16 12:22:27.580: CSM_PROC_OC3_COLLECT_ALL_DIGIT: called party num: (30001) at slot 1, port 54The following shows that CSM attempts to find a free signalling D channel to direct the outgoing call:
March 16 12:22:27.580: csm_vtsp_check_dchan (voice_vdev=0x60B8562C)March 16 12:22:27.580: csm_vtsp_check_dchan (vtsp requested dchan=0x60D7ACB0, dchan_idb=0x60E8ACF0)March 16 12:22:27.580: csm_vtsp_check_dchan (voice_vdev=0x60B8562C)March 16 12:22:27.580: csm_vtsp_check_dchan (vtsp requested dchan=0x60D7ACB0, dchan_idb=0x60D7ACB0)In the case of voice calls, the free signaling D channel must match the voice interface specified inside the signalling data block (vtsp_sdb) passed from the VTSP.
The following shows that CSM has received an event from ISDN:
March 16 12:22:27.624: EVENT_FROM_ISDN::dchan_idb=0x60D7ACB0, call_id=0xA121, ces=0x1 bchan=0x1E, event=0x3, cause=0x0In this sample output:
•
•
•
•
The following shows that CSM has received a CALL PROCEEDING message from ISDN.
March 16 12:22:27.624: EVENT_FROM_ISDN:(A121): DEV_CALL_PROC at slot 1 and port 54The following shows that the CALL PROCEEDING event received from ISDN has been interpreted as a CSM_EVENT_ISDN_BCHAN_ASSIGNED message:
*March 16 12:22:27.624: CSM_PROC_OC4_DIALING: CSM_EVENT_ISDN_BCHAN_ASSIGNED at slot 1, port 54ISDN has assigned a B channel for this outgoing call. This B channel must be on the same PRI span as the signalling D channel allocated previously.
The following shows that the csm_vtsp_setup_for_oc function is called:
March 16 12:22:27.624: csm_vtsp_setup_for_oc (voice_vdev=0x60B8562C)This is invoked when an outgoing call initiated by the VTSP receives a response from the ISDN stack.
The following shows that ISDN has sent a CONNECT message to CSM indicating that the call leg to the PSTN side has been established:
March 16 12:22:28.084: EVENT_FROM_ISDN::dchan_idb=0x60D7ACB0, call_id=0xA121, ces=0x1bchan=0x1E, event=0x4, cause=0x0March 16 12:22:28.084: EVENT_FROM_ISDN:(A121): DEV_CONNECTED at slot 1 and port 54The following shows that while CSM is in the OC5_WAIT_FOR_CARRIER state, it has received the 'CONNECT' message from ISDN and has translated it into the CSM_EVENT_ISDN_CONNECTED message, which is passed to the CSM central state machine:
March 16 12:22:28.084: CSM_PROC_OC5_WAIT_FOR_CARRIER: CSM_EVENT_ISDN_CONNECTED at slot 1, port 54The following shows that the function vtsp_confirm_oc() has been called:
March 16 12:22:28.084: vtsp_confirm_oc : (voice_vdev= 0x60B8562C)This is invoked after CSM received the CONNECT message from ISDN. CSM sends a confirmation of the CONNECT to the VTSP.
debug csm tgrm
To view Call Switching Module (CSM) trunk group resource manager information, use the debug csm tgrm command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug csm tgrm
no debug csm tgrm
Syntax Description
This command has no arguments or keywords.
Defaults
Disabled
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Disable console logging and use buffered logging before using the debug csm tgrm command. Using the debug csm tgrm command generates a large volume of debugs, which can affect router performance.
Examples
The following is sample output from the debug csm tgrm command. The output shows that the call type is voice, the direction is incoming, and the call is accepted by the CSM.
Router# debug csm tgrmRouter#00:02:25:CSM-TGRM:csm_rx_cas_event_from_neat(EVENT_DIAL_IN) - c(T1 7/1:1:3)call_type=VOICE, dir=INCOMINGRouter#00:02:30:CSM-TGRM:csm_proc_ic3_wait_for_res_resp() c(T1 7/1:1:3) VOICE <ACCEPTED !!>Table 68 describes the significant fields shown in the display.
Table 68 debug csm tgrm Field Descriptions
call_type
Type of call: VOICE or MODEM.
dir
Direction of the call: INCOMING or OUTGOING.
debug csm voice
To turn on debugging for all Call Switching Module (CSM) Voice over IP (VoIP) calls, use the debug csm voice command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug csm voice [slot | dspm | dsp | dsp-channel]
no debug csm voice [slot | dspm | dsp | dsp-channel]
Syntax Description
slot | dspm | dsp | dsp-channel
(Optional) Identifies the location of a particular digital signal processor (DSP) channel.
Command Modes
Privileged EXEC
Usage Guidelines
The debug csm voice command turns on debugging for all CSM VoIP calls. If this command has no keyword specified, then debugging is enabled for all voice calls.
Note
The no debug cms voice command turns off debugging information for all voice calls.
If the slot | dspm | dsp | dsp-channel argument is specified, then (if the specified DSP channel is engaged in a CSM call) CSM call-related debugging information will be turned on for this channel. The no form of this command turns off debugging for that particular channel.
Examples
The following examples show sample output from the debug csm voice command. The following shows that CSM has received an event from ISDN.
Router# debug csm voiceOct 18 04:05:07.052: EVENT_FROM_ISDN::dchan_idb=0x60D7B6B8, call_id=0xCF, ces=0x1bchan=0x0, event=0x1, cause=0x0In this example, terms are explained as follows:
•
•
•
•
The following shows that CSM has allocated the CSM voice control block for the DSP device on slot 1 port 10 for this call.
Oct 18 04:05:07.052: VDEV_ALLOCATE: slot 1 and port 10 is allocated.This AS5300 access server might not be actually used to handle this call. CSM must first allocate the CSM voice control block to initiate the state machine. After the voice control block has been allocated, CSM obtains from the DSP Resource Manager the actual DSP channel that will be used for the call. At that point, CSM will switch to the actual logical port number. The slot number refers to the physical slot on the AS5300 access server. The port number is the logical DSP number interpreted as listed in Table 69.
The following shows that the function csm_vtsp_init_tdm() has been called with a voice control block of address 0x60B8562C. This function will be called only when the call is treated as a voice call.
Oct 18 04:05:07.052: csm_vtsp_init_tdm (voice_vdev=0x60B8562C)The following shows that CSM has obtained a DSP channel from the DSP Resource Manager:
Oct 18 04:05:07.052: csm_vtsp_init_tdm: dsprm_tdm_allocate: tdm slot 1, dspm 2, dsp 5, dsp_channel 1csm_vtsp_init_tdm: dsprm_tdm_allocate: tdm stream 5, channel 9, bank 0, bp_channel 10The DSP channel has the following initialized TDM channel information:
•
•
The following shows that CSM has received an incoming call event from ISDN:
Oct 18 04:05:07.052: EVENT_FROM_ISDN:(00CF): DEV_INCALL at slot 1 and port 20Slot 1, port 20 means the logical DSP channel 20 (mapped to DSPRM 2, DSP 5, DSP channel 1).
The following shows that the DEV_INCALL message has been translated into a CSM_EVENT_ISDN_CALL message:
Oct 18 04:05:07.052: CSM_PROC_IDLE: CSM_EVENT_ISDN_CALL at slot 1, port 20This message is passed to the CSM central state machine while it is in the CSM_IDLE state and is in the CSM_PROC_IDLE procedure. The logical DSP channel port 20 on slot 1 is used to handle this call.
The following shows that CSM has invoked the vtsp_ic_notify() function with a CSM voice call control block 0x60B8562C.
Oct 18 04:05:07.052: vtsp_ic_notify : (voice_vdev= 0x60B8562C)Inside this function, CSM will send a SETUP INDICATION message to the VTSP. This function will be invoked only if the call is a voice call.
The following shows that CSM has received a SETUP INDICATION RESPONSE message from the VTSP as an acknowledgment.
Oct 18 04:05:07.056: csm_vtsp_call_setup_resp (vdev_info=0x60B8562C, vtsp_cdb=0x60FCA114)This means that the VTSP has received the CALL SETUP INDICATION message previously sent and has proceeded to process the call.
•
•
The following shows that CSM has received a CALL CONNECT message from the VTSP:
Oct 18 04:05:07.596: csm_vtsp_call_connect (vtsp_cdb=0x60FCA114, voice_vdev=0x60B8562C)This indicates that the VTSP has received a CONNECT message for the call leg initiated to the Internet side.
•
•
The following shows that while CSM is in the CSM_IC2_RING state, it receives a SETUP INDICATION RESPONSE from the VTSP. This message is translated into CSM_EVENT_MODEM_OFFHOOK and passed to the CSM central state machine.
Oct 18 04:05:07.596: CSM_PROC_IC2_RING: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 20The following shows that CSM has received a CONNECT message from ISDN for the call using the logical DSP channel on slot 1 and port 20:
Oct 18 04:05:07.616: EVENT_FROM_ISDN:(00CF): DEV_CONNECTED at slot 1 and port 20The following shows that CSM has translated the CONNECT event from ISDN into the CSM_EVENT_ISDN_CONNECTED message, which is then passed to the CSM central state machine:
Oct 18 04:05:07.616: CSM_PROC_IC4_WAIT_FOR_CARRIER: CSM_EVENT_ISDN_CONNECTED at slot 1, port 20The following shows that CSM has received a CALL SETUP REQUEST from the VTSP:
May 16 12:22:27.580: csm_vtsp_call_setup_request (vtsp_cdb=0x60FCFA20, vtsp_sdb=0x60DFB608)This represents a request to make an outgoing call to the PSTN.
•
•
The following shows that the physical DSP channel has been allocated for this outgoing call:
May 16 12:22:27.580: csm_vtsp_call_setup_request: tdm slot 1, dspm 5, dsp 4, dsp_channel 1The following shows the on-chip and backplane TDM channel assigned to this DSP channel:
May 16 12:22:27.580: csm_vtsp_call_setup_request: tdm stream 5, channel 25, bank 0, bp_channel 27In this sample output, tdm stream 5, channel 25, bank 0, bp_channel 27 indicates the on-chip and backplane TDM channel assigned to this DSP channel. Stream 5, channel 25 gives the on-chip TDM channel mapped to the DSP; bank 0, bp_channel 27 means that the backplane stream 0 and backplane channel 1 are assigned to this DSP.
The following shows the calling number and the called number for this call.
May 16 12:22:27.580: csm_vtsp_call_setup_request: calling number: 10001, called number: 30001The following shows that the CALL SETUP REQUEST from the VTSP has been translated into the ' CSM_EVENT_MODEM_OFFHOOK message and is passed to the CSM central state machine:
May 16 12:22:27.580: CSM_PROC_IDLE: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 54The logical DSP channel number for the DSP (slot 1, port 54) is now displayed, which maps to the physical DSP channel slot 1, dspm 5, dsp 4, dsp_channel 1.
The following shows that CSM has collected all the digits for dialing out:
May 16 12:22:27.580: CSM_PROC_OC3_COLLECT_ALL_DIGIT: CSM_EVENT_GET_ALL_DIGITS at slot 1, port 54For PRI and for applications that do not require digit collection of outdialing digits (for example, voice calls), the intermediate digit collection states are omitted and the CSM state machine moves to this state directly, pretending that the digit collection has been done.
The following shows an information message:
May 16 12:22:27.580: CSM_PROC_OC3_COLLECT_ALL_DIGIT: called party num: (30001) at slot 1, port 54The following shows that CSM attempts to find a free signalling D channel to direct the outgoing call:
May 16 12:22:27.580: csm_vtsp_check_dchan (voice_vdev=0x60B8562C)May 16 12:22:27.580: csm_vtsp_check_dchan (vtsp requested dchan=0x60D7ACB0, dchan_idb=0x60E8ACF0)May 16 12:22:27.580: csm_vtsp_check_dchan (voice_vdev=0x60B8562C)May 16 12:22:27.580: csm_vtsp_check_dchan (vtsp requested dchan=0x60D7ACB0, dchan_idb=0x60D7ACB0)In the case of voice calls, the free signaling D channel must match the voice interface specified inside the signalling data block (vtsp_sdb) passed from the VTSP.
The following shows that CSM has received an event from ISDN:
May 16 12:22:27.624: EVENT_FROM_ISDN::dchan_idb=0x60D7ACB0, call_id=0xA121, ces=0x1 bchan=0x1E, event=0x3, cause=0x0In this sample output:
•
•
•
•
The following shows that CSM has received a CALL PROCEEDING message from ISDN.
May 16 12:22:27.624: EVENT_FROM_ISDN:(A121): DEV_CALL_PROC at slot 1 and port 54The following shows that the CALL PROCEEDING event received from ISDN has been interpreted as a CSM_EVENT_ISDN_BCHAN_ASSIGNED message:
*May 16 12:22:27.624: CSM_PROC_OC4_DIALING: CSM_EVENT_ISDN_BCHAN_ASSIGNED at slot 1, port 54ISDN has assigned a B channel for this outgoing call. This B channel must be on the same PRI span as the signalling D channel allocated previously.
The following shows that the csm_vtsp_setup_for_oc function is called:
May 16 12:22:27.624: csm_vtsp_setup_for_oc (voice_vdev=0x60B8562C)This is invoked when an outgoing call initiated by the VTSP receives a response from the ISDN stack.
The following shows that ISDN has sent a CONNECT message to CSM indicating that the call leg to the PSTN side has been established:
May 16 12:22:28.084: EVENT_FROM_ISDN::dchan_idb=0x60D7ACB0, call_id=0xA121, ces=0x1bchan=0x1E, event=0x4, cause=0x0May 16 12:22:28.084: EVENT_FROM_ISDN:(A121): DEV_CONNECTED at slot 1 and port 54The following shows that while CSM is in the OC5_WAIT_FOR_CARRIER state, it has received the 'CONNECT' message from ISDN and has translated it into the CSM_EVENT_ISDN_CONNECTED message, which is passed to the CSM central state machine:
May 16 12:22:28.084: CSM_PROC_OC5_WAIT_FOR_CARRIER: CSM_EVENT_ISDN_CONNECTED at slot 1, port 54The following shows that the function vtsp_confirm_oc() has been called:
May 16 12:22:28.084: vtsp_confirm_oc : (voice_vdev= 0x60B8562C)This is invoked after CSM received the CONNECT message from ISDN. CSM sends a confirmation of the CONNECT to the VTSP.
debug ctl-client
To collect debug information about the CTL client, use the debug ctl-client command in privileged EXEC configuration mode. To disable collection of debug information, use the no form of this command.
debug ctl-client
no debug ctl-client
Syntax Description
This command has no arguments or keywords.
Command Default
Collection of CTL client debug information is disabled.
Command Modes
Privileged EXEC
Command History
12.4(4)XC
This command was introduced.
12.4(9)T
This command was integrated into Cisco IOS Release 12.4(9)T.
Usage Guidelines
This command is used with Cisco Unified CME phone authentication.
Examples
The following example shows debug messages for the CTL client:
Router# debug ctl-client001954: .Jul 21 18:23:02.136: ctl_client_create_ctlfile:001955: .Jul 21 18:23:02.272: create_ctl_record: Function 0 Trustpoint cisco1001956: .Jul 21 18:23:02.276: create_ctl_record: record added for function 0001957: .Jul 21 18:23:02.276: create_ctl_record: Function 0 Trustpoint sast2001958: .Jul 21 18:23:02.280: create_ctl_record: record added for function 0001959: .Jul 21 18:23:02.280: create_ctl_record: Function 1 Trustpoint cisco1001960: .Jul 21 18:23:02.284: create_ctl_record: record added for function 1001961: .Jul 21 18:23:02.284: create_ctl_record: Function 3 Trustpoint cisco1001962: .Jul 21 18:23:02.288: create_ctl_record: record added for function 3001963: .Jul 21 18:23:02.288: create_ctl_record: Function 4 Trustpoint cisco1001964: .Jul 21 18:23:02.292: create_ctl_record: record added for function 4001965: .Jul 21 18:23:02.424: ctl_client_create_ctlfile: Signature length 128001966: .Jul 21 18:23:02.640: CTL File Created Successfullydebug ctunnel
To display debugging messages for the IP over a Connectionless Network Service (CLNS) Tunnel feature, use the debug ctunnel command in privileged EXEC mode. To disable debugging messages, use the no form of this command.
debug ctunnel
no debug ctunnel
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Examples
As packets are sent over the virtual interface, the following type of output will appear on the console when the debug ctunnel command is used:
Router# debug ctunnel4d21h: CTunnel1: IPCLNP encapsulated 49.0001.1111.1111.1111.00->49.0001.2222.2222.2222.00(linktype=7, len=89)debug custom-queue
To enable custom queueing output, use the debug custom-queue command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug custom-queue
no debug custom-queue
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Examples
The following is an example of enabling custom queueing output:
Router# debug custom-queueCustom output queueing debugging is onThe following is sample output from the debug custom-queue command:
00:27:38: CQ: Serial0 output (Pk size/Q: 232/1) Q # was 1 now 100:27:38: CQ: Serial0 output (Pk size/Q: 232/1) Q # was 1 now 100:27:38: CQ: Serial0 output (Pk size/Q: 232/1) Q # was 1 now 100:27:38: CQ: Serial0 output (Pk size/Q: 232/1) Q # was 1 now 200:27:38: CQ: Serial0 output (Pk size/Q: 232/1) Q # was 2 now 100:27:38: CQ: Serial0 output (Pk size/Q: 232/1) Q # was 1 now 100:27:38: CQ: Serial0 output (Pk size/Q: 232/1) Q # was 1 now 100:27:38: CQ: Serial0 output (Pk size/Q: 232/1) Q # was 1 now 100:27:38: CQ: Serial0 output (Pk size/Q: 232/1) Q # was 1 now 100:27:38: CQ: Serial0 output (Pk size/Q: 232/1) Q # was 1 now 100:27:38: CQ: Serial0 output (Pk size/Q: 232/1) Q # was 1 now 200:27:38: CQ: Serial0 output (Pk size/Q: 232/1) Q # was 2 now 100:27:38: CQ: Serial0 output (Pk size/Q: 232/1) Q # was 1 now 100:27:38: CQ: Serial0 output (Pk size/Q: 232/1) Q # was 1 now 100:27:38: CQ: Serial0 output (Pk size/Q: 232/1) Q # was 1 now 100:27:38: CQ: Serial0 output (Pk size/Q: 232/1) Q # was 1 now 100:27:38: CQ: Serial0 output (Pk size/Q: 232/1) Q # was 1 now 200:27:38: CQ: Serial0 output (Pk size/Q: 232/1) Q # was 2 now 100:27:38: CQ: Serial0 output (Pk size/Q: 232/1) Q # was 1 now 100:27:38: CQ: Serial0 output (Pk size/Q: 232/1) Q # was 1 now 100:27:38: CQ: Serial0 output (Pk size/Q: 232/1) Q # was 1 now 1Related Commands
debug dampening
To display debug trace information messages for interface dampening, use the debug dampening command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug dampening [all | interface]
no debug dampening [all | interface]
Syntax Description
all
(Optional) Enables trace debugging for all dampening features.
interface
(Optional) Enables trace debugging for IP event dampening.
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
12.0(22)S
This command was introduced.
12.2(13)T
This command was integrated into Cisco IOS Release 12.2(13)T.
Examples
The following sample output is similar to the output that will be displayed when the debug dampening command is entered with the interface keyword. The sample output shows the following information:
•
•
Router# debug dampening interface00:07:17:IF-EvD(Ethernet1/1):CLNS Routing reports state transition from UP to DOWN00:07:17:EvD(Ethernet1/1):charge penalty 1000, new accum. penalty 1000, flap count 100:07:17:EvD(Ethernet1/1):accum. penalty 1000, now suppressed with a reuse intervals of 3000:07:17:IF-EvD(Ethernet1/1):update CLNS Routing state to DOWN, interface is suppressed00:07:17:IF-EvD(Ethernet1/1):IP Routing reports state transition from DOWN to DOWN00:07:17:IF-EvD(Ethernet1/1):update IP Routing state to DOWN, interface is suppressed00:07:17:IF-EvD(Ethernet1/1):CLNS Routing reports state transition from DOWN to UP00:07:17:IF-EvD(Ethernet1/1):CLNS Routing reports state transition from UP to DOWN00:07:17:EvD(Ethernet1/1):accum. penalty decayed to 1000 after 0 second(s)00:07:17:EvD(Ethernet1/1):charge penalty 1000, new accum. penalty 2000, flap count 200:07:17:EvD(Ethernet1/1):accum. penalty 2000, now suppressed with a reuse intervals of 6000:07:17:IF-EvD(Ethernet1/1):CLNS Routing reports state transition from DOWN to UP00:07:17:IF-EvD(Ethernet1/1):CLNS Routing reports state transition from UP to DOWN00:07:17:EvD(Ethernet1/1):accum. penalty decayed to 2000 after 0 second(s)00:07:17:EvD(Ethernet1/1):charge penalty 1000, new accum. penalty 3000, flap count 300:07:17:EvD(Ethernet1/1):accum. penalty 3000, now suppressed with a reuse intervals of 7800:07:17:IF-EvD(Ethernet1/1):CLNS Routing reports state transition from DOWN to UP00:07:17:IF-EvD(Ethernet1/1):IP Routing reports state transition from UP to UP00:07:17:IF-EvD(Ethernet1/1):IP Routing reports state transition from UP to UP00:07:17:IF-EvD(Ethernet1/1):IP Routing reports state transition from UP to UP00:07:17:IF-EvD(Ethernet1/1):IP Routing reports state transition from UP to UP00:07:17:IF-EvD(Ethernet1/1):IP Routing reports state transition from UP to UP00:07:20:IF-EvD(Ethernet1/1):CLNS Routing reports state transition from UP to UP00:07:20:IF-EvD(Ethernet1/1):IP Routing reports state transition from UP to UP00:07:47:IF-EvD:unsuppress interfaces00:08:36:IF-EvD:unsuppress interfaces00:08:36:EvD(Ethernet1/1):accum. penalty decayed to 483 after 79 second(s)00:08:36:EvD(Ethernet1/1):accum. penalty 483, now unsuppressed00:08:36:IF-EvD(Ethernet1/1):update IP Routing state to UP, interface is not suppressed00:08:36:IF-EvD(Ethernet1/1):update CLNS Routing state to UP, interface is not suppressed00:08:36:IF-EvD(Ethernet1/1):CLNS Routing reports state transition from UP to UPTable 70 describes the significant fields shown in the display.
debug data-store
To display persistant storage device (PSD)-related debugging messages for the gateway GPRS support node (GGSN), use the debug data-store command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug data-store
no debug data-store
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Usage Guidelines
This command displays PSD-related debugging messages for the GGSN.
Caution
Examples
The following example configures a debugging session to check PSD-related parameters:
Router# debug data-storedebug data-store detail
To display extended details for persistent storage device (PSD)-related debugging information, use the debug data-store detail command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug data-store detail
no debug data-store detail
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command Modes
Privileged EXEC
Command History
Usage Guidelines
This command displays PSD-related debugging messages for the GGSN.
Caution
Examples
The following example configures a detailed PSD-related debugging session:
Router# debug data-store detailsRelated Commands
debug dbconn all
To turn on all debug flags for Database Connection, use the debug dbconn all command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug dbconn all
no debug dbconn all
Syntax Description
This command has no arguments or keywords.
Defaults
Debugging is not enabled for Database Connection.
Command Modes
Privileged EXEC
Usage Guidelines
The debug dbconn all command displays debug output for Advanced Program-to-Program Communication (APPC), Database Connection configuration, Distributed Relational Database Architecture (DRDA), error messages, event traces, and TCP. The Database Connection debug flags are appc, config, drda, event, and tcp.
Examples
See the sample output provided for the debug dbconn appc, debug dbconn config, debug dbconn drda, debug dbconn event, and debug dbconn tcp commands.
Related Commands
debug dbconn appc
To display Advanced Program-to-Program Communication (APPC)-related trace or error messages, use the debug dbconn appc command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug dbconn appc
no debug dbconn appc
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
In a router with stable Database Connection, the alias_cp_name field in the trace message should not be blank. There should be no other APPC error message. You can use Advanced Peer-to-Peer Networking (APPN) debug commands with this debug command to track APPN-related errors.
Examples
The following is sample output from the debug dbconn appc command. In a normal situation, only the following message is displayed:
DBCONN-APPC: alias_cp_name is "ASH"The following error messages are displayed if there is a network configuration error or other APPN-related problem:
DBCONN-APPC-612C2B28: APPC error: opcode 0x1, primary_rc 0x0003,secondary_rc 0x00000004DBCONN-APPC-612C2B28: Verb block =DBCONN-APPC-612C2B28: 0001 0200 0003 0000 0000 0004 0020 100CDBCONN-APPC-612C2B28: 610A 828B 0000 0000 0000 0000 0000 0000DBCONN-APPC-612C2B28: 0000 0000 8014 0003 0000 0000 0000 0000DBCONN-APPC-612C2B28: D3E4 F6F2 E2E3 C1D9 C4C2 F240 4040 4040DBCONN-APPC-612C2B28: 4040 4040 4040 4040 4040 4040 4040 4040DBCONN-APPC-612C2B28: 4040 4040 4040 4040 4040 4040 4040 4040DBCONN-APPC-612C2B28: 4040 4040 4040 4040 4040 4040 4040 4040DBCONN-APPC-612C2B28: 4040 4040 4040 4040 0200 0000 0000 0000DBCONN-APPC-612C2B28: 0000 0000 D4C5 D9D9 C9C5 4040 4040 D7C5DBCONN-APPC-612C2B28: E3C5 D940 4040 4040 0000 0000 0000 0000DBCONN-APPC-612C2B28: 00E2 E3C1 D9E6 4BE3 D6D9 C3C8 4040 4040DBCONN-APPC-612C2B28: 4040 0000 0000 0000 0000 0000DBCONN-APPC-612C2B28: ALLOCATE verb block =DBCONN-APPC-612C2B28: 0001 0200 0003 0000 0000 0004 0020 100CDBCONN-APPC-612C2B28: 610A 828B 0000 0000 0000 0000 0000 0000DBCONN-APPC-612C2B28: 0000 0000 8014 0003 0000 0000 0000 0000DBCONN-APPC-612C2B28: D3E4 F6F2 E2E3 C1D9 C4C2 F240 4040 4040DBCONN-APPC-612C2B28: 4040 4040 4040 4040 4040 4040 4040 4040DBCONN-APPC-612C2B28: 4040 4040 4040 4040 4040 4040 4040 4040DBCONN-APPC-612C2B28: 4040 4040 4040 4040 4040 4040 4040 4040DBCONN-APPC-612C2B28: 4040 4040 4040 4040 0200 0000 0000 0000You can use the debug appn command to obtain more information.
The following message is displayed if a database connection is manually cleared and an outstanding APPC verb is pending:
DBCONN-APPC-%612C2B28: Canceling pending APPC verb 0x1Related Commands
debug dbconn config
To display trace or error messages for Database Connection configuration and control blocks, use the debug dbconn config command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug dbconn config
no debug dbconn config
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
Most of the messages for Database Connection and control blocks do not report any errors. If a connection is inactive and cannot be cleared, use this command with the debug dbconn appc, debug dbconn tcp, and debug appn commands to locate the problem. The alias_cp_name field must match the configured APPN cpname.
Examples
The following is sample output from the debug dbconn config command:
Router# debug dbconn configDBCONN-CONFIG: alias_cp_name is "ASH "DBCONN-CONFIG: connection 612BDAAC matching server on 198.147.235.5:0 withrdbname=STELLADBCONN-CONFIG: APPN shutdown; clearing connection 1234abcdDBCONN-CONFIG: created server 612C2720DBCONN-CONFIG: server 612C2720 (listen 60F72E94) is activeDBCONN-CONFIG: server 612C2720 (listen 60F72E94) is activeDBCONN-CONFIG: new connection 612BDAACDBCONN-CONFIG: listen 60F72E94 accepts connection 612BDAACDBCONN-CONFIG: server 60F74614 takes connection 612BDAACDBCONN-CONFIG: listen 60F72E94 releases connection 612BDAACDBCONN-CONFIG: server 60F74614 releases connection 612BDAACDBCONN-CONFIG: deleting connection 612BDAACDBCONN-CONFIG: listen 60F72E94 abandons connection 612BDAACDBCONN-CONFIG: server 612C2720 abandons connection 612BDAACDBCONN-CONFIG: deleting server 612C2720DBCONN-CONFIG: daemon 60381738 takes zombie connection 612BDAACDBCONN-CONFIG: daemon 60381738 releases zombie connection 612BDAACRelated Commands
debug dbconn drda
To display error messages and stream traces for Distributed Relational Database Architecture (DRDA), use the debug dbconn drda command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug dbconn drda
no debug dbconn drda
Syntax Description
This command has no arguments or keywords.
Defaults
Debugging is not enabled for the dbconn subsystem.
Command Modes
Privileged EXEC
Command History
Examples
The following is sample output from the debug dbconn drda command:
Router# debug dbconn drda*Jun 30 16:09:32.363: DBCONN-DRDA-62008300: DSS X'006CD0410001', length 108, in chain,REQDSS, correlator 1*Jun 30 16:09:32.363: DBCONN-DRDA-62008300: OBJECT X'00661041', length 98, code pointX'1041'*Jun 30 16:09:32.363: DBCONN-DRDA-62008300: OBJECT X'0020115E' in COLLECTION X'1041',length 28, code point X'115E'*Jun 30 16:09:32.363: DBCONN-DRDA-62008300: OBJECT X'000C116D' in COLLECTION X'1041',length 8, code point X'116D'*Jun 30 16:09:32.363: DBCONN-DRDA-62008300: OBJECT X'0013115A' in COLLECTION X'1041',length 15, code point X'115A' (skipping...)Related Commands
debug dbconn event
To display trace or error messages for Cisco Transaction Connection (CTRC) events related to DATABASE2 (DB2) communications, use the debug dbconn event command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug dbconn event
no debug dbconn event
Syntax Description
This command has no arguments or keywords.
Defaults
Debugging is not enabled for the dbconn subsystem
Command Modes
Privileged EXEC
Command History
Examples
The following examples display output from the debug dbconn event command in a variety of situations. A normal trace for the debug dbconn event displays as follows:
Router# debug dbconn eventDBCONN-EVENT: Dispatch to 60FD6C00, from 0, msg 60F754CC, msgid 6468 'dh',buffer 0.DBCONN-EVENT: [*] Post to 61134240(cn), from 60EC5470(tc), msg 611419E4,msgid 0x6372 'cr', buffer 612BF68C.DBCONN-EVENT: Flush events called for pto 61182742, pfrom 61239837.DBCONN-EVENT: Event discarded: to 61182742 (cn), from 61239837(ap), msg61339273, msgid 0x6372 'cr' buffer 0.DBCONN-EVENT: == Send to 1234abcd, from 22938acd, msg 72618394, msgid0x6372 'cr', buffer 0.If the following messages are displayed, contact Cisco technical support personnel:
DBCONN-TCPFSM-1234abcd: Cannot occur in state 2 on input 6363 ('cc')DBCONN-APPCFSM-1234abcd: Cannot occur in state 3 on input 6363 ('cc')Related Commands
debug dbconn tcp
To display error messages and traces for TCP, use the debug dbconn tcp command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug dbconn tcp
no debug dbconn tcp
Syntax Description
This command has no arguments or keywords.
Defaults
Debugging is not enabled for the dbconn subsystem.
Command Modes
Privileged EXEC
Command History
Examples
The following is sample output from the debug dbconn tcp command:
Router# debug dbconn tcpDBCONN-TCP-63528473: tcpdriver_passive_open returned NULLDBCONN-TCP-63528473: (no memory) tcp_reset(63829482) returns 4DBCONN-TCP: tcp_accept(74625348,&error) returns tcb 63829482, error 4DBCONN-TCP: (no memory) tcp_reset(63829482) returns 4DBCONN-TCP-63528473: (open) tcp_create returns 63829482, error = 4DBCONN-TCP-63528473: tcb_connect(63829482,1.2.3.4,2010) returns 4DBCONN-TCP-63528473: (open error) tcp_reset(63829482) returns 4DBCONN-TCP-63528473: tcp_create returns 63829482, error = 4DBCONN-TCP-63528473: tcb_bind(63829482,0.0.0.0,2001) returns 4DBCONN-TCP-63528473: tcp_listen(63829482,,) returns 4DBCONN-TCP-63528473: (errors) Calling tcp_close (63829482)Related Commands
debug decnet adj
To display debugging information on DECnet adjacencies, use the debug decnet adj command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug decnet adj
no debug decnet adj
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Examples
The following is sample output from the debug decnet adj command:
Router# debug decnet adjDNET-ADJ: Level 1 hello from 1.3DNET-ADJ: sending hellosDNET-ADJ: Sending hellos to all routers on interface Ethernet0, blksize 1498DNET-ADJ: Level 1 hello from 1.3DNET-ADJ: 1.5 adjacency initializingDNET-ADJ: sending triggered hellosDNET-ADJ: Sending hellos to all routers on interface Ethernet0, blksize 1498DNET-ADJ: Level 1 hello from 1.3DNET-ADJ: 1.5 adjacency upDNET-ADJ: Level 1 hello from 1.5DNET-ADJ: 1.5 adjacency down, listener timeoutThe following line indicates that the router is sending hello messages to all routers on this segment, which in this case is Ethernet 0:
DNET-ADJ: Sending hellos to all routers on interface Ethernet0, blksize 1498The following line indicates that the router has heard a hello message from address 1.5 and is creating an adjacency entry in its table. The initial state of this adjacency will be initializing.
DNET-ADJ: 1.5 adjacency initializingThe following line indicates that the router is sending an unscheduled (triggered) hello message as a result of some event, such as new adjacency being heard:
DNET-ADJ: sending triggered hellosThe following line indicates that the adjacency with 1.5 is now up, or active:
DNET-ADJ: 1.5 adjacency upThe following line indicates that the adjacency with 1.5 has timed out, because no hello message has been heard from adjacency 1.5 in the time interval originally specified in the hello message from 1.5:
DNET-ADJ: 1.5 adjacency down, listener timeoutThe following line indicates that the router is sending an unscheduled hello message, as a result of some event, such as the adjacency state changing:
DNET-ADJ: hello update triggered by state changed in dn_add_adjacencydebug decnet connects
To display debugging information of all connect packets that are filtered (permitted or denied) by DECnet access lists, use the debug decnet connects command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug decnet connects
no debug decnet connects
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
When you use connect packet filtering, it may be helpful to use the decnet access-group configuration command to apply the following basic access list:
access-list 300 permit 0.0 63.1023 eq anyYou can then log all connect packets sent on interfaces to which you applied this list, in order to determine those elements on which your connect packets must be filtered.
Note
Examples
The following is sample output from the debug decnet connects command:
Router# debug decnet connectsDNET-CON: list 300 item #2 matched zrc=19.403 dst=19.309 on Ethernet0: permittedsrcname="RICK" srcuic=[0,017]dstobj=42 id="USER"Table 71 describes significant fields shown in the output.
debug decnet events
To display debugging information on DECnet events, use the debug decnet events command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug decnet events
no debug decnet events
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Examples
The following is sample output from the debug decnet events command:
Router# debug decnet eventsDNET: Hello from area 50 rejected - exceeded `max area' parameter (45)DNET: Hello from area 50 rejected - exceeded `max area' parameter (45)The following line indicates that the router received a hello message from a router whose area was greater than the max-area parameter with which this router was configured:
DNET: Hello from area 50 rejected - exceeded'max area' parameter (45)The following line indicates that the router received a hello message from a router whose node ID was greater than the max-node parameter with which this router was configured:
DNET: Hello from node 1002 rejected - exceeded'max node' parameter (1000)debug decnet packet
To display debugging information on DECnet packet events, use the debug decnet packet command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug decnet packet
no debug decnet packet
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Examples
The following is sample output from the debug decnet packet command:
Router# debug decnet packetDNET-PKT: src 1.4 dst 1.5 sending to PHASEVDNET-PKT: Packet fwded from 1.4 to 1.5, via 1.5, snpa 0000.3080.cf90, TokenRing0The following line indicates that the router is sending a converted packet addressed to node 1.5 to
Phase V:DNET-PKT: src 1.4 dst 1.5 sending to PHASEVThe following line indicates that the router forwarded a packet from node 1.4 to node 1.5. The packet is being sent to the next hop of 1.5 whose subnetwork point of attachment (MAC address) on that interface is 0000.3080.cf90.
DNET-PKT: Packet fwded from 1.4 to 1.5, via 1.5, snpa 0000.3080.cf90, TokenRing0debug decnet routing
To display all DECnet routing-related events occurring at the router, use the debug decnet routing command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug decnet routing
no debug decnet routing
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Examples
The following is sample output from the debug decnet routing command:
Router# debug decnet routingDNET-RT: Received level 1 routing from 1.3 on Ethernet0 at 1:16:34DNET-RT: Sending routesDNET-RT: Sending normal routing updates on Ethernet0DNET-RT: Sending level 1 routing updates on interface Ethernet0DNET-RT: Level1 routes from 1.5 on Ethernet0: entry for node 5 createdDNET-RT: route update triggered by after split route pointers in dn_rt_inputDNET-RT: Received level 1 routing from 1.5 on Ethernet 0 at 1:18:35DNET-RT: Sending L1 triggered routesDNET-RT: Sending L1 triggered routing updates on Ethernet0DNET-RT: removing route to node 5The following line indicates that the router has received a level 1 update on Ethernet interface 0:
DNET-RT: Received level 1 routing from 1.3 on Ethernet0 at 1:16:34The following line indicates that the router is sending its scheduled updates on Ethernet interface 0:
DNET-RT: Sending normal routing updates on Ethernet0The following line indicates that the route will send an unscheduled update on this interface as a result of some event. In this case, the unscheduled update is a result of a new entry created in the routing table of the interface.
DNET-RT: route update triggered by after split route pointers in dn_rt_inputThe following line indicates that the router sent the unscheduled update on Ethernet 0:
DNET-RT: Sending L1 triggered routesDNET-RT: Sending L1 triggered routing updates on Ethernet0The following line indicates that the router removed the entry for node 5 because the adjacency with node 5 timed out, or the route to node 5 through a next-hop router was disconnected:
DNET-RT: removing route to node 5debug dhcp
To display debugging information about the Dynamic Host Configuration Protocol (DHCP) client activities and to monitor the status of DHCP packets, use the debug dhcp command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug dhcp [detail]
no debug dhcp [detail]
Syntax Description
Command Modes
Privileged EXEC
Command History
12.0
This command was introduced.
12.3(8)T
The output of this command was enhanced to display default static routes.
Usage Guidelines
You can also use the debug dhcp command to monitor the subnet allocation and releasing for on-demand address pools.
For debugging purposes, the debug dhcp detail command provides the most useful information such as the lease entry structure of the client and the state transitions of the lease entry. The debug output shows the scanned option values from received DHCP messages that are replies to a router request. The values of the op, htype, hlen, hops, server identifier option, xid, secs, flags, ciaddr, yiaddr, siaddr, and giaddr fields of the DHCP packet are shown in addition to the length of the options field.
Examples
The following examples show and explain some of the typical debugging messages you may see when using the debug dhcp detail command.
The following sample output shows when a DHCP client sends a DHCPDISCOVER broadcast message to find its local DHCP server:
Router# debug dhcp detail00:07:16:DHCP:DHCP client process started:1000:07:16:RAC:Starting DHCP discover on Ethernet200:07:16:DHCP:Try 1 to acquire address for Ethernet200:07:16:%SYS-5-CONFIG_I:Configured from console by console00:07:19:DHCP:Shutting down from get_netinfo()00:07:19:DHCP:Attempting to shutdown DHCP Client00:07:21:DHCP:allocate request00:07:21:DHCP:new entry. add to queue00:07:21:DHCP:SDiscover attempt # 1 for entry:The first seven lines of the following output show the current values stored in the lease entry structure for the client:
00:07:21:Temp IP addr:0.0.0.0 for peer on Interface:Ethernet200:07:21:Temp sub net mask:0.0.0.000:07:21: DHCP Lease server:0.0.0.0, state:1 Selecting00:07:21: DHCP transaction id:58200:07:21: Lease:0 secs, Renewal:0 secs, Rebind:0 secs00:07:21: Next timer fires after:00:00:0300:07:21: Retry count:1 Client-ID:cisco-0010.7b6e.afd8-Et200:07:21:DHCP:SDiscover:sending 308 byte length DHCP packet00:07:21:DHCP:SDiscover 308 bytes00:07:21: B'cast on Ethernet2 interface from 0.0.0.0The following output shows the offered addresses and parameters sent to the DHCP client by the DHCP server via a DHCPOFFER message. The messages containing the Scan field indicate the options that were scanned from the received BOOTP packet and the corresponding values:
00:07:23:DHCP:Received a BOOTREP pkt00:07:23:DHCP:Scan:Message type:DHCP Offer00:07:23:DHCP:Scan:Server ID Option:10.1.1.1 = A01010100:07:23:DHCP:Scan:Lease Time:18000:07:23:DHCP:Scan:Renewal time:9000:07:23:DHCP:Scan:Rebind time:15700:07:23:DHCP:Scan:Subnet Address Option:255.255.255.0The following output shows selected fields in the received BOOTP packet:
00:07:23:DHCP:rcvd pkt source:10.1.1.1, destination: 255.255.255.25500:07:23: UDP sport:43, dport:44, length:30800:07:23: DHCP op:2, htype:1, hlen:6, hops:000:07:23: DHCP server identifier:10.1.1.100:07:23: xid:582, secs:0, flags:800000:07:23: client:0.0.0.0, your:10.1.1.200:07:23: srvr: 0.0.0.0, gw:0.0.0.000:07:23: options block length:6000:07:23:DHCP Offer Message Offered Address:10.1.1.200:07:23:DHCP:Lease Seconds:180 Renewal secs: 90 Rebind secs:15700:07:23:DHCP:Server ID Option:10.1.1.100:07:23:DHCP:offer received from 10.1.1.1The following output shows when the DHCP client sends a DHCPREQUEST broadcast message to the DHCP server to accept the offered parameters:
00:07:23:DHCP:SRequest attempt # 1 for entry:00:07:23:Temp IP addr:10.1.1.2 for peer on Interface:Ethernet200:07:23:Temp sub net mask:255.255.255.000:07:23: DHCP Lease server:10.1.1.1, state:2 Requesting00:07:23: DHCP transaction id:58200:07:23: Lease:180 secs, Renewal:0 secs, Rebind:0 secs00:07:23: Next timer fires after:00:00:0200:07:23: Retry count:1 Client-ID:cisco-0010.7b6e.afd8-Et200:07:23:DHCP:SRequest- Server ID option:10.1.1.100:07:23:DHCP:SRequest- Requested IP addr option:10.1.1.200:07:23:DHCP:SRequest placed lease len option:18000:07:23:DHCP:SRequest:326 bytes00:07:23:DHCP:SRequest:326 bytes00:07:23: B'cast on Ethernet2 interface from 0.0.0.0The following output shows when the DHCP server sends a DHCPACK message to the client with the full set of configuration parameters:
00:07:23:DHCP:Received a BOOTREP pkt00:07:23:DHCP:Scan:Message type:DHCP Ack00:07:23:DHCP:Scan:Server ID Option:10.1.1.1 = A01010100:07:23:DHCP:Scan:Lease Time:18000:07:23:DHCP:Scan:Renewal time:9000:07:23:DHCP:Scan:Rebind time:15700:07:23:DHCP:Scan:Subnet Address Option:255.255.255.000:07:23:DHCP:rcvd pkt source:10.1.1.1, destination: 255.255.255.25500:07:23: UDP sport:43, dport:44, length:30800:07:23: DHCP op:2, htype:1, hlen:6, hops:000:07:23: DHCP server identifier:10.1.1.100:07:23: xid:582, secs:0, flags:800000:07:23: client:0.0.0.0, your:10.1.1.200:07:23: srvr: 0.0.0.0, gw:0.0.0.000:07:23: options block length:6000:07:23:DHCP Ack Message00:07:23:DHCP:Lease Seconds:180 Renewal secs: 90 Rebind secs:15700:07:23:DHCP:Server ID Option:10.1.1.1Interface Ethernet2 assigned DHCP address 10.1.1.2,mask 255.255.255.000:07:26:DHCP Client Pooling:***Allocated IP address:10.1.1.200:07:26:Allocated IP address = 10.1.1.2 255.255.255.0The following output shows when the default gateway (option 3) is assigned a static IP address that is the default route and then static routes are added from the DHCP server:
*Oct 2 06:22:24: Setting default_gateway to 68.8.8.1 ! This is the option 3 defaultgateway.*Oct 2 06:22:24: Adding default route 68.8.8.1*Oct 2 06:22:24: DHCP: Adding static route to 4.3.2.1 255.255.255.255 via 68.8.8.1*Oct 2 06:22:24: DHCP: Adding static route to 1.1.1.1 255.255.255.255 via 68.8.8.1*Oct 2 06:22:24: DHCP: Adding static route to 67.2.2.2 255.255.255.255 via 68.8.8.1Most fields are self-explanatory; however, fields that may need further explanation are described in Table 72.
Related Commands
debug ip dhcp server
Enables DHCP server debugging.
show dhcp lease
Displays DHCP addresses leased from a server.
debug dialer events
To display debugging information about the packets received on a dialer interface, use the debug dialer events command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug dialer events
no debug dialer events
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Usage Guidelines
When dial-on-demand routing (DDR) is enabled on the interface, information concerning the cause of any call (called the Dialing cause) is displayed.
Examples
In the following example, the line of output for an IP packet lists the name of the DDR interface and the source and destination addresses of the packet:
Router# debug dialer eventsDialing cause: Serial0: ip (s=172.16.1.111 d=172.16.2.22)The following line of output for a bridged packet lists the DDR interface and the type of packet (in hexadecimal). For information on these packet types, see the "Ethernet Type Codes" appendix of the Cisco IOS Bridging and IBM Networking Command Reference publication.
Dialing cause: Serial1: Bridge (0x6005)Most messages are self-explanatory; however, messages that may need some explanation are described in Table 73.
Table 74 describes the messages that the debug dialer events command can generate for a serial interface used as a V.25bis dialer for DDR.
Related Commands
debug decnet packet
Displays debugging information about the packets received on a dialer interface.
debug dialpeer
Note
To view dial peer information, use the debug dialpeer command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug dialpeer
no debug dialpeer
Syntax Description
This command has no arguments or keywords.
Defaults
Disabled
Command Modes
Privileged EXEC
Command History
12.2(11)T
This command was introduced.
12.3(8)T
This command was replaced by the debug voip dialpeer command.
Usage Guidelines
Disable console logging and use buffered logging before using the debug dialpeer command. Using the debug dialpeer command generates a large volume of debugging messages, which can affect router performance.
Examples
The following is sample output for the debug dialpeer command. The output shows the destination pattern configured on the matched dial-peer. Expanded string is the string after applying number translation to the original number. It shows that dial-peer 1311 was an incoming dial-peer match. It also shows that routing label was att1. It shows that dial-peer 5108888 and 111399 are an outgoing dial-peer match.
Router# debug dialpeerRouter#00:22:28: Inside dpMatchCore:00:22:28: destination pattn:5108880101 expanded string:510888010100:22:28:MatchNextPeer:Peer 1311 matched00:22:28: Inside dpMatchCore:00:22:28: destination pattn:5108880101 expanded string:510888010100:22:28: Inside dpMatchCore:00:22:28: destination pattn:4088880101 expanded string:408888010100:22:28: Inside dpMatchCore:00:22:28: destination pattn:4088880101 expanded string:408888010100:22:28: dpAssociateIncomingPeer_T:Matching route label att100:22:28: Inside dpMatchCore:00:22:28: destination pattn:5108880101 expanded string:510888010100:22:28: dpAssociateIncomingPeer_T:Matching peer with src route label att1 failed00:22:28: Inside dpMatchCore:00:22:28: destination pattn:5108880101 expanded string:510888010100:22:28:MatchNextPeer:Peer 1311 matched00:22:28: Inside dpMatchPeersMoreArg00:22:28:dpMatchPeersMoreArg:Match Dest. pattern; called (5108880101)00:22:28: Inside dpMatchCore:00:22:28: destination paRouter#ttn:5108880101 expanded string:510888010100:22:28:MatchNextPeer:Peer 5108888 matched00:22:28:MatchNextPeer:Peer 111399 matched00:22:28:dpMatchPeersMoreArg:Result=0 after MATCH_ORIGINATETable 75 describes the significant fields shown in the display.
Related Commands
debug diameter
To display information about the Diameter Protocol, use the debug diameter command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug diameter [dcca | connection | error | packet | event | fsm | failover]
no debug diameter [dcca | connection | error | packet | event | fsm | failover]
Syntax Description
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use this command to display information about any of the listed classes of information about the Diameter Protocol.
Examples
The following examples show output from the debug diameter command:
Peer configuration and peer connection after a peer is configured
Router# debug diameter all*May 9 17:58:14.832: Dia Base: Diameter Peer configured. Allocate connection context.*May 9 17:58:14.832: Dia Base: Allocate the peer connection context 50F63888, handle C000000C *May 9 17:58:14.832: Dia Base: (C000000C): Received peer configuration event *May 9 17:58:14.832: Dia Peer FSM (50F63888): input event START in state CLOSED *May 9 17:58:14.832: Dia Peer FSM (50F63888): Starting Connection timer *May 9 17:58:14.832: Dia Peer FSM (50F63888): event START, stateCLOSED-->WAIT_CONN_ACK*May 9 17:58:14.836: Dia Transport: socket 0 - connecting to 9.113.33.6(3868)*May 9 17:58:14.836: Dia Transport: socket 0 - connection in progress *May 9 17:58:14.836: Dia Transport: socket 0 - local address 9.113.33.5(49214)*May 9 17:58:14.836: Dia Transport: socket 0 - resume socket write - nothing to write *May 9 17:58:14.836: Dia Base: (C000000C): Received peer connection event from transport *May 9 17:58:14.836: Dia Peer FSM (50F63888): input event RCV_CONN_ACK in state WAIT_CONN_ACK *May 9 17:58:14.836: Dia Base: Sending diameter message to peer "Unknown"*May 9 17:58:14.836: DIAMETER: CER message, ver=1, len=120, app=0, [2328318322/2328318322]*May 9 17:58:14.836: DIAMETER: Origin-host-name [264]"host" (M)*May 9 17:58:14.836: DIAMETER: Origin-Realm [296]"cisco" (M)*May 9 17:58:14.836: DIAMETER: Host-IP-address [257]9.113.33.5 (M)*May 9 17:58:14.836: DIAMETER: Vendor-ID [266] 9(M)*May 9 17:58:14.836: DIAMETER: Product-name [269]"C7200-G8IS-M"*May 9 17:58:14.836: DIAMETER: Auth-Application-ID [258] 4(M)*May 9 17:58:14.836: DIAMETER: Firmware-Revision [267] 150D0B710: 01000078 80000101 00000000 ...x........50D0B720: 8AC75172 8AC75172 00000108 4000000C .GQr.GQr....@...50D0B730: 686F7374 00000128 4000000D 63697363 host...(@...cisc50D0B740: 6F000000 00000101 4000000E 00010971 o.......@......q50D0B750: 21050000 0000010A 4000000C 00000009 !.......@.......50D0B760: 0000010D 00000014 43373230 302D4738 ........C7200-G850D0B770: 49532D4D 00000102 4000000C 00000004 IS-M....@.......50D0B780: 0000010B 0000000C 00000001 00 .............*May 9 17:58:14.836: Dia Base: Request message hash ctx created for [2328318322/2328318322] *May 9 17:58:14.836: Dia Peer FSM (50F63888): Starting CER timer *May 9 17:58:14.836: Dia Peer FSM (50F63888): event RCV_CONN_ACK, state WAIT_CONN_ACK-->WAIT_CEA *May 9 17:58:14.836: Dia Transport: Dia Transport write message event *May 9 17:58:14.836: Dia Transport: socket 0 - complete msg sent *May 9 17:58:14.840: Dia Transport: socket 0 - complete read of 20 bytes *May 9 17:58:14.840: Dia Transport: complete header read from socket 0 *May 9 17:58:14.840: Dia Transport: read msg (172) bytes from socket 0 *May 9 17:58:14.840: Dia Transport: socket 0 - complete read of 172 bytes *May 9 17:58:14.840: Dia Base: Diameter message received from the peer "Unknown"*May 9 17:58:14.840: DIAMETER: CEA message, ver=1, len=192, app=0, [2328318322/2328318322]*May 9 17:58:14.840: DIAMETER: Result-code [268]2001 (M)*May 9 17:58:14.840: DIAMETER: Origin-host-name [264]"diameter2.cisco.com" (M)*May 9 17:58:14.840: DIAMETER: Origin-Realm [296]"cisco.com" (M)*May 9 17:58:14.840: DIAMETER: Host-IP-address [257]10.77.154.80 (M)*May 9 17:58:14.840: DIAMETER: Vendor-ID [266] 9(M)*May 9 17:58:14.840: DIAMETER: Product-name [269]"Diameter-Server"*May 9 17:58:14.840: DIAMETER: Supported-Vendor-ID [265]10415 (M)*May 9 17:58:14.840: DIAMETER: Supported-Vendor-ID [265]12645 (M)*May 9 17:58:14.840: DIAMETER: Supported-Vendor-ID [265] 9(M)*May 9 17:58:14.840: DIAMETER: Supported-Vendor-ID [265] 9(M)*May 9 17:58:14.840: DIAMETER: Auth-Application-ID [258] 4(M)65940780: 010000C0 00000101 00000000 ...@........65940790: 8AC75172 8AC75172 0000010C 4000000C .GQr.GQr....@...659407A0: 000007D1 00000108 4000001B 6469616D ...Q....@...diam659407B0: 65746572 322E6369 73636F2E 636F6D00 eter2.cisco.com.659407C0: 00000128 40000011 63697363 6F2E636F ...(@...cisco.co659407D0: 6D000000 00000101 4000000E 00010A4D m.......@......M659407E0: 9A500000 0000010A 4000000C 00000009 .P......@.......659407F0: 0000010D 00000017 4469616D 65746572 ........Diameter65940800: 2D536572 76657200 00000109 4000000C -Server.....@...65940810: 000028AF 00000109 4000000C 00003165 ..(/....@.....1e65940820: 00000109 4000000C 00000009 00000109 ....@...........65940830: 4000000C 00000009 00000102 4000000C @...........@...65940840: 00000004 00 .....*May 9 17:58:14.840: Dia Base: Request message hash ctx removed for [2328318322/2328318322] *May 9 17:58:14.840: Dia Base: (C000000C): Received msg event from message i/o *May 9 17:58:14.840: Dia Peer FSM (50F63888): input event RCV_CEA in state WAIT_CEA *May 9 17:58:14.840: Dia Peer FSM (50F63888): Starting Watchdog timer *May 9 17:58:14.840: %DIABASE-4-DIA_PEER_UP: Diameter peer 9.113.33.6 port 3868 TCP UP *May 9 17:58:14.840: Dia Peer FSM (50F63888): event RCV_CEA, state WAIT_CEA-->OPENPeriodic watch-dog message exchanges
*May 9 17:59:14.840: Dia Peer FSM (50F63888): input event TIMEOUT instate OPEN*May 9 17:59:14.840: Dia Base: Sending diameter message to peer"diameter2.cisco.com"*May 9 17:59:14.840: DIAMETER: DWR message, ver=1, len=48, app=0,[2328318323/2328318323]*May 9 17:59:14.840: DIAMETER: Origin-host-name [264]"host" (M)*May 9 17:59:14.840: DIAMETER: Origin-Realm [296]"cisco" (M)50D0B710: 01000030 80000118 00000000 ...0........50D0B720: 8AC75173 8AC75173 00000108 4000000C .GQs.GQs....@...50D0B730: 686F7374 00000128 4000000D 63697363 host...(@...cisc50D0B740: 6F000000 FD o...}*May 9 17:59:14.840: Dia Base: Request message hash ctx created for[2328318323/2328318323]*May 9 17:59:14.840: Dia Peer FSM (50F63888): Starting Watchdog timer,[60] left for next timeout*May 9 17:59:14.840: Dia Peer FSM (50F63888):event TIMEOUT, state OPEN-->OPEN*May 9 17:59:14.840: Dia Transport: Dia Transport write message event*May 9 17:59:14.840: Dia Transport: socket 0 - complete msg sent*May 9 17:59:14.840: Dia Transport: socket 0 - complete read of 20bytes*May 9 17:59:14.840: Dia Transport: complete header read from socket 0*May 9 17:59:14.840: Dia Transport: read msg (60) bytes from socket 0*May 9 17:59:14.840: Dia Transport: socket 0 - complete read of 60bytes*May 9 17:59:14.840: Dia Base: Diameter message received from the peer"diameter2.cisco.com"*May 9 17:59:14.840: DIAMETER: DWA message, ver=1, len=80, app=0,[2328318323/2328318323]*May 9 17:59:14.840: DIAMETER: Result-code [268]2001 (M)*May 9 17:59:14.840: DIAMETER: Origin-host-name [264]"diameter2.cisco.com" (M)*May 9 17:59:14.840: DIAMETER: Origin-Realm [296]"cisco.com" (M)65940780: 01000050 00000118 00000000 ...P........65940790: 8AC75173 8AC75173 0000010C 4000000C .GQs.GQs....@...659407A0: 000007D1 00000108 4000001B 6469616D ...Q....@...diam659407B0: 65746572 322E6369 73636F2E 636F6D00 eter2.cisco.com.659407C0: 00000128 40000011 63697363 6F2E636F ...(@...cisco.co659407D0: 6D000000 00 m....*May 9 17:59:14.840: Dia Base: Request message hash ctx removed for[2328318323/2328318323]*May 9 17:59:14.840: Dia Base: (C000000C): Received msg event frommessage i/o*May 9 17:59:14.840: Dia Peer FSM (50F63888): input event RCV_DWA instate OPEN*May 9 17:59:14.840: Dia Peer FSM (50F63888): Starting Watchdog timer*May 9 17:59:14.840: Dia Peer FSM (50F63888): event RCV_DWA, stateOPEN-->OPENPeriodic connection attempt when the peer connection is broken
*May 9 18:07:18.472: Dia Transport: socket 0 READ event: UP->CLOSE dueto bytes read = 0*May 9 18:07:18.472: Dia Base: (8600000E): Received peer disconnectionevent from transport*May 9 18:07:18.472: %DIABASE-4-DIA_PEER_DOWN: Diameter peer 9.113.33.6port 3868 TCP DOWN*May 9 18:07:18.472: Dia Peer FSM (2068FF44): input event PEER_DISC instate OPEN*May 9 18:07:18.472: Dia Peer FSM (2068FF44): Starting Reconnect timer*May 9 18:07:18.472: Dia Peer FSM (2068FF44): event PEER_DISC, stateOPEN-->CLOSED*May 9 18:07:48.472: Dia Peer FSM (2068FF44): input event START instate CLOSED*May 9 18:07:48.472: Dia Peer FSM (2068FF44): Starting Connection timer*May 9 18:07:48.472: Dia Peer FSM (2068FF44): event START, stateCLOSED-->WAIT_CONN_ACK*May 9 18:07:48.472: Dia Transport: socket 0 - connecting to 9.113.33.6(3868)*May 9 18:07:48.472: Dia Transport: socket 0 - connection in progress*May 9 18:07:48.472: Dia Transport: socket 0 - local address 9.113.33.5(61122)*May 9 18:07:48.472: Dia Transport: socket 0 - CONN_WAIT->CLOSE*May 9 18:07:48.472: Dia Base: (8600000E): Received peer disconnectionevent from transport*May 9 18:07:48.472: Dia Peer FSM (2068FF44): input event PEER_DISC instate WAIT_CONN_ACK*May 9 18:07:48.472: Dia Peer FSM (2068FF44): Starting Reconnect timer*May 9 18:07:48.472: Dia Peer FSM (2068FF44): event PEER_DISC, stateWAIT_CONN_ACK-->CLOSEDPeer disconnection when a peer configuration is removed
Ginger(config)#no diameter peer watchGinger(config)#*May 9 18:05:02.812: Dia Base: Peer unconfigured, start peerdisconnection*May 9 18:05:02.812: Dia Base: (C000000C): Received peerunconfiguration event*May 9 18:05:02.812: Dia Peer FSM (50F63888): input event STOP in stateOPEN*May 9 18:05:02.812: Dia Base: Sending diameter message to peer"diameter2.cisco.com"*May 9 18:05:02.812: DIAMETER: DPR message, ver=1, len=60, app=0,[2328318329/2328318329]*May 9 18:05:02.812: DIAMETER: Origin-host-name [264]"host" (M)*May 9 18:05:02.816: DIAMETER: Origin-Realm [296]"cisco" (M)*May 9 18:05:02.816: DIAMETER: Peer-disconnect-reason [273]Server-do-not-want-to-talk (M)653D1810: 0100003C 8000011A ...<....653D1820: 00000000 8AC75179 8AC75179 00000108 .....GQy.GQy....653D1830: 4000000C 686F7374 00000128 4000000D @...host...(@...653D1840: 63697363 6F000000 00000111 4000000C cisco.......@...653D1850: 00000002 00 .....*May 9 18:05:02.816: Dia Base: Request message hash ctx created for[2328318329/2328318329]*May 9 18:05:02.816: Dia Peer FSM (50F63888): Starting DPR timer*May 9 18:05:02.816: Dia Peer FSM (50F63888): event STOP, stateOPEN-->CLOSING*May 9 18:05:02.816: Dia Transport: Dia Transport write message event*May 9 18:05:02.816: Dia Transport: socket 0 - complete msg sent*May 9 18:05:02.816: Dia Transport: socket 0 - complete read of 20bytes*May 9 18:05:02.816: Dia Transport: complete header read from socket 0*May 9 18:05:02.816: Dia Transport: read msg (60) bytes from socket 0*May 9 18:05:02.816: Dia Transport: socket 0 - complete read of 60bytes*May 9 18:05:02.816: Dia Base: Diameter message received from the peer"diameter2.cisco.com"*May 9 18:05:02.816: DIAMETER: DPA message, ver=1, len=80, app=0,[2328318329/2328318329]*May 9 18:05:02.816: DIAMETER: Result-code [268]2001 (M)*May 9 18:05:02.816: DIAMETER: Origin-host-name [264]"diameter2.cisco.com" (M)*May 9 18:05:02.816: DIAMETER: Origin-Realm [296]"cisco.com" (M)65913A20: 01000050 ...P65913A30: 0000011A 00000000 8AC75179 8AC75179 .........GQy.GQy65913A40: 0000010C 4000000C 000007D1 00000108 ....@......Q....65913A50: 4000001B 6469616D 65746572 322E6369 @...diameter2.ci65913A60: 73636F2E 636F6D00 00000128 40000011 sco.com....(@...65913A70: 63697363 6F2E636F 6D000000 00 cisco.com....*May 9 18:05:02.816: Dia Base: Request message hash ctx removed for[2328318329/2328318329]*May 9 18:05:02.816: Dia Base: (C000000C): Received msg event frommessage i/o*May 9 18:05:02.816: Dia Peer FSM (50F63888): input event RCV_DPA instate CLOSING*May 9 18:05:02.816: Dia Base: (C000000C): Free the peer connectioncontext 50F63888Related Commands
debug dlsw
To enable debugging of data-link switching plus (DLSw+), use the debug dlsw command in privileged EXEC mode. To disable debugging output, use the no form of this command.
debug dlsw [border-peers [interface interface | ip address ip-address] | core [flow-control messages | state | xid] [circuit-number] | local-circuit circuit-number | peers [interface interface [fast-errors | fast-paks] | ip address ip-address [fast-errors | fast-paks | fst-seq | udp]] | reachability [error | verbose] [sna | netbios]
no debug dlsw [border-peers [interface interface | ip address ip-address] | core [flow-control messages | state | xid] [circuit-number] | local-circuit circuit-number | peers [interface interface [fast-errors | fast-paks] | ip address ip-address [fast-errors | fast-paks | fst-seq | udp]] | reachability [error | verbose] [sna | netbios
Syntax Description
Usage Guidelines
When you specify no optional keywords, the debug dlsw command enables all available DLSW debugging output.
Normally you need to use only the error or verbose option of the debug dlsw reachability command to help identify problems. The error option is recommended for use by customers and provides a subset of the messages from the normal event-level debugging. The verbose option provides a very detailed view of events, and is typically used only by service personnel.
To reduce the amount of debug information displayed, use the sna or netbios option with the debug dlsw reachability command if you know that you have an SNA or NetBIOS problem.
The DLSw core is the engine that is responsible for the establishment and maintenance of remote circuits. If possible, specifying the index of the specific circuit you want to debug reduces the amount of output displayed. However, if you want to watch a circuit initially come up, do not use the circuit-number option with the core keyword.
The core flow-control option provides information about congestion in the WAN or at the remote end station. In these cases, DLSw sends Receiver Not Ready (RNR) frames on its local circuits, slowing data traffic on established sessions and giving the congestion an opportunity to clear.
The core state option allows you to see when the circuit changes state. This capability is especially useful for determining why a session cannot be established or why a session is being disconnected.
The core XID option allows you to track the exchange identification (XID)-state machine. The router tracks XID commands and responses used in negotiations between end stations before establishing a session.
Examples
The following examples show and explain some of the typical DLSw debugging messages you might see when using the debug dlsw command.
The following example enables UDP packet debugging for a specific remote peer:
Router# debug dlsw peers ip-address 1.1.1.6 udpThe following message is sample output from the debug dlsw border-peers command:
*Mar 10 17:39:56: CSM: delete group mac cache for group 0*Mar 10 17:39:56: CSM: delete group name cache for group 0*Mar 10 17:40:19: CSM: update group cache for mac 0000.3072.1070, group 10*Mar 10 17:40:22: DLSw: send_to_group_members(): copy to peer 10.19.32.5The following message is from a router that initiated a TCP connection:
DLSw: START-TPFSM (peer 10.3.8.7(2065)): event:ADMIN-OPEN CONNECTION state:DISCONNDLSw: dtp_action_a() attempting to connect peer 10.3.8.7(2065)DLSw: END-TPFSM (peer 10.3.8.7(2065)): state:DISCONN->WAIT_WRDLSw: Async Open Callback 10.3.8.7(2065) -> 11002DLSw: START-TPFSM (peer 10.3.8.7(2065)): event:TCP-WR PIPE OPENED state:WAIT_WRDLSw: dtp_action_f() start read open timer for peer 10.3.8.7(2065)DLSw: END-TPFSM (peer 10.3.8.7(2065)): state:WAIT_WR->WAIT_RDDLSw: passive open 10.3.8.7(11004) -> 2065DLSw: START-TPFSM (peer 10.3.8.7(2065)): event:TCP-RD PIPE OPENED state:WAIT_RDDLSw: dtp_action_g() read pipe opened for peer 10.3.8.7(2065)DLSw: CapExId Msg sent to peer 10.3.8.7(2065)DLSw: END-TPFSM (peer 10.3.8.7(2065)): state:WAIT_RD->WAIT_CAPDLSw: START-TPFSM (peer 10.3.8.7(2065)): event:SSP-CAP MSG RCVD state:WAIT_CAPDLSw: dtp_action_j() cap msg rcvd from peer 10.3.8.7(2065)DLSw: Recv CapExId Msg from peer 10.3.8.7(2065)DLSw: Pos CapExResp sent to peer 10.3.8.7(2065)DLSw: END-TPFSM (peer 10.3.8.7(2065)): state:WAIT_CAP->WAIT_CAPDLSw: START-TPFSM (peer 10.3.8.7(2065)): event:SSP-CAP MSG RCVD state:WAIT_CAPDLSw: dtp_action_j() cap msg rcvd from peer 10.3.8.7(2065)DLSw: Recv CapExPosRsp Msg from peer 10.3.8.7(2065)DLSw: END-TPFSM (peer 10.3.8.7(2065)): state:WAIT_CAP->WAIT_CAPDLSw: Processing delayed event:SSP-CAP EXCHANGED - prev state:WAIT_CAPDLSw: START-TPFSM (peer 10.3.8.7(2065)): event:SSP-CAP EXCHANGED state:WAIT_CAPDLSw: dtp_action_k() cap xchged for peer 10.3.8.7(2065)DLSw: closing read pipe tcp connection for peer 10.3.8.7(2065)DLSw: END-TPFSM (peer 10.3.8.7(2065)): state:WAIT_CAP->PCONN_WTDLSw: Processing delayed event:TCP-PEER CONNECTED - prev state:PCONN_WTDLSw: START-TPFSM (peer 10.3.8.7(2065)): event:TCP-PEER CONNECTED state:PCONN_WTDLSw: dtp_action_m() peer connected for peer 10.3.8.7(2065)DLSw: END-TPFSM (peer 10.3.8.7(2065)): state:PCONN_WT->CONNECTDLSw: START-TPFSM (peer 10.3.8.7(2065)): event:CORE-ADD CIRCUIT state:CONNECTDLSw: dtp_action_u(), peer add circuit for peer 10.3.8.7(2065)DLSw: END-TPFSM (peer 10.3.8.7(2065)): state:CONNECT->CONNECTThe following message is from a router that received a TCP connection:
DLSw: passive open 10.10.10.4(11002) -> 2065DLSw: START-TPFSM (peer 10.10.10.4(2065)): event:TCP-RD PIPE OPENED state:DISCONNDLSw: dtp_action_c() opening write pipe for peer 10.10.10.4(2065)DLSw: END-TPFSM (peer 10.10.10.4(2065)): state:DISCONN->WWR_RDOPDLSw: Async Open Callback 10.10.10.4(2065) -> 11004DLSw: START-TPFSM (peer 10.10.10.4(2065)): event:TCP-WR PIPE OPENED state:WWR_RDOPDLSw: dtp_action_i() write pipe opened for peer 10.10.10.4(2065)DLSw: CapExId Msg sent to peer 10.10.10.4(2065)DLSw: END-TPFSM (peer 10.10.10.4(2065)): state:WWR_RDOP->WAIT_CAPDLSw: START-TPFSM (peer 10.10.10.4(2065)): event:SSP-CAP MSG RCVD state:WAIT_CAPDLSw: dtp_action_j() cap msg rcvd from peer 10.10.10.4(2065)DLSw: Recv CapExId Msg from peer 10.10.10.4(2065)DLSw: Pos CapExResp sent to peer 10.10.10.4(2065)DLSw: END-TPFSM (peer 10.10.10.4(2065)): state:WAIT_CAP->WAIT_CAPDLSw: START-TPFSM (peer 10.10.10.4(2065)): event:SSP-CAP MSG RCVD state:WAIT_CAPDLSw: dtp_action_j() cap msg rcvd from peer 10.10.10.4(2065)DLSw: Recv CapExPosRsp Msg from peer 10.10.10.4(2065)DLSw: END-TPFSM (peer 10.10.10.4(2065)): state:WAIT_CAP->WAIT_CAPDLSw: Processing delayed event:SSP-CAP EXCHANGED - prev state:WAIT_CAPDLSw: START-TPFSM (peer 10.10.10.4(2065)): event:SSP-CAP EXCHANGED state:WAIT_CAPDLSw: dtp_action_k() cap xchged for peer 10.10.10.4(2065)DLSw: END-TPFSM (peer 10.10.10.4(2065)): state:WAIT_CAP->PCONN_WTDLSw: dlsw_tcpd_fini() for peer 10.10.10.4(2065)DLSw: dlsw_tcpd_fini() closing write pipe for peer 10.10.10.4DLSw: START-TPFSM (peer 10.10.10.4(2065)): event:TCP-CLOSE WR PIPE state:PCONN_WTDLSw: dtp_action_l() close write pipe for peer 10.10.10.4(2065)DLSw: closing write pipe tcp connection for peer 10.10.10.4(2065)DLSw: END-TPFSM (peer 10.10.10.4(2065)): state:PCONN_WT->PCONN_WTDLSw: Processing delayed event:TCP-PEER CONNECTED - prev state:PCONN_WTDLSw: START-TPFSM (peer 10.10.10.4(2065)): event:TCP-PEER CONNECTED state:PCONN_WTDLSw: dtp_action_m() peer connected for peer 10.10.10.4(2065)DLSw: END-TPFSM (peer 10.10.10.4(2065)): state:PCONN_WT->CONNECTDLSw: START-TPFSM (peer 10.10.10.4(2065)): event:CORE-ADD CIRCUIT state:CONNECTDLSw: dtp_action_u(), peer add circuit for peer 10.10.10.4(2065)DLSw: END-TPFSM (peer 10.10.10.4(2065)): state:CONNECT->CONNECTThe following message is from a router that initiated an FST connection:
DLSw: START-FSTPFSM (peer 10.10.10.4(0)): event:ADMIN-OPEN CONNECTION state:DISCONNDLSw: dfstp_action_a() attempting to connect peer 10.10.10.4(0)DLSw: Connection opened for peer 10.10.10.4(0)DLSw: CapExId Msg sent to peer 10.10.10.4(0)DLSw: END-FSTPFSM (peer 10.10.10.4(0)): state:DISCONN->WAIT_CAPDLSw: START-FSTPFSM (peer 10.10.10.4(0)): event:SSP-CAP MSG RCVD state:WAIT_CAPDLSw: dfstp_action_e() cap msg rcvd for peer 10.10.10.4(0)DLSw: Recv CapExPosRsp Msg from peer 10.10.10.4(0)DLSw: END-FSTPFSM (peer 10.10.10.4(0)): state:WAIT_CAP->WAIT_CAPDLSw: START-FSTPFSM (peer 10.10.10.4(0)): event:SSP-CAP MSG RCVD state:WAIT_CAPDLSw: dfstp_action_e() cap msg rcvd for peer 10.10.10.4(0)DLSw: Recv CapExId Msg from peer 10.10.10.4(0)DLSw: Pos CapExResp sent to peer 10.10.10.4(0)DLSw: END-FSTPFSM (peer 10.10.10.4(0)): state:WAIT_CAP->WAIT_CAPDLSw: Processing delayed event:SSP-CAP EXCHANGED - prev state:WAIT_CAPDLSw: START-FSTPFSM (peer 10.10.10.4(0)): event:SSP-CAP EXCHANGED state:WAIT_CAPDLSw: dfstp_action_f() cap xchged for peer 10.10.10.4(0)DLSw: END-FSTPFSM (peer 10.10.10.4(0)): state:WAIT_CAP->CONNECTThe following message is from a router that received an FST connection:
DLSw: START-FSTPFSM (peer 10.3.8.7(0)): event:SSP-CAP MSG RCVD state:DISCONNDLSw: dfstp_action_c() cap msg rcvd for peer 10.3.8.7(0)DLSw: Recv CapExId Msg from peer 10.3.8.7(0)DLSw: Pos CapExResp sent to peer 10.3.8.7(0)DLSw: CapExId Msg sent to peer 10.3.8.7(0)DLSw: END-FSTPFSM (peer 10.3.8.7(0)): state:DISCONN->WAIT_CAPDLSw: START-FSTPFSM (peer 10.3.8.7(0)): event:SSP-CAP MSG RCVD state:WAIT_CAPDLSw: dfstp_action_e() cap msg rcvd for peer 10.3.8.7(0)DLSw: Recv CapExPosRsp Msg from peer 10.3.8.7(0)DLSw: END-FSTPFSM (peer 10.3.8.7(0)): state:WAIT_CAP->WAIT_CAPDLSw: Processing delayed event:SSP-CAP EXCHANGED - prev state:WAIT_CAPDLSw: START-FSTPFSM (peer 10.3.8.7(0)): event:SSP-CAP EXCHANGED state:WAIT_CAPDLSw: dfstp_action_f() cap xchged for peer 10.3.8.7(0)DLSw: END-FSTPFSM (peer 10.3.8.7(0)): state:WAIT_CAP->CONNECTThe following message is from a router that initiated an LLC2 connection:
DLSw-LLC2: Sending enable port ; port no : 0PEER-DISP Sent : CLSI Msg : ENABLE.Req dlen: 20DLSw: Peer Received : CLSI Msg : ENABLE.Cfm CLS_OK dlen: 20DLSw-LLC2 : Sending activate sap for Serial1 - port_id = 887C3Cport_type = 7 dgra(UsapID) = 952458PEER-DISP Sent : CLSI Msg : ACTIVATE_SAP.Req dlen: 60DLSw: Peer Received : CLSI Msg : ACTIVATE_SAP.Cfm CLS_OK dlen: 60DLSw Got ActSapcnf back for Serial1 - port_id = 8978204, port_type = 7, psap_id = 0DLSw: START-LLC2PFSM (peer on interface Serial1): event:ADMIN-OPEN CONNECTION state:DISCONNDLSw: dllc2p_action_a() attempting to connect peer on interface Serial1PEER-DISP Sent : CLSI Msg : REQ_OPNSTN.Req dlen: 106DLSw: END-LLC2PFSM (peer on interface Serial1): state:DISCONN->ROS_SENTDLSw: Peer Received : CLSI Msg : REQ_OPNSTN.Cfm CLS_OK dlen: 106DLSw: START-LLC2PFSM (peer on interface Serial1): event:CLS-REQOPNSTN.CNF state:ROS_SENTDLSw: dllc2p_action_c()PEER-DISP Sent : CLSI Msg : CONNECT.Req dlen: 16DLSw: END-LLC2PFSM (peer on interface Serial1): state:ROS_SENT->CON_PENDDLSw: Peer Received : CLSI Msg : CONNECT.Cfm CLS_OK dlen: 28DLSw: START-LLC2PFSM (peer on interface Serial1): event:CLS-CONNECT.CNF state:CON_PENDDLSw: dllc2p_action_e() send capabilities to peer on interface Serial1PEER-DISP Sent : CLSI Msg : SIGNAL_STN.Req dlen: 8PEER-DISP Sent : CLSI Msg : DATA.Req dlen: 418DLSw: CapExId Msg sent to peer on interface Serial1DLSw: END-LLC2PFSM (peer on interface Serial1): state:CON_PEND->WAIT_CAPDLSw: Peer Received : CLSI Msg : DATA.Ind dlen: 418DLSw: START-LLC2PFSM (peer on interface Serial1): event:SSP-CAP MSG RCVD state:WAIT_CAPDLSw: dllc2p_action_k() cap msg rcvd for peer on interface Serial1DLSw: Recv CapExId Msg from peer on interface Serial1PEER-DISP Sent : CLSI Msg : DATA.Req dlen: 96DLSw: Pos CapExResp sent to peer on interface Serial1DLSw: END-LLC2PFSM (peer on interface Serial1): state:WAIT_CAP->WAIT_CAPDLSw: Peer Received : CLSI Msg : DATA.Ind dlen: 96DLSw: START-LLC2PFSM (peer on interface Serial1): event:SSP-CAP MSG RCVD state:WAIT_CAPDLSw: dllc2p_action_k() cap msg rcvd for peer on interface Serial1DLSw: Recv CapExPosRsp Msg from peer on interface Serial1DLSw: END-LLC2PFSM (peer on interface Serial1): state:WAIT_CAP->WAIT_CAPDLSw: Processing delayed event:SSP-CAP EXCHANGED - prev state:WAIT_CAPDLSw: START-LLC2PFSM (peer on interface Serial1): event:SSP-CAP EXCHANGED state:WAIT_CAPDLSw: dllc2p_action_l() cap xchged for peer on interface Serial1DLSw: END-LLC2PFSM (peer on interface Serial1): state:WAIT_CAP->CONNECTThe following message is from a router that received a Logical Link Control, type 2 (LLC2) connection:
DLSw-LLC2: Sending enable port ; port no : 0PEER-DISP Sent : CLSI Msg : ENABLE.Req dlen: 20DLSw: Peer Received : CLSI Msg : ENABLE.Cfm CLS_OK dlen: 20DLSw-LLC2 : Sending activate sap for Serial0 - port_id = 887C3Cport_type = 7 dgra(UsapID) = 93AB34PEER-DISP Sent : CLSI Msg : ACTIVATE_SAP.Req dlen: 60DLSw: Peer Received : CLSI Msg : ACTIVATE_SAP.Cfm CLS_OK dlen: 60DLSw Got ActSapcnf back for Serial0 - port_id = 8944700, port_type = 7, psap_id = 0DLSw: Peer Received : CLSI Msg : CONECT_STN.Ind dlen: 39DLSw: START-LLC2PFSM (peer on interface Serial0): event:CLS-CONNECT_STN.IND state:DISCONNDLSw: dllc2p_action_s() conn_stn for peer on interface Serial0PEER-DISP Sent : CLSI Msg : REQ_OPNSTN.Req dlen: 106DLSw: END-LLC2PFSM (peer on interface Serial0): state:DISCONN->CONS_PENDDLSw: Peer Received : CLSI Msg : REQ_OPNSTN.Cfm CLS_OK dlen: 106DLSw: START-LLC2PFSM (peer on interface Serial0): event:CLS-REQOPNSTN.CNF state:CONS_PENDDLSw: dllc2p_action_h() send capabilities to peer on interface Serial0PEER-DISP Sent : CLSI Msg : CONNECT.Rsp dlen: 20PEER-DISP Sent : CLSI Msg : DATA.Req dlen: 418DLSw: CapExId Msg sent to peer on interface Serial0DLSw: END-LLC2PFSM (peer on interface Serial0): state:CONS_PEND->WAIT_CAPDLSw: Peer Received : CLSI Msg : CONNECTED.Ind dlen: 8DLSw: START-LLC2PFSM (peer on interface Serial0): event:CLS-CONNECTED.IND state:WAIT_CAPDLSw: END-LLC2PFSM (peer on interface Serial0): state:WAIT_CAP->WAIT_CAPDLSw: Peer Received : CLSI Msg : DATA.Ind dlen: 418DLSw: START-LLC2PFSM (peer on interface Serial0): event:SSP-CAP MSG RCVD state:WAIT_CAPDLSw: dllc2p_action_k() cap msg rcvd for peer on interface Serial0DLSw: Recv CapExId Msg from peer on interface Serial0PEER-DISP Sent : CLSI Msg : DATA.Req dlen: 96DLSw: Pos CapExResp sent to peer on interface Serial0DLSw: END-LLC2PFSM (peer on interface Serial0): state:WAIT_CAP->WAIT_CAPDLSw: Peer Received : CLSI Msg : DATA.Ind dlen: 96DLSw: START-LLC2PFSM (peer on interface Serial0): event:SSP-CAP MSG RCVD state:WAIT_CAPDLSw: dllc2p_action_k() cap msg rcvd for peer on interface Serial0DLSw: Recv CapExPosRsp Msg from peer on interface Serial0DLSw: END-LLC2PFSM (peer on interface Serial0): state:WAIT_CAP->WAIT_CAPDLSw: Processing delayed event:SSP-CAP EXCHANGED - prev state:WAIT_CAPDLSw: START-LLC2PFSM (peer on interface Serial0): event:SSP-CAP EXCHANGED state:WAIT_CAPDLSw: dllc2p_action_l() cap xchged for peer on interface Serial0DLSw: END-LLC2PFSM (peer on interface Serial0): state:WAIT_CAP->CONNECTThe following messages occur when a CUR_ex (CANUREACH explorer) frame is received from other peers, and the peer statements or the promiscuous keyword have not been enabled so that the router is not configured correctly:
22:42:44: DLSw: Not promiscuous - Rej conn from 172.20.96.1(2065)22:42:51: DLSw: Not promiscuous - Rej conn from 172.20.99.1(2065)In the following messages, the router sends a keepalive message every 30 seconds to keep the peer connected. If three keepalive messages are missed, the peer is torn down. These messages are displayed only if keepalives are enabled (by default, keepalives are disabled):
22:44:03: DLSw: Keepalive Request sent to peer 172.20.98.1(2065) (168243148)22:44:03: DLSw: Keepalive Response from peer 172.20.98.1(2065) (168243176)22:44:34: DLSw: Keepalive Request sent to peer 172.20.98.1(2065) (168274148)22:44:34: DLSw: Keepalive Response from peer 172.20.98.1(2065) (168274172)The following peer debugging messages indicate that the local peer is disconnecting from the specified remote peer because of missed peer keepalives:
0:03:24: DLSw: keepalive failure for peer on interface Serial00:03:24: DLSw: action_d(): for peer on interface Serial00:03:24: DLSW: DIRECT aborting connection for peer on interface Serial00:03:24: DLSw: peer on interface Serial0, old state CONNECT, new state DISCONNThe following peer debugging messages result from an attempt to connect to an IP address that does not have DLSw enabled. The local router attempts to connect in 30-second intervals:
23:13:22: action_a() attempting to connect peer 172.20.100.1(2065)23:13:22: DLSw: CONN: peer 172.20.100.1 open failed, rejected [9]23:13:22: action_a() retries: 8 next conn time: 86123250423:13:52: action_a() attempting to connect peer 172.20.100.1(2065)23:13:52: DLSw: CONN: peer 172.20.100.1 open failed, rejected [9]23:13:52: action_a() retries: 9 next conn time: 861292536The following peer debugging messages that indicates a remote peer statement is missing on the router (address 172.20.100.1) to which the connection attempt is sent:
23:14:52: action_a() attempting to connect peer 172.20.100.1(2065)23:14:52: DLSw: action_a(): Write pipe opened for peer 172.20.100.1(2065)23:14:52: DLSw: peer 172.20.100.1(2065), old state DISCONN, new state WAIT_RD23:14:52: DLSw: dlsw_tcpd_fini() closing connection for peer 172.20.100.123:14:52: DLSw: action_d(): for peer 172.20.100.1(2065)23:14:52: DLSw: aborting tcp connection for peer 172.20.100.1(2065)23:14:52: DLSw: peer 172.20.100.1(2065), old state WAIT_RD, new state DISCONNThe following messages show a peer connection opening with no errors or abnormal events:
23:16:37: action_a() attempting to connect peer 172.20.100.1(2065)23:16:37: DLSw: action_a(): Write pipe opened for peer 172.20.100.1(2065)23:16:37: DLSw: peer 172.20.100.1(2065), old state DISCONN, new state WAIT_RD23:16:37: DLSW: passive open 172.20.100.1(17762) -> 206523:16:37: DLSw: action_c(): for peer 172.20.100.1(2065)23:16:37: DLSw: peer 172.20.100.1(2065), old state WAIT_RD, new state CAP_EXG23:16:37: DLSw: peer 172.20.100.1(2065) conn_start_time set to 86139778423:16:37: DLSw: CapExId Msg sent to peer 172.20.100.1(2065)23:16:37: DLSw: Recv CapExId Msg from peer 172.20.100.1(2065)23:16:37: DLSw: Pos CapExResp sent to peer 172.20.100.1(2065)23:16:37: DLSw: action_e(): for peer 172.20.100.1(2065)23:16:37: DLSw: Recv CapExPosRsp Msg from peer 172.20.100.1(2065)23:16:37: DLSw: action_e(): for peer 172.20.100.1(2065)23:16:37: DLSw: peer 172.20.100.1(2065), old state CAP_EXG, new state CONNECT23:16:37: DLSw: dlsw_tcpd_fini() closing write pipe for peer 172.20.100.123:16:37: DLSw: action_g(): for peer 172.20.100.1(2065)23:16:37: DLSw: closing write pipe tcp connection for peer 172.20.100.1(2065)23:16:38: DLSw: peer_act_on_capabilities() for peer 172.20.100.1(2065)The following two messages show that an information frame is passing through the router:
DLSw: dlsw_tr2fct() lmac:c000.a400.0000 rmac:0800.5a29.75fe ls:5 rs:4 i:34DLSw: dlsw_tr2fct() lmac:c000.a400.0000 rmac:0800.5a29.75fe ls:4 rs:4 i:34Sample debug DLSw Reachability Messages
The messages in this section are based on the following criteria:
•
•
•
•
•
Table 76 describes the debug output indicating that the DLSW router received an SSP message that is flow controlled and should be counted against the window of the sender.
Dec 6 11:26:49: CSM: Received SSP CUR csex flags = 80, mac 4000.90b1.26cf,The csex flags = 80 means that this is an CUR_ex (explorer).Dec 5 10:48:33: DLSw: 1620175180 decr r - s:27 so:0 r:27 ro:0
The following message shows that DLSW is sending an I frame to a LAN:
Dec 5 10:48:33: DISP Sent : CLSI Msg : DATA.Req dlen: 1086The following message shows that DLSW received the I frame from the LAN:
Dec 5 10:48:35: DLSW Received-disp : CLSI Msg : DATA.Ind dlen: 4The following messages show that the reachability cache is cleared:
Router# clear dlsw rea23:44:11: CSM: Clearing CSM cache23:44:11: CSM: delete local mac cache for port 023:44:11: CSM: delete local name cache for port 023:44:11: CSM: delete remote mac cache for peer 023:44:11: CSM: delete remote name cash dlsw reaThe next group of messages show that the DLSW reachability cache is added, and that a name query is perform from the router MARIAN:
23:45:11: CSM: core_to_csm CLSI_MSG_PROC - port_id 5EFBB423:45:11: CSM: 0800.5a30.7a9b passes local mac excl. filter23:45:11: CSM: update local cache for mac 0800.5a30.7a9b, port 5EFBB423:45:11: CSM: update local cache for name MARIAN , port 5EFBB423:45:11: CSM: Received CLS_UDATA_STN from Core23:45:11: CSM: Received netbios frame type A23:45:11: CSM: Processing Name Query23:45:11: CSM: Netbios Name Query: ws_status = 623:45:11: CSM: Write to peer 0 ok.23:45:11: CSM: Freeing clsi message23:45:11: CSM: core_to_csm CLSI_MSG_PROC - port_id 658AB423:45:11: CSM: 0800.5a30.7a9b passes local mac excl. filter23:45:11: CSM: update local cache for mac 0800.5a30.7a9b, port 658AB423:45:11: CSM: update local cache for name MARIAN , port 658AB423:45:11: CSM: Received CLS_UDATA_STN from Core23:45:11: CSM: Received netbios frame type A23:45:11: CSM: Processing Name Query23:45:11: CSM: Netbios Name Query: ws_status = 523:45:11: CSM: DLXNR_PEND match found.... drop name query23:45:11: CSM: Freeing clsi message23:45:12: CSM: core_to_csm CLSI_MSG_PROC - port_id 5EFBB423:45:12: CSM: 0800.5a30.7a9b passes local mac excl. filter23:45:12: CSM: update local cache for mac 0800.5a30.7a9b, port 5EFBB423:45:12: CSM: update local cache for name MARIAN , port 5EFBB423:45:12: CSM: Received CLS_UDATA_STN from Core23:45:12: CSM: Received netbios frame type A23:45:12: CSM: Processing Name Query23:45:12: CSM: Netbios Name Query: ws_status = 523:45:12: CSM: DLXNR_PEND match found.... drop name query23:45:12: CSM: Freeing clsi message23:45:12: CSM: core_to_csm CLSI_MSG_PROC - port_id 658AB423:45:12: CSM: 0800.5a30.7a9b passes local mac excl. filter23:45:12: CSM: update local cache for mac 0800.5a30.7a9b, port 658AB423:45:12: CSM: update local cache for name MARIAN , port 658AB423:45:12: CSM: Received CLS_UDATA_STN from Core23:45:12: CSM: Received netbios frame type A23:45:12: CSM: Processing Name Query23:45:12: CSM: Netbios Name Query: ws_status = 523:45:12: CSM: DLXNR_PEND match found.... drop name query23:45:12: CSM: Freeing clsi message23:45:12: CSM: core_to_csm CLSI_MSG_PROC - port_id 5EFBB423:45:12: CSM: 0800.5a30.7a9b passes local mac excl. filter23:45:12: CSM: update local cache for mac 0800.5a30.7a9b, port 5EFBB423:45:12: CSM: update local cache for name MARIAN , port 5EFBB423:45:12: CSM: Received CLS_UDATA_STN from Core23:45:12: CSM: Received netbios frame type A23:45:12: CSM: Processing Name Query23:45:12: CSM: Netbios Name Query: ws_status = 523:45:12: CSM: DLXNR_PEND match found.... drop name query23:45:12: CSM: Freeing clsi message23:45:12: CSM: core_to_csm CLSI_MSG_PROC - port_id 658AB423:45:12: CSM: 0800.5a30.7a9b passes local mac excl. filter23:45:12: CSM: update local cache for mac 0800.5a30.7a9b, port 658AB423:45:12: CSM: update local cache for name MARIAN , port 658AB423:45:12: CSM: Received CLS_UDATA_STN from Core23:45:12: CSM: Received netbios frame type A23:45:12: CSM: Processing Name Query23:45:12: CSM: Netbios Name Query: ws_status = 523:45:12: CSM: DLXNR_PEND match found.... drop name query23:45:12: CSM: Freeing clsi message23:45:18: CSM: Deleting Reachability cache23:45:18: CSM: Deleting DLX NR pending record....23:45:38: CSM: core_to_csm CLSI_MSG_PROC - port_id 5EFBB423:45:38: CSM: 0800.5a30.7a9b passes local mac excl. filter23:45:38: CSM: update local cache for mac 0800.5a30.7a9b, port 5EFBB423:45:38: CSM: update local cache for name MARIAN , port 5EFBB423:45:38: CSM: Received CLS_UDATA_STN from Core23:45:38: CSM: Received netbios frame type 823:45:38: CSM: Write to peer 0 ok.23:45:38: CSM: Freeing clsi message23:45:38: CSM: core_to_csm CLSI_MSG_PROC - port_id 658AB423:45:38: CSM: 0800.5a30.7a9b passes local mac excl. filter23:45:38: CSM: update local cache for mac 0800.5a30.7a9b, port 658AB423:45:38: CSM: update local cache for name MARIAN , port 658AB423:45:38: CSM: Received CLS_UDATA_STN from Core23:45:38: CSM: Received netbios frame type 823:45:38: CSM: Write to peer 0 ok.23:45:38: CSM: Freeing clsi messageThe following messages show that the router named MARIAN is added to the network:
23:45:38: CSM: core_to_csm CLSI_MSG_PROC - port_id 5EFBB423:45:38: CSM: 0800.5a30.7a9b passes local mac excl. filter23:45:38: CSM: update local cache for mac 0800.5a30.7a9b, port 5EFBB423:45:38: CSM: update local cache for name MARIAN , port 5EFBB423:45:38: CSM: Received CLS_UDATA_STN from Core23:45:38: CSM: Received netbios frame type 823:45:38: CSM: Write to peer 0 ok.23:45:38: CSM: Freeing clsi message23:45:38: CSM: core_to_csm CLSI_MSG_PROC - port_id 658AB423:45:38: CSM: 0800.5a30.7a9b passes local mac excl. filter23:45:38: CSM: update local cache for mac 0800.5a30.7a9b, port 658AB423:45:38: CSM: update local cache for name MARIAN , port 658AB423:45:38: CSM: Received CLS_UDATA_STN from Core23:45:38: CSM: Received netbios frame type 823:45:38: CSM: Write to peer 0 ok.23:45:38: CSM: Freeing clsi messageIn the next group of messages, an attempt is made to add the router named GINGER on the Ethernet interface:
0:07:44: CSM: core_to_csm CLSI_MSG_PROC - port_id 658AB40:07:44: CSM: 0004.f545.24e6 passes local mac excl. filter0:07:44: CSM: update local cache for mac 0004.f545.24e6, port 658AB40:07:44: CSM: update local cache for name GINGER , port 658AB40:07:44: CSM: Received CLS_UDATA_STN from Core0:07:44: CSM: Received netbios frame type 80:07:44: CSM: Write to peer 0 ok.In the following example, the output from the show dlsw reachability command indicates that GINGER is on the Ethernet interface and MARIAN is on the Token Ring interface:
Router# show dlsw reachabilityDLSw MAC address reachability cache listMac Addr status Loc. peer/port rif0004.f545.24e6 FOUND LOCAL P007-S000 --no rif--0800.5a30.7a9b FOUND LOCAL P000-S000 06C0.0621.7D00P007-S000 F0F8.0006.A6FC.005F.F100.0000.0000.0000DLSw NetBIOS Name reachability cache listNetBIOS Name status Loc. peer/port rifGINGER FOUND LOCAL P007-S000 --no rif--MARIAN FOUND LOCAL P000-S000 06C0.0621.7D00P007-S000 --no rif--
Posted: Mon Jul 2 21:16:35 PDT 2007
All contents are Copyright © 1992--2007 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
