Troubleshoot E1 PRI

Introduction

This document describes how to troubleshoot E1 PRI.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

The information in this document is based on the software and hardware versions below.

• Cisco IOS® Software Release 12.0

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, see the .

Background Information

When troubleshooting a Primary Rate Interface (PRI), ensure that the E1 is running properly on both ends. If Layer 1 problems have been resolved, look for problems on Layers 2 and 3. Use the show controller e1 command to verify that the configuration of the line matches that of the remote end. Ensure that the framing, line coding, and clock source are configured correctly. Refer to the and documents for more information. Contact your Service Provider for the correct settings.

Using the show isdn status Command

The show isdn status command displays a summary of all ISDN interfaces. It also displays the status of Layers 1, 2, and 3. Complete the next steps to check the status of the layers:

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

   If the show isdn status command output indicates that Layer 1 is DEACTIVATED, then there is a problem with the physical connectivity of the E1 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 desired state for Layer 2, indicating that Layer 2 frames are being exchanged and Layer 2 initialization has finished.

   If Layer 2 is not in the MULTIPLE_FRAME_ESTABLISHED state, use the show controller e1 EXEC command to diagnose the problem. For more information, see the E1 Alarm Troubleshooting document.

   Since the show isdn status command displays a summary of the current status, it is possible that Layer 2 is bouncing up and down despite indicating a MULTIPLE_FRAME_ESTABLISHED state. Use the debug isdn q921 command to verify that Layer 2 is stable.

   Next is an example of show isdn status output:

   bru-nas-03#show isdn status
   Global ISDN Switchtype = primary-net5
   ISDN Serial0:15 interface
           dsl 0, interface ISDN Switchtype = primary-net5
       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:  0xFFFF78FC
   ISDN Serial1:15 interface
           dsl 1, interface ISDN Switchtype = primary-net5
       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:  0xFFFF7FFF
       Total Allocated ISDN CCBs = 5

   Notice that E1 0 (whose D-channel is Serial 0:15) has Layer 1 as ACTIVE and Layer 2 as MULTIPLE_FRAME_ESTABLISHED indicating that the signaling channel is functioning correctly and is exchanging Layer 2 frames with the Telco switch. The D-channel (Serial1:15) for E1 1 has Layer 1 ACTIVE, but Layer 2 is TEI_ASSIGNED. This indicates that the PRI is not exchanging Layer 2 frames with the switch. Use the show controller e1 x command to troubleshoot. Refer to the flowchart for more information.

Using the debug q921 Command

The debug isdn q921 command displays data link layer (Layer 2) access procedures that are occurring at the router on the D-channel.

Ensure you are configured to view debug messages by using the logging console or terminal monitor command.

Note: In a production environment, verify that console logging is disabled by using the show logging command. If logging 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.

Note: If debug isdn q921 is turned on and you do not receive any debug outputs, place a call or reset the controller to get debug outputs.

Complete the next steps to ensure that the data link layer access procedures are occurring at the router on the D-channel:

1. Verify that Layer 2 is stable by looking for messages in the debug output. If the line is bouncing up and down, output similar to the next can appear:

   Mar 20 10:06:07.882: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0:15, TEI 0 changed to down
   Mar 20 10:06:09.882: %LINK-3-UPDOWN: Interface Serial0:15, 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:15, TEI 0 changed to up
   Mar 20 10:06:22.494: %CONTROLLER-5-UPDOWN: Controller E1 0, changed state to up
   Mar 20 10:06:24.494: %LINK-3-UPDOWN: Interface Serial0:15, changed state to up
   
   

   If Layer 2 does not appear to be stable, refer to the document.

2. Verify that only service access point identifier (SAPI) messages appear on both the transmit (TX) and receive (RX) sides. For example:

   Mar 20 10:06:52.505: ISDN Se0:15: TX -> RRf sapi = 0 tei = 0 nr = 0
   Mar 20 10:06:52.505: ISDN Se0:15: RX <- RRf sapi = 0 tei = 0 NR = 0
   Mar 20 10:07:22.505: ISDN Se0:15: TX -> RRp sapi = 0 tei = 0 NR = 0
   Mar 20 10:07:22.509: ISDN Se0:15: RX <- RRp sapi = 0 tei = 0 NR = 0
   Mar 20 10:07:22.509: ISDN Se0:15: TX -> RRf sapi = 0 tei = 0 NR = 0
   Mar 20 10:07:22.509: ISDN Se0:15: RX <- RRf sapi = 0 tei = 0 NR = 0 
   
   

3. Verify that asynchronous balanced mode extended (SABME) messages do not appear. These messages indicate that Layer 2 is trying to reinitialize. The messages usually appear when poll requests (RRp) are transmitted and there is no response from the switch (RRf), or vice versa. Next are examples of SABME messages:

   Mar 20 10:06:21.702: ISDN Se0:15: RX <- SABMEp sapi = 0 tei = 0
   Mar 20 10:06:22.494: ISDN Se0:15: TX -> SABMEp sapi = 0 tei = 0
   
   

   If SABME messages appear, complete the next steps:

   1. Use the show running-config command to ensure that isdn switch-type and pri-group timeslots are configured correctly. Contact your Service Provider for the correct values.

   2. To change the isdn switch-type and pri-group settings, enter the next commands:

      bru-nas-03#configure terminal
      bru-nas-03(config)#isdn switch-type primary-net5
      bru-nas-03(config)#controller e1 0
      bru-nas-03(config-controlle)#pri-group timeslots 1-31
      
      

4. Ensure the D-channel is up using the show interfaces serial number:15 command, where the number is the interface number.

   If the D-channel is not up, use the no shutdown command to bring it up. For example:

   bru-nas-03(config)#interface serial 0:15
   bru-nas-03(config-if)#no shutdown
   

5. Ensure encapsulation is PPP. If not, use the encapsulation ppp command to set encapsulation. For example:

   bru-nas-03(config-if)#encapsulation ppp
   

6. Ensure the interface is in loopback mode. Loopback must be set only for testing purposes. Use the no loopback command to remove loopbacks. For example:

   bru-nas-03(config-if)#no loopback 
   

7. Power cycle the router.

If the problem persists, contact your Service Provider or the Cisco Technical Assistance Center (TAC).

Related Information

• Cisco Technical Support & Download