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.

Syntax 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

Figure 2-53 shows sample debug ipx ipxwan output during link startup.

router# debug ipx ipxwan
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
IPXWAN: state (Disconnect -> Sending Timer Requests) [Serial1/6666:200 (IPX line
 state brought up)]
IPXWAN: state (Sending Timer Requests -> Disconnect) [Serial1/6666:200 (IPX line
 state brought down)]
IPXWAN: state (Disconnect -> Sending Timer Requests) [Serial1/6666:200 (IPX line
 state brought up)]
IPXWAN: Send TIMER_REQ [seq 0] out Serial1/6666:200
IPXWAN: Send TIMER_REQ [seq 1] out Serial1/6666:200
IPXWAN: Send TIMER_REQ [seq 2] out Serial1/6666:200
IPXWAN: Send TIMER_REQ [seq 0] out Serial1/6666:200
IPXWAN: Rcv TIMER_REQ on Serial1/6666:200, NodeID 1234, Seq 1
IPXWAN: Send TIMER_REQ [seq 1] out Serial1/6666:200
IPXWAN: Rcv TIMER_RSP on Serial1/6666:200, NodeID 1234, Seq 1, Del 6
IPXWAN: 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:200
IPXWAN: Rcv RIPSAP_INFO_RSP from Serial1/6666:200, NodeID 1234, Seq 0
IPXWAN: state (Master: Sent RIP/SAP -> Master: Connect) [Serial1/6666:200 (Received Router 
Info Rsp as Master)]

Explanations for representative lines of output in Figure 2-53 follow.

The following line indicates that the interface has initialized:

%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up

The 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 line
 state brought down)]
IPXWAN: state (Disconnect -> Sending Timer Requests) [Serial1/6666:200 (IPX line
 state 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:200
IPXWAN: Send TIMER_REQ [seq 1] out Serial1/6666:200

The 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 1
IPXWAN: Send TIMER_REQ [seq 1] out Serial1/6666:200
IPXWAN: Rcv TIMER_RSP on Serial1/6666:200, NodeID 1234, Seq 1, Del 6
IPXWAN: 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:200
IPXWAN: Rcv RIPSAP_INFO_RSP from Serial1/6666:200, NodeID 1234, Seq 0
IPXWAN: 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.

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

Sample Display

Figure 2-54 shows sample debug ipx packet output.

router# debug ipx packet
Novell: src=160.0260.8c4c.4f22, dst=1.0000.0000.0001, packet received
Novell: src=160.0260.8c4c.4f22, dst=1.0000.0000.0001,gw=183.0000.0c01.5d85, 
sending packet

In Figure 2-54, 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).

Table 2-30 describes significant fields shown in Figure 2-54.

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.

Syntax 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

Figure 2-55 shows sample debug ipx routing output.

router# debug ipx routing
NovellRIP: update from 9999.0260.8c6a.1733
           110801 in 1 hops, delay 2
NovellRIP: sending update to 12FF02:ffff.ffff.ffff via Ethernet 1
           network 555, metric 2, delay 3
           network 1234, metric 3, delay 4

Table 2-31 describes significant fields shown in Figure 2-55.

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.

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

Caution Because 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

Figure 2-56 shows sample debug ipx sap output.

As Figure 2-56 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:

Table 2-32 describes the fields shown in the second line of output in Figure 2-56.

Table 2-33 describes the fields shown in the third and fourth lines of output in Figure 2-56.

NovellSAP: sending update to 160

As Figure 2-56 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)

Table 2-34 describes possible values for the ssoc: field.

Related Command

debug ipx routing

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.

Syntax Description

This command has no arguments or keywords.

Command Mode

EXEC

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.

Sample Display

Figure 2-57 shows sample debug isdn-event output of call setup events for an outgoing call.

router# debug isdn-event
ISDN Event: Call to 415555121202
received HOST_PROCEEDING
 Channel ID i = 0x0101
 -------------------
 Channel ID i = 0x89
received HOST_CONNECT
 Channel ID i = 0x0101
ISDN Event: Connected to 415555121202 on B1 at 64 Kb/s

Figure 2-58 shows 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-59 shows sample debug isdn-event output of call teardown events for a call that has been hung up by the other side of the connection.

router# debug isdn-event
received HOST_DISCONNECT
ISDN Event: Call to 415555121202 was hung up

Figure 2-60 shows sample debug isdn-event output of a call teardown event for an outgoing or incoming call that has been hung up by the ISDN interface on the router side.

router# debug isdn-event
ISDN Event: Hangup call to call id 0x8008

Table 2-35 describes significant fields shown in Figure 2-57 through Figure 2-60.

Figure 2-61 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.

0:04:51: 291.848 RX <-  DISCONNECT pd = 8  callref = 0x83
0:04:51:         Cause i = 0x8090 - Normal call clearing

Figure 2-62 shows 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.

0:06:44: 404.732 RX <-  DISCONNECT pd = 8  callref = 0x82
0:06:44:         Cause i = 0x8095 - Call rejected

Figure 2-63 shows sample debug isdn-event output of a call teardown event for an outgoing call that uses a dialer subaddress.

0:04:55: ISDN Event: Call to 5551201:123
0:04:55: 295.692 TX ->  SETUP pd = 8  callref = 0x02
0:04:55:         Bearer Capability i = 0x8890
0:04:55:         Channel ID i = 0x83
0:04:55:         Called Party Number i = 0x80, '5551201'
0:04:55:         Called Party SubAddr i = 0x80, 'P123'
0:04:55: 295.840 RX <-  CALL_PROC pd = 8  callref = 0x82
0:04:55:         Channel ID i = 0x89
0:04:55: received HOST_PROCEEDING
        Channel ID i = 0x0101
0:04:55:        -------------------
        Channel ID i = 0x89
0:04:56: 296.044 RX <-  CONNECT pd = 8  callref = 0x82
0:04:56: received HOST_CONNECT
        Channel ID i = 0x0101
0:04:56:        -------------------
0:04:56: ISDN Event: Connected to 5551201:123 on B1 at 64 Kb/s
0:04:56: 296.064 TX ->  CONNECT_ACK pd = 8  callref = 0x02.

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.

Syntax Description

This command has no arguments or keywords.

Command Mode

EXEC

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.

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 (RRs).

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.

Sample Display

Figure 2-64 shows sample debug isdn-q921 output for an outgoing call.

Figure 2-65 shows sample debug isdn-q921 output for a startup message on a DMS-100 switch.

Figure 2-66 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.

router# debug isdn-q921
234423.764 TX -> RRp sapi = 0 tei = 66 nr = 36 
234423.780 RX <- RRp sapi = 0 tei = 66 nr = 26
234423.784 TX -> RRf sapi = 0 tei = 66 nr = 36
234423.808 RX <- RRf sapi = 0 tei = 66 nr = 26
234425.800 RX <- UAf sapi = 0 tei = 127 i = 
0x0801080504028890018001896C1000833831303132333445363738393032
234425.820 TX -> INFOc sapi = 0 tei = 66 ns = 36 nr = 36 i=0x08018807
234425.904 RX <- RRr sapi = 0 tei = 90 nr = 27
234425.920 RX <- INFOc sapi = 0 tei = 66 ns = 36 nr = 33 i=0x0801080F
234433.936 TX -> RRr sapi = 0 tei = 66 nr = 37 
234435.940 RX <- RRp sapi = 0 tei = 66 nr = 27
234435.980 TX -> RRf sapi = 0 tei = 66 nr = 37
234435.640 RX <- RRf sapi = 0 tei = 66 nr = 27

Table 2-36 describes significant fields in Figure 2-64, Figure 2-65, and Figure 2-66.

Explanations for individual lines of output from Figure 2-64 follow.

The following lines indicate the message exchanges between the data link 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.

At 139.516, 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 (48386) 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 139.544, the network data link entity responds to the Identity Request message with an Identity Assigned message. The response includes the reference number (48386) previously sent in the request and TEI value (90) assigned by the ASP.

The following line indicates a message exchange between the layer management entity on the network side and the layer management entity on the local router (user side) during the TEI removal procedure:

At 139.520, the network layer management entity sends an Identity Remove message when it determines that removal is necessary. The message includes a reference number that is always 0, because it is not responding to a request from the local router. The message also includes the TEI value (89) that is being removed because it is an old value that is no longer used.

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:

At 139.552, 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 139.560, the layer management entity on the local router responds with an Identity Check Response message indicating that TEI value 90 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.

140.584 RX <- UAf sapi = 0 tei = 90

At 140.560, the data link layer entity on the local router sends the SABME command with a SAPI of 0 (call control procedure) for TEI 90. At 140.584, 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.

150.768 TX -> RRp sapi = 0 tei = 90 nr = 1
150.788 RX <- RRf sapi = 0 tei = 90 nr = 1

These I frames are typically exchanged every 10 seconds (T203 timer).

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.

Syntax Description

This command has no arguments or keywords.

Command Mode

EXEC

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 types VN2 and VN3.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.

Sample Display

Figure 2-67 shows sample debug isdn-q931 output of a call setup procedure for an outgoing call.

router# debug isdn-q931
234191.372 TX -> SETUP pd = 8 callref = 0x04
 Bearer Capability i = 0x8890
 Channel ID i = 0x83
 Called Party Number i = 0x80, '415555121202'
234191.624 RX <- CALL_PROC pd = 8 callref = 0x84
 Channel ID i = 0x89
234191.692 RX <- CONNECT pd = 8 callref = 0x84
234191.692 TX -> CONNECT_ACK pd = 8 callref = 0x04....
Success rate is 0 percent (0/5)

Figure 2-68 shows sample debug isdn-q931 output of a call setup procedure for an incoming call.

router# debug isdn-q931
234223.224 RX <- SETUP pd = 8 callref = 0x06
 Bearer Capability i = 0x8890
 Channel ID i = 0x89
 Calling Party Number i = 0x0083, '81012345678902'
234223.244 TX -> CONNECT pd = 8 callref = 0x86
234223.344 RX <- CONNECT_ACK pd = 8 callref = 0x06

Figure 2-69 shows sample debug isdn-q931 output of a call teardown procedure from the network.

router# debug isdn-q931
234207.648 RX <- DISCONNECT pd = 8 callref = 0x84
 Cause i = 0x8790
 Looking Shift to Codeset 6
 Codeset 6 IE 0x1 1 0x82 '10'
234207.668 TX -> RELEASE pd = 8 callref = 0x04
 Cause i = 0x8090
234207.764 RX <- RELEASE_COMP pd = 8 callref = 0x84

Figure 2-70 shows sample debug isdn-q931 output of a call teardown procedure from the router.

router# debug isdn-q931
234236.644 TX -> DISCONNECT pd = 8 callref = 0x05
 Cause i = 0x879081
234238.664 RX <- RELEASE pd = 8 callref = 0x85
 Looking Shift to Codeset 6
 Codeset 6 IE 0x1 1 0x82 '10'
234238.752 TX <- RELEASE_COMP pd = 8 callref = 0x05

Table 2-37 describes significant fields in Figure 2-67 through Figure 2-70.

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.

Syntax Description

This command has no arguments or keywords.

Command Mode

EXEC

Sample Display

Figure 2-71 shows sample debug isis adj packets output.

router# debug isis adj packets
ISIS-Adj: Rec L1 IIH from 0000.0c00.40af (Ethernet0), cir type 3, cir id 
BBBB.BBBB.BBBB.01
ISIS-Adj: Rec L2 IIH from 0000.0c00.40af (Ethernet0), cir type 3, cir id 
BBBB.BBBB.BBBB.01
ISIS-Adj: Rec L1 IIH from 0000.0c00.0c36 (Ethernet1), cir type 3, cir id 
CCCC.CCCC.CCCC.03
ISIS-Adj: Area mismatch, level 1 IIH on Ethernet1
ISIS-Adj: Sending L1 IIH on Ethernet1
ISIS-Adj: Sending L2 IIH on Ethernet1
ISIS-Adj: Rec L2 IIH from 0000.0c00.0c36 (Ethernet1), cir type 3, cir id 
BBBB.BBBB.BBBB.03

Explanations for individual lines of output from Figure 2-71 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.01

The 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 Ethernet1

The 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 Ethernet1
ISIS-Adj: Sending L2 IIH on Ethernet1

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

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

Sample Display

Figure 2-72 shows sample debug isis spf statistics output.

router# debug isis spf packets
ISIS-Stats: Compute L1 SPT, Timestamp 2780.328 seconds
ISIS-Stats: Complete L1 SPT, Compute time 0.004, 1 nodes on SPT
ISIS-Stats: Compute L2 SPT, Timestamp 2780.3336 seconds
ISIS-Stats: Complete L2 SPT, Compute time 0.056, 12 nodes on SPT

Table 2-38 describes significant fields shown in Figure 2-72.

Explanations for individual lines of output from Figure 2-72 follow.

The following lines show the statistical information available for Level 1 ISs:

The 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:

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

Syntax Description

This command has no arguments or keywords.

Command Mode

EXEC

Sample Display

Figure 2-73 shows sample debug isis update-packets output.

router# debug isis update-packets
ISIS-Update: Sending L1 CSNP on Ethernet0
ISIS-Update: Sending L2 CSNP on Ethernet0
ISIS-Update: Updating L2 LSP
ISIS-Update: Delete link 888.8800.0181.00 from L2 LSP 1600.8906.4022.00-00, seq E
ISIS-Update: Updating L1 LSP
ISIS-Update: Sending L1 CSNP on Ethernet0
ISIS-Update: Sending L2 CSNP on Ethernet0
ISIS-Update: Add link 8888.8800.0181.00 to L2 LSP 1600.8906.4022.00-00, new seq 10,
 len 91
ISIS-Update: Sending L2 LSP 1600.8906.4022.00-00, seq 10, ht 1198 on Tunnel0
ISIS-Update: Sending L2 CSNP on Tunnel0
ISIS-Update: Updating L2 LSP
ISIS-Update: Rate limiting L2 LSP 1600.8906.4022.00-00, seq 11 (Tunnel0)
ISIS-Update: Updating L1 LSP
ISIS-Update: Rec L2 LSP 888.8800.0181.00.00-00 (Tunnel0)
ISIS-Update: PSNP entry 1600.8906.4022.00-00, seq 10, ht 1196

Explanations for individual lines of output from Figure 2-73 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 Ethernet0
ISIS-Update: Sending L2 CSNP on Ethernet0

The 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 LSP
ISIS-Update: Delete link 888.8800.0181.00 from L2 LSP 1600.8906.4022.00-00, seq E

The 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 LSP
ISIS-Update: Sending L1 CSNP on Ethernet0
ISIS-Update: Sending L2 CSNP on Ethernet0
ISIS-Update: Add link 8888.8800.0181.00 to L2 LSP 1600.8906.4022.00-00, new seq 10,
 len 91

The 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 Tunnel0

The following lines indicates that a Level 2 LSP could not be transmitted because it was recently transmitted:

ISIS-Update: Sending L2 CSNP on Tunnel0
ISIS-Update: Updating L2 LSP
ISIS-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 LSP
ISIS-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 1196

debug lapb

Use the debug lapb EXEC command to display all traffic for interfaces using LAPB encapsulation. The no form of this command disables debugging output.

Syntax Description

This command has no arguments or keywords.

Command Mode

EXEC

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.

Caution Because 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

Figure 2-74 shows sample debug lapb output. (The numbers 1 through 7 at the top of the display have been added in order to aid documentation.)

   1      2   3    4     5    6    7
Serial0: LAPB I CONNECT (5) IFRAME P 2 1
Serial0: LAPB O REJSENT (2) REJ F 3
Serial0: LAPB O REJSENT (5) IFRAME 0 3
Serial0: LAPB I REJSENT (2) REJ (C) 7
Serial0: LAPB I DISCONNECT (2) SABM P
Serial0: LAPB O CONNECT (2) UA F
Serial0: LAPB O CONNECT (5) IFRAME 0 0
Serial0: LAPB T1 CONNECT 357964 0

In Figure 2-74 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 Figure 2-74, the last line describes a timer event; all of the other lines describe frame events. Table 2-39 describes the first seven fields shown in Figure 2-74.

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 Figure 2-74 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 255748
Serial2: LAPB O CONNECT (2) RR P 5
Serial2: LAPB I CONNECT (2) RR F 5
Serial2: LAPB T4 CONNECT 260748
Serial2: LAPB O CONNECT (2) RR P 5
Serial2: LAPB I CONNECT (2) RR F 5

The next example shows an interface outage timer expiration (T3):

Serial2: LAPB T3 DISCONNECT 273284

The 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 1
Serial2: LAPB O SABMSENT (2) SABM P
Serial2: LAPB I SABMSENT (2) SABM (R/ERR)
Serial2: LAPB T1 SABMSENT 1029508 2
Serial2: LAPB O SABMSENT (2) SABM P
Serial2: 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 0
Serial2: LAPB O SABMSENT (2) SABME P
Serial2: LAPB I SABMSENT (2) SABM P
Serial2: LAPB T1 SABMSENT 1431720 1
Serial2: LAPB O SABMSENT (2) SABME P
Serial2: LAPB I SABMSENT (2) SABM P

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

Syntax Description

This command has no arguments or keywords.

Command Mode

EXEC

Usage Guidelines

For each datagram (packet) received or transmitted, a message is logged to the console.

Sample Display

Figure 2-75 shows sample debug lat packet output.

router# debug lat packet
LAT: I int=Ethernet0, src=0000.0c01.0509, dst=0900.2b00.000f, type=0, M=0, R=0
LAT: I int=Ethernet0, src=0800.2b11.2d13, dst=0000.0c01.7876, type=A, M=0, R=0
LAT: O dst=0800.2b11.2d13, int=Ethernet0, type= A, M=0, R=0, len= 20, next 0 ref 1

The second line of output in Figure 2-75 describes a packet that is input to the router. Table 2-40 describes the fields in this line.

The third line of output in Figure 2-75 describes a packet that is output from the router. Table 2-41 describes the last three fields in this line.

debug lex rcmd

Use the debug lex rcmd EXEC command to debug LAN Extender (LEX) remote commands. The no form of this command disables debugging output.

Syntax Description

This command has no arguments or keywords.

Command Mode

EXEC

Sample Display

Figure 2-76 shows sample debug lex rcmd output.

router# debug lex rcmd
LEX-RCMD: "shutdown" command received on unbound serial interface- Serial0
LEX-RCMD: Lex0 : "inventory" command received
Rcvd rcmd: FF 03 80 41 41 13 00 1A 8A 00 00 16 01 FF 00 00
Rcvd rcmd: 00 02 00 00 07 5B CD 15 00 00 0C 01 15 26
LEX-RCMD: ACK or response received on Serial0 without a corresponding ID
LEX-RCMD: REJ received
LEX-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 interface
LEX-RCMD: encapsulation failure
LEX-RCMD: timeout for Lex0: "lex priority-group" command
LEX-RCMD: re-transmitting Lex0: "lex priority-group" command
LEX-RCMD: lex_setup_and_send called with invalid parameter
LEX-RCMD: bind occurred on shutdown LEX interface
LEX-RCMD: Serial0- No free Lex interface found with negotiated MAC address 0000.0c00.d8db
LEX-RCMD: No active Lex interface found for unbind

Explanations for individual lines of output from Figure 2-76 follow.

The following output indicates that a LEX remote command packet was received on a serial interface which is not bound to a LEX interface.

LEX-RCMD: "shutdown" command received on unbound serial interface- Serial0

This message can occur for any of the LEX remote commands. Possible causes of this message are as follows:

• FLEX state machine software error

• Serial line momentarily goes down, which is detected by the host but not by FLEX

The following output indicates that a LEX remote command response has been received. The hexadecimal values are for internal use only:

LEX-RCMD: Lex0 : "inventory" command received
Rcvd rcmd: FF 03 80 41 41 13 00 1A 8A 00 00 16 01 FF 00 00
Rcvd rcmd: 00 02 00 00 07 5B CD 15 00 00 0C 01 15 26

The following output indicates that when the host router originates a LEX 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 ID

This message could be displayed for any of the following reasons:

• FLEX was very busy at the time that the command arrived and could not send an immediate response. The command timedout on the host router and then FLEX finally sent the response.

• Transmission error.

• Software error.

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 received

The following output shows that a LEX 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 LEX remote command response was received but that it had an incorrect length field. This message can occur for any of the LEX 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 interface

The 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 failure

The 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 LEX remote commands:

 LEX-RCMD: timeout for Lex0: "lex priority-group" command

This message could be displayed for any of the following reasons:

• FLEX too busy to respond

• Transmission failure

• Software error

The following output indicates that the host is retransmitting the remote command after a timeout:

LEX-RCMD: re-transmitting Lex0: "lex priority-group" command

The 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 parameter

The following output is informational and shows when a bind occurs on a shutdown interface:

LEX-RCMD: bind occurred on shutdown LEX interface

The following output shows that LEX-NCP reached the open state and a bind operation was attempted with the FLEX's MAC address, but that no free LEX interfaces were found that were configured with that MAC address. This output can occur when the network administrator does not configure a LEX interface with the correct MAC address.

LEX-RCMD: Serial0- No free Lex interface found with negotiated MAC address 0000.0c00.d8db

The following output shows that the serial line that was bound to the LEX interface went down, and the unbind routine was called, but when the list of active LEX interfaces was searched the LEX 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 unbind

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

Syntax Description

This command has no arguments or keywords.

Command Mode

EXEC

Sample Display

Figure 2-77 shows sample debug lnm events output.

router# debug lnm events
IBMNM3: Adding 0000.3001.1166 to error list
IBMNM3: Station 0000.3001.1166 going into preweight condition
IBMNM3: Station 0000.3001.1166 going into weight condition
IBMNM3: Removing 0000.3001.1166 from error list
LANMGR0: Beaconing is present on the ring
LANMGR0: Ring is no longer beaconing
IBMNM3: Beaconing, Postmortem Started
IBMNM3: Beaconing, heard from 0000.3000.1234
IBMNM3: Beaconing, Postmortem Next Stage
IBMNM3: Beaconing, Postmortem Finished

Explanations for the messages shown in Figure 2-77 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 list

The 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 condition

The following message indicates that station 0000.3001.1166 is experiencing a severe number of errors:

IBMNM3: Station 0000.3001.1166 going into weight condition

The 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 list

The following message indicates that Ring 0 has entered failure mode. This ring number is assigned internally.

LANMGR0: Beaconing is present on the ring

The following message indicates that Ring 0 is no longer in failure mode. This ring number is assigned internally.

LANMGR0: Ring is no longer beaconing

The following message indicates that the router is beginning its attempt to determine whether or not 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 Started

The 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.1234

The 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 Stage

The 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 Finished

Explanations 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 exceeded

The following message indicates that a station (or stations) on Ring 3 are receiving frames faster than they can be processed.

IBMNM3: Adapters experiencing congestion

The following message indicates that the beaconing has lasted for over 1 minute and is considered a "permanent" error:

IBMNM3: Beaconing, permanent

The 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 Started

In 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 LNMs that have connections to it. The no form of this command disables debugging output.

Syntax Description

This command has no arguments or keywords.

Command Mode

EXEC

Usage Guidelines

One line is displayed for each message sent or received.

Sample Display

Figure 2-78 shows sample debug lnm llc output.

router# debug lnm llc
IBMNM: Received LRM Set Reporting Point frame from 1000.5ade.0d8a.
IBMNM: found bridge: 001-2-00A, addresses: 0000.3040.a630 4000.3040.a630
IBMNM: Opening connection to 1000.5ade.0d8a on TokenRing0
IBMNM: 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 LNM
IBMNM: 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.2d7

As Figure 2-78 indicates, debug lnm llc output can vary somewhat in format. Table 2-42 describes significant fields shown in the first line of output in Figure 2-78.

Explanations for other types of messages shown in Figure 2-78 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.a630

The following message is self-explanatory:

IBMNM: Opening connection to 1000.5ade.0d8a on TokenRing0

The 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 LNM

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

Syntax Description

This command has no arguments or keywords.

Command Mode

EXEC

Usage Guidelines

One line is displayed for each message sent or received.

Sample Display

Figure 2-79 shows sample debug lnm mac output.

router# debug lnm mac
LANMGR0: 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.

Table 2-43 describes significant fields shown in the first line of output in Figure 2-79.

As Figure 2-79 indicates, all debug lnm mac messages follow the format described in Table 2-43 except the following:

LANMGR2: RS start watching ring poll
LANMGR2: RS stop watching ring poll

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

Syntax Description

This command has no arguments or keywords.

Command Mode

EXEC

Sample Display

Figure 2-80 shows sample debug local-ack state output.

router# debug local-ack state
LACK_STATE: 2370300, hashp 2AE628, old state = disconn, new state = awaiting 
LLC2 open to finish
LACK_STATE: 2370304, hashp 2AE628, old state = awaiting LLC2 open to finish, 
new state = connected
LACK_STATE: 2373816, hashp 2AE628, old state = connected, new state = disconnected
LACK_STATE: 2489548, hashp 2AE628, old state = disconn, new state = awaiting 
LLC2 open to finish
LACK_STATE: 2489548, hashp 2AE628, old state = awaiting LLC2 open to finish, 
new state = connected
LACK_STATE: 2490132, hashp 2AE628, old state = connected, new state = awaiting 
linkdown response
LACK_STATE: 2490140, hashp 2AE628, old state = awaiting linkdown response, 
new state = disconnected
LACK_STATE: 2497640, hashp 2AE628, old state = disconn, new state = awaiting 
LLC2 open to finish
LACK_STATE: 2497644, hashp 2AE628, old state = awaiting LLC2 open to finish, 
new state = connected

Table 2-44 describes significant fields shown in Figure 2-80.

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

Syntax Description

This command has no arguments or keywords.

Command Mode

EXEC

Usage Guidelines

Examine the display to diagnose problems in NetBIOS name caching.

Sample Display

Figure 2-81 illustrates a collection of sample debug netbios-name-cache output listings.

router# debug netbios-name-cache
NETBIOS: L checking name ORINDA , vrn=0
NetBIOS name cache table corrupted at offset 13
NetBIOS name cache table corrupted at later offset, at location 13
NETBIOS: U chk name=ORINDA, addr=1000.4444.5555, idb=TR1, vrn=0, type=1
NETBIOS: U upd name=ORINDA,addr=1000.4444.5555,idb=TR1,vrn=0,type=1
NETBIOS: U add name=ORINDA,addr=1000.4444.5555,idb=TR1,vrn=0,type=1
NETBIOS: U no memory to add cache entry. name=ORINDA,addr=1000.4444.5555
NETBIOS: Invalid structure detected in netbios_name_cache_ager
NETBIOS: flushed name=ORINDA, addr=1000.4444.5555
NETBIOS: expired name=ORINDA, addr=1000.4444.5555
NETBIOS: removing entry. name=ORINDA,addr=1000.4444.5555,idb=TR1,vrn=0
NETBIOS: Tossing ADD_NAME/STATUS/NAME/ADD_GROUP frame
NETBIOS: Lookup Failed -- not in cache
NETBIOS: Lookup Worked, but split horizon failed
NETBIOS: Could not find RIF entry
NETBIOS: Cannot duplicate packet in netbios_name_cache_proxy

Table 2-45 describes selected debug netbios-name-cache output fields.

The following discussion briefly outlines each line shown in the example provided in Figure 2-81.

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=0

The 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 13
NetBIOS name cache table corrupted at later offset, at location 13

The 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=1

The 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=1

The 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=1

The 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.5555

The 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_ager

The following line indicates that the entry for ORINDA was flushed from the cache table:

NETBIOS: flushed name=ORINDA, addr=1000.4444.5555

The following line indicates that the entry for ORINDA timed out and was flushed from the cache table:

NETBIOS: expired name=ORINDA, addr=1000.4444.5555

The 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=0

The 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 frame

The following line indicates that the system could not find a NetBIOS name in the cache:

NETBIOS: Lookup Failed -- not in cache

The 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 failed

The 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 entry

The 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_proxy

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.

Syntax Description

This command has no arguments or keywords.

Command Mode

EXEC

Sample Display

Figure 2-82 shows sample debug packet output. Notice how similar it is to debug broadcast output.

router# debug packet
Ethernet0: Unknown ARPA, src 0000.0c00.6fa4, dst ffff.ffff.ffff, type 0x0a0
data 00000c00f23a00000c00ab45, len 60
Serial3: Unknown HDLC, size 64, type 0xaaaa, flags 0x0F00
Serial2: Unknown PPP, size 128
Serial7: Unknown FRAME-RELAY, size 174, type 0x5865, DLCI 7a
Serial0: compressed TCP/IP packet dropped

Table 2-46 describes significant fields shown in Figure 2-82.

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.

Syntax Description

Command Mode

EXEC

Usage Guidelines

Use the debug ppp commands when trying to find the following:

• The Network Control Protocols (NCPs) that are supported on either end of a PPP connection

• Any loops that might exist in a PPP internetwork

• Nodes that are (or are not) properly negotiating PPP connections

• Errors that have occurred over the PPP connection

• Causes for CHAP session failures

• Causes for PAP session failures

Refer to Internet RFCs 1331, 1332, and 1333 for details concerning PPP-related nomenclature and protocol information.

Sample Displays

Figure 2-83 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.

router# debug ppp packet
PPP Serial4(o): lcp_slqr() state = OPEN magic = D21B4, len = 48
PPP Serial4(i): pkt type 0xC025, datagramsize 52
PPP Serial4(i): lcp_rlqr() state = OPEN magic = D3454, len = 48
PPP Serial4(i): pkt type 0xC021, datagramsize 16
PPP Serial4: I LCP ECHOREQ(9) id 3 (C) magic D3454
PPP Serial4: input(C021) state = OPEN code = ECHOREQ(9) id = 3 len = 12
PPP Serial4: O LCP ECHOREP(A) id 3 (C) magic D21B4
PPP Serial4(o): lcp_slqr() state = OPEN magic = D21B4, len = 48
PPP Serial4(i): pkt type 0xC025, datagramsize 52
PPP Serial4(i): lcp_rlqr() state = OPEN magic = D3454, len = 48
PPP Serial4(i): pkt type 0xC021, datagramsize 16
PPP Serial4: I LCP ECHOREQ(9) id 4 (C) magic D3454
PPP Serial4: input(C021) state = OPEN code = ECHOREQ(9) id = 4 len = 12
PPP Serial4: O LCP ECHOREP(A) id 4 (C) magic D21B4
PPP Serial4(o): lcp_slqr() state = OPEN magic = D21B4, len = 48
PPP Serial4(i): pkt type 0xC025, datagramsize 52
PPP Serial4(i): lcp_rlqr() state = OPEN magic = D3454, len = 48
PPP Serial4(i): pkt type 0xC021, datagramsize 16
PPP Serial4: I LCP ECHOREQ(9) id 5 (C) magic D3454
PPP Serial4: input(C021) state = OPEN code = ECHOREQ(9) id = 5 len = 12
PPP Serial4: O LCP ECHOREP(A) id 5 (C) magic D21B4
PPP Serial4(o): lcp_slqr() state = OPEN magic = D21B4, len = 48
PPP Serial4(i): pkt type 0xC025, datagramsize 52
PPP Serial4(i): lcp_rlqr() state = OPEN magic = D3454, len = 48
PPP Serial4(i): pkt type 0xC021, datagramsize 16
PPP Serial4: I LCP ECHOREQ(9) id 6 (C) magic D3454
PPP Serial4: input(C021) state = OPEN code = ECHOREQ(9) id = 6 len = 12
PPP Serial4: O LCP ECHOREP(A) id 6 (C) magic D21B4
PPP Serial4(o): lcp_slqr() state = OPEN magic = D21B4, len = 48
PPP Serial4(i): pkt type 0xC025, datagramsize 52
PPP Serial4(i): lcp_rlqr() state = OPEN magic = D3454, len = 48
PPP Serial4(i): pkt type 0xC021, datagramsize 16
PPP Serial4: I LCP ECHOREQ(9) id 7 (C) magic D3454
PPP Serial4: input(C021) state = OPEN code = ECHOREQ(9) id = 7 len = 12
PPP Serial4: O LCP ECHOREP(A) id 7 (C) magic D21B4
PPP Serial4(o): lcp_slqr() state = OPEN magic = D21B4, len = 48

Table 2-47 describes significant fields shown in Figure 2-83.

To elaborate on the displayed output, consider the partial exchange in Figure 2-84. This sequence shows that one side is using ECHO for its keepalives and the other side is using LQRs.

PPP Serial4(o): lcp_slqr() state = OPEN magic = D21B4, len = 48
PPP Serial4(i): pkt type 0xC025, datagramsize 52
PPP Serial4(i): lcp_rlqr() state = OPEN magic = D3454, len = 48
PPP Serial4(i): pkt type 0xC021, datagramsize 16
PPP Serial4: I LCP ECHOREQ(9) id 3 (C) magic D3454
PPP Serial4: input(C021) state = OPEN code = ECHOREQ(9) id = 3 len = 12
PPP Serial4: O LCP ECHOREP(A) id 3 (C) magic D21B4
PPP Serial4(o): lcp_slqr() state = OPEN magic = D21B4, len = 48

PPP Serial4(o): lcp_slqr() state = OPEN magic = D21B4, len = 48

PPP Serial4(i): pkt type 0xC025, datagramsize 52
PPP Serial4(i): lcp_rlqr() state = OPEN magic = D3454, len = 48

PPP Serial4(i): pkt type 0xC021, datagramsize 16
PPP Serial4: I LCP ECHOREQ(9) id 3 (C) magic D3454

PPP Serial4: O LCP ECHOREP(A) id 3 (C) magic D21B4
PPP Serial4(o): lcp_slqr() state = OPEN magic = D21B4, len = 48

Figure 2-85 shows sample debug ppp negotiation output. This is a normal negotiation, where both sides agree on NCP parameters. In this case, protocol type IP is proposed and acknowledged.

router# debug ppp negotiation
ppp: sending CONFREQ, type = 4 (CI_QUALITYTYPE), value = C025/3E8
ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 3D56CAC
ppp: received config for type = 4 (QUALITYTYPE) acked
ppp: received config for type = 5 (MAGICNUMBER) value = 3D567F8 acked (ok)
PPP Serial4: state = ACKSENT fsm_rconfack(C021): rcvd id 5
ppp: config ACK received, type = 4 (CI_QUALITYTYPE), value = C025
ppp: config ACK received, type = 5 (CI_MAGICNUMBER), value = 3D56CAC
ppp: ipcp_reqci: returning CONFACK.
 (ok)
PPP Serial4: state = ACKSENT fsm_rconfack(8021): rcvd id 4

Table 2-48 describes significant fields shown in Figure 2-85.

The following discussion briefly outlines each line shown in the example provided in Figure 2-85.

The first two lines in Figure 2-85 indicate that the router is trying to bring up LCP and intends to 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/3E8
ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 3D56CAC

The 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