-
Cisco IOS Debug Command Reference, Release 12.1
-
About this Manual
-
Using Cisco IOS Software
-
Using Debug Commands
-
Conditionally Triggered Debugging
-
Debug Commands (debug aaa acounting - debug appn trs)
-
Debug Commands (debug arap - debug channel packets)
-
Debug Commands (debug clns esis events - debug dialer events)
-
Debug Commands (debug dlsw - debug ip dhcp server)
-
Debug Commands (debug ip drp - debug ip pgm router)
-
Debug Commands (debug ip pim - debug ip wccp packets)
-
Debug Commands (debug ipx ipxwan - debug kerberos)
-
Debug Commands (debug lane client - debug mls rp ip multicast)
-
Debug Commands (debug modem - debug ppp)
-
Debug Commands (debug ppp bap - debug sdllc)
-
Debug Commands (debug serial interface - debug tacacs events)
-
Debug Commands (debug tag-switching adjacency - debug tag-switching xtagatm vc)
-
Debug Commands (debug tarp events - debug voip settlement transactions)
-
Debug Commands (debug vpdn - debug xns routing)
-
X.25 Cause and Diagnostic Codes
-
ISDN Switch Types, Codes, and Values
-
Index
-
Table Of Contents
debug serial interface
Use the debug serial interface privileged EXEC command to display information on a serial connection failure. The no form of this command disables debugging output.
debug serial interface
no debug serial interface
Syntax Description
This command has no arguments or keywords.
Usage Guidelines
If the show interface serial command shows that the line and protocol are down, you can use the debug serial interface command to isolate a timing problem as the cause of a connection failure. If the keepalive values in the mineseq, yourseen, and myseen fields are not incrementing in each subsequent line of output, there is a timing or line problem at one end of the connection.
CautionWhile the debug serial interface command typically does not generate a lot of output, nevertheless use it cautiously during production hours. When SMDS is enabled, for example, it can generate considerable output.
The output of the debug serial interface command can vary, depending on the type of WAN configured for an interface: Frame Relay, HDLC, HSSI, SMDS, or X.25. The output also can vary depending on the type of encapsulation configured for that interface. The hardware platform also can affect debug serial interface output.
The following sections show and describe sample debug serial interface output for various configurations.
Examples
Debug Serial Interface for Frame Relay Encapsulation
The following message is displayed if the encapsulation for the interface is Frame Relay (or HDLC) and the router attempts to send a packet containing an unknown packet type:
Illegal serial link type code xxxDebug Serial Interface for HDLC
The following is sample output from the debug serial interface command for an HDLC connection when keepalives are enabled. This output shows that the remote router is not receiving all the keepalives the router is sending. When the difference in the values in the myseq and mineseen fields exceeds three, the line goes down and the interface is reset.
Table 136 describes the significant fields.
The previous example shows that after missing three keepalives, the line goes down and the interface is reset. However, the interface is also reset when two keepalives are missed, but the line is not marked as "down." This is done in an attempt to restart traffic on the interface without bringing the line down, as shown in the following output:
*Mar 18 08:07:29.057: Serial3/2: HDLC myseq 604562, mineseen 604562, yourseen 259336, line up*Mar 18 08:07:39.053: Serial3/2: HDLC myseq 604563, mineseen 604563, yourseen 259337, line up*Mar 18 08:07:49.081: Serial3/2: HDLC myseq 604564, mineseen 604564, yourseen 259338, line up*Mar 18 08:07:59.057: Serial3/2: HDLC myseq 604565, mineseen 604565, yourseen 259339, line up*Mar 18 08:08:09.073: Serial3/2: HDLC myseq 604566, mineseen 604565, yourseen 259340, line up*Mar 18 08:08:19.057: Serial3/2: Reset from PC 0x6DEA0*Mar 18 08:08:19.061: Serial3/2: HDLC myseq 604567, mineseen 604565, yourseen 259341, line up*Mar 18 08:08:29.057: Serial3/2: HDLC myseq 604568, mineseen 604568, yourseen 259342, line up*Mar 18 08:08:39.061: Serial3/2: HDLC myseq 604569, mineseen 604569, yourseen 259343, line up*Mar 18 08:08:49.065: Serial3/2: HDLC myseq 604570, mineseen 604570, yourseen 259344, line up*Mar 18 08:08:59.053: Serial3/2: HDLC myseq 604571, mineseen 604571, yourseen 259345, line upEven though the "Reset from PC" message appears to occur when there is only a difference of 1 between myseq and mineseen, this message applies to the condition shown in the immediately following line (notice that the timestamp is only a few milliseconds later) where the difference is 2. After the reset, the line has recovered and the difference between myseq and mineseen is zero.
Table 137 describes additional error messages that the debug serial interface command can generate for HDLC.
Debug Serial Interface for HSSI
On an HSSI interface, the debug serial interface command can generate the following additional error message:
HSSI0: Reset from 0xnnnnnnnThis message indicates that the HSSI hardware has been reset. The 0xnnnnnnn variable is the address of the routine requesting that the hardware be reset; this value is useful only to development engineers.
Debug Serial Interface for ISDN Basic Rate
Table 138 describes error messages that the debug serial interface command can generate for ISDN Basic Rate.
Debug Serial Interface for an MK5025 Device
Table 139 describes the additional error messages that the debug serial interface command can generate for an MK5025 device.
Debug Serial Interface for SMDS Encapsulation
When encapsulation is set to SMDS, debug serial interface displays SMDS packets that are sent and received, as well as any error messages resulting from SMDS packet transmission.
The error messages that the debug serial interface command can generate for SMDS follow.
The following message indicates that a new protocol requested SMDS to encapsulate the data for transmission. SMDS is not yet able to encapsulate the protocol.
SMDS: Error on Serial 0, encapsulation bad protocol = xThe following message indicates that SMDS was asked to encapsulate a packet, but no corresponding destination E.164 SMDS address was found in any of the static SMDS tables or in the ARP tables:
SMDS send: Error in encapsulation, no hardware address, type = xThe following message indicates that a protocol such as CLNS or IP has been enabled on an SMDS interface, but the corresponding multicast addresses have not been configured. The n variable displays the link type for which encapsulation was requested.
SMDS: Send, Error in encapsulation, type=nThe following messages can occur when a corrupted packet is received on an SMDS interface. The router expected x, but received y.
SMDS: Invalid packet, Reserved NOT ZERO, x ySMDS: Invalid packet, TAG mismatch x ySMDS: Invalid packet, Bad TRAILER length x yThe following messages can indicate an invalid length for an SMDS packet:
SMDS: Invalid packet, Bad BA length xSMDS: Invalid packet, Bad header extension length xSMDS: Invalid packet, Bad header extension type xSMDS: Invalid packet, Bad header extension value xThe following messages are displayed when the debug serial interface command is enabled:
Interface Serial 0 Sending SMDS L3 packet:SMDS: dgsize:x type:0xn src:y dst:zIf the debug serial interface command is enabled, the following message can be displayed when a packet is received on an SMDS interface, but the destination SMDS address does not match any on that interface:
SMDS: Packet n, not addressed to usdebug serial packet
Use the debug serial packet privileged EXEC command to display more detailed serial interface debugging information than you can obtain using debug serial interface command. The no form of this command disables debugging output.
debug serial packet
no debug serial packet
Syntax Description
This command has no arguments or keywords.
Usage Guidelines
The debug serial packet command generates output that is dependent on the type of serial interface and the encapsulation that is running on that interface. The hardware platform also can impact debug serial packet output.
The debug serial packet command displays output for only SMDS encapsulations.
Examples
The following is sample output from the debug serial packet command when SMDS is enabled on the interface:
Router# debug serial packetInterface Serial2 Sending SMDS L3 packet:SMDS Header: Id: 00 RSVD: 00 BEtag: EC Basize: 0044Dest:E18009999999FFFF Src:C12015804721FFFF Xh:04030000030001000000000000000000SMDS LLC: AA AA 03 00 00 00 80 38SMDS Data: E1 19 01 00 00 80 00 00 0C 00 38 1F 00 0A 00 80 00 00 0C 01 2B 71SMDS Data: 06 01 01 0F 1E 24 00 EC 00 44 00 02 00 00 83 6C 7D 00 00 00 00 00SMDS Trailer: RSVD: 00 BEtag: EC Length: 0044As the above shows, when encapsulation is set to SMDS, debug serial packet displays the entire SMDS header (in hexadecimal), as well as some payload data on transmit or receive. This information is useful only when you have an understanding of the SMDS protocol. The first line of the output indicates either Sending or Receiving.
debug service-module
Use the debug service-module privileged EXEC command to display debugging information that monitors the detection and clearing of network alarms on the integrated channel service unit/data service unit (CSU/DSU) modules. The no form of this command disables debugging output.
debug service-module
no debug service-module
Syntax Description
This command has no arguments or keywords.
Usage Guidelines
Use this command to enable and disable debug logging for the serial 0 and serial 1 interfaces when an integrated CSU/DSU is present. This command enables debugging on all interfaces.
Network alarm status can also be viewed through the use of the show service-module command.
Note
Examples
The following is sample output from the debug service-module command:
Router# debug service-moduleSERVICE_MODULE(1): loss of signal ended after duration 00:05:36SERVICE_MODULE(1): oos/oof ended after duration 01:05:14SERVICE_MODULE(0): Unit has no clockSERVICE_MODULE(0): detects loss of signalSERVICE_MODULE(0): loss of signal ended after duration 00:00:33debug sgbp dial-bids
To display large scale dialout negotiations between the primary network access server and alternate network access servers, use the debug sgbp dial-bids privileged EXEC command. The no form of this command disables debugging output.
debug sgbp dial-bids
no debug sgbp dial-bids
Syntax Description
This command has no arguments or keywords.
Usage Guidelines
Use this command only when the sgbp dial-bids command has been configured.
Examples
The following is sample output from the debug sgbp dial-bids command:
router# debug sgbp dial-bids*Jan 1 00:25:03.643: SGBP-RES: New bid add request: 4B0 8 2 1 DAC0 1 1This indicates a new dialout bid has started.*Jan 1 00:25:03.643: SGBP-RES: Sent Discover message to ID 7B09B71E 49 bytesThe bid request has been sent.*Jan 1 00:25:03.647: SGBP-RES: Received Message of 49 length:*Jan 1 00:25:03.647: SGBP-RES: header 5 30 0 312 0 0 2D 0 0 0 0 0 0 0 3 0 0 0 1 1E AF 3A 41 7B 9 B7 1E 8 15 B 3 2 C 6 0 0 DA C0 D 4 0 0 E 3 1 F 3 1*Jan 1 00:25:03.647:*Jan 1 00:25:03.647: SGBP RES: Scan: Message type: Offer*Jan 1 00:25:03.647: SGBP RES: Scan: Len is 45*Jan 1 00:25:03.647: SGBP RES: Scan: Transaction ID: 3*Jan 1 00:25:03.647: SGBP RES: Scan: Message ID: 1*Jan 1 00:25:03.647: SGBP RES: Scan: Client ID: 1EAF3A41*Jan 1 00:25:03.651: SGBP RES: Scan: Server ID: 7B09B71E*Jan 1 00:25:03.651: SGBP RES: Scan: Resource type 8 length 21*Jan 1 00:25:03.651: SGBP RES: Scan: Phy-Port Media type: ISDN*Jan 1 00:25:03.651: SGBP RES: Scan: Phy-Port Min BW: 56000*Jan 1 00:25:03.651: SGBP RES: Scan: Phy-Port Num Links: 0*Jan 1 00:25:03.651: SGBP RES: Scan: Phy-Port User class: 1*Jan 1 00:25:03.651: SGBP RES: Scan: Phy-Port Priority: 1*Jan 1 00:25:03.651: SGBP-RES: received 45 length Offer packet*Jan 1 00:25:03.651: SGBP-RES: Offer from 7B09B71E for Transaction 3 accepted*Jan 1 00:25:03.651: SGBP RES: Server is uncongested. Immediate winAn alternate network access server has responded and won the bid.*Jan 1 00:25:03.651: SGBP-RES: Bid Succeeded handle 7B09B71E Server-id 4B0*Jan 1 00:25:03.651: SGBP-RES: Sent Dial-Req message to ID 7B09B71E 66 bytesThe primary network access server has asked the alternate server to dial.*Jan 1 00:25:04.651: SGBP-RES: QScan: Purging entry*Jan 1 00:25:04.651: SGBP-RES: deleting entry 6112E204 1EAF3A41 from list...debug sgbp error
To enable the display of debug messages about routing problems between members of a stack group, use the debug sgbp error command in privileged EXEC mode. To disable debug messages about routing problems between members of a stack group, use the no form of this command.
debug sgbp error
no debug sgbp error
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Enable the debug sgbp error command to enable the display of debug messages about routing problems between members of a stack group.
Note
Examples
One common configuration error is setting a source IP address for a stack member that does not match the locally defined IP address for the same stack member. The following debug output shows the error message that results from this misconfiguration:
Systema# debug sgbp error%SGBP-7-DIFFERENT - systemb's addr 10.1.1.2 is different from hello's addr 10.3.4.5This error means that the source IP address of the Stack Group Bidding Protocol (SGBP) hello message received from systemb does not match the IP address configured locally for systemb (through the sgbp member command). Correct this configuaration error by going to systemb and checking for multiple interfaces by which the SGBP hello can send the message.
Another common error message is:
Systema# debug sgbp error%SGBP-7-MISCONF, Possible misconfigured member routerk (10.1.1.6)This error message means that routerk is not defined locally, but is defined on another stack member. Correct this configuration error by defining routerk across all members of the stack group using the sgbp member command.
The following error message indicates that an SGBP peer is leaving the stack group:
Systema# debug sgbp error%SGBP-7-LEAVING:Member systemc leaving group stack1This error message indicates that the peer systemc is leaving the stack group. Systemc could be leaving the stack group intentionally, or a connectivity problem may exist.
The following error message indicates that an SGBP event was detected from an unknown peer:
Systema# debug sgbp error%SGBP-7-UNKNOWPEER:Event 0x10 from peer at 172.21.54.3An SGBP event came from a network host that was not recognizable as an SGBP peer. Check to see if a network media error could have corrupted the address, or if peer equipment is malfunctioning to generate corrupted packets. Depending on the network topology and firewalling of your network, SGBP packets from a nonpeer host could indicate probing and attempts to breach security.
Caution
Related Commands
debug sgbp hellos
To enable the display of debug messages for authentication between stack group members, use the debug sgbp hellos command in privileged EXEC mode. To disable debug messages about authentication between stack group members, use the no form of this command
debug sgbp hellos
no debug sgbp hellos
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Enable the debug sgbp hellos command to enable the display of debug messages for authentication between routers configured as members of a stack group.
Note
Examples
The following output from the debug sgbp hellos command shows systema sending a successful Challenge Handshake Authentication Protocol (CHAP) challenge to and receiving a response from systemb. Similarly, systemb sends out a challenge and receives a response from systema:
systema# debug sgbp hellos%SGBP-7-CHALLENGE: Send Hello Challenge to systemb group stack1%SGBP-7-CHALLENGED: Hello Challenge message from member systemb (10.1.1.2)%SGBP-7-RESPONSE: Send Hello Response to systemb group stack1%SGBP-7-CHALLENGE: Send Hello Challenge to systemb group stack1%SGBP-7-RESPONDED: Hello Response message from member systemb (10.1.1.2)%SGBP-7-AUTHOK: Send Hello Authentication OK to member systemb (10.1.1.2)%SGBP-7-INFO: Addr = 10.1.1.2 Reference = 0xC347DF7%SGBP-5-ARRIVING: New peer event for member systembThis debug output is self-explanitory.
If authentication fails, you may see one of the following messages in your debug output:
%SGBP-7-AUTHFAILED - Member systemb failed authenticationThis error message means that the remote systemb password for the stack group does not match the password defined on systema. To correct this error, make sure that both systema and systemb have the same password defined using the username command.
%SGBP-7-NORESP -Fail to respond to systemb group stack1, may not have password.This error message means that systema does not have a username or password defined. To correct this error, define a common group password across all stack members using the username command.
Related Commands
debug sgcp
To debug Simple Gateway Control Protocol, use the debug sgcp privileged EXEC command. To turn off debugging, use the no form of the command.
debug sgcp {errors | events | packet}
no debug sgcp {errors | events | packet}
Syntax Description
errors
Returns debug information about SGCP errors.
events
Returns debug information about SGCP events.
packet
Returns debug information about SGCP packets.
Command History
12.0(5)T
This command was introduced.
12.0(7)T
Support for this command was extended to the Cisco uBR924 cable modem.
Examples
See the following examples to enable and disable debugging at the specified level:
AS5300-TGW# debug sgcp errorsSimple Gateway Control Protocol errors debugging is onAS5300-TGW# no debug sgcp errorsSimple Gateway Control Protocol errors debugging is offAS5300-TGW#AS5300-TGW# debug sgcp eventsSimple Gateway Control Protocol events debugging is onAS5300-TGW# no debug sgcp eventsSimple Gateway Control Protocol events debugging is offAS5300-TGW#AS5300-TGW# debug sgcp packSimple Gateway Control Protocol packets debugging is onAS5300-TGW# no debug sgcp packSimple Gateway Control Protocol packets debugging is offAS5300-TGW#Related Commands
debug smrp all
Use the debug smrp all privileged EXEC command to display information about Simple Multicast Routing Protocol (SMRP) activity. The no form of this command disables debugging output.
debug smrp all
no debug smrp all
Syntax Description
This command has no arguments or keywords.
Usage Guidelines
Because the debug smrp all command displays all SMRP debugging output, it is processor intensive and should not be enabled when memory is scarce or in very high traffic situations.
For general debugging, use the debug smrp all command and turn off excessive transactions with the no debug smrp transaction command. This combination of commands will display various state changes and events without displaying every transaction packet. For debugging a specific feature such as a routing problem, use the debug smrp route and debug smrp transaction commands to see if packets are sent and received and which specific routes are affected. The show smrp traffic command is highly recommended as a troubleshooting method because it displays the SMRP counters.
For examples of the type of output you may see, refer to each of the commands listed in the "Related Commands" section.
Related Commands
debug smrp group
Use the debug smrp group privileged EXEC command to display information about SMRP group activity. The no form of this command disables debugging output.
debug smrp group
no debug smrp group
Syntax Description
This command has no arguments or keywords.
Usage Guidelines
The debug smrp group command displays information when a group is created or deleted and when a forwarding entry for a group is created, changed, or deleted.
For more information, refer to the show smrp group command described in the
Cisco IOS AppleTalk and Novell IPX Command Reference.Examples
The following is sample output from the debug smrp group command showing a port being created and deleted on group AT 20.34. (AT signifies that this is an AppleTalk network group.)
Router# debug smrp groupSMRP: Group AT 20.34, created on port 20.1 by 20.2SMRP: Group AT 20.34, deleted on port 20.1Table 140 lists the messages that may be generated with the debug smrp group command concerning the forwarding table.
Related Commands
Displays large scale dialout negotiations between the primary network access server and alternate network access servers.
debug smrp mcache
Use the debug smrp mcache privileged EXEC command to display information about SMRP multicast fast-switching cache entries. The no form of this command disables debugging output.
debug smrp mcache
no debug smrp mcache
Syntax Description
This command has no arguments or keywords.
Usage Guidelines
Use the show smrp mcache command (described in the Cisco IOS AppleTalk and Novell IPX Command Reference to display the entries in the SMRP multicast cache, and use the debug smrp mcache command to see whether the cache is being populated and invalidated.
Examples
The following is sample output from the debug smrp mcache command. In this example, the cache is created and populated for group AT 11.124. (AT signifies that this is an AppleTalk network group.)
Router# debug smrp mcacheSMRP: Cache createdSMRP: Cache populated for group AT 11.124mac - 090007400b7c00000c1740d9net - 001fef7500000014ff020a0a0aSMRP: Forward cache entry created for group AT 11.124SMRP: Forward cache entry validated for group AT 11.124SMRP: Forward cache entry invalidated for group AT 11.124SMRP: Forward cache entry deleted for group AT 11.124Table 141 lists all the messages that can be generated with the debug smrp mcache command concerning the multicast cache.
Related Commands
Displays large scale dialout negotiations between the primary network access server and alternate network access servers.
debug smrp neighbor
Use the debug smrp neighbor privileged EXEC command to display information about SMRP neighbor activity. The no form of this command disables debugging output.
debug smrp neighbor
no debug smrp neighbor
Syntax Description
This command has no arguments or keywords.
Usage Guidelines
The debug smrp neighbor command displays information when a neighbor operating state changes. A neighbor is an adjacent router. For more information, refer to the show smrp neighbor command described in the Cisco IOS AppleTalk and Novell IPX Command Reference.
Examples
The following is sample output from the debug smrp neighbor command. In this example, the neighbor on port 30.02 has changed state from normal operation to secondary operation.
Router# debug smrp neighborSMRP: Neighbor 30.2, state changed from "normal op" to "secondary op"Table 142 lists all the messages that can be generated with the debug smrp neighbor command concerning the neighbor table.
Related Commands
Displays large scale dialout negotiations between the primary network access server and alternate network access servers.
debug smrp port
Use the debug smrp port privileged EXEC command to display information about SMRP port activity. The no form of this command disables debugging output.
debug smrp port
no debug smrp port
Syntax Description
This command has no arguments or keywords.
Usage Guidelines
The debug smrp port command displays information when a port operating state changes.
For more information, refer to the show smrp port command described in the
Cisco IOS AppleTalk and Novell IPX Command Reference.Examples
The following is sample output from the debug smrp port command. In this example, port 30.1 has changed state from secondary negative to secondary operation to primary negative.
Router# debug smrp portSMRP: Port 30.1, state changed from "secondary neg" to "secondary op"SMRP: Port 30.1, secondary router changed from 0.0 to 30.1SMRP: Port 30.1, state changed from "secondary op" to "primary neg"Table 143 lists all the messages that can be generated with the debug smrp port command concerning the port table.
Related Commands
Displays large scale dialout negotiations between the primary network access server and alternate network access servers.
debug smrp route
Use the debug smrp route privileged EXEC command to display information about SMRP routing activity. The no form of this command disables debugging output.
debug smrp route
no debug smrp route
Syntax Description
This command has no arguments or keywords.
Usage Guidelines
For more information, refer to the show smrp route command described in the
Cisco IOS AppleTalk and Novell IPX Command Reference.Examples
The following is sample output from the debug smrp route command. In this example, poison notification is received from port 30.2. Poison notification is the receipt of a poisoned route on a nonparent port.
Router# debug smrp routeSMRP: Route AT 20-20, poison notification from 30.2SMRP: Route AT 30-30, poison notification from 30.2Table 144 lists all the messages that can be generated with the debug smrp route command concerning the routing table. In Table 144, the term route does not refer to an address but rather it is a network range.
Related Commands
Displays large scale dialout negotiations between the primary network access server and alternate network access servers.
debug smrp transaction
Use the debug smrp transaction privileged EXEC command to display information about SMRP transactions. The no form of this command disables debugging output.
debug smrp transaction
no debug smrp transaction
Syntax Description
This command has no arguments or keywords.
Examples
The following is sample output from the debug smrp transaction command. In this example, a secondary node request is sent out to all routers on port 30.1.
Router# debug smrp transactionSMRP: Transaction for port 30.1, secondary node request (seq 8435) sent to all routersSMRP: Transaction for port 30.1, secondary node request (seq 8435) sent to all routersSMRP: Transaction for port 30.1, secondary node request (seq 8435) sent to all routersSMRP: Transaction for port 30.1, secondary node request (seq 8435) sent to all routersTable 145 lists all the messages that can be generated with the debug smrp route command.
Related Commands
Displays large scale dialout negotiations between the primary network access server and alternate network access servers.
debug snasw dlc
Use the debug snasw dlc privileged EXEC command to display frame information entering and leaving the SNA Switch in real time to the console.
debug snasw dlc detail
Syntax Description
detail
Indicates that in addition to a one-line description of the frame being displayed, an entire hexadecimal dump of the frame will follow.
Defaults
By default, a one line description of the frame is displayed.
Caution
Command History
Examples
The following is an example of the debug snasw dlc command:
router# debug snasw dlcSequenceNumber Size of ISR/Link SNA BTU HPR Description of frame343 MVSD In sz:134 ISR fmh5 DLUR Rq ActPU NETA.APPNRA29344 MVSD Out sz:12 ISR +Rsp IPM slctd nws:0008345 @I000002 Out sz:18 ISR Rq ActPU346 MVSD Out sz:273 ISR fmh5 TOPOLOGY UPDATE347 @I000002 In sz:9 ISR +Rsp Data348 @I000002 In sz:12 ISR +Rsp IPM slctd nws:0002349 @I000002 In sz:29 ISR +Rsp ActPU350 MVSD Out sz:115 ISR fmh5 DLUR +Rsp ActPU351 MVSD In sz:12 ISR +Rsp IPM slctd nws:0007352 MVSD In sz:88 ISR fmh5 DLUR Rq ActLU NETA.MARTLU1353 MVSD Out sz:108 ISR fmh5 REGISTER354 @I000002 Out sz:27 ISR Rq ActLU NETA.MARTLU1Related Commands
debug snasw ips
Use the debug snasw ips privileged EXEC command to display internal signal information between the SNA Switch and the console in real time.
debug snasw dlc
Syntax Description
This command has no arguments or keywords.
Defaults
By default, a one-line description of the interprocess signal is displayed.
Caution
Command History
Examples
The following is an example of the debug snasw ips command:
router# debug snasw ipsSequenceNumber Sending ReceivingSignal Name Process Process Queue11257 : DEALLOCATE_RCB : --(0) -> RM(2130000) Q 411258 : RCB_DEALLOCATED : RM(2130000) -> PS(22E0000) Q 211259 : RCB_DEALLOCATED : --(0) -> PS(22E0000) Q 211260 : VERB_SIGNAL : PS(22E0000) -> DR(20F0000) Q 211261 : FREE_SESSION : --(0) -> RM(2130000) Q 211262 : BRACKET_FREED : RM(2130000) -> HS(22FB0001) Q 211263 : BRACKET_FREED : --(0) -> HS(22FB0001) Q 211264 : VERB_SIGNAL : --(0) -> DR(20F0000) Q 211265 : DLC_MU : DLC(2340000) -> PC(22DD0001) Q 211266 : DLC_MU : --(0) -> PC(22DD0001) Q 2Related Commands
snasw ipstrace
Captures interprocess signal information between Switching Services components.
debug snmp packet
To display information about every SNMP packet sent or received by the router, use the debug snmp packet privileged EXEC command. The no form of this command disables debugging output.
debug snmp packet
no debug snmp packet
Syntax Description
This command has no arguments or keywords.
Examples
The following is sample output from the debug snmp packet command. In this example, the router receives a get-next request from the host at 172.16.63.17 and responds with the requested information.
Router# debug snmp packetSNMP: Packet received via UDP from 172.16.63.17 on Ethernet0SNMP: Get-next request, reqid 23584, errstat 0, erridx 0sysUpTime = NULL TYPE/VALUEsystem.1 = NULL TYPE/VALUEsystem.6 = NULL TYPE/VALUESNMP: Response, reqid 23584, errstat 0, erridx 0sysUpTime.0 = 2217027system.1.0 = Cisco Internetwork Operating System Softwaresystem.6.0 =SNMP: Packet sent via UDP to 172.16.63.17Based on the kind of packet sent or received, the output may vary. For get-bulk requests, a line similar to the following is displayed:
SNMP: Get-bulk request, reqid 23584, nonrptr 10, maxreps 20For traps, a line similar to the following is displayed:
SNMP: V1 Trap, ent 1.3.6.1.4.1.9.1.13, gentrap 3, spectrap 0Table 146 describes the significant fields in these displays.
debug snmp requests
To display information about every SNMP request made by the SNMP manager, use the debug snmp requests privileged EXEC command. The no form of this command disables debugging output.
debug snmp requests
no debug snmp requests
Syntax Description
This command has no arguments or keywords.
Examples
The following is sample output from the debug snmp requests command:
Router# debug snmp requestsSNMP Manager API: requestdest: 171.69.58.33.161, community: publicretries: 3, timeout: 30, mult: 2, use session rttuserdata: 0x0Table 147 describes the fields shown in the display.
debug sntp adjust
Use the debug sntp adjust privileged EXEC command to display information about SNTP clock adjustments. The no form of this command disables debugging output.
debug sntp adjust
no debug sntp adjust
Syntax Description
This command has no arguments or keywords.
Examples
The following is sample output from the debug sntp adjust command output when an offset to the time reported by the configured NTP server is calculated. The offset indicates the difference between the router time and the actual time (as kept by the server) and is displayed in milliseconds. The clock time is then successfully changed to the accurate time by adding the offset to the current router time.
Router# debug sntp adjustDelay calculated, offset 3.48Clock slewed.The following is sample output from the debug sntp adjust command when an offset to the time reported by a broadcast server is calculated. Since the packet is a broadcast packet, no transmission delay can be calculated. However, in this case, the offset is too large, so the clock is reset to the correct time.
Router# debug sntp adjustNo delay calculated, offset 11.18Clock stepped.debug sntp packets
Use the debug sntp packets privileged EXEC command to display information about SNTP packets sent and received. The no form of this command disables debugging output.
debug sntp packets
no debug sntp packets
Syntax Description
This command has no arguments or keywords.
Examples
The following is sample output from the debug sntp packets command when a message is received:
Router# debug sntp packetsReceived SNTP packet from 172.16.186.66, length 48leap 0, mode 1, version 3, stratum 4, ppoll 1024rtdel 00002B00, rtdsp 00003F18, refid AC101801 (172.16.24.1)ref B7237786.ABF9CDE5 (23:28:06.671 UTC Tue May 13 1997)org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)xmt B7237B5C.A7DE94F2 (23:44:28.655 UTC Tue May 13 1997)inp AF3BD529.810B66BC (00:19:53.504 UTC Mon Mar 1 1993)The following is sample output from the debug sntp packets command when a message is sent:
Router# debug sntp packetsSending SNTP packet to 172.16.25.1xmt AF3BD455.FBBE3E64 (00:16:21.983 UTC Mon Mar 1 1993)Table 148 describes the significant fields.
debug sntp select
Use the debug sntp select privileged EXEC command to display information about SNTP server selection. The no form of this command disables debugging output.
debug sntp select
no debug sntp select
Syntax Description
This command has no arguments or keywords.
Examples
The following is sample output from the show sample debug sntp select command. In this example, the router will synchronize its time to server at 172.16.186.66.
Router# debug sntp selectSNTP: Selected 172.16.186.66debug source bridge
Use the debug source bridge privileged EXEC command to display information about packets and frames transferred across a source-route bridge. The no form of this command disables debugging output.
debug source bridge
no debug source bridge
Syntax Description
This command has no arguments or keywords.
Examples
The following is sample output from the debug source bridge output for peer bridges using TCP as a transport mechanism. The remote source-route bridging (RSRB) network configuration has ring 2 and ring 1 bridged together through remote peer bridges. The remote peer bridges are connected via a serial line and use TCP as the transport mechanism.
Router# debug source bridgeRSRB: remote explorer to 5/131.108.250.1/1996 srn 2 [C840.0021.0050.0000]RSRB: Version/Ring XReq sent to peer 5/131.108.250.1/1996RSRB: Received version reply from 5/131.108.250.1/1996 (version 2)RSRB: DATA: 5/131.108.250.1/1996 Ring Xchg Rep, trn 2, vrn 5, off 18, len 10RSRB: added bridge 1, ring 1 for 5/131.108.240.1/1996RSRB: DATA: 5/131.108.250.1/1996 Explorer trn 2, vrn 5, off 18, len 69RSRB: DATA: 5/131.108.250.1/1996 Forward trn 2, vrn 5, off 0, len 92RSRB: DATA: forward Forward srn 2, br 1, vrn 5 to peer 5/131.108.250.1/1996The following line indicates that a remote explorer frame has been sent to IP address 131.108.250.1 and, like all RSRB TCP connections, has been assigned port 1996. The bridge belongs to ring group 5. The explorer frame originated from ring number 2. The routing information field (RIF) descriptor has been generated by the local station and indicates that the frame was sent out via bridge 1 onto virtual ring 5.
RSRB: remote explorer to 5/131.108.250.1/1996 srn 2 [C840.0021.0050.0000]The following line indicates that a request for remote peer information has been sent to IP address 131.108.250.1, TCP port 1996. The bridge belongs to ring group 5.
RSRB: Version/Ring XReq sent to peer 5/131.108.250.1/1996The following line is the response to the version request previously sent. The response is sent from IP address 131.108.250.1, TCP port 1996. The bridge belongs to ring group 5.
RSRB: Received version reply from 5/131.108.250.1/1996 (version 2)The following line is the response to the ring request previously sent. The response is sent from IP address 131.108.250.1, TCP port 1996. The target ring number is 2, virtual ring number is 5, the offset is 18, and the length of the frame is 10 bytes.
RSRB: DATA: 5/131.108.250.1/1996 Ring Xchg Rep, trn 2, vrn 5, off 0, len 10The following line indicates that bridge 1 and ring 1 were added to the source-bridge table for IP address 131.108.250.1, TCP port 1996:
RSRB: added bridge 1, ring 1 for 5/131.108.250.1/1996The following line indicates that a packet containing an explorer frame came across virtual ring 5 from IP address 131.108.250.1, TCP port 1996. The packet is 69 bytes in length. This packet is received after the Ring Exchange information was received and updated on both sides.
RSRB: DATA: 5/131.108.250.1/1996 Explorer trn 2, vrn 5, off 18, len 69The following line indicates that a packet containing data came across virtual ring 5 from IP address 131.108.250.1 over TCP port 1996. The packet is being placed on the local target ring 2.The packet is 92 bytes in length.
RSRB: DATA: 5/131.108.250.1/1996 Forward trn 2, vrn 5, off 0, len 92The following line indicates that a packet containing data is being forwarded to the peer that has IP 131.108.250.1 address belonging to local ring 2 and bridge 1. The packet is forwarded via virtual ring 5. This packet is sent after the Ring Exchange information was received and updated on both sides.
RSRB: DATA: forward Forward srn 2, br 1, vrn 5 to peer 5/131.108.250.1/1996The following is sample output from the debug source bridge command for peer bridges using direct encapsulation as a transport mechanism. The RSRB network configuration has ring 1 and ring 2 bridged together through peer bridges. The peer bridges are connected via a serial line and use TCP as the transport mechanism.
Router# debug source bridgeRSRB: remote explorer to 5/Serial1 srn 1 [C840.0011.0050.0000]RSRB: Version/Ring XReq sent to peer 5/Serial1RSRB: Received version reply from 5/Serial1 (version 2)RSRB: IFin: 5/Serial1 Ring Xchg, Rep trn 0, vrn 5, off 0, len 10RSRB: added bridge 1, ring 1 for 5/Serial1The following line indicates that a remote explorer frame was sent to remote peer Serial1, which belongs to ring group 5. The explorer frame originated from ring number 1. The routing information field (RIF) descriptor 0011.0050 was generated by the local station and indicates that the frame was sent out via bridge 1 onto virtual ring 5.
RSRB: remote explorer to 5/Serial1 srn 1 [C840.0011.0050.0000]The following line indicates that a request for remote peer information was sent to Serial1. The bridge belongs to ring group 5.
RSRB: Version/Ring XReq sent to peer 5/Serial1The following line is the response to the version request previously sent. The response is sent from Serial 1. The bridge belongs to ring group 5 and the version is 2.
RSRB: Received version reply from 5/Serial1 (version 2)The following line is the response to the ring request previously sent. The response is sent from Serial1. The target ring number is 2, virtual ring number is 5, the offset is 0, and the length of the frame is 39 bytes.
RSRB: IFin: 5/Serial1 Ring Xchg Rep, trn 2, vrn 5, off 0, len 39The following line indicates that bridge 1 and ring 1 were added to the source-bridge table for Serial1:
RSRB: added bridge 1, ring 1 for 5/Serial1debug source error
Use the debug source error privileged EXEC command to display source-route bridging errors. The no form of this command disables debugging output.
debug source error
no debug source error
Syntax Description
This command has no arguments or keywords.
Usage Guidelines
The debug source error command displays some output also found in the debug source bridge output. Refer to the debug source bridge command for other possible output.
Examples
In all of the following examples of debug source error command messages, the variable number is the Token Ring interface. For example, if the line of output starts with SRB1, the output relates to the Token Ring 1 interface. SRB indicates a source-route bridging message. RSRB indicates a remote source-route bridging message. SRTLB indicates a source-route translational bridging message.
In the following example, a packet of protocol protocol-type was dropped:
SRBnumber drop: Routed protocol protocol-typeIn the following example, an Address Resolution Protocol (ARP) packet was dropped. ARP is defined in RFC 826.
SRBnumber drop:TYPE_RFC826_ARPIn the following example, the current Cisco IOS version does not support Qualified Logical Link Control (QLLC). Reconfigure the router with an image that has the IBM feature set.
RSRB: QLLC not supported in version versionPlease reconfigure.In the following example, the packet was dropped because the outgoing interface of the router was down:
RSRB IF: outgoing interface not up, dropping packetIn the following example, the router received an out-of-sequence IP sequence number in a Fast Sequenced Transport (FST) packet. FST has no recovery for this problem like TCP encapsulation does.
RSRB FST: bad sequence number dropping.In the following example, the router was unable to locate the virtual interface:
RSRB: couldn't find virtual interfaceIn the following example, the peer router's TCP queue is full. TCPD indicates that this is a TCP debug.
RSRB TCPD: tcp queue full for peerIn the following example, the router was unable to send data to the peer router. A result of 1 indicates that the TCP queue is full. A result of -1 indicates that the RSRB peer is closed.
RSRB TCPD: tcp send failed for peer resultIn the following example, the Routing Information Identifier was not set in the explorer packet going forward. The packet will not support SRB, so it is dropped.
vrforward_explorer - RII not setIn the following example, a packet sent to a virtual bridge in the router did not include a routing information field (RIF) to tell the router which route to use:
RSRB: no RIF on packet sent to virtual bridgeThe following example indicates that the RIF did not contain any information or the length field was set to zero:
RSRB: RIF length of zero sent to virtual bridgeThe following message occurs when the local service access point (LSAP) is out of range. The variable lsap-out is the value, type is the type of RSRB peer, and state is the state of the RSRB peer.
VRP: rsrb_lsap_out = lsap-out, type = type, state = stateIn the following message, the router is unable to find another router with which to exchange bridge protocol data units (BPDU's). BPDU's are exchanged to set up the spanning tree and determine the forwarding path.
RSRB(span): BPDU's peer not foundRelated Commands
Displays information about packets and frames transferred across a source-route bridge.
Displays information on source-route bridging activity.
debug source event
Use the debug source event privileged EXEC command to display information on source-route bridging activity. The no form of this command disables debugging output.
debug source event
no debug source event
Syntax Description
This command has no arguments or keywords.
Usage Guidelines
Some of the output from the debug source bridge and debug source error commands is identical to the output of this command.
Note
Examples
The following is sample output from the debug source event command:
Router# debug source eventRSRB0: forward (srn 5 bn 1 trn 10), src: 8110.2222.33c1 dst: 1000.5a59.04f9[0800.3201.00A1.0050]RSRB0: forward (srn 5 bn 1 trn 10), src: 8110.2222.33c1 dst: 1000.5a59.04f9[0800.3201.00A1.0050]RSRB0: forward (srn 5 bn 1 trn 10), src: 8110.2222.33c1 dst: 1000.5a59.04f9[0800.3201.00A1.0050]RSRB0: forward (srn 5 bn 1 trn 10), src: 8110.2222.33c1 dst: 1000.5a59.04f9[0800.3201.00A1.0050]RSRB0: forward (srn 5 bn 1 trn 10), src: 8110.2222.33c1 dst: 1000.5a59.04f9[0800.3201.00A1.0050]Table 149 describes the significant fields.
In the following example messages, SRBnumber or RSRBnumber denotes a message associated with interface Token Ring number. A number of 99 denotes the remote side of the network.
SRBnumber: no path, s: source-MAC-addr d: dst-MAC-addr rif: rifIn the preceding example, a bridgeable packet came in on interface Token Ring number but there was nowhere to send it. This is most likely a configuration error. For example, an interface has source bridging turned on, but it is not connected to another source bridging interface or a ring group.
In the following example, a bridgeable packet has been forwarded from Token Ring number to the target ring. The two interfaces are directly linked.
SRBnumber: direct forward (srn ring bn bridge trn ring)In the following examples, a proxy explorer reply was not generated because there was no way to get to the address from this interface. The packet came from the node with the first address.
SRBnumber: br dropped proxy XID, address for address, wrong vring (rem)SRBnumber: br dropped proxy TEST, address for address, wrong vring (rem)SRBnumber: br dropped proxy XID, address for address, wrong vring (local)SRBnumber: br dropped proxy TEST, address for address, wrong vring (local)SRBnumber: br dropped proxy XID, address for address, no pathSRBnumber: br dropped proxy TEST, address for address, no pathIn the following example, an appropriate proxy explorer reply was generated on behalf of the second address. It is sent to the first address.
SRBnumber: br sent proxy XID, address for address[rif]SRBnumber: br sent proxy TEST, address for address[rif]The following example indicates that the broadcast bits were not set, or that the routing information indicator on the packet was not set:
SRBnumber: illegal explorer, s: source-MAC-addr d: dst-MAC-addr rif: rifThe following example indicates that the direction bit in the RIF field was set, or that an odd packet length was encountered. Such packets are dropped.
SRBnumber: bad explorer control, D set or oddThe following example indicates that a spanning explorer was dropped because the spanning option was not configured on the interface:
SRBnumber: span dropped, input off, s: source-MAC-addr d: dst-MAC-addr rif: rifThe following example indicates that a spanning explorer was dropped because it had traversed the ring previously:
SRBnumber: span violation, s: source-MAC-addr d: dst-MAC-addr rif: rifThe following example indicates that an explorer was dropped because the maximum hop count limit was reached on that interface:
SRBnumber: max hops reached - hop-cnt, s: source-MAC-addr d: dst-MAC-addr rif: rifThe following example indicates that the ring exchange request was sent to the indicated peer. This request tells the remote side which rings this node has and asks for a reply indicating which rings that side has.
RSRB: sent RingXreq to ring-group/ip-addrThe following example indicates that a message was sent to the remote peer. The label variable can be AHDR (active header), PHDR (passive header), HDR (normal header), or DATA (data exchange), and op can be Forward, Explorer, Ring Xchg, Req, Ring Xchg, Rep, Unknown Ring Group, Unknown Peer, or Unknown Target Ring.
RSRB: label: sent op to ring-group/ip-addrThe following example indicates that the remote bridge and ring pair were removed from or added to the local ring group table because the remote peer changed:
RSRB: removing bn bridge rn ring from ring-group/ip-addrRSRB: added bridge bridge, ring ring for ring-group/ip-addrThe following example shows miscellaneous remote peer connection establishment messages:
RSRB: peer ring-group/ip-addr closed [last state n]RSRB: passive open ip-addr(remote port) -> local portRSRB: CONN: opening peer ring-group/ip-addr, attempt nRSRB: CONN: Remote closed ring-group/ip-addr on openRSRB: CONN: peer ring-group/ip-addr open failed, reason[code]The following example shows that an explorer packet was propagated onto the local ring from the remote ring group:
RSRBn: sent local explorer, bridge bridge trn ring, [rif]The following messages indicate that the remote source-route bridging code found the packet was in error:
RSRBn: ring group ring-group not foundRSRBn: explorer rif [rif] not long enoughThe following example indicates that a buffer could not be obtained for a ring exchange packet (this is an internal error):
RSRB: couldn't get pak for ringXchgThe following example indicates that a ring exchange packet was received that had an incorrect length (this is an internal error):
RSRB: XCHG: req/reply badly formed, length pak-length, peer peer-idThe following example indicates that a ring entry was removed for the peer; the ring was possibly disconnected from the network, causing the remote router to send an update to all its peers.
RSRB: removing bridge bridge ring ring from peer-id ring-typeThe following example indicates that a ring entry was added for the specified peer; the ring was possibly added to the network, causing the other router to send an update to all its peers.
RSRB: added bridge bridge, ring ring for peer-idThe following example indicates that no memory was available to add a ring number to the ring group specified (this is an internal error):
RSRB: no memory for ring element ring-groupThe following example indicates that memory was corrupted for a connection block (this is an internal error):
RSRB: CONN: corrupt connection blockThe following example indicates that a connector process started, but that there was no packet to process (this is an internal error):
RSRB: CONN: warning, no initial packet, peer: ip-addr peer-pointerThe following example indicates that a packet was received with a version number different from the one present on the router:
RSRB: IF New version. local=local-version, remote=remote-version,pak-op-code peer-idThe following example indicates that a packet with a bad op code was received for a direct encapsulation peer (this is an internal error):
RSRB: IFin: bad op op-code (op code string) from peer-idThe following example indicates that the virtual ring header will not fit on the packet to be sent to the peer (this is an internal error):
RSRB: vrif_sender, hdr won't fitThe following example indicates that the specified peer is being opened. The retry count specifies the number of times the opening operation is attempted.
RSRB: CONN: opening peer peer-id retry-countThe following example indicates that the router, configured for FST encapsulation, received a version reply to the version request packet it had sent previously:
RSRB: FST Rcvd version reply from peer-id (version version-number)The following example indicates that the router, configured for FST encapsulation, sent a version request packet to the specified peer:
RSRB: FST Version Request. op = opcode, peer-idThe following example indicates that the router received a packet with a bad op code from the specified peer (this is an internal error):
RSRB: FSTin: bad op opcode (op code string) from peer-idThe following example indicates that the TCP connection between the router and the specified peer is being aborted:
RSRB: aborting ring-group/peer-id (vrtcpd_abort called)The following example indicates that an attempt to establish a TCP connection to a remote peer timed out:
RSRB: CONN: attempt timed outThe following example indicates that a packet was dropped because the ring group number in the packet did not correlate with the ring groups configured on the router:
RSRBnumber: ring group ring-group not founddebug span
Use the debug span privileged EXEC command to display information on changes in the spanning-tree topology when debugging a transparent bridge. The no form of this command disables debugging output.
debug span
no debug span
Syntax Description
This command has no arguments or keywords.
Usage Guidelines
This command is useful for tracking and verifying that the spanning-tree protocol is operating correctly.
Examples
IEEE Spanning Tree
The following is sample output from the debug span command for an IEEE BPDU packet:
Router# debug spanST: Ether4 0000000000000A080002A02D6700000000000A080002A02D6780010000140002000F00The following is sample output from the debug span command:
ST: Ether4 0000000000000A080002A02D6700000000000A080002A02D6780010000140002000F00A B C D E F G H I J K L M N OTable 150 describes the significant fields.
DEC Spanning Tree
The following is sample output from the debug span command for a DEC BPDU packet:
Router# debug spanST: Ethernet4 E1190100000200000C01A2C90064008000000C0106CE0A01050F1E6AThe following is sample output from the debug span command:
E1 19 01 00 0002 00000C01A2C9 0064 0080 00000C0106CE 0A 01 05 0F 1E 6AA B C D E F G H I J K L M N OTable 151 describes the significant fields.
debug sse
Use the debug sse privileged EXEC command to display information for the silicon switching engine (SSE) processor. The no form of this command disables debugging output.
debug sse
no debug sse
Syntax Description
This command has no arguments or keywords.
Usage Guidelines
Use the debug sse command to observe statistics and counters maintained by the SSE.
Examples
The following is sample output from the debug sse command:
Router# debug sseSSE: IP number of cache entries changed 273 274SSE: bridging enabledSSE: interface Ethernet0/0 icb 0x30 addr 0x29 status 0x21A040 protos 0x11SSE: interface Ethernet0/1 icb 0x33 addr 0x29 status 0x21A040 protos 0x11SSE: interface Ethernet0/2 icb 0x36 addr 0x29 status 0x21A040 protos 0x10SSE: interface Ethernet0/3 icb 0x39 addr 0x29 status 0x21A040 protos 0x11SSE: interface Ethernet0/4 icb 0x3C addr 0x29 status 0x21A040 protos 0x10SSE: interface Ethernet0/5 icb 0x3F addr 0x29 status 0x21A040 protos 0x11SSE: interface Hssi1/0 icb 0x48 addr 0x122 status 0x421E080 protos 0x11SSE: cache update took 316ms, elapsed 320msThe following line indicates that the SSE cache is being updated due to a change in the IP fast switching cache:
SSE: IP number of cache entries changed 273 274The following line indicates that bridging functions were enabled on the SSE:
SSE: bridging enabledThe following lines indicate that the SSE is now loaded with information about the interfaces:
SSE: interface Ethernet0/0 icb 0x30 addr 0x29 status 0x21A040 protos 0x11SSE: interface Ethernet0/1 icb 0x33 addr 0x29 status 0x21A040 protos 0x11SSE: interface Ethernet0/2 icb 0x36 addr 0x29 status 0x21A040 protos 0x10SSE: interface Ethernet0/3 icb 0x39 addr 0x29 status 0x21A040 protos 0x11SSE: interface Ethernet0/4 icb 0x3C addr 0x29 status 0x21A040 protos 0x10SSE: interface Ethernet0/5 icb 0x3F addr 0x29 status 0x21A040 protos 0x11SSE: interface Hssi1/0 icb 0x48 addr 0x122 status 0x421E080 protos 0x11The following line indicates that the SSE took 316 ms of processor time to update the SSE cache. The value of 320 ms represents the total time elapsed while the cache updates were performed.
SSE: cache update took 316ms, elapsed 320msdebug standby
Use the debug standby privileged EXEC command to display Hot Standby Protocol state changes. The no form of this command disables debugging output.
debug standby
no debug standby
Syntax Description
This command has no arguments or keywords.
Usage Guidelines
The debug standby command displays Hot Standby Protocol state changes and debugging information regarding transmission and receipt of Hot Standby Protocol packets. Use this command to determine whether hot standby routers recognize one another and take the proper actions.
Examples
The following is sample output from the debug standby command:
Router# debug standbySB: Ethernet0 state Virgin -> ListenSB: Starting up hot standby processSB:Ethernet0 Hello in 192.168.72.21 Active pri 90 hel 3 hol 10 ip 192.168.72.29SB:Ethernet0 Hello in 192.168.72.21 Active pri 90 hel 3 hol 10 ip 192.168.72.29SB:Ethernet0 Hello in 192.168.72.21 Active pri 90 hel 3 hol 10 ip 192.168.72.29SB:Ethernet0 Hello in 192.168.72.21 Active pri 90 hel 3 hol 10 ip 192.168.72.29SB: Ethernet0 state Listen -> SpeakSB:Ethernet0 Hello out 192.168.72.20 Speak pri 100 hel 3 hol 10 ip 192.168.72.29SB:Ethernet0 Hello in 192.168.72.21 Active pri 90 hel 3 hol 10 ip 192.168.72.29SB:Ethernet0 Hello out 192.168.72.20 Speak pri 100 hel 3 hol 10 ip 192.168.72.29SB:Ethernet0 Hello in 192.168.72.21 Active pri 90 hel 3 hol 10 ip 192.168.72.29SB:Ethernet0 Hello out 192.168.72.20 Speak pri 100 hel 3 hol 10 ip 192.168.72.29SB:Ethernet0 Hello in 192.168.72.21 Active pri 90 hel 3 hol 10 ip 192.168.72.29SB: Ethernet0 state Speak -> StandbySB:Ethernet0 Hello out 192.168.72.20 Standby pri 100 hel 3 hol 10 ip 192.168.72.29SB:Ethernet0 Hello in 192.168.72.21 Active pri 90 hel 3 hol 10 ip 192.168.72.29SB:Ethernet0 Hello out 192.168.72.20 Standby pri 100 hel 3 hol 10 ip 192.168.72.29SB:Ethernet0 Hello in 192.168.72.21 Active pri 90 hel 3 hol 10 ip 192.168.72.29SB:Ethernet0 Hello out 192.168.72.20 Standby pri 100 hel 3 hol 10 ip 192.168.72.29SB:Ethernet0 Hello in 192.168.72.21 Active pri 90 hel 3 hol 10 ip 192.168.72.29SB: Ethernet0 Coup out 192.168.72.20 Standby pri 100 hel 3 hol 10 ip 192.168.72.29SB: Ethernet0 state Standby -> ActiveSB:Ethernet0 Hello out 192.168.72.20 Active pri 100 hel 3 hol 10 ip 192.168.72.29SB:Ethernet0 Hello in 192.168.72.21 Speak pri 90 hel 3 hol 10 ip 192.168.72.29SB:Ethernet0 Hello out 192.168.72.20 Active pri 100 hel 3 hol 10 ip 192.168.72.29SB:Ethernet0 Hello in 192.168.72.21 Speak pri 90 hel 3 hol 10 ip 192.168.72.29SB:Ethernet0 Hello out 192.168.72.20 Active pri 100 hel 3 hol 10 ip 192.168.72.29Table 152 describes the significant fields.
The following line indicates that the router is initiating the Hot Standby Protocol. The standby ip interface configuration command enables hot standby.
SB: Starting up hot standby processThe following line indicates that a state transition occurred on the interface:
SB: Ethernet0 state Listen -> Speakdebug stun packet
Use the debug stun packet privileged EXEC command to display information on packets traveling through the serial tunnel (STUN) links. The no form of this command disables debugging output.
debug stun packet [group] [address]
no debug stun packet [group] [address]
Syntax Description
Usage Guidelines
Because using this command is processor intensive, it is best to use it after hours, rather than in a production environment. It is also best to turn this command on by itself, rather than use it in conjunction with other debug commands.
Examples
The following is sample output from the debug stun packet command:
The following line describes an X1 type of packet:
STUN sdlc: 0:00:04 Serial3 NDI: (0C2/008) U: SNRM PF:1Table 153 describes the significant fields in this line of debug stun packet output.
The following line of output describes an X2 type of packet:
STUN sdlc: 0:00:00 Serial3 SDI: (0C2/008) S: RR PF:1 NR:000All the fields in the previous line of output match those for an X1 type of packet, except the last field, which is additional. NR:000 indicates a receive count of 0; the range for the receive count is 0 to 7.
The following line of output describes an X3 type of packet:
STUN sdlc: 0:00:00 Serial3 SDI: (0C2/008) S:I PF:1 NR:000 NS:000All fields in the previous line of output match those for an X2 type of packet, except the last field, which is additional. NS:000 indicates a send count of 0; the range for the send count is 0 to 7.
debug sw56
Use the debug sw56 privileged EXEC command to display debug information for switched 56K services.
debug sw56
Syntax Description
This command has no arguments or keywords.
debug syscon perfdata
Use the debug syscon perfdata privileged EXEC command to display messages related to performance data collection. The no form of this command disables debugging output.
debug syscon perfdata
no debug syscon perfdata
Syntax Description
This command has no arguments or keywords.
Usage Guidelines
This command is primarily useful to your technical support representative.
Examples
The following is sample output from the debug syscon perfdata command. In this example, the CallFail poll group is configured and applied to shelf 1111. The system determines when the next polling cycle should occur and polls the shelf at the appropriate time. The data is stored in the file CallFail.891645120, and an older file is deleted.
SysCont# debug syscon perfdataPERF: Applying 'CallFail' to shelf 1111PERF: Setting up objects for SNMP polling: 'CallFail', shelf 1111PERF: year hours mins secs msecs = 1998 15 11 1 5PERF: Start 'CallFail' timer, next cycle in 0 mins, 59 secsPERF: Timer event: CallFail, 4 minutesPERF: Polling 'CallFail', shelf 1111, pc 60AEFDF0PERF: SNMP resp: Type 6, 'CallFail', shelf 1111, error_st 0PERF: Logged polled data to disk0:/performance/shelf-1111/CallFail.891645120PERF: Deleted disk0:/performance/shelf-1111/CallFail.891637469debug syscon sdp
Use the debug syscon sdp privileged EXEC command to display messages related to the Shelf Discovery Protocol (SDP). The no form of this command disables debugging output.
debug syscon sdp
no debug syscon sdp
Syntax Description
This command has no arguments or keywords.
Usage Guidelines
Use this command to display information about SDP packets exchanged between the shelf and the system controller.
Examples
The following sample output from the debug syscon sdp command shows the system controller discovering a managed shelf. In the first few lines, the system controller receives a Hello packet from shelf 99 at 172.23.66.106. The system controller responds with a Hello packet. When the shelf sends another Hello packet, the system controller resets the timer and sends another packet.
Syscon# debug syscon sdpSYSCTLR: Hello packet received via UDP from 172.23.66.106%SYSCTLR-6-SHELF_ADD: Shelf 99 discovered located at address 172.23.66.106Hello packet sent to the RS located at 172.23.66.106SYSCTLR: Hello packet received via UDP from 172.23.66.106Timer for shelf 99 updated, shelf is aliveHello packet sent to the RS located at 172.23.66.106The following sample output from the debug syscon sdp command shows the shelf contacting the system controller. The shelf sends a Hello packet to the system controller at 172.23.66.111. The system controller responds with the autoconfiguration commands. The remaining lines show the Hello packets exchanged between the shelf and the system controller.
Shelf# debug syscon sdpSYSCTLR: Hello packet sent to the SYSCTLR at 172.23.66.111SYSCTLR: Command packet received from SYSCTLRFeb 24 17:24:16.713: %SHELF-6-SYSCTLR_ESTABLISHED: Configured via system controller located at 172.23.66.111SYSCTLR: Rcvd HELLO from SYSCTLR at 172.23.66.111SYSCTLR: Hello packet sent to the SYSCTLR at 172.23.66.111SYSCTLR: Rcvd HELLO from SYSCTLR at 172.23.66.111debug syslog-server
Use the debug syslog-server privileged EXEC command to display information about the syslog server process. The no form of this command disables debugging output.
debug syslog-server
no debug syslog-server
Syntax Description
This command has no arguments or keywords.
Usage Guidelines
This command outputs a message every time the syslog server receives a message. It also displays information about subfile creation, removal, and renaming.
Use this command when subfiles are not being created as configured or data is not being written to subfiles. This command is also useful for detecting syslog file size mismatches.
Examples
The following sample display shows output when the following command has been added to the configuration:
logging syslog-server 10 3 syslogsThis example shows the files being created. Use the dir disk0:/syslogs.dir command to view the contents of the newly created directory.
Router# debug syslog-serverSYSLOG_SERVER:Syslog file syslogsSYSLOG_SERVER:Directory disk0:/syslogs.dir created.SYSLOG_SERVER:Syslog file syslogs created successfully.When a syslog message is received, the router checks to see if the current file will be too large when the new data is added. In this example, two messages are successfully added to the file.
SYSLOG_SERVER: Configured size : 10240 bytesCurrent size : 0 bytesData size : 68 bytesNew size : 68 bytesSYSLOG_SERVER: Wrote 68 bytes successfully.SYSLOG_SERVER: Configured size : 10240 bytesCurrent size : 68 bytesData size : 61 bytesNew size : 129 bytesSYSLOG_SERVER: Wrote 61 bytes successfully.Table 154 describes the significant fields.
The following output indicates that the current file is too full to fit the next syslog message. The oldest subfile is removed, and the remaining files are renamed. A new file is created and opened for writing syslog messages.
SYSLOG_SERVER:Last archive subfile disk0:/syslogs.dir/syslogs.2 removed.SYSLOG_SERVER: Subfile disk0:/syslogs.dir/syslogs.1 renamed as disk0:/syslogs.dir/syslogs.2.SYSLOG_SERVER:subfile disk0:/syslogs.dir/syslogs.cur renamed as disk0:/syslogs.dir/syslogs.1.SYSLOG_SERVER:Current subfile disk0:/syslogs.dir/syslogs.cur has been opened.debug tacacs
Use the debug tacacs privileged EXEC command to display information associated with the Terminal Access Controller Access Control System (TACACS). The no form of this command disables debugging output.
debug tacacs
no debug tacacs
Syntax Description
This command has no arguments or keywords.
Usage Guidelines
TACACS is a distributed security system that secures networks against unauthorized access. Cisco supports TACACS under the authentication, authorization, and accounting (AAA) security system.
Use the debug aaa authentication command to get a high-level view of login activity. When TACACS is used on the router, you can use the debug tacacs command for more detailed debugging information.
Examples
The following is sample output from the debug aaa authentication command for a TACACS login attempt that was successful. The information indicates that TACACS+ is the authentication method used.
Router# debug aaa authentication14:01:17: AAA/AUTHEN (567936829): Method=TACACS+14:01:17: TAC+: send AUTHEN/CONT packet14:01:17: TAC+ (567936829): received authen response status = PASS14:01:17: AAA/AUTHEN (567936829): status = PASSThe following is sample output from the debug tacacs command for a TACACS login attempt that was successful as indicated by the status PASS.
Router# debug tacacs14:00:09: TAC+: Opening TCP/IP connection to 192.168.60.15 using source 10.116.0.7914:00:09: TAC+: Sending TCP/IP packet number 383258052-1 to 192.168.60.15 (AUTHEN/START)14:00:09: TAC+: Receiving TCP/IP packet number 383258052-2 from 192.168.60.1514:00:09: TAC+ (383258052): received authen response status = GETUSER14:00:10: TAC+: send AUTHEN/CONT packet14:00:10: TAC+: Sending TCP/IP packet number 383258052-3 to 192.168.60.15 (AUTHEN/CONT)14:00:10: TAC+: Receiving TCP/IP packet number 383258052-4 from 192.168.60.1514:00:10: TAC+ (383258052): received authen response status = GETPASS14:00:14: TAC+: send AUTHEN/CONT packet14:00:14: TAC+: Sending TCP/IP packet number 383258052-5 to 192.168.60.15 (AUTHEN/CONT)14:00:14: TAC+: Receiving TCP/IP packet number 383258052-6 from 192.168.60.1514:00:14: TAC+ (383258052): received authen response status = PASS14:00:14: TAC+: Closing TCP/IP connection to 192.168.60.15The following is sample output from the debug tacacs command for a TACACS login attempt that was unsuccessful as indicated by the status FAIL.
Router# debug tacacs13:53:35: TAC+: Opening TCP/IP connection to 192.168.60.15 using source192.48.0.7913:53:35: TAC+: Sending TCP/IP packet number 416942312-1 to 192.168.60.15(AUTHEN/START)13:53:35: TAC+: Receiving TCP/IP packet number 416942312-2 from 192.168.60.1513:53:35: TAC+ (416942312): received authen response status = GETUSER13:53:37: TAC+: send AUTHEN/CONT packet13:53:37: TAC+: Sending TCP/IP packet number 416942312-3 to 192.168.60.15(AUTHEN/CONT)13:53:37: TAC+: Receiving TCP/IP packet number 416942312-4 from 192.168.60.1513:53:37: TAC+ (416942312): received authen response status = GETPASS13:53:38: TAC+: send AUTHEN/CONT packet13:53:38: TAC+: Sending TCP/IP packet number 416942312-5 to 192.168.60.15(AUTHEN/CONT)13:53:38: TAC+: Receiving TCP/IP packet number 416942312-6 from 192.168.60.1513:53:38: TAC+ (416942312): received authen response status = FAIL13:53:40: TAC+: Closing TCP/IP connection to 192.168.60.15Related Commands
Displays information on accountable events as they occur.
Displays information on AAA/TACACS+ authentication.
debug tacacs events
Use the debug tacacs events privileged EXEC command to display information from the TACACS+ helper process. The no form of this command disables debugging output.
debug tacacs events
no debug tacacs events
Syntax Description
This command has no arguments or keywords.
Usage Guidelines
Use the debug tacacs events command only in response to a request from service personnel to collect data when a problem has been reported.
Caution
The TACACS protocol is used on routers to assist in managing user accounts. TACACS+ enhances the TACACS functionality by adding security features and cleanly separating out the authentication, authorization, and accounting (AAA) functionality.
Examples
The following is sample output from the debug tacacs events command. In this example, the opening and closing of a TCP connection to a TACACS+ server are shown, as well as the bytes read and written over the connection and the connection's TCP status.
Router# debug tacacs events%LINK-3-UPDOWN: Interface Async2, changed state to up00:03:16: TAC+: Opening TCP/IP to 192.168.58.104/1049 timeout=1500:03:16: TAC+: Opened TCP/IP handle 0x48A87C to 192.168.58.104/104900:03:16: TAC+: periodic timer started00:03:16: TAC+: 192.168.58.104 req=3BD868 id=-1242409656 ver=193 handle=0x48A87C (ESTAB)expire=14 AUTHEN/START/SENDAUTH/CHAP queued00:03:17: TAC+: 192.168.58.104 ESTAB 3BD868 wrote 46 of 46 bytes00:03:22: TAC+: 192.168.58.104 CLOSEWAIT read=12 wanted=12 alloc=12 got=1200:03:22: TAC+: 192.168.58.104 CLOSEWAIT read=61 wanted=61 alloc=61 got=4900:03:22: TAC+: 192.168.58.104 received 61 byte reply for 3BD86800:03:22: TAC+: req=3BD868 id=-1242409656 ver=193 handle=0x48A87C (CLOSEWAIT) expire=9AUTHEN/START/SENDAUTH/CHAP processed00:03:22: TAC+: periodic timer stopped (queue empty)00:03:22: TAC+: Closing TCP/IP 0x48A87C connection to 192.168.58.104/104900:03:22: TAC+: Opening TCP/IP to 192.168.58.104/1049 timeout=1500:03:22: TAC+: Opened TCP/IP handle 0x489F08 to 192.168.58.104/104900:03:22: TAC+: periodic timer started00:03:22: TAC+: 192.168.58.104 req=3BD868 id=299214410 ver=192 handle=0x489F08 (ESTAB)expire=14 AUTHEN/START/SENDPASS/CHAP queued00:03:23: TAC+: 192.168.58.104 ESTAB 3BD868 wrote 41 of 41 bytes00:03:23: TAC+: 192.168.58.104 CLOSEWAIT read=12 wanted=12 alloc=12 got=1200:03:23: TAC+: 192.168.58.104 CLOSEWAIT read=21 wanted=21 alloc=21 got=900:03:23: TAC+: 192.168.58.104 received 21 byte reply for 3BD86800:03:23: TAC+: req=3BD868 id=299214410 ver=192 handle=0x489F08 (CLOSEWAIT) expire=13AUTHEN/START/SENDPASS/CHAP processed00:03:23: TAC+: periodic timer stopped (queue empty)The TACACS messages are intended to be self-explanatory or for consumption by service personnel only. However, the following messages shown above are briefly explained in the following text.
The following message indicates that a TCP open request to host 192.168.58.104 on port 1049 will time out in 15 seconds if it gets no response:
00:03:16: TAC+: Opening TCP/IP to 192.168.58.104/1049 timeout=15The following message indicates a successful open operation and provides the address of the internal TCP "handle" for this connection:
00:03:16: TAC+: Opened TCP/IP handle 0x48A87C to 192.168.58.104/1049The following message indicates that a TACACS+ request has been queued:
00:03:16: TAC+: 192.168.58.104 req=3BD868 id=-1242409656 ver=193 handle=0x48A87C (ESTAB) expire=14 AUTHEN/START/SENDAUTH/CHAP queuedThe message identifies the following:
•
•
•
•
•
•
–
–
–
–
–
–
–
–
–
–
–
•
•
The following message indicates that all 46 bytes were written to address 192.168.58.104 for request 3BD868:
00:03:17: TAC+: 192.168.58.104 ESTAB 3BD868 wrote 46 of 46 bytesThe following message indicates that 12 bytes were read in reply to the request:
00:03:22: TAC+: 192.168.58.104 CLOSEWAIT read=12 wanted=12 alloc=12 got=12The following message indicates that 49 more bytes were read, making a total of 61 bytes in all, which is all that was expected:
00:03:22: TAC+: 192.168.58.104 CLOSEWAIT read=61 wanted=61 alloc=61 got=49The following message indicates that a complete 61-byte reply has been read and processed for request 3BD868:
00:03:22: TAC+: 192.168.58.104 received 61 byte reply for 3BD868 00:03:22: TAC+: req=3BD868 id=-1242409656 ver=193 handle=0x48A87C (CLOSEWAIT) expire=9 AUTHEN/START/SENDAUTH/CHAP processedThe following message indicates that the TACACS+ server helper process switched itself off when it had no more work to do:
00:03:22: TAC+: periodic timer stopped (queue empty)Related Commands
