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
Note: Activate millisecond timestamps for debugs using the following
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
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
For more information on document conventions, see the
Cisco Technical Tips
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
You should then use the clear interface bri
to reset the BRI interface. This
forces the router to renegotiate Layer 2 information with the telco ISDN
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
and how to decode the Layer 2 negotiation
sequence, refer to the
command reference. You can also use
for more debug
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:
The ISDN switch cannot assign the requested terminal endpoint
identifier (TEI). If this message has AI=127, then the ISDN switch has no TEIs
It is usually followed by another IDREQ from the router.
Reset the BRI interface using clear interface bri
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
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
If the disconnect message originated from the router, reset the
interface using clear interface bri
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
shut/no shut on the interface.
If the DM message originated from the ISDN switch, contact the
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
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