Table Of Contents
debug serial interface
Debug Serial Interface for Frame Relay Encapsulation
Debug Serial Interface for HDLC
Debug Serial Interface for HSSI
Debug Serial Interface for ISDN Basic Rate
Debug Serial Interface for an MK5025 Device
Debug Serial Interface for SMDS Encapsulation
debug serial packet
Debug Serial Packet for SMDS Encapsulation
debug service-module
debug source bridge
debug source error
debug source event
debug span
debug sse
debug standby
debug stun packet
debug tftp
debug token ring
debug vines arp
debug vines echo
debug vines ipc
debug vines netrpc
debug vines packet
debug vines routing
debug vines service
debug vines state
debug vines table
debug x25 all
debug x25 events
debug x25 vc
debug xns packet
debug xns routing
debug serial interface
Use the debug serial interface 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.
Command Mode
EXEC
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.
Note
While 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 sample debug serial interface displays for various configurations and describe the possible output the command can generate for these configurations.
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 xxx
Debug Serial Interface for HDLC
shows sample debug serial interface output for an HDLC connection when keepalives are enabled.
Figure 2-133 Sample Debug Serial Interface Output for HDLC
In , the debug serial interface display 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.
describes significant fields shown in .
Table 2-76 Debug Serial Interface Field Descriptions for HDLC
Field
|
Description
|
Serial1
|
Interface through which the serial connection is taking place.
|
HDLC
|
The serial connection is an HDLC connection.
|
myseq 636119
|
The myseq counter increases by one each time the router sends a keepalive packet to the remote router.
|
mineseen 636119
|
The value of the mineseen counter reflects the last myseq sequence number the remote router has acknowledged receiving from the router. The remote router stores this value in its yourseen counter and sends that value in a keepalive packet to the router.
|
yourseen 515032
|
The yourseen counter reflects the value of the myseq sequence number the router has received in a keepalive packet from the remote router.
|
line up
|
The connection between the routers is maintained. Value changes to "line down" if the values of the myseq and myseen fields in a keepalive packet differ by more than three. Value returns to "line up" when the interface is reset. If the line is in loopback mode, ("looped") appears after this field.
|
describes additional error messages that the debug serial interface command can generate for HDLC.
Table 2-77 Debug Serial Interface Error Messages for HDLC
Field
|
Description
|
Illegal serial link type code xxx, PC = 0xnnnnnn
|
This message is displayed if the router attempts to send a packet containing an unknown packet type.
|
Illegal HDLC serial type code xxx, PC = 0xnnnnn
|
This message is displayed if an unknown packet type is received.
|
Serial 0: attempting to restart
|
This message is displayed periodically if the interface is down. The hardware is then reset to hopefully correct the problem.
|
Serial 0: Received bridge packet sent to nnnnnnnnn
|
This message is displayed if a bridge packet is received over a serial interface configured for HDLC, and bridging is not configured on that interface.
|
Debug Serial Interface for HSSI
On an HSSI interface, the debug serial interface command can generate the following additional error message:
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.
Debug Serial Interface for ISDN Basic Rate
describes error messages that the debug serial interface command can generate for ISDN Basic Rate.
Table 2-78 Debug Serial Interface Message Descriptions for ISDN Basic Rate
Message
|
Description
|
BRI: D-chan collision
|
A collision on the ISDN D-channel has occurred; the software will retry transmission.
|
Received SID Loss of Frame Alignment int.
|
The ISDN hardware has lost frame alignment. This usually indicates a problem with the ISDN network.
|
Unexpected IMP int: ipr = 0xnn
|
The 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
|
The 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
|
This message is displayed if a packet is received, but the encapsulation used for the packet is not recognized. It can indicate that the interface is misconfigured.
|
Debug Serial Interface for an MK5025 Device
describes the additional error messages that the debug serial interface command can generate for an MK5025 device.
Table 2-79 Debug Serial Interface Message Descriptions for an MK5025 Device
Message
|
Description
|
MK5(d): Reset from 0xnnnnnnnn
|
This message indicates that the 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
|
This message is displayed if a packet is received, but the encapsulation used for the packet is not recognized. Possibly an indication that the interface is misconfigured.
|
MK5(d): No packet available for packet realignment
|
This message is displayed in cases where the 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 then reset. If this message is displayed constantly, it usually indicates a hardware problem.
|
MK5(d): New serial state = n
|
This message is displayed to indicate that the 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.
|
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 = 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. This value is only significant to Cisco as an internal protocol type value.
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
debug serial packet
Use the debug serial packet 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.
Command Mode
EXEC
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.
Sample Display
The debug serial packet command displays output for only SMDS encapsulations.
Debug Serial Packet for SMDS Encapsulation
shows sample output when SMDS is enabled on the interface.
Figure 2-134 Sample Debug Serial Packet Output for SMDS
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 shows, when encapsulation is set to SMDS, debug serial packet displays the entire SMDS header (in hex), 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
To display debugging messages that monitor the detection and clearing of network alarms on the CSU/DSU, use the debug service-module privileged EXEC command. Use the no debug service-module command to disable debugging messages.
debug service-module
no debug service-module
Syntax Description
This command has no arguments or keywords.
Command Mode
Privileged EXEC
Usage Guidelines
Use this command to enable and disable debug logging for the serial 0 and serial 1 interfaces on the Cisco 2524 and Cisco 2525 routers.
Debug messages can also be viewed by entering the show service-module command.
Example
The following example is output from the debug service-module command:
Router1# debug service-module
Service module debugging is on
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
debug source bridge
Use the debug source bridge EXEC command to display information about packets and frames transferred across a source-route bridge. The no form of this command disables debugging output.
[no] debug source bridge
Sample Display
shows sample 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.
Figure 2-135 Sample Debug Source Bridge Output—TCP Environment
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
Explanations for individual lines of output in follow.
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
The 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 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
shows sample debug source bridge output 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.
Figure 2-136 Sample Debug Source Bridge Output—Direct Encapsulation Environment
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
Explanations for individual lines of output in follow.
The 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/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
debug source error
Use the debug source error EXEC command to display source-route bridging errors. The no form of this command disables debugging output.
[no] debug source error
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.
Sample Displays
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-type
In the following example, an Address Resolution Protocol (ARP) packet was dropped. ARP is defined in RFC 826.
SRBnumber drop:TYPE_RFC826_ARP
In 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 version
In the following example, the packet was dropped because the outgoing interface of the router was down:
RSRB IF: outgoing interface not up, dropping packet
In 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 interface
In 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 peer
In 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 result
In 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 set
In 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 bridge
The 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 bridge
The 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 = state
In 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 found
Related Commands
debug source bridge
debug source event
debug source event
Use the debug source event EXEC command to display information on source-route bridging activity. The no form of this command disables debugging output.
[no] debug source event
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
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.
Sample Display
shows sample debug source event output.
Figure 2-137 Sample Debug Source Event Output
router# debug source event
RSRB0: forward (srn 5 bn 1 trn 10), src: 8110.2222.33c1 dst: 1000.5a59.04f9
RSRB0: forward (srn 5 bn 1 trn 10), src: 8110.2222.33c1 dst: 1000.5a59.04f9
RSRB0: forward (srn 5 bn 1 trn 10), src: 8110.2222.33c1 dst: 1000.5a59.04f9
RSRB0: forward (srn 5 bn 1 trn 10), src: 8110.2222.33c1 dst: 1000.5a59.04f9
RSRB0: forward (srn 5 bn 1 trn 10), src: 8110.2222.33c1 dst: 1000.5a59.04f9
describes significant fields shown in .
Table 2-80 Debug Source Event Field Descriptions
Field
|
Description
|
RSRB0:
|
Indication that this RIF cache entry is for the Token Ring 0 interface, which has been configured for remote source-route bridging. (SRB1, in contrast, would indicate that this RIF cache entry is for Token Ring 1, configured for source-route bridging.)
|
forward
|
Forward (normal data) packet, in contrast to a control packet containing proprietary Cisco bridging information.
|
srn 5
|
Ring number of the packet's source ring.
|
bn 1
|
Bridge number of the bridge this packet traverses.
|
trn 10
|
Ring number of the packet's target ring.
|
src: 8110.2222.33c1
|
Source address of the route in this RIF cache entry.
|
dst: 1000.5a59.04f9
|
Destination address of the route in this RIF cache entry.
|
[0800.3201.00A1.0050]
|
RIF string in this RIF cache entry.
|
Examples of other debug source event messages follow.
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
The 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-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]
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 found
RSRBn: explorer rif [rif] not long enough
The 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 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
The 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 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)
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-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
debug span
Use the debug span 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.
Command Mode
EXEC
Usage Guidelines
This command is useful for tracking and verifying that the spanning-tree protocol is operating correctly.
Sample Display—IEEE Spanning Tree
Sample debug span output for an IEEE BPDU packet follows:
ST: Ether4 0000000000000A080002A02D6700000000000A080002A02D6780010000140002000F00
shows the preceding debug span output broken up by fields and labeled to aid documentation.
Figure 2-138 Sample Debug Span Output for an IEEE BPDU Packet
describes significant fields shown in .
Table 2-81 Debug Span Field Descriptions for an IEEE BPDU Packet
Field
|
Description
|
ST:
|
Indication that this is a spanning tree packet.
|
Ether4
|
Interface receiving the packet.
|
(A) 0000
|
Indication that this is an IEEE BPDU packet.
|
(B) 00
|
Version.
|
(C) 00
|
Command mode:
00 indicates config BPDU.
80 indicates the Topology Change Notification (TCN) BPDU.
|
(D) 00
|
Topology change acknowledgment:
00 indicates no change.
80 indicates a change notification.
|
(E) 000A
|
Root priority.
|
(F) 080002A02D67
|
Root ID.
|
(G) 00000000
|
Root path cost (0 means the sender of this BPDU packet is the root bridge).
|
(H) 000A
|
Bridge priority.
|
(I) 080002A02D67
|
Bridge ID.
|
(J) 80
|
Port priority.
|
(K) 01
|
Port No. 1.
|
(L) 0000
|
Message age in 256ths of a second (0 seconds, in this case).
|
(M) 1400
|
Maximum age in 256ths of a second (20 seconds, in this case).
|
(N) 0200
|
Hello time in 256ths of a second (2 seconds, in this case).
|
(O) 0F00
|
Forward delay in 256ths of a second (15 seconds, in this case).
|
Sample Display—DEC Spanning Tree
Sample debug span output for a DEC BPDU packet follows:
ST: Ethernet4 E1190100000200000C01A2C90064008000000C0106CE0A01050F1E6A
shows the preceding debug span output broken up by fields and labeled to aid documentation.
Figure 2-139 Sample Debug Span Output
describes significant fields shown in .
Table 2-82 Debug Span Field Descriptions for a DEC BPDU Packet
Field
|
Description
|
ST:
|
Indication that this is a spanning tree packet.
|
Ethernet4
|
Interface receiving the packet.
|
(A) E1
|
Indication that this is a DEC BPDU packet.
|
(B) 19
|
Indication that this is a DEC Hello packet. Possible values are as follows:
0x19—DEC Hello
0x02—Topology change notification (TCN)
|
(C) 01
|
DEC version.
|
(D) 00
|
Flag that is a bit field with the following mapping:
1—TCN
2—TCN acknowledgment
8—Use short timers
|
(E) 0002
|
Root priority.
|
(F) 00000C01A2C9
|
Root ID (MAC address).
|
(G) 0064
|
Root path cost (translated as 100 in decimal notation).
|
(H) 0080
|
Bridge priority.
|
(I) 00000C0106CE
|
Bridge ID.
|
(J) 0A
|
Port ID (in contrast to interface number).
|
(K) 01
|
Message age (in seconds).
|
(L) 05
|
Hello time (in seconds).
|
(M) 0F
|
Maximum age (in seconds).
|
(N) 1E
|
Forward delay (in seconds).
|
(O) 6A
|
Not applicable.
|
debug sse
Use the debug sse 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.
Command Mode
EXEC
Usage Guidelines
By using the debug sse command, you can observe statistics and counters maintained by the SSE.
Sample Display
shows sample debug sse output.
Figure 2-140 Sample Debug SSE Output
SSE: IP number of cache entries changed 273 274
SSE: IP number of cache entries changed 273 274
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
Explanations for representative lines of output in follow.
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:
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
debug standby
Use the debug standby 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.
Command Mode
EXEC
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.
Sample Display
shows sample debug standby output.
Figure 2-141 Sample Debug Standby Output
SB: Ethernet0 state Virgin -> Listen
SB: Starting up hot standby process
SB:Ethernet0 Hello in 198.92.72.21 Active pri 90 hel 3 hol 10 ip 198.92.72.29
SB:Ethernet0 Hello in 198.92.72.21 Active pri 90 hel 3 hol 10 ip 198.92.72.29
SB:Ethernet0 Hello in 198.92.72.21 Active pri 90 hel 3 hol 10 ip 198.92.72.29
SB:Ethernet0 Hello in 198.92.72.21 Active pri 90 hel 3 hol 10 ip 198.92.72.29
SB: Ethernet0 state Listen -> Speak
SB:Ethernet0 Hello out 198.92.72.20 Speak pri 100 hel 3 hol 10 ip 198.92.72.29
SB:Ethernet0 Hello in 198.92.72.21 Active pri 90 hel 3 hol 10 ip 198.92.72.29
SB:Ethernet0 Hello out 198.92.72.20 Speak pri 100 hel 3 hol 10 ip 198.92.72.29
SB:Ethernet0 Hello in 198.92.72.21 Active pri 90 hel 3 hol 10 ip 198.92.72.29
SB:Ethernet0 Hello out 198.92.72.20 Speak pri 100 hel 3 hol 10 ip 198.92.72.29
SB:Ethernet0 Hello in 198.92.72.21 Active pri 90 hel 3 hol 10 ip 198.92.72.29
SB: Ethernet0 state Speak -> Standby
SB:Ethernet0 Hello out 198.92.72.20 Standby pri 100 hel 3 hol 10 ip 198.92.72.29
SB:Ethernet0 Hello in 198.92.72.21 Active pri 90 hel 3 hol 10 ip 198.92.72.29
SB:Ethernet0 Hello out 198.92.72.20 Standby pri 100 hel 3 hol 10 ip 198.92.72.29
SB:Ethernet0 Hello in 198.92.72.21 Active pri 90 hel 3 hol 10 ip 198.92.72.29
SB:Ethernet0 Hello out 198.92.72.20 Standby pri 100 hel 3 hol 10 ip 198.92.72.29
SB:Ethernet0 Hello in 198.92.72.21 Active pri 90 hel 3 hol 10 ip 198.92.72.29
SB: Ethernet0 Coup out 198.92.72.20 Standby pri 100 hel 3 hol 10 ip 198.92.72.29
SB: Ethernet0 state Standby -> Active
SB:Ethernet0 Hello out 198.92.72.20 Active pri 100 hel 3 hol 10 ip 198.92.72.29
SB:Ethernet0 Hello in 198.92.72.21 Speak pri 90 hel 3 hol 10 ip 198.92.72.29
SB:Ethernet0 Hello out 198.92.72.20 Active pri 100 hel 3 hol 10 ip 198.92.72.29
SB:Ethernet0 Hello in 198.92.72.21 Speak pri 90 hel 3 hol 10 ip 198.92.72.29
SB:Ethernet0 Hello out 198.92.72.20 Active pri 100 hel 3 hol 10 ip 198.92.72.29
describes significant fields shown in .
Table 2-83 Debug Standby Field Descriptions
Field
|
Description
|
SB
|
An abbreviation for "standby."
|
Ethernet0
|
The interface on which a hot standby packet was sent or received.
|
Hello in
|
Hello packet received from the specified IP address.
|
Hello out
|
Hello packet sent from the specified IP address.
|
pri
|
Priority advertised in the hello packet.
|
hel
|
Hello interval advertised in the hello packet.
|
hol
|
Holddown interval advertised in the hello packet.
|
ip address
|
Hot standby group IP address advertised in the hello packet.
|
state
|
Transition from one state to another.
|
Coup out address
|
Coup packet sent by the router from the specified IP address.
|
Explanations for representative lines of output in follow.
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 process
The following line indicates that a state transition occurred on the interface:
SB: Ethernet0 state Listen -> Speak
debug stun packet
Use the debug stun packet EXEC command to display information on packets traveling through the serial tunnel (STUN) links. Use the no form of this command to disable debugging output.
debug stun packet [group] [address]
no debug stun packet [group] [address]
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.
|
Command Mode
EXEC
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.
Sample Display
shows sample debug stun packet output.
Figure 2-142 Sample Debug STUN Packet Output
Explanations for individual lines of output from follow.
The following line describes an X1 type of packet:
STUN sdlc: 0:00:04 Serial3 NDI: (0C2/008) U: SNRM PF:1
describes significant fields shown in this line of debug stun packet output.
Table 2-84 Debug STUN Packet Field Descriptions
Field
|
Description
|
STUN sdlc:
|
Indication that the STUN feature is providing the information.
|
0:00:04
|
Time elapsed since receipt of previous packet.
|
Serial3
|
Interface type and unit number reporting the event.
|
NDI:
|
The type of cloud separating the SDLC end nodes. Possible values follow:
NDI—Network input
SDI—Serial link
|
0C2
|
SDLC address of the SDLC connection.
|
008
|
A modulo value of 8.
|
U:SNRM
|
The frame type followed by the command or response type. In this case it is an Unnumbered frame that contains an SNRM (Set Normal Response Mode) command. The possible frame types are as follows:
I—Information frame
S—Supervisory frame. The possible commands and responses are: RR (Receive Ready), RNR (Receive Not Ready), and REJ (Reject).
U—Unnumbered frame. The possible commands are: UI (Unnumbered Information), SNRM, DISC/RD (Disconnect/Request Disconnect), SIM/RIM, XID Exchange Identification), TEST. The possible responses are UA (unnumbered acknowledgment), DM (Disconnected Mode), and FRMR (Frame Reject Mode)
|
PF:1
|
Poll/Final bit.
0—Off
1—On
|
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: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.
debug tftp
Use the debug tftp EXEC command to display Trivial File Transfer Protocol (TFTP) debugging information when encountering problems netbooting or using the configure network or write network commands. The no form of this command disables debugging output.
debug tftp
no debug tftp
Syntax Description
This command has no arguments or keywords.
Command Mode
EXEC
Sample Display
shows sample debug tftp output from the EXEC command write network.
Figure 2-143 Sample Debug TFTP Output
TFTP: msclock 0x292B4; Sending write request (retry 0), socket_id 0x301DA8
TFTP: msclock 0x2A63C; Sending write request (retry 1), socket_id 0x301DA8
TFTP: msclock 0x2A6DC; Received ACK for block 0, socket_id 0x301DA8
TFTP: msclock 0x2A6DC; Received ACK for block 0, socket_id 0x301DA8
TFTP: msclock 0x2A6DC; Sending block 1 (retry 0), socket_id 0x301DA8
TFTP: msclock 0x2A6E4; Received ACK for block 1, socket_id 0x301DA8
describes significant fields shown in the first line of output from .
Table 2-85 Debug TFTP Field Descriptions
Message
|
Description
|
TFTP:
|
This entry describes a TFTP packet.
|
msclock 0x292B4;
|
Internal timekeeping clock (in milliseconds).
|
Sending write request (retry 0)
|
The TFTP operation.
|
socket_id 0x301DA8
|
Unique memory address for the socket for the TFTP connection.
|
debug token ring
Use the debug token ring EXEC command to display messages about Token Ring interface activity. The no form of this command disables debugging output.
debug token ring
no debug token ring
Syntax Description
This command has no arguments or keywords.
Command Mode
EXEC
Usage Guidelines
This command reports several lines of information for each packet sent or received and is intended for low traffic, detailed debugging.
The Token Ring interface records provide information regarding the current state of the ring. These messages are only displayed when the debug token events command is enabled.
The debug token ring command invokes verbose Token Ring hardware debugging. This includes detailed displays as traffic arrives and departs the unit.
Note
It is best to use this command only on router/bridges with light loads.
Sample Display
shows sample debug token ring output.
Figure 2-144 Sample Debug Token Ring Output
TR0: Interface is alive, phys. addr 5000.1234.5678
TR0: in: MAC: acfc: 0x1105 Dst: c000.ffff.ffff Src: 5000.1234.5678 bf: 0x45
TR0: in: riflen 0, rd_offset 0, llc_offset 40
TR0: out: MAC: acfc: 0x0040 Dst: 5000.1234.5678 Src: 5000.1234.5678 bf: 0x00
TR0: out: LLC: AAAA0300 00009000 00000100 AAC00000 00000802 50001234 ln: 28
TR0: in: MAC: acfc: 0x1140 Dst: 5000.1234.5678 Src: 5000.1234.5678 bf: 0x09
TR0: in: LLC: AAAA0300 00009000 00000100 AAC0B24A 4B4A6768 74732072 ln: 28
TR0: in: riflen 0, rd_offset 0, llc_offset 14
TR0: out: MAC: acfc: 0x0040 Dst: 5000.1234.5678 Src: 5000.1234.5678 bf: 0x00
TR0: out: LLC: AAAA0300 00009000 00000100 D1D00000 FE11E636 96884006 ln: 28
TR0: in: MAC: acfc: 0x1140 Dst: 5000.1234.5678 Src: 5000.1234.5678 bf: 0x09
TR0: in: LLC: AAAA0300 00009000 00000100 D1D0774C 4DC2078B 3D000160 ln: 28
TR0: in: riflen 0, rd_offset 0, llc_offset 14
TR0: out: MAC: acfc: 0x0040 Dst: 5000.1234.5678 Src: 5000.1234.5678 bf: 0x00
TR0: out: LLC: AAAA0300 00009000 00000100 F8E00000 FE11E636 96884006 ln: 28
describes significant fields shown in the second line of output from .
Table 2-86 Debug Token Ring Field Descriptions—Part 1
Message
|
Description
|
TR0:
|
Name of the interface associated with the Token Ring event.
|
in:
|
Indication of whether the packet was input to the interface (in) or output from the interface (out).
|
MAC:
|
The type of packet, as follows:
MAC—Media Access Control
LLC—Link Level Control
|
acfc: 0x1105
|
Access Control, Frame Control bytes, as defined by the IEEE 802.5 standard.
|
Dst: c000.ffff.ffff
|
Destination address of the frame.
|
Src: 5000.1234.5678
|
Source address of the frame.
|
bf: 0x45
|
Bridge flags for internal use by technical support staff.
|
describes significant fields shown in the third line of output from .
Table 2-87 Debug Token Ring Field Descriptions—Part 2
Message
|
Description
|
TR0:
|
Name of the interface associated with the Token Ring event.
|
in:
|
Indication of whether the packet was input to the interface (in) or output from the interface (out).
|
riflen 0
|
Length of the RIF field (in bytes).
|
rd_offset 0
|
Offset (in bytes) of the frame pointing to the start of the RIF field.
|
llc_offset 40
|
Offset in the frame pointing to the start of the LLC field.
|
describes significant fields shown in the fifth line of output from .
Table 2-88 Debug Token Ring Field Descriptions—Part 3
Message
|
Description
|
TR0:
|
Name of the interface associated with the Token Ring event.
|
out:
|
Indication of whether the packet was input to the interface (in) or output from the interface (out).
|
LLC:
|
The type of frame, as follows:
MAC—Media Access Control
LLC—Link Level Control
|
AAAA0300
|
This and the octets that follow it indicate the contents (hex) of the frame.
|
ln: 28
|
The length of the information field (in bytes).
|
debug vines arp
Use the debug vines arp EXEC command to display debugging information on all Virtual Integrated Network Service (VINES) Address Resolution Protocol (ARP) packets that the router sends or receives. The no form of this command disables debugging output.
debug vines arp
no debug vines arp
Syntax Description
This command has no arguments or keywords.
Command Mode
EXEC
Sample Display
shows sample debug vines arp output.
Figure 2-145 Sample Debug VINES ARP Output
VNSARP: received ARP type 0 from 0260.8c43.a7e4
VNSARP: sending ARP type 1 to 0260.8c43.a7e4
VNSARP: received ARP type 2 from 0260.8c43.a7e4
VNSARP: sending ARP type 3 to 0260.8c43.a7e4 assigning address 3001153C:8004
VSARP: received ARP type 0 from 0260.8342.1501
VSARP: sending ARP type 1 to 0260.8342.1501
VSARP: received ARP type 2 from 0260.8342.1501
VSARP: sending ARP type 3 to 0260.8342.1501 assigning address 3001153C:8005,
In , the first four lines show a non-sequenced ARP transaction and the second four lines show a sequenced ARP transaction. Within the first group of four lines, the first line shows that the router received an ARP request (type 0) from indicated station address 0260.8c43.a7e4. The second line shows that the router is sending back the ARP service response (type 1), indicating that it is willing to assign VINES Internet addresses. The