Resolución de problema de conectividad de tecnología de marcado – IOS DDR inicia las llamadas

Introducción

Este documento proporciona métodos para solucionar problemas de diferentes tipos de conexiones de marcado y no está pensado para ser leído de principio a fin. La estructura está diseñada para permitir al lector avanzar a las secciones de interés, cada una de las cuales son variaciones en el tema general de solución de problemas para un caso específico.

Prerequisites

Requirements

Este documento abarca tres escenarios principales: antes de comenzar a solucionar el problema, determine qué tipo de llamada se está intentando y vaya a esa sección:

• Callin

• Cisco IOS Dial-On-Demand Routing (DDR)

• Llamada sin DDR

Componentes Utilizados

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

La información que se presenta en este documento se originó a partir de dispositivos dentro de un ambiente de laboratorio específico. All of the devices used in this document started with a cleared (default) configuration. Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.

Historial

Dialup es simplemente la aplicación de la Red de Telefonía Pública Conmutada (PSTN) que transporta datos en nombre del usuario final. Implica un dispositivo Customer Premises Equipment (CPE) que envía al switch de teléfono un número de teléfono al cual dirigir una conexión. Los AS3600, AS5200, AS5300 y AS5800 son ejemplos de routers que tienen la capacidad de ejecutar una interfaz de velocidad primaria (PRI) junto con bancos de módems digitales. El AS2511, por otra parte, es un ejemplo de router que se comunica con módems externos.

El mercado de los operadores ha crecido significativamente y el mercado exige ahora mayores densidades de módem. La respuesta a esta necesidad es un mayor grado de interoperación con el equipo de la compañía telefónica y el desarrollo del módem digital. Se trata de un módem capaz de acceder directamente a la red PSTN. Como resultado, se han desarrollado módems CPE más rápidos que aprovechan la claridad de la señal que disfrutan los módems digitales. El hecho de que los módems digitales que se conectan a la PSTN a través de una PRI o una Interfaz de velocidad básica (BRI) puedan transmitir datos a más de 53.000 usando el estándar de comunicación V.90, da fe del éxito de la idea.

Los primeros servidores de acceso fueron el AS2509 y el AS2511. El AS2509 podría soportar 8 conexiones entrantes usando módems externos, y el AS2511 podría soportar 16. El AS5200 se introdujo con 2 PRI y podía admitir 48 usuarios usando módems digitales, y representaba un gran avance en tecnología. Las densidades de los módems han aumentado constantemente con el AS5300 que admite 4 y luego 8 PRI. Por último, el AS5800 se introdujo para cubrir las necesidades de las instalaciones de clase de operador que necesitaban gestionar decenas de T1 entrantes y cientos de conexiones de usuario.

Un par de tecnologías obsoletas merecen mención en un debate histórico sobre la tecnología del marcador. 56Kflex es un estándar de módem de 56k más antiguo (anterior a V.90) propuesto por Rockwell. Cisco admite la versión 1.1 del estándar 56Kflex en sus módems internos, pero recomienda migrar los módems CPE a V.90 lo antes posible. Otra tecnología obsoleta es el AS5100. El AS5100 fue una empresa conjunta entre Cisco y un fabricante de módem. El AS5100 se creó como una manera de aumentar la densidad del módem mediante el uso de tarjetas de cuatro módems. Se trataba de un grupo de AS2511s construido como tarjetas que se insertaban en una placa de interconexiones compartida por tarjetas de cuatro módems y una tarjeta T1 dual.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.

Cisco IOS DDR inicia la llamada

Mientras que el enfoque de solución de problemas para las llamadas entrantes comienza en la parte inferior, la resolución de problemas de una conexión saliente comienza en la parte superior.

El flujo general de razonamiento se asemeja al siguiente:

1. ¿El enrutamiento de marcado a petición (DDR) inicia una llamada? (Una respuesta afirmativa avanza a la siguiente pregunta.)

2. Si se trata de un módem asincrónico, ¿los scripts de chat emiten los comandos esperados?

3. ¿La llamada llega a PSTN?

4. ¿El extremo remoto contesta la llamada?

5. ¿Se ha completado la llamada?

6. ¿Pasan los datos por el enlace?

7. ¿Se ha establecido el período de sesiones? (PPP o Terminal)

Para ver si el marcador está tratando de hacer una llamada a su destino remoto, utilice el comando debug dialer events. Se puede obtener información más detallada de debug dialer packet, pero el comando debug dialer packet requiere muchos recursos y no se debe utilizar en un sistema ocupado que tiene varias interfaces de marcador funcionando.

La siguiente línea de salida de debug dialer events para un paquete IP enumera el nombre de la interfaz DDR y las direcciones de origen y destino del paquete:

Dialing cause: Async1: ip (s=172.16.1.111 d=172.16.2.22)

Si el tráfico no inicia un intento de marcado, la razón más común es una configuración incorrecta (cualquiera de las definiciones de tráfico interesante, el estado de la interfaz del marcador o el ruteo).

Colocación de llamada

Si el enrutamiento y los filtros de tráfico interesantes son correctos, se debe iniciar una llamada. Esto se puede ver usando eventos debug dialer:

Async1 DDR: Dialing cause ip (s=10.0.0.1, d=10.0.0.2)



Async1 DDR: Attempting to dial 5551212

Si se ve la causa de marcación pero no se intenta marcar, la razón habitual es un mapa de marcador o perfil de marcador mal configurado.

Dialer1: Can't place call, no dialer pool set

A continuación, identifique el tipo de medio que se está utilizando:

• DDR de módem asíncrono externo

• DDR de módem asíncrono T1/E1 de señalización asociada al canal (CAS)

• DDR de módem asincrónico de PRI

• DDR de módem asíncrono BRI

• PRI ISDN DDR

• BRI ISDN DDR

DDR de módem asíncrono externo

1. Para identificar un DDR de módem asíncrono externo, utilice los siguientes comandos y luego intente realizar una llamada:

   router# debug modem
   router# debug chat line  
            
   
   

2. Para las llamadas de módem, se debe ejecutar una secuencia de comandos de conversación para que la llamada continúe. Para DDR basado en correspondencia de marcador, el script de chat es invocado por el parámetro modem-script en un comando dialer map. Si DDR se basa en el perfil del marcador, esto se logra mediante el comando script dialer, configurado en la línea TTY. Ambos métodos se basan en un script de chat existente en la configuración global del router, por ejemplo:

   chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c
   

   En cualquier caso, el comando para ver la actividad del script de chat es debug chat. Si la cadena de marcado (es decir, número de teléfono) utilizada en el comando dialer map o dialer string fueran 5551212, el resultado de la depuración sería similar al siguiente:

   CHAT1: Attempting async line dialer script
   
   
   CHAT1: Dialing using Modem script: callout & System script: none
   CHAT1: process started
   CHAT1: Asserting DTR
   CHAT1: Chat script callout started
   CHAT1: Sending string: AT
   CHAT1: Expecting string: OK
   CHAT1: Completed match for expect: OK
   CHAT1: Sending string: atdt5551212
   CHAT1: Expecting string: CONNECT
   CHAT1: Completed match for expect: CONNECT
   CHAT1: Chat script callout finished, status = Success
   

3. Asegúrese de que la secuencia de comandos de conversación intente la llamada esperada (es decir, el número correcto) basándose en la "cadena de envío". Si el script de chat no intenta realizar la llamada esperada, verifique la configuración del script de chat. Utilice el comando start-chat en la indicación exec para iniciar el script de chat manualmente.

4. Ver "Tiempo de espera agotado: CONNECT" puede describir varias posibilidades:

   • Posibilidad 1: El módem local no está realizando la llamada. Verifique que el módem pueda realizar una llamada realizando un telnet inverso al módem e iniciando manualmente un marcado. Si el extremo remoto no parece estar respondiendo, verifique que el módem de origen esté realizando la llamada llamando a un número local manualmente con el comando ATDT <number> y escuchando el timbre.

   • Posibilidad 2: El módem remoto no responde. Pruebe esto marcando el módem remoto con un teléfono POTS normal. Intente hacer lo siguiente:

     1. Asegúrese de que el número de teléfono al que se ha llamado es correcto. Utilice un terminal para llamar al número de recepción. Asegúrese de utilizar el mismo cable en la pared que estaba utilizando el módem. Si una llamada manual puede alcanzar el módem asincrónico receptor, es posible que el módem de origen no funcione correctamente. Verifique el módem y reemplace según sea necesario.

     2. Si una llamada manual no puede alcanzar el módem asincrónico de respuesta, cambie los cables telefónicos del módem receptor e intente utilizar un teléfono normal en la línea del módem receptor. Si el teléfono normal puede recibir la llamada, es probable que haya un problema con el módem receptor.

     3. Si la llamada manual todavía no puede alcanzar el teléfono normal en la línea en cuestión, pruebe con otra línea (que se conoce que es buena) en la instalación de recepción. Si se conecta correctamente, haga que la compañía telefónica verifique la línea telefónica que va al módem receptor.

     4. Si se trata de una llamada de larga distancia, haga que el lado de origen intente otro número de larga distancia (conocido como bueno). Si esto funciona, es posible que la línea o la instalación receptora no esté aprovisionada para recibir llamadas de larga distancia. Si la línea de origen no puede alcanzar ningún otro número de larga distancia, es posible que no tenga activada una larga distancia. Pruebe los códigos 1010 para diferentes compañías de larga distancia.

     5. Por último, intente otro número local (conocido) de la línea de origen. Si la conexión todavía falla, haga que la compañía telefónica verifique la línea de origen.

   • Posibilidad 3: El número marcado es incorrecto. Verifique el número marcándolo manualmente. Corrija la configuración, si es necesario.

   • Posibilidad 4: La preparación del módem tarda demasiado o el valor de TIMEOUT es demasiado bajo. Intente aumentar el valor TIMEOUT en el comando chat-script. Si el TIEMPO DE ESPERA ya es de 60 segundos o más, puede haber un problema de cable entre el módem y el DTE al que está conectado. Las fallas de la formación también pueden indicar un problema de circuito o incompatibilidad del módem.

     Para llegar a la parte inferior de un problema de módem individual, vaya al mensaje AT en el módem de origen con Telnet inverso. Si es posible, acceda también al mensaje AT del módem receptor. La mayoría de los módems indicarán un anillo a la sesión de terminal conectada a su conexión DTE. Utilice ATM1 para que el módem envíe sonidos a su altavoz de modo que la gente de cada extremo pueda oír lo que está sucediendo en la línea.

     ¿La música tiene ruido? Si es así, limpie el circuito. Si los módems asincrónicos no se forman, llame al número y escuche estático. Puede haber otros factores que interfieran con la preparación. Telnet inverso al módem asíncrono y debug.

5. Si todo funciona correctamente y todavía no puede conectarse en su DDR de módem asíncrono CAS, intente la depuración PPP. Utilice los comandos:

   router# debug ppp negotiation
        router# debug ppp authentication
   

   Si el script de chat se completa correctamente, los módems están conectados. Consulte la sección "Resolución de problemas de PPP" en el Capítulo 17 de la Guía de Troubleshooting de Internetwork para ver el siguiente paso en la solución de problemas de la conexión.

DDR de módem asincrónico CAS T1/E1

1. Para identificar un DDR de módem asíncrono CAS T1/E1, utilice los siguientes comandos y luego intente realizar una llamada:

   Advertencia:  La ejecución de depuraciones en un sistema ocupado podría provocar un desperfecto en el router al sobrecargar la CPU o al ejecutar en exceso el búfer de consola.

   router# debug modem
   router# debug chat or debug chat line n
   
   router# debug modem csm
   router# debug cas
   

   Nota: ¿El comando debug cas está disponible en las plataformas Cisco AS5200 y AS5300 que ejecutan Cisco IOS? Versión de software 12.0(7)T y posterior. En las versiones anteriores de IOS, el comando service internal tendría que ingresarse al nivel principal de la configuración del router y modem-mgmt csm debug-rbs tendría que ingresarse en el mensaje exec. La depuración en el Cisco AS5800 requiere la conexión a la tarjeta troncal. (Utilice modem-mgmt csm no-debug-rbs para desactivar la depuración.)

2. Para las llamadas de módem, se debe ejecutar una secuencia de comandos de conversación para que la llamada continúe. Para DDR basado en correspondencia de marcador, el script de chat es invocado por el parámetro modem-script en un comando dialer map. Si DDR se basa en el perfil del marcador, esto se logra mediante el comando script dialer, configurado en la línea TTY. Ambos usuarios se basan en un script de chat existente en la configuración global del router, como:

   chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c
   

   En cualquier caso, el comando para ver la actividad del script de chat es debug chat. Si la cadena de marcado (es decir, número de teléfono) utilizada en el comando dialer map o dialer string fueran 5551212, el resultado de la depuración sería similar al siguiente:

   CHAT1: Attempting async line dialer script
   
   
   CHAT1: Dialing using Modem script: callout & System script: none
   CHAT1: process started
   CHAT1: Asserting DTR
   CHAT1: Chat script callout started
   CHAT1: Sending string: AT
   CHAT1: Expecting string: OK
   CHAT1: Completed match for expect: OK
   CHAT1: Sending string: atdt5551212
   CHAT1: Expecting string: CONNECT
   CHAT1: Completed match for expect: CONNECT
   CHAT1: Chat script callout finished, status = Success
   

3. Asegúrese de que la secuencia de comandos de conversación intente la llamada esperada (es decir, el número correcto) basándose en la "cadena de envío". Si el script de chat no intenta realizar la llamada esperada, verifique la configuración del script de chat. Utilice el comando start-chat en la indicación exec para iniciar el script de chat manualmente.

4. Ver "Tiempo de espera agotado: CONNECT" puede describir varias posibilidades:

   • Posibilidad 1: El módem local no está realizando la llamada. Verifique que el módem pueda realizar una llamada realizando una telnet inversa al módem e iniciando manualmente una marcación. Si el extremo remoto no parece estar respondiendo, verifique que el módem esté realizando la llamada llamando a un número local manualmente con el comando ATDT <number> y escuchando el timbre.

     Para las llamadas salientes a través de CAS T1 o E1 y módems digitales integrados, gran parte de la resolución de problemas es similar a otros troubleshooting DDR. Lo mismo se aplica a las llamadas de módem integrado saliente a través de una línea PRI. Las características únicas involucradas en la realización de una llamada de esta manera requieren un debugging especial en caso de una falla de llamada.

     En cuanto a otras situaciones de DDR, debe asegurarse de que se requiera un intento de llamada. Utilice los eventos debug dialer para este propósito. Consulte IOS DDR, anteriormente en este artículo.

     Antes de realizar una llamada, se debe asignar un módem a la llamada. Para ver este proceso y la llamada subsiguiente, utilice los siguientes comandos debug:

     router# debug modem
     router# debug modem csm
     router# debug cas 
     

     Nota: El comando debug cas apareció por primera vez en la versión 12.0(7)T del IOS para AS5200 y AS5300. Las versiones anteriores de IOS utilizan un comando de configuración de nivel del sistema service internal junto con el comando exec modem-mgmt debug rbs:

     Activación de los depuradores:

     router#conf t 
     Enter configuration commands, one per line.  End with CNTL/Z. 
     router(config)#service internal 
     router(config)#^Z 
     router#modem-mgmt csm ? 
       debug-rbs     enable rbs debugging 
       no-debug-rbs  disable rbs debugging 
     router#modem-mgmt csm debug-rbs 
     router# 
     neat msg at slot 0: debug-rbs is on 
     neat msg at slot 0: special debug-rbs is on 
     

     Desactivación de Depuraciones:

     router#modem-mgmt csm no-debug-rbs 
     neat msg at slot 0: debug-rbs is off 

     La depuración de esta información en un AS5800 requiere la conexión a la tarjeta troncal. El siguiente es un ejemplo de una llamada saliente normal sobre un CAS T1 que se aprovisiona y configura para FXS-Ground-Start:

     Mica Modem(1/0): Rcvd Dial String(5551111) 
     [Modem receives digits from chat script]
     
     CSM_PROC_IDLE: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 0 
     
     CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
     EVENT_CHANNEL_LOCK at slot 1 and port 0 
     
     CSM_PROC_OC4_DIALING: 
     CSM_EVENT_DSX0_BCHAN_ASSIGNED at slot 1, port 0 
     
     Mica Modem(1/0): Configure(0x1) 
     
     Mica Modem(1/0): Configure(0x2) 
     
     Mica Modem(1/0): Configure(0x5) 
     
     Mica Modem(1/0): Call Setup 
     
     neat msg at slot 0: (0/2): Tx RING_GROUND 
     
     Mica Modem(1/0): State Transition to Call Setup 
     
     neat msg at slot 0: (0/2): Rx TIP_GROUND_NORING 
     [Telco switch goes OFFHOOK]
     
     CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
     EVENT_START_TX_TONE at slot 1 and port 0 
     
     CSM_PROC_OC5_WAIT_FOR_CARRIER: 
     CSM_EVENT_DSX0_START_TX_TONE at slot 1, port 0 
     
     neat msg at slot 0: (0/2): 
     Tx LOOP_CLOSURE [Now the router goes OFFHOOK]
     
     Mica Modem(1/0): Rcvd Tone detected(2) 
     
     Mica Modem(1/0): Generate digits:called_party_num=5551111 len=8 
     
     Mica Modem(1/0): Rcvd Digits Generated 
     
     CSM_PROC_OC5_WAIT_FOR_CARRIER: 
     CSM_EVENT_ADDR_INFO_COLLECTED at slot 1, port 0 
     
     CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
     EVENT_CHANNEL_CONNECTED at slot 1 and port 0 
     
     CSM_PROC_OC5_WAIT_FOR_CARRIER: 
     CSM_EVENT_DSX0_CONNECTED at slot 1, port 0 
     
     Mica Modem(1/0): Link Initiate 
     
     Mica Modem(1/0): State Transition to Connect 
     
     Mica Modem(1/0): State Transition to Link 
     
     Mica Modem(1/0): State Transition to Trainup 
     
     Mica Modem(1/0): State Transition to EC Negotiating 
     
     Mica Modem(1/0): State Transition to Steady State 
     
     Mica Modem(1/0): State Transition to Steady State Speedshifting 
     
     Mica Modem(1/0): State Transition to Steady State
     

     Las depuraciones para T1s y E1s con otros tipos de señalización son similares.

     Llegar a este punto en la depuración indica que los módems de llamada y de respuesta se han entrenado y conectado y que los protocolos de capa superior pueden comenzar a negociar. Si un módem se asigna correctamente para la llamada saliente pero la conexión no llega hasta aquí, se debe examinar la T1. Utilice el comando show controller t1/e1 para verificar que T1/E1 está funcionando. Consulte Resolución de Problemas de Líneas Seriales para obtener una explicación de la salida de show controller . Si el T1/E1 no funciona correctamente, es necesario solucionar problemas de T1/E1.

   • Posibilidad 2: El módem remoto no responde. Pruebe esto marcando el módem remoto con un teléfono normal. Intente hacer lo siguiente:

     1. Asegúrese de que el número de teléfono al que se ha llamado es correcto. Utilice un terminal para llamar al número de recepción.

     2. Asegúrese de que una llamada manual pueda alcanzar el módem asíncrono de respuesta. Si una llamada manual puede alcanzar el módem asíncrono de respuesta, es posible que la línea CAS no esté aprovisionada para permitir llamadas de voz salientes.

     3. Si una llamada manual no puede alcanzar el módem asincrónico de respuesta, cambie los cables telefónicos del módem receptor e intente utilizar un teléfono normal en la línea del módem receptor. Si el teléfono normal puede recibir la llamada, es probable que haya un problema con el módem receptor.

     4. Si la llamada manual todavía no puede alcanzar el teléfono normal en la línea en cuestión, pruebe con otra línea (que se conoce que es buena) en la instalación de recepción. Si se conecta, haga que la compañía telefónica verifique la línea telefónica que va al módem receptor.

     5. Si se trata de una llamada de larga distancia, haga que el lado de origen intente otro número de larga distancia (conocido como bueno). Si esto funciona, es posible que la línea o la instalación receptora no esté aprovisionada para recibir llamadas de larga distancia. Si la línea de origen (CAS) no puede alcanzar ningún otro número de larga distancia, es posible que no tenga activada la opción de larga distancia. Pruebe los códigos 10-10 para diferentes compañías de larga distancia.

     6. Finalmente, intente otro número local (conocido) de la línea CAS de origen. Si la conexión todavía falla, haga que la compañía telefónica verifique el CAS.

   • Posibilidad 3: El número marcado es incorrecto. Verifique el número marcándolo manualmente. Corrija la configuración, si es necesario.

   • Posibilidad 4: La preparación del módem tarda demasiado o el valor de TIMEOUT es demasiado bajo. Intente aumentar el valor TIMEOUT en el comando chat-script. Si el TIEMPO DE ESPERA ya es de 60 segundos o más, puede haber un problema de cable entre el módem y el DTE al que está conectado. Las fallas de la formación también pueden indicar un problema de circuito o incompatibilidad del módem.

     Para llegar a la parte inferior de un problema de módem individual, vaya al mensaje AT en el módem de origen con Telnet inverso. Si es posible, use reverse telnet para llegar al mensaje AT del módem receptor también. Utilice ATM1 para que el módem envíe sonidos a su altavoz de modo que la gente de cada extremo pueda oír lo que está sucediendo en la línea.

     ¿La música tiene ruido? Si es así, limpie el circuito. Si los módems asincrónicos no se forman, llame al número y escuche estático. Puede haber otros factores que interfieran con la preparación. Telnet inverso al módem asíncrono y a la depuración.

5. Si todo funciona correctamente y todavía no puede conectarse en su DDR de módem asíncrono CAS, intente la depuración PPP. Si el script de chat se completa correctamente y las depuraciones PPP indican un error, consulte la sección "Resolución de problemas de PPP" en el Capítulo 17 de la Guía de Troubleshooting de Internetwork.

DDR de módem asincrónico de PRI

1. Para identificar un DDR de módem asíncrono PRI, utilice los siguientes comandos y luego intente realizar una llamada:

   Advertencia:  La ejecución de depuraciones en un sistema ocupado podría provocar un desperfecto en el router al sobrecargar la CPU o al ejecutar en exceso el búfer de consola.

   router# debug modem
   router# debug chat
   router# debug modem csm
   router# debug isdn q931
   router# debug isdn
   router# debug ppp negotiate
   router# debug ppp authenticate
   

2. Para las llamadas de módem, se debe ejecutar una secuencia de comandos de conversación para que la llamada continúe. Para DDR basado en correspondencia de marcador, el script de chat es invocado por el parámetro modem-script en un comando dialer map. Si DDR se basa en el perfil del marcador, esto se logra mediante el comando script dialer, configurado en la línea TTY. Ambos métodos se basan en un script de chat existente en la configuración global del router, como:

   chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

   En cualquier caso, el comando para ver la actividad del script de chat es debug chat. Si la cadena de marcado (número de teléfono) utilizada en el comando dialer map o dialer string fueran 5551212, el resultado de debug sería similar al siguiente:

   CHAT1: Attempting async line dialer script
   
   
   CHAT1: Dialing using Modem script: callout & System script: none
   CHAT1: process started
   CHAT1: Asserting DTR
   CHAT1: Chat script callout started
   CHAT1: Sending string: AT
   CHAT1: Expecting string: OK
   CHAT1: Completed match for expect: OK
   CHAT1: Sending string: atdt5551212
   CHAT1: Expecting string: CONNECT
   CHAT1: Completed match for expect: CONNECT
   CHAT1: Chat script callout finished, status = Success
   

3. Asegúrese de que la secuencia de comandos de conversación intente la llamada esperada (el número correcto) basándose en la "cadena de envío". Si el script de chat no intenta realizar la llamada esperada, verifique la configuración del script de chat. Utilice el comando start-chat en la indicación exec para iniciar el script de chat manualmente.

4. Ver "Tiempo de espera agotado: CONNECT" puede describir varias posibilidades:

   • Posibilidad 1: El módem local no está realizando la llamada. Verifique que el módem pueda realizar una llamada realizando un telnet inverso al módem e iniciando manualmente un marcado. Si el extremo remoto no parece estar respondiendo, verifique que la llamada esté siendo realizada por el módem llamando a un número local manualmente con el comando ATDT <number> y escuchando el timbre. Si no se recibe ninguna llamada, active las depuraciones ISDN. Ante la primera sospecha de una falla ISDN en un BRI, verifique siempre la salida del estado show isdn. Las cosas clave a tener en cuenta son que la Capa 1 debe ser Activa y la Capa 2 debe estar en un estado de MULTIPLE_FRAME_ESTABLISHED. Consulte la Guía de Troubleshooting de Internetwork Capítulo 16, "Interpretación de Mostrar Estado ISDN" para obtener información sobre la lectura de este resultado, así como sobre las medidas correctivas.

     Para las llamadas ISDN salientes, debug isdn q931 y debug isdn events son las mejores herramientas para usar. Afortunadamente, la depuración de llamadas salientes es muy similar a la depuración de llamadas entrantes. Una llamada normal exitosa podría verse de la siguiente manera:

     *Mar 20 21:07:45.025: ISDN SE0:23: Event: 
     Call to 5553759 at 64 Kb/s
     
     *Mar 20 21:07:45.033: ISDN SE0:23: TX ->  SETUP pd = 8  
     callref = 0x2C
     *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
     *Mar 20 21:07:45.041:         Channel ID i = 0x83
     *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
     *Mar 20 21:07:45.141: ISDN SE0:23: RX <-  CALL_PROC pd = 8  
     callref = 0xAC
     *Mar 20 21:07:45.145:         Channel ID i = 0x89
     *Mar 20 21:07:45.157: ISDN SE0:23: received HOST_PROCEEDING
             Channel ID i = 0x0101
     *Mar 20 21:07:45.161:   -------------------
             Channel ID i = 0x89
     *Mar 20 21:07:45.313: ISDN SE0:23: RX <-  CONNECT pd = 8  
     callref = 0xAC
     *Mar 20 21:07:45.325: ISDN SE0:23: received HOST_CONNECT
     

     Tenga en cuenta que el mensaje CONNECT es el indicador clave del éxito. Si no se recibe CONNECT, puede ver un mensaje DISCONNECT o RELEASE_COMP (versión completa) seguido de un código de causa:

     *Mar 20 22:11:03.212: ISDN SE0:23: 
     RX <-RELEASE_COMP pd = 8 callref = 0x8F
     *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected 
     

     El valor de la causa indica dos cosas:

     • El segundo byte del valor de 4 o 6 bytes indica el punto en la trayectoria de llamada de extremo a extremo desde el que se recibió DISCONNECT o RELEASE_COMP. Esto puede ayudarle a localizar el problema.

     • Los bytes tercero y cuarto indican la razón real de la falla. Consulte la tabla 9 para ver los significados de los diferentes valores.

   • Posibilidad 2: El módem remoto no responde. Pruebe esto marcando el módem remoto con un teléfono normal. Intente hacer lo siguiente:

     1. Asegúrese de que el número de teléfono al que se ha llamado es correcto. Utilice un terminal para llamar al número de recepción.

     2. Asegúrese de que una llamada manual pueda alcanzar el módem asíncrono de respuesta. Si una llamada manual puede alcanzar el módem asíncrono de respuesta, es posible que la línea BRI no esté aprovisionada para permitir llamadas de voz salientes.

     3. Si una llamada manual no puede alcanzar el módem asincrónico de respuesta, cambie los cables telefónicos del módem receptor e intente utilizar un teléfono normal en la línea del módem receptor. Si el teléfono normal puede recibir la llamada, es probable que haya un problema con el módem receptor.

     4. Si la llamada manual todavía no puede alcanzar el teléfono normal en la línea en cuestión, pruebe con otra línea (que se conoce que es buena) en la instalación de recepción. Si se conecta, haga que la compañía telefónica verifique la línea telefónica que va al módem receptor.

     5. Si se trata de una llamada de larga distancia, haga que el lado de origen intente otro número de larga distancia (conocido como bueno). Si esto funciona, es posible que la línea o la instalación receptora no esté aprovisionada para recibir llamadas de larga distancia. Si la línea de origen (BRI) no puede alcanzar ningún otro número de larga distancia, es posible que no tenga activada la opción de larga distancia. Pruebe los códigos 1010 para diferentes compañías de larga distancia.

     6. Finalmente, intente otro número local (conocido) de la línea BRI de origen. Si la conexión todavía falla, haga que la compañía telefónica verifique el BRI.

   • Posibilidad 3: El número marcado es incorrecto. Verifique el número marcándolo manualmente. Corrija la configuración, si es necesario.

   • Posibilidad 4: La preparación del módem tarda demasiado o el valor de TIMEOUT es demasiado bajo. Intente aumentar el valor TIMEOUT en el comando chat-script. Si el TIEMPO DE ESPERA ya es de 60 segundos o más, puede haber un problema de cable entre el módem y el DTE al que está conectado. Las fallas de la formación también pueden indicar un problema de circuito o incompatibilidad del módem.

     Para llegar a la parte inferior de un problema de módem individual, vaya al mensaje AT en el módem de origen con Telnet inverso. Si es posible, use reverse telnet para llegar al mensaje AT del módem receptor también. Utilice ATM1 para que el módem envíe sonidos a su altavoz de modo que la gente de cada extremo pueda oír lo que está sucediendo en la línea.

     ¿La música tiene ruido? Si es así, limpie el circuito. Si los módems asincrónicos no se forman, llame al número y escuche estático. Puede haber otros factores que interfieran con la preparación. Telnet inverso al módem asíncrono y a la depuración.

5. Si todo funciona correctamente y todavía no puede conectarse en el DDR del módem asíncrono BRI, intente la depuración PPP. Si el script de chat se completa correctamente y las depuraciones PPP indican un error, consulte la sección "Resolución de problemas de PPP" en el Capítulo 17 de la Guía de Troubleshooting de Internetwork.

DDR de módem asíncrono BRI

Esta función sólo funciona en la plataforma Cisco 3640 con Cisco IOS Software Release 12.0(3)T o posterior. Requiere una revisión posterior del hardware del módulo de red BRI. Esto no funcionará con una tarjeta de interfaz WAN (WIC).

1. Asegúrese de que el código de país es correcto con el comando show modem. Utilice los siguientes comandos y, a continuación, intente realizar una llamada:

   Advertencia:  La ejecución de depuraciones en un sistema ocupado podría provocar un desperfecto en el router al sobrecargar la CPU o al ejecutar en exceso el búfer de consola.

   router# debug modem
   router# debug chat
   router# debug modem csm
   router# debug isdn q931
   router# debug bri
   router# debug ppp negotiate
   router# debug ppp authenticate
   

2. Para las llamadas de módem, se debe ejecutar una secuencia de comandos de conversación para que la llamada continúe. Para DDR basado en correspondencia de marcador, el script de chat es invocado por el parámetro modem-script en un comando dialer map. Si DDR se basa en el perfil del marcador, esto se logra mediante el comando script dialer, configurado en la línea TTY. Ambos usuarios se basan en un script de chat existente en la configuración global del router, como:

   chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c
   

   En cualquier caso, el comando para ver la actividad del script de chat es debug chat. Si la cadena de marcado (número de teléfono) utilizada en el comando dialer map o dialer string fueran 5551212, el resultado de debug sería similar al siguiente:

   CHAT1: Attempting async line dialer script
   
   CHAT1: Dialing using Modem script: callout & System script: none
   CHAT1: process started
   CHAT1: Asserting DTR
   CHAT1: Chat script callout started
   CHAT1: Sending string: AT
   CHAT1: Expecting string: OK
   CHAT1: Completed match for expect: OK
   CHAT1: Sending string: atdt5551212
   CHAT1: Expecting string: CONNECT
   CHAT1: Completed match for expect: CONNECT
   CHAT1: Chat script callout finished, status = Success
   

3. Asegúrese de que la secuencia de comandos de conversación intente la llamada esperada (el número correcto) basándose en la "cadena de envío". Si el script de chat no intenta realizar la llamada esperada, verifique la configuración del script de chat. Utilice el comando start-chat en la indicación exec para iniciar el script de chat manualmente.

4. Ver "Tiempo de espera agotado: CONNECT" puede describir varias posibilidades:

   • Posibilidad 1: El módem local no está realizando la llamada. Verifique que el módem pueda realizar una llamada realizando un telnet inverso al módem e iniciando manualmente un marcado. Si el extremo remoto no parece estar respondiendo, verifique que la llamada esté siendo realizada por el módem llamando a un número local manualmente con el comando ATDT <number> y escuchando el timbre. Si no se recibe ninguna llamada, active las depuraciones ISDN. Ante la primera sospecha de una falla ISDN en un BRI, verifique siempre la salida del estado show isdn. Los aspectos clave a tener en cuenta son que la Capa 1 debe ser Activa y la Capa 2 debe estar en un estado de MULTIPLE_FRAME_ESTABLISHED . Consulte la Guía de Troubleshooting de Internetwork Capítulo 16, "Interpretación de Mostrar Estado ISDN" para obtener información sobre la lectura de este resultado y las medidas correctivas.

     Para las llamadas ISDN salientes, debug isdn q931 y debug isdn events son las mejores herramientas para usar. Afortunadamente, la depuración de llamadas salientes es muy similar a la depuración de llamadas entrantes. Una llamada normal exitosa podría verse de la siguiente manera:

     *Mar 20 21:07:45.025: ISDN BR0: Event: 
     Call to 5553759 at 64 Kb/s
     
     *Mar 20 21:07:45.033: ISDN BR0: TX ->  SETUP pd = 8  
     callref = 0x2C
     *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
     *Mar 20 21:07:45.041:         Channel ID i = 0x83
     *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
     *Mar 20 21:07:45.141: ISDN BR0: RX <-  CALL_PROC pd = 8  
     callref = 0xAC
     *Mar 20 21:07:45.145:         Channel ID i = 0x89
     *Mar 20 21:07:45.157: ISDN BR0: received HOST_PROCEEDING
             Channel ID i = 0x0101
     *Mar 20 21:07:45.161:   -------------------
             Channel ID i = 0x89
     *Mar 20 21:07:45.313: ISDN BR0: RX <-  CONNECT pd = 8  
     callref = 0xAC
     *Mar 20 21:07:45.325: ISDN BR0: received HOST_CONNECT
     

     Tenga en cuenta que el mensaje CONNECT es el indicador clave del éxito. Si no se recibe CONNECT, puede ver un mensaje DISCONNECT o RELEASE_COMP (versión completa) seguido de un código de causa:

     *Mar 20 22:11:03.212: ISDN BR0: RX <-  RELEASE_COMP pd = 8  
     callref = 0x8F
     *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected 
     

     El valor de la causa indica dos cosas.

     • El segundo byte del valor de 4 o 6 bytes indica el punto en la trayectoria de llamada de extremo a extremo desde el que se recibió DISCONNECT o RELEASE_COMP. Esto puede ayudarle a localizar el problema.

     • Los bytes tercero y cuarto indican la razón real de la falla. Véase la tabla 9 para conocer los significados de los diferentes valores.

   • Posibilidad 2: El módem remoto no responde. Pruebe esto marcando el módem remoto con un teléfono normal. Intente hacer lo siguiente:

     1. Asegúrese de que el número de teléfono al que se ha llamado es correcto. Utilice un terminal para llamar al número de recepción.

     2. Asegúrese de que una llamada manual pueda alcanzar el módem asíncrono de respuesta. Si una llamada manual puede alcanzar el módem asíncrono de respuesta, es posible que la línea BRI no esté aprovisionada para permitir llamadas de voz salientes.

     3. Si una llamada manual no puede alcanzar el módem asincrónico de respuesta, cambie los cables telefónicos del módem receptor e intente utilizar un teléfono normal en la línea del módem receptor. Si el teléfono normal puede recibir la llamada, es probable que haya un problema con el módem receptor.

     4. Si la llamada manual todavía no puede alcanzar el teléfono normal en la línea en cuestión, pruebe con otra línea (que se conoce que es buena) en la instalación de recepción. Si se conecta, haga que la compañía telefónica verifique la línea telefónica que va al módem receptor.

     5. Si se trata de una llamada de larga distancia, haga que el lado de origen intente otro número de larga distancia (conocido como bueno). Si esto funciona, es posible que la línea o la instalación receptora no esté aprovisionada para recibir llamadas de larga distancia. Si la línea de origen (BRI) no puede alcanzar ningún otro número de larga distancia, es posible que no tenga activada la opción de larga distancia. Pruebe los códigos 10-10 para diferentes empresas de larga distancia.

     6. Finalmente, intente otro número local (conocido) de la línea BRI de origen. Si la conexión todavía falla, haga que la compañía telefónica verifique el BRI.

   • Posibilidad 3: El número marcado es incorrecto. Verifique el número marcándolo manualmente. Corrija la configuración, si es necesario.

   • Posibilidad 4: La preparación del módem tarda demasiado o el valor de TIMEOUT es demasiado bajo. Intente aumentar el valor TIMEOUT en el comando chat-script. Si el TIEMPO DE ESPERA ya es de 60 segundos o más, puede haber un problema de cable entre el módem y el DTE al que está conectado. Las fallas de la formación también pueden indicar un problema de circuito o incompatibilidad del módem.

     Para llegar a la parte inferior de un problema de módem individual, vaya al mensaje AT en el módem de origen con Telnet inverso. Si es posible, use reverse telnet para llegar al mensaje AT del módem receptor también. Utilice ATM1 para que el módem envíe sonidos a su altavoz de modo que la gente de cada extremo pueda oír lo que está sucediendo en la línea.

     ¿La música tiene ruido? Si es así, limpie el circuito. Si los módems asincrónicos no se forman, llame al número y escuche estático. Puede haber otros factores que interfieran con la preparación. Telnet inverso al módem asíncrono y a la depuración.

5. Si todo funciona correctamente y todavía no puede conectarse en el DDR del módem asíncrono BRI, intente la depuración PPP. Si el script de chat se completa correctamente y las depuraciones PPP indican un error, consulte la sección "Resolución de problemas de PPP" en el Capítulo 17 de la Guía de Troubleshooting de Internetwork.

PRI ISDN DDR

1. Ante la primera sospecha de una falla ISDN en un PRI, siempre verifique la salida del estado show isdn. Los aspectos clave a tener en cuenta son que la Capa 1 debe estar activa y la Capa 2 debe estar en un estado de MULTIPLE_FRAME_ESTABLISHED. Consulte la Guía de Troubleshooting de Internetwork Capítulo 16, "Interpretación de Mostrar Estado ISDN" para obtener información sobre la lectura de este resultado y las medidas correctivas.

   Para las llamadas ISDN salientes, debug isdn q931 y debug isdn events son las mejores herramientas para usar. Afortunadamente, la depuración de llamadas salientes es muy similar a la depuración de llamadas entrantes. Una llamada normal exitosa podría verse de la siguiente manera:

   *Mar 20 21:07:45.025: ISDN SE0:23: Event: 
   Call to 5553759 at 64 Kb/s
   
   *Mar 20 21:07:45.033: ISDN SE0:23: TX ->  SETUP pd = 8  
   callref = 0x2C
   *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
   *Mar 20 21:07:45.041:         Channel ID i = 0x83
   *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
   *Mar 20 21:07:45.141: ISDN SE0:23: RX <-  CALL_PROC pd = 8  
   callref = 0xAC
   *Mar 20 21:07:45.145:         Channel ID i = 0x89
   *Mar 20 21:07:45.157: ISDN SE0:23: received HOST_PROCEEDING
           Channel ID i = 0x0101
   *Mar 20 21:07:45.161:   -------------------
           Channel ID i = 0x89
   *Mar 20 21:07:45.313: ISDN SE0:23: RX <-  CONNECT pd = 8  
   callref = 0xAC
   *Mar 20 21:07:45.325: ISDN SE0:23: received HOST_CONNECT
   

   Tenga en cuenta que el mensaje CONNECT es el indicador clave del éxito. Si no se recibe CONNECT, puede ver un mensaje DISCONNECT o RELEASE_COMP (versión completa) seguido de un código de causa:

   *Mar 20 22:11:03.212: ISDN SE0:23: RX <-  RELEASE_COMP pd = 8  
   callref = 0x8F
   *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected
   

   El valor de la causa indica dos cosas.

   • El segundo byte del valor de 4 o 6 bytes indica el punto en la trayectoria de llamada de extremo a extremo desde el que se recibió DISCONNECT o RELEASE_COMP. Esto puede ayudarle a localizar el problema.

   • Los bytes tercero y cuarto indican la razón real de la falla. Véase la tabla 9 para conocer los significados de los diferentes valores.

   Nota: La siguiente impresión indica una falla de protocolo superior:

   Cause i = 0x8090 - Normal call clearing

   La falla de autenticación PPP es una razón típica. Active debug ppp negotiation y debug ppp authentication antes de asumir que la falla de conexión es necesariamente un problema ISDN.

2. Si se ve el mensaje ISDN CONNECT y las depuraciones PPP indican una falla, consulte la sección "Resolución de Problemas de PPP" en el Capítulo 17 de la Guía de Troubleshooting de Internetwork.

BRI ISDN DDR

1. En la primera sospecha de una falla ISDN en un BRI, verifique siempre la salida de show isdn status. Los aspectos clave a tener en cuenta son que la Capa 1 debe estar activa y la Capa 2 debe estar en estado MULTIPLE_FRAME_ESTABLISHED. Consulte la Guía de Troubleshooting de Internetwork Capítulo 16, "Interpretando Mostrar Estado ISDN" para obtener información sobre cómo leer este resultado y las medidas correctivas.

   Para las llamadas ISDN salientes, debug isdn q931 y debug isdn events son las mejores herramientas para usar. Afortunadamente, la depuración de llamadas salientes es muy similar a la depuración de llamadas entrantes. Una llamada normal exitosa podría verse de la siguiente manera:

   *Mar 20 21:07:45.025: ISDN BR0: Event: Call to 5553759 at 64 Kb/s
   
   *Mar 20 21:07:45.033: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x2C
   *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
   *Mar 20 21:07:45.041:         Channel ID i = 0x83
   *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
   *Mar 20 21:07:45.141: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0xAC
   *Mar 20 21:07:45.145:         Channel ID i = 0x89
   *Mar 20 21:07:45.157: ISDN BR0: received HOST_PROCEEDING
           Channel ID i = 0x0101
   *Mar 20 21:07:45.161:   -------------------
           Channel ID i = 0x89
   *Mar 20 21:07:45.313: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0xAC
   *Mar 20 21:07:45.325: ISDN BR0: received HOST_CONNECT
   

   Tenga en cuenta que el mensaje CONNECT es el indicador clave del éxito. Si no se recibe CONNECT, puede ver un mensaje DISCONNECT o RELEASE_COMP (versión completa) seguido de un código de causa:

   *Mar 20 22:11:03.212: ISDN BR0: RX <-  RELEASE_COMP pd = 8  
   callref = 0x8F
   *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected
   

   El valor de la causa indica dos cosas.

   • El segundo byte del valor de 4 o 6 bytes indica el punto en la trayectoria de llamada de extremo a extremo desde el que se recibió DISCONNECT o RELEASE_COMP. Esto puede ayudarle a localizar el problema.

   • Los bytes tercero y cuarto indican la razón real de la falla. Véase la tabla 9 para conocer los significados de los diferentes valores.

     Nota: La siguiente impresión indica una falla de protocolo superior:

     Cause i = 0x8090 - Normal call clearing

     La falla de autenticación PPP es una razón típica. Active debug ppp negotiation y debug ppp authentication antes de asumir que la falla de conexión es necesariamente un problema ISDN.

2. Si se ve el mensaje ISDN CONNECT y las depuraciones PPP indican una falla, consulte la sección "Resolución de Problemas de PPP" en el Capítulo 17 de la Guía de Troubleshooting de Internetwork.

Información Relacionada

• Guía de Configuración Rápida de Servicios de Marcado de Cisco IOS
• Guía de Configuración de Servicios de Marcado de Cisco IOS: Servicios de red
• Guía de Configuración de Servicios de Marcado de Cisco IOS: Servicios de terminal
• Referencia de Comandos de Servicios de Marcado de Cisco IOS
• Descripción general del caso práctico de marcación
• Páginas de tecnología de acceso
• Soporte Técnico y Documentación - Cisco Systems

Historial de revisiones