Table Of Contents

debug serial interface

Usage Guidelines

Sample Displays

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

Usage Guidelines

Sample Display

debug service-module

Usage Guidelines

Sample Display

debug sgbp error

Usage Guidelines

Sample Display

Related Commands

debug sgbp hellos

Usage Guidelines

Sample Display

Related Commands

debug smrp all

Usage Guidelines

Related Commands

debug smrp group

Usage Guidelines

Sample Display

Related Command

debug smrp mcache

Usage Guidelines

Sample Display

Related Command

debug smrp neighbor

Usage Guidelines

Sample Display

Related Command

debug smrp port

Usage Guidelines

Sample Display

Related Command

debug smrp route

Usage Guidelines

Sample Display

Related Command

debug smrp transaction

Sample Display

Related Command

debug snmp packet

Sample Display

debug snmp requests

Sample Display

debug sntp adjust

Sample Displays

debug sntp packets

Sample Displays

debug sntp select

Sample Display

debug source bridge

Sample Displays

debug source error

Usage Guidelines

Sample Displays

Related Commands

debug source event

Usage Guidelines

Sample Display

debug span

Usage Guidelines

Sample Display—IEEE Spanning Tree

Sample Display—DEC Spanning Tree

debug sse

Usage Guidelines

Sample Display

debug standby

Usage Guidelines

Sample Display

debug stun packet

Syntax Description

Usage Guidelines

Sample Display

debug sw56

debug syscon perfdata

Usage Guidelines

Sample Display

debug syscon sdp

Usage Guidelines

Sample Display

debug syslog-server

Usage Guidelines

Sample Display

debug tacacs

Usage Guidelines

Sample Displays

Related Commands

debug tacacs events

Usage Guidelines

Sample Display

Related Commands

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 and describe sample debug serial interface output for various configurations.

Sample Displays

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

The following is sample output from the debug serial interface command for an HDLC connection when keepalives are enabled. This output shows that the remote router is not receiving all the keepalives the router is sending. When the difference in the values in the myseq and mineseen fields exceeds three, the line goes down and the interface is reset.

describes the significant fields.

Table 119 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.

The previous example shows that after missing three keepalives, the line goes down and the interface is reset. However, the interface is also reset when two keepalives are missed, but the line is not marked as "down." This is done in an attempt to restart traffic on the interface without bringing the line down, as shown in the following output:

*Mar 18 08:07:29.057: Serial3/2: HDLC myseq 604562, mineseen 604562, yourseen 259336, line up 

*Mar 18 08:07:39.053: Serial3/2: HDLC myseq 604563, mineseen 604563, yourseen 259337, line up 

*Mar 18 08:07:49.081: Serial3/2: HDLC myseq 604564, mineseen 604564, yourseen 259338, line up 

*Mar 18 08:07:59.057: Serial3/2: HDLC myseq 604565, mineseen 604565, yourseen 259339, line up 

*Mar 18 08:08:09.073: Serial3/2: HDLC myseq 604566, mineseen 604565, yourseen 259340, line up 

*Mar 18 08:08:19.057: Serial3/2: Reset from PC 0x6DEA0 

*Mar 18 08:08:19.061: Serial3/2: HDLC myseq 604567, mineseen 604565, yourseen 259341, line up 

*Mar 18 08:08:29.057: Serial3/2: HDLC myseq 604568, mineseen 604568, yourseen 259342, line up 

*Mar 18 08:08:39.061: Serial3/2: HDLC myseq 604569, mineseen 604569, yourseen 259343, line up 

*Mar 18 08:08:49.065: Serial3/2: HDLC myseq 604570, mineseen 604570, yourseen 259344, line up 

*Mar 18 08:08:59.053: Serial3/2: HDLC myseq 604571, mineseen 604571, yourseen 259345, line up 

Even though the "Reset from PC" message appears to occur when there is only a difference of 1 between myseq and mineseen, this message applies to the condition shown in the immediately following line (notice that the timestamp is only a few milliseconds later) where the difference is 2. After the reset, the line has recovered and the difference between myseq and mineseen is zero.

describes additional error messages that the debug serial interface command can generate for HDLC.

Table 120 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 121 Debug Serial Interface Error Messages 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 122 Debug Serial Interface Err or Messages 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.

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.

[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

The following is sample output from the debug serial packet command when SMDS is enabled on the interface.

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 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. 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   The debug output varies depending on the type of service module installed in the router.

---

Sample Display

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

debug sgbp error

To enable the display of debug messages about routing problems between members of a stack group, use the debug sgbp error command in privileged EXEC mode. The no form of this command disables debugging output.

[no] debug sgbp error

Usage Guidelines

Enable the debug sgbp error command to enable the display of debug messages about routing problems between members of a stack group.

---

Note   In unusual cases you may see debug messages not documented on this command reference page. These debug messages are intended for expert diagnostic interpretation by the Cisco Technical Assistance Center (TAC).

---

Sample Display

One common configuration error is setting a source IP address for a stack member that does not match the locally defined IP address for the same stack member. The following debug output shows the error message that results from this misconfiguration:

Systema# debug sgbp error

%SGBP-7-DIFFERENT - systemb's addr 10.1.1.2 is different from hello's addr 10.3.4.5

This error means that the source IP address of the Stack Group Bidding Protocol (SGBP) hello message received from systemb does not match the IP address configured locally for systemb (through the sgbp member command). Correct this configuaration error by going to systemb and checking for multiple interfaces by which the SGBP hello can send the message.

Another common error message is:

Systema# debug sgbp error

%SGBP-7-MISCONF, Possible misconfigured member routerk (10.1.1.6)

This error message means that routerk is not defined locally, but is defined on another stack member. Correct this configuration error by defining routerk across all members of the stack group using the sgbp member command.

The following error message indicates that an SGBP peer is leaving the stack group:

Systema# debug sgbp error

%SGBP-7-LEAVING:Member systemc leaving group stack1

This error message indicates that the peer systemc is leaving the stack group. Systemc could be leaving the stack group intentionally, or a connectivity problem may exist.

The following error message indicates that an SGBP event was detected from an unknown peer:

Systema# debug sgbp error

%SGBP-7-UNKNOWPEER:Event 0x10 from peer at 172.21.54.3

An SGBP event came from a network host that was not recognizable as an SGBP peer. Check to see if a network media error could have corrupted the address, or if peer equipment is malfunctioning to generate corrupted packets. Depending on the network topology and firewalling of your network, SGBP packets from a nonpeer host could indicate probing and attempts to breach security.

---

Caution If there is a chance your network is under attack, obtain knowledgeable assistance from TAC.

---

Related Commands

debug sgbp hellos
sgbp group
sgbp member
show sgbp
username

debug sgbp hellos

To enable the display of debug messages for authentication between stack members, use the debug sgbp hellos command in privileged EXEC mode. The no form of this command disables debugging output.

[no] debug sgbp hellos

Usage Guidelines

Enable the debug sgbp hellos command to enable the display of debug messages for authentication between routers configured as members of a stack group.

---

Note   In unusual cases you may see debug messages not documented on this command reference page. These debug messages are intended for expert diagnostic interpretation by the Cisco Technical Assistance Center (TAC).

---

Sample Display

The following output from the debug sgbp hellos command shows systema sending a successful Challenge Handshake Authentication Protocol (CHAP) challenge to and receiving a response from systemb. Similarly, systemb sends out a challenge and receives a response from systema:

systema# debug sgbp hellos

%SGBP-7-CHALLENGE: Send Hello Challenge to systemb group stack1

%SGBP-7-CHALLENGED: Hello Challenge message from member systemb (10.1.1.2)

%SGBP-7-RESPONSE: Send Hello Response to systemb group stack1

%SGBP-7-CHALLENGE: Send Hello Challenge to systemb group stack1

%SGBP-7-RESPONDED: Hello Response message from member systemb (10.1.1.2)

%SGBP-7-AUTHOK: Send Hello Authentication OK to member systemb (10.1.1.2)

%SGBP-7-INFO: Addr = 10.1.1.2 Reference = 0xC347DF7

%SGBP-5-ARRIVING: New peer event for member systemb

This debug output is self-explanitory.

If authentication fails, you may see one of the following messages in your debug output:

%SGBP-7-AUTHFAILED - Member systemb failed authentication

This error message means that the remote systemb password for the stack group does not match the password defined on systema. To correct this error, make sure that both systema and systemb have the same password defined using the username command.

%SGBP-7-NORESP -Fail to respond to systemb group stack1, may not have password.

This error message means that systema does not have a username or password defined. To correct this error, define a common group password across all stack members using the username command.

Related Commands

debug sgbp error
sgbp group
sgbp member
show sgbp
username

debug 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 transaction

debug 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

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

lists the messages that may be generated with the debug smrp group command concerning the forwarding table.

Table 123 Debug SMRP Group Message Descriptions 

Messages	Descriptions
Group address, deleted on port address	Group entry was deleted from the group table for the specified port.
Group address, forward state changed from state to state	Group's state changed. Possible states are join, forward, and leave.
Group address, deleted forward entry	Group was deleted from the forwarding table.
Group address, created on port address by address	Group entry was created in the table for the specified port.
Group address, added by address to the group	A secondary router has added this group to its group table.
Group address, discard join request from address, not responsible	Discard Join Group request if the router is not the primary router on the local connected network or if it is not the port parent of the route.
Group address, join request from address	Request to join the group was received.
Group address, forward is found	Forward entry for the group was found in the forwarding table.
Group address, forward state is already joining, ignored	Request to join the group is in progress, so the second request was discarded.
Group address, no forward found	Forward entry for the group was not found in the forwarding table.
Group address, join request discarded, fw discarded, fwd parent port not operational	Request to join the group was discarded because the parent port is not available.
Group address, created forward entry - parent address child address	Forward entry was created in the forwarding table for the parent and child address.
Group address, creator no longer up on address	Group creator has not been heard from for a specified time and is deemed no longer available.
Group address, pruning duplicate path on address	Duplicate path was removed. If we are forwarding and we are a child port, and our port parent address is not pointing to our own port address, we are in a duplicate path.
Group address, member no longer up on address	Group member has not been heard from for a specified time and is deemed no longer available.
Group address, no more child ports in forward entry	Forward entry for group no longer has any child ports. As a result, the forward entry is no longer necessary.

Related Command

debug smrp all

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

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 

lists all the messages that can be generated with the debug smrp mcache command concerning the multicast cache.

Table 124 Debug SMRP Mcache Message Descriptions 

Messages	Descriptions
Cache populated for group address	SMRP packet was received on a parent port that has fast switching enabled. As a result, the cache was created and the MAC and network headers were stored for all child ports that have fast switching enabled. Use the show smrp port appletalk command with the optional interface type and number to display the switching path.
Cache memory allocated	Memory was allocated for the multicast cache.
Forward cache entry created/deleted for group address	Forward cache entry for the group was added to or deleted from the cache.
Forward cache entry validated for group address	Forward cache entry is validated and is now ready for fast switching.
Forward cache entry invalidated for group address	Cache entry is invalidated because some change (such as port was shut down) occurred to one of the ports.

Related Command

debug smrp all

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

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"

lists all the messages that can be generated with the debug smrp neighbor command concerning the neighbor table.

Table 125 Debug SMRP Neighbor Message Descriptions 

Messages	Descriptions
Neighbor address, state changed from state to state	Neighbor's state changed. Possible states are primary operation, secondary operation, normal operation, primary negotiation, secondary negotiation, and down.
Neighbor address, neighbor added/deleted	Neighbor was added to or removed from the neighbor table.
SMRP neighbor up/down	Neighbor is available for service or unavailable.
Neighbor address, no longer up	Neighbor is unavailable because it has not been heard from for a specified duration.

Related Command

debug smrp all

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

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"

lists all the messages that can be generated with the debug smrp port command concerning the port table.

Table 126 Debug SMRP Port Message Descriptions 

Messages	Descriptions
Port address, port created/deleted	Port entry was added to or removed from the port table.
Port address, line protocol changed to state	Line protocol for the port is up or down.
Port address, state changed from state to state	Port's state changed. Possible states are primary operation, secondary operation, normal operation, primary negotiation, secondary negotiation, and down.
Port address, primary/secondary router changed from address to address	Primary or secondary router's port address changed.

Related Command

debug smrp all

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

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

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

Table 127 Debug SMRP Route Message Descriptions 

Messages	Descriptions
Route address, deleted/created as local network	Route entry was removed from or added to the routing table.
Route address, from address has invalid distance value	Route entry from the specified address has an incorrect distance value and was ignored.
Route address, unknown route poisoned by address ignored	Route entry received from the specified address is bad and was ignored.
Route address, created via address - hop number tunnel number	New route entry added to the routing table with the specified number of hops and tunnels.
Route address, from address - overlaps existing route	Route entry received from the specified address overlaps an existing route and was ignored.
Route address, poisoned by address	Route entry has been poisoned by neighbor. Poisoned routes have distance of 255.
Route address, poison notification from address	A poison notification is a poisoned route that is received from a non-parent port.
Route address, worsened by parent address	The distance to the route has worsened (become higher), received from the parent neighbor.
Route address, improved via address - number -> number hop, number -> number tunnel	The distance to the route has improved (become lower), received from a neighbor.
Route address, switched to address - higher address than address	A tie condition exists, and because this router had the highest network address, it was used to forward the packet.
Route address, parent port changed address -> address	Parent port address change occurred. The parent port address of a physical network segment determines which router should handle Join Group and Leave Group requests.
SMRP bad distance vector	Packet has an invalid distance vector and was ignored.
Route address, has been poisoned	Route has been poisoned. Poisoned routes are purged from the routing table after a specified time.

Related Command

debug smrp all

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

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

lists all the messages that can be generated with the debug smrp route command.

Table 128 Debug SMRP Transaction Message Descriptions 

Messages	Descriptions
Transaction for port address, packet-type command-type (grp/sec number) sent to/received from address	Port message concerning a packet or command was sent to or received from the specified address.
Transaction for group address on port address, (seq number) sent to/received from address	Group message for a specified port was sent to or received from the specified address.
Unrecognized transaction for port address	An unrecognized message was received and ignored by the port.
Discarded incomplete request	An incomplete message was received and ignored.
Response in wrong state in HandleRequest	A message was received with the wrong state and was ignored.
SMRP bad packet type	An SMRP packet was received with a bad packet type and was ignored.
Packet discarded, Bad Port ID	A packet was received with a bad port ID and was ignored.
Packet discarded, Check Packet failed	A packet was received with a failed check packet and was ignored.

Related Command

debug smrp all

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

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

describes the significant fields in these displays.

Table 129 Debug SNMP Packet Field Descriptions 

Field	Description
Get-next request	Indicates what type of SNMP PDU the packet is. Possible types are: •Get request •Get-next request •Response •Set request •V1 Trap •Get-bulk request •Inform request •V2 Trap Depending on the type of PDU, the rest of this line displays different fields. The indented lines following this line list the MIB object names and corresponding values.
reqid	Request identification number. This number is used by the SNMP manager to match responses with requests.
errstat	Error status. All PDU types other than response will have an errstat of 0. If the agent encounters an error while processing the request, it will set errstat in the response PDU to indicate the type of error.
erridx	Error index. This value will always be 0 in all PDUs other than responses. If the agent encounters an error, the erridx will be set to indicate which varbind in the request caused the error. For example, if the agent had an error on the 2nd varbind in the request PDU, the response PDU will have an erridx equal to 2.
nonrptr	Non-repeater value. This value and the maximum repetition value are used to determine how many varbinds are returned. Refer to RFC 1905 for details.
maxreps	Maximum repetition value. This value and the non-repeater value are used to determine how many varbinds are returned. Refer to RFC 1905 for details.
ent	Enterprise object identifier. Refer to RFC 1215 for details.
gentrap	Generic trap value. Refer to RFC 1215 for details.
spectrap	Specific trap value. Refer to RFC 1215 for details.

debug snmp requests

To display information about every SNMP request made by the SNMP manager, use the debug snmp requests EXEC command. The no form of this command disables debugging output.

[no] debug snmp requests

Sample Display

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

describes the fields shown in the display.

Table 130 Debug SNMP Requests Field Descriptions 

Field	Description
SNMP Manager API	Indicates that the router sent an SNMP request.
dest	Destination of the request.
community	Community string sent with the request.
retries	Number of times the request has been resent.
timeout	Request timeout, or how long the router will wait before resending the request.
mult	Timeout multiplier. The timeout for a resent request will be equal to the previous timeout multiplied by the timeout multiplier.
use session rtt	Indicates that the session's average round-trip time should be used in calculating the timeout value.
userdata	Internal IOS data.

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

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.

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

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)

describes the significant fields.

Table 131 Debug SNTP Packets Field Descriptions 

Field	Description
length	Length of the SNTP packet.
leap	Indicates if a leap second will be added or subtracted.
mode	Indicates the mode of the router relative to the server sending the packet.
version	SNTP version number of the packet.
stratum	Stratum of the server.
ppoll	Peer polling interval.
rtdel	Total delay along the path to the root clock.
rtdsp	Dispersion of the root path.
refid	Address of the server which the router is currently using for synchronization.
ref	Reference timestamp.
org	Originate timestamp. This value indicates the time the request was sent by the router.
rec	Receive timestamp. This value indicates the time the request was received by the SNTP server.
xmt	Transmit timestamp. This value indicates the time the reply was sent by the SNTP server.
inp	Destination timestamp. This value indicate the time the reply was received by the router.

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

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

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 Displays

The following is sample output from the debug source bridge output for peer bridges using TCP as a transport mechanism. The remote source-route bridging (RSRB) network configuration has ring 2 and ring 1 bridged together through remote peer bridges. The remote peer bridges are connected via a serial line and use TCP as the transport mechanism.

Router# debug source 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

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

The following is sample output from the debug source bridge command for peer bridges using direct encapsulation as a transport mechanism. The RSRB network configuration has ring 1 and ring 2 bridged together through peer bridges. The peer bridges are connected via a serial line and use TCP as the transport mechanism.

Router# debug source 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

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

Please 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 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 fo