Table Of Contents
debug ipx ipxwan
Use the debug ipx ipxwan EXEC command to display debug information for interfaces configured to use IPXWAN. The no form of this command disables debugging output.
[no] debug ipx ipxwan
Usage Guidelines
The debug ipx ipxwan command is useful for verifying the startup negotiations between two routers running the IPX protocol through a WAN. This command produces output only during state changes or startup. During normal operations, no output is produced.
Sample Display
shows sample debug ipx ipxwan output during link startup.
Figure 2-114 Sample Debug IPX IPXWAN Output
router# debug ipx ipxwan%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to upIPXWAN: state (Disconnect -> Sending Timer Requests) [Serial1/6666:200 (IPX linestate brought up)]IPXWAN: state (Sending Timer Requests -> Disconnect) [Serial1/6666:200 (IPX linestate brought down)]IPXWAN: state (Disconnect -> Sending Timer Requests) [Serial1/6666:200 (IPX linestate brought up)]IPXWAN: Send TIMER_REQ [seq 0] out Serial1/6666:200IPXWAN: Send TIMER_REQ [seq 1] out Serial1/6666:200IPXWAN: Send TIMER_REQ [seq 2] out Serial1/6666:200IPXWAN: Send TIMER_REQ [seq 0] out Serial1/6666:200IPXWAN: Rcv TIMER_REQ on Serial1/6666:200, NodeID 1234, Seq 1IPXWAN: Send TIMER_REQ [seq 1] out Serial1/6666:200IPXWAN: Rcv TIMER_RSP on Serial1/6666:200, NodeID 1234, Seq 1, Del 6IPXWAN: state (Sending Timer Requests -> Master: Sent RIP/SAP) [Serial1/6666:200(Received Timer Response as master)]IPXWAN: Send RIPSAP_INFO_REQ [seq 0] out Serial1/6666:200IPXWAN: Rcv RIPSAP_INFO_RSP from Serial1/6666:200, NodeID 1234, Seq 0IPXWAN: state (Master: Sent RIP/SAP -> Master: Connect) [Serial1/6666:200 (Received RouterInfo Rsp as Master)]Explanations for representative lines of output in follow.
The following line indicates that the interface has initialized:
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to upThe following lines indicate that the startup process failed to receive a timer response, brought the link down, then brought the link up and tried again with a new timer set:
IPXWAN: state (Sending Timer Requests -> Disconnect) [Serial1/6666:200 (IPX linestate brought down)]IPXWAN: state (Disconnect -> Sending Timer Requests) [Serial1/6666:200 (IPX linestate brought up)]The following lines indicate that the interface is sending timer requests and waiting on timer response:
IPXWAN: Send TIMER_REQ [seq 0] out Serial1/6666:200IPXWAN: Send TIMER_REQ [seq 1] out Serial1/6666:200The following lines indicate that the interface has received a timer request from the other end of the link and has sent a timer response. The fourth line shows that the interface has come up as the master on the link.
IPXWAN: Rcv TIMER_REQ on Serial1/6666:200, NodeID 1234, Seq 1IPXWAN: Send TIMER_REQ [seq 1] out Serial1/6666:200IPXWAN: Rcv TIMER_RSP on Serial1/6666:200, NodeID 1234, Seq 1, Del 6IPXWAN: state (Sending Timer Requests -> Master: Sent RIP/SAP) [Serial1/6666:200(Received Timer Response as master)]The following lines indicate that the interface is sending RIP/SAP requests:
IPXWAN: Send RIPSAP_INFO_REQ [seq 0] out Serial1/6666:200IPXWAN: Rcv RIPSAP_INFO_RSP from Serial1/6666:200, NodeID 1234, Seq 0IPXWAN: state (Master: Sent RIP/SAP -> Master: Connect) [Serial1/6666:200 (Received Router Info Rsp as Master)]debug ipx nasi
Use the debug ipx nasi EXEC command to display information about the NetWare Asynchronous Services Interface (NASI) connections. The no form of this command disables debugging output.
[no] debug ipx nasi {packets | error | activity}
Syntax Description
Usage Guidelines
Use the debug ipx nasi command to display handshaking or negotiating details between the protocol (SPX or NASI) and the other protocols or applications. Use the packets option to determine the NASI traffic flow, and use the error option as a quick check of failure reasons in NASI connections.
Sample Display
shows sample debug ipx nasi output of the packet and error options.
Figure 2-115 Sample Debug IXP NASI Output
router# debug ipx nasi packetrouter# debug ipx nasi errorNASI0: 6E6E Check server infoNASI0: 6E6E sending server-info 4F00 Good response: 43 bytesNASI0: 7A6E Query Port. Find firstNASI0: FFirst: line 0 DE, port: TTY1-__________ASYNC___^, group: ASYNC___^NASI0: 7A6E sending Qport find-first response: 300 bytesNASI0: 7B6E port request. setting up portNASI: Check-login User: c h r i sNASI: Check-login PW hash: C7 A6 C5 C7 C4 C0 C5 C3 C4 CC C5 CF C4 C8 C5 CB C4 D4 C5 D7 C4 D0 C5 D3 C4NASI: Check-login PW: l a bNASI1: 7B6E sending NCS Good server Data Ack in 0 bytes pkt in 13 size pktNASI1: 7B6E sending Preq response: 303 bytes GoodNASI1: 7B6E port request. setting up portNASI1: 7B6E sending NCS Good server Data Ack in 0 bytes pkt in 13 size pktNASI1: 7B6E sending Preq response: 303 bytes GoodNASI1: 7B6E Unknown NASI code 4500 Pkt Size: 1345 0 0 FC 0 2 0 20 0 0 FF 1 0NASI1: 7B6E Flush Rx BuffersNASI1: 7B6E sending NASI server TTY data: 1 byte in 14 size pktNASI1: 7B6E sending NCS Good server Data Ack in 1 bytes pkt in 13 size pktThe following text describes some of the lines in the debug ipx nasi output shown in .
In the following line, the 0 in NASI0 is the number of the terminal (TTY) to which this NASI connection is attached. TTY 0 is used by all NASI control connections. 6E6E is the associated SPX connection pointer for this NASI connection. Check server info is a type of NASI packet that indicates an incoming NASI packet of this type.
NASI0: 6E6E Check server infoThe following message indicates the router is sending back a server-info packet with a positive acknowledgment, and the packet size is 43 bytes:
NASI0: 6E6E sending server-info 4F00 Good response: 43 bytesThe following line is a NASI packet type. Find first and find next are NASI packet types.
NASI0: 7A6E Query Port. Find firstThe following line indicates that the outgoing find first packet for the NASI connection 7A6E has line 0 DE, port name TTY1, and general name ASYNC:
NASI0: FFirst: line 0 DE, port: TTY1-__________ASYNC___^, group: ASYNC___^The following two lines indicate a received NASI packet for NASI connection on line 1. 7B6E is the NASI connection pointer. The packet code is 4500 and is not recognizable by Cisco. The second line is a hexadecimal dump of the packet.
NASI1: 7B6E Unknown NASI code 4500 Pkt Size: 1345 0 0 FC 0 2 0 20 0 0 FF 1 0Related Command
debug ipx packet
Use the debug ipx packet EXEC command to display information about packets received, transmitted, and forwarded. The no form of this command disables debugging output.
[no] debug ipx packet
Usage Guidelines
This command is useful for learning whether IPX packets are traveling over a router.
Note
In order to generate debug ipx packet information on all IPX traffic traveling over the router, you must first configure the router so that fast switching is disabled. Use the no ipx route-cache command on all interfaces on which you want to observe traffic. If the router is configured for IPX fast switching, only non-fast switched packets will produce output. When the IPX cache is invalidated or cleared, one packet for each destination is displayed as the cache is repopulated.
Sample Display
shows sample debug ipx packet output.
Figure 2-116 Sample Debug IPX Packet Output
router# debug ipx packetNovell: src=160.0260.8c4c.4f22, dst=1.0000.0000.0001, packet receivedNovell: src=160.0260.8c4c.4f22, dst=1.0000.0000.0001,gw=183.0000.0c01.5d85,sending packetIn , the first line indicates that the router receives a packet from a Novell station (address 160.0260.8c4c.4f22); this trace does not indicate the address of the immediate router sending the packet to this router. In the second line, the router forwards the packet toward the Novell server (address 1.0000.0000.0001) through an immediate router (183.0000.0c01.5d85).
describes significant fields shown in .
debug ipx routing
Use the debug ipx routing EXEC command to display information on IPX routing packets that the router sends and receives. The no form of this command disables debugging output.
[no] debug ipx routing
Usage Guidelines
Normally, a router or server sends out one routing update per minute. Each routing update packet can include up to 50 entries. If many networks exist on the internetwork, the router sends out multiple packets per update. For example, if a router has 120 entries in the routing table, it would send three routing update packets per update. The first routing update packet would include the first 50 entries, the second packet would include the next 50 entries, and the last routing update packet would include the last 20 entries.
Sample Display
shows sample debug ipx routing output.
Figure 2-117 Sample Debug IPX Routing Output
router# debug ipx routingNovellRIP: update from 9999.0260.8c6a.1733110801 in 1 hops, delay 2NovellRIP: sending update to 12FF02:ffff.ffff.ffff via Ethernet 1network 555, metric 2, delay 3network 1234, metric 3, delay 4describes significant fields shown in .
Related Command
debug ipx sap
Use the debug ipx sap EXEC command to display information about IPX Service Advertisement Protocol (SAP) packets. The no form of this command disables debugging output.
debug ipx sap [activity | events]
no debug ipx sapSyntax Description
Usage Guidelines
Normally, a router or server sends out one SAP update per minute. Each SAP packet can include up to seven entries. If many servers are advertising on the network, the router sends out multiple packets per update. For example, if a router has 20 entries in the SAP table, it would send three SAP packets per update. The first SAP would include the first seven entries, the second SAP would include the next seven entries, and the last update would include the last six entries.
Obtain the most meaningful detail by using the debug ipx sap activity and the debug ipx sap events commands together.
CautionBecause the debug ipx sap command can generate a lot of output, use it with caution on networks that have many interfaces and large service tables.
Sample Display
shows sample debug ipx sap output.
Figure 2-118 Sample Debug IPX SAP Output
As shows, the debug ipx sap command generates multiple lines of output for each SAP packet—a packet summary message and a service detail message.
The first line displays the internal router memory address of the packet. The technical support staff may use this information in problem debugging.
NovellSAP: at 0023F778:describes the fields shown in the second line of output in .
describes the fields shown in the third and fourth lines of output in .
The fifth line of output indicates that the router sent a SAP update to network 160:
NovellSAP: sending update to 160As shows, the format for debug ipx sap output describing a SAP update the router sends is similar to that describing a SAP update the router receives, except that the ssoc: field replaces the src: field, as the following line of output indicates:
O SAP Update type 0x2 len 96 ssoc:0x452 dest:160.ffff.ffff.ffff(452)describes possible values for the ssoc: field.
Related Command
debug ipx spoof
Use the debug ipx spoof EXEC command to display information about SPX keepalive and IPX watchdog packets when ipx watchdog and ipx spx-spoof are configured on the router. The no form of this command disables debugging output.
[no] debug ipx spoof
Usage Guidelines
Use this command to troubleshoot connections that use sequential packet exchange (SPX) spoofing when SPX keepalive spoofing is enabled.
Sample Display
shows sample debug ipx spoof output.
Figure 2-119 Sample Debug IPX Spoof Output
router# debug ipx spoofIPX: Tu1:200.0260.8c8d.da75->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7004 4B8 8 1D 23 (new) (changed:yes) Last Changed 0IPX: Tu1:200.0260.8c8d.c558->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7104 2B8 7 29 2E (new) (changed:yes) Last Changed 0IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.c558 ln= 42 tc=02, SPX: 80 0 2B8 7104 29 7 7 (early)IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.da75 ln= 42 tc=02, SPX: 80 0 4B8 7004 1D 8 8 (early)IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.da75 ln= 32 tc=02, watchdogIPX: local:200.0260.8c8d.da75->CC0001.0000.0000.0001 ln= 32 tc=00, watchdog snetIPX: Tu1:200.0260.8c8d.da75->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7004 4B8 8 1D 23 (changed:clear) Last Changed 0IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.c558 ln= 42 tc=02, SPX: C0 0 2B8 7104 29 7 7 (early)IPX: Tu1:200.0260.8c8d.c558->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7104 2B8 7 29 2E (changed:clear) Last Changed 0IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.c558 ln= 42 tc=02, SPX: C0 0 2B8 7104 29 7 7 (Last Changed 272 sec)IPX: local:200.0260.8c8d.c558->CC0001.0000.0000.0001 ln= 42 tc=02, spx keepalive sent 80 0 7104 2B8 7 29 2EExplanations for lines of output shown in follow.
The following lines show that SPX packets were seen, but they are not seen for a connection that exists in the SPX table.
IPX: Tu1:200.0260.8c8d.da75->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7004 4B8 8 1D 23 (new) (changed:yes) Last Changed 0IPX: Tu1:200.0260.8c8d.c558->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7104 2B8 7 29 2E (new) (changed:yes) Last Changed 0The following lines show SPX packets are for connections that exist in the SPX table but SPX idle time has not yet elapsed and spoofing has not started.
IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.c558 ln= 42 tc=02, SPX: 80 0 2B8 7104 29 7 7 (early)IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.da75 ln= 42 tc=02, SPX: 80 0 4B8 7004 1D 8 8 (early)The following lines show an IPX watchdog packet and the spoofed reply.
IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.da75 ln= 32 tc=02, watchdogIPX: local:200.0260.8c8d.da75->CC0001.0000.0000.0001 ln= 32 tc=00, watchdog sentThe following lines show SPX packets that arrived more than two minutes after spoofing started. This situation occurs when the other sides of the SPX table are cleared. When the table is cleared, the routing processes stop spoofing the connection, which allows SPX keepalives from the local side to travel to the remote side and repopulate the SPX table.
IPX: Tu1:200.0260.8c8d.da75->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7004 4B8 8 1D 23 (changed:clear) Last Changed 0IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.c558 ln= 42 tc=02, SPX: C0 0 2B8 7104 29 7 7 (early)IPX: Tu1:200.0260.8c8d.c558->CC0001.0000.0000.0001 ln= 42 tc=02, SPX: 80 0 7104 2B8 7 29 2E (changed:clear) Last Changed 0The following lines show that an SPX keepalive packet came in and was spoofed:
IPX: Et1:CC0001.0000.0000.0001->200.0260.8c8d.c558 ln= 42 tc=02, SPX: C0 0 2B8 7104 29 7 7 (Last Changed 272 sec)IPX: local:200.0260.8c8d.c558->CC0001.0000.0000.0001 ln= 42 tc=02, spx keepalive sent 80 0 7104 2B8 7 29 2Edebug ipx spx
Use the debug ipx spx EXEC command to display debugging messages related to the Sequenced Packet Exchange (SPX) protocol. The no form of this command disables debugging output.
[no] debug ipx spx
Usage Guidelines
Use the debug ipx spx command to display handshaking or negotiating details between the SPX protocol and the other protocols or applications. SPX debugging messages indicate various states of SPX connections such as incoming and outgoing traffic information, timer events, and related processing of SPX connections.
Sample Display
shows sample debug ipx spx output.
Figure 2-120 Sample Debug IXP SPX Output
router# debug ipx spxSPX: Sent an SPX packetSPX: I Con Src/Dst 776E/20A0 d-strm 0 con-ctl 80SPX: I Con Src/Dst 776E/20A0 d-strm FE con-ctl 40SPX: C847C Connection close requested by peerSPX: Sent an SPX packetSPX: purge timer fired. Cleaning up C847CSPX: purging spxcon C847C from conQSPX: returning inQ buffersSPX: returning outQ buffersSPX: returning unackedQ buffersSPX: returning spxconSPX: I Con Src/Dst 786E/FFFF d-strm 0 con-ctl C0SPX: new connection request for listening socketSPX: Sent an SPX packetSPX: I Con Src/Dst 786E/20B0 d-strm 0 con-ctl 40SPX: 300 bytes data recvdSPX: Sent an SPX packetThe following text describes some of the lines in the debug ipx spx output shown in .
The following line indicates an incoming SPX packet that has a source connection ID of 776E and a destination connection ID of 20A0 (both in hexadecimal). The data stream value in the SPX packet is indicated by d-strm, and the connection control value in the SPX packet is indicated by con-ctl (both in hexadecimal). All data packets received are followed by an SPX debug message indicating the size of the packet. All control packets received are consumed internally.
SPX: I Con Src/Dst 776E/20A0 d-strm 0 con-ctl 80The following lines indicate that SPX is attempting to remove an SPX connection that has the address C8476 from its list of connections:
SPX: purge timer fired. Cleaning up C847CSPX: purging spxcon C847C from conQRelated Commands
debug isdn event
Use the debug isdn event EXEC command to display Integrated Services Digital Network (ISDN) events occurring on the user side (on the router) of the ISDN interface. The ISDN events that can be displayed are Q.931 events (call setup and teardown of ISDN network connections). The no form of this command disables debugging output.
[no] debug isdn event
Usage Guidelines
Although the debug isdn event and the debug isdn q931 commands provide similar debug information, the information is displayed in a different format. If you want to see the information in both formats, enable both commands at the same time. The displays will be intermingled.
Use the show dialer command to retrieve information about the status and configuration of the ISDN interface on the router.
Use the service timestamps debug datetime msec global configuration command to include the time with each message.
For more information on ISDN switch types, codes, and values, refer to the "ISDN Switch Types, Codes, and Values" appendix.
Sample Display
shows sample debug isdn event output of call setup events for an outgoing call.
Figure 2-121 Sample Debug ISDN Event Output—Call Setup Outgoing Call
router# debug isdn eventISDN Event: Call to 415555121202received HOST_PROCEEDINGChannel ID i = 0x0101-------------------Channel ID i = 0x89received HOST_CONNECTChannel ID i = 0x0101ISDN Event: Connected to 415555121202 on B1 at 64 Kb/sshows sample debug isdn event output of call setup events for an incoming call. The values used for internal purposes are unpacked information elements. The values that follow the ISDN specification are an interpretation of the unpacked information elements. Refer to the "ISDN Switch Types, Codes, and Values" appendix for information about these values.
Figure 2-122 Sample Debug ISDN Event Output—Call Setup Incoming Call
router# debug isdn eventreceived HOST_INCOMING_CALLBearer Capability i = 0x080010-------------------Channel ID i = 0x0101Calling Party Number i = 0x0000, `415555121202'IE out of order or end of `private' IEs --Bearer Capability i = 0x8890Channel ID i = 0x89Calling Party Number i = 0x0083, `415555121202'ISDN Event: Received a call from 415555121202 on B1 at 64 Kb/sISDN Event: Accepting the callreceived HOST_CONNECTChannel ID i = 0x0101ISDN Event: Connected to 415555121202 on B1 at 64 Kb/sshows sample debug isdn event output of call teardown events for a call that has been disconnected by the host side of the connection.
Figure 2-123 Sample Debug ISDN Event Output—Call Teardown by Far End
router# debug isdn eventreceived HOST_DISCONNECTISDN Event: Call to 415555121202 was hung upshows sample debug isdn event output of a call teardown event for an outgoing or incoming call that has been disconnected by the ISDN interface on the router side.
Figure 2-124 Sample Debug ISDN Event Output—Call Teardown Local Side
router# debug isdn eventISDN Event: Hangup call to call id 0x8008describes significant fields shown in through .
Table 2-65 Debug ISDN Event Field Descriptions
Bearer Capability
Indicates the requested bearer service to be provided by the network. Refer to Table B-4 in the ""ISDN Switch Types, Codes, and Values" appendix for detailed information about bearer capability values.
i=
Indicates the Information Element Identifier. The value depends on the field it is associated with. Refer to the ITU-T1 Q.931 specification for details about the possible values associated with each field for which this identifier is relevant.
Channel ID
Indicates the Channel Identifier. The value 83 indicates any channel, 0101 indicates the B1 channel, and 89 indicates the B1 channel. For more information about the Channel Identifier, refer to ITU-T Recommendation Q.931.
Calling Party Number
Identifies the called party. This field is only present in outgoing calls. The Calling Party Number field uses the IA5 character set. Note that it may be replaced by the Keypad facility field.
IE out of order or end of `private' IEs
Indicates that an information element identifier is out of order or there are no more private network information element identifiers to interpret.
Received a call from 415555121202 on B1 at 64Kb/s
Identifies the origin of the call. This field is present only in incoming calls. Note that the information about the incoming call includes the channel and speed. Whether the channel and speed are displayed depends on the network delivering the calling party number.
1 The ITU-T carries out the functions of the former Consultative Committee for International Telegraph and Telephone.
shows sample debug isdn event output of a call teardown event for a call that has passed call screening then has been hung up by the ISDN interface on the far end side.
Figure 2-125 Sample Debug ISDN Event Output—Call Screening Normal Disconnect
router# debug isdn eventJan 3 11:29:52.559: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0x81Jan 3 11:29:52.563: Cause i = 0x8090 - Normal call clearingshows sample debug isdn event output of a call teardown event for a call that has not passed call screening and has been rejected by the ISDN interface on the router side.
Figure 2-126 Sample Debug ISDN Event Output—Call Screening Call Rejection
router# debug isdn eventJan 3 11:32:03.263: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0x85Jan 3 11:32:03.267: Cause i = 0x8095 - Call rejectedshows sample debug isdn event output of a call teardown event for an outgoing call that uses a dialer subaddress.
Figure 2-127 Sample Debug ISDN Event Output—Called Party Subaddress
router# debug isdn eventJan 3 11:41:48.483: ISDN BR0: Event: Call to 61885:1212 at 64 Kb/sJan 3 11:41:48.495: ISDN BR0: TX -> SETUP pd = 8 callref = 0x04Jan 3 11:41:48.495: Bearer Capability i = 0x8890Jan 3 11:41:48.499: Channel ID i = 0x83Jan 3 11:41:48.503: Called Party Number i = 0x80, '61885'Jan 3 11:41:48.507: Called Party SubAddr i = 0x80, 'P1212'Jan 3 11:41:48.571: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0x84Jan 3 11:41:48.575: Channel ID i = 0x89Jan 3 11:41:48.587: ISDN BR0: Event: incoming ces value = 1Jan 3 11:41:48.587: ISDN BR0: received HOST_PROCEEDINGChannel ID i = 0x0101Jan 3 11:41:48.591: -------------------Channel ID i = 0x89Jan 3 11:41:48.731: ISDN BR0: RX <- CONNECT pd = 8 callref = 0x84Jan 3 11:41:48.743: ISDN BR0: Event: incoming ces value = 1Jan 3 11:41:48.743: ISDN BR0: received HOST_CONNECTChannel ID i = 0x0101Jan 3 11:41:48.747: -------------------%LINK-3-UPDOWN: Interface BRI0:1 changed state to upJan 3 11:41:48.771: ISDN BR0: Event: Connected to 61885:1212 on B1 at 64 Kb/sJan 3 11:41:48.775: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x04%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up%ISDN-6-CONNECT: Interface BRI0:1 is now connected to 61885:1212 goodieThe output shown in through is similar to the output of debug isdn q931. Refer to this section for detailed field descriptions.
debug isdn q921
Use the debug isdn q921 EXEC command to display data link layer (Layer 2) access procedures that are taking place at the router on the D channel (LAPD) of its Integrated Services Digital Network (ISDN) interface. The no form of this command disables debugging output.
[no] debug isdn q921
Usage Guidelines
The ISDN data link layer interface provided by the router conforms to the user interface specification defined by ITU-T recommendation Q.921. The debug isdn q921 command output is limited to commands and responses exchanged during peer-to-peer communication carried over the D channel. This debug information does not include data transmitted over the B channels that are also part of the router's ISDN interface. The peers (data link layer entities and layer management entities on the routers) communicate with each other via an ISDN switch over the D channel.
Note
A router can be the calling or called party of the ISDN Q.921 data link layer access procedures. If the router is the calling party, the command displays information about an outgoing call. If the router is the called party, the command displays information about an incoming call and the keepalives.
The debug isdn q921 command can be used with the debug isdn event and the debug isdn q931 commands at the same time. The displays will be intermingled.
Use the service timestamps debug datetime msec global configuration command to include the time with each message.
For more information on ISDN switch types, codes, and values, refer to the "ISDN Switch Types, Codes, and Values" appendix.
Sample Display
shows sample debug isdn q921 output for an outgoing call.
Figure 2-128 Sample Debug ISDN Q921 Output—Outgoing Call
router# debug isdn q921Jan 3 14:52:24.475: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 5 nr = 2i = 0x08010705040288901801837006803631383835Jan 3 14:52:24.503: ISDN BR0: RX <- RRr sapi = 0 tei = 64 nr = 6Jan 3 14:52:24.527: ISDN BR0: RX <- INFOc sapi = 0 tei = 64 ns = 2 nr = 6i = 0x08018702180189Jan 3 14:52:24.535: ISDN BR0: TX -> RRr sapi = 0 tei = 64 nr = 3Jan 3 14:52:24.643: ISDN BR0: RX <- INFOc sapi = 0 tei = 64 ns = 3 nr = 6i = 0x08018707Jan 3 14:52:24.655: ISDN BR0: TX -> RRr sapi = 0 tei = 64 nr = 4%LINK-3-UPDOWN: Interface BRI0:1, changed state to upJan 3 14:52:24.683: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 6 nr = 4i = 0x0801070FJan 3 14:52:24.699: ISDN BR0: RX <- RRr sapi = 0 tei = 64 nr = 7%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up%ISDN-6-CONNECT: Interface BRI0:1 is now connected to 61885 goodieJan 3 14:52:34.415: ISDN BR0: RX <- RRp sapi = 0 tei = 64 nr = 7Jan 3 14:52:34.419: ISDN BR0: TX -> RRf sapi = 0 tei = 64 nr = 4In the following lines from , the seventh and eighth most significant hexadecimal numbers indicate the type of message. 0x05 indicates a Call Setup message, 0x02 indicates a Call Proceeding message, 0x07 indicates a Call Connect message, and 0x0F indicates a Connect Ack message.
Jan 3 14:52:24.475: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 5 nr = 2i = 0x08010705040288901801837006803631383835Jan 3 14:52:24.527: ISDN BR0: RX <- INFOc sapi = 0 tei = 64 ns = 2 nr = 6i = 0x08018702180189Jan 3 14:52:24.643: ISDN BR0: RX <- INFOc sapi = 0 tei = 64 ns = 3 nr = 6i = 0x08018707Jan 3 14:52:24.683: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 6 nr = 4i = 0x0801070Fshows sample debug isdn q921 output for a startup message on a DMS-100 switch.
Figure 2-129 Sample Debug ISDN Q921 Output—Startup Message on a DMS-100 Switch
router# debug isdn q921Jan 3 14:47:28.455: ISDN BR0: RX <- IDCKRQ ri = 0 ai = 127 0Jan 3 14:47:30.171: ISDN BR0: TX -> IDREQ ri = 31815 ai = 127Jan 3 14:47:30.219: ISDN BR0: RX <- IDASSN ri = 31815 ai = 64Jan 3 14:47:30.223: ISDN BR0: TX -> SABMEp sapi = 0 tei = 64Jan 3 14:47:30.227: ISDN BR0: RX <- IDCKRQ ri = 0 ai = 127Jan 3 14:47:30.235: ISDN BR0: TX -> IDCKRP ri = 16568 ai = 64Jan 3 14:47:30.239: ISDN BR0: RX <- UAf sapi = 0 tei = 64Jan 3 14:47:30.247: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 0 nr = 0i = 0x08007B3A03313233Jan 3 14:47:30.267: ISDN BR0: RX <- RRr sapi = 0 tei = 64 nr = 1Jan 3 14:47:34.243: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 1 nr = 0i = 0x08007B3A03313233Jan 3 14:47:34.267: ISDN BR0: RX <- RRr sapi = 0 tei = 64 nr = 2Jan 3 14:47:43.815: ISDN BR0: RX <- RRp sapi = 0 tei = 64 nr = 2Jan 3 14:47:43.819: ISDN BR0: TX -> RRf sapi = 0 tei = 64 nr = 0Jan 3 14:47:53.819: ISDN BR0: TX -> RRp sapi = 0 tei = 64 nr = 0The first seven lines of this example indicate an L2 link establishment. Explanations for individual lines of output from follow.
The following lines indicate the message exchanges between the data link layer entity on the local router (user side) and the assignment source point (ASP) on the network side during the TEI assignment procedure. This assumes that the link is down and no TEI currently exists.
Jan 3 14:47:30.171: ISDN BR0: TX -> IDREQ ri = 31815 ai = 127Jan 3 14:47:30.219: ISDN BR0: RX <- IDASSN ri = 31815 ai = 64At 14:47:30.171, the local router data link layer entity sent an Identity Request message to the network data link layer entity to request a TEI value that can be used in subsequent communication between the peer data link layer entities. The request includes a randomly generated reference number (31815) to differentiate among user devices that request automatic TEI assignment and an action indicator of 127 to indicate that the ASP can assign any TEI value available. The ISDN user interface on the router uses automatic TEI assignment.
At 14:47:30.219, the network data link entity responds to the Identity Request message with an Identity Assigned message. The response includes the reference number (31815) previously sent in the request and TEI value (64) assigned by the ASP.
The following lines indicate the message exchanges between the layer management entity on the network and the layer management entity on the local router (user side) during the TEI check procedure:
Jan 3 14:47:30.227: ISDN BR0: RX <- IDCKRQ ri = 0 ai = 127Jan 3 14:47:30.235: ISDN BR0: TX -> IDCKRP ri = 16568 ai = 64At 14:47:30.227, the layer management entity on the network sends the Identity Check Request message to the layer management entity on the local router to check whether a TEI is in use. The message includes a reference number that is always 0 and the TEI value to check. In this case, an ai value of 127 indicates that all TEI values should be checked. At 14:47:30.227, the layer management entity on the local router responds with an Identity Check Response message indicating that TEI value 64 is currently in use.
The following lines indicate the messages exchanged between the data link layer entity on the local router (user side) and the data link layer on the network side to place the network side into modulo 128 multiple frame acknowledged operation. Note that the data link layer entity on the network side also can initiate the exchange.
Jan 3 14:47:30.223: ISDN BR0: TX -> SABMEp sapi = 0 tei = 64Jan 3 14:47:30.239: ISDN BR0: RX <- UAf sapi = 0 tei = 64At 14:47:30.223, the data link layer entity on the local router sends the SABME command with a SAPI of 0 (call control procedure) for TEI 64. At 14:47:30.239, the first opportunity, the data link layer entity on the network responds with a UA response. This response indicates acceptance of the command. The data link layer entity sending the SABME command may have to send it more than once before receiving a UA response.
The following lines indicate the status of the data link layer entities. Both are ready to receive I frames.
Jan 3 14:47:43.815: ISDN BR0: RX <- RRp sapi = 0 tei = 64 nr = 2Jan 3 14:47:43.819: ISDN BR0: TX -> RRf sapi = 0 tei = 64 nr = 0These I frames are typically exchanged every 10 seconds (T203 timer).
shows sample debug isdn q921 output for an incoming call. It is an incoming SETUP message that assumes the L2 link is already established to the other side.
Figure 2-130 Sample Debug ISDN Q921 Output—Incoming Call
router# debug isdn q921Jan 3 14:49:22.507: ISDN BR0: TX -> RRp sapi = 0 tei = 64 nr = 0Jan 3 14:49:22.523: ISDN BR0: RX <- RRf sapi = 0 tei = 64 nr = 2Jan 3 14:49:32.527: ISDN BR0: TX -> RRp sapi = 0 tei = 64 nr = 0Jan 3 14:49:32.543: ISDN BR0: RX <- RRf sapi = 0 tei = 64 nr = 2Jan 3 14:49:42.067: ISDN BR0: RX <- RRp sapi = 0 tei = 64 nr = 2Jan 3 14:49:42.071: ISDN BR0: TX -> RRf sapi = 0 tei = 64 nr = 0Jan 3 14:49:47.307: ISDN BR0: RX <- UI sapi = 0 tei = 127i = 0x08011F05040288901801897006C13631383836%LINK-3-UPDOWN: Interface BRI0:1, changed state to upJan 3 14:49:47.347: ISDN BR0: TX -> INFOc sapi = 0 tei = 64 ns = 2 nr = 0i = 0x08019F07180189Jan 3 14:49:47.367: ISDN BR0: RX <- RRr sapi = 0 tei = 64 nr = 3Jan 3 14:49:47.383: ISDN BR0: RX <- INFOc sapi = 0 tei = 64 ns = 0 nr = 3i = 0x08011F0F180189Jan 3 14:49:47.391: ISDN BR0: TX -> RRr sapi = 0 tei = 64 nr = 1%LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to updescribes significant fields in , , and .
Table 2-66 Debug ISDN Q921 Field Descriptions
Jan 3 14:49:47.391
Indicates the date and time at which the frame was transmitted from or received by the data link layer entity on the router. The time is maintained by an internal clock.
TX
Indicates that this frame is being transmitted from the ISDN interface on the local router (user side).
RX
Indicates that this frame is being received by the ISDN interface on the local router from the peer (network side).
IDREQ
Indicates the Identity Request message type sent from the local router to the network (assignment source point [ASP]) during the automatic terminal endpoint identifier (TEI) assignment procedure. This message is sent in a UI command frame. The service access point identifier (SAPI) value for this message type is always 63 (indicating that it is a Layer 2 management procedure) but it is not displayed. The TEI value for this message type is 127 (indicating that it is a broadcast operation).
ri = 31815
Indicates the Reference number used to differentiate between user devices requesting TEI assignment. This value is a randomly generated number between 0 and 65535. The same ri value sent in the IDREQ message should be returned in the corresponding IDASSN message. Note that a Reference number of 0 indicates that the message is sent from the network side management layer entity and a reference number has not been generated.
ai = 127
Indicates the Action indicator used to request that the ASP assign any TEI value. It is always 127 for the broadcast TEI. Note that in some message types, such as IDREM, a specific TEI value is indicated.
IDREM
Indicates the Identity Remove message type sent from the ASP to the user side layer management entity during the TEI removal procedure. This message is sent in a UI command frame. The message includes a reference number that is always 0, because it is not responding to a request from the local router. The ASP sends the Identity Remove message twice to avoid message loss.
IDASSN
Indicates the Identity Assigned message type sent from the ISDN service provider on the network to the local router during the automatic TEI assignment procedure. This message is sent in a UI command frame. The SAPI value for this message type is always 63 (indicating that it is a Layer 2 management procedure). The TEI value for this message type is 127 (indicating it is a broadcast operation).
ai = 64
Indicates the TEI value automatically assigned by the ASP. This TEI value is used by data link layer entities on the local router in subsequent communication with the network. The valid values are in the range 64 to 126.
SABME
Indicates the set asynchronous balanced mode extended command. This command places the recipient into modulo 128 multiple frame acknowledged operation. This command also indicates that all exception conditions have been cleared. The SABME command is sent once a second for N200 times (typically three times) until its acceptance is confirmed with a UA response. For a list and brief description of other commands and responses that can be exchanged between the data link layer entities on the local router and the network, see ITU-T Recommendation Q.921.
sapi = 0
Identifies the service access point at which the data link layer entity provides services to Layer 3 or to the management layer. A SAPI with the value 0 indicates it is a call control procedure. Note that the Layer 2 management procedures such as TEI assignment, TEI removal, and TEI checking, which are tracked with the debug isdn q921 command, do not display the corresponding SAPI value; it is implicit. If the SAPI value were displayed it would be 63.
tei = 90
Indicates the TEI value automatically assigned by the ASP. This TEI value will be used by data link layer entities on the local router in subsequent communication with the network. The valid values are in the range 64 to 126.
IDCKRQ
Indicates the Identity Check Request message type sent from the ISDN service provider on the network to the local router during the TEI check procedure. This message is sent in a UI command frame. The ri field is always 0. The ai field for this message contains either a specific TEI value for the local router to check or 127, which indicates that the local router should check all TEI values. For a list and brief description of other message types that can be exchanged between the local router and the ISDN service provider on the network, see the "ISDN Switch Types, Codes, and Values" appendix.
IDCKRP
Indicates the Identity Check Response message type sent from the local router to the ISDN service provider on the network during the TEI check procedure. This message is sent in a UI command frame in response to the IDCKRQ message. The ri field is a randomly generated number between 0 and 65535. The ai field for this message contains the specific TEI value that has been checked.
UAf
Confirms that the network side has accepted the SABME command previously sent by the local router. The final bit is set to 1.
INFOc
Indicates that this is an Information command. It is used to transfer sequentially numbered frames containing information fields that are provided by Layer 3. The information is transferred across a datalink connection.
INFORMATION pd = 8 callref = (null)
Indicates the information fields provided by Layer 3. The information is sent one frame at a time. If multiple frames need to be sent, several Information commands are sent. The pd value is the protocol discriminator. The value 8 indicates it is call control information. The call reference number is always null for SPID information.
SPID information i = 0x343135393033383336363031
Indicates the service profile identifier (SPID). The local router sends this information to the ISDN switch to indicate the services to which it subscribes. SPIDs are assigned by the service provider and are usually 10-digit telephone numbers followed by optional numbers. Currently, only the DMS-100 switch supports SPIDs, one for each B channel. If SPID information is sent to a switch type other than DMS-100, an error may be displayed in the debug information.
ns = 0
Indicates the send sequence number of transmitted I frames.
nr = 0
Indicates the expected send sequence number of the next received I frame. At time of transmission, this value should be equal to the value of ns. The value of nr is used to determine whether frames need to be retransmitted for recovery.
RRr
Indicates the Receive Ready response for unacknowledged information transfer. The RRr is a response to an INFOc.
RRp
Indicates the Receive Ready command with the poll bit set. The data link layer entity on the user side uses the poll bit in the frame to solicit a response from the peer on the network side.
RRf
Indicates the Receive Ready response with the final bit set. The data link layer entity on the network side uses the final bit in the frame to indicate a response to the poll.
sapi
Indicates the service access point identifier. The SAPI is the point at which data link services are provided to a network layer or management entity. Currently, this field can have the value 0 (for call control procedure) or 63 (for Layer 2 management procedures).
tei
Indicates the terminal endpoint identifier (TEI) that has been assigned automatically by the assignment source point (ASP) (also called the layer management entity on the network side). The valid range is 64 to 126. The value 127 indicates a broadcast.
debug isdn q931
Use the debug isdn q931 EXEC command to display information about call setup and teardown of ISDN network connections (Layer 3) between the local router (user side) and the network. The no form of this command disables debugging output.
[no] debug isdn q931
Usage Guidelines
The ISDN network layer interface provided by the router conforms to the user interface specification defined by ITU-T recommendation Q.931, supplemented by other specifications such as for switch type VN4. The router tracks only activities that occur on the user side, not the network side, of the network connection. The display information debug isdn q931 command output is limited to commands and responses exchanged during peer-to-peer communication carried over the D channel. This debug information does not include data transmitted over the B channels, which are also part of the router's ISDN interface. The peers (network layers) communicate with each other via an ISDN switch over the D channel.
A router can be the calling or called party of the ISDN Q.931 network connection call setup and tear- down procedures. If the router is the calling party, the command displays information about an outgoing call. If the router is the called party, the command displays information about an incoming call.
You can use the debug isdn q931 command with the debug isdn event and the debug isdn q921 commands at the same time. The displays will be intermingled. Use the service timestamps debug datetime msec global configuration command to include the time with each message.
For more information on ISDN switch types, codes, and values, refer to the "ISDN Switch Types, Codes, and Values" appendix.
Sample Display
shows sample debug isdn q931 output of a call setup procedure for an outgoing call.
Figure 2-131 Sample Debug ISDN Q931 Output—Call Setup Procedure for an Outgoing Call
router# debug isdn q931TX -> SETUP pd = 8 callref = 0x04Bearer Capability i = 0x8890Channel ID i = 0x83Called Party Number i = 0x80, `415555121202'RX <- CALL_PROC pd = 8 callref = 0x84Channel ID i = 0x89RX <- CONNECT pd = 8 callref = 0x84TX -> CONNECT_ACK pd = 8 callref = 0x04....Success rate is 0 percent (0/5)shows sample debug isdn q931 output of a call setup procedure for an incoming call.
Figure 2-132 Sample Debug ISDN Q931 Output—Call Setup Procedure for an Incoming Call
router# debug isdn q931RX <- SETUP pd = 8 callref = 0x06Bearer Capability i = 0x8890Channel ID i = 0x89Calling Party Number i = 0x0083, `81012345678902'TX -> CONNECT pd = 8 callref = 0x86RX <- CONNECT_ACK pd = 8 callref = 0x06shows sample debug isdn q931 output of a call teardown procedure from the network.
Figure 2-133 Sample Debug ISDN Q931 Output—Call Teardown Procedure from the Network
router# debug isdn q931RX <- DISCONNECT pd = 8 callref = 0x84Cause i = 0x8790Looking Shift to Codeset 6Codeset 6 IE 0x1 1 0x82 `10'TX -> RELEASE pd = 8 callref = 0x04Cause i = 0x8090RX <- RELEASE_COMP pd = 8 callref = 0x84shows sample debug isdn q931 output of a call teardown procedure from the router.
Figure 2-134 Sample Debug ISDN Q931 Output—Call Teardown Procedure from the Router
router# debug isdn q931TX -> DISCONNECT pd = 8 callref = 0x05Cause i = 0x879081RX <- RELEASE pd = 8 callref = 0x85Looking Shift to Codeset 6Codeset 6 IE 0x1 1 0x82 `10'TX <- RELEASE_COMP pd = 8 callref = 0x05describes significant fields in through .
Table 2-67 Debug ISDN Q931 Call Setup Procedure Field Descriptions
TX ->
Indicates that this message is being transmitted from the local router (user side) to the network side of the ISDN interface.
RX <-
Indicates that this message is being received by the user side of the ISDN interface from the network side.
SETUP
Indicates that the SETUP message type has been sent to initiate call establishment between peer network layers. This message can be sent from either the local router or the network.
pd
Indicates the protocol discriminator. The protocol discriminator distinguishes messages for call control over the user-network ISDN interface from other ITU-T-defined messages, including other Q.931messages. The protocol discriminator is 8 for call control messages such as SETUP. For basic-1tr6, the protocol discriminator is 65.
callref
Indicates the call reference number in hexadecimal. The value of this field indicates the number of calls made from either the router (outgoing calls) or the network (incoming calls). Note that the originator of the SETUP message sets the high-order bit of the call reference number to 0. The destination of the connection sets the high-order bit to 1 in subsequent call control messages, such as the CONNECT message. For example, callref = 0x04 in the request becomes callref = 0x84 in the response.
Bearer Capability
Indicates the requested bearer service to be provided by the network. Refer to Table B-4 in the "ISDN Switch Types, Codes, and Values" appendix for detailed information about bearer capability values.
i=
Indicates the Information Element Identifier. The value depends on the field it is associated with. Refer to the ITU-T Q.931 specification for details about the possible values associated with each field for which this identifier is relevant.
Channel ID
Indicates the Channel Identifier. The value 83 indicates any channel, 89 indicates the B1 channel, and 8A indicates the B2 channel. For more information about the Channel Identifier, refer to ITU-T Recommendation Q.931.
Called Party Number
Identifies the called party. This field is only present in outgoing SETUP messages. Note that it can be replaced by the Keypad facility field. This field uses the IA5 character set.
Calling Party Number
Identifies the origin of the call. This field is present only in incoming SETUP messages. This field uses the IA5 character set.
CALL_PROC
Indicates the CALL PROCEEDING message; the requested call setup has begun and no more call setup information will be accepted.
CONNECT
Indicates that the called user has accepted the call.
CONNECT_ACK
Indicates that the calling user acknowledges the called user's acceptance of the call.
DISCONNECT
Indicates either that the user side has requested the network to clear an end-to-end connection or that the network has cleared the end-to-end connection.
Cause
Indicates the cause of the disconnect. Refer to Table B-2 and Table B-3 in the "ISDN Switch Types, Codes, and Values" appendix for detailed information about DISCONNECT cause codes and RELEASE cause codes.
Looking Shift to Codeset 6
Indicates that the next information elements will be interpreted according to information element identifiers assigned in codeset 6. Codeset 6 means that the information elements are specific to the local network.
Codeset 6 IE 0x1 i = 0x82, `10'
Indicates charging information. This information is specific to the NTT switch type and may not be sent by other switch types.
RELEASE
Indicates that the sending equipment will release the channel and call reference. The recipient of this message should prepare to release the call reference and channel.
RELEASE_COMP
Indicates that the sending equipment has received a RELEASE message and has now released the call reference and channel.
debug isis adj packets
Use the debug isis adj packets EXEC command to display information on all adjacency-related activity such as hello packets sent and received and IS-IS adjacencies going up and down. The no form of this command disables debugging output.
[no] debug isis adj packets
Sample Display
shows sample debug isis adj packets output.
Figure 2-135 Sample Debug ISIS Adj Packets Output
router# debug isis adj packetsISIS-Adj: Rec L1 IIH from 0000.0c00.40af (Ethernet0), cir type 3, cir idBBBB.BBBB.BBBB.01ISIS-Adj: Rec L2 IIH from 0000.0c00.40af (Ethernet0), cir type 3, cir idBBBB.BBBB.BBBB.01ISIS-Adj: Rec L1 IIH from 0000.0c00.0c36 (Ethernet1), cir type 3, cir idCCCC.CCCC.CCCC.03ISIS-Adj: Area mismatch, level 1 IIH on Ethernet1ISIS-Adj: Sending L1 IIH on Ethernet1ISIS-Adj: Sending L2 IIH on Ethernet1ISIS-Adj: Rec L2 IIH from 0000.0c00.0c36 (Ethernet1), cir type 3, cir idBBBB.BBBB.BBBB.03Explanations for individual lines of output from follow.
The following line indicates that the router received an IS-IS hello packet (IIH) on Ethernet0 from the Level 1 router (L1) at MAC address 0000.0c00.40af. The circuit type is the interface type: 1—Level 1 only; 2—Level 2 only; 3—Level 1/2.
The circuit ID is what the neighbor interprets as the designated router for the interface.
ISIS-Adj: Rec L1 IIH from 0000.0c00.40af (Ethernet0), cir type 3, cir id BBBB.BBBB.BBBB.01The following line indicates that the router (configured as a Level 1 router) received on Ethernet1 an IS-IS hello packet from a Level 1 router in another area, thereby declaring an area mismatch:
ISIS-Adj: Area mismatch, level 1 IIH on Ethernet1The following lines indicates that the router (configured as a Level 1/Level 2 router) sent on Ethernet1 a Level 1 IS-IS hello packet, and then a Level 2 IS-IS packet:
ISIS-Adj: Sending L1 IIH on Ethernet1ISIS-Adj: Sending L2 IIH on Ethernet1debug isis spf statistics
Use the debug isis spf statistics EXEC command to display statistical information about building routes between intermediate systems (ISs). The no form of this command disables debugging output.
[no] debug isis spf statistics
Usage Guidelines
The Intermediate System-to-Intermediate System (IS-IS) Intra-Domain Routing Exchange Protocol (IDRP) provides routing between ISs by flooding the network with link-state information. IS-IS provides routing at two levels, intra-area (Level 1) and intra-domain (Level 2). Level 1 routing allows Level 1 ISs to communicate with other Level 1 ISs in the same area. Level 2 routing allows Level 2 ISs to build an interdomain backbone between Level 1 areas by traversing only Level 2 ISs. Level 1 ISs only need to know the path to the nearest Level 2 IS in order to take advantage of the interdomain backbone created by the Level 2 ISs.
The IS-IS protocol uses the Shortest Path First (SPF) routing algorithm to build Level 1 and Level 2 routes. The debug isis spf statistics command provides information for determining how long it takes to place a Level 1 IS or Level 2 IS on the shortest path tree (SPT) using the IS-IS protocol.
Note
Sample Display
shows sample debug isis spf statistics output.
Figure 2-136 Sample Debug ISIS SPF Statistics Output
router# debug isis spf statisticsISIS-Stats: Compute L1 SPT, Timestamp 2780.328 secondsISIS-Stats: Complete L1 SPT, Compute time 0.004, 1 nodes on SPTISIS-Stats: Compute L2 SPT, Timestamp 2780.3336 secondsISIS-Stats: Complete L2 SPT, Compute time 0.056, 12 nodes on SPTdescribes significant fields shown in .
Explanations for individual lines of output from follow.
The following lines show the statistical information available for Level 1 ISs:
ISIS-Stats: Compute L1 SPT, Timestamp 2780.328 secondsISIS-Stats: Complete L1 SPT, Compute time 0.004, 1 nodes on SPTThe output indicates that the SPF algorithm was applied 2780.328 seconds after the system was up and configured. Given the existing intra-area topology, it took 4 milliseconds to place one Level 1 IS on the SPT.
The following lines show the statistical information available for Level 2 ISs:
ISIS-Stats: Compute L2 SPT, Timestamp 2780.3336 secondsISIS-Stats: Complete L2 SPT, Compute time 0.056, 12 nodes on SPTThis output indicates that the SPF algorithm was applied 2780.3336 seconds after the system was up and configured. Given the existing intra-domain topology, it took 56 milliseconds to place 12 Level 2 ISs on the SPT.
debug isis update-packets
Use the debug isis update-packets EXEC command to display various sequence number protocol data units (PDUs) and link state packets that are detected by a router. This router has been configured for IS-IS routing. The no form of this command disables debugging output.
[no] debug isis update-packets
Sample Display
shows sample debug isis update-packets output.
Figure 2-137 Sample Debug ISIS Update-Packets Output
router# debug isis update-packetsISIS-Update: Sending L1 CSNP on Ethernet0ISIS-Update: Sending L2 CSNP on Ethernet0ISIS-Update: Updating L2 LSPISIS-Update: Delete link 888.8800.0181.00 from L2 LSP 1600.8906.4022.00-00, seq EISIS-Update: Updating L1 LSPISIS-Update: Sending L1 CSNP on Ethernet0ISIS-Update: Sending L2 CSNP on Ethernet0ISIS-Update: Add link 8888.8800.0181.00 to L2 LSP 1600.8906.4022.00-00, new seq 10,len 91ISIS-Update: Sending L2 LSP 1600.8906.4022.00-00, seq 10, ht 1198 on Tunnel0ISIS-Update: Sending L2 CSNP on Tunnel0ISIS-Update: Updating L2 LSPISIS-Update: Rate limiting L2 LSP 1600.8906.4022.00-00, seq 11 (Tunnel0)ISIS-Update: Updating L1 LSPISIS-Update: Rec L2 LSP 888.8800.0181.00.00-00 (Tunnel0)ISIS-Update: PSNP entry 1600.8906.4022.00-00, seq 10, ht 1196Explanations for individual lines of output from follow.
The following lines indicate that the router has sent a periodic Level 1 and Level 2 complete sequence number PDU on Ethernet 0:
ISIS-Update: Sending L1 CSNP on Ethernet0ISIS-Update: Sending L2 CSNP on Ethernet0The following lines indicate that the network service access point (NSAP) identified as 8888.8800.0181.00 was deleted from the Level 2 LSP 1600.8906.4022.00-00. The sequence number associated with this LSP is 0xE.
ISIS-Update: Updating L2 LSPISIS-Update: Delete link 888.8800.0181.00 from L2 LSP 1600.8906.4022.00-00, seq EThe following lines indicate that the NSAP identified as 8888.8800.0181.00 was added to the Level 2 LSP 1600.8906.4022.00-00. The new sequence number associated with this LSP is 0x10.
ISIS-Update: Updating L1 LSPISIS-Update: Sending L1 CSNP on Ethernet0ISIS-Update: Sending L2 CSNP on Ethernet0ISIS-Update: Add link 8888.8800.0181.00 to L2 LSP 1600.8906.4022.00-00, new seq 10,len 91The following line indicates that the router sent Level 2 LSP 1600.8906.4022.00-00 with sequence number 0x10 on Tunnel0:
ISIS-Update: Sending L2 LSP 1600.8906.4022.00-00, seq 10, ht 1198 on Tunnel0The following lines indicates that a Level 2 LSP could not be transmitted because it was recently transmitted:
ISIS-Update: Sending L2 CSNP on Tunnel0ISIS-Update: Updating L2 LSPISIS-Update: Rate limiting L2 LSP 1600.8906.4022.00-00, seq 11 (Tunnel0)The following lines indicate that a Level 2 partial sequence number PDU (PSNP) has been received on Tunnel0:
ISIS-Update: Updating L1 LSPISIS-Update: Rec L2 PSNP from 8888.8800.0181.00 (Tunnel0)The following line indicates that a Level 2 PSNP with an entry for Level 2 LSP 1600.8906.4022.00-00 has been received. This output is an acknowledgment that a previously sent LSP was received without an error.
ISIS-Update: PSNP entry 1600.8906.4022.00-00, seq 10, ht 1196debug kerberos
Use the debug kerberos EXEC command to display information associated with the Kerberos Authentication Subsystem. The no form of this command disables debugging output.
[no] debug kerberos
Usage Guidelines
Kerberos is a security system that authenticates users and services without passing a cleartext password over the network. Cisco supports Kerberos under the Authentication, Authorization, and Accounting (AAA) security system.
Use the debug aaa authentication command to get a high-level view of login activity. When Kerberos is used on the router, you can use the debug kerberos command for more detailed debugging information.
Note
Sample Display
shows part of the debug aaa authentication command output for a Kerberos login attempt that failed. The information indicates that Kerberos is the authentication method used.
Figure 2-138 Sample Debug AAA Authentication Output—Kerberos Login Attempt
AAA/AUTHEN/START (116852612): Method=KRB5AAA/AUTHEN (116852612): status = GETUSERAAA/AUTHEN/CONT (116852612): continue_loginAAA/AUTHEN (116852612): status = GETUSERAAA/AUTHEN (116852612): Method=KRB5AAA/AUTHEN (116852612): status = GETPASSAAA/AUTHEN/CONT (116852612): continue_loginAAA/AUTHEN (116852612): status = GETPASSAAA/AUTHEN (116852612): Method=KRB5AAA/AUTHEN (116852612): password incorrectAAA/AUTHEN (116852612): status = FAILshows part of the debug kerberos command output for a login attempt that was successful. The information indicates that the router sent a request to the KDC and received a valid credential.
Figure 2-139 Sample Debug Kerberos Output—Successful Login
Kerberos: Requesting TGT with expiration date of 820911631Kerberos: Sent TGT request to KDCKerberos: Received TGT reply from KDCKerberos: Received valid credential with endtime of 820911631shows part of the debug kerberos command output for a login attempt that failed. The information indicates that the router sent a request to the KDC and received a reply, but the reply did not contain a valid credential.
Figure 2-140 Sample Debug Kerberos Output—Failed Login
Kerberos: Requesting TGT with expiration date of 820911731Kerberos: Sent TGT request to KDCKerberos: Received TGT reply from KDCKerberos: Received invalid credential.AAA/AUTHEN (425003829): password incorrectshows other failure messages you might see that indicate a configuration problem. The first message indicates the router failed to find the default Kerberos realm, therefore the process failed to build a message to send to the KDC. The second message indicates the router failed to retrieve its own IP address. The third message indicates the router failed to retrieve the current time. The fourth message indicates the router failed to find or create a credentials cache for a user, which is usually caused by low memory availability.
Figure 2-141 Sample Debug Kerberos Output—Miscellaneous Messages
Kerberos: authentication failed when parsing nameKerberos: authentication failed while getting my addressKerberos: authentication failed while getting time of dayKerberos: authentication failed while allocating credentials cacheRelated Commands
debug lane client
Use the debug lane client EXEC command to display information about a LAN Emulation Client (LEC). The no form of this command disables debugging output.
[no] debug lane client {all | le-arp | packet | signaling | state | topology}
Syntax Description
Usage Guidelines
The debug lane client all command can generate a large amount of output. Use a limiting keyword to decrease the amount of output and focus on the information you need.
Sample Displays
shows sample output for debug lane client packet and debug lane client state commands for an LEC joining an emulated LAN (ELAN) called elan1.
Figure 2-142 Sample Debug LANE Client Output—Client Joining ELAN
Router# debug lane client packetRouter# debug lane client stateThe LEC listens for signaling calls to its ATM address. (Initial State)
LEC ATM2/0.1: sending LISTENLEC ATM2/0.1: listen on 39.020304050607080910111213.00000CA05B40.01LEC ATM2/0.1: received LISTENThe LEC calls the LAN Emulation Configuration Server (LECS) and attempts to set up the Configure Direct VC. (LECS Connect Phase)
LEC ATM2/0.1: sending SETUPLEC ATM2/0.1: callid 0x6114D174LEC ATM2/0.1: called party 39.020304050607080910111213.00000CA05B43.00LEC ATM2/0.1: calling_party 39.020304050607080910111213.00000CA05B40.01The LEC receives a CONNECT response from the LECS. The Configure Direct VC is established.
LEC ATM2/0.1: received CONNECTLEC ATM2/0.1: callid 0x6114D174LEC ATM2/0.1: vcd 148The LEC sends a CONFIG REQUEST to the LECS on the Configure Direct VC. (Configuration Phase)
LEC ATM2/0.1: sending LANE_CONFIG_REQ on VCD 148LEC ATM2/0.1: SRC MAC address 0000.0ca0.5b40LEC ATM2/0.1: SRC ATM address 39.020304050607080910111213.00000CA05B40.01LEC ATM2/0.1: LAN Type 2LEC ATM2/0.1: Frame size 2LEC ATM2/0.1: LAN Name elan1LEC ATM2/0.1: LAN Name size 5The LEC receives a CONFIG RESPONSE from the LECS on the Configure Direct VC.
LEC ATM2/0.1: received LANE_CONFIG_RSP on VCD 148LEC ATM2/0.1: SRC MAC address 0000.0ca0.5b40LEC ATM2/0.1: SRC ATM address 39.020304050607080910111213.00000CA05B40.01LEC ATM2/0.1: LAN Type 2LEC ATM2/0.1: Frame size 2LEC ATM2/0.1: LAN Name elan1LEC ATM2/0.1: LAN Name size 5The LEC releases the Configure Direct VC.
LEC ATM2/0.1: sending RELEASELEC ATM2/0.1: callid 0x6114D174LEC ATM2/0.1: cause code 31The LEC receives a RELEASE_COMPLETE from the LECS.
LEC ATM2/0.1: received RELEASE_COMPLETELEC ATM2/0.1: callid 0x6114D174LEC ATM2/0.1: cause code 16The LEC calls the LAN Emulation Server (LES) and attempts to set up the Control Direct VC. (Join/Registration Phase)
LEC ATM2/0.1: sending SETUPLEC ATM2/0.1: callid 0x61167110LEC ATM2/0.1: called party 39.020304050607080910111213.00000CA05B41.01LEC ATM2/0.1: calling_party 39.020304050607080910111213.00000CA05B40.01The LEC receives a CONNECT response from the LES. The Control Direct VC is established.
LEC ATM2/0.1: received CONNECTLEC ATM2/0.1: callid 0x61167110LEC ATM2/0.1: vcd 150The LEC sends a JOIN REQUEST to the LES on the Control Direct VC.
LEC ATM2/0.1: sending LANE_JOIN_REQ on VCD 150LEC ATM2/0.1: Status 0LEC ATM2/0.1: LECID 0LEC ATM2/0.1: SRC MAC address 0000.0ca0.5b40LEC ATM2/0.1: SRC ATM address 39.020304050607080910111213.00000CA05B40.01LEC ATM2/0.1: LAN Type 2LEC ATM2/0.1: Frame size 2LEC ATM2/0.1: LAN Name elan1LEC ATM2/0.1: LAN Name size 5The LEC receives a SETUP request from the LES to set up the Control Distribute VC.
LEC ATM2/0.1: received SETUPLEC ATM2/0.1: callid 0x6114D174LEC ATM2/0.1: called party 39.020304050607080910111213.00000CA05B40.01LEC ATM2/0.1: calling_party 39.020304050607080910111213.00000CA05B41.01The LEC responds to the LES call setup with a CONNECT.
LEC ATM2/0.1: sending CONNECTLEC ATM2/0.1: callid 0x6114D174LEC ATM2/0.1: vcd 151A CONNECT_ACK is received from the ATM switch. The Control Distribute VC is established.
LEC ATM2/0.1: received CONNECT_ACKThe LEC receives a JOIN response from the LES on the Control Direct VC.
LEC ATM2/0.1: received LANE_JOIN_RSP on VCD 150LEC ATM2/0.1: Status 0LEC ATM2/0.1: LECID 1LEC ATM2/0.1: SRC MAC address 0000.0ca0.5b40LEC ATM2/0.1: SRC ATM address 39.020304050607080910111213.00000CA05B40.01LEC ATM2/0.1: LAN Type 2LEC ATM2/0.1: Frame size 2LEC ATM2/0.1: LAN Name elan1LEC ATM2/0.1: LAN Name size 5The LEC sends an LE_ARP request to the LES to obtain the broadcast-and-unknown (BUS) ATM NSAP address. (BUS Connect)
LEC ATM2/0.1: sending LANE_ARP_REQ on VCD 150LEC ATM2/0.1: SRC MAC address 0000.0ca0.5b40LEC ATM2/0.1: SRC ATM address 39.020304050607080910111213.00000CA05B40.01LEC ATM2/0.1: TARGET MAC address ffff.ffff.ffffLEC ATM2/0.1: TARGET ATM address 00.000000000000000000000000.000000000000.00The LEC receives its own LE_ARP request via the LES over the Control Distribute VC.
LEC ATM2/0.1: received LANE_ARP_RSP on VCD 151LEC ATM2/0.1: SRC MAC address 0000.0ca0.5b40LEC ATM2/0.1: SRC ATM address 39.020304050607080910111213.00000CA05B40.01LEC ATM2/0.1: TARGET MAC address ffff.ffff.ffffLEC ATM2/0.1: TARGET ATM address 39.020304050607080910111213.00000CA05B42.01The LEC calls the BUS and attempts to setup the Multicast Send VC.
LEC ATM2/0.1: sending SETUPLEC ATM2/0.1: callid 0x6114D354LEC ATM2/0.1: called party 39.020304050607080910111213.00000CA05B42.01LEC ATM2/0.1: calling_party 39.020304050607080910111213.00000CA05B40.01The LEC receives a CONNECT response from the BUS. The Multicast Send VC is established.
LEC ATM2/0.1: received CONNECTLEC ATM2/0.1: callid 0x6114D354LEC ATM2/0.1: vcd 153The LEC receives a SETUP request from the BUS to set up the Multicast Forward VC.
LEC ATM2/0.1: received SETUPLEC ATM2/0.1: callid 0x610D4230LEC ATM2/0.1: called party 39.020304050607080910111213.00000CA05B40.01LEC ATM2/0.1: calling_party 39.020304050607080910111213.00000CA05B42.01The LEC responds to the BUS call setup with a CONNECT.
LEC ATM2/0.1: sending CONNECTLEC ATM2/0.1: callid 0x610D4230LEC ATM2/0.1: vcd 154A CONNECT_ACK is received from the ATM switch. The Multicast Forward VC is established.
LEC ATM2/0.1: received CONNECT_ACKThe LEC moves into the OPERATIONAL state.
%LANE-5-UPDOWN: ATM2/0.1 elan elan1: LE Client changed state to upThe following output is the from show lane client command after the LEC joins the emulated LAN as shown in the debug lane client output:
Router# show lane clientLE Client ATM2/0.1 ELAN name: elan1 Admin: up State: operationalClient ID: 1 LEC up for 1 minute 2 secondsJoin Attempt: 1HW Address: 0000.0ca0.5b40 Type: token ring Max Frame Size: 4544Ring:1 Bridge:1 ELAN Segment ID: 2048ATM Address: 39.020304050607080910111213.00000CA05B40.01VCD rxFrames txFrames Type ATM Address0 0 0 configure 39.020304050607080910111213.00000CA05B43.00142 1 2 direct 39.020304050607080910111213.00000CA05B41.01143 1 0 distribute 39.020304050607080910111213.00000CA05B41.01145 0 0 send 39.020304050607080910111213.00000CA05B42.01146 1 0 forward 39.020304050607080910111213.00000CA05B42.01shows sample debug lane client all output when an interface with an LECS, an LES/BUS, and an LEC is shut down.
Figure 2-143 Sample Debug LANE Client Output—Interface Shutdown
Router# debug lane client allLEC ATM1/0.2: received RELEASE_COMPLETELEC ATM1/0.2: callid 0x60E8B474LEC ATM1/0.2: cause code 0LEC ATM1/0.2: action A_PROCESS_REL_COMPLEC ATM1/0.2: action A_TEARDOWN_LECLEC ATM1/0.2: sending RELEASELEC ATM1/0.2: callid 0x60EB6160LEC ATM1/0.2: cause code 31LEC ATM1/0.2: sending RELEASELEC ATM1/0.2: callid 0x60EB7548LEC ATM1/0.2: cause code 31LEC ATM1/0.2: sending RELEASELEC ATM1/0.2: callid 0x60EB9E48LEC ATM1/0.2: cause code 31LEC ATM1/0.2: sending CANCELLEC ATM1/0.2: ATM address 47.00918100000000613E5A2F01.006070174820.02LEC ATM1/0.2: state ACTIVE event LEC_SIG_RELEASE_COMP => TERMINATINGLEC ATM1/0.3: received RELEASE_COMPLETELEC ATM1/0.3: callid 0x60E8D108LEC ATM1/0.3: cause code 0LEC ATM1/0.3: action A_PROCESS_REL_COMPLEC ATM1/0.3: action A_TEARDOWN_LECLEC ATM1/0.3: sending RELEASELEC ATM1/0.3: callid 0x60EB66D4LEC ATM1/0.3: cause code 31LEC ATM1/0.3: sending RELEASELEC ATM1/0.3: callid 0x60EB7B8CLEC ATM1/0.3: cause code 31LEC ATM1/0.3: sending RELEASELEC ATM1/0.3: callid 0x60EBA3BCLEC ATM1/0.3: cause code 31LEC ATM1/0.3: sending CANCELLEC ATM1/0.3: ATM address 47.00918100000000613E5A2F01.006070174820.03LEC ATM1/0.3: state ACTIVE event LEC_SIG_RELEASE_COMP => TERMINATINGLEC ATM1/0.2: received RELEASE_COMPLETELEC ATM1/0.2: callid 0x60EB7548LEC ATM1/0.2: cause code 0LEC ATM1/0.2: action A_PROCESS_TERM_REL_COMPLEC ATM1/0.2: state TERMINATING event LEC_SIG_RELEASE_COMP => TERMINATINGLEC ATM1/0.3: received RELEASE_COMPLETELEC ATM1/0.3: callid 0x60EB7B8CLEC ATM1/0.3: cause code 0LEC ATM1/0.3: action A_PROCESS_TERM_REL_COMPLEC ATM1/0.3: state TERMINATING event LEC_SIG_RELEASE_COMP => TERMINATINGLEC ATM1/0.1: received RELEASE_COMPLETELEC ATM1/0.1: callid 0x60EBC458LEC ATM1/0.1: cause code 0LEC ATM1/0.1: action A_PROCESS_REL_COMPLEC ATM1/0.1: action A_TEARDOWN_LECLEC ATM1/0.1: sending RELEASELEC ATM1/0.1: callid 0x60EBD30CLEC ATM1/0.1: cause code 31LEC ATM1/0.1: sending RELEASELEC ATM1/0.1: callid 0x60EBDD28LEC ATM1/0.1: cause code 31LEC ATM1/0.1: sending RELEASELEC ATM1/0.1: callid 0x60EBF174LEC ATM1/0.1: cause code 31LEC ATM1/0.1: sending CANCELLEC ATM1/0.1: ATM address 47.00918100000000613E5A2F01.006070174820.01LEC ATM1/0.1: state ACTIVE event LEC_SIG_RELEASE_COMP => TERMINATINGLEC ATM1/0.1: received RELEASE_COMPLETELEC ATM1/0.1: callid 0x60EBDD28LEC ATM1/0.1: cause code 0LEC ATM1/0.1: action A_PROCESS_TERM_REL_COMPLEC ATM1/0.1: state TERMINATING event LEC_SIG_RELEASE_COMP => TERMINATINGLEC ATM1/0.2: received RELEASE_COMPLETELEC ATM1/0.2: callid 0x60EB6160LEC ATM1/0.2: cause code 0LEC ATM1/0.2: action A_PROCESS_TERM_REL_COMPLEC ATM1/0.2: state TERMINATING event LEC_SIG_RELEASE_COMP => TERMINATINGLEC ATM1/0.3: received RELEASE_COMPLETELEC ATM1/0.3: callid 0x60EB66D4LEC ATM1/0.3: cause code 0LEC ATM1/0.3: action A_PROCESS_TERM_REL_COMPLEC ATM1/0.3: state TERMINATING event LEC_SIG_RELEASE_COMP => TERMINATINGLEC ATM1/0.2: received RELEASE_COMPLETELEC ATM1/0.2: callid 0x60EB9E48LEC ATM1/0.2: cause code 0LEC ATM1/0.2: action A_PROCESS_TERM_REL_COMPLEC ATM1/0.2: state TERMINATING event LEC_SIG_RELEASE_COMP => IDLELEC ATM1/0.3: received RELEASE_COMPLETELEC ATM1/0.3: callid 0x60EBA3BCLEC ATM1/0.3: cause code 0LEC ATM1/0.3: action A_PROCESS_TERM_REL_COMPLEC ATM1/0.3: state TERMINATING event LEC_SIG_RELEASE_COMP => IDLELEC ATM1/0.1: received RELEASE_COMPLETELEC ATM1/0.1: callid 0x60EBD30CLEC ATM1/0.1: cause code 0LEC ATM1/0.1: action A_PROCESS_TERM_REL_COMPLEC ATM1/0.1: state TERMINATING event LEC_SIG_RELEASE_COMP => TERMINATINGLEC ATM1/0.1: received RELEASE_COMPLETELEC ATM1/0.1: callid 0x60EBF174LEC ATM1/0.1: cause code 0LEC ATM1/0.1: action A_PROCESS_TERM_REL_COMPLEC ATM1/0.1: state TERMINATING event LEC_SIG_RELEASE_COMP => IDLELEC ATM1/0.2: received CANCELLEC ATM1/0.2: state IDLE event LEC_SIG_CANCEL => IDLELEC ATM1/0.3: received CANCELLEC ATM1/0.3: state IDLE event LEC_SIG_CANCEL => IDLELEC ATM1/0.1: received CANCELLEC ATM1/0.1: state IDLE event LEC_SIG_CANCEL => IDLELEC ATM1/0.1: action A_SHUTDOWN_LECLEC ATM1/0.1: sending CANCELLEC ATM1/0.1: ATM address 47.00918100000000613E5A2F01.006070174820.01LEC ATM1/0.1: state IDLE event LEC_LOCAL_DEACTIVATE => IDLELEC ATM1/0.2: action A_SHUTDOWN_LECLEC ATM1/0.2: sending CANCELLEC ATM1/0.2: ATM address 47.00918100000000613E5A2F01.006070174820.02LEC ATM1/0.2: state IDLE event LEC_LOCAL_DEACTIVATE => IDLELEC ATM1/0.3: action A_SHUTDOWN_LECLEC ATM1/0.3: sending CANCELLEC ATM1/0.3: ATM address 47.00918100000000613E5A2F01.006070174820.03LEC ATM1/0.3: state IDLE event LEC_LOCAL_DEACTIVATE => IDLEdebug lane config
Use the debug lane config EXEC command to display information about a LANE configuration server. The no form of this command disables debugging output.
[no] debug lane config {all | events | packets}
Syntax Description
Usage Guidelines
The debug lane config output is intended to be used primarily by a Cisco technical support representative.
Sample Display
shows sample debug lane config all output when an interface with an LECS, an LES/BUS, and an LEC is shut down.
Figure 2-144 Sample Debug LANE Config All Output
router# debug lane config allLECS EVENT ATM1/0: processing interface down transitionLECS EVENT ATM1/0: placed de-register address 0x60E8A824 (47.00918100000000613E5A2F01.006070174823.00) request with signallingLECS EVENT ATM1/0: ilmiDeRegisterAddress: sendSetRequestToILMI failure; interface down ?LECS EVENT ATM1/0: placed de-register address 0x60EC4F28 (47.007900000000000000000000.00A03E000001.00) request with signallingLECS EVENT ATM1/0: ilmiDeRegisterAddress: sendSetRequestToILMI failure; interface down ?LECS EVENT ATM1/0: placed de-register address 0x60EC5C08 (47.00918100000000613E5A2F01.006070174823.99) request with signallingLECS EVENT ATM1/0: ilmiDeRegisterAddress: sendSetRequestToILMI failure; interface down ?LECS EVENT ATM1/0: tearing down all connexionsLECS EVENT ATM1/0: elan 'xxx' LES 47.00918100000000613E5A2F01.006070174821.01 callId 0x60CE0F58 deliberately being disconnectedLECS EVENT ATM1/0: sending RELEASE for call 0x60CE0F58 cause 31LECS EVENT ATM1/0: elan 'yyy' LES 47.00918100000000613E5A2F01.006070174821.02 callId 0x60CE2104 deliberately being disconnectedLECS EVENT ATM1/0: sending RELEASE for call 0x60CE2104 cause 31LECS EVENT ATM1/0: elan 'zzz' LES 47.00918100000000613E5A2F01.006070174821.03 callId 0x60CE2DC8 deliberately being disconnectedLECS EVENT ATM1/0: sending RELEASE for call 0x60CE2DC8 cause 31LECS EVENT ATM1/0: All calls to/from LECSs are being releasedLECS EVENT ATM1/0: placed de-register address 0x60EC4F28 (47.007900000000000000000000.00A03E000001.00) request with signallingLECS EVENT ATM1/0: ilmiDeRegisterAddress: sendSetRequestToILMI failure; interface down ?LECS EVENT ATM1/0: ATM_RELEASE_COMPLETE received: callId 0x60CE0F58 cause 0LECS EVENT ATM1/0: call 0x60CE0F58 cleaned upLECS EVENT ATM1/0: ATM_RELEASE_COMPLETE received: callId 0x60CE2104 cause 0LECS EVENT ATM1/0: call 0x60CE2104 cleaned upLECS EVENT ATM1/0: ATM_RELEASE_COMPLETE received: callId 0x60CE2DC8 cause 0LECS EVENT ATM1/0: call 0x60CE2DC8 cleaned upLECS EVENT ATM1/0: UNKNOWN/UNSET: signalling DE-registeredLECS EVENT: UNKNOWN/UNSET: signalling DE-registeredLECS EVENT ATM1/0: UNKNOWN/UNSET: signalling DE-registeredLECS EVENT ATM1/0: placed de-register address 0x60E8A824 (47.00918100000000613E5A2F01.006070174823.00) request with signallingLECS EVENT ATM1/0: ilmiDeRegisterAddress: sendSetRequestToILMI failure; interface down ?LECS EVENT ATM1/0: placed de-register address 0x60EC5C08 (47.00918100000000613E5A2F01.006070174823.99) request with signallingLECS EVENT ATM1/0: ilmiDeRegisterAddress: sendSetRequestToILMI failure; interface down ?LECS EVENT ATM1/0: tearing down all connexionsLECS EVENT ATM1/0: All calls to/from LECSs are being releasedLECS EVENT: config server 56 killeddebug lane finder
Use the debug lane finder EXEC command to display information about the finder internal state machine. The no form of this command disables debugging output.
[no] debug lane finder
Usage Guidelines
The debug lane finder output is intended to be used primarily by a Cisco technical support representative.
Sample Display
shows sample debug lane finder output when an interface with an LECS, an LES/BUS, and an LEC is shut down.
Figure 2-145 Sample Debug LANE Finder Output
router# debug lane finderLECS FINDER ATM1/0.3: user request 1819 of type GET_MASTER_LECS_ADDRESS queued upLECS FINDER ATM1/0: finder state machine startedLECS FINDER ATM1/0: time to perform a getNext on the ILMILECS FINDER ATM1/0: LECS 47.00918100000000613E5A2F01.006070174823.00 deletedLECS FINDER ATM1/0: ilmi_client_request failed, answering all usersLECS FINDER ATM1/0: answering all requests nowLECS FINDER ATM1/0: responded to user request 1819LECS FINDER ATM1/0: number of remaining requests still to be processed: 0LECS FINDER ATM1/0.2: user request 1820 of type GET_MASTER_LECS_ADDRESS queued upLECS FINDER ATM1/0: finder state machine startedLECS FINDER ATM1/0: time to perform a getNext on the ILMILECS FINDER ATM1/0: ilmi_client_request failed, answering all usersLECS FINDER ATM1/0: answering all requests nowLECS FINDER ATM1/0: responded to user request 1820LECS FINDER ATM1/0: number of remaining requests still to be processed: 0LECS FINDER ATM1/0.1: user request 1821 of type GET_MASTER_LECS_ADDRESS queued upLECS FINDER ATM1/0: finder state machine startedLECS FINDER ATM1/0: time to perform a getNext on the ILMILECS FINDER ATM1/0: ilmi_client_request failed, answering all usersLECS FINDER ATM1/0: answering all requests nowLECS FINDER ATM1/0: responded to user request 1821LECS FINDER ATM1/0: number of remaining requests still to be processed: 0debug lane server
Use the debug lane server EXEC command to display information about a LANE server. The no form of this command disables debugging output.
[no] debug lane server
Usage Guidelines
The debug lane server output is intended to be used primarily by a Cisco technical support representative.
Note
Sample Display
shows sample debug lane server output when an interface with an LECS, an LES/BUS, and an LEC is shut down.
Figure 2-146 Sample Debug LANE Server Output
Router# debug lane serverLES ATM1/0.1: lsv_lecsAccessSigCB called with callId 0x60CE124C, opcode ATM_RELEASE_COMPLETELES ATM1/0.1: disconnected from the master LECSLES ATM1/0.1: should have been connected, will reconnect in 3 secondsLES ATM1/0.2: lsv_lecsAccessSigCB called with callId 0x60CE29E0, opcode ATM_RELEASE_COMPLETELES ATM1/0.2: disconnected from the master LECSLES ATM1/0.2: should have been connected, will reconnect in 3 secondsLES ATM1/0.3: lsv_lecsAccessSigCB called with callId 0x60EB1940, opcode ATM_RELEASE_COMPLETELES ATM1/0.3: disconnected from the master LECSLES ATM1/0.3: should have been connected, will reconnect in 3 secondsLES ATM1/0.2: elan yyy client 1 lost control distributeLES ATM1/0.2: elan yyy client 1: lsv_kill_client calledLES ATM1/0.2: elan yyy client 1 state change Oper -> TermLES ATM1/0.3: elan zzz client 1 lost control distributeLES ATM1/0.3: elan zzz client 1: lsv_kill_client calledLES ATM1/0.3: elan zzz client 1 state change Oper -> TermLES ATM1/0.2: elan yyy client 1 lost MC forwardLES ATM1/0.2: elan yyy client 1: lsv_kill_client calledLES ATM1/0.3: elan zzz client 1 lost MC forwardLES ATM1/0.3: elan zzz client 1: lsv_kill_client calledLES ATM1/0.1: elan xxx client 1 lost control distributeLES ATM1/0.1: elan xxx client 1: lsv_kill_client calledLES ATM1/0.1: elan xxx client 1 state change Oper -> TermLES ATM1/0.1: elan xxx client 1 lost MC forwardLES ATM1/0.1: elan xxx client 1: lsv_kill_client calledLES ATM1/0.2: elan yyy client 1 released control directLES ATM1/0.2: elan yyy client 1: lsv_kill_client calledLES ATM1/0.3: elan zzz client 1 released control directLES ATM1/0.3: elan zzz client 1: lsv_kill_client calledLES ATM1/0.2: elan yyy client 1 MC forward releasedLES ATM1/0.2: elan yyy client 1: lsv_kill_client calledLES ATM1/0.2: elan yyy client 1: freeing client structuresLES ATM1/0.2: elan yyy client 1 unregistered 0060.7017.4820LES ATM1/0.2: elan yyy client 1 destroyedLES ATM1/0.3: elan zzz client 1 MC forward releasedLES ATM1/0.3: elan zzz client 1: lsv_kill_client calledLES ATM1/0.3: elan zzz client 1: freeing client structuresLES ATM1/0.3: elan zzz client 1 unregistered 0060.7017.4820LES ATM1/0.3: elan zzz client 1 destroyedLES ATM1/0.1: elan xxx client 1 released control directLES ATM1/0.1: elan xxx client 1: lsv_kill_client calledLES ATM1/0.1: elan xxx client 1 MC forward releasedLES ATM1/0.1: elan xxx client 1: lsv_kill_client calledLES ATM1/0.1: elan xxx client 1: freeing client structuresLES ATM1/0.1: elan xxx client 1 unregistered 0060.7017.4820LES ATM1/0.1: elan xxx client 1 destroyedLES ATM1/0.1: elan xxx major interface state changeLES ATM1/0.1: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.1: shutting downLES ATM1/0.1: elan xxx: lsv_kill_lesbus calledLES ATM1/0.1: elan xxx: LES/BUS state change operational -> terminatingLES ATM1/0.1: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.2: elan yyy major interface state changeLES ATM1/0.2: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.2: shutting downLES ATM1/0.2: elan yyy: lsv_kill_lesbus calledLES ATM1/0.2: elan yyy: LES/BUS state change operational -> terminatingLES ATM1/0.2: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.3: elan zzz major interface state changeLES ATM1/0.3: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.3: shutting downLES ATM1/0.3: elan zzz: lsv_kill_lesbus calledLES ATM1/0.3: elan zzz: LES/BUS state change operational -> terminatingLES ATM1/0.3: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.1: elan xxx: lsv_kill_lesbus calledLES ATM1/0.1: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.1: elan xxx: lsv_kill_lesbus calledLES ATM1/0.1: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.1: elan xxx: stopped listening on addressesLES ATM1/0.1: elan xxx: all clients killedLES ATM1/0.1: elan xxx: multicast groups killedLES ATM1/0.1: elan xxx: addresses de-registered from ilmiLES ATM1/0.1: elan xxx: LES/BUS state change terminating -> downLES ATM1/0.1: elan xxx: administratively downLES ATM1/0.2: elan yyy: lsv_kill_lesbus calledLES ATM1/0.2: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.2: elan yyy: lsv_kill_lesbus calledLES ATM1/0.2: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.2: elan yyy: stopped listening on addressesLES ATM1/0.2: elan yyy: all clients killedLES ATM1/0.2: elan yyy: multicast groups killedLES ATM1/0.2: elan yyy: addresses de-registered from ilmiLES ATM1/0.2: elan yyy: LES/BUS state change terminating -> downLES ATM1/0.2: elan yyy: administratively downLES ATM1/0.3: elan zzz: lsv_kill_lesbus calledLES ATM1/0.3: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.3: elan zzz: lsv_kill_lesbus calledLES ATM1/0.3: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.3: elan zzz: stopped listening on addressesLES ATM1/0.3: elan zzz: all clients killedLES ATM1/0.3: elan zzz: multicast groups killedLES ATM1/0.3: elan zzz: addresses de-registered from ilmiLES ATM1/0.3: elan zzz: LES/BUS state change terminating -> downLES ATM1/0.3: elan zzz: administratively downLES ATM1/0.3: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.2: cleanupLecsAccess: discarding all validation requestsLES ATM1/0.1: cleanupLecsAccess: discarding all validation requestsdebug lane signaling
Use the debug lane signaling EXEC command to display information about LANE Server and BUS switched virtual circuits (SVCs). The no form of this command disables debugging output.
[no] debug lane signaling
Usage Guidelines
The debug lane signaling output is intended to be used primarily by a Cisco technical support representative.
Note
Sample Display
shows sample debug lane signaling output when an interface with an LECS, an LES/BUS, and an LEC is shut down.
Figure 2-147 Sample Debug LANE Signaling Output
Router# debug lane signalingLANE SIG ATM1/0.2: received ATM_RELEASE_COMPLETE callid 0x60EB565C cause 0 lv 0x60E8D348 lvstate LANE_VCC_CONNECTEDLANE SIG ATM1/0.2: lane_sig_mc_release: breaking lv 0x60E8D348 from mcg 0x60E97E84LANE SIG ATM1/0.2: timer for lv 0x60E8D348 stoppedLANE SIG ATM1/0.2: sent ATM_RELEASE request for lv 0x60E8D468 in state LANE_VCC_CONNECTEDLANE SIG ATM1/0.2: sent ATM_RELEASE request for lv 0x60E8D3D8 in state LANE_VCC_CONNECTEDLANE SIG ATM1/0.2: sent ATM_RELEASE request for lv 0x60E8D2B8 in state LANE_VCC_CONNECTEDLANE SIG ATM1/0.3: received ATM_RELEASE_COMPLETE callid 0x60EB5CA0 cause 0 lv 0x60E8BEF4 lvstate LANE_VCC_CONNECTEDLANE SIG ATM1/0.3: lane_sig_mc_release: breaking lv 0x60E8BEF4 from mcg 0x60E9A37CLANE SIG ATM1/0.3: timer for lv 0x60E8BEF4 stoppedLANE SIG ATM1/0.3: sent ATM_RELEASE request for lv 0x60E8C014 in state LANE_VCC_CONNECTEDLANE SIG ATM1/0.3: sent ATM_RELEASE request for lv 0x60E8BF84 in state LANE_VCC_CONNECTEDLANE SIG ATM1/0.3: sent ATM_RELEASE request for lv 0x60E8BE64 in state LANE_VCC_CONNECTEDLANE SIG ATM1/0.2: received ATM_RELEASE_COMPLETE callid 0x60EB9040 cause 0 lv 0x60E8D468 lvstate LANE_VCC_DROP_SENTLANE SIG ATM1/0.2: lane_sig_mc_release: breaking lv 0x60E8D468 from mcg 0x60E97EC8LANE SIG ATM1/0.2: timer for lv 0x60E8D468 stoppedLANE SIG ATM1/0.3: received ATM_RELEASE_COMPLETE callid 0x60EB97D4 cause 0 lv 0x60E8C014 lvstate LANE_VCC_DROP_SENTLANE SIG ATM1/0.3: lane_sig_mc_release: breaking lv 0x60E8C014 from mcg 0x60E9A3C0LANE SIG ATM1/0.3: timer for lv 0x60E8C014 stoppedLANE SIG ATM1/0.1: received ATM_RELEASE_COMPLETE callid 0x60EBCEB8 cause 0 lv 0x60EBBAF0 lvstate LANE_VCC_CONNECTEDLANE SIG ATM1/0.1: lane_sig_mc_release: breaking lv 0x60EBBAF0 from mcg 0x60E8F51CLANE SIG ATM1/0.1: timer for lv 0x60EBBAF0 stoppedLANE SIG ATM1/0.1: sent ATM_RELEASE request for lv 0x60EBBC10 in state LANE_VCC_CONNECTEDLANE SIG ATM1/0.1: sent ATM_RELEASE request for lv 0x60EBBB80 in state LANE_VCC_CONNECTEDLANE SIG ATM1/0.1: sent ATM_RELEASE request for lv 0x60EBBA60 in state LANE_VCC_CONNECTEDLANE SIG ATM1/0.1: received ATM_RELEASE_COMPLETE callid 0x60EBEB00 cause 0 lv 0x60EBBC10 lvstate LANE_VCC_DROP_SENTLANE SIG ATM1/0.1: lane_sig_mc_release: breaking lv 0x60EBBC10 from mcg 0x60E8F560LANE SIG ATM1/0.1: timer for lv 0x60EBBC10 stoppedLANE SIG ATM1/0.2: received ATM_RELEASE_COMPLETE callid 0x60E8B174 cause 0 lv 0x60E8D2B8 lvstate LANE_VCC_RELEASE_SENTLANE SIG ATM1/0.2: timer for lv 0x60E8D2B8 stoppedLANE SIG ATM1/0.3: received ATM_RELEASE_COMPLETE callid 0x60E8B990 cause 0 lv 0x60E8BE64 lvstate LANE_VCC_RELEASE_SENTLANE SIG ATM1/0.3: timer for lv 0x60E8BE64 stoppedLANE SIG ATM1/0.2: received ATM_RELEASE_COMPLETE callid 0x60EB7FE0 cause 0 lv 0x60E8D3D8 lvstate LANE_VCC_RELEASE_SENTLANE SIG ATM1/0.2: timer for lv 0x60E8D3D8 stoppedLANE SIG ATM1/0.3: received ATM_RELEASE_COMPLETE callid 0x60EB8554 cause 0 lv 0x60E8BF84 lvstate LANE_VCC_RELEASE_SENTLANE SIG ATM1/0.3: timer for lv 0x60E8BF84 stoppedLANE SIG ATM1/0.1: received ATM_RELEASE_COMPLETE callid 0x60EBB6D4 cause 0 lv 0x60EBBA60 lvstate LANE_VCC_RELEASE_SENTLANE SIG ATM1/0.1: timer for lv 0x60EBBA60 stoppedLANE SIG ATM1/0.1: received ATM_RELEASE_COMPLETE callid 0x60EBE24C cause 0 lv 0x60EBBB80 lvstate LANE_VCC_RELEASE_SENTLANE SIG ATM1/0.1: timer for lv 0x60EBBB80 stoppedLANE SIG ATM1/0.1: sent ATM_CANCEL_NSAP request for lv 0x0 in state NULL_VCC_POINTERLANE SIG ATM1/0.1: sent ATM_CANCEL_NSAP request for lv 0x0 in state NULL_VCC_POINTERLANE SIG ATM1/0.2: sent ATM_CANCEL_NSAP request for lv 0x0 in state NULL_VCC_POINTERLANE SIG ATM1/0.2: sent ATM_CANCEL_NSAP request for lv 0x0 in state NULL_VCC_POINTERLANE SIG ATM1/0.3: sent ATM_CANCEL_NSAP request for lv 0x0 in state NULL_VCC_POINTERLANE SIG ATM1/0.3: sent ATM_CANCEL_NSAP request for lv 0x0 in state NULL_VCC_POINTERLANE SIG ATM1/0.1: received ATM_CANCEL_NSAP for nsap 00.000000000000050000000000.000000000000.00LANE SIG ATM1/0.1: received ATM_CANCEL_NSAP for nsap 00.000000000000050000000000.000000000000.00LANE SIG ATM1/0.2: received ATM_CANCEL_NSAP for nsap 00.000000000000050000000000.000000000000.00LANE SIG ATM1/0.2: received ATM_CANCEL_NSAP for nsap 00.000000000000050000000000.000000000000.00LANE SIG ATM1/0.3: received ATM_CANCEL_NSAP for nsap 00.000000000000050000000000.000000000000.00LANE SIG ATM1/0.3: received ATM_CANCEL_NSAP for nsap 00.000000000000050000000000.000000000000.00debug lapb
Use the debug lapb EXEC command to display all traffic for interfaces using Link Access Procedure, Balanced (LAPB) encapsulation. The no form of this command disables debugging output.
[no] debug lapb
Usage Guidelines
This command displays information on the X.25 Layer 2 protocol. It is useful to users who are familiar with the LAPB protocol.
You can use the debug lapb command to determine why X.25 interfaces or LAPB connections are going up and down. It is also useful for identifying link problems, as evidenced when show interfaces command displays a high number of rejects or frame errors over the X.25 link.
CautionBecause the debug lapb command generates a lot of output, use it when the aggregate of all LAPB traffic on X.25 and LAPB interfaces is fewer than five frames per second.
Sample Display
shows sample debug lapb output. (The numbers 1 through 7 at the top of the display have been added in order to aid documentation.)
Figure 2-148 Sample Debug LAPB Output
1 2 3 4 5 6 7Serial0: LAPB I CONNECT (5) IFRAME P 2 1Serial0: LAPB O REJSENT (2) REJ F 3Serial0: LAPB O REJSENT (5) IFRAME 0 3Serial0: LAPB I REJSENT (2) REJ (C) 7Serial0: LAPB I DISCONNECT (2) SABM PSerial0: LAPB O CONNECT (2) UA FSerial0: LAPB O CONNECT (5) IFRAME 0 0Serial0: LAPB T1 CONNECT 357964 0In each line of output describes a LAPB event. There are two types of LAPB events: frame events (when a frame enters or exits the LAPB) and timer events. In , the last line describes a timer event; all of the other lines describe frame events. describes the first seven fields shown in .
A timer event only displays the first six fields of debug lapb output. For frame events, however, the fields that follow the sixth field document the LAPB control information present in the frame. Depending on the value of the frame type name shown in the sixth field, these fields may or may not appear. Descriptions of the fields following the first six fields shown in follow.
After the Poll/Final indicator, depending on the frame type, three different types of LAPB control information can be printed.
For information frames, the value of the N(S) field and the N(R) field will be printed. The N(S) field of an information frame is the sequence number of that frame, so this field will rotate between 0 and 7 for (modulo 8 operation) or 0 and 127 (for modulo 128 operation) for successive outgoing information frames and (under normal circumstances) also will rotate for incoming information frame streams. The N(R) field is a "piggybacked" acknowledgment for the incoming information frame stream; it informs the other end of the link what sequence number is expected next.
RR, RNR, and REJ frames have an N(R) field, so the value of that field is printed. This field has exactly the same significance that it does in an information frame.
For the FRMR frame, the error information is decoded to display the rejected control field, V(R) and V(S) values, the Response/Command flag, and the error flags WXYZ.
In the following example, the output shows an idle link timer action (T4) where the timer expires twice on an idle link, with the value of T4 set to five seconds:
Serial2: LAPB T4 CONNECT 255748Serial2: LAPB O CONNECT (2) RR P 5Serial2: LAPB I CONNECT (2) RR F 5Serial2: LAPB T4 CONNECT 260748Serial2: LAPB O CONNECT (2) RR P 5Serial2: LAPB I CONNECT (2) RR F 5The next example shows an interface outage timer expiration (T3):
Serial2: LAPB T3 DISCONNECT 273284The following example output shows an error condition when no DCE to DTE connection exists. Note that if a frame has only one valid type (for example, a SABM can only be a command frame), a received frame that has the wrong frame type will be flagged as a receive error (R/ERR in the following output). This feature makes misconfigured links (DTE-DTE or DCE-DCE) easy to spot. Other, less common errors will be highlighed too, such as a too-short or too-long frame, or an invalid address (neither command nor response):
Serial2: LAPB T1 SABMSENT 1026508 1Serial2: LAPB O SABMSENT (2) SABM PSerial2: LAPB I SABMSENT (2) SABM (R/ERR)Serial2: LAPB T1 SABMSENT 1029508 2Serial2: LAPB O SABMSENT (2) SABM PSerial2: LAPB I SABMSENT (2) SABM (R/ERR)The output in the next example shows the router is misconfigured and has a standard (modulo 8) interface connected to an extended (modulo 128) interface. This condition is indicated by the SABM balanced mode and SABME balanced mode extended messages appearing on the same interface:
Serial2: LAPB T1 SABMSENT 1428720 0Serial2: LAPB O SABMSENT (2) SABME PSerial2: LAPB I SABMSENT (2) SABM PSerial2: LAPB T1 SABMSENT 1431720 1Serial2: LAPB O SABMSENT (2) SABME PSerial2: LAPB I SABMSENT (2) SABM Pdebug lat packet
Use the debug lat packet EXEC command to display information on all LAT events. The no form of this command disables debugging output.
[no] debug lat packet
Usage Guidelines
For each datagram (packet) received or transmitted, a message is logged to the console.
Note
Sample Display
shows sample debug lat packet output.
Figure 2-149 Sample Debug LAT Packet Output
router# debug lat packetLAT: I int=Ethernet0, src=0000.0c01.0509, dst=0900.2b00.000f, type=0, M=0, R=0LAT: I int=Ethernet0, src=0800.2b11.2d13, dst=0000.0c01.7876, type=A, M=0, R=0LAT: O dst=0800.2b11.2d13, int=Ethernet0, type= A, M=0, R=0, len= 20, next 0 ref 1The second line of output in describes a packet that is input to the router. describes the fields in this line.
The third line of output in describes a packet that is output from the router. describes the last three fields in this line.
debug lex rcmd
Use the debug lex rcmd EXEC command to debug LAN Extender remote commands. The no form of this command disables debugging output.
[no] debug lex rcmd
Sample Display
shows sample debug lex rcmd output.
Figure 2-150 Sample Debug LEX Rcmd Output
router# debug lex rcmdLEX-RCMD: "shutdown" command received on unbound serial interface- Serial0LEX-RCMD: Lex0: "inventory" command receivedRcvd rcmd: FF 03 80 41 41 13 00 1A 8A 00 00 16 01 FF 00 00Rcvd rcmd: 00 02 00 00 07 5B CD 15 00 00 0C 01 15 26LEX-RCMD: ACK or response received on Serial0 without a corresponding IDLEX-RCMD: REJ receivedLEX-RCMD: illegal CODE field received in header: <number>LEX-RCMD: illegal length for Lex0: "lex input-type-list"LEX-RCMD: Lex0 is not bound to a serial interfaceLEX-RCMD: encapsulation failureLEX-RCMD: timeout for Lex0: "lex priority-group" commandLEX-RCMD: re-transmitting Lex0: "lex priority-group" commandLEX-RCMD: lex_setup_and_send called with invalid parameterLEX-RCMD: bind occurred on shutdown LEX interfaceLEX-RCMD: Serial0- No free Lex interface found with negotiated MAC address 0000.0c00.d8dbLEX-RCMD: No active Lex interface found for unbindExplanations for individual lines of output from follow.
The following output indicates that a LAN Extender remote command packet was received on a serial interface which is not bound to a LAN Extender interface.
LEX-RCMD: "shutdown" command received on unbound serial interface- Serial0This message can occur for any of the LAN Extender remote commands. Possible causes of this message are as follows:
•
•
The following output indicates that a LAN Extender remote command response has been received. The hexadecimal values are for internal use only:
LEX-RCMD: Lex0: "inventory" command receivedRcvd rcmd: FF 03 80 41 41 13 00 1A 8A 00 00 16 01 FF 00 00Rcvd rcmd: 00 02 00 00 07 5B CD 15 00 00 0C 01 15 26The following output indicates that when the host router originates a LAN Extender remote command to FLEX, it generates an 8-bit identifier which is used to associate a command with its corresponding response:
LEX-RCMD: ACK or response received on Serial0 without a corresponding IDThis message could be displayed for any of the following reasons:
•
•
•
Possible responses to Config-Request are Config-ACK, Config-NAK, and Config-Rej. The following output shows that some of the options in the Config-Request are not recognizable or are not acceptable to FLEX due to transmission errors or software errors:
LEX-RCMD: REJ receivedThe following output shows that a LAN Extender remote command response was received but that the CODE field in the header was incorrect:
LEX-RCMD: illegal CODE field received in header: <number>The following output indicates that a LAN Extender remote command response was received but that it had an incorrect length field. This message can occur for any of the LAN Extender remote commands:
LEX-RCMD: illegal length for Lex0: "lex input-type-list"The following output shows that a host router was about to send a remote command when the serial link went down:
LEX-RCMD: Lex0 is not bound to a serial interfaceThe following output shows that the serial interface's encapsulation routine failed to encapsulate the remote command datagram because the LEX-NCP was not in the OPEN state. Due to the way the PPP state machine is implemented, it is normal to see a single encapsulation failure for each remote command that gets sent at bind time.
LEX-RCMD: encapsulation failureThe following output shows that the timer expired for the given remote command without having received a response from the FLEX device. This message can occur for any of the LAN Extender remote commands:
LEX-RCMD: timeout for Lex0: "lex priority-group" commandThis message could be displayed for any of the following reasons:
•
•
•
The following output indicates that the host is retransmitting the remote command after a timeout:
LEX-RCMD: re-transmitting Lex0: "lex priority-group" commandThe following output indicates that an illegal parameter was passed to the lex_setup_and_send routine. This message could be displayed for due to a host software error:
LEX-RCMD: lex_setup_and_send called with invalid parameterThe following output is informational and shows when a bind occurs on a shutdown interface:
LEX-RCMD: bind occurred on shutdown LEX interfaceThe following output shows that LEX-NCP reached the open state and a bind operation was attempted with the FLEX's MAC address, but no free LAN Extender interfaces were found that were configured with that MAC address. This output can occur when the network administrator does not configure a LAN Extender interface with the correct MAC address.
LEX-RCMD: Serial0- No free Lex interface found with negotiated MAC address 0000.0c00.d8dbThe following output shows that the serial line that was bound to the LAN Extender interface went down and the unbind routine was called, but when the list of active LAN Extender interfaces was searched, the LAN Extender interface corresponding to the serial interface was not found. This output usually occurs because of a host software error:
LEX-RCMD: No active Lex interface found for unbinddebug list
Use the debug list EXEC command to filter debugging information on a per-interface or per-access list basis. The no form of this command turns off the list filter.
debug list [list] [interface]
no debug listSyntax Description
Usage Guidelines
The debug list command is used with other debug commands for specific protocols and interfaces to filter the amount of debug information that is displayed. In particular, this command is designed to filter specific physical unit (PU) output from bridging protocols. The debug list command is supported with the following commands:
•
•
•
•
•
•
Note
Examples
To use debug list on only the first of several LLC2 connections, use the show llc2 command to display the active connections:
router# show llc2SdllcVirtualRing2008 DTE: 4000.2222.22c7 4000.1111.111c 04 04 state NORMALSdllcVirtualRing2008 DTE: 4000.2222.22c8 4000.1111.1120 04 04 state NORMALSdllcVirtualRing2008 DTE: 4000.2222.22c1 4000.1111.1104 04 04 state NORMALNext, configure an extended bridging access list, numbered 1103, for the connection you want to filter:
access-list 1103 permit 4000.1111.111c 0000.0000.0000 4000.2222.22c7 0000.0000.0000 0xC 2 eq 0x404The convention for LLC debug list filtering is to use dmac=6 bytes, smac=6 bytes, dsap_offset = 12, and ssap_offset = 13.
Finally, you invoke the debug commands:
router# debug list 1103router# debug llc2 packetLLC2 Packets debugging is onfor access list: 1103To use debug list for SDLC connections, with the exception of address 04, create access list 1102 to deny the specific address and permit all others:
access-list 1102 deny 0000.0000.0000 0000.0000.0000 0000.0000.0000 0000.0000.0000 0xC 1 eq 0x4access-list 1102 permit 0000.0000.0000 0000.0000.0000 0000.0000.0000 0000.0000.0000The convention is to use dmac = 0.0.0, smac = 0.0.0, and sdlc_frame_offset = 12.
Invoke the debug commands:
router# debug list 1102router# debug sdlcSDLC link debugging is onfor access list: 1102To enable SDLC debugging (or debugging for any of the other supported protocols) for a specific interface rather than for all interfaces on a router, use the following commands:
router# debug list serial 0router# debug sdlcSDLC link debugging is onfor interface: Serial0To enable Token Ring debugging between two MAC address, 0000.3018.4acd and 0000.30e0.8250, configure an extended bridging access list 1106:
access-list 1106 permit 0000.3018.4acd 8000.0000.0000 0000.30e0.8250 8000.0000.0000access-list 1106 permit 0000.30e0.8250 8000.0000.0000 0000.3018.4acd 8000.0000.0000Invoke the debug commands:
router# debug list 1106router# debug token ringToken Ring Interface debugging is onfor access list: 1106To enable RIF debugging for a single MAC address, configure an access list 1109:
access-list 1109 permit permit 0000.0000.0000 ffff.ffff.ffff 4000.2222.22c6 0000.0000.0000Invoke the debug commands:
router# debug list 1109router# debug rifRIF update debugging is onfor access list: 1109Related Commands
debug llc2 errors
debug llc2 packet
debug llc2 state
debug rif
debug sdlc
debug token ringdebug llc2 dynwind
Use the debug llc2 dynwind EXEC command to display changes to the dynamic window over Frame Relay. The no form of this command disables debugging output.
[no] debug llc2 dynwind
Sample Display
shows sample debug llc2 dynwind output.
Figure 2-151 Sample Debug LLC2 Dynwind Output
router# debug llc2 dynwindLLC2/DW: BECN received! event REC_I_CMD, Window size reduced to 4LLC2/DW: 1 consecutive I-frame(s) received without BECNLLC2/DW: 2 consecutive I-frame(s) received without BECNLLC2/DW: 3 consecutive I-frame(s) received without BECNLLC2/DW: 4 consecutive I-frame(s) received without BECNLLC2/DW: 5 consecutive I-frame(s) received without BECNLLC2/DW: Current working window size is 5In this example, the router receives a backward explicit congestion notification (BECN) and reduces the window size to four. After receiving five consecutive I-frames without a BECN, the router increases the window size to five.
Related Commands
debug llc2 errors
debug llc2 packet
debug llc2 statedebug llc2 errors
Use the debug llc2 errors EXEC command to display Logical Link Control, type 2 (LLC2) protocol error conditions or unexpected input. The no form of this command disables debugging output.
[no] debug llc2 errors
Sample Display
shows sample debug llc2 errors output from a router ignoring an incorrectly configured device.
Figure 2-152 Sample Debug LLC2 Errors Output
router# debug llc2 errorsLLC: admstate: 4000.1014.0001 0000.0000.0000 04 04 REC_RR_RSPLLC: admstate: 4000.1014.0001 0000.0000.0000 04 04 REC_RR_RSPLLC: admstate: 4000.1014.0001 0000.0000.0000 04 04 REC_RR_RSPLLC: admstate: 4000.1014.0001 0000.0000.0000 04 04 REC_RR_RSPLLC: admstate: 4000.1014.0001 0000.0000.0000 04 04 REC_RR_RSPLLC: admstate: 4000.1014.0001 0000.0000.0000 04 04 REC_RR_RSPEach line of output contains the remote MAC address, the local MAC address, the remote service access point (SAP), and the local SAP. In this example, the router receives unsolicited RR frames marked as responses.
Related Commands
debug list
debug llc2 dynwind
debug llc2 packet
debug llc2 statedebug llc2 packet
Use the debug llc2 packet EXEC command to display all input and output from the Logical Link Control, type 2 (LLC2) protocol stack. This command also displays information about some error conditions as well as internal interactions between the Common Link Services (CLS) layer and the LLC2 layer. The no form of this command disables debugging output.
[no] debug llc2 packet
Sample Display
shows sample debug llc2 packet output from the router sending ping data back and forth to another router.
Figure 2-153 Sample Debug LLC2 Packet Output
router# debug llc2 packetLLC: llc2_input401E54F0: 10400000 .@..401E5500: 303A90CF 0006F4E1 2A200404 012B5E 0:.O..ta* ...+LLC: i REC_RR_CMD N(R)=21 p/f=1LLC: 0006.f4e1.2a20 0000.303a.90cf 04 04 NORMAL REC_RR_CMD (3)LLC (rs): 0006.f4e1.2a20 0000.303a.90cf 04 04 REC_RR_CMD N(R)=42LLC: 0006.f4e1.2a20 0000.303a.90cf 04 04 txmt RR_RSP N(R)=20 p/f=1LLC: llc_sendframe401E5610: 0040 0006F4E1 2A200000 .@..ta* ..401E5620: 303A90CF 04050129 00 N 0:.O...). 2012LLC: llc_sendframe4022E3A0: 0040 0006F4E1 .@..ta4022E3B0: 2A200000 303A90CF 04042A28 2C000202 * ..0:.O..*(,...4022E3C0: 00050B90 A02E0502 FF0003D1 004006C1 .... ......Q.@.A4022E3D0: D7C9D5C 0.128C400130A C1D7D7D5 4BD5F2F0 WIUGD...AWWUKUrp4022E3E0: F1F30000 011A6071 00010860 D7027000 qs....`q...`W.p.4022E3F0: 00003B00 1112FF01 03000243 6973636F ..;........Cisco4022E400: 20494F53 69 IOSiLLC: 0006.f4e1.2a20 0000.303a.90cf 04 04 txmt I N(S)=21 N(R)=20 p/f=0 size=90LLC: llc2_input401E5620: 10400000 303A90CF .@..0:.O401E5630: 0006F4E1 2A200404 282C2C00 02020004 ..ta* ..(,,.....401E5640: 03902000 1112FF01 03000243 6973636F .. ........Cisco401E5650: 20494F53 A0 IOSLLC: i REC_I_CMD N(R)=22 N(S)=20 V(R)=20 p/f=0LLC: 0006.f4e1.2a20 0000.303a.90cf 04 04 NORMAL REC_I_CMD (1)LLC (rs): 0006.f4e1.2a20 0000.303a.90cf 04 04 REC_I_CMD N(S)=20 V(R)=20LLC (rs): 0006.f4e1.2a20 0000.303a.90cf 04 04 REC_I_CMD N(R)=44LLC: INFO: 0006.f4e1.2a20 0000.303a.90cf 04 04 v(r) 20The first three lines indicate that the router has received some input from the link.
LLC: llc2_input401E54F0: 10400000 .@..401E5500: 303A90CF 0006F4E1 2A200404 012B5E 0:.O..ta* ...+The next line indicates that this input was an RR command with the poll bit set. The other router has received sequence number 21 and is waiting for the final bit.
LLC: i REC_RR_CMD N(R)=21 p/f=1The next two lines contain the MAC addresses of the sender and receiver as well as the state of the router when it received this frame.
LLC: 0006.f4e1.2a20 0000.303a.90cf 04 04 NORMAL REC_RR_CMD (3)LLC (rs): 0006.f4e1.2a20 0000.303a.90cf 04 04 REC_RR_CMD N(R)=42The next four lines indicate that the router is transmitting a response with the final bit set.
LLC: 0006.f4e1.2a20 0000.303a.90cf 04 04 txmt RR_RSP N(R)=20 p/f=1LLC: llc_sendframe401E5610: 0040 0006F4E1 2A200000 .@..ta* ..401E5620: 303A90CF 04050129 00 N 0:.O...). 2012Related Commands
debug list
debug llc2 dynwind
debug llc2 errors
debug llc2 statedebug llc2 state
Use the debug llc2 state EXEC command to display state transitions of the Logical Link Control, type 2 (LLC2) protocol. The no form of this command disables debugging output.
[no] debug llc2 state
Usage Guidelines
Refer to the ISO/IEC standard 8802-2 for definitions and explanations of debug llc2 state output.
Sample Display
shows sample debug llc2 state output when a router disables and enables an interface.
Figure 2-154 Sample Debug LLC2 State Output
router# debug llc2 stateLLC (stsw): 0006.f4e1.2a20 0000.303a.90cf 04 04, NORMAL -> AWAIT (P_TIMER_EXP)LLC(rs): 0006.f4e1.2a20 0000.303a.90cf 04 04, AWAIT -> D_CONN (P_TIMER_EXP)LLC: cleanup 0006.f4e1.2a20 0000.303a.90cf 04 04, UNKNOWN (17)LLC (stsw): 0006.f4e1.2a20 0000.303a.90cf 04 04, ADM -> SETUP (CONN_REQ)LLC: normalstate: set_local_busy 0006.f4e1.2a20 0000.303a.90cf 04 04LLC (stsw): 0006.f4e1.2a20 0000.303a.90cf 04 04, NORMAL -> BUSY (SET_LOCAL_BUSY)LLC: Connection established: 0006.f4e1.2a20 0000.303a.90cf 04 04, successLLC (stsw): 0006.f4e1.2a20 0000.303a.90cf 04 04, SETUP -> BUSY (SET_LOCAL_BUSY)LLC: busystate: 0006.f4e1.2a20 0000.303a.90cf 04 04 local busy clearedLLC (stsw): 0006.f4e1.2a20 0000.303a.90cf 04 04, BUSY -> NORMAL (CLEAR_LOCAL_BUSY)Related Commands
debug list
debug llc2 dynwind
debug llc2 errors
debug llc2 packetdebug lnm events
Use the debug lnm events EXEC command to display any unusual events that occur on a Token Ring network. These events include stations reporting errors or error thresholds being exceeded. The no form of this command disables debugging output.
[no] debug lnm events
Sample Display
shows sample debug lnm events output.
Figure 2-155 Sample Debug LNM Events Output
router# debug lnm eventsIBMNM3: Adding 0000.3001.1166 to error listIBMNM3: Station 0000.3001.1166 going into preweight conditionIBMNM3: Station 0000.3001.1166 going into weight conditionIBMNM3: Removing 0000.3001.1166 from error listLANMGR0: Beaconing is present on the ringLANMGR0: Ring is no longer beaconingIBMNM3: Beaconing, Postmortem StartedIBMNM3: Beaconing, heard from 0000.3000.1234IBMNM3: Beaconing, Postmortem Next StageIBMNM3: Beaconing, Postmortem FinishedExplanations for the messages shown in follow.
The following message indicates that station 0000.3001.1166 reported errors and has been added to the list of stations reporting errors. This station is located on Ring 3.
IBMNM3: Adding 0000.3001.1166 to error listThe following message indicates that station 0000.3001.1166 has passed the "early warning" threshold for error counts:
IBMNM3: Station 0000.3001.1166 going into preweight conditionThe following message indicates that station 0000.3001.1166 is experiencing a severe number of errors:
IBMNM3: Station 0000.3001.1166 going into weight conditionThe following message indicates that the error counts for station 0000.3001.1166 have all decayed to zero, so this station is being removed from the list of stations that have reported errors:
IBMNM3: Removing 0000.3001.1166 from error listThe following message indicates that Ring 0 has entered failure mode. This ring number is assigned internally.
LANMGR0: Beaconing is present on the ringThe following message indicates that Ring 0 is no longer in failure mode. This ring number is assigned internally.
LANMGR0: Ring is no longer beaconingThe following message indicates that the router is beginning its attempt to determine whether any stations left the ring during the automatic recovery process for the last beaconing failure. The router attempts to contact stations that were part of the fault domain to detect whether they are still operating on the ring.
IBMNM3: Beaconing, Postmortem StartedThe following message indicates that the router is attempting to determine whether or not any stations left the ring during the automatic recovery process for the last beaconing failure. It received a response from station 0000.3000.1234, one of the two stations in the fault domain.
IBMNM3: Beaconing, heard from 0000.3000.1234The following message indicates that the router is attempting to determine whether any stations left the ring during the automatic recovery process for the last beaconing failure. It is initiating another attempt to contact the two stations in the fault domain.
IBMNM3: Beaconing, Postmortem Next StageThe following message indicates that the router has attempted to determine whether any stations left the ring during the automatic recovery process for the last beaconing failure. It has successfully heard back from both stations that were part of the fault domain.
IBMNM3: Beaconing, Postmortem FinishedExplanations follow for other messages that the debug lnm events command can generate.
The following message indicates that the router is out of memory:
LANMGR: memory request failed, find_or_build_station()The following message indicates that Ring 3 is experiencing a large number of errors that cannot be attributed to any individual station:
IBMNM3: Non-isolating error threshold exceededThe following message indicates that a station (or stations) on Ring 3 are receiving frames faster than they can be processed.
IBMNM3: Adapters experiencing congestionThe following message indicates that the beaconing has lasted for over 1 minute and is considered a "permanent" error:
IBMNM3: Beaconing, permanentThe following message indicates that the beaconing lasted for less than 1 minute. The router is attempting to determine whether either station in the fault domain left the ring.
IBMNM: Beaconing, Destination StartedIn the preceding line of output, the following can replace "Started": "Next State", "Finished", "Timed out", and "Cannot find station n".
debug lnm llc
Use the debug lnm llc EXEC command to display all communication between the router/bridge and the LAN Network Managers (LNMs) that have connections to it. The no form of this command disables debugging output.
[no] debug lnm llc
Usage Guidelines
One line is displayed for each message sent or received.
Sample Display
shows sample debug lnm llc output.
Figure 2-156 Sample Debug LNM LLC Output
router# debug lnm llcIBMNM: Received LRM Set Reporting Point frame from 1000.5ade.0d8a.IBMNM: found bridge: 001-2-00A, addresses: 0000.3040.a630 4000.3040.a630IBMNM: Opening connection to 1000.5ade.0d8a on TokenRing0IBMNM: Sending LRM LAN Manager Accepted to 1000.5ade.0d8a on link 0.IBMNM: sending LRM New Reporting Link Established to 1000.5a79.dbf8 on link 1.IBMNM: Determining new controlling LNMIBMNM: Sending Report LAN Manager Control Shift to 1000.5ade.0d8a on link 0.IBMNM: Sending Report LAN Manager Control Shift to 1000.5a79.dbf8 on link 1.IBMNM: Bridge 001-2-00A received Request Bridge Status from 1000.5ade.0d8a.IBMNM: Sending Report Bridge Status to 1000.5ade.0d8a on link 0.IBMNM: Bridge 001-2-00A received Request REM Status from 1000.5ade.0d8a.IBMNM: Sending Report REM Status to 1000.5ade.0d8a on link 0.IBMNM: Bridge 001-2-00A received Set Bridge Parameters from 1000.5ade.0d8a.IBMNM: Sending Bridge Parameters Set to 1000.5ade.0d8a on link 0.IBMNM: sending Bridge Params Changed Notification to 1000.5a79.dbf8 on link 1.IBMNM: Bridge 001-2-00A received Set REM Parameters from 1000.5ade.0d8a.IBMNM: Sending REM Parameters Set to 1000.5ade.0d8a on link 0.IBMNM: sending REM Parameters Changed Notification to 1000.5a79.dbf8 on link 1.IBMNM: Bridge 001-2-00A received Set REM Parameters from 1000.5ade.0d8a.IBMNM: Sending REM Parameters Set to 1000.5ade.0d8a on link 0.IBMNM: sending REM Parameters Changed Notification to 1000.5a79.dbf8 on link 1.IBMNM: Received LRM Set Reporting Point frame from 1000.5ade.0d8a.IBMNM: found bridge: 001-1-00A, addresses: 0000.3080.2d79 4000.3080.2d7As indicates, debug lnm llc output can vary somewhat in format. describes significant fields shown in the first line of output in .
Explanations for other types of messages shown in follow.
The following message indicates that the lookup for the bridge with which the LAN Manager was requesting to communicate was successful:
IBMNM: found bridge: 001-2-00A, addresses: 0000.3040.a630 4000.3040.a630The following message is self-explanatory:
IBMNM: Opening connection to 1000.5ade.0d8a on TokenRing0The following message indicates that a LAN Manager has connected or disconnected from an internal bridge and that the router computes which LAN Manager is allowed to change parameters:
IBMNM: Determining new controlling LNMThe following line of output indicates which bridge in the router is the destination for the frame:
IBMNM: Bridge 001-2-00A received Request Bridge Status from 1000.5ade.0d8a.debug lnm mac
Use the debug lnm mac EXEC command to display all management communication between the router/bridge and all stations on the local Token Rings. The no form of this command disables debugging output.
[no] debug lnm mac
Usage Guidelines
One line is displayed for each message sent or received.
Sample Display
shows sample debug lnm mac output.
Figure 2-157 Sample Debug LNM MAC Output
router# debug lnm macLANMGR0: RS received request address from 4000.3040.a670.LANMGR0: RS sending report address to 4000.3040.a670.LANMGR0: RS received request state from 4000.3040.a670.LANMGR0: RS sending report state to 4000.3040.a670.LANMGR0: RS received request attachments from 4000.3040.a670.LANMGR0: RS sending report attachments to 4000.3040.a670.LANMGR2: RS received ring purge from 0000.3040.a630.LANMGR2: CRS received report NAUN change from 0000.3040.a630.LANMGR2: RS start watching ring poll.LANMGR0: CRS received report NAUN change from 0000.3040.a630.LANMGR0: RS start watching ring poll.LANMGR2: REM received report soft error from 0000.3040.a630.LANMGR0: REM received report soft error from 0000.3040.a630.LANMGR2: RS received ring purge from 0000.3040.a630.LANMGR2: RS received AMP from 0000.3040.a630.LANMGR2: RS received SMP from 0000.3080.2d79.LANMGR2: CRS received report NAUN change from 1000.5ade.0d8a.LANMGR2: RS start watching ring poll.LANMGR0: RS received ring purge from 0000.3040.a630.LANMGR0: RS received AMP from 0000.3040.a630.LANMGR0: RS received SMP from 0000.3080.2d79.LANMGR0: CRS received report NAUN change from 1000.5ade.0d8a.LANMGR0: RS start watching ring poll.LANMGR2: RS received SMP from 1000.5ade.0d8a.LANMGR2: RPS received request initialization from 1000.5ade.0d8a.LANMGR2: RPS sending initialize station to 1000.5ade.0d8a.describes significant fields shown in the first line of output in .
As indicates, all debug lnm mac messages follow the format described in except the following:
LANMGR2: RS start watching ring pollLANMGR2: RS stop watching ring pollThese messages indicate that the router starts and stops receiving AMP and SMP frames. These frames are used to build a current picture of which stations are on the ring.
debug local-ack state
Use the debug local-ack state EXEC command to display the new and the old state conditions whenever there is a state change in the local acknowledgment state machine. The no form of this command disables debugging output.
[no] debug local-ack state
Sample Display
shows sample debug local-ack state output.
Figure 2-158 Sample Debug Local-Ack State Output
router# debug local-ack stateLACK_STATE: 2370300, hashp 2AE628, old state = disconn, new state = awaitingLLC2 open to finishLACK_STATE: 2370304, hashp 2AE628, old state = awaiting LLC2 open to finish,new state = connectedLACK_STATE: 2373816, hashp 2AE628, old state = connected, new state = disconnectedLACK_STATE: 2489548, hashp 2AE628, old state = disconn, new state = awaitingLLC2 open to finishLACK_STATE: 2489548, hashp 2AE628, old state = awaiting LLC2 open to finish,new state = connectedLACK_STATE: 2490132, hashp 2AE628, old state = connected, new state = awaitinglinkdown responseLACK_STATE: 2490140, hashp 2AE628, old state = awaiting linkdown response,new state = disconnectedLACK_STATE: 2497640, hashp 2AE628, old state = disconn, new state = awaitingLLC2 open to finishLACK_STATE: 2497644, hashp 2AE628, old state = awaiting LLC2 open to finish,new state = connecteddescribes significant fields shown in .
debug modem
Use the debug modem EXEC command to observe modem line activity on an access server. The no form of this command disables debugging output.
[no] debug modem
Usage Guidelines
This output of this command is self-explanatory.
Sample Display
shows sample debug modem output.
Figure 2-159 Sample Debug Modem Output
router# debug modem15:25:51: TTY4: DSR came up15:25:51: tty4: Modem: IDLE->READY15:25:51: TTY4: Autoselect started15:27:51: TTY4: Autoselect failed15:27:51: TTY4: Line reset15:27:51: TTY4: Modem: READY->HANGUP15:27:52: TTY4: dropping DTR, hanging up15:27:52: tty4: Modem: HANGUP->IDLE15:27:57: TTY4: restoring DTR15:27:58: TTY4: DSR came upThe output in shows when the modem line changes state.
debug modem csm
Use the debug modem csm EXEC command to debug the call state machine used to connect calls on the modem of an AS5200 access server. Use the no form of this command to disable debug output.
[no] debug modem csm [slot/modem-port | group group-number]
Syntax Description
Usage Guidelines
Use the debug modem csm command to troubleshoot call switching problems. With this command, you can trace the complete sequence of switching incoming and outgoing calls.
Sample Displays
shows sample debug modem csm output. In this example, a call enters the modem (incoming) on slot 1 port 0.
Figure 2-160 Sample Debug Modem CSM Output—Incoming Call
AS5200(config)#service timestamps debug uptimeAS5200(config)#endAS5200#debug modem csmModem Management Call Switching Module debugging is on00:04:09: ccpri_ratetoteup bear rate is 1000:04:09: CSM_MODEM_ALLOCATE: slot 1 and port 0 is allocated.00:04:09: MODEM_REPORT(0001): DEV_INCALL at slot 1 and port 000:04:09: CSM_PROC_IDLE: CSM_EVENT_ISDN_CALL at slot 1, port 000:04:11: CSM_RING_INDICATION_PROC: RI is on00:04:13: CSM_RING_INDICATION_PROC: RI is off00:04:15: CSM_PROC_IC1_RING: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 000:04:15: MODEM_REPORT(0001): DEV_CONNECTED at slot 1 and port 000:04:15: CSM_PROC_IC2_WAIT_FOR_CARRIER: CSM_EVENT_ISDN_CONNECTED at slot 1, port 0shows sample debug modem csm output when call is dialed from the modem into the network (outgoing) from slot 1 port 2.
Figure 2-161 Sample Debug Modem CSM Output—Outgoing Call
AS5200#debug modem csmatdt1666520200:11:21: CSM_PROC_IDLE: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 200:11:21: T1_MAIL_FROM_NEAT: DC_READY_RSP: mid = 1, slot = 0, unit = 000:11:21: CSM_PROC_OC1_REQUEST_DIGIT: CSM_EVENT_DIGIT_COLLECT_READY at slot 1, port 200:11:24: T1_MAIL_FROM_NEAT: DC_FIRST_DIGIT_RSP: mid = 1, slot = 0, unit = 000:11:24: CSM_PROC_OC2_COLLECT_1ST_DIGIT: CSM_EVENT_GET_1ST_DIGIT at slot 1, port 200:11:27: T1_MAIL_FROM_NEAT: DC_ALL_DIGIT_RSP: mid = 1, slot = 0, unit = 000:11:27: CSM_PROC_OC3_COLLECT_ALL_DIGIT: CSM_EVENT_GET_ALL_DIGITS (16665202) at slot 1, port 200:11:27: ccpri_ratetoteup bear rate is 1000:11:27: MODEM_REPORT(A000): DEV_CALL_PROC at slot 1 and port 200:11:27: CSM_PROC_OC4_DIALING: CSM_EVENT_ISDN_BCHAN_ASSIGNED at slot 1, port 200:11:31: MODEM_REPORT(A000): DEV_CONNECTED at slot 1 and port 200:11:31: CSM_PROC_OC5_WAIT_FOR_CARRIER: CSM_EVENT_ISDN_CONNECTED at slot 1, port 2CONNECT 19200/REL - MNPRelated Commands
debug modem oob
debug modem tracedebug modem oob
Use the debug modem oob EXEC command to debug the out-of-band port used to poll modem events on the modem of a Cisco AS5200. Use the no form of this command to disable debug output.
[no] debug modem oob [slot/modem-port | group group-number]
Syntax Description
Usage Guidelines
CautionEntering the debug modem oob command without specifying a slot and modem number debugs all out-of-band ports in the Cisco AS5200, which generates a significant amount of information.
The message types and sequence numbers that appear in the debug output are initiated by the Modem Out-of-Band (OOB) Protocol and used by service personnel for debugging purposes.
Sample Display
shows sample debug modem oob output. This example debugs the out-of-band port on modem 2/0, which creates modem startup messages between the network management software and the modem.
Figure 2-162 Sample Debug Modem OOB Output
AS5200# debug modem oob 2/0MODEM(2/0): One message sent --Message type:3, Sequence number:0MODEM(2/0): Modem DC session data replyMODEM(2/0): One message sent --Message type:83, Sequence number:1MODEM(2/0): DC session event =MODEM(2/0): One message sent --Message type:82, Sequence number:2MODEM(2/0): No status changes since last polledMODEM(2/0): One message sent --Message type:3, Sequence number:3MODEM(2/0): Modem DC session data replyMODEM(2/0): One message sent --Message type:83, Sequence number:4Related Commands
debug modem csm
debug modem tracedebug modem trace
Use the debug modem trace EXEC command to debug a call trace on the modem of a Cisco AS5200 access server to determine why calls are terminated. Use the no form of this command to disable debug output.
[no] debug modem trace [normal | abnormal | all] [slot/modem-port | group group-number]
Syntax Description
Usage Guidelines
The debug modem trace command applies only to manageable modems.
For additional information, use the show modem command.
Sample Display
shows sample debug modem trace abnormal output.
Figure 2-163 Sample Debug Modem Trace Command
AS5200# debug modem trace abnormal 1/14Modem 1/14 Abnormal End of Connection Trace. Caller 123-4567Start-up Response: AS5200 Modem, Firmware 1.0Control Reply: 0x7C01DC session response: brasil firmware 1.0RS232 event:DSR=On, DCD=On, RI=Off, TST=Offchanges: RTS=No change, DTR=No change, CTS=No changechanges: DSR=No change, DCD=No change, RI=No change, TST=No changeModem State event: ConnectedConnection event: Speed = 19200, Modulation = VFCDirection = Originate, Protocol = reliable/LAPM, Compression = V42bisDTR event: DTR OnModem Activity event: Data ActiveModem Analog signal event: TX = -10, RX = -24, Signal to noise = -32End connection event: Duration = 10:34-11:43,Number of xmit char = 67, Number of rcvd char = 88, Reason: Watchdog Time-out.Related Commands
debug modem csm
debug modem oobdebug ncia circuit
Use the debug ncia circuit EXEC command to display circuit-related information between the native client interface architecture (NCIA) server and client. The no form of this command disables debugging output.
[no] debug ncia circuit [error | event | flow-control | state]
Syntax Description
Usage Guidelines
NCIA is an architecture developed by Cisco for accessing SNA applications. This architecture allows native SNA interfaces on hosts and clients to access TCP/IP backbones.
You cannot enable debugging output for a particular client or particular circuit.
CautionDo not enable the debug ncia circuit command during normal operation because this command generates a large amount of output messages and could slow down the router.
Sample Displays
shows sample debug ncia circuit error output. In this example, the possible errors are displayed. The first error message indicates that the router is out of memory. The second message indicates that the router has an invalid circuit control block. The third message indicates that the router is out of memory. The remaining messages identify errors related to the finite state machine.
Figure 2-164 Sample Debug NCIA Circuit Error Output
router# debug ncia circuit errorNCIA: ncia_circuit_create memory allocation failNCIA: ncia_send_ndlc: invalid circuit control blockNCIA: send_ndlc: fail to get buffer for ndlc primitive xxxNCIA: ncia circuit fsm: Invalid inputNCIA: ncia circuit fsm: Illegal stateNCIA: ncia circuit fsm: Illegal inputNCIA: ncia circuit fsm: Unexpected inputNCIA: ncia circuit fsm: Unknown error rtn codeshows sample debug ncia circuit event output. In this example, a session start-up sequence is displayed.
Figure 2-165 Sample Debug NCIA Circuit Event Output
router# debug ncia circuit eventNCIA(IN): Ver_Id: 0x81, MsgType: NDLC_START_DL, Len: 24, tmac: 4000.1060.1000,tsap: 4, csap 8, oid: 8A91E8, tid 0, lfs 16, ws 1NCIA: create circuit: saddr 4000.1060.1000, ssap 4, daddr 4000.3000.0003, dsap 8 sid:8B09A8NCIA: send NDLC_DL_STARTED to client 10.2.20.3 for ckt: 8B09A8NCIA(OUT): Ver_Id: 0x81, MsgType: NDLC_DL_STARTED, Len: 2,4 tmac: 4000.1060.1000,tsap: 4, csap 8, oid: 8A91E8, tid 8B09A8, lfs 16, ws 1NCIA(IN): Ver_Id: 0x81, MsgType: NDLC_XID_FRAME, Len: 12, sid: 8B09A8, FC 0x81NCIA: send NDLC_XID_FRAME to client 10.2.20.3 for ckt: 8B09A8NCIA(OUT): Ver_Id: 0x81, MsgType: NDLC_XID_FRAME, Len: 12, sid: 8A91E8, FC 0xC1NCIA(IN): Ver_Id: 0x81, MsgType: NDLC_XID_FRAME, Len: 18, sid: 8B09A8, FC 0xC1NCIA: send NDLC_CONTACT_STN to client 10.2.20.3 for ckt: 8B09A8NCIA(OUT): Ver_Id: 0x81, MsgType: NDLC_CONTACT_STN, Len: 12, sid: 8A91E8, FC 0xC1NCIA(IN): Ver_Id: 0x81, MsgType: NDLC_STN_CONTACTED, Len: 12, sid: 8B09A8, FC 0xC1NCIA: send NDLC_INFO_FRAME to client 10.2.20.3 for ckt: 8B09A8NCIA(OUT): Ver_Id: 0x81, MsgType: NDLC_INFO_FRAME, Len: 30, sid: 8A91E8, FC 0xC1describes the fields and messages shown in .
In the following messages, an NDLC_START_DL messages is received from a client. to start a data link session.
NCIA(IN): Ver_Id: 0x81, MsgType: NDLC_START_DL, Len: 24, tmac: 4000.1060.1000,tsap: 4, csap 8, oid: 8A91E8, tid 0, lfs 16, ws 1NCIA: create circuit: saddr 4000.1060.1000, ssap 4, daddr 4000.3000.0003, dsap 8 sid:8B09A8The next two messages indicate that an NDLC_DL_STARTED message is sent to a client. The server informs the client that a data link session is started.
NCIA: send NDLC_DL_STARTED to client 10.2.20.3 for ckt: 8B09A8NCIA(OUT): Ver_Id: 0x81, MsgType: NDLC_DL_STARTED, Len: 2,4 tmac: 4000.1060.1000,tsap: 4, csap 8, oid: 8A91E8, tid 8B09A8, lfs 16, ws 1In the following two messages, an NDLC_XID_FRAME message is received from a client, and the client starts an XID exchange:
NCIA(IN): Ver_Id: 0x81, MsgType: NDLC_XID_FRAME, Len: 12, sid: 8B09A8, FC 0x81NCIA: send NDLC_XID_FRAME to client 10.2.20.3 for ckt: 8B09A8In the following two messages, an NDLC_XID_FRAME message is sent from a client, and an DLC_XID_FRAME message is received from a client:
NCIA(OUT): Ver_Id: 0x81, MsgType: NDLC_XID_FRAME, Len: 12, sid: 8A91E8, FC 0xC1NCIA(IN): Ver_Id: 0x81, MsgType: NDLC_XID_FRAME, Len: 18, sid: 8B09A8, FC 0xC1The next two messages show that an NDLC_CONTACT_STN message is sent to a client:
NCIA: send NDLC_CONTACT_STN to client 10.2.20.3 for ckt: 8B09A8NCIA(OUT): Ver_Id: 0x81, MsgType: NDLC_CONTACT_STN, Len: 12, sid: 8A91E8, FC 0xC1In the following message, an NDLC_STN_CONTACTED message is received from a client. The client informs server that the station has been contacted.
NCIA(IN): Ver_Id: 0x81, MsgType: NDLC_STN_CONTACTED, Len: 12, sid: 8B09A8, FC 0xC1In the last two messages, an NDLC_INFO_FRAME is sent to a client, and the server sends data to the client:
NCIA: send NDLC_INFO_FRAME to client 10.2.20.3 for ckt: 8B09A8NCIA(OUT): Ver_Id: 0x81, MsgType: NDLC_INFO_FRAME, Len: 30, sid: 8A91E8, FC 0xC1shows sample debug ncia circuit flow-control output. In this example, the flow control in a session start-up sequence is displayed.
Figure 2-166 Sample Debug NCIA Circuit Flow-Control Output
router# debug ncia circuit flow-controlNCIA: no flow control in NDLC_DL_STARTED frameNCIA: receive Increment Window Op for circuit 8ADE00NCIA: ncia_flow_control_in FC 0x81, IW 1 GP 2 CW 2, Client IW 1 GP 0 CW 1NCIA: grant client more packet by sending Repeat Window OpNCIA: ncia_flow_control_out FC: 0xC1, IW 1 GP 2 CW 2, Client IW 1 GP 2 CW 2NCIA: receive FCA for circuit 8ADE00NCIA: receive Increment Window Op for circuit 8ADE00NCIA: ncia_flow_control_in FC 0xC1, IW 1 GP 5 CW 3, Client IW 1 GP 2 CW 2NCIA: grant client more packet by sending Repeat Window OpNCIA: ncia_flow_control_out FC: 0xC1, IW 1 GP 5 CW 3, Client IW 1 GP 5 CW 3NCIA: receive FCA for circuit 8ADE00NCIA: receive Increment Window Op for circuit 8ADE00NCIA: ncia_flow_control_in FC 0xC1, IW 1 GP 9 CW 4, Client IW 1 GP 5 CW 3NCIA: grant client more packet by sending Repeat Window OpNCIA: ncia_flow_control_out FC: 0xC1, IW 1 GP 8 CW 4, Client IW 1 GP 9 CW 4NCIA: reduce ClientGrantPacket by 1 (Granted: 8)NCIA: receive FCA for circuit 8ADE00NCIA: receive Increment Window Op for circuit 8ADE00describes the important fields shown in .
Table 2-76 Debug NCIA Circuit Flow-Control Field Descriptions
IW
Initial window size.
GP
Granted packet number.
CW
Current window size.
shows sample debug ncia circuit state output. In this example, a session start-up sequence is displayed.
Figure 2-167 Sample Debug NCIA Circuit State Output
router# debug ncia circuit stateNCIA: pre-server fsm: event CONN_OPENEDNCIA: pre-server fsm: event NDLC_PRIMITIVESNCIA: server event: WAN - STDL state: CLSOEDNCIA: ncia server fsm action 32NCIA: circuit state: CLOSED -> START_DL_RCVDNCIA: server event: DLU - TestStn.Rsp state: START_DL_RCVDNCIA: ncia server fsm action 17NCIA: circuit state: START_DL_RCVD -> DL_STARTED_SNDNCIA: pre-server fsm: event NDLC_PRIMITIVESNCIA: server event: WAN - XID state: DL_STARTED_SNDNCIA: ncia server fsm action 33NCIA: circuit state: DL_STARTED_SND -> DL_STARTED_SNDNCIA: server event: DLU - ReqOpnStn.Req state: DL_STARTED_SNDNCIA: ncia server fsm action 33NCIA: circuit state: DL_STARTED_SND -> OPENEDNCIA: server event: DLU - Id.Rsp state: OPENEDNCIA: ncia server fsm action 11NCIA: circuit state: OPENED -> OPENEDNCIA: pre-server fsm: event NDLC_PRIMITIVESNCIA: server event: WAN - XID state: OPENEDNCIA: ncia server fsm action 33NCIA: circuit state: OPENED -> OPENEDNCIA: server event: DLU - Connect.Req state: OPENEDNCIA: ncia server fsm action 6NCIA: circuit state: OPENED -> CONNECT_PENDINGNCIA: pre-server fsm: event NDLC_PRIMITIVESNCIA: server event: WAN - CONR state: CONNECT_PENDINGNCIA: ncia server fsm action 33 --> CLS_CONNECT_CNF sets NciaClsBusyNCIA: circuit state: CONNECT_PENDING -> CONNECTEDNCIA: server event: DLU - Flow.Req (START) state: CONNECTEDNCIA: ncia server fsm action 25 --> unset NciaClsBusyNCIA: circuit state: CONNECTED -> CONNECTEDNCIA: server event: DLU - Data.Rsp state: CONNECTEDNCIA: ncia server fsm action 8NCIA: circuit state: CONNECTED -> CONNECTEDdescribes the important fields shown in .
Related Commands
debug dlsw
debug ncia client
debug ncia serverdebug ncia client
Use the debug ncia client EXEC command to display debug information for all native client interface architecture (NCIA) client processing that occurs in the router. The no form of this command disables debugging output.
[no] debug ncia client [ip-address | error [ip-address] | event [ip-address] | message [ip-address]]
Syntax Description
Usage Guidelines
NCIA is an architecture developed by Cisco for accessing SNA applications. This architecture allows native SNA interfaces on hosts and clients to access TCP/IP backbones.
Use the debug ncia client event command to determine the sequences of activities that occur while a NCIA client is in different processing states.
Use the debug ncia client error command to see only certain error conditions that occur.
Use the debug ncia client message command to see only the first 32 bytes of data in a TCP packet sent to or received from an NCIA client.
The debug ncia client command can be used in conjunction with the debug ncia server and debug ncia circuit commands to get a complete picture of NCIA activity.
Sample Display
shows sample debug ncia circuit output. Following the example is a description of each sample output message.
Figure 2-168 Sample Debug NCIA Circuit Output
router# debug ncia clientNCIA: Passive open 10.2.20.123(1088) -> 1973NCIA: index for client hash queue is 27NCIA: number of element in client hash queue 27 is 1NCIA: event PASSIVE_OPEN, state NCIA_CLOSED for client 10.2.20.123NCIA: Rcvd msg type NDLC_CAP_XCHG in tcp packet for client 10.2.20.123NCIA: First 17 byte of data rcvd: 811200110000000000000400050104080CNCIA: Sent msg type NDLC_CAP_XCHG in tcp packet to client 10.2.20.123NCIA: First 17 byte of data sent: 811200111000000010000400050104080CNCIA: event CAP_CMD_RCVD, state NCIA_CAP_WAIT, for client 10.2.20.123, cap xchg cmd sentNCIA: Rcvd msg type NDLC_CAP_XCHG in tcp packet for client 10.2.20.123NCIA: First 17 byte of data rcvd: 811200111000000010000000050104080CNCIA: event CAP_RSP_RCVD, state NCIA_CAP_NEG for client 10.2.20.123NCIA: Rcvd msg type NDLC_PEER_TEST_REQ in tcp packet for client 10.2.20.123NCIA: First 4 byte of data rcvd: 811D0004NCIA: event KEEPALIVE_RCVD, state NCIA_OPENED for client 10.2.20.123NCIA: Sent msg type NDLC_PEER_TEST_RSP in tcp packet to client 10.2.20.123NCIA: First 4 byte of data sent: 811E0004IANCIA: event TIME_OUT, state NCIA_OPENED, for client 10.2.20.123, keepalive_count = 0NCIA: Sent msg type NDLC_PEER_TEST_REQ, in tcp packet to client 10.2.20.123NCIA: First 4 byte of data sent: 811D0004NCIA: Rcvd msg type NDLC_PEER_TEST_RSP in tcp packet for client 10.2.20.123NCIA: First 4 byte of data rcvd: 811E0004NCIA: event KEEPALIVE_RSP_RCVD, state NCIA_OPENED for client 10.2.20.123NCIA: Error, event PASIVE_OPEN, state NCIA_OPENED, for client 10.2.20.123, should not have occured.NCIA: Error, active_open for pre_client_fsm while client 10.2.20.123 is active or not configured, registered.Messages 1 through 12 show the events that occur when a client connects to the router (the NCIA server). These messages show a passive_open process.
Messages 13 to 17 show the events that occur when a TIME_OUT event is detected by a client PC workstation. The workstation sends an NDLC_PEER_TEST_REQ message to the NCIA server, and the router responds with an NDLC_PEER_TEST_RSP message.
Messages 18 to 23 show the events that occur when a TIME_OUT event is detected by the router (the NCIA server). The router sends an NDLC_PEER_TEST_REQ message to the client PC workstation, and the PC responds with an NDLC_PEER_TEST_RSP message.
When you use the debug ncia client message command, the messages shown on lines 6, 8, 11, 14, 17, 20, and 22 are output in addition to other messages not shown in this example.
When you use the debug ncia client error command, the messages shown on lines 24 and 25 are output in addition to other messages not shown in this example.
Related Commands
debug ncia circuit
debug ncia serverdebug ncia server
Use the debug ncia server EXEC command to display debug information for the native client interface architecture (NCIA) server and its upstream software modules. The no form of this command disables debugging output.
[no] debug ncia server
Usage Guidelines
NCIA is an architecture developed by Cisco for accessing SNA applications. This architecture allows native SNA interfaces on hosts and clients to access TCP/IP backbones.
The debug ncia server command displays all Cisco Link Services (CLS) messages between the NCIA server and its upstream modules, such as data-link switching (DLSw) and downstream physical units (DSPUs). Use this command when a problem exists between the NCIA server and other software modules within the router.
You cannot enable debugging output for a particular client or particular circuit.
Sample Display
shows sample debug ncia server output. In this example, a session start-up sequence is displayed. Following the example is a description of each group of sample output messages.
Figure 2-169 Sample Debug NCIA Server Output
router# debug ncia serverNCIA: send CLS_TEST_STN_IND to DLUNCIA: Receive TestStn.RspNCIA: send CLS_ID_STN_IND to DLUNCIA: Receive ReqOpnStn.ReqNCIA: send CLS_REQ_OPNSTN_CNF to DLUNCIA: Receive Id.RspNCIA: send CLS_ID_IND to DLUNCIA: Receive Connect.ReqNCIA: send CLS_CONNECT_CNF to DLUNCIA: Receive Flow.ReqNCIA: Receive Data.ReqNCIA: send CLS_DATA_IND to DLUNCIA: send CLS_DISC_IND to DLUNCIA: Receive Disconnect.RspIn the following messages, the client is sending a test message to the host and the test message is received by the host:
NCIA: send CLS_TEST_STN_IND to DLUNCIA: Receive TestStn.RspIn the next message, the server is sending an XID message to the host.
NCIA: send CLS_ID_STN_IND to DLUIn the next two messages, the host opens the station and the server responds.
NCIA: Receive ReqOpnStn.ReqNCIA: send CLS_REQ_OPNSTN_CNF to DLUIn the following two messages, the client is performing an XID exchange with the host:
NCIA: Receive Id.RspNCIA: send CLS_ID_IND to DLUIn the next group of messages, the host attempts to establish a session with the client.
NCIA: Receive Connect.ReqNCIA: send CLS_CONNECT_CNF to DLUNCIA: Receive Flow.ReqIn the next two messages, the host sends data to the client.
NCIA: Receive Data.ReqNCIA: send CLS_DATA_IND to DLUIn the last two messages, the client closes the session.
NCIA: send CLS_DISC_IND to DLUNCIA: Receive Disconnect.RspRelated Commands
debug dlsw
debug ncia circuit
debug ncia clientdebug netbios error
Use the debug netbios error EXEC command to display information about Network Basic Input/Output System (NetBIOS) protocol errors. The no form of this command disables debugging output.
[no] debug netbios error
Usage Guidelines
For complete information on the NetBIOS process, use the debug netbios packet command along with the debug netbios error command.
Sample Display
Figure 2-170 shows sample debug netbios error output. This example shows that an illegal packet has been received on the async interface.
Figure 2-170 Sample Debug NetBIOS Error Output
router# debug netbios errorNETBIOS: NetBIOS protocol errors debugging is onAsync1 nbf Bad packetRelated Commands
debug netbios-name-cache
debug netbios packetdebug netbios-name-cache
Use the debug netbios-name-cache EXEC command to display name caching activities on a router. The no form of this command disables debugging output.
[no] debug netbios-name-cache
Usage Guidelines
Examine the display to diagnose problems in NetBIOS name caching.
Sample Display
illustrates a collection of sample debug netbios-name-cache output listings.
Figure 2-171 Sample Debug NetBIOS-Name-Cache Output
router# debug netbios-name-cacheNETBIOS: L checking name ORINDA, vrn=0NetBIOS name cache table corrupted at offset 13NetBIOS name cache table corrupted at later offset, at location 13NETBIOS: U chk name=ORINDA, addr=1000.4444.5555, idb=TR1, vrn=0, type=1NETBIOS: U upd name=ORINDA,addr=1000.4444.5555,idb=TR1,vrn=0,type=1NETBIOS: U add name=ORINDA,addr=1000.4444.5555,idb=TR1,vrn=0,type=1NETBIOS: U no memory to add cache entry. name=ORINDA,addr=1000.4444.5555NETBIOS: Invalid structure detected in netbios_name_cache_agerNETBIOS: flushed name=ORINDA, addr=1000.4444.5555NETBIOS: expired name=ORINDA, addr=1000.4444.5555NETBIOS: removing entry. name=ORINDA,addr=1000.4444.5555,idb=TR1,vrn=0NETBIOS: Tossing ADD_NAME/STATUS/NAME/ADD_GROUP frameNETBIOS: Lookup Failed -- not in cacheNETBIOS: Lookup Worked, but split horizon failedNETBIOS: Could not find RIF entryNETBIOS: Cannot duplicate packet in netbios_name_cache_proxy
Note
describes selected debug netbios-name-cache output fields.
The following discussion briefly outlines each line shown in the example provided in .
With the first line of output, the router declares that it has examined the NetBIOS name cache table for the machine name ORINDA and that the packet that prompted the lookup came from virtual ring 0. In this case, this packet comes from a real interface—virtual ring number 0 is not valid.
NETBIOS: L checking name ORINDA, vrn=0The following two lines indicate that an invalid NetBIOS entry exists and that the corrupted memory was detected. The invalid memory will be removed from the table; no action is needed.
NetBIOS name cache table corrupted at offset 13NetBIOS name cache table corrupted at later offset, at location 13The following line indicates that the router attempted to check the NetBIOS cache table for the name ORINDA with MAC address 1000.4444.5555. This name was obtained from Token Ring interface 1. The type field indicates that the name was learned from traffic.
NETBIOS: U chk name=ORINDA, addr=1000.4444.5555, idb=TR1, vrn=0, type=1The following line indicates that the NetBIOS name ORINDA is in the name cache table and was updated to the current value:
NETBIOS: U upd name=ORINDA,addr=1000.4444.5555,idb=TR1,vrn=0,type=1The following line indicates that the NetBIOS name ORINDA is not in the table and must be added to the table:
NETBIOS: U add name=ORINDA,addr=1000.4444.5555,idb=TR1,vrn=0,type=1The following line indicates that there was insufficient cache buffer space when the router tried to add this name:
NETBIOS: U no memory to add cache entry. name=ORINDA,addr=1000.4444.5555The following line indicates that the NetBIOS ager detects an invalid memory in the cache. The router clears the entry; no action is needed.
NETBIOS: Invalid structure detected in netbios_name_cache_agerThe following line indicates that the entry for ORINDA was flushed from the cache table:
NETBIOS: flushed name=ORINDA, addr=1000.4444.5555The following line indicates that the entry for ORINDA timed out and was flushed from the cache table:
NETBIOS: expired name=ORINDA, addr=1000.4444.5555The following line indicates that the router removed the ORINDA entry from its cache table:
NETBIOS: removing entry. name=ORINDA,addr=1000.4444.5555,idb=TR1,vrn=0The following line indicates that the router discarded a NetBIOS packet of type ADD_NAME, STATUS, NAME_QUERY, or ADD_GROUP. These packets are discarded when multiple copies of one of these packet types are detected during a certain period of time.
NETBIOS: Tossing ADD_NAME/STATUS/NAME/ADD_GROUP frameThe following line indicates that the system could not find a NetBIOS name in the cache:
NETBIOS: Lookup Failed -- not in cacheThe following line indicates that the system found the destination NetBIOS name in the cache, but located on the same ring from which the packet came. The router will drop this packet because the packet should not leave this ring.
NETBIOS: Lookup Worked, but split horizon failedThe following line indicates that the system found the NetBIOS name in the cache, but the router could not find the corresponding RIF. The packet will be sent as a broadcast frame.
NETBIOS: Could not find RIF entryThe following line indicates that no buffer was available to create a NetBIOS name-cache proxy. A proxy will not be created for the packet, which will be forwarded as a broadcast frame.
NETBIOS: Cannot duplicate packet in netbios_name_cache_proxyRelated Commands
debug netbios error
debug netbios packetdebug netbios packet
Use the debug netbios packet EXEC command to display general information about NetBIOS packets. The no form of this command disables debugging output.
[no] debug netbios packet
Usage Guidelines
For complete information on the NetBIOS process, use the debug netbios error command along with the debug netbios packet command.
Sample Display
Figure 2-172 shows sample debug netbios packet and debug netbios error output. This example shows the LLC header for an asynchronous interface followed by the NetBIOS information. For additional information on the NetBIOS fields, refer to IBM LAN Technical Reference IEEE 802.2.
Figure 2-172 Sample Debug NetBIOS Packet Output
router# debug netbios packetNETBIOS: NetBIOS packet display debugging is onAsync1 (i) U-format UI C_R=0x0(i) NETBIOS_ADD_NAME_QUERYResp_correlator= 0x6F 0x0Src name=CS-NT-1Async1 (i) U-format UI C_R=0x0(i) NETBIOS_ADD_GROUP_QUERYResp_correlator= 0x6F 0x0Src name=COMMSERVER-WGAsync1 (i) U-format UI C_R=0x0(i) NETBIOS_ADD_NAME_QUERYResp_correlator= 0x6F 0x0Src name=CS-NT-1Ethernet0 (i) U-format UI C_R=0x0(i) NETBIOS_DATAGRAMLength= 0x2C 0x0Dest name=COMMSERVER-WGSrc name=CS-NT-3Related Commands
debug netbios error
debug netbios-name-cachedebug nhrp
Use the debug nhrp EXEC command to display information about Next Hop Resolution Protocol (NHRP) activity. The no form of this command disables debugging output.
[no] debug nhrp
Usage Guidelines
Use this command when some nodes on a TCP/IP or IPX network are not responding. It shows whether the router is sending or receiving NHRP packets.
Sample Display
Figure 2-173 shows sample debug nhrp output.
Figure 2-173 Sample Debug NHRP Output
router# debug nhrpNHRP: Cache update 172.19.145.57 NoneNHRP: Sent request src 172.19.145.56 dst 255.255.255.255NHRP M: id 0 src 172.19.145.56 dst 172.19.145.57NHRP: Encapsulation succeeded. MAC addr ffff.ffff.ffff.NHRP: O 86 bytes out Ethernet1 dest 255.255.255.255NHRP: Recv reply Size 64NHRP M: id 0 src 172.19.145.56 dst 172.19.145.57NHRP: Cache update 172.19.145.57 0000.0c14.59d3.describes the fields shown in the display.
Related Commands
debug nhrp options
debug nhrp ratedebug nhrp options
Use the debug nhrp options EXEC command to display information about NHRP option processing. The no form of this command disables debugging output.
[no] debug nhrp options
Usage Guidelines
Use this command to show you whether there are problems or error situations with NHRP option processing (for example, unknown options).
Sample Display
Figure 2-174 shows sample debug nhrp options output.
Figure 2-174 Sample Debug NHRP Options Output
router# debug nhrp optionsNHRP-OPT: MASK 4NHRP-OPT-MASK: FFFFFFFFNHRP-OPT: NETID 4NHRP-OPT: RESPONDER 4NHRP-OPT: RECORD 0NHRP-OPT: RRECORD 0describes the fields shown in the display.
Related Commands
debug nhrp rate
Use the debug nhrp rate EXEC command to display information about NHRP traffic rate limits. The no form of this command disables debugging output.
[no] debug nhrp rate
Usage Guidelines
Use this command to verify that the traffic is consistent with the setting of the NHRP commands (such as ip nhrp use and ip max-send commands).
Sample Display
Figure 2-175 shows sample debug nhrp rate output.
Figure 2-175 Sample Debug NHRP Rate Output
router# debug nhrp rateNHRP-RATE: Sending initial requestNHRP-RATE: Retransmitting request (retrans ivl 2)NHRP-RATE: Retransmitting request (retrans ivl 4)NHRP-RATE: Ethernet1: Used 3describes the fields shown in the display.
Related Commands
debug packet
Use the debug packet EXEC command to display information on packets that the network can not classify. The no form of this command disables debugging output.
[no] debug packet
Sample Display
shows sample debug packet output.
Figure 2-176 Sample Debug Packet Output
router# debug packetEthernet0: Unknown ARPA, src 0000.0c00.6fa4, dst ffff.ffff.ffff, type 0x0a0data 00000c00f23a00000c00ab45, len 60Serial3: Unknown HDLC, size 64, type 0xaaaa, flags 0x0F00Serial2: Unknown PPP, size 128Serial7: Unknown FRAME-RELAY, size 174, type 0x5865, DLCI 7aSerial0: compressed TCP/IP packet droppeddescribes significant fields shown in .
debug ppp
Use the debug ppp EXEC command to display information on traffic and exchanges in an internetwork implementing the Point-to-Point Protocol (PPP). The no form of this command disables debugging output.
[no] debug ppp {packet | negotiation | error | authentication}
Syntax Description
Usage Guidelines
Use the debug ppp commands when trying to find the following:
•
•
•
•
•
•
Refer to Internet RFCs 1331, 1332, and 1333 for details concerning PPP-related nomenclature and protocol information.
Sample Displays
shows sample debug ppp packet output as seen from the Link Quality Monitor (LQM) side of the connection. This display example depicts packet exchanges under normal PPP operation.
Figure 2-177 Sample Debug PPP Packet Output
router# debug ppp packetPPP Serial4(o): lcp_slqr() state = OPEN magic = D21B4, len = 48PPP Serial4(i): pkt type 0xC025, datagramsize 52PPP Serial4(i): lcp_rlqr() state = OPEN magic = D3454, len = 48PPP Serial4(i): pkt type 0xC021, datagramsize 16PPP Serial4: I LCP ECHOREQ(9) id 3 (C) magic D3454PPP Serial4: input(C021) state = OPEN code = ECHOREQ(9) id = 3 len = 12PPP Serial4: O LCP ECHOREP(A) id 3 (C) magic D21B4PPP Serial4(o): lcp_slqr() state = OPEN magic = D21B4, len = 48PPP Serial4(i): pkt type 0xC025, datagramsize 52PPP Serial4(i): lcp_rlqr() state = OPEN magic = D3454, len = 48PPP Serial4(i): pkt type 0xC021, datagramsize 16PPP Serial4: I LCP ECHOREQ(9) id 4 (C) magic D3454PPP Serial4: input(C021) state = OPEN code = ECHOREQ(9) id = 4 len = 12PPP Serial4: O LCP ECHOREP(A) id 4 (C) magic D21B4PPP Serial4(o): lcp_slqr() state = OPEN magic = D21B4, len = 48PPP Serial4(i): pkt type 0xC025, datagramsize 52PPP Serial4(i): lcp_rlqr() state = OPEN magic = D3454, len = 48PPP Serial4(i): pkt type 0xC021, datagramsize 16PPP Serial4: I LCP ECHOREQ(9) id 5 (C) magic D3454PPP Serial4: input(C021) state = OPEN code = ECHOREQ(9) id = 5 len = 12PPP Serial4: O LCP ECHOREP(A) id 5 (C) magic D21B4PPP Serial4(o): lcp_slqr() state = OPEN magic = D21B4, len = 48PPP Serial4(i): pkt type 0xC025, datagramsize 52PPP Serial4(i): lcp_rlqr() state = OPEN magic = D3454, len = 48PPP Serial4(i): pkt type 0xC021, datagramsize 16PPP Serial4: I LCP ECHOREQ(9) id 6 (C) magic D3454PPP Serial4: input(C021) state = OPEN code = ECHOREQ(9) id = 6 len = 12PPP Serial4: O LCP ECHOREP(A) id 6 (C) magic D21B4PPP Serial4(o): lcp_slqr() state = OPEN magic = D21B4, len = 48PPP Serial4(i): pkt type 0xC025, datagramsize 52PPP Serial4(i): lcp_rlqr() state = OPEN magic = D3454, len = 48PPP Serial4(i): pkt type 0xC021, datagramsize 16PPP Serial4: I LCP ECHOREQ(9) id 7 (C) magic D3454PPP Serial4: input(C021) state = OPEN code = ECHOREQ(9) id = 7 len = 12PPP Serial4: O LCP ECHOREP(A) id 7 (C) magic D21B4PPP Serial4(o): lcp_slqr() state = OPEN magic = D21B4, len = 48describes significant fields shown in .
To elaborate on the displayed output, consider the partial exchange in . This sequence shows that one side is using ECHO for its keepalives and the other side is using LQRs.
Figure 2-178 Sample Debug PPP Packet Output—Keepalive Messages
PPP Serial4(o): lcp_slqr() state = OPEN magic = D21B4, len = 48PPP Serial4(i): pkt type 0xC025, datagramsize 52PPP Serial4(i): lcp_rlqr() state = OPEN magic = D3454, len = 48PPP Serial4(i): pkt type 0xC021, datagramsize 16PPP Serial4: I LCP ECHOREQ(9) id 3 (C) magic D3454PPP Serial4: input(C021) state = OPEN code = ECHOREQ(9) id = 3 len = 12PPP Serial4: O LCP ECHOREP(A) id 3 (C) magic D21B4PPP Serial4(o): lcp_slqr() state = OPEN magic = D21B4, len = 48The following discussion briefly outlines each line of this exchange.
The first line states that the router with debugging enabled has sent an LQR to the other side of the PPP connection:
PPP Serial4(o): lcp_slqr() state = OPEN magic = D21B4, len = 48The next two lines indicate that the router has received a packet of type C025 (LQM) and provides details about the packet:
PPP Serial4(i): pkt type 0xC025, datagramsize 52PPP Serial4(i): lcp_rlqr() state = OPEN magic = D3454, len = 48The next two lines indicate that the router received an ECHOREQ of type C021 (LCP). The other side is sending ECHOs. The router on which debugging is configured for LQM but also responds to ECHOs.
PPP Serial4(i): pkt type 0xC021, datagramsize 16PPP Serial4: I LCP ECHOREQ(9) id 3 (C) magic D3454Next the router is detected to have responded to the ECHOREQ with an ECHOREP and is preparing to send out an LQR:
PPP Serial4: O LCP ECHOREP(A) id 3 (C) magic D21B4PPP Serial4(o): lcp_slqr() state = OPEN magic = D21B4, len = 48shows sample debug ppp negotiation output. This is a normal negotiation, where both sides agree on network control program (NCP) parameters. In this case, protocol type IP is proposed and acknowledged.
Figure 2-179 Sample Debug PPP Negotiation Output
router# debug ppp negotiationppp: sending CONFREQ, type = 4 (CI_QUALITYTYPE), value = C025/3E8ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 3D56CACppp: received config for type = 4 (QUALITYTYPE) ackedppp: received config for type = 5 (MAGICNUMBER) value = 3D567F8 acked (ok)PPP Serial4: state = ACKSENT fsm_rconfack(C021): rcvd id 5ppp: config ACK received, type = 4 (CI_QUALITYTYPE), value = C025ppp: config ACK received, type = 5 (CI_MAGICNUMBER), value = 3D56CACppp: ipcp_reqci: returning CONFACK.(ok)PPP Serial4: state = ACKSENT fsm_rconfack(8021): rcvd id 4describes significant fields shown in .
The following discussion briefly outlines each line shown in the example provided in .
The first two lines in indicate that the router is trying to bring up LCP and will use the indicated negotiation options (Quality Protocol and Magic Number). The value fields are the values of the options themselves. C025/3E8 translates to Quality Protocol LQM. 3E8 is the reporting period (in hundredths of a second). 3D56CAC is the value of the Magic Number for the router.
ppp: sending CONFREQ, type = 4 (CI_QUALITYTYPE), value = C025/3E8ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 3D56CACThe next two lines indicate that the other side negotiated for options 4 and 5 as requested and acknowledged both. If the responding end does not support the options, a CONFREJ is sent by the responding node. If the responding end does not accept the value of the option, a CONFNAK is sent with the value field modified.
ppp: received config for type = 4 (QUALITYTYPE) ackedppp: received config for type = 5 (MAGICNUMBER) value = 3D567F8 acked (ok)The next three lines indicate that the router received a CONFACK from the responding side and displays accepted option values. Use the rcvd id field to verify that the CONFREQ and CONFACK have the same id field.
PPP Serial4: state = ACKSENT fsm_rconfack(C021): rcvd id 5ppp: config ACK received, type = 4 (CI_QUALITYTYPE), value = C025ppp: config ACK received, type = 5 (CI_MAGICNUMBER), value = 3D56CACThe next line indicates that the router has IP routing enabled on this interface and that the IPCP NCP negotiated successfully:
ppp: ipcp_reqci: returning CONFACK.In the last line, the router's state is listed as ACKSENT.
PPP Serial4: state = ACKSENT fsm_rconfack(C021): rcvd id 5\shows sample output when debug ppp packet and debug ppp negotiation output are enabled at the same time.
Figure 2-180 Sample Debug PPP Output—Packet and Negotiation Options Enabled
shows sample debug ppp negotiation output when the remote side of the connection is unable to respond to LQM requests.
Figure 2-181 Sample Debug PPP Negotiation Output—No Response Detected
router# debug ppp negotiationppp: sending CONFREQ, type = 4 (CI_QUALITYTYPE), value = C025/3E8ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 44B7010ppp: sending CONFREQ, type = 4 (CI_QUALITYTYPE), value = C025/3E8ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 44B7010ppp: sending CONFREQ, type = 4 (CI_QUALITYTYPE), value = C025/3E8ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 44B7010ppp: sending CONFREQ, type = 4 (CI_QUALITYTYPE), value = C025/3E8ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 44B7010ppp: sending CONFREQ, type = 4 (CI_QUALITYTYPE), value = C025/3E8ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 44B7010ppp: sending CONFREQ, type = 4 (CI_QUALITYTYPE), value = C025/3E8ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 44B7010ppp: sending CONFREQ, type = 4 (CI_QUALITYTYPE), value = C025/3E8ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 44B7010ppp: sending CONFREQ, type = 4 (CI_QUALITYTYPE), value = C025/3E8ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 44B7010ppp: sending CONFREQ, type = 4 (CI_QUALITYTYPE), value = C025/3E8ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 44B7010ppp: sending CONFREQ, type = 4 (CI_QUALITYTYPE), value = C025/3E8ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 44B7010ppp: sending CONFREQ, type = 4 (CI_QUALITYTYPE), value = C025/3E8ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 44B7010ppp: sending CONFREQ, type = 4 (CI_QUALITYTYPE), value = C025/3E8ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 44C1488shows sample output when no response is detected for configuration requests (with both debug ppp negotiation and debug ppp packet enabled).
Figure 2-182 Sample Debug PPP Negotiation and Packet Output—No Response Detected
router# debug ppp negotiationrouter# debug ppp packetppp: sending CONFREQ, type = 4 (CI_QUALITYTYPE), value = C025/3E8ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 44DFDC8PPP Serial4: O LCP CONFREQ(1) id 14 (12) QUALITYTYPE (8) 192 37 0 0 3 232MAGICNUMBER (6) 4 77 253 200ppp: TIMEout: Time= 44E0980 State= 3ppp: sending CONFREQ, type = 4 (CI_QUALITYTYPE), value = C025/3E8ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 44DFDC8PPP Serial4: O LCP CONFREQ(1) id 15 (12) QUALITYTYPE (8) 192 37 0 0 3 232MAGICNUMBER (6) 4 77 253 200ppp: TIMEout: Time= 44E1828 State= 3ppp: sending CONFREQ, type = 4 (CI_QUALITYTYPE), value = C025/3E8ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 44DFDC8PPP Serial4: O LCP CONFREQ(1) id 16 (12) QUALITYTYPE (8) 192 37 0 0 3 232MAGICNUMBER (6) 4 77 253 200ppp: TIMEout: Time= 44E27C8 State= 3ppp: sending CONFREQ, type = 4 (CI_QUALITYTYPE), value = C025/3E8ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 44DFDC8PPP Serial4: O LCP CONFREQ(1) id 17 (12) QUALITYTYPE (8) 192 37 0 0 3 232MAGICNUMBER (6) 4 77 253 200ppp: TIMEout: Time= 44E3768 State= 3shows sample debug ppp error output. These messages might appear when the Quality Protocol option is enabled on an interface that is already running PPP.
Figure 2-183 Sample Debug PPP Error Output
router# debug ppp errorPPP Serial3(i): rlqr receive failure. successes = 15PPP: myrcvdiffp = 159 peerxmitdiffp = 41091PPP: myrcvdiffo = 2183 peerxmitdiffo = 1714439PPP: threshold = 25PPP Serial4(i): rlqr transmit failure. successes = 15PPP: myxmitdiffp = 41091 peerrcvdiffp = 159PPP: myxmitdiffo = 1714439 peerrcvdiffo = 2183PPP: l->OutLQRs = 1 LastOutLQRs = 1PPP: threshold = 25PPP Serial3(i): lqr_protrej() Stop sending LQRs.PPP Serial3(i): The link appears to be looped back.describes significant fields shown in .
shows sample debug ppp authentication output. Use this debug command to determine why an authentication fails.
Figure 2-184 Sample Debug PPP Authentication Output
router# debug ppp authenticationSerial0: Unable to authenticate. No name received from peerSerial0: Unable to validate CHAP response. USERNAME pioneer not found.Serial0: Unable to validate CHAP response. No password defined for USERNAME pioneerSerial0: Failed CHAP authentication with remote.Remote message is Unknown nameSerial0: remote passed CHAP authentication.Serial0: Passed CHAP authentication with remote.Serial0: CHAP input code = 4 id = 3 len = 48In general, these messages are self-explanatory. Fields that appear in debug ppp authentication displays that can show optional output are outlined in .
debug ppp multilink
Use the debug ppp multilink EXEC command to display information about individual multilink fragments and important multilink events. The no form of this command disables debugging output.
[no] debug ppp multilink
Usage Guidelines
The debug ppp multilink command has some memory overhead and should not be used when memory is scarce or in very high traffic situations.
Sample Display
Figure 2-185 shows sample debug ppp multilink output when this command is used with the ping command. The debug output indicates that a multilink PPP packet on interface BRI 0 (on the B channel) is an input (I) or output (O) packet. The output also identifies the sequence number of the packet and the size of the fragment.
Figure 2-185 Sample Debug PPP Multilink Output
router# debug ppp multilinkrouter# ping 7.1.1.7Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 7.1.1.7, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 32/34/36 msrouter#2:00:28: MLP BRI0: B-Channel 1: O seq 80000000: size 582:00:28: MLP BRI0: B-Channel 2: O seq 40000001: size 592:00:28: MLP BRI0: B-Channel 2: I seq 40000001: size 592:00:28: MLP BRI0: B-Channel 1: I seq 80000000: size 582:00:28: MLP BRI0: B-Channel 1: O seq 80000002: size 582:00:28: MLP BRI0: B-Channel 2: O seq 40000003: size 592:00:28: MLP BRI0: B-Channel 2: I seq 40000003: size 592:00:28: MLP BRI0: B-Channel 1: I seq 80000002: size 582:00:28: MLP BRI0: B-Channel 1: O seq 80000004: size 582:00:28: MLP BRI0: B-Channel 2: O seq 40000005: size 592:00:28: MLP BRI0: B-Channel 2: I seq 40000005: size 592:00:28: MLP BRI0: B-Channel 1: I seq 80000004: size 582:00:28: MLP BRI0: B-Channel 1: O seq 80000006: size 582:00:28: MLP BRI0: B-Channel 2: O seq 40000007: size 592:00:28: MLP BRI0: B-Channel 2: I seq 40000007: size 592:00:28: MLP BRI0: B-Channel 1: I seq 80000006: size 582:00:28: MLP BRI0: B-Channel 1: O seq 80000008: size 582:00:28: MLP BRI0: B-Channel 2: O seq 40000009: size 592:00:28: MLP BRI0: B-Channel 2: I seq 40000009: size 592:00:28: MLP BRI0: B-Channel 1: I seq 80000008: size 58debug qllc error
Use the debug qllc error EXEC command to display quality link line control (QLLC) errors. The no form of this command disables debugging output.
[no] debug qllc error
Usage Guidelines
This command helps you track down errors in the QLLC interactions with X.25 networks. Use debug qllc error in conjunction with debug x25 all to see the connection. The data shown by this command only flows through the router on the X.25 connection. Some forms of this command can generate lots of output and network traffic.
Sample Display
shows sample debug qllc error output.
Figure 2-186 Sample Debug QLLC Error Output
router# debug qllc error%QLLC-3-GENERRMSG: qllc_close - bad qllc pointer Caller 00407116 Caller 00400BD2QLLC 4000.1111.0002: NO X.25 connection. Dicarding XID and calling outExplanations for individual lines of output from follow.
The following line indicates that the QLLC connection was closed:
%QLLC-3-GENERRMSG: qllc_close - bad qllc pointer Caller 00407116 Caller 00400BD2The following line shows the virtual MAC address of the failed connection:
QLLC 4000.1111.0002: NO X.25 connection. Dicarding XID and calling outdebug qllc event
Use the debug qllc event EXEC command to enable debugging of QLLC events. The no form of this command disables debugging output.
[no] debug qllc event
Usage Guidelines
Use the debug qllc event command to display primitives that might affect the state of a QLLC connection. An example of these events is the allocation of a QLLC structure for a logical channel indicator when an X.25 call has been accepted with the QLLC call user data. Other examples are the receipt and transmission of LAN explorer and XID frames.
Sample Display
shows sample debug qllc event output.
Figure 2-187 Sample Debug QLLC Event Output
router# debug qllc eventQLLC: allocating new qllc lci 9QLLC: tx POLLING TEST, da 4001.3745.1088, sa 4000.1111.0001QLLC: rx explorer response, da 4000.1111.0001, sa c001.3745.1088, rif 08B0.1A91.1901.A040QLLC: gen NULL XID, da c001.3745.1088, sa 4000.1111.0001, rif 0830.1A91.1901.A040, dsap 4, ssap 4QLLC: rx XID response, da 4000.1111.0001, sa c001.3745.1088, rif 08B0.1A91.1901.A040Explanations for representative lines of output in follow.
The following line indicates a new QLLC data structure has been allocated:
QLLC: allocating new qllc lci 9The following lines show transmission and receipt of LAN explorer or test frames:
QLLC: tx POLLING TEST, da 4001.3745.1088, sa 4000.1111.0001QLLC: rx explorer response, da 4000.1111.0001, sa c001.3745.1088, rif 08B0.1A91.1901.A040The following lines show XID events:
QLLC: gen NULL XID, da c001.3745.1088, sa 4000.1111.0001, rif 0830.1A91.1901.A040, dsap 4, ssap 4QLLC: rx XID response, da 4000.1111.0001, sa c001.3745.1088, rif 08B0.1A91.1901.A040debug qllc packet
Use the debug qllc packet EXEC command to display QLLC events and QLLC data packets. The no form of this command disables debugging output.
[no] debug qllc packet
Usage Guidelines
This command helps you to track down errors in the QLLC interactions with X.25 networks. The data shown by this command only flows through the router on the X25 connection. Use debug qllc packet in conjunction with debug x25 all to see the connection and the data that flows through the router.
Sample Display
shows sample debug qllc packet output.
Figure 2-188 Sample Debug QLLC Packet Output
router# debug qllc packet14:38:05: Serial2/5 QLLC I: Data Packet.-RSP 9 bytes.14:38:07: Serial2/6 QLLC I: Data Packet.-RSP 112 bytes.14:38:07: Serial2/6 QLLC O: Data Packet. 128 bytes.14:38:08: Serial2/6 QLLC I: Data Packet.-RSP 9 bytes.14:38:08: Serial2/6 QLLC I: Data Packet.-RSP 112 bytes.14:38:08: Serial2/6 QLLC O: Data Packet. 128 bytes.14:38:08: Serial2/6 QLLC I: Data Packet.-RSP 9 bytes.14:38:12: Serial2/5 QLLC I: Data Packet.-RSP 112 bytes.14:38:12: Serial2/5 QLLC O: Data Packet. 128 bytes.Explanations for individual lines of output from follow.
The following lines indicate a packet was received on the interfaces:
14:38:05: Serial2/5 QLLC I: Data Packet.-RSP 9 bytes.14:38:07: Serial2/6 QLLC I: Data Packet.-RSP 112 bytes.The following lines show that a packet was transmitted on the interfaces:
14:38:07: Serial2/6 QLLC O: Data Packet. 128 bytes.14:38:12: Serial2/5 QLLC O: Data Packet. 128 bytes.debug qllc state
Use the debug qllc state EXEC command to enable debugging of the QLLC events. The no form of this command disables debugging output.
[no] debug qllc state
Usage Guidelines
Use the debug qllc state command to show when the state of a QLLC connection has changed. The typical QLLC connection goes from states ADM to SETUP to NORMAL. The NORMAL state indicates that a QLLC connection exists and is ready for data transfer.
Sample Display
shows sample debug qllc state output.
Figure 2-189 Sample Debug QLLC State Output
router# debug qllc stateSerial2 QLLC O: QSM-CMDSerial2: X25 O D1 DATA (5) Q 8 lci 9 PS 4 PR 3QLLC: state ADM -> SETUPSerial2: X25 I D1 RR (3) 8 lci 9 PR 5Serial2: X25 I D1 DATA (5) Q 8 lci 9 PS 3 PR 5Serial2 QLLC I: QUA-RSPQLLC: addr 00, ctl 73QLLC: qsetupstate: recvd qua rspQLLC: state SETUP -> NORMALExplanations for representative lines of output in follow.
The following line indicates a QLLC connection attempt is changing state from ADM to SETUP:
QLLC: state ADM -> SETUPThe following line indicates a QLLC connection attempt is changing state from SETUP to NORMAL:
QLLC: state SETUP -> NORMALdebug qllc timer
Use the debug qllc timer EXEC command to display QLLC timer events. The no form of this command disables debugging output.
[no] debug qllc timer
Usage Guidelines
The QLLC process periodically cycles and checks status of itself and its partner. If the partner is not found in the desired state, a LAPB primitive command is resent until the partner is in the desired state or the timer expires.
Sample Display
shows sample debug qllc timer output.
Figure 2-190 Sample Debug QLLC Timer Output
router# debug qllc timer14:27:24: Qllc timer lci 257, state ADM retry count 0 Caller 00407116 Caller 00400BD214:27:34: Qllc timer lci 257, state NORMAL retry count 014:27:44: Qllc timer lci 257, state NORMAL retry count 114:27:54: Qllc timer lci 257, state NORMAL retry count 1Explanations for individual lines of output from follow.
The following line of output shows the state of a QLLC partner on a given X.25 logical channel identifier:
14:27:24: Qllc timer lci 257, state ADM retry count 0 Caller 00407116 Caller 00400BD2Other messages are informational and appear every ten seconds.
debug qllc x25
Use the debug qllc x25 EXEC command to display X.25 packets that affect a QLLC connection. The no form of this command disables debugging output.
[no] debug qllc x25
Usage Guidelines
This command is helpful to track down errors in the QLLC interactions with X.25 networks. Use debug qllc x25 in conjunction with debug x25 events or debug x25 all to see the X.25 events between the router and its partner.
Sample Display
shows sample debug qllc x25 output.
Figure 2-191 Sample Debug QLLC X25 Output
router# debug qllc x25qllc x.25 events debugging is on15:07:23: QLLC X25 notify lci 257 event 115:07:23: QLLC X25 notify lci 257 event 515:07:34: QLLC X25 notify lci 257 event 3 Caller 00407116 Caller 00400BD215:07:35: QLLC X25 notify lci 257 event 4describes fields of output that appear in follow.
debug radius
Use the debug radius EXEC command to display information associated with the Remote Authentication Dial-In User Server (RADIUS). The no form of this command disables debugging output.
[no] debug radius
Usage Guidelines
RADIUS is a distributed security system that secures networks against unauthorized access. Cisco supports RADIUS under the Authentication, Authorization, and Accounting (AAA) security system.
Use the debug aaa authentication command to get a high-level view of login activity. When RADIUS is used on the router, you can use the debug radius command for more detailed debugging information.
Sample Displays
shows part of the debug aaa authentication command output for a RADIUS login attempt that failed. The information indicates that RADIUS is the authentication method used.
Figure 2-192 Sample Debug AAA Authentication Output—RADIUS Login Attempt
14:02:55: AAA/AUTHEN (164826761): Method=RADIUS14:02:55: AAA/AUTHEN (164826761): status = GETPASS14:03:01: AAA/AUTHEN/CONT (164826761): continue_login14:03:01: AAA/AUTHEN (164826761): status = GETPASS14:03:01: AAA/AUTHEN (164826761): Method=RADIUS14:03:04: AAA/AUTHEN (164826761): status = FAILshows part of the debug radius command output that shows a login attempt that failed because of a key mismatch (that is, a configuration problem).
Figure 2-193 Sample Debug RADIUS Output—Failed Login (Key Mismatch)
13:55:19: Radius: IPC Send 0.0.0.0:1645, Access-Request, id 0x7, len 5713:55:19: Attribute 4 6 AC150E5A13:55:19: Attribute 5 6 0000000A13:55:19: Attribute 1 7 62696C6C13:55:19: Attribute 2 18 19D6648313:55:22: Radius: Received from 171.69.1.152:1645, Access-Reject, id 0x7, len 2013:55:22: Radius: Reply for 7 fails decryptshows part of the debug radius command output that shows a successful login attempt as indicated by an Access-Accept message.
Figure 2-194 Sample Debug RADIUS Output—Successful Login
13:59:02: Radius: IPC Send 0.0.0.0:1645, Access-Request, id 0xB, len 5613:59:02: Attribute 4 6 AC150E5A13:59:02: Attribute 5 6 0000000A13:59:02: Attribute 1 6 62696C6C13:59:02: Attribute 2 18 0531FEA313:59:04: Radius: Received from 171.69.1.152:1645, Access-Accept, id 0xB, len 2613:59:04: Attribute 6 6 00000001shows part of the debug radius command output that shows an unsuccessful login attempt as indicated by the Access-Reject message.
Figure 2-195 Sample Debug RADIUS Output—Failed Login
13:57:56: Radius: IPC Send 0.0.0.0:1645, Access-Request, id 0xA, len 5713:57:56: Attribute 4 6 AC150E5A13:57:56: Attribute 5 6 0000000A13:57:56: Attribute 1 7 62696C6C13:57:56: Attribute 2 18 49C28F6C13:57:59: Radius: Received from 171.69.1.152:1645, Access-Reject, id 0xA, len 20Related Commands
debug aaa accounting
debug aaa authenticationdebug rif
Use the debug rif EXEC command to display information on entries entering and leaving the routing information field (RIF) cache. The no form of this command disables debugging output.
[no] debug rif
Usage Guidelines
In order to use the debug rif command to display traffic source-routed through an interface, fast switching of source route bridging (SRB) frames must first be disabled with the no source-bridge route-cache interface configuration command.
Sample Display
shows sample debug rif output.
Figure 2-196 Sample Debug RIF Output
Explanations for representative lines of debug rif output in follow.
The first line of output is an example of a RIF entry for an interface configured for SDLLC or Local-Ack. describes significant fields shown in this line of debug rif output.
The following line of output is an example of a RIF entry for an interface that is not configured for SDLLC or Local-Ack:
RIF: U chk da=0000.3080.4aed,sa=0000.0000.0000 [] type 8 on TokenRing0/0Notice that the source address contains only zero values (0000.0000.0000), and that the RIF string is null ([ ]). The last element in the entry indicates that this route was learned from a virtual ring, rather than a real Token Ring port.
The following line shows that a new entry has been added to the RIF cache:
RIF: U add 1000.5a59.04f9 [4880.3201.00A1.0050] type 8The following line shows that a RIF cache lookup operation has taken place:
RIF: L checking da=0000.3080.4aed, sa=0000.0000.0000The following line shows that a TEST response from address 9000.5a59.04f9 was inserted into the RIF cache:
RIF: rcvd TEST response from 9000.5a59.04f9The following line shows that the RIF entry for this route has been found and updated:
RIF: U upd da=1000.5a59.04f9,sa=0110.2222.33c1 [4880.3201.00A1.0050]The following line shows that an XID response from this address was inserted into the RIF cache:
RIF: rcvd XID response from 9000.5a59.04f9The following line shows that the router sent an XID response to this address:
SR1: sent XID response to 9000.5a59.04f9explains the other possible lines of debug rif output.
Related Command
debug rtr error
Use the debug rtr error EXEC command to enable logging of response time reporter runtime errors. The no form of this command disables debugging output—including the debug rtr trace command.
[no] debug rtr error [probe]
Syntax Description:
Usage Guidelines
The response time reporter feature allows you to monitor network performance and network resources by measuring response times and availability. With this feature you can perform troubleshooting, problem notifications, and preproblem analysis based on response time reporter statistics.
The debug rtr error command displays runtime errors. When a probe number other than 0 is specified, all runtime errors for that probe are displayed when the probe is active. When the probe number is 0, all runtime errors relating to the response time reporter scheduler process are displayed. When no probe number is specified, all runtime errors for all active probes configured on the router and probe control are displayed. The response time reporter scheduler process is responsible for starting and stopping probes and managing the database.
Note
Because the trace output generated by the debug rtr trace command uses the same control mechanism as debug rtr error, the no debug rtr error command disables both logging and tracing.
Sample Display
shows sample debug rtr error output. All debug output for the response time reporter (including debug rtr trace) has the format shown in .
Figure 2-197 Sample Debug RTR Error Output
router# debug rtr error 1RTR 1: Error Return Code - LU0 RTR Probe 1in echoTarget on call luReceiveLuApiReturnCode of InvalidHandle - invalid host name or API handleshows describes the fields and messages shown in .
Related Command
debug rtr trace
Use the debug rtr trace EXEC command to trace the execution of a response time reporter probe. The no form of this command disables trace debugging output (but not debug rtr error output).
[no] debug rtr [probe]
Syntax Description:
Usage Guidelines
Note
When a probe number other than 0 is specified, execution for that probe is traced. When the probe number is 0, the response time reporter scheduler process is traced. When no probe number is specified, all active probes and every probe control is traced. The response time reporter scheduler process is responsible for starting and stopping probes and managing the database.
The debug rtr trace command also enables debug rtr error for the specified probe. However, the no debug rtr trace command does not disable the debug rtr error command. You must manually disable the command by using the no debug rtr error command.
All debug output (including debug rtr error) has the format shown in the debug rtr error output example in .
Sample Display
shows a partial sample of debug rtr trace output. In this example, a probe is traced through a single operation attempt: the setup of a connection to the target (LU0), the attempt at an echo, and the closing of the connection on the echo attempt.
Figure 2-198 Sample Debug RTR Trace Output
router# debug rtrRTR 1: Calling getRttMonOperState (check pending) - LU0 RTR Probe 1RTR 1: Calling getRttMonOperState (check death) - LU0 RTR Probe 1RTR 1: Starting An Echo Operation - LU0 RTR Probe 1RTR 1: setting receiveFinished to FALSE - LU0 RTR Probe 1in dependLuEchoApplicationRTR 1: openConnection called - LU0 RTR Probe 1Calling rttMonHopConnectedRTR 1: calling luT0orT2Open - LU0 RTR Probe 1RTR 1: Dumping luT0orT2Open Result - LU0 RTR Probe 1applicationHandle: inRttMonCtrlAdminQItem = 13920808receiveFinished = FALSE currentLUHandle = 14199576maxRespBufferLen = 52 receivedBufferLen = 0aHostName = CWBC02 locAddr = 1 eApplNameLen = 7ApplName = D5E2D7C5C3C8D60 eModeName = 4040404040404040 userDataLen = 14userData = D5E2D7C5C3C8D61 sysSense = 0 userSense = 0 bindDataLen = 64bindData = D5E2D7C5C3C8D61 bindDataCount = 14RTR 1: Calling rttMonSetConnectionHandle - LU0 RTR Probe 1RTR 1: Calling rttMonSetHopConnectedState to TRUE - LU0 RTR Probe 1RTR 1: Calling rttMonSetDiagText - LU0 RTR Probe 1RTR 1: setupPathInfo called - LU0 RTR Probe 1Calling rttMonStartUpdatePathRTR 1: Calling rttMonUpdatePath - LU0 RTR Probe 1for Target CWBC02 NSPECHORTR 1: Calling rttMonEndUpdatePath - LU0 RTR Probe 1RTR 1: Calling rttMonUpdateNumberOfEchosAttempted - LU0 RTR Probe 1RTR 1: performEcho called - LU0 RTR Probe 1applicationHandle: inRttMonCtrlAdminQItem = 13920808receiveFinished = FALSE currentLUHandle = 14199576maxRespBufferLen = 52 receivedBufferLen = 0echoTimeout (milliseconds) = 5000 sequenceNum = 886rttMonEchoAdminTargetAddress is CWBC02 NSPECHOverifyDataFlag = FalseRTR 1: Calling rttMonGetFirstStoredHopAddress - LU0 RTR Probe 1RTR 1: echoTarget called - LU0 RTR Probe 1applicationHandle: inRttMonCtrlAdminQItem = 13920808receiveFinished = FALSE currentLUHandle = 14199576maxRespBufferLen = 52 receivedBufferLen = 0echoTimeout (milliseconds) = 5000Data:E6 A7 E8 A9 01 02 03 77 00 00 00 00 C1calling luReceive...RTR 1: calling luSend - LU0 RTR Probe 1RTR 1: receiveFinished is FALSE - LU0 RTR Probe 1in echoTarget callingprocess_wait_for_event_timed(5000 milliseconds)RTR 1: rtt_closeIndication called - DSPU Msg ProcapplicationHandle: inRttMonCtrlAdminQItem = 13920808receiveFinished = FALSE currentLUHandle = 14199576maxRespBufferLen = 52 receivedBufferLen = 0RTR 1: setting receiveFinished to TRUE - DSPU Msg Procin rtt_closeIndicationRTR 1: Woke on receive event - LU0 RTR Probe 1RTR 1: returned from echoTarget - LU0 RTR Probe 1with D_echoTarget_connectionLost return_codeand responseTime (milliseconds) = 196...RTR 1: Calling getRttMonOperState (check active) - LU0 RTR Probe 1RTR 1: Going to Sleep - LU0 RTR Probe 1until next frequency time (delta milliseconds 60000)Related Command
debug sdlc
Use the debug sdlc EXEC command to display information on Synchronous Data Link Control (SDLC) frames received and sent by any router serial interface involved in supporting SDLC end station functions. The no form of this command disables debugging output.
[no] debug sdlc
Usage Guidelines
Note
Sample Display
shows sample debug sdlc output.
Figure 2-199 Sample Debug SDLC Output
router# debug sdlcSDLC: Sending RR at location 4Serial3: SDLC O (12495952) C2 CONNECT (2) RR P/F 6Serial3: SDLC I (12495964) [C2] CONNECT (2) RR P/F 0 (R) [VR: 6 VS: 0]Serial3: SDLC T [C2] 12496064 CONNECT 12496064 0SDLC: Sending RR at location 4Serial3: SDLC O (12496064) C2 CONNECT (2) RR P/F 6Serial3: SDLC I (12496076) [C2] CONNECT (2) RR P/F 0 (R) [VR: 6 VS: 0]Serial3: SDLC T [C2] 12496176 CONNECT 12496176 0Explanations for individual lines of output from follow.
The following line of output indicates that the router is sending a Receiver Ready packet at location 4 in the code:
SDLC: Sending RR at location 4The following line of output describes a frame input event:
Serial3: SDLC O (12495952) C2 CONNECT (2) RR P/F 6describes the fields in this line of output.
The following line of output describes a frame input event:
Serial3: SDLC I (12495964) [C2] CONNECT (2) RR P/F 0 (R) [VR: 6 VS: 0] rfp: PIn addition to the fields described in , output for a frame input event also includes two additional fields, as described in .
The following line of output describes a frame timer event:
Serial3: SDLC T [C2] 12496064 CONNECT 12496064 0describes the fields in this line of output.
Related Command
debug sdlc local-ack
Use the debug sdlc local-ack EXEC command to display information on the local acknowledgment feature. The no form of this command disables debugging output.
[no] debug sdlc local-ack [number]
Syntax Description
This command has no arguments or keywords.
Usage Guidelines
You can select the frame types you want to monitor; the frame types correspond to bit flags. You can select 1, 2, 4, or 7, which is the decimal value of the bit flag settings. If you select 1, the octet is set to 00000001. If you select 2, the octet is set to 0000010. If you select 4, the octet is set to 00000100. If you want to select all frame types, select 7; the octet is 00000111. The default is 7 for all events. defines these bit flags.
CautionBecause 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 use this command by itself, rather than in conjunction with other debugging commands.
Sample Display
shows sample debug sdlc local-ack output.
Figure 2-200 Sample Debug SDLC Local-Ack Output
Explanations for individual lines of output from follow.
The first line shows the input to the SDLC local acknowledgment state machine:
SLACK (Serial3): Input = Network, LinkupRequestdescribes the fields in this line of output.
The second line shows the change in the SDLC local acknowledgment state machine. In this case the AwaitSdlcOpen state is an internal state that has not changed while this display was captured.
SLACK (Serial3): Old State = AwaitSdlcOpen New State = AwaitSdlcOpenThe third line shows the output from the SDLC local acknowledgment state machine:
SLACK (Serial3): Input = Network, LinkupRequestdebug sdlc packet
Use the debug sdlc packet EXEC command to display packet information on Synchronous Data Link Control (SDLC) frames received and sent by any router serial interface involved in supporting SDLC end station functions. The no form of this command disables debugging output.
debug sdlc packet [max-bytes]
no debug sdlc packetSyntax Description
Usage Guidelines
This command requires intensive CPU processing; therefore, we recommend not using it when the router is expected to handle normal network loads, such as in a production environment. Instead, use this command when network response is non-critical. We also recommend that you use this command by itself, rather than in conjunction with other debug commands.
Sample Display
shows sample debug sdlc packet output with the packet display limited to 20 bytes of data.
Figure 2-201 Sample Debug SDLC Packet Output
router# debug sdlc packet 20Serial3 SDLC Output00000 C3842C00 02010010 019000C5 C5C5C5C5 Cd.........EEEEE00010 C5C5C5C5 EEEESerial3 SDLC Output00000 C3962C00 02010011 039020F2 Co.........2Serial3 SDLC Output00000 C4962C00 0201000C 039020F2 Do.........2Serial3 SDLC Input00000 C491 Djdebug sdllc
Use the debug sdllc EXEC command to display information about data link layer frames transferred between a device on a Token Ring and a device on a serial line via a router configured with the SDLLC feature. The no form of this command disables debugging output.
[no] debug sdllc
Usage Guidelines
The SDLLC feature translates between the SDLC link layer protocol used to communicate with devices on a serial line and the LLC2 link layer protocol used to communicate with devices on a Token Ring.
The router configured with the SDLLC feature must be attached to the serial line. The router sends and receives frames on behalf of the serial device on the attached serial line but acts as an SDLC station.
The topology between the router configured with the SDLLC feature and the Token Ring is network dependent and is not limited by the SDLLC feature.
Sample Display
shows sample debug sdllc output between link layer peers from the perspective of the SDLLC-configured router.
Figure 2-202 Sample Debug SDLLC Output
router# debug sdllcSDLLC: rx explorer rsp, da 4000.2000.1001, sa C000.1020.1000, rif8840.0011.00A1.0050SDLLC: tx short xid, sa 4000.2000.1001, da C000.1020.1000, rif88C0.0011.00A1.0050, dsap 4 ssap 4SDLLC: tx long xid, sa 4000.2000.1001, da C000.1020.1000, rif88C0.0011.00A1.0050, dsap 4 ssap 4Rcvd SABME/LINKUP_REQ pak from TR hostSDLLCERR: not from our partner, pak dropped, da 4000.2000.1001,sa C000.1020.1000, rif 8840.0011.00A1.0050, partner = 5000.1040.1003describes significant fields shown in .
The following line indicates that an explorer frame response was received by the router at address 4000.2000.1001 from the FEP at address C000.1020.1000 with the specified RIF. The original explorer sent to the FEP from the router is not monitored as part of the debug sdllc command.
SDLLC: rx explorer rsp, da 4000.2000.1001, sa C000.1020.1000, rif8840.0011.00A1.0050The following line indicates that the router sent the null XID (Type 0) to the FEP. The debugging information does not include the response to the XID message sent by the FEP to the router.
SDLLC: tx short xid, sa 4000.2000.1001, da C000.1020.1000, rif88C0.0011.00A1.0050, dsap 4 ssap 4The following line indicates that the router sent the XID command (Format 0 Type 2) to the FEP:
SDLLC: tx long xid, sa 4000.2000.1001, da C000.1020.1000, rif88C0.0011.00A1.0050, dsap 4 ssap 4The following line is the SABME response to the XID command previously sent by the router to the FEP:
Rcvd SABME/LINKUP_REQ pak from TR host
