Marcado y acceso remotos : Dial-on-Demand Routing (DDR)

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

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Este documento proporciona los métodos de resolver problemas diversos tipos de conexiones de marcado y no se piensa ser leído de principio a fin. La estructura se diseña para permitir que el lector salte adelante a las secciones del interés, que son variaciones en el tema general de Troubleshooting para un caso específico.

prerrequisitos

Requisitos

Este documentos abarca tres escenarios principales; antes de que usted comience a resolver problemas, determine están intentando a qué tipo de llamada y vaya a esa sección:

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. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). 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. El AS3600, el AS5200, el AS5300, y el AS5800 son todos los ejemplos de Routers que tienen la capacidad de funcionar con una interfaz de la velocidad primaria (PRI) junto con los bancos de los módems digitales. El AS2511, por otra parte, es un ejemplo de router que se comunica con módems externos.

El mercado de portadoras ha crecido perceptiblemente, y el mercado ahora exige densidades del módem más altas. La respuesta a esta necesidad es un grado de interoperación más alto con el equipo de la compañía telefónica y el desarrollo del módem digital. Éste es un módem que es capaz del acceso digital directo al PSTN. Como consecuencia, módems CPE más rápidos ahora se han desarrollado que se aprovechan de la claridad de señal de que los módems digitales disfrutan. El hecho de que los módems digitales que conectan en el PSTN con un PRI o el Basic Rate Interface (BRI) puedan transmitir los datos en 53k excesivo usando la norma de comunicación del v.90, atestigua al éxito de la idea.

El primer Access Servers era el AS2509 y el AS2511. El AS2509 podría soportar 8 conexiones entrantes usando los Módems externos, y el AS2511 podría soportar 16. El AS5200 fue introducido con 2 PRI y podría apoyar a 48 usuarios que usaban los módems digitales, y representó un avance importante adelante en tecnología. Las densidades del módem han aumentado constantemente con el AS5300 que soportaba 4 y entonces 8 PRI. Finalmente, el AS5800 fue introducido para llenar las necesidades de las instalaciones de clases portadoras que necesitaban manejar el T1s de las docenas de entrantes y los centenares de conexiones del usuario.

Un par de tecnologías desactualizadas llevan el mencionar en una explicación histórica de la tecnología de dialer. 56Kflex es una más vieja (pre-V.90) norma del módem 56K que fue propuesta por Rockwell. Cisco es compatible con la versión 1.1 del estándar 56Kflex en sus módems internos, pero recomienda el emigrar de los módems CPE al v.90 cuanto antes. Otra tecnología desactualizada es el AS5100. El AS5100 era empresa conjunta entre Cisco y un fabricante del módem. El AS5100 fue creado como una manera de aumentar la densidad del módem con el uso de las placas del módem del patio. Implicó un grupo de AS2511 construido como los indicadores luminosos LED amarillo de la placa muestra gravedad menor que insertaron en un backplane compartido por las placas del módem del patio, y indicador luminoso LED amarillo de la placa muestra gravedad menor dual T1.

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 método de Troubleshooting para las llamadas entrantes comienza en la parte inferior, resolviendo problemas el comienzo de una conexión saliente en el top.

El flujo general de razonamiento se asemeja a siguiente:

  1. ¿El On-Demand Routing del dial (DDR) inicia una llamada? (La respuesta A avanza sí a la pregunta siguiente.)

  2. ¿Si esto es un módem asincrónico, los scripts de la charla publican los comandos expected?

  3. ¿La llamada lo hace al PSTN?

  4. ¿El extremo remoto contesta a la llamada?

  5. ¿La llamada completa?

  6. ¿Está el paso de los datos sobre el link?

  7. ¿Se establece la sesión? (PPP o terminal)

Para ver si el marcador está intentando hacer una llamada a su destino remoto, utilice el comando debug dialer events. Más información detallada se puede ganar del paquete del debug dialer, pero el comando debug dialer packet es uso intensivo de recurso y no debe ser utilizado en un sistema ocupado que tenga funcionamiento de las interfaces de dialer múltiple.

La siguiente línea de eventos del debug dialer hizo salir para un paquete del IP enumera el nombre de la interfaz DDR y de las direcciones de origen y de 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 mayoría de las razones comunes son configuración inapropiada (de las definiciones de tráfico interesante, del estado de la interfaz del dialer, o de la encaminamiento).

Tabla 1: El tráfico no inicia un intento de marcado

Posibles Causas Acciones sugeridas
Definiciones que falta o incorrectas del “tráfico interesante”
  1. Usando el comando show running-config, asegúrese de que la interfaz esté configurada con un marcador-grupo y de que hay una marcador-lista llana global configurada con un número concordante.
  2. Asegúrese de que configuren al comando dialer-list para permitir un protocolo completo o de permitir el tráfico que corresponde con una lista de acceso
  3. Verifique que la lista de acceso declare los paquetes que van a través del link a ser interesante. Una prueba útil es utilizar el [list number] del paquete del IP del debug del comando privileged exec usando el número de la lista de accesos pertinente. Entonces tentativa de hacer ping, o de enviar de otra manera el tráfico, a través del link. Si los filtros de tráfico interesante se han definido correctamente, usted verá los paquetes en la salida de los debugs. Si no hay salida de los debugs de esta prueba, la lista de acceso no está correspondiendo con los paquetes.
Estado de la interfaz Utilice el comando show interfaces <interface name> de asegurarse de que la interfaz está en el estado “up/up (spoofing).”
  • Interconecte en el modo "inactivo"
Otra interfaz (primaria) en el router se ha configurado para utilizar la interfaz del dialer como Interfaz de respaldo. Además, la interfaz primaria no está en un estado de “abajo/abajo”, que se requiere para traer la interfaz del dialer del modo de reserva. También, backup delay debe ser configurado en la interfaz primaria, o nunca aplicarán al comando backup interface. Para marcar que la interfaz del dialer cambiará del “recurso seguro” al “up/up (spoofing),” es generalmente necesario tirar del cable de la interfaz primaria. ¿Simplemente apagar la interfaz primaria con el configuration command shutdown no pondrá la interfaz primaria en “abajo/abajo,” sino que por el contrario la pondrá en “administrativo abajo de”? no la misma cosa. Además, si la conexión primaria está vía el Frame Relay, la configuración de Frame Relay se debe hacer en una subinterfaz serial Point-to-Point, y la compañía telefónica debe pasar el bit “activo”. Esta práctica también se conoce como “Interfaz de administración local (LMI) de punta a punta.”
  • La interfaz está “administrativo abajo de”
La interfaz del dialer se ha configurado con el comando shutdown. Éste es también el estado predeterminado de cualquier interfaz cuando inician a un router Cisco por el primer tiempo. Utilice el comando interface configuration ningún apagan para quitar este impedimento.
Encaminamiento incorrecta Publique el exec command show ip route [a.b.c.d], donde está el direccionamiento el a.b.c.d de la interfaz del dialer del router remoto. Si los unnumberedis del IP usados en el router remoto, utilizan el direccionamiento de la interfaz enumerada en el unnumberedcommand del IP. La salida debe mostrar una ruta a la dirección remota vía la interfaz del dialer. Si no hay ruta, asegúrese de que los parásitos atmosféricos o las Rutas estáticas flotantes hayan sido configurados examinando la salida de los ejecutar-config de la demostración. Si hay una ruta vía una interfaz con excepción de la interfaz del dialer, la implicación es que el DDR se está utilizando como respaldo. Examine la configuración del router para aseegurarse que se han configurado los parásitos atmosféricos o las Rutas estáticas flotantes. La forma más segura de probar la encaminamiento, en este caso, es inhabilitar la conexión primaria y ejecutar el commandto del [a.b.c.d] de la ruta de IP de la demostración verifique que la ruta apropiado ha estado instalada en la tabla de ruteo.

Nota: Si usted intenta esto durante las operaciones de la red en funcionamiento, un evento del dial puede ser accionado. Esta clase de prueba se logra mejor durante los ciclos de mantenimiento programado.

Colocación de llamada

Si la encaminamiento y los filtros de tráfico interesante están correctos, una llamada debe ser iniciada. Esto se puede ver usando los eventos del 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 considera la causa de marcación pero no se hace ninguna tentativa para marcar, la razón habitual es una correlación del dialer mal configurada o un perfil de marcado.

Tabla 2: Llamada no puesta

Posible problema Acciones sugeridas
Correlación del dialer mal configurada Utilice el comando show running-config de asegurarse de que la interfaz de marcación está configurada con por lo menos una sentencia del mapa de marcado que las puntas a la dirección de protocolo y número al que se llamó del sitio remoto.
Perfil del discador mal configurado Utilice el comando show running-config de asegurarse de que la interfaz del dialer está configurada con un comando dialer pool X y de que una interfaz del dialer en el router está configurada con un dialer miembro de los recursos compartidos que corresponde con X. Si los Perfiles de marcado no se configuran correctamente, usted puede ver un mensaje del debug como:
Dialer1: Can't place call, no dialer pool set
Aseegurese que una cadena del dialer está configurada.

Después, identifique el tipo de media se esté utilizando que:

DDR de módem asíncrono externo

  1. Para identificar un módem asíncrono externo DDR, utilice los siguientes comandos, después intente hacer una llamada:

    router# debug modem
    router# debug chat line <n>
    
    
  2. Para las llamadas del módem, un chat script debe ejecutar para que la llamada proceda. Para la correspondencia basada DDR del marcador, el chat script es invocado por el parámetro de secuencia de comandos del módem en un comando dialer map. Si el DDR es marcador basado en el perfil, esto es lograda por el comando script dialer, configurado en la línea TTY. Ambos métodos confían en un chat script que existe en la configuración global del router, por ejemplo:

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

    En cualquier evento, el comando de ver la actividad del chat script es charla del debug. Si la cadena de marcado (es decir, número de teléfono) usada en el comando dialer map o dialer string fuera 5551212, la salida de los debugs parecería el 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 el chat script intente la llamada esperada (es decir el número correcto) basada en el “envío de la cadena.” Si el chat script no intenta hacer la llamada esperada, verifique la configuración del chat script. Utilice el comando start-chat en el prompt exec de iniciar el chat script manualmente.

  4. Ver la “espera del descanso: CONECTE” puede describir varias diversas posibilidades:

    • Posibilidad 1: El módem local no está poniendo realmente la llamada. Verifique que el módem pueda poner una llamada realizando un telnet reverso al módem y manualmente iniciando un dial. Si el extremo remoto no parece contestar, verifique que la llamada esté siendo puesta por el módem de origen llamando un número local manualmente con el comando ATDT <number> y estando atento el timbre.

    • Posibilidad 2: El módem remoto no está contestando. Pruebe esto marcando el módem remoto con un teléfono ordinario de los CRISOLES. Intente esto:

      1. Asegúrese de que el número de teléfono llamado esté correcto. Utilice un microteléfono para llamar el número de recepción. Esté seguro de utilizar el mismo cable a la pared que el módem utilizaba. Si una llamada manual puede alcanzar el módem asincrónico de recepción, el módem de origen puede no trabajar correctamente. Verifique el módem y substitúyalo según las necesidades.

      2. Si una llamada manual no puede alcanzar el módem asincrónico de contestación, cambie los cables del teléfono en el módem de recepción e intente un teléfono normal en la línea de módem de recepción. Si la llamada se puede recibir por el teléfono normal, hay probable un problema con el módem de recepción.

      3. Si la llamada manual todavía no puede alcanzar el teléfono normal en la línea en la pregunta, intente otra línea (bueno sabida) en el recurso de recepción. Si eso conecta OK, tenga el control de la compañía telefónica la línea telefónica que va al módem de recepción.

      4. Si esto es una llamada de larga distancia, tenga el lado de origen intentar otro número de larga distancia (bueno sabida). Si eso trabaja, el recurso o la línea de recepción puede no ser aprovisionado para recibir las llamadas de larga distancia. Si la línea de origen no puede alcanzar ninguna otra números de larga distancia, puede no hacer la larga distancia habilitar. Códigos del intento 1010 para diversas compañías de larga distancia.

      5. Finalmente, intente otro número local (bueno sabida) de la línea de origen. Si la conexión todavía falla, tenga el control de la compañía telefónica la línea de origen.

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

    • Posibilidad 4: Los preparativos del módem están durando demasiado o el valor de agotamiento del tiempo es demasiado bajo. Intento que aumenta el valor de agotamiento del tiempo en el comando chat-script. Si el DESCANSO es ya 60 segundos o más, puede haber un problema de cable entre el módem y el DTE a los cuales se asocia. Las fallas de preparación de conexión pueden también indicar un problema del circuito o una incompatibilidad del módem.

      Para conseguir a la parte inferior de un problema del módem individual, vaya al EN el prompt en el módem de origen con el telnet reverso. Si es posible, consiga al EN el prompt del módem de recepción también. La mayoría de los módems indicarán un timbre a la sesión terminal asociada a su conexión DTE. Uso ATM1 de hacer que el módem envíe los sonidos a su altavoz de modo que la gente en cada extremo pueda oír qué está sucediendo en la línea.

      ¿La música tiene ruido en ella? Si es así limpie el circuito. Si los módems asincrónicos no entrenan para arriba, llame el número y esté atentos los parásitos atmosféricos. Puede haber otros factores que interfieren con el tren para arriba. Invierta el telnet al módem asincrónico y hagalo el debug de.

  5. Si todo está trabajando muy bien y usted todavía no puede conectar en su DDR de módem asíncrono de CAS, intente el debugging de PPP. Utilice los comandos:

    router# debug ppp negotiation
         router# debug ppp authentication
    

    Si el chat script completa con éxito, los módems están conectados. Consulte en el capítulo 17 del guía de Troubleshooting de la red interna para el siguiente paso en resolver problemas la conexión.

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

  1. Para identificar un DDR de módem asíncrono de CAS T1/E1, utilice los siguientes comandos, después intente hacer una llamada:

    advertencia Advertencia:  ¡Los debugs que se ejecutaban en un sistema ocupado podían causar un crash al router sobrecargando el CPU o sobrando el búfer de la 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 del Cisco AS5200 y AS5300 que funcionan con el Cisco IOS?? Software Release 12.0(7)T y Posterior. En las versiones anteriores del IOS, el comando service internal tendría que ser ingresado en el nivel principal de la configuración del router y el módem-mgmt csm debug-RBS necesitaría ser ingresado en el prompt exec. El debugging en el Cisco AS5800 requiere la conexión con la placa troncal. (No-debug-rbs csm del módem-mgmt del uso para apagar el debug.)

  2. Para las llamadas del módem, un chat script debe ejecutar para que la llamada proceda. Para la correspondencia basada DDR del marcador, el chat script es invocado por el parámetro de secuencia de comandos del módem en un comando dialer map. Si el DDR es marcador basado en el perfil, esto es lograda por el comando script dialer, configurado en la línea TTY. Ambas aplicaciones confían en un chat script que existe en la configuración global del router, por ejemplo:

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

    En cualquier evento, el comando de ver la actividad del chat script es charla del debug. Si la cadena de marcado (es decir, número de teléfono) usada en el comando dialer map o dialer string fuera 5551212, la salida de los debugs parecería el 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 el chat script intente la llamada esperada (es decir el número correcto) basada en el “envío de la cadena”. Si el chat script no intenta hacer la llamada esperada, verifique la configuración del chat script. Utilice el comando start-chat en el prompt exec de iniciar el chat script manualmente.

  4. Ver la “espera del descanso: CONECTE” puede describir varias diversas posibilidades:

    • Posibilidad 1: El módem local no está poniendo realmente la llamada. Verifique que el módem pueda poner una llamada realizando un telnet reverso al módem y manualmente iniciando un dial. Si el extremo remoto no parece contestar, verifique la llamada está siendo colocado por el módem llamando un número local manualmente con el comando ATDT <number> y estando atento el timbre.

      Para la Llamada saliente vía el T1 o E1 de CAS y los módems digitales integrados, mucho del troubleshooting es similar al otro Troubleshooting de DDR. Lo mismo es verdad, también, para las llamadas salientes del módem integrado sobre una línea PRI. Las funciones únicas implicadas en la fabricación de una llamada de este modo requieren el debugging especial en caso de falla de llamada.

      En cuanto a otros problemas con DDR, usted debe asegurarse de que un intento de llamada esté exigido. Utilice el para este propósito de los eventos del debug dialer. Refiera a IOS DDR, anterior en este artículo.

      Antes de que una llamada pueda ser puesta, un módem se debe afectar un aparato para la llamada. Para ver este proceso y la llamada posterior, utilice los comandos debug siguientes:

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

      Nota: El comando debug cas primero apareció en la versión de IOS 12.0(7)T para el AS5200 y el AS5300. Las versiones anteriores del IOS utilizan un system-level configuration command service internal junto con el exec command modem-mgmt debug rbs:

      Girar los debugs:

      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 
      

      Apagar los debugs:

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

      Hacer el debug de esta información sobre un AS5800 requiere la conexión con la placa troncal. Lo que sigue es un ejemplo de una llamada de salida normal sobre un T1 de CAS que sea aprovisionado y configurado para el FXS-Tierra-principio:

      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
      

      Los debugs para el T1s y E1s con otros tipos de señalización son similares.

      El conseguir a esta punta en el debugging indica que la llamada y los módems que contesta hayan entrenado y hayan conectado y que los protocolos de capa más altas pueden comenzar a negociar. Si un módem se afecta un aparato correctamente para la llamada de salida pero la conexión no puede conseguir esto lejano, el T1 debe ser examinado. Utilice el comando show controller t1/e1 de verificar que el T1/E1 está trabajando. Vea resolver problemas las líneas seriales para una explicación del resultado del controlador de la demostración. Si el T1/E1 no está trabajando correctamente, el Troubleshooting de T1/E1 es necesario.

    • Posibilidad 2: El módem remoto no está contestando. Pruebe esto marcando el módem remoto con un teléfono ordinario. Intente esto:

      1. Asegúrese de que el número de teléfono llamado esté correcto. Utilice un microteléfono para llamar el número de recepción.

      2. Asegúrese de que una llamada manual pueda alcanzar el módem asincrónico de contestación. Si una llamada manual puede alcanzar el módem asincrónico de contestación, la línea de CAS puede no ser aprovisionado para permitir las llamadas de voz saliente.

      3. Si una llamada manual no puede alcanzar el módem asincrónico de contestación, cambie los cables del teléfono en el módem de recepción e intente un teléfono normal en la línea de módem de recepción. Si la llamada se puede recibir por el teléfono normal, hay probable un problema con el módem de recepción.

      4. Si la llamada manual todavía no puede alcanzar el teléfono normal en la línea en la pregunta, intente otra línea (bueno sabida) en el recurso de recepción. Si eso conecta, tenga el control de la compañía telefónica la línea telefónica que va al módem de recepción.

      5. Si esto es una llamada de larga distancia, tenga el lado de origen intentar otro número de larga distancia (bueno sabida). Si eso trabaja el recurso o la línea de recepción puede no ser aprovisionado para recibir las llamadas de larga distancia. Si la línea (de CAS que origina) no puede alcanzar ninguna otra números de larga distancia, puede no hacer la larga distancia habilitar. Códigos del intento 10-10 para diversas compañías de larga distancia.

      6. Finalmente, intente otro número local (bueno sabida) de la línea de CAS que origina. Si la conexión todavía falla, tenga control de la compañía telefónica CAS.

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

    • Posibilidad 4: Los preparativos del módem están durando demasiado, o el valor de agotamiento del tiempo es demasiado bajo. Intento que aumenta el valor de agotamiento del tiempo en el comando chat-script. Si el DESCANSO es ya 60 segundos o más, puede haber un problema de cable entre el módem y el DTE a los cuales se asocia. Las fallas de preparación de conexión pueden también indicar un problema del circuito o una incompatibilidad del módem.

      Para conseguir a la parte inferior de un problema del módem individual, vaya al EN el prompt en el módem de origen con el telnet reverso. Si es posible, utilice el telnet reverso para conseguir al EN el prompt del módem de recepción también. Uso ATM1 de hacer que el módem envíe los sonidos a su altavoz de modo que la gente en cada extremo pueda oír qué está sucediendo en la línea.

      ¿La música tiene ruido en ella? Si es así limpie el circuito. Si los módems asincrónicos no entrenan para arriba, llame el número y esté atentos los parásitos atmosféricos. Puede haber otros factores que interfieren con el tren para arriba. Invierta el telnet al módem asincrónico y hagalo el debug de.

  5. Si todo está trabajando muy bien y usted todavía no puede conectar en su DDR de módem asíncrono de CAS, intente el debugging de PPP. Si el chat script completa con éxito y los debugs PPP indican un error, consulte en el capítulo 17 del guía de Troubleshooting de la red interna.

DDR de módem asincrónico de PRI

  1. Para identificar un DDR de módem asíncrono PRI, utilice los siguientes comandos, después intente hacer una llamada:

    advertencia Advertencia:  ¡Los debugs que se ejecutaban en un sistema ocupado podían causar un crash al router sobrecargando el CPU o sobrando el búfer de la 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 del módem, un chat script debe ejecutar para que la llamada proceda. Para la correspondencia basada DDR del marcador, el chat script es invocado por el parámetro de secuencia de comandos del módem en un comando dialer map. Si el DDR es marcador basado en el perfil, esto es lograda por el comando script dialer, configurado en la línea TTY. Ambos métodos confían en un chat script que existe en la configuración global del router, por ejemplo:

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

    En cualquier evento, el comando de ver la actividad del chat script es charla del debug. Si la cadena de marcado (número de teléfono) usada en el comando dialer map o dialer string fuera 5551212, la salida de los debugs parecería el 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 el chat script intente la llamada esperada (el número correcto) basada en el “envío de la cadena.” Si el chat script no intenta hacer la llamada esperada, verifique la configuración del chat script. Utilice el comando start-chat en el prompt exec de iniciar el chat script manualmente.

  4. Ver la “espera del descanso: CONECTE” puede describir varias diversas posibilidades:

    • Posibilidad 1: El módem local no está poniendo realmente la llamada. Verifique que el módem pueda poner una llamada realizando un telnet reverso al módem y manualmente iniciando un dial. Si el extremo remoto no parece contestar, verifique que la llamada esté siendo puesta por el módem llamando un número local manualmente con el comando ATDT <number> y estando atento el timbre. Si ninguna llamada sale, gire los debugs ISDN. A la primera sospecha de una falla ISDN en un BRI, marque siempre la salida del isdn status de la demostración. Las cosas dominantes a observar son que el Layer 1 debe ser activo y la capa 2 debe estar en un estado del MULTIPLE_FRAME_ESTABLISHED. Vea el capítulo 16 del guía de Troubleshooting de la red interna, para la información sobre la lectura de esta salida, así como por medidas correctivas.

      Para los llamadas ISDN de salidas, haga el debug de ISDN q931 y el debug isdn events es las mejores herramientas a utilizar. Afortunadamente, los debugginges de llamada de salida son muy similares a los debugginges de llamada entrante. Una llamada satisfactoria normal pudo parecer esto:

      *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
      

      Observe que el mensaje CONNECT es el indicador clave del éxito. Si CONNECT no se recibe, usted puede ver una DESCONEXIÓN o un mensaje del RELEASE_COMP (versión completa) seguido por un código de la 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 causa indica dos cosas:

      • El segundo byte de los 4 o del valor 6-byte indica la punta en el trayecto de llamada de extremo a extremo del cual la DESCONEXIÓN o el RELEASE_COMP fue recibida. Esto puede ayudarle a localizar el problema.

      • El tercero y los cuartos bytes indican la razón real del error. Vea el cuadro 9 para los significados de los diversos valores.

    • Posibilidad 2: El módem remoto no está contestando. Pruebe esto marcando el módem remoto con un teléfono ordinario. Intente esto:

      1. Asegúrese de que el número de teléfono llamado esté correcto. Utilice un microteléfono para llamar el número de recepción.

      2. Asegúrese de que una llamada manual pueda alcanzar el módem asincrónico de contestación. Si una llamada manual puede alcanzar el módem asincrónico de contestación, la línea BRI puede no ser aprovisionado para permitir las llamadas de voz saliente.

      3. Si una llamada manual no puede alcanzar el módem asincrónico de contestación, cambie los cables del teléfono en el módem de recepción e intente un teléfono normal en la línea de módem de recepción. Si la llamada se puede recibir por el teléfono normal, hay probable un problema con el módem de recepción.

      4. Si la llamada manual todavía no puede alcanzar el teléfono normal en la línea en la pregunta, intente otra línea (bueno sabida) en el recurso de recepción. Si eso conecta, tenga el control de la compañía telefónica la línea telefónica que va al módem de recepción.

      5. Si esto es una llamada de larga distancia, tenga el lado de origen intentar otro número de larga distancia (bueno sabida). Si eso trabaja, el recurso o la línea de recepción puede no ser aprovisionado para recibir las llamadas de larga distancia. Si la línea que origina (BRI) no puede alcanzar ninguna otra números de larga distancia, puede no hacer la larga distancia habilitar. Códigos del intento 1010 para diversas compañías de larga distancia.

      6. Finalmente, intente otro número local (bueno sabida) de la línea BRI que origina. Si la conexión todavía falla, tenga el control de la compañía telefónica el BRI.

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

    • Posibilidad 4: Los preparativos del módem están durando demasiado o el valor de agotamiento del tiempo es demasiado bajo. Intento que aumenta el valor de agotamiento del tiempo en el comando chat-script. Si el DESCANSO es ya 60 segundos o más, puede haber un problema de cable entre el módem y el DTE se asocia a. Las fallas de preparación de conexión pueden también indicar un problema del circuito o una incompatibilidad del módem.

      Para conseguir a la parte inferior de un problema del módem individual, vaya al EN el prompt en el módem de origen con el telnet reverso. Si es posible, utilice el telnet reverso para conseguir al EN el prompt del módem de recepción también. Uso ATM1 de hacer que el módem envíe los sonidos a su altavoz de modo que la gente en cada extremo pueda oír qué está sucediendo en la línea.

      ¿La música tiene ruido en ella? Si es así limpie el circuito. Si los módems asincrónicos no entrenan para arriba, llame el número y esté atentos los parásitos atmosféricos. Puede haber otros factores que interfieren con el tren para arriba. Invierta el telnet al módem asincrónico y hagalo el debug de.

  5. Si todo está trabajando muy bien y usted todavía no puede conectar en su módem asíncrono BRI DDR, intente el debugging de PPP. Si el chat script completa con éxito y los debugs PPP indican un error, consulte en el capítulo 17 del guía de Troubleshooting de la red interna.

DDR de módem asíncrono BRI

Esta característica trabaja solamente en la plataforma del Cisco 3640 usando el Cisco IOS Software Release 12.0(3)T o Posterior. Requiere una revisión de hardware posterior del módulo de red BRI. Esto no trabajará con un tarjeta de interfaz WAN (WIC).

  1. Asegúrese de que el código del país esté correcto con el comando show modem. Utilice los siguientes comandos, después intente hacer una llamada:

    advertencia Advertencia:  ¡Los debugs que se ejecutaban en un sistema ocupado podían causar un crash al router sobrecargando el CPU o sobrando el búfer de la 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 del módem, un chat script debe ejecutar para que la llamada proceda. Para la correspondencia basada DDR del marcador, el chat script es invocado por el parámetro de secuencia de comandos del módem en un comando dialer map. Si el DDR es marcador basado en el perfil, esto es lograda por el comando script dialer, configurado en la línea TTY. Ambas aplicaciones confían en un chat script que existe en la configuración global del router, por ejemplo:

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

    En cualquier evento, el comando de ver la actividad del chat script es charla del debug. Si la cadena de marcado (número de teléfono) usada en el comando dialer map o dialer string fuera 5551212, la salida de los debugs parecería el 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 el chat script intente la llamada esperada (el número correcto) basada en el “envío de la cadena.” Si el chat script no intenta hacer la llamada esperada, verifique la configuración del chat script. Utilice el comando start-chat en el prompt exec de iniciar el chat script manualmente.

  4. Ver la “espera del descanso: CONECTE” puede describir varias diversas posibilidades:

    • Posibilidad 1: El módem local no está poniendo realmente la llamada. Verifique que el módem pueda poner una llamada realizando un telnet reverso al módem y manualmente iniciando un dial. Si el extremo remoto no parece contestar, verifique que la llamada esté siendo puesta por el módem llamando un número local manualmente con el comando ATDT <number> y estando atento el timbre. Si ninguna llamada sale, gire los debugs ISDN. A la primera sospecha de una falla ISDN en un BRI, marque siempre la salida del isdn status de la demostración. Las cosas dominantes a observar son que el Layer 1 debe ser activo y la capa 2 debe estar en un estado del MULTIPLE_FRAME_ESTABLISHED. Vea el capítulo 16 del guía de Troubleshooting de la red interna, para la información sobre la lectura de esta salida y medidas correctivas.

      Para los llamadas ISDN de salidas, haga el debug de ISDN q931 y el debug isdn events es las mejores herramientas a utilizar. Afortunadamente, los debugginges de llamada de salida son muy similares a los debugginges de llamada entrante. Una llamada satisfactoria normal pudo parecer esto:

      *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
      

      Observe que el mensaje CONNECT es el indicador clave del éxito. Si CONNECT no se recibe, usted puede ver una DESCONEXIÓN o un mensaje del RELEASE_COMP (versión completa) seguido por un código de la 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 causa indica dos cosas.

      • El segundo byte de los 4 o del valor 6-byte indica la punta en el trayecto de llamada de extremo a extremo del cual la DESCONEXIÓN o el RELEASE_COMP fue recibida. Esto puede ayudarle a localizar el problema.

      • El tercero y los cuartos bytes indican la razón real del error. Vea el cuadro 9 para los significados de los diversos valores.

    • Posibilidad 2: El módem remoto no está contestando. Pruebe esto marcando el módem remoto con un teléfono ordinario. Intente esto:

      1. Asegúrese de que el número de teléfono llamado esté correcto. Utilice un microteléfono para llamar el número de recepción.

      2. Asegúrese de que una llamada manual pueda alcanzar el módem asincrónico de contestación. Si una llamada manual puede alcanzar el módem asincrónico de contestación, la línea BRI puede no ser aprovisionado para permitir las llamadas de voz saliente.

      3. Si una llamada manual no puede alcanzar el módem asincrónico de contestación, cambie los cables del teléfono en el módem de recepción e intente un teléfono normal en la línea de módem de recepción. Si la llamada se puede recibir por el teléfono normal, hay probable un problema con el módem de recepción.

      4. Si la llamada manual todavía no puede alcanzar el teléfono normal en la línea en la pregunta, intente otra línea (bueno sabida) en el recurso de recepción. Si eso conecta, tenga el control de la compañía telefónica la línea telefónica que va al módem de recepción.

      5. Si esto es una llamada de larga distancia, tenga el lado de origen intentar otro número de larga distancia (bueno sabida). Si eso trabaja, el recurso o la línea de recepción puede no ser aprovisionado para recibir las llamadas de larga distancia. Si la línea que origina (BRI) no puede alcanzar ninguna otra números de larga distancia, puede no hacer la larga distancia habilitar. Códigos del intento 10-10 para diversas compañías de larga distancia.

      6. Finalmente, intente otro número local (bueno sabida) de la línea BRI que origina. Si la conexión todavía falla, tenga el control de la compañía telefónica el BRI.

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

    • Posibilidad 4: Los preparativos del módem están durando demasiado, o el valor de agotamiento del tiempo es demasiado bajo. Intento que aumenta el valor de agotamiento del tiempo en el comando chat-script. Si el DESCANSO es ya 60 segundos o más, puede haber un problema de cable entre el módem y el DTE se asocia a. Las fallas de preparación de conexión pueden también indicar un problema del circuito o una incompatibilidad del módem.

      Para conseguir a la parte inferior de un problema del módem individual, vaya al EN el prompt en el módem de origen con el telnet reverso. Si es posible, utilice el telnet reverso para conseguir al EN el prompt del módem de recepción también. Uso ATM1 de hacer que el módem envíe los sonidos a su altavoz de modo que la gente en cada extremo pueda oír qué está sucediendo en la línea.

      ¿La música tiene ruido en ella? Si es así limpie el circuito. Si los módems asincrónicos no entrenan para arriba, llame el número y esté atentos los parásitos atmosféricos. Puede haber otros factores que interfieren con el tren para arriba. Invierta el telnet al módem asincrónico y hagalo el debug de.

  5. Si todo está trabajando muy bien y usted todavía no puede conectar en su módem asíncrono BRI DDR, intente el debugging de PPP. Si el chat script completa con éxito y los debugs PPP indican un error, consulte en el capítulo 17 del guía de Troubleshooting de la red interna.

PRI ISDN DDR

  1. A la primera sospecha de una falla ISDN en un PRI, marque siempre la salida del isdn status de la demostración. Las cosas dominantes a observar son que el Layer 1 debe ser activo y la capa 2 debe estar en un estado del MULTIPLE_FRAME_ESTABLISHED. Vea el capítulo 16 del guía de Troubleshooting de la red interna, para la información sobre la lectura de esta salida y medidas correctivas.

    Para los llamadas ISDN de salidas, haga el debug de ISDN q931 y el debug isdn events es las mejores herramientas a utilizar. Afortunadamente, los debugginges de llamada de salida son muy similares a los debugginges de llamada entrante. Una llamada satisfactoria normal pudo parecer esto:

    *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
    

    Observe que el mensaje CONNECT es el indicador clave del éxito. Si CONNECT no se recibe, usted puede ver una DESCONEXIÓN o un mensaje del RELEASE_COMP (versión completa) seguido por un código de la 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 causa indica dos cosas.

    • El segundo byte de los 4 o del valor 6-byte indica la punta en el trayecto de llamada de extremo a extremo del cual la DESCONEXIÓN o el RELEASE_COMP fue recibida. Esto puede ayudarle a localizar el problema.

    • El tercero y los cuartos bytes indican la razón real del error. Vea el cuadro 9 para los significados de los diversos valores.

    Nota: El informe de ejecución siguiente indica una falla de protocolo superior:

    Cause i = 0x8090 - Normal call clearing

    La falla de autenticación de PPP es una razón típica. Gire la negociación ppp del debug y haga el debug de la autenticación PPP antes de si se asume que la falla de conexión es necesariamente un problema de ISDN.

  2. Si mensaje ISDN CONNECT (CONECTAR ISDN se ve y los debugs PPP indican un error, consulte en el capítulo 17 del guía de Troubleshooting de la red interna.

BRI ISDN DDR

  1. A la primera sospecha de una falla ISDN en un BRI, marque siempre la salida del isdn status de la demostración. Las cosas dominantes a observar son que el Layer 1 debe ser activo y la capa 2 debe estar en un estado del MULTIPLE_FRAME_ESTABLISHED. Vea el capítulo 16 del guía de Troubleshooting de la red interna, “Interpretación de show isdn status” para la información sobre la lectura de esta salida y medidas correctivas.

    Para los llamadas ISDN de salidas, haga el debug de ISDN q931 y el debug isdn events es las mejores herramientas a utilizar. Afortunadamente, los debugginges de llamada de salida son muy similares a los debugginges de llamada entrante. Una llamada satisfactoria normal pudo parecer esto:

    *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
    

    Observe que el mensaje CONNECT es el indicador clave del éxito. Si CONNECT no se recibe, usted puede ver una DESCONEXIÓN o un mensaje del RELEASE_COMP (versión completa) seguido por un código de la 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 causa indica dos cosas.

    • El segundo byte de los 4 o del valor 6-byte indica la punta en el trayecto de llamada de extremo a extremo del cual la DESCONEXIÓN o el RELEASE_COMP fue recibida. Esto puede ayudarle a localizar el problema.

    • El tercero y los cuartos bytes indican la razón real del error. Vea el cuadro 9 para los significados de los diversos valores.

      Nota: El informe de ejecución siguiente indica una falla de protocolo superior:

      Cause i = 0x8090 - Normal call clearing

      La falla de autenticación de PPP es una razón típica. Gire la negociación ppp del debug y haga el debug de la autenticación PPP antes de si se asume que la falla de conexión es necesariamente un problema de ISDN.

  2. Si mensaje ISDN CONNECT (CONECTAR ISDN se ve y los debugs PPP indican un error, consulte en el capítulo 17 del guía de Troubleshooting de la red interna.


Información Relacionada


Document ID: 14954