Solucionar problemas de PPRI de T1

Introducción

En este documento se describe cómo solucionar problemas y garantizar que una interfaz de velocidad principal (PRI) T1 se ejecute correctamente.

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Convenciones

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

Antecedentes

Cuando resuelva problemas relacionados con una interfaz de velocidad primaria (PRI), asegúrese de que T1 se ejecute correctamente en ambos extremos. Esto debe ser así porque la señalización PRI de ISDN fluye por encima de la capa física T1. Para verificar si la Capa 1 de T1 se ejecuta correctamente, utilice el comando show controller t1 . Asegúrese de que no exista ningún error en los contadores. Cerciórese de que framing (tramas), line coding (codificación de líneas) y clock source (fuente de reloj) estén configurados de manera adecuada. Para obtener más información, refiera al diagrama de flujo de Troubleshooting de T1. Contacte a su proveedor de servicio para obtener la configuración correcta.

Si ya ha solucionado los problemas en la Capa 1 y los contadores de show controller t1 indican cero, puede centrarse en las Capas 2 y 3 de la señalización de PRI de ISDN.

Sugerencia: puede utilizar el comando clear counters para restablecer los contadores T1. Cuando los contadores ya se han despejado, es muy fácil observar si la línea T1 está experimentando algún error. Sin embargo, recuerde que este comando también borra todos los otros contadores show interface. Aquí tiene un ejemplo:

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

Uso del comando show isdn status

El comando show isdn status es muy útil para resolver problemas relacionados con la señalización de ISDN. El comando show isdn status muestra un resumen del estado actual de todas las interfaces ISDN y también el estado de las Capas 1, 2 y 3. A continuación se muestra un ejemplo de la salida del comando show isdn status:

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 estos pasos para verificar el estado de las capas:

1. Verifique que la Capa 1 se encuentre en el estado ACTIVE. El estado de la Capa 1 siempre debe ser ACTIVE a menos que T1 no esté funcionando.

   Si la salida del comando show isdn status indica que la Capa 1 está DEACTIVATED, significa que existe un problema con la conectividad física de la línea T1. Si la línea está administrativamente inactiva, utilice el comando no shutdown para reiniciar la interfaz.

2. Asegúrese de que la Capa 2 se encuentre en el estado MULTIPLE_FRAME_ESTABLISHED. Este es el estado necesario para la Capa 2. Este estado indica que el router recibió un mensaje SABME (Set Asynchronous Balanced Mode Extended) de ISDN y respondió con una trama UA (Unnumbered Acknowledge) para sincronizar con el switch de la compañía telefónica. Además, debe haber un intercambio constante de tramas de Capa 2 (Receiver Ready, RR) entre los dos dispositivos. Cuando esto ocurra, el router y el switch ISDN habrán iniciado por completo el protocolo de Capa 2 de ISDN. Para obtener información sobre cómo identificar los mensajes SABME y RR, vea la sección Uso del comando debug q921.

   Si la Capa 2 no está en el estado MULTIPLE_FRAME_ESTABLISHED, utilice el comando debug isdn q921 para diagnosticar el problema.

   Además, el comando show isdn status muestra un resumen del estado actual. Por lo tanto, la Capa 2 puede mostrarse inestable aunque su estado indique MULTIPLE_FRAME_ESTABLISHED. Utilice el comando debug isdn q921 para asegurarse de que la Capa 2 está estable.

   Ahora, utilice el comando show controllers t1 para verificar la T1 otra vez y asegúrese de que no existen errores. Si hay errores, consulte el diagrama de flujo de Troubleshooting de T1.

En el comando show isdn status output de ejemplo, observe que T1 0 (cuyo canal D es Serial 0:23) tiene la Capa 1 como ACTIVE y la Capa 2 como MULTIPLE_FRAME_ESTABLISHED para indicar que el canal de señalización funciona correctamente e intercambia las tramas de la Capa 2 con el switch de la compañía telefónica. El canal D (Serial1:23) para T1 1 tiene la Capa 1 ACTIVE, pero la Capa 2 es TEI_ASSIGNED, que indica que el PRI no intercambia las tramas de la Capa 2 con el switch. Utilice el comando show controller t1 xpara verificar primero el circuito t1 del controlador y verificar si está limpio (es decir, no tiene errores) antes de resolver el problema de la Capa 2 de ISDN con el comando debug isdn q921. Para obtener más información consulte el Diagrama de flujo de resolución de problemas de T1.

Uso del comando debug isdn q921

Este comando debug es útil cuando se resuelven problemas relacionados con la señalización de la Capa 2 de ISDN. El comando debug isdn q921 muestra procedimientos de acceso a la capa de link de datos (Capa 2) que se producen en el router del canal D. Esto puede indicar si el problema se debe al NAS, al switch de la compañía telefónica o a la línea.

Utilice el comando logging console o el comando terminal monitor para asegurarse de dispone de la configuración correcta para ver mensajes de debug.

Nota: En un entorno de producción, utilice el comando show logging para asegurarse de que el registro de la consola esté inhabilitado. Si la consola de registro está habilitada, el servidor de acceso puede detener intermitentemente sus funciones cuando el puerto de la consola está sobrecargado con mensajes de registro. Ingrese el comando no logging console para desactivar el inicio de sesión en el puerto de la consola. Consulte la información importante sobre comandos de depuración para más detalles.

Nota: Si debug isdn q921 está activado y no recibe ninguna salida de depuración, primero verifique y asegúrese de que ha habilitado el monitor de terminal. Luego, intente restablecer el controlador o el canal D para obtener salidas de depuración. Puede utilizar el comando clear controller t1 o clear interface serial x:23 para restablecer la línea.

Complete estos pasos para asegurarse de que los procedimientos de acceso de la capa del link tienen lugar en el router en el Canal D:

1. Verifique si la Capa 2 es estable. A tal efecto, busque los mensajes en la salida de debug. A continuación se muestra la salida de debug isdn q921 cuando se realiza un apagado y no apagado en el controlador T1:

   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

   Si la línea se muestra inestable, se mostrará una salida similar a la siguiente:

   %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. Si la Capa 2 es estable, el router y el switch deben comenzar a sincronizarse entre sí. El mensaje Set Asynchronous Balanced Mode Extended (SABME) aparece en la pantalla. Este mensaje indica que la Capa 2 intenta inicializarse con el otro lado. Cualquier lado puede enviar el mensaje e intentar iniciarse con el otro. Si el router recibe el mensaje SABME, debe devolver una trama de Reconocimiento sin numerar (UAf). A continuación, el router cambiará el estado de Capa 2 a MULTIPLE_FRAME_ESTABLISHED. Aquí tiene un ejemplo:

   *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
   
   

   Si el switch recibe y reconoce la trama UAf, ambos dispositivos se sincronizarán y se intercambiarán paquetes keepalive periódicos entre el router y el switch ISDN. Estos mensajes se encuentran en la forma Receiver Ready (RRf y RRp). Estos paquetes keepalive se muestran con diez segundos de intervalo y garantizan que ambos lados son capaces de comunicarse entre sí. Por ejemplo:

   *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
   
   

   

   Nota: Consulte TX, RX y la flecha. TX indica que el router está transmitiendo la señal hacia el switch. Rx significa que el router está recibiendo la señal desde el switch.

3. Hay ocasiones en las que el canal D no se activa correctamente y permanece en el estado TEI_ASSIGNED, o la Capa 2 se muestra inestable. Esto puede ser debido a una transmisión unidireccional o a la falta de paquetes keepalive. Cuando algún lado pierde cuatro paquetes keepalive de forma consecutiva, el lado en cuestión intenta volver a inicializar el link de la Capa 2. Para conseguirlo, el lado vuelve a enviar el mensaje SABME y el proceso vuelve a empezar otra vez. En este tipo de situaciones, es necesario averiguar si estos paquetes keepalive se transmiten realmente por la línea y si uno de los lados no responde a los paquetes keepalive cuando los recibe.

   Para aislar el problema, utilice los comandos debug isdn q921 y show interface serial x:23 y complete estos pasos en el router y con el proveedor del servicio de T1 (compañía telefónica):

   1. Ejecute show interface serial x:23 varias veces y asegúrese de que el contador de salida se incremente y que no haya descartes de entrada o salida ni errores.

   2. Cree un Loopback Plug T1 y, a continuación, conéctelo en el puerto T1 en el que desee resolver problemas. La salida de debug isdn q921 debe indicar que SABME se ha enviado y que este mensaje se ha recibido:

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

      Si no aparecen depuraciones, realice un apagado y no cierre en el controlador T1 correspondiente.

      Los mensajes BAD FRAME indican que el router funciona correctamente. El router envía el paquete SABME. El mensaje se vuelve a enviar en loop al router y, como consecuencia de ello, el router recibe el mismo mensaje SABME que se ha enviado. El router lo marca como BAD FRAME y muestra el mensaje de error. El mensaje de error indica que la línea ha entrado probablemente en un loop. Esta es la conducta esperada del circuito con loop. Por lo tanto, el problema reside en el switch ISDN de la compañía telefónica o en el cableado del punto de demarcación con el switch de la compañía telefónica.

      No obstante, si la línea entre en un loopback y el router envía SABMEs pero no los vuelve a recibir, es posible que exista un problema con el conector de loopback de cableado físico o la propia interfaz del router. Consulte Pruebas de Loopback para Líneas T1/56K y verifique si puede hacer ping al router desde el mismo router con la ayuda de la prueba de loopback de cableado. Si no puede hacer ping en el router, es posible que exista un problema de hardware con el controlador T1. En tal caso, llame al TAC para recibir asistencia. Si puede hacer ping en el router, proceda al paso c.

   3. Una vez aislado y probado el router y los puertos T1 y confirmado que se encuentran en buen estado, es preciso implicar a la compañía telefónica para que realice un troubleshooting más exhaustivo.

      • Comuníquese conTelco y consulte por qué el switch no responde a la señal de mantenimiento. Asimismo, solicite a la compañía telefónica que verifique si puede ver los mensajes keepalive o cualquier mensaje de Capa 2 de ISDN entrante desde el router.

      • Lleve a cabo la prueba de loopback nuevamente, pero esta vez amplíela hasta el switch de la compañía telefónica. Este procedimiento se describe en el artículo Pruebas de loopback para líneas T1/56K.

      • Solicite al técnico del switch de la compañía telefónica que coloque un loop en la línea y verifique si todavía es posible hacer un ping del propio router.

      • Si el router no puede ejecutar un ping a sí mismo, es posible que exista un problema con el cableado del circuito hacia el switch ISDN de la compañía telefónica. Consulte Pruebas de Loopback para Líneas T1/56K para obtener más información.

      • Si el router puede ejecutar un ping a sí mismo, la prueba de loopback se considera superada. Deshaga la configuración del loopback y cambie la configuración del controlador de channel-group a 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
        

      • Realice un apagado y no apagado al controlador y verifique si el router envía esto:

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

        y recibe lo siguiente:

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

        Si ocurre esto, significa que el router funciona correctamente y que la trayectoria de transmisión y recepción con la compañía telefónica es correcto. El problema reside en el switch ISDN o la red ISDN. No obstante, si el router envía:

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

        y no recibe lo siguiente:

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

        Llame al Soporte del TAC para obtener más ayuda.

Troubleshooting de Capa 3 ISDN

Cuando resuelva todos los problemas de Capa 2 asociados con el PRI y confirme que el hardware funciona correctamente, debe resolver los problemas de Capa 3 de ISDN. Consulte Troubleshooting de la Capa 3 de ISDN BRI con el Comando debug isdn q931 para obtener más información.

Nota: Aunque el documento trata la resolución de problemas de la Capa 3 para BRI, puede aplicar los mismos conceptos a la resolución de problemas de la Capa 3 PRI. También puede consultar Comprensión de los Códigos de Causa de Desconexión debug isdn q931 para interpretar el motivo de desconexión de la Capa 3.

Información Relacionada

• Resolución de problemas de la alarma T1
• Prueba de loopback para las líneas T1/56K
• Resolución de problemas de eventos de error T1
• Soporte técnico y descargas de Cisco