Troubleshoot T1 PPRI

Introduction

This document describes how to troubleshoot and ensure that a Primary Rate Interface (PRI) T1 runs correctly.

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, ensure that you understand the potential impact of any command.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Background Information

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 interfacecounters 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

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 Use the debug q921 Commandsection.

   If Layer 2 is not in the MULTIPLE_FRAME_ESTABLISHED state, use thedebug isdn q921command 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 Troubleshootingflowchart.

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 xcommand 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 its functions 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 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
   
   

   

   Note: See the TX, 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):

   1. Execute show interface serial x:23 several times, and ensure the output counter does increment and there are no input/output drops or errors.

   2. 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 ashutdown 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 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.

   3. 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 Loopback Tests for T1/56K Lines article.

      • 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 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 ashutdown 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!

        Call the TAC Support for further assistance.

Troubleshoot ISDN Layer 3

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 Troubleshoot ISDN BRI Layer 3 with 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 Understand debug isdn q931 Disconnect Cause Codes to interpret the Layer 3 disconnect reason.

Related Information

• T1 Alarm Troubleshooting
• Loopback Tests for T1/56K Lines
• T1 Error Events Troubleshooting
• Cisco Technical Support & Downloads