When troubleshooting Integrated Services Digital Network (ISDN) Basic Rate Interfaces (BRIs), it is necessary to first determine if the router can properly communicate with the telco ISDN switch. Once this has been verified, you can proceed to higher level troubleshooting issues such as dialer configurations, interesting traffic definitions, PPP failures and so on.
Readers of this document should be knowledgeable of the following:
Note: Activate millisecond timestamps for debugs using the following commands:
maui-soho-01(config)#service timestamps debug datetime msec
maui-soho-01(config)#service timestamps log datetime msec
The information in this document is based on the software and hardware versions below.
The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.
For more information on document conventions, see the Cisco Technical Tips Conventions.
Use the show isdn status command to check if the switch type for the interface is correctly configured. A sample below shows that the switch type is not configured:
maui-soho-01#show isdn status
**** No Global ISDN Switchtype currently defined ****
ISDN BRI0 interface
dsl 0, interface ISDN Switchtype = none
Layer 1 Status:
Layer 2 Status:
Layer 2 NOT Activated
!-- An invalid switch type can be displayed as a Layer 1 or Layer 2 problem.
Layer 3 Status:
0 Active Layer 3 Call(s)
Activated dsl 0 CCBs = 0
The Free Channel Mask: 0x80000003
Total Allocated ISDN CCBs = 0
If the switch type is either not configured or configured incorrectly, configure it on the interface.
Tip: The Telco should explicitly indicate the switchtype that needs to be configured. Occasionally (especially in North America) the Telco may indicate the switchtype is "custom" or "national". In such cases, use the following guidelines to determine the switchtype configuration:
Custom: If the Telco indicates that their switch-type is Custom, then configure the switchtype on the router as basic-5ess (for BRI with 5ess switch), primary-5ess (for PRI with 5ess), basic-dms(for BRI with DMS switch), or primary-dms (for PRI with DMS).
National: Switchtype conforming to the NI-1 standard for BRI and NI-2 standard for PRI. If the telco informs you that the switchtype is National, then the Cisco router configuration should be basic-ni (for BRI) or primary-ni (for PRI).
Note: For Cisco IOS software releases up to 11.2, the configured ISDN switch type is a global command (which meant you could not use BRI and Primary Rate Interface (PRI) cards in the same Cisco chassis with IOS 11.2 and earlier). In Cisco IOS 11.3T or later, multiple switch types in a single Cisco IOS chassis are supported.
Contact your telco to determine what your switch type is, then use the isdn switch-type command to configure it on the router as shown below:
Enter configuration commands, one per line. End with CNTL/Z.
maui-soho-01(config)#isdn switch-type basic-5ess
After each step prescribed below, use the show isdn status command to check if BRI Layers 1 and 2 are up.
Turn on debug isdn q921 to follow the messages that are transmitted from the router to the telco ISDN switch.
You should then use the clear interface bri number to reset the BRI interface. This forces the router to renegotiate Layer 2 information with the telco ISDN switch.
An example of a successful Layer 2 negotiation is shown below:
All possible debugging has been turned off
maui-soho-01#debug isdn q921
ISDN Q921 packets debugging is on
ISDN Q921 packets debugging is on
ISDN Q921 packets debug DSLs. (On/Off/No DSL:1/0/-)
DSL 0 --> 1
maui-soho-01#clear interface bri 0
*Mar 1 00:03:46.976: ISDN BR0: TX -> IDREQ ri = 29609 ai = 127
! -- IDREQ: Identity Request transmitted (Tx)to the ISDN switch requesting a ! -- Terminal Endpoint Identifier (TEI) ! -- Action Indicator, AI = 127 indicates that the ISDN switch can assign any ! -- TEI value available
*Mar 1 00:03:47.000: ISDN BR0: RX <- IDASSN RI = 29609 AI = 96
! -- IDASSN: Identity Assigned message Received(Rx) with the TEI value(96) ! -- assigned by the ISDN switch
*Mar 1 00:03:47.016: ISDN BR0: TX -> SABMEp sapi = 0 tei = 96
! -- Request the connection be put in Multiple Frame Established State
*Mar 1 00:03:47.036: ISDN BR0: RX <- UAf sapi = 0 tei = 96
! -- Unnumbered Acknowledgment(UA) of the SABME message ! -- Layer 2 is now Multiple Frame Established
*Mar 1 00:03:47.040: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 96
changed to up
*Mar 1 00:04:07.340: ISDN BR0: RX <- INFOc sapi = 0 tei = 96 ns = 0 nr = 0
i = 0x08007B3201C3
*Mar 1 00:04:07.352: ISDN BR0: TX -> RRr sapi = 0 tei = 96 NR = 1
! -- RRr Service Access Point Identifier (sapi=0) indicates data link services ! -- are provided to a network Layer.
For further information on debug isdn q921 and how to decode the Layer 2 negotiation sequence, refer to the debug command reference. You can also use debug isdn event for more debug information.
For a circuit that is properly functioning (Layer 2 is Multiple Frame Established), you should have periodic exchanges of RRp sapi = 0 and RRf sapi = 0 messages between the router and the ISDN switch, indicating that the link is up. The interval between Receiver Ready poll (RRp) and Receiver Ready final (RRf) sapi messages is usually 10 or 30 seconds. An example with the messages at 30 second intervals is shown below:
*Mar 1 01:33:48.559: ISDN BR0: TX -> RRp sapi = 0 tei = 96 NR = 0
*Mar 1 01:33:48.579: ISDN BR0: RX <- RRf sapi = 0 tei = 96 NR = 0
*Mar 1 01:34:18.347: ISDN BR0: TX -> RRp sapi = 0 tei = 96 NR = 0
*Mar 1 01:34:18.367: ISDN BR0: RX <- RRf sapi = 0 tei = 96 NR = 0
Layer 2 problems cannot often be rectified at the customer site. However, Layer 2 debugs (or the interpretation of the debugs) can be provided to the telco for their reference. The debug isdn q921 command output provides details on the Layer 2 transaction occurring between the ISDN switch and the router.
Pay attention to the direction of the messages. The debugs indicate whether the messages were generated by the router (indicated by TX ->) or if they were received by the router (indicated by RX <--). In the example below, the first message (IDREQ) is sent by the router, while the second (IDASSN) is from the ISDN switch:
*Mar 1 00:03:46.976: ISDN BR0: TX -> IDREQ RI = 29609 AI = 127
*Mar 1 00:03:47.000: ISDN BR0: RX <- IDASSN RI = 29609 AI = 96
You can identify the source of the problem by following the direction of a particular message and the response. For example, if the telco ISDN switch unexpectedly sends a Layer 2 disconnect, the router will reset Layer 2 as well. This indicates that the problem lies with the telco ISDN switch.
The router and the ISDN switch transmit and receive many Layer 2 messages. Most of the messages are normal and are used to verify normal operation. However, some messages can indicate Layer 2 problems. Though occasional resets may not affect service, if you observe extended periods of Layer 2 instability, you should take a closer look at the circuit.
The following table below has debug isdn q921 Layer 2 messages that indicate problems:
|| Possible Solution
|| The ISDN switch cannot assign the requested terminal endpoint identifier (TEI). If this message has AI=127, then the ISDN switch has no TEIs available. It is usually followed by another IDREQ from the router.
|| Reset the BRI interface using clear interface bri number or shut/no shut on the interface. If AI=127, then contact the telco/provider.
|| The ISDN switch has removed the TEI (ID) from the connection. The router must discard all exiting communication using that TEI.
|| Check to see if a new TEI is assigned at a later time. If not, contact the telco.
|| The side sending the DISConnect message has terminated Layer 3 operation on the link. It may be UAcknowledged by the other side. The router should then send a SABME message reestablishing the link
|| If the disconnect message originated from the router, reset the interface using clear interface bri number or shut/no shut on the interface. If the DISC message originated from the ISDN switch, contact the telco. If the router does not initiate a SABME, reset the interface first.
|| Acknowledged Disconnect Mode. The device sending this message does not wish to enter the Multiple Frame Established state. The router will remain in Layer 2 state TEI_ASSIGNED. SABMEs are retransmitted until the other side responds with a UA instead of a DM.
|| If the DM is generated by the router, reset the interface using clear interface bri number or shut/no shut on the interface. If the DM message originated from the ISDN switch, contact the telco.
|| A Frame Reject Response (from the ISDN switch) indicates an error that cannot be recovered by retransmission. The router will initiate a Layer 2 reset and transmit a SABME for transition to state Multiple Frame Established.
|| If the router does not initiate a SABME, reset the interface using clear interface bri number or shut/no shut on the interface.
An example of a Received DISC message shown in the table is provided:
Jan 30 10:50:18.523: ISDN BR1/0: RX <- RRf sapi = 0 tei = 71 NR = 0
Jan 30 10:50:23.379: ISDN BR1/0: RX <- DISCp sapi = 0 tei = 71
Jan 30 10:50:23.379: %ISDN-6-Layer2DOWN: Layer 2 for Interface BR1/0,TEI 71
changed to down
Jan 30 10:50:23.383: ISDN BR1/0: TX -> UAf sapi = 0 tei = 71
Here are some additional steps for troubleshooting:
If you observe that the router is sending ISDN Q.921 IDREQs and is receiving no response from the ISDN switch, check that the SPIDs are configured correctly, verify the SPIDs with the telco, and if necessary, have the telco track the SPIDs.
An example is shown below:
19:27:31: TX -> IDREQ RI = 19354 AI = 127 dsl = 0
19:27:33: TX -> IDREQ RI = 1339 AI = 127 dsl = 0
19:27:35: TX -> IDREQ RI = 22764 AI = 127 dsl = 0
19:27:37: TX -> IDREQ RI = 59309 AI = 127 dsl = 0
Observe that each IDREQ has an AI = 127 requesting that the ISDN switch can assign any TEI value available.
Normally, the router is assigned the TEI by the ISDN switch during powerup. However, sometimes (notably in Europe) switches may deactivate Layers 1 or 2 when there are no active calls. In such situations, it is necessary to configure isdn tei-negotiation first-call under the BRI interface, so that TEI negotiation can occur when the first ISDN call is placed or received. Typically, this setting is used for ISDN service offerings in Europe and connections to dms100 switches that are designed to initiate TEI negotiation.
maui-soho-01(config)#interface bri 0
maui-soho-01(config-if)#isdn tei-negotiation first-call
In this case, you may have to initiate a dialout or receive a call for the TEI negotiation to occur. For dialout, ensure that your DDR configuration is correct.
Reload the router.
If you have performed all the above procedures and continue to have Layer 1 and 2 not properly established, contact the telco for further troubleshooting assistance.