T1 PRI Troubleshooting

Document ID: 8131

Contents
Introduction
Prerequisites
Requirements
Components Used
Conventions
Use the show isdn status Command
Use the debug isdn q921 Command
Troubleshoot Further
Related Information
Introduction
When you troubleshoot a Primary Rate Interface (PRI), ensure that the T1 runs properly on both ends. The
reason is that ISDN PRI signaling rides on top of the T1 physical layer. To check whether the T1 Layer 1 runs
properly, use the show controller t1 command. Ensure that there are no errors on any of the counters. Ensure
that the framing, line coding, and clock source are configured correctly. Refer to the T1 Troubleshooting
flowchart for more information. Contact your Service Provider for the correct settings.

When you have resolved problems in Layer 1, and the show controller t1 counters are zero, you can focus on
Layers 2 and 3 of the ISDN PRI signaling.

Tip: You can use the clear counters command to reset the T1 counters. When the counters are clear, you can
easily observe whether the T1 Line experiences any errors. However, remember that this command clears all
other show interface counters as well. Here is an example:

maui−nas−03#clear counters
Clear "show interface" counters on all interfaces [confirm]
maui−nas−03#
*Apr 12 03:34:12.143: %CLEAR−5−COUNTERS: Clear counter on all interfaces by console

Prerequisites
Requirements
There are no specific requirements for this document.

Components Used
This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the
devices used in this document started with a cleared (default) configuration. If your network is live, make sure
that you understand the potential impact of any command.
Conventions
For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Use the show isdn status Command

The show isdn status command is very useful to troubleshoot ISDN signaling problems. The show isdn
status command displays a summary of the current status of all ISDN interfaces, and also the status of Layers
1, 2, and 3. Here is an example of the show isdn status command output:

maui−nas−03#show isdn status

Global ISDN Switchtype = primary−5ess
ISDN Serial0:23 interface
dsl 0, interface ISDN Switchtype = primary−5ess
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
Layer 3 Status:
5 Active Layer 3 Call(s)
Activated dsl 0 CCBs = 5
CCB:callid=7D5, sapi=0, ces=0, B−chan=9, calltype=DATA
CCB:callid=7D6, sapi=0, ces=0, B−chan=10, calltype=DATA
CCB:callid=7DA, sapi=0, ces=0, B−chan=11, calltype=DATA
CCB:callid=7DE, sapi=0, ces=0, B−chan=1, calltype=DATA
CCB:callid=7DF, sapi=0, ces=0, B−chan=2, calltype=DATA
The Free Channel Mask: 0x807FF8FC
ISDN Serial1:23 interface
dsl 1, interface ISDN Switchtype = primary−5ess
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 0, Ces = 1, SAPI = 0, State = TEI_ASSIGNED
Layer 3 Status:
0 Active Layer 3 Call(s)
Activated dsl 1 CCBs = 0
The Free Channel Mask: 0x807FFFFF
Total Allocated ISDN CCBs = 5

Complete these steps to check the status of the layers:

1. Verify whether Layer 1 is in the ACTIVE state. The status of Layer 1 must always be ACTIVE unless
the T1 is down.

If the show isdn status command output indicates that Layer 1 is DEACTIVATED, there is a
problem with the physical connectivity of the T1 line. If the line is administratively down, use the no
shutdown command to restart the interface.
2. Ensure that Layer 2 is in the MULTIPLE_FRAME_ESTABLISHED state. This is the required state
for Layer 2. This state indicates that the router received an ISDN SABME (Set Asynchronous
Balanced Mode Extended) message, and responded with a UA (Unnumbered Acknowledge) frame to
synchronize with the Telco switch. Furthermore, there must be constant Layer 2 frames (Receiver
Ready, RR) frames exchange between the two devices. When this occurs, the router and ISDN switch
have fully initialized the ISDN Layer 2 protocol. For information on how to identify the SABME and
RR messages, see the Using the debug q921 Command section.

If Layer 2 is not in the MULTIPLE_FRAME_ESTABLISHED state, use the debug isdn q921
command to diagnose the problem.
 Furthermore, the show isdn status command displays a summary of the current status. Therefore,
Layer 2 can bounce up and down even though it indicates a MULTIPLE_FRAME_ESTABLISHED
state. Use the debug isdn q921 command to ensure that Layer 2 is stable.

At this time, use the show controllers t1 command to check the T1 again, and ensure that there are no
errors. If there are errors, refer to the T1 Troubleshooting flowchart.

In the sample show isdn status output, notice that T1 0 (whose D channel is Serial 0:23) has Layer 1
as ACTIVE and Layer 2 as MULTIPLE_FRAME_ESTABLISHED to indicate that the signaling
channel functions correctly and exchanges Layer 2 frames with the Telco switch. The D channel
(Serial1:23) for T1 1 has Layer 1 ACTIVE, but Layer 2 is TEI_ASSIGNED, which indicates that the
PRI does not exchange Layer 2 frames with the switch. Use the show controller t1 x command to
first check the controller t1 circuit, and verify whether it is clean (that is, it has no errors) before you
troubleshoot ISDN Layer 2 problem with the debug isdn q921. Refer to the T1 Troubleshooting
flowchart for more information

Use the debug isdn q921 Command

This debug command is useful when you troubleshoot ISDN Layer 2 signaling problems. The debug isdn
q921 command displays data link layer (Layer 2) access procedures that occur at the router on the D−channel.
This can indicate whether the problem lies with the NAS, the Telco switch or the line.

Use the logging console or terminal monitor command to ensure you are configured to view debug
messages.

Note: In a production environment, use the show logging command to ensure that console logging is
disabled. If logging console is enabled, the access server can intermittently stop working when the console
port is overloaded with log messages. Enter the no logging console command to disable logging on the
console port. Refer to Important Information on Debug Commands for more information.

Note: If debug isdn q921 is turned on and you do not receive any debug outputs, first check and make sure
you have enabled terminal monitor. Then try to reset the controller or the D−channel to get debug outputs.
You can use the clear controller t1 x or clear interface serial x:23 command to reset the line.

Complete these steps to ensure that the data link layer access procedures occur at the router on the D−channel:

1. Verify whether Layer 2 is stable. To do so, look for messages in the debug output. Here is the debug
isdn q921 output when T1 controller goes through a shutdown and no shutdown:

Mar 20 10:06:07.882: %ISDN−6−LAYER2DOWN: Layer 2 for Interface Se0:23,

TEI 0 changed to down
Mar 20 10:06:09.882: %LINK−3−UPDOWN: Interface Serial0:23,
changed state to down
Mar 20 10:06:21.274: %DSX1−6−CLOCK_CHANGE:
Controller 0 clock is now selected as clock source
Mar 20 10:06:21.702: %ISDN−6−LAYER2UP: Layer 2 for Interface Se0:23,
TEI 0 changed to up
Mar 20 10:06:22.494: %CONTROLLER−5−UPDOWN: Controller T1 0,
changed state to up
Mar 20 10:06:24.494: %LINK−3−UPDOWN: Interface Serial0:23,
changed state to up

If the line bounces up and down, output similar to this is displayed:

%ISDN−6−LAYER2DOWN: Layer 2 for Interface Se0:23, TEI 0 changed to down

%LINK−3−UPDOWN: Interface Serial0:23, changed state to down
 %ISDN−6−LAYER2UP: Layer 2 for Interface Se0:23, TEI 0 changed to up
%LINK−3−UPDOWN: Interface Serial0:23, changed state to up
%ISDN−6−LAYER2DOWN: Layer 2 for Interface Se0:23, TEI 0 changed to down
%LINK−3−UPDOWN: Interface Serial0:23, changed state to down
2. If Layer 2 is stable, the router and switch must begin to synchronize with each other. The Set
Asynchronous Balanced Mode Extended (SABME) message appears on the display. This message
indicates that Layer 2 tries to initialize with the other side. Either side can send the message and try to
initialize with the other side. If the router receives the SABME message, it must send back an
Unnumbered Acknowledge frame (UAf). The router then changes the Layer 2 status to
MULTIPLE_FRAME_ESTABLISHED. Here is an example:

*Apr 12 04:14:43.967: ISDN Se0:23: RX <− SABMEp c/r=1 sapi=0 tei=0

*Apr 12 04:14:43.971: ISDN Se0:23: TX −> UAf c/r=1 sapi=0 tei=0

If the switch receives and recognizes the UAf, both devices synchronize, and periodic keepalives are
exchanged between the router and the ISDN switch. These messages are in the form of Receiver
Ready (RRf and RRp). These keepalives are seen ten seconds apart, and ensure that both sides are
able to communicate with each other. For example:

*Apr 12 05:19:56.183: ISDN Se0:23: RX <− RRp sapi=0 tei=0 nr=18

*Apr 12 05:19:56.183: ISDN Se0:23: TX −> RRf sapi=0 tei=0 nr=18

*Apr 12 05:20:06.247: ISDN Se0:23: RX <− RRp sapi=0 tei=0 nr=18

*Apr 12 05:20:06.247: ISDN Se0:23: TX −> RRf sapi=0 tei=0 nr=18

*Apr 12 05:20:16.311: ISDN Se0:23: RX <− RRp sapi=0 tei=0 nr=18

*Apr 12 05:20:16.311: ISDN Se0:23: TX −> RRf sapi=0 tei=0 nr=18

Please note the TX and RX and the arrow. TX indicates that the router transmits the signal toward the
switch. RX means the router receives the signal from the switch.
3. At times, the D−channel does not come up correctly and stays in TEI_ASSIGNED state, or Layer 2
bounces up and down. This could be caused by one way transmission or missed keepalive packets.
When either side misses four consecutive keepalives, the respective side tries to initialize the Layer 2
link again. To achieve this, the side re−sends the SABME message and starts the process over again.
In such a situation, you must find out whether those keepalives are actually placed on the wire and
whether one side does not respond to the keepalives when it receives them.

To isolate the problem, use the debug isdn q921 and show interface serial x:23 commands, and
complete these steps on the router and with T1 service provider (Telco):

a. Execute show interface serial x:23 several times, and ensure the output counter does
increment and there are no input/output drops or errors.
b. Create a T1 loopback plug and then plug it into the T1 port that you want to troubleshoot. The
debug isdn q921 output must indicate that the SABME was sent, and this message was
received:

RX <− BAD FRAME(0x00017F)Line may be looped!

If no debugs appear, perform a shutdown and no shutdown on the corresponding T1

controller.

The BAD FRAME messages indicate that the router performs correctly. The router sends out
the SABME packet. The message is looped back to the router, because of which, the router
receives the same SABME message that was sent. The router marks it as a BAD FRAME,
 and presents the error message. The error message states that the line is probably looped. This
is the expected behavior for the looped circuit. Therefore, the problem lies within the Telco
ISDN switch or the cabling from the demarc to the Telco switch.

However, if the line is looped back and the router sends out SABMEs but does not receive
them back, there can be a problem with the physical hardwire loopback plug or the router
interface itself. Refer to Hard Plug Loopback Tests for T1/56K Lines and verify whether you
can ping the router from the same router with the help of the hardwire loopback test. If you
cannot ping the router, there can be a hardware problem with the T1 controller. In such a case,
call the TAC for assistance. If you are able to ping the router, proceed to step c.
c. After you have isolated and tested the router and the T1 ports and confirmed that they are
good, you need to engage the Telco to troubleshoot further.

◊ Contact the Telco and enquire as to why the switch does not respond to the keepalive.
Also have the Telco check to see if they see the keepalive messages or any incoming
ISDN Layer 2 message from the router.
◊ Perform the loopback test again, but this time extend the loopback test to the Telco
switch. This procedure is described in the Hard Plug Loopback Tests for T1/56K
Lines document.
◊ Ask the Telco switch technician to place a loop on the line, and then test if the router
can still ping itself.
◊ If the router cannot ping itself, there can be a problem with the wiring of the circuit
toward the Telco ISDN switch. Refer to Hard Plug Loopback Tests for T1/56K Lines
for more information.
◊ If the router can ping itself, the loopback test is successful. Undo the loopback
configuration and change the controller configuration from channel−group to
pri−group.

maui−nas−03(config)#controller t1 0
maui−nas−0(config−controller)#no channel−group 0
maui−nas−0(config−controller)#pri−group timeslots 1−24
◊ Perform a shutdown and no shutdown to the controller and check to see if the router
sends this out:

ISDN Se0:23: TX −> SABMEp sapi = 0 tei = 0

and receives this:

RX <− BAD FRAME(0x00017F)Line may be looped!

If this occurs, the router functions properly and the transmit and received path toward
Telco is fine. The problem lays within the ISDN switch or the ISDN network.
However, if the router sends:

ISDN Se0:23: TX −> SABMEp sapi = 0 tei = 0

and does not receive this:

RX <− BAD FRAME(0x00017F)Line may be looped!

please call TAC for further assistance.

Troubleshoot Further
When you resolve all Layer 2 issues associated with the PRI, and confirm that the hardware works fine, you
must troubleshoot ISDN Layer 3. Refer to Troubleshooting ISDN BRI Layer 3 using the debug isdn q931
Command for more information.

Note: Even though the document discusses Layer 3 Troubleshooting for BRIs, you can apply the same
concepts to Layer 3 PRI troubleshooting. You can also refer to Understanding debug isdn q931 Disconnect
Cause Codes to interpret the Layer 3 disconnect reason.

Related Information
• T1 Alarm Troubleshooting
• Hard Plug Loopback Tests for T1/56K Lines
• T1 Error Events Troubleshooting
• T1/E1 Controller Commands
• Serial Port and T1/E1 Trunk Configuration
• Configuring Channelized E1 and Channelized T1
• Technical Support & Documentation − Cisco Systems

Contacts & Feedback | Help | Site Map

© 2012 − 2013 Cisco Systems, Inc. All rights reserved. Terms & Conditions | Privacy Statement | Cookie Policy | Trademarks of
Cisco Systems, Inc.

Updated: Jun 05, 2005 Document ID: 8131