Syntax Description

This command has no arguments or keywords.

Usage Guidelines

The following sections show and describe sample debug serial interface output for various configurations.

Examples

Debug Serial Interface for Frame Relay Encapsulation

Illegal serial link type code xxx

HSSI0: Reset from 0xnnnnnnn
 

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

Table 136: debug serial interface Command Error Messages for ISDN Basic Rate

Message	Description
BRI: D-chan collision	Collision on the ISDN D-channel has occurred; the software will retry transmission.
Received SID Loss of Frame Alignment int.	ISDN hardware has lost frame alignment. This usually indicates a problem with the ISDN network.
Unexpected IMP int: ipr = 0xnn	ISDN hardware received an unexpected interrupt. The 0xnn variable indicates the value returned by the interrupt register.
BRI(d): RX Frame Length Violation. Length=n BRI(d): RX Nonoctet Aligned Frame BRI(d): RX Abort Sequence BRI(d): RX CRC Error BRI(d): RX Overrun Error BRI(d): RX Carrier Detect Lost	Any of these messages can be displayed when a receive error occurs on one of the ISDN channels. The (d) indicates which channel it is on. These messages can indicate a problem with the ISDN network connection.
BRI0: Reset from 0xnnnnnnn	BRI hardware has been reset. The 0xnnnnnnn variable is the address of the routine that requested that the hardware be reset; it is useful only to development engineers.
BRI(d): Bad state in SCMs scm1=x scm2=x scm3=x BRI(d): Bad state in SCONs scon1=x scon2 =x scon3=x BRI(d): Bad state ub SCR; SCR=x	Any of these messages can be displayed if the ISDN hardware is not in the proper state. The hardware is then reset. If the message is displayed constantly, it usually indicates a hardware problem.
BRI(d): Illegal packet encapsulation=n	Packet is received, but the encapsulation used for the packet is not recognized. The interface might be misconfigured.

Table 137: debug serial interface Command Error Messages for an MK5025 Device

Message	Description
MK5(d): Reset from 0xnnnnnnnn	Hardware has been reset. The 0xnnnnnnn variable is the address of the routine that requested that the hardware be reset; it is useful only to development engineers.
MK5(d): Illegal packet encapsulation=n	Packet is received, but the encapsulation used for the packet is not recognized. Interface might be misconfigured.
MK5(d): No packet available for packet realignment	Serial driver attempted to get a buffer (memory) and was unable to do so.
MK5(d): Bad state in CSR0=(x)	This message is displayed if the hardware is not in the proper state. The hardware is reset. If this message is displayed constantly, it usually indicates a hardware problem.
MK5(d): New serial state=n	Hardware has interrupted the software. It displays the state that the hardware is reporting.
MK5(d): DCD is down. MK5(d): DCD is up.	If the interrupt indicates that the state of carrier has changed, one of these messages is displayed to indicate the current state of DCD.

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 = x
 

The 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 = x
 

The 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=n
 

The 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 y
SMDS: Invalid packet, TAG mismatch x y
SMDS: Invalid packet, Bad TRAILER length x y
 

The following messages can indicate an invalid length for an SMDS packet:

SMDS: Invalid packet, Bad BA length x
SMDS: Invalid packet, Bad header extension length x
SMDS: Invalid packet, Bad header extension type x
SMDS: Invalid packet, Bad header extension value x
 

The 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:z
 

If 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 us

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

Router# debug serial packet
 
Interface Serial2 Sending SMDS L3 packet:
SMDS Header: Id: 00 RSVD: 00 BEtag: EC Basize: 0044
Dest:E18009999999FFFF Src:C12015804721FFFF Xh:04030000030001000000000000000000
SMDS LLC: AA AA 03 00 00 00 80 38
SMDS Data: E1 19 01 00 00 80 00 00 0C 00 38 1F 00 0A 00 80 00 00 0C 01 2B 71
SMDS Data: 06 01 01 0F 1E 24 00 EC 00 44 00 02 00 00 83 6C 7D 00 00 00 00 00
SMDS Trailer: RSVD: 00 BEtag: EC Length: 0044
 

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

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

Network alarm status can also be viewed through the use of the show service-module command.

Note The debug output varies depending on the type of service module installed in the router.

Examples

The following is sample output from the debug service-module command:

Router# debug service-module
 
SERVICE_MODULE(1): loss of signal ended after duration 00:05:36
SERVICE_MODULE(1): oos/oof ended after duration 01:05:14
SERVICE_MODULE(0): Unit has no clock
SERVICE_MODULE(0): detects loss of signal
SERVICE_MODULE(0): loss of signal ended after duration 00:00:33
 

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

Command	Description
debug smrp group	Displays information about SMRP group activity.
debug smrp mcache	Displays information about SMRP multicast fast-switching cache entries.
debug smrp neighbor	Displays information about SMRP neighbor activity.
debug smrp port	Displays information about SMRP port activity.
debug smrp route	Displays information about SMRP routing activity.
debug smrp transaction	Displays information about SMRP transactions.

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 group
 
SMRP: Group AT 20.34, created on port 20.1 by 20.2
SMRP: Group AT 20.34, deleted on port 20.1
 

Related Commands

Command	Description
debug sgbp dial-bids	Displays large scale dialout negotiations between the primary network access server and alternate network access servers.

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 mcache
 
SMRP: Cache created
SMRP: Cache populated for group AT 11.124
        mac - 090007400b7c00000c1740d9
        net - 001fef7500000014ff020a0a0a
SMRP: Forward cache entry created for group AT 11.124
SMRP: Forward cache entry validated for group AT 11.124
SMRP: Forward cache entry invalidated for group AT 11.124
SMRP: Forward cache entry deleted for group AT 11.124 
 

Related Commands

Command	Description
debug sgbp dial-bids	Displays large scale dialout negotiations between the primary network access server and alternate network access servers.

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 neighbor
 
SMRP: Neighbor 30.2, state changed from "normal op" to "secondary op"
 

Related Commands

Command	Description
debug sgbp dial-bids	Displays large scale dialout negotiations between the primary network access server and alternate network access servers.

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

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 port
 
SMRP: Port 30.1, state changed from "secondary neg" to "secondary op"
SMRP: Port 30.1, secondary router changed from 0.0 to 30.1
SMRP: Port 30.1, state changed from "secondary op" to "primary neg"
 

Related Commands

Command	Description
debug sgbp dial-bids	Displays large scale dialout negotiations between the primary network access server and alternate network access servers.

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 route
 
SMRP: Route AT 20-20, poison notification from 30.2
SMRP: Route AT 30-30, poison notification from 30.2
 

Related Commands

Command	Description
debug sgbp dial-bids	Displays large scale dialout negotiations between the primary network access server and alternate network access servers.

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 transaction 
 
SMRP: Transaction for port 30.1, secondary node request (seq 8435) sent to all routers
SMRP: Transaction for port 30.1, secondary node request (seq 8435) sent to all routers
SMRP: Transaction for port 30.1, secondary node request (seq 8435) sent to all routers
SMRP: Transaction for port 30.1, secondary node request (seq 8435) sent to all routers
 

Related Commands

Command	Description
debug sgbp dial-bids	Displays large scale dialout negotiations between the primary network access server and alternate network access servers.

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 packet
 
SNMP: Packet received via UDP from 172.16.63.17 on Ethernet0 
SNMP: Get-next request, reqid 23584, errstat 0, erridx 0 
 sysUpTime = NULL TYPE/VALUE 
 system.1 = NULL TYPE/VALUE 
 system.6 = NULL TYPE/VALUE
SNMP: Response, reqid 23584, errstat 0, erridx 0 
 sysUpTime.0 = 2217027 
 system.1.0 = Cisco Internetwork Operating System Software  
 system.6.0 = 
SNMP: Packet sent via UDP to 172.16.63.17
 

Based 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 20
 

For 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 0
 

Syntax Description

This command has no arguments or keywords.

Examples

The following is sample output from the debug snmp requests command:

Router# debug snmp requests
 
SNMP Manager API: request
  dest: 171.69.58.33.161, community: public
  retries: 3, timeout: 30, mult: 2, use session rtt
  userdata: 0x0
 

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 adjust
 
Delay calculated, offset 3.48
Clock 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 adjust
 
No delay calculated, offset 11.18
Clock stepped.
 

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 packets
 
Received SNTP packet from 172.16.186.66, length 48
 leap 0, mode 1, version 3, stratum 4, ppoll 1024
 rtdel 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 packets
 
Sending SNTP packet to 172.16.25.1
 xmt AF3BD455.FBBE3E64 (00:16:21.983 UTC Mon Mar 1 1993)
 

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 select
 
SNTP: Selected 172.16.186.66
 

Syntax Description

This command has no arguments or keywords.

Examples

Router# debug source bridge
 
RSRB: 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/1996
RSRB: 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 10
RSRB: added bridge 1, ring 1 for 5/131.108.240.1/1996
RSRB: DATA: 5/131.108.250.1/1996 Explorer trn 2, vrn 5, off 18, len 69
RSRB: DATA: 5/131.108.250.1/1996 Forward trn 2, vrn 5, off 0, len 92
RSRB: DATA: forward Forward srn 2, br 1, vrn 5 to peer 5/131.108.250.1/1996 
 

The 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/1996
 

The 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 10
 

The 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/1996
 

RSRB: DATA: 5/131.108.250.1/1996 Explorer trn 2, vrn 5, off 18, len 69
 

The 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 92
 

The 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/1996
 

Router# debug source bridge
 
RSRB: remote explorer to 5/Serial1 srn 1 [C840.0011.0050.0000]
RSRB: Version/Ring XReq sent to peer 5/Serial1
RSRB: Received version reply from 5/Serial1 (version 2)
RSRB: IFin: 5/Serial1 Ring Xchg, Rep trn 0, vrn 5, off 0, len 10
RSRB: added bridge 1, ring 1 for 5/Serial1
 

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/Serial1
 

The 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 39
 

The 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/Serial1
 

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

Syntax Description

This command has no arguments or keywords.

Usage Guidelines

Note In order to use the debug source event command to display traffic source-routed through an interface, you first must disable fast switching of SRB frames with the no source bridge route-cache interface configuration command.

Examples

The following is sample output from the debug source event command:

Router# debug source event
 
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]
RSRB0: forward (srn 5 bn 1 trn 10), src: 8110.2222.33c1 dst: 1000.5a59.04f9 
[0800.3201.00A1.0050]
 

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

In 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 path
SRBnumber: br dropped proxy TEST, address for address, no path
 

In 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: rif
 

The 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 odd
 

The 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: rif
 

The 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: rif
 

The 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: rif
 

The 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-addr
 

RSRB: label: sent op to ring-group/ip-addr
 

The 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-addr
RSRB: added bridge bridge, ring ring for ring-group/ip-addr
 

The 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 port
RSRB: CONN: opening peer ring-group/ip-addr, attempt n
RSRB: CONN: Remote closed ring-group/ip-addr on open
RSRB: CONN: peer ring-group/ip-addr open failed, reason[code]
 

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 found
RSRBn: explorer rif [rif] not long enough
 

RSRB: couldn't get pak for ringXchg
 

The 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-id
 

The 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-type
 

The 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-id
 

The 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-group
 

The following example indicates that memory was corrupted for a connection block (this is an internal error):

RSRB: CONN: corrupt connection block
 

The 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-pointer
 

The 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-id
 

The 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-id
 

RSRB: vrif_sender, hdr won't fit
 

The 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-count
 

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

RSRB: FST Version Request. op = opcode, peer-id
 

The 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-id
 

The 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 out
 

The 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 found

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.

Router# debug span
 
ST: Ether4 0000000000000A080002A02D6700000000000A080002A02D6780010000140002000F00
 

The following is sample output from the debug span command:

ST: Ether4 0000000000000A080002A02D6700000000000A080002A02D6780010000140002000F00
A   B C D E   F           G       H   I           J K L   M   N   O
 

Router# debug span
 
ST: Ethernet4 E1190100000200000C01A2C90064008000000C0106CE0A01050F1E6A
 

The following is sample output from the debug span command:

E1 19 01 00 0002 00000C01A2C9 0064 0080 00000C0106CE 0A 01 05 0F 1E 6A
A  B  C  D  E    F            G    H    I            J  K  L  M  N  O
 

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 sse
 
SSE: IP number of cache entries changed 273 274
SSE: bridging enabled
SSE: interface Ethernet0/0 icb 0x30 addr 0x29 status 0x21A040 protos 0x11
SSE: interface Ethernet0/1 icb 0x33 addr 0x29 status 0x21A040 protos 0x11
SSE: interface Ethernet0/2 icb 0x36 addr 0x29 status 0x21A040 protos 0x10
SSE: interface Ethernet0/3 icb 0x39 addr 0x29 status 0x21A040 protos 0x11
SSE: interface Ethernet0/4 icb 0x3C addr 0x29 status 0x21A040 protos 0x10
SSE: interface Ethernet0/5 icb 0x3F addr 0x29 status 0x21A040 protos 0x11
SSE: interface Hssi1/0 icb 0x48 addr 0x122 status 0x421E080 protos 0x11
SSE: cache update took 316ms, elapsed 320ms
 

The 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 274
 

The following line indicates that bridging functions were enabled on the SSE:

SSE: bridging enabled
 

The 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 0x11
SSE: interface Ethernet0/1 icb 0x33 addr 0x29 status 0x21A040 protos 0x11
SSE: interface Ethernet0/2 icb 0x36 addr 0x29 status 0x21A040 protos 0x10
SSE: interface Ethernet0/3 icb 0x39 addr 0x29 status 0x21A040 protos 0x11
SSE: interface Ethernet0/4 icb 0x3C addr 0x29 status 0x21A040 protos 0x10
SSE: interface Ethernet0/5 icb 0x3F addr 0x29 status 0x21A040 protos 0x11
SSE: interface Hssi1/0 icb 0x48 addr 0x122 status 0x421E080 protos 0x11
 

The 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 320ms

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 standby
 
SB: Ethernet0 state Virgin -> Listen
SB: Starting up hot standby process
SB:Ethernet0 Hello in 192.168.72.21 Active pri 90 hel 3 hol 10 ip 192.168.72.29
SB:Ethernet0 Hello in 192.168.72.21 Active pri 90 hel 3 hol 10 ip 192.168.72.29
SB:Ethernet0 Hello in 192.168.72.21 Active pri 90 hel 3 hol 10 ip 192.168.72.29
SB:Ethernet0 Hello in 192.168.72.21 Active pri 90 hel 3 hol 10 ip 192.168.72.29
SB: Ethernet0 state Listen -> Speak
SB:Ethernet0 Hello out 192.168.72.20 Speak pri 100 hel 3 hol 10 ip 192.168.72.29
SB:Ethernet0 Hello in 192.168.72.21 Active pri 90 hel 3 hol 10 ip 192.168.72.29
SB:Ethernet0 Hello out 192.168.72.20 Speak pri 100 hel 3 hol 10 ip 192.168.72.29
SB:Ethernet0 Hello in 192.168.72.21 Active pri 90 hel 3 hol 10 ip 192.168.72.29
SB:Ethernet0 Hello out 192.168.72.20 Speak pri 100 hel 3 hol 10 ip 192.168.72.29
SB:Ethernet0 Hello in 192.168.72.21 Active pri 90 hel 3 hol 10 ip 192.168.72.29
SB: Ethernet0 state Speak -> Standby
SB:Ethernet0 Hello out 192.168.72.20 Standby pri 100 hel 3 hol 10 ip 192.168.72.29
SB:Ethernet0 Hello in 192.168.72.21 Active pri 90 hel 3 hol 10 ip 192.168.72.29
SB:Ethernet0 Hello out 192.168.72.20 Standby pri 100 hel 3 hol 10 ip 192.168.72.29
SB:Ethernet0 Hello in 192.168.72.21 Active pri 90 hel 3 hol 10 ip 192.168.72.29
SB:Ethernet0 Hello out 192.168.72.20 Standby pri 100 hel 3 hol 10 ip 192.168.72.29
SB:Ethernet0 Hello in 192.168.72.21 Active pri 90 hel 3 hol 10 ip 192.168.72.29
SB: Ethernet0 Coup out 192.168.72.20 Standby pri 100 hel 3 hol 10 ip 192.168.72.29
SB: Ethernet0 state Standby -> Active
SB:Ethernet0 Hello out 192.168.72.20 Active pri 100 hel 3 hol 10 ip 192.168.72.29
SB:Ethernet0 Hello in 192.168.72.21 Speak pri 90 hel 3 hol 10 ip 192.168.72.29
SB:Ethernet0 Hello out 192.168.72.20 Active pri 100 hel 3 hol 10 ip 192.168.72.29
SB:Ethernet0 Hello in 192.168.72.21 Speak pri 90 hel 3 hol 10 ip 192.168.72.29
SB:Ethernet0 Hello out 192.168.72.20 Active pri 100 hel 3 hol 10 ip 192.168.72.29
 

SB: Starting up hot standby process
 

The following line indicates that a state transition occurred on the interface:

SB: Ethernet0 state Listen -> Speak
 

Syntax Description

group	(Optional) Decimal integer assigned to a group. Using this option limits output to packets associated with the specified STUN group.
address	(Optional) Output is further limited to only those packets containing the specified STUN address. The address argument is in the appropriate format for the STUN protocol running for the specified group.

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:

STUN sdlc: 0:00:04 Serial3         NDI: (0C2/008) U: SNRM    PF:1
 

STUN sdlc: 0:00:00 Serial3         SDI: (0C2/008) S: RR      PF:1 NR:000
 

All 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:000
 

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

Syntax Description

This command has no arguments or keywords.

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 perfdata
 
PERF: Applying 'CallFail' to shelf 1111
PERF: Setting up objects for SNMP polling: 'CallFail', shelf 1111
PERF: year hours mins secs msecs = 1998 15 11 1 5
PERF: Start 'CallFail' timer, next cycle in 0 mins, 59 secs
PERF: Timer event:  CallFail, 4 minutes
PERF: Polling 'CallFail', shelf 1111, pc 60AEFDF0
PERF: SNMP resp: Type 6, 'CallFail', shelf 1111, error_st 0
PERF: Logged polled data to disk0:/performance/shelf-1111/CallFail.891645120
PERF: Deleted disk0:/performance/shelf-1111/CallFail.891637469

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 sdp
 
SYSCTLR: Hello packet received via UDP from 172.23.66.106
%SYSCTLR-6-SHELF_ADD: Shelf 99 discovered located at address 172.23.66.106
Hello packet sent to the RS located at 172.23.66.106
SYSCTLR: Hello packet received via UDP from 172.23.66.106
Timer for shelf 99 updated, shelf is alive
Hello packet sent to the RS located at 172.23.66.106
 

The 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 sdp
 
SYSCTLR: Hello packet sent to the SYSCTLR at 172.23.66.111
SYSCTLR: Command packet received from SYSCTLR
Feb 24 17:24:16.713: %SHELF-6-SYSCTLR_ESTABLISHED: Configured via system controller located at 172.23.66.111
SYSCTLR: Rcvd HELLO from SYSCTLR at 172.23.66.111
SYSCTLR: Hello packet sent to the SYSCTLR at 172.23.66.111
SYSCTLR: Rcvd HELLO from SYSCTLR at 172.23.66.111
 

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 syslogs
 

This 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-server
 
SYSLOG_SERVER:Syslog file syslogs
SYSLOG_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 bytes
Current size : 0 bytes
Data size : 68 bytes
New size : 68 bytes
SYSLOG_SERVER: Wrote 68 bytes successfully.
SYSLOG_SERVER: Configured size : 10240 bytes
Current size : 68 bytes
Data size : 61 bytes
New size : 129 bytes
SYSLOG_SERVER: Wrote 61 bytes successfully.
 

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.

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 authentication
 
14:01:17: AAA/AUTHEN (567936829): Method=TACACS+
14:01:17: TAC+: send AUTHEN/CONT packet
14:01:17: TAC+ (567936829): received authen response status = PASS
14:01:17: AAA/AUTHEN (567936829): status = PASS
 

Router# debug tacacs
 
14:00:09: TAC+: Opening TCP/IP connection to 192.168.60.15 using source 10.116.0.79
14: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.15
14:00:09: TAC+ (383258052): received authen response status = GETUSER
14:00:10: TAC+: send AUTHEN/CONT packet
14: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.15
14:00:10: TAC+ (383258052): received authen response status = GETPASS
14:00:14: TAC+: send AUTHEN/CONT packet
14: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.15
14:00:14: TAC+ (383258052): received authen response status = PASS
14:00:14: TAC+: Closing TCP/IP connection to 192.168.60.15
 

The 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 tacacs
 
13:53:35: TAC+: Opening TCP/IP connection to 192.168.60.15 using source
192.48.0.79
13: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.15
13:53:35: TAC+ (416942312): received authen response status = GETUSER
13:53:37: TAC+: send AUTHEN/CONT packet
13: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.15
13:53:37: TAC+ (416942312): received authen response status = GETPASS
13:53:38: TAC+: send AUTHEN/CONT packet
13: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.15
13:53:38: TAC+ (416942312): received authen response status = FAIL
13:53:40: TAC+: Closing TCP/IP connection to 192.168.60.15

Related Commands

Command	Description
debug aaa accounting	Displays information on accountable events as they occur.
debug aaa authentication	Displays information on AAA/TACACS+ authentication.

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 Use the debug tacacs events command with caution because it can generate a significant amount of output.

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 up 
00:03:16: TAC+: Opening TCP/IP to 192.168.58.104/1049 timeout=15 
00:03:16: TAC+: Opened TCP/IP handle 0x48A87C to 192.168.58.104/1049 
00:03:16: TAC+: periodic timer started
00:03:16: TAC+: 192.168.58.104 req=3BD868 id=-1242409656 ver=193 handle=0x48A87C (ESTAB)
expire=14 AUTHEN/START/SENDAUTH/CHAP queued 
00:03:17: TAC+: 192.168.58.104 ESTAB 3BD868 wrote 46 of 46 bytes 
00:03:22: TAC+: 192.168.58.104 CLOSEWAIT read=12 wanted=12 alloc=12 got=12 
00:03:22: TAC+: 192.168.58.104 CLOSEWAIT read=61 wanted=61 alloc=61 got=49 
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 processed 
00:03:22: TAC+: periodic timer stopped (queue empty) 
00:03:22: TAC+: Closing TCP/IP 0x48A87C connection to 192.168.58.104/1049 
00:03:22: TAC+: Opening TCP/IP to 192.168.58.104/1049 timeout=15 
00:03:22: TAC+: Opened TCP/IP handle 0x489F08 to 192.168.58.104/1049 
00:03:22: TAC+: periodic timer started
00:03:22: TAC+: 192.168.58.104 req=3BD868 id=299214410 ver=192 handle=0x489F08 (ESTAB)
expire=14 AUTHEN/START/SENDPASS/CHAP queued 
00:03:23: TAC+: 192.168.58.104 ESTAB 3BD868 wrote 41 of 41 bytes 
00:03:23: TAC+: 192.168.58.104 CLOSEWAIT read=12 wanted=12 alloc=12 got=12 
00:03:23: TAC+: 192.168.58.104 CLOSEWAIT read=21 wanted=21 alloc=21 got=9 
00:03:23: TAC+: 192.168.58.104 received 21 byte reply for 3BD868 
00:03:23: TAC+: req=3BD868 id=299214410 ver=192 handle=0x489F08 (CLOSEWAIT) expire=13
AUTHEN/START/SENDPASS/CHAP processed 
00: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=15 
 

The 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/1049 
 

The 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 queued 
 

The message identifies the following:

• Server that the request is destined for

• Internal address of the request

• TACACS+ ID of the request

• TACACS+ version number of the request

• Internal TCP handle the request uses (which will be zero for a single-connection server)

• TCP status of the connection---which is one of the following:

  • CLOSED

  • LISTEN

  • SYNSENT

  • SYNRCVD

  • ESTAB

  • FINWAIT1

  • FINWAIT2

  • CLOSEWAIT

  • LASTACK

  • CLOSING

  • TIMEWAIT

• Number of seconds until the request times out

• Request type

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 bytes 
 

The 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=12 
 

The 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=49 
 

The 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 processed 
 

The 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

Command	Description
debug aaa accounting	Displays information on accountable events as they occur.
debug aaa authentication	Displays information on AAA/TACACS+ authentication.
debug aaa authorization	Displays the information on AAA/TACACS+ authorization.
debug sw56	Displays debug information for switched 56 K services.