Table Of Contents
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.
[no] debug serial interface
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 xxxDebug Serial Interface for HDLC
shows sample debug serial interface output for an HDLC connection when keepalives are enabled.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.
Figure 2-234 Sample Debug Serial Interface Output for HDLC
describes significant fields shown in .
describes additional error messages that the debug serial interface command can generate for HDLC.
Debug Serial Interface for HSSI
On an HSSI interface, the debug serial interface command can generate the following additional error message:
HSSI0: Reset from 0xnnnnnnnThis message indicates that the HSSI hardware has been reset. The 0xnnnnnnn variable is the address of the routine requesting that the hardware be reset; this value is useful only to development engineers.
Debug Serial Interface for ISDN Basic Rate
describes error messages that the debug serial interface command can generate for ISDN Basic Rate.
Debug Serial Interface for an MK5025 Device
describes the additional error messages that the debug serial interface command can generate for an MK5025 device.
Debug Serial Interface for SMDS Encapsulation
When encapsulation is set to SMDS, debug serial interface displays SMDS packets that are sent and received, as well as any error messages resulting from SMDS packet transmission.
The error messages that the debug serial interface command can generate for SMDS follow.
The following message indicates that a new protocol requested SMDS to encapsulate the data for transmission. SMDS is not yet able to encapsulate the protocol.
SMDS: Error on Serial 0, encapsulation bad protocol = xThe following message indicates that SMDS was asked to encapsulate a packet, but no corresponding destination E.164 SMDS address was found in any of the static SMDS tables or in the ARP tables:
SMDS send: Error in encapsulation, no hardware address, type = xThe following message indicates that a protocol such as CLNS or IP has been enabled on an SMDS interface, but the corresponding multicast addresses have not been configured. The n variable displays the link type for which encapsulation was requested.
SMDS: Send, Error in encapsulation, type=nThe following messages can occur when a corrupted packet is received on an SMDS interface. The router expected x, but received y.
SMDS: Invalid packet, Reserved NOT ZERO, x ySMDS: Invalid packet, TAG mismatch x ySMDS: Invalid packet, Bad TRAILER length x yThe following messages can indicate an invalid length for an SMDS packet:
SMDS: Invalid packet, Bad BA length xSMDS: Invalid packet, Bad header extension length xSMDS: Invalid packet, Bad header extension type xSMDS: Invalid packet, Bad header extension value xThe following messages are displayed when the debug serial interface command is enabled:
Interface Serial 0 Sending SMDS L3 packet:SMDS: dgsize:x type:0xn src:y dst:zIf the debug serial interface command is enabled, the following message can be displayed when a packet is received on an SMDS interface, but the destination SMDS address does not match any on that interface:
SMDS: Packet n, not addressed to usdebug serial packet
Use the debug serial packet 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.
[no] debug serial packet
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.
Sample Display
shows sample output when SMDS is enabled on the interface.
Figure 2-235 Sample Debug Serial Packet Output for SMDS
Router# debug serial packetInterface Serial2 Sending SMDS L3 packet:SMDS Header: Id: 00 RSVD: 00 BEtag: EC Basize: 0044Dest:E18009999999FFFF Src:C12015804721FFFF Xh:04030000030001000000000000000000SMDS LLC: AA AA 03 00 00 00 80 38SMDS Data: E1 19 01 00 00 80 00 00 0C 00 38 1F 00 0A 00 80 00 00 0C 01 2B 71SMDS Data: 06 01 01 0F 1E 24 00 EC 00 44 00 02 00 00 83 6C 7D 00 00 00 00 00SMDS Trailer: RSVD: 00 BEtag: EC Length: 0044As 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
Use the debug service-module EXEC command to display debugging information that monitors the detection and clearing of network alarms on the integrated channel service unit/data service unit (CSU/DSU) modules installed in a Cisco 2524 or Cisco 2525 router. The no form of this command disables debugging output.
[no] debug service-module
Usage Guidelines
Use this command to enable and disable debug logging for the serial 0 and serial 1 interfaces when an integrated CSU/DSU is present. This command enables debugging on all interfaces.
Network alarm status can also be viewed through the use of the show service-module command.
Note
Sample Display
shows sample debug service-module output.
Figure 2-236 Sample Debug Service-Module Output
Router# debug service-moduleSERVICE_MODULE(1): loss of signal ended after duration 00:05:36SERVICE_MODULE(1): oos/oof ended after duration 01:05:14SERVICE_MODULE(0): Unit has no clockSERVICE_MODULE(0): detects loss of signalSERVICE_MODULE(0): loss of signal ended after duration 00:00:33debug smrp all
Use the debug smrp all EXEC command to display information about Simple Multicast Routing Protocol (SMRP) activity. The no form of this command disables debugging output.
[no] debug smrp all
Usage Guidelines
Because the debug smrp all command displays all SMRP debugging output, it is processor intensive and should not be enabled when memory is scarce or in very high traffic situations.
For general debugging, use the debug smrp all command and turn off excessive transactions with the no debug smrp transaction command. This combination of commands will display various state changes and events without displaying every transaction packet. For debugging a specific feature such as a routing problem, use the debug smrp route and debug smrp transaction commands to see if packets are sent and received and which specific routes are affected. The show smrp traffic command is highly recommended as a troubleshooting method because it displays the SMRP counters.
For examples of the type of output you may see, refer to each of the commands listed in the "Related Commands" section.
Related Commands
debug smrp group
debug smrp mcache
debug smrp neighbor
debug smrp port
debug smrp route
debug smrp transactiondebug smrp group
Use the debug smrp group EXEC command to display information about SMRP group activity. The no form of this command disables debugging output.
[no] debug smrp group
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 Network Protocols Command Reference, Part 2
Sample Display
Figure 2-237 shows sample debug smrp group output of a port being created and deleted on group AT 20.34. (AT signifies that this is an AppleTalk network group.)
Figure 2-237 Sample Debug SMRP Group Output
Router# debug smrp groupSMRP: Group AT 20.34, created on port 20.1 by 20.2SMRP: Group AT 20.34, deleted on port 20.1lists the messages that may be generated with the debug smrp group command concerning the forwarding table.
Related Command
debug smrp mcache
Use the debug smrp mcache EXEC command to display information about SMRP multicast fast-switching cache entries. The no form of this command disables debugging output.
[no] debug smrp mcache
Usage Guidelines
Use the show smrp mcache command (described in the Network Protocols Command Reference, Part 2) 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.
Sample Display
Figure 2-238 shows sample debug smrp mcache output. In this example, the cache is created and populated for group AT 11.124. (AT signifies that this is an AppleTalk network group.)
Figure 2-238 Sample Debug SMRP Multicast Route Cache Output
Router# debug smrp mcacheSMRP: Cache createdSMRP: Cache populated for group AT 11.124mac - 090007400b7c00000c1740d9net - 001fef7500000014ff020a0a0aSMRP: Forward cache entry created for group AT 11.124SMRP: Forward cache entry validated for group AT 11.124SMRP: Forward cache entry invalidated for group AT 11.124SMRP: Forward cache entry deleted for group AT 11.124lists all the messages that can be generated with the debug smrp mcache command concerning the multicast cache.
Related Command
debug smrp neighbor
Use the debug smrp neighbor EXEC command to display information about SMRP neighbor activity. The no form of this command disables debugging output.
[no] debug smrp neighbor
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 Network Protocols Command Reference, Part 2.
Sample Display
Figure 2-239 shows sample debug smrp neighbor output. In this example, the neighbor on port 30.02 has changed state from normal operation to secondary operation.
Figure 2-239 Sample Debug SMRP Neighbor Output
Router# debug smrp neighborSMRP: Neighbor 30.2, state changed from "normal op" to "secondary op"lists all the messages that can be generated with the debug smrp neighbor command concerning the neighbor table.
Related Command
debug smrp port
Use the debug smrp port EXEC command to display information about SMRP port activity. The no form of this command disables debugging output.
[no] debug smrp port
Usage Guidelines
The debug smrp port command displays information when a port operating state changes.
For more information, refer to the show smrp port command described in the Network Protocols Command Reference, Part 2.
Sample Display
Figure 2-240 shows sample debug smrp port output. In this example, port 30.1 has changed state from secondary negative to secondary operation to primary negative.
Figure 2-240 Sample Debug SMRP Port Output
Router# debug smrp portSMRP: Port 30.1, state changed from "secondary neg" to "secondary op"SMRP: Port 30.1, secondary router changed from 0.0 to 30.1SMRP: Port 30.1, state changed from "secondary op" to "primary neg"lists all the messages that can be generated with the debug smrp port command concerning the port table.
Related Command
debug smrp route
Use the debug smrp route EXEC command to display information about SMRP routing activity. The no form of this command disables debugging output.
[no] debug smrp route
Usage Guidelines
For more information, refer to the show smrp route command described in the Network Protocols Command Reference, Part 2.
Sample Display
Figure 2-241 shows sample debug smrp route output. In this example, poison notification is received from port 30.2. Poison notification is the receipt of a poisoned route on a nonparent port.
Figure 2-241 Sample Debug SMRP Route Output
Router# debug smrp routeSMRP: Route AT 20-20, poison notification from 30.2SMRP: Route AT 30-30, poison notification from 30.2lists all the messages that can be generated with the debug smrp route command concerning the routing table. In , the term route does not refer to an address but rather it is a network range.
Related Command
debug smrp transaction
Use the debug smrp transaction EXEC command to display information about SMRP transactions. The no form of this command disables debugging output.
[no] debug smrp transaction
Sample Display
Figure 2-242 shows sample debug smrp transaction output. In this example, a secondary node request is sent out to all routers on port 30.1.
Figure 2-242 Sample Debug SMRP Transaction Output
Router# debug smrp transactionSMRP: Transaction for port 30.1, secondary node request (seq 8435) sent to all routersSMRP: Transaction for port 30.1, secondary node request (seq 8435) sent to all routersSMRP: Transaction for port 30.1, secondary node request (seq 8435) sent to all routersSMRP: Transaction for port 30.1, secondary node request (seq 8435) sent to all routerslists all the messages that can be generated with the debug smrp route command.
Related Command
debug snmp packet
To display information about every SNMP packet sent or received by the router, use the debug snmp packet EXEC command. The no form of this command disables debugging output.
[no] debug snmp packet
Sample Display
shows 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.
Figure 2-243 Sample Debug SNMP Packet Output
Router# debug snmp packetSNMP: Packet received via UDP from 172.16.63.17 on Ethernet0SNMP: Get-next request, reqid 23584, errstat 0, erridx 0sysUpTime = NULL TYPE/VALUEsystem.1 = NULL TYPE/VALUEsystem.6 = NULL TYPE/VALUESNMP: Response, reqid 23584, errstat 0, erridx 0sysUpTime.0 = 2217027system.1.0 = Cisco Internetwork Operating System Softwaresystem.6.0 =SNMP: Packet sent via UDP to 172.16.63.17Based on the kind of packet sent or received, the output may vary. For get-bulk requests, a line similar to the following is displayed:
SNMP: Get-bulk request, reqid 23584, nonrptr 10, maxreps 20For traps, a line similar to the following is displayed:
SNMP: V1 Trap, ent 1.3.6.1.4.1.9.1.13, gentrap 3, spectrap 0describes significant fields in these displays.
debug sntp adjust
Use the debug sntp adjust EXEC command to display information about SNTP clock adjustments. The no form of this command disables debugging output.
[no] debug sntp adjust
Sample Displays
shows sample 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.
Figure 2-244 Sample Debug SNTP Adjust Output—Small Offset from Configured Server
Router# debug sntp adjustDelay calculated, offset 3.48Clock slewed.show sample debug sntp adjust command output 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.
Figure 2-245 Sample Debug SNTP Adjust Output—Large Offset from Broadcast Server
Router# debug sntp adjustNo delay calculated, offset 11.18Clock stepped.debug sntp packets
Use the debug sntp packets EXEC command to display information about SNTP packets sent and received. The no form of this command disables debugging output.
[no] debug sntp packets
Sample Displays
show sample debug sntp packets command output when a message is received.
Figure 2-246 Sample Debug SNTP Packets Output When a Packet Is Received
Router# debug sntp packetsReceived SNTP packet from 172.16.186.66, length 48leap 0, mode 1, version 3, stratum 4, ppoll 1024rtdel 00002B00, rtdsp 00003F18, refid AC101801 (172.16.24.1)ref B7237786.ABF9CDE5 (23:28:06.671 UTC Tue May 13 1997)org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)xmt B7237B5C.A7DE94F2 (23:44:28.655 UTC Tue May 13 1997)inp AF3BD529.810B66BC (00:19:53.504 UTC Mon Mar 1 1993)show sample debug sntp packets command output when a message is sent.
Figure 2-247 Sample Debug SNTP Packets Output When a Packet Is Sent
Router# debug sntp packetsSending SNTP packet to 172.16.25.1xmt AF3BD455.FBBE3E64 (00:16:21.983 UTC Mon Mar 1 1993)describes the significant fields shown in and .
debug sntp select
Use the debug sntp select EXEC command to display information about SNTP server selection. The no form of this command disables debugging output.
[no] debug sntp select
Sample Display
show sample debug sntp select command output. In this example, the router will synchronize its time to server at 172.16.186.66.
Figure 2-248 Sample Debug SNTP Select Output
Router# debug sntp selectSNTP: Selected 172.16.186.66debug 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 Displays
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-249 Sample Debug Source Bridge Output—TCP Environment
Router# debug source bridgeRSRB: remote explorer to 5/131.108.250.1/1996 srn 2 [C840.0021.0050.0000]RSRB: Version/Ring XReq sent to peer 5/131.108.250.1/1996RSRB: Received version reply from 5/131.108.250.1/1996 (version 2)RSRB: DATA: 5/131.108.250.1/1996 Ring Xchg Rep, trn 2, vrn 5, off 18, len 10RSRB: added bridge 1, ring 1 for 5/131.108.240.1/1996RSRB: DATA: 5/131.108.250.1/1996 Explorer trn 2, vrn 5, off 18, len 69RSRB: DATA: 5/131.108.250.1/1996 Forward trn 2, vrn 5, off 0, len 92RSRB: DATA: forward Forward srn 2, br 1, vrn 5 to peer 5/131.108.250.1/1996Explanations 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/1996The following line is the response to the version request previously sent. The response is sent from IP address 131.108.250.1, TCP port 1996. The bridge belongs to ring group 5.
RSRB: Received version reply from 5/131.108.250.1/1996 (version 2)The following line is the response to the ring request previously sent. The response is sent from IP address 131.108.250.1, TCP port 1996. The target ring number is 2, virtual ring number is 5, the offset is 18, and the length of the frame is 10 bytes.
RSRB: DATA: 5/131.108.250.1/1996 Ring Xchg Rep, trn 2, vrn 5, off 0, len 10The following line indicates that bridge 1 and ring 1 were added to the source-bridge table for IP address 131.108.250.1, TCP port 1996:
RSRB: added bridge 1, ring 1 for 5/131.108.250.1/1996The following line indicates that a packet containing an explorer frame came across virtual ring 5 from IP address 131.108.250.1, TCP port 1996. The packet is 69 bytes in length. This packet is received after the Ring Exchange information was received and updated on both sides.
RSRB: DATA: 5/131.108.250.1/1996 Explorer trn 2, vrn 5, off 18, len 69The following line indicates that a packet containing data came across virtual ring 5 from IP address 131.108.250.1 over TCP port 1996. The packet is being placed on the local target ring 2.The packet is 92 bytes in length.
RSRB: DATA: 5/131.108.250.1/1996 Forward trn 2, vrn 5, off 0, len 92The following line indicates that a packet containing data is being forwarded to the peer that has IP 131.108.250.1 address belonging to local ring 2 and bridge 1. The packet is forwarded via virtual ring 5. This packet is sent after the Ring Exchange information was received and updated on both sides.
RSRB: DATA: forward Forward srn 2, br 1, vrn 5 to peer 5/131.108.250.1/1996shows 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-250 Sample Debug Source Bridge Output—Direct Encapsulation Environment
Router# debug source bridgeRSRB: remote explorer to 5/Serial1 srn 1 [C840.0011.0050.0000]RSRB: Version/Ring XReq sent to peer 5/Serial1RSRB: Received version reply from 5/Serial1 (version 2)RSRB: IFin: 5/Serial1 Ring Xchg, Rep trn 0, vrn 5, off 0, len 10RSRB: added bridge 1, ring 1 for 5/Serial1Explanations 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/Serial1The following line is the response to the version request previously sent. The response is sent from Serial 1. The bridge belongs to ring group 5 and the version is 2.
RSRB: Received version reply from 5/Serial1 (version 2)The following line is the response to the ring request previously sent. The response is sent from Serial1. The target ring number is 2, virtual ring number is 5, the offset is 0, and the length of the frame is 39 bytes.
RSRB: IFin: 5/Serial1 Ring Xchg Rep, trn 2, vrn 5, off 0, len 39The following line indicates that bridge 1 and ring 1 were added to the source-bridge table for Serial1:
RSRB: added bridge 1, ring 1 for 5/Serial1debug source error
Use the debug source error 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-typeIn the following example, an Address Resolution Protocol (ARP) packet was dropped. ARP is defined in RFC 826.
SRBnumber drop:TYPE_RFC826_ARPIn the following example, the current Cisco IOS version does not support Qualified Logical Link Control (QLLC). Reconfigure the router with an image that has the IBM feature set.
RSRB: QLLC not supported in version versionPlease reconfigure.In the following example, the packet was dropped because the outgoing interface of the router was down:
RSRB IF: outgoing interface not up, dropping packetIn the following example, the router received an out-of-sequence IP sequence number in a Fast Sequenced Transport (FST) packet. FST has no recovery for this problem like TCP encapsulation does.
RSRB FST: bad sequence number dropping.In the following example, the router was unable to locate the virtual interface:
RSRB: couldn't find virtual interfaceIn the following example, the peer router's TCP queue is full. TCPD indicates that this is a TCP debug.
RSRB TCPD: tcp queue full for peerIn the following example, the router was unable to send data to the peer router. A result of 1 indicates that the TCP queue is full. A result of -1 indicates that the RSRB peer is closed.
RSRB TCPD: tcp send failed for peer resultIn the following example, the Routing Information Identifier was not set in the explorer packet going forward. The packet will not support SRB, so it is dropped.
vrforward_explorer - RII not setIn the following example, a packet sent to a virtual bridge in the router did not include a routing information field (RIF) to tell the router which route to use:
RSRB: no RIF on packet sent to virtual bridgeThe following example indicates that the RIF did not contain any information or the length field was set to zero:
RSRB: RIF length of zero sent to virtual bridgeThe following message occurs when the local service access point (LSAP) is out of range. The variable lsap-out is the value, type is the type of RSRB peer, and state is the state of the RSRB peer.
VRP: rsrb_lsap_out = lsap-out, type = type, state = stateIn the following message, the router is unable to find another router with which to exchange bridge protocol data units (BPDU's). BPDU's are exchanged to set up the spanning tree and determine the forwarding path.
RSRB(span): BPDU's peer not foundRelated Commands
debug source bridge
debug source eventdebug 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
Sample Display
shows sample debug source event output.
Figure 2-251 Sample Debug Source Event Output
Router# debug source eventRSRB0: forward (srn 5 bn 1 trn 10), src: 8110.2222.33c1 dst: 1000.5a59.04f9[0800.3201.00A1.0050]RSRB0: forward (srn 5 bn 1 trn 10), src: 8110.2222.33c1 dst: 1000.5a59.04f9[0800.3201.00A1.0050]RSRB0: forward (srn 5 bn 1 trn 10), src: 8110.2222.33c1 dst: 1000.5a59.04f9[0800.3201.00A1.0050]RSRB0: forward (srn 5 bn 1 trn 10), src: 8110.2222.33c1 dst: 1000.5a59.04f9[0800.3201.00A1.0050]RSRB0: forward (srn 5 bn 1 trn 10), src: 8110.2222.33c1 dst: 1000.5a59.04f9[0800.3201.00A1.0050]describes significant fields shown in .
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: rifIn the preceding example, a bridgeable packet came in on interface Token Ring number but there was nowhere to send it. This is most likely a configuration error. For example, an interface has source bridging turned on, but it is not connected to another source bridging interface or a ring group.
In the following example, a bridgeable packet has been forwarded from Token Ring number to the target ring. The two interfaces are directly linked.
SRBnumber: direct forward (srn ring bn bridge trn ring)In the following examples, a proxy explorer reply was not generated because there was no way to get to the address from this interface. The packet came from the node with the first address.
SRBnumber: br dropped proxy XID, address for address, wrong vring (rem)SRBnumber: br dropped proxy TEST, address for address, wrong vring (rem)SRBnumber: br dropped proxy XID, address for address, wrong vring (local)SRBnumber: br dropped proxy TEST, address for address, wrong vring (local)SRBnumber: br dropped proxy XID, address for address, no pathSRBnumber: br dropped proxy TEST, address for address, no pathIn the following example, an appropriate proxy explorer reply was generated on behalf of the second address. It is sent to the first address.
SRBnumber: br sent proxy XID, address for address[rif]SRBnumber: br sent proxy TEST, address for address[rif]The following example indicates that the broadcast bits were not set, or that the routing information indicator on the packet was not set:
SRBnumber: illegal explorer, s: source-MAC-addr d: dst-MAC-addr rif: rifThe following example indicates that the direction bit in the RIF field was set, or that an odd packet length was encountered. Such packets are dropped.
SRBnumber: bad explorer control, D set or oddThe following example indicates that a spanning explorer was dropped because the spanning option was not configured on the interface:
SRBnumber: span dropped, input off, s: source-MAC-addr d: dst-MAC-addr rif: rifThe following example indicates that a spanning explorer was dropped because it had traversed the ring previously:
SRBnumber: span violation, s: source-MAC-addr d: dst-MAC-addr rif: rifThe following example indicates that an explorer was dropped because the maximum hop count limit was reached on that interface:
SRBnumber: max hops reached - hop-cnt, s: source-MAC-addr d: dst-MAC-addr rif: rifThe following example indicates that the ring exchange request was sent to the indicated peer. This request tells the remote side which rings this node has and asks for a reply indicating which rings that side has.
RSRB: sent RingXreq to ring-group/ip-addrThe following example indicates that a message was sent to the remote peer. The label variable can be AHDR (active header), PHDR (passive header), HDR (normal header), or DATA (data exchange), and op can be Forward, Explorer, Ring Xchg, Req, Ring Xchg, Rep, Unknown Ring Group, Unknown Peer, or Unknown Target Ring.
RSRB: label: sent op to ring-group/ip-addrThe following example indicates that the remote bridge and ring pair were removed from or added to the local ring group table because the remote peer changed:
RSRB: removing bn bridge rn ring from ring-group/ip-addrRSRB: added bridge bridge, ring ring for ring-group/ip-addrThe following example shows miscellaneous remote peer connection establishment messages:
RSRB: peer ring-group/ip-addr closed [last state n]RSRB: passive open ip-addr(remote port) -> local portRSRB: CONN: opening peer ring-group/ip-addr, attempt nRSRB: CONN: Remote closed ring-group/ip-addr on openRSRB: CONN: peer ring-group/ip-addr open failed, reason[code]The following example shows that an explorer packet was propagated onto the local ring from the remote ring group:
RSRBn: sent local explorer, bridge bridge trn ring, [rif]The following messages indicate that the remote source-route bridging code found the packet was in error:
RSRBn: ring group ring-group not foundRSRBn: explorer rif [rif] not long enoughThe following example indicates that a buffer could not be obtained for a ring exchange packet (this is an internal error):
RSRB: couldn't get pak for ringXchgThe following example indicates that a ring exchange packet was received that had an incorrect length (this is an internal error):
RSRB: XCHG: req/reply badly formed, length pak-length, peer peer-idThe following example indicates that a ring entry was removed for the peer; the ring was possibly disconnected from the network, causing the remote router to send an update to all its peers.
RSRB: removing bridge bridge ring ring from peer-id ring-typeThe following example indicates that a ring entry was added for the specified peer; the ring was possibly added to the network, causing the other router to send an update to all its peers.
RSRB: added bridge bridge, ring ring for peer-idThe following example indicates that no memory was available to add a ring number to the ring group specified (this is an internal error):
RSRB: no memory for ring element ring-groupThe following example indicates that memory was corrupted for a connection block (this is an internal error):
RSRB: CONN: corrupt connection blockThe following example indicates that a connector process started, but that there was no packet to process (this is an internal error):
RSRB: CONN: warning, no initial packet, peer: ip-addr peer-pointerThe following example indicat
