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.
debug ipx ipxwan
no debug ipx ipxwanSyntax Description
This command has no arguments or keywords.
Command Mode
EXEC
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-82 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 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.
debug ipx packet
no debug ipx packetSyntax Description
This command has no arguments or keywords.
Command Mode
EXEC
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-83 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 .
Table 2-46 Debug IPX Packet Field Descriptions
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.
debug ipx routing
no debug ipx routingSyntax Description
This command has no arguments or keywords.
Command Mode
EXEC
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-84 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 .
Table 2-47 Debug IPX Routing Field Descriptions
Related Command
debug ipx sap
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
Command Mode
EXEC
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-85 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 .
Table 2-48 Debug IPX SAP Field Descriptions—Part 1
describes the fields shown in the third and fourth lines of output in .
Table 2-49 Debug IPX SAP Field Descriptions—Part 2
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.
Table 2-50 Debug IPX SAP Field Descriptions—Part 3
Related Command
debug ipx routing
debug ipx spoof
Use the debug ipx spoof 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.
debug ipx spoof
no debug ipx spoofSyntax Description
This command has no arguments or keywords.
Command Mode
EXEC
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-86 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 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-87 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-88 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-89 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-90 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-51 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-91 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-92 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-93 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-94 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-95 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-96 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-52 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-97 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-98 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-99 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-100 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-53 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.
debug isis adj packets
no debug isis adj packetsSyntax Description
This command has no arguments or keywords.
Command Mode
EXEC
Sample Display
shows sample debug isis adj packets output.
Figure 2-101 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.
debug isis spf statistics
no debug isis spf statisticsSyntax Description
This command has no arguments or keywords.
Command Mode
EXEC
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-102 Sample Debug ISIS SPF Statistics Output
router# debug isis spf packetsISIS-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 .
Table 2-54 Debug ISDN Event Field Descriptions
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
