Marcado y acceso remotos : "Red digital de servicios integrados (ISDN), Señalización por canal asociado (CAS)"

Tecnología de marcación manual: Técnicas de resolución de problemas

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


Esta información del guía de Troubleshooting de la red interna primero fue fijada en el CCO. Como un servicio para nuestros clientes, los capítulos seleccionados tienen la información más exacta y actual. La actualización completa de la Guía de resolución de problemas de red estará disponible pronto en línea.


Contenido


Introducción

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. Cisco3600, AS5200, AS5300 y AS5800 son todos ejemplos de routers que tienen la capacidad de ejecutar un 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.

prerrequisitos

Requisitos

Quienes lean este documento deben tener conocimiento de lo siguiente:

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 un 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 los Cisco2509 y los Cisco2511. 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.

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.

Convenciones

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

Resolver problemas las llamadas entrantes

Resolver problemas una llamada entrante comienza en la parte inferior y elabora su manera. El flujo general de razonamiento busca el siguiente:

  1. ¿Vemos la llamada llegar? (La respuesta A avanza sí a la pregunta siguiente)

  2. ¿El extremo receptor contesta a la llamada?

  3. ¿La llamada completa?

  4. ¿Es el paso de los datos a través del link?

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

Para las conexiones del módem, una llamada de datos mira lo mismo que una sesión terminal que entra hasta el extremo adonde la llamada de datos va a negociar el PPP.

Para las llamadas entrantes que implican los módems digitales, primero aseegurese el ISDN subyacente o CAS está recibiendo la llamada. Si usa un Módem externo, el ISDN y las secciones del grupo CAS pueden ser saltados.

Troubleshooting de la llamada ISDN entrante

Utilice el comando debug isdn q931. Aquí está una salida de ejemplo de una conexión satisfactoria:

Router# debug isdn q931
RX <- SETUP pd = 8 callref = 0x06
 Bearer Capability i = 0x8890
 Channel ID i = 0x89
 Calling Party Number i = 0x0083, `5551234'
TX -> CONNECT pd = 8 callref = 0x86
RX <- CONNECT_ACK pd = 8 callref = 0x06

El mensaje setup indica que una conexión está siendo iniciada por el extremo remoto. Los números de referencia de llamada se mantienen como par. En este caso el número de referencia de llamada para el lado entrante de la conexión es 0x06, y el número de referencia de llamada del lado de salida de la conexión es 0x86. La capacidad portadora (designada a menudo el bearercap) dice a router está viniendo qué clase de llamada adentro. En este caso la conexión es el tipo 0x8890. Ese valor indica la “velocidad 64 Kb/s ISDN”. Si el bearercap hubiera sido 0x8090A2, habría indicado el “Llamada de voz/discurso de u-law”.

Si vino ningún mensaje setup adentro, usted debe verificar el número correcto llamándolo manualmente, si es aprovisionado de la Voz. Usted debe también marcar el estatus de la interfaz de ISDN (refiérase usando el comando show isdn status para el Troubleshooting de BRI). Si ese todo marca hacia fuera, aseegurese que el originador de la llamada está haciendo la llamada correcta. Esto puede ser hecha entrando en contacto la compañía telefónica. ¿El originador de la llamada puede localizar la llamada para ver donde él? s que es enviado. Si la conexión es de larga distancia, intente una diversa portadora de larga distancia que usa un código de larga distancia 1010.

Si la llamada que viene adentro es una llamada del módem asincrónico, aseegurese la línea es aprovisionado para permitir las llamadas de voz.

Nota: El módem asíncrono BRI de llamada es una característica de los 3600 Router que ejecutan 12.0(3)T, o más adelante. Requiere una revisión de hardware reciente del módulo de red de la interfaz BRI. Los módulos WIC no soportan la llamada de módem asíncrono.

Si la llamada llegó pero no completó, busque un código de la causa (véase el cuadro 17-10). Una terminación satisfactoria es indicada por el conectar-ACK.

Si esto es una llamada del módem asincrónico, muévase adelante “a la sección del troubleshooting de la llamada de módem entrante”.

En este momento la llamada ISDN está conectada, pero no se ha considerado ningunos datos el parecer del link. Utilice el comando debug ppp negotiate de ver si algún tráfico PPP está pareciendo la línea. Si usted no ve el tráfico, puede haber una discrepancia de velocidad. Para determinar si éste es el caso, utilice el comando show running-config privileged exec de ver la configuración del router. Marque las entradas del comando dialer map interface configuration en los routers local y remoto. Estas entradas deben parecer similares al siguiente:

dialer map ip 131.108.2.5 speed 56 name C4000

Para los Perfiles de marcado, un map-class necesita ser definido para fijar la velocidad. Observe que, por abandono, las interfaces de ISDN intentan utilizar las velocidades de las comunicaciones 64K en cada canal.

Para información detallada sobre configurar los Mapas de marcado y los perfiles, refiera a la guía de configuración de las soluciones del dial del Cisco IOS, al Dial Solutions Command Reference, y a la guía de configuración rápida de las soluciones del dial.

Si usted recibe los paquetes PPP válidos, el link es ascendente y trabajo. Usted debe proceder a la sección "Troubleshooting de PPP" ahora.

Troubleshooting entrante de la llamada de CAS

Para resolver problemas la Conectividad de la porción del grupo CAS a los módems, utilice los comandos debug modem, debug modem csm, y debug cas.

Nota: El comando debug cas primero apareció en 12.0(7)T para el AS5200 y el AS5300. Las versiones anteriores del IOS utilizan el servicio del comando system level configuration interno junto con el exec command modem-mgmt debug rbs. Hacer el debug de esta información sobre un AS5800 requiere la conexión con la placa troncal sí mismo.

Primero, determine si fue el Switch de la compañía telefónica “offhook” para señalar la llamada entrante. Si no hizo, verificar el número que es llamado. Haga esto asociando un teléfono a la línea telefónica del lado de origen y llamando el número. Si viene la llamada adentro correctamente, el problema está en el CPE que origina. Si la llamada todavía no aparece en CAS, marque el T1 (el capítulo el 15).In este caso, utiliza el comando debug serial interfaces.

Las demostraciones siguientes una conexión correcta usando el debug modem csm:

Router# debug modem csm
CSM_MODEM_ALLOCATE: slot 1 and port 0 is allocated.
MODEM_REPORT(0001): DEV_INCALL at slot 1 and port 0
CSM_PROC_IDLE: CSM_EVENT_ISDN_CALL at slot 1, port 0
CSM_RING_INDICATION_PROC: RI is on
CSM_RING_INDICATION_PROC: RI is off
CSM_PROC_IC1_RING: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 0
MODEM_REPORT(0001): DEV_CONNECTED at slot 1 and port 0
CSM_PROC_IC2_WAIT_FOR_CARRIER: CSM_EVENT_ISDN_CONNECTED at slot 1, port 0

En este ejemplo, la llamada fue dirigida a un módem. Si su llamada fue dirigida a un módem, proceda “a la sección del troubleshooting de la llamada de módem entrante”, abajo.

Troubleshooting de la llamada de módem entrante

Utilice los comandos debug siguientes al resolver problemas las llamadas de módem entrante:

  • haga el debug del módem

  • debug modem csm (para los módems digitales integrados)

Utilice los comandos debug siguientes en la conjunción de indicar la nueva llamada que viene en:

  • debug isdn q931

  • debug cas

Si se asume que la llamada alcanza el módem, el módem necesita escoger el llamar.

Extremidades para los debugginges del módem externos

Para facilitar el hacer el debug de en un Módem externo conectó con una línea TTY, aumenta el volumen del altavoz. Esto ayuda a hacer algunos problemas más evidentes.

¿Cuando el módem de origen llama, el módem la recepción suena? Si no, verifique el número e intente una llamada manual del sitio remoto. Intente usar un teléfono normal en el extremo receptor también. Substituya los cables y el hardware según las necesidades.

Toma de llamada del módem asincrónico

Si un Módem externo no está contestando, marque el cableado entre el módem y el servidor de acceso o el router. Confirme que el módem está conectado con el TTY o el puerto auxiliar en el router con un cable rolled RJ-45 y un adaptador MMOD DB-25. Cisco recomienda y soporta esta configuración del cable para los puertos RJ-45. Observe que estos conectores están etiquetados típicamente: Módem.

El cableado RJ-45 viene en algunos teclea: derecho, rodado, y cruce. Usted puede determinar el tipo de cable llevando a cabo los dos extremos de un cable RJ-45 de lado a lado. Usted verá ocho franjas coloreadas, o los contactos, en cada extremo.

  • Si el orden de los pines coloreados es igual en cada extremo, el cable es de conexión directa.

  • Si el orden de los colores es opuesto en cada extremo, el cable es enrollado.

  • El cable es un cable de par cruzado si los colores indican el siguiente:

RJ45 al cable de par cruzado RJ45:

RJ45                  RJ45 
         5 ------------------ 2
         2 ------------------ 5
         4 ------------------ 1 
         1 ------------------ 4

Para aseegurarse la señalización es AUTORIZACIÓN, utiliza el comando show line delineado en el capítulo 16.

Las cuestiones del cableado a un lado, un Módem externo necesitan ser inicializadas a la respuesta automática. Marque el módem remoto para ver si está fijado a la respuesta automática. Generalmente, un indicador luminoso AA está en cuando se fija la respuesta automática. Fije el módem remoto a la respuesta automática si no se fija ya. Para la información sobre verificar y el cambio de las configuraciones del módem, refiera a su documentación del módem. Utilice un telnet reverso para inicializar el módem (refiera al capítulo 16).

Respuesta de llamada del módem (integrada) digital

En un Módem externo está claro si se está contestando la llamada, pero los módems internos requieren una llamada manual al número de recepción. Esté atento el Answer Back Tone (ABT). Si usted no oye un ABT, marque la configuración para las dos cosas siguientes:

  1. Aseegurese el comando isdn incoming-voice modem existe bajo cualquier interfaz de ISDN que maneja las conexiones de módem entrante.

  2. Bajo configuración de línea para el TTY del módem, aseegurese el comando modem inout existe.

Es también posible que el Call Switching Module (CS) no afectó un aparato un módem interno para manejar la llamada entrante. Este problema se puede causar por el módem o los agrupamientos de recursos que son configurados para demasiado pocas conexiones entrantes. Puede también significar que el servidor de acceso puede simplemente estar fuera de los módems. Marque la disponibilidad de módems y ajuste el agrupamiento de módems o las configuraciones del administrador de agrupamientos de recursos apropiadamente. Si un módem fue afectado un aparato y los debugs y el contacto Cisco del frunce del modem inout, de las demostraciones de la configuración para la ayuda.

Preparativos del módem

Si el módem de recepción aumenta el DSR, el trainup era acertado. Las fallas de preparación de conexión pueden 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 mientras que ha asociado a los CRISOLES la línea de interés. Si la llamada en un módem digital en un Cisco Access Server, se prepare para registrar un archivo del .wav de la música de preparación de conexión, o de la secuencia de aprendizaje de defecto digital (DIL). El DIL es la secuencia musical (secuencia PCM) que el módem analógico del v.90 que origina dice a módem digital de recepción al reproducir. La secuencia permite que el módem analógico discierna cualquier error defecto digital en el circuito; por ejemplo las conversiones múltiples D/A, un law/u-law, los bits robados, o las amortiguaciones digitales. Si usted no oye el DIL, los módems no negociaron el v.90 en V.8/V.8bis (que es., un problema de compatibilidad del módem). Si usted oye el DIL y un reentrenamiento en el V.34, el módem analógico decidía (en base de la Reproducción DIL) que el v.90 era infeasible.

¿La música tiene ruido en ella? Si es así entonces limpie el circuito.

¿El cliente abandona rápidamente, sin ejecutar el entrenamiento V.34? Por ejemplo, quizás no conoce qué hacer cuando oye el V.8bis. En este caso usted debe intentar inhabilitar el V.8bis (por lo tanto K56Flex) en el servidor (si es aceptable). Usted debe conseguir el nuevo firmware de cliente o intercambiar hacia fuera el modem del cliente. Alternativamente, el extremo de marca podía insertar cinco comas en el extremo de la cadena de marcado. Esto retrasa la escucha del módem de llamada y causará el tono del V.8bis del servidor de recepción al descanso sin afectar al modem del cliente. Cinco comas en la cadena de marcado son Pautas generales y pudieron necesitar ajustar para tener en cuenta las condiciones locales.

Establecimiento de sesión

En este momento en la secuencia, los módems están conectados y entrenados para arriba. Ahora es hora de descubrir si algún tráfico está pareciendo correctamente.

Si la línea que recibe la llamada se configura con el autoselect ppp y la interfaz asincrónica se configura con el modo asincrónico interactivo, utilice el comando debug modem de verificar el proceso de selección automática. Pues el tráfico viene adentro sobre el link asincrónico, el servidor de acceso examinará el tráfico para determinar si el tráfico carácter-está basado o paquete basado. Dependiendo de la determinación, el servidor de acceso después comenzará a una sesión PPP o irá no más lejos que teniendo una sesión EXEC en la línea.

Una secuencia de selección automática normal con los paquetes PPP LCP entrantes:

*Mar  1 21:34:56.958: TTY1: DSR came up
*Mar  1 21:34:56.962: tty1: Modem: IDLE->READY
*Mar  1 21:34:56.970: TTY1: EXEC creation
*Mar  1 21:34:56.978: TTY1: set timer type 10, 30 seconds
*Mar  1 21:34:59.722: TTY1: Autoselect(2) sample 7E 

!--- The inbound traffic is displayed in hexadecimal format. This is based on the
!--- bits coming in over the line, regardless of whether the bits are ASCII
!--- characters or elements of a packet. The bits represented in this example are
!--- correct for a LCP packet. Anything different would be either a malformed packet
!--- or character traffic.

*Mar  1 21:34:59.726: TTY1: Autoselect(2) sample 7EFF
*Mar  1 21:34:59.730: TTY1: Autoselect(2) sample 7EFF7D
*Mar  1 21:34:59.730: TTY1: Autoselect(2) sample 7EFF7D23
*Mar  1 21:34:59.734: TTY1 Autoselect cmd: ppp negotiate 

!--- Having determined that the inbound traffic is actually an LCP packet, the access
!--- server triggers the PPP negotiation process.

*Mar  1 21:34:59.746: TTY1: EXEC creation
*Mar  1 21:34:59.746: TTY1: create timer type 1, 600 seconds
*Mar  1 21:34:59.794: TTY1: destroy timer type 1 (OK)
*Mar  1 21:34:59.794: TTY1: destroy timer type 0
*Mar  1 21:35:01.798: %LINK-3-UPDOWN: Interface Async1, changed state to up 

!--- The async interface changes state to up, and the PPP negotiation (not shown)
!--- commences.

Si la llamada es una sesión PPP y si configuran al modo asincrónico dedicado en la interfaz asincrónica, utilice el comando debug ppp negotiation de ver si algunos paquetes de pedido de configuración están viniendo del extremo remoto. Los debugs muestran éstos como CONFREQ. Si usted observa entrante y los paquetes PPP salientes, proceda a “resolver problemas el PPP”. Si no, conecte del extremo de origen de llamada con una sesión del modo de carácter (o “ejecutivo”) (es decir, a sesión no PPP).

Nota: Si el extremo receptor visualiza el módem asincrónico dedicado bajo interfaz asincrónica, las demostraciones del acceso telefónico exec solamente qué aparece ser basura aleatoria ASCII. Para permitir a una sesión terminal y todavía tener capacidad de PPP, utilice al modo asincrónico del comando async interface configuration interactivo. Bajo configuración de línea asociada, utilice el comando autoselect ppp.

El módem no puede enviar o recibir los datos

Si los módems conectan con una sesión terminal y ningunos datos parecen, marque las posibles causas siguientes y las líneas de acción sugeridas:

  • La configuración de velocidad del módem no es bloqueada

    1. Utilice el comando show line exec en el servidor de acceso o el router. La salida para el puerto auxiliar debe indicar las velocidades actualmente configuradas del tx y del rx.

      Para una explicación de la salida del comando show line, vea “usando la sección de los comandos Debug” en el capítulo 15.

    2. Si la línea no se configura a la velocidad correcta, utilice el comando speed line configuration de fijar la velocidad de línea en el servidor de acceso o la línea del router. Fije el valor a la velocidad más alta del campo común entre el módem y el servidor de acceso o el puerto de router. Para fijar el velocidad en baudios de la terminal, utilice el comando speed line configuration. Este los comandos estableces el transmitir (a la terminal) y reciben (de la terminal) las velocidades.

      Sintaxis:

      velocidad BPS

      Descripción de la sintaxis:

      BPS - Velocidad en baudios en los bits por segundo (BPS). El valor por defecto es 9600 BPS.

      El siguiente ejemplo fija las líneas 1 y 2 en un Cisco 2509 Access Server a 115200 BPS:

      line 1 2
      speed 115200

      Nota: Si, por alguna razón, usted no puede utilizar el control de flujo, limite la velocidad de línea a 9600 BPS. Velocidades más rápidas son probables dar lugar a los datos perdidos.

    3. Utilice el comando show line exec otra vez y confirme que la velocidad de línea está fijada al valor deseado.

    4. Cuando usted está seguro que el servidor de acceso o la línea del router está configurado para la velocidad deseada, inicie a una sesión telnet reversa al módem vía esa línea. Para más información, vea la sección el “establecer de una sesión telnet reversa a un módem” en el capítulo 16.

    5. Utilice una cadena de comandos de módem que incluya el comando " lock dte speed " para su módem. Vea su documentación del módem para la sintaxis exacta del comando de configuración.

    Nota: El comando lock dte speed, que pudo también ser referido mientras que la velocidad de puerto ajusta o modo guardado en memoria intermedia, se relaciona a menudo con la manera de la cual el módem maneja la corrección de errores. Este comando varía extensamente a partir de un módem a otro.

    Bloquear la velocidad del módem se asegura de que el módem comunica siempre con el Cisco Access Server o el router a la velocidad configurada en el puerto auxiliar Cisco. Si este comando no se utiliza, el módem invierte a la velocidad del link de datos (la línea telefónica), en vez de la comunicación a la velocidad configurada en el servidor de acceso.

  • Control de flujo de hardware no configurado en el módem o router local o remoto

    1. Utilice el comando show line aux-line-number exec y busque el siguiente en el campo de las capacidades:

      Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out

      Para más información, refiera a interpretar la salida de línea de la demostración en el capítulo 16.

      Si no hay mención del control de flujo de hardware en este campo, el control de flujo de hardware no se habilita en la línea. El control de flujo de hardware para las conexiones del Access Server al módem se recomienda.

      Para una explicación de la salida del comando show line, vea la sección “usando los comandos Debug” en el capítulo 15.

    2. Configure el control de flujo de hardware en la línea usando el comando flowcontrol hardware line configuration.

      Para fijar el método de control de flujo de datos entre la terminal o el otro dispositivo en serie y el router, utilice el comando flowcontrol line configuration. No utilice la ninguna forma de este comando de inhabilitar el control de flujo.

      Sintaxis:

      control de flujos {ninguno | [lock] del software [en | hacia fuera] | hardware [en | hacia fuera]}

      Descripción de la sintaxis:

      • ningunos - Apaga el control de flujo.

      • software - Fija el control de flujo de software. Una palabra clave optativa especifica la dirección: en hace el Cisco IOS Software escuchar el control de flujo del dispositivo conectado, y hacia fuera hace el software enviar la información de control de flujo al dispositivo conectado. Si usted no especifica una dirección, se asumen ambos.

      • bloqueo - Hace imposible apagar el control de flujo del host remoto cuando el dispositivo conectado necesita el control de flujo de software. Esta opción se aplica a las conexiones usando los protocolos de Telnet o de rlogin.

      • hardware - Fija el control de flujo de hardware. Una palabra clave optativa especifica la dirección: en hace el software escuchar el control de flujo del dispositivo conectado, y hacia fuera hace el software enviar la información de control de flujo al dispositivo conectado. Si usted no especifica una dirección, se asumen ambos. Para más información sobre el control de flujo de hardware, vea el manual de hardware que fue enviado con su router.

      Ejemplo:

      El siguiente ejemplo fija el control de flujo de hardware en la línea 7:

      line 7
      flowcontrol hardware

      Nota: Si por alguna razón usted no puede utilizar el control de flujo, limite la velocidad de línea a 9600 BPS. Velocidades más rápidas son probables dar lugar a los datos perdidos.

    3. Después de habilitar el control de flujo de hardware en el servidor de acceso o la línea del router, inicie a una sesión telnet reversa al módem vía esa línea. Para más información, vea la sección el “establecer de una sesión telnet reversa a un módem” en el capítulo 16.

    4. Utilice una cadena de comandos de módem que incluya el comando RTS/CTS Flow para su módem. Este comando se asegura de que el módem esté utilizando el mismo método de control de flujo (es decir, control de flujo de hardware) que el Cisco Access Server o el router. Vea su documentación del módem para la sintaxis exacta del comando de configuración.

  • Comandos de la correlación del dialer mal configurada

    1. Utilice el comando show running-config privileged exec de ver la configuración del router. Marque el dialer map command entries para ver si transmitir la palabra clave está especificado.

    2. Si la palabra clave falta, agreguela a la configuración.

      Sintaxis:

      dialer map protocol next-hop-address [name hostname] [broadcast] [dial-string]

      Descripción de la sintaxis:

      • protocolo - El protocolo conforme a la asignación. Las opciones incluyen el IP, el IPX, el Bridge, y la foto.

      • next-hop-address - La dirección de protocolo de la interfaz asincrónica del sitio opuesto.

      • nombre de host del nombre - Un parámetro obligatorio usado en la autenticación PPP. Es el nombre del sitio remoto para el cual se crea el mapa de marcado. El nombre es con diferenciación entre mayúsculas y minúsculas y debe hacer juego el nombre de host del router remoto.

      • broadcast - Una palabra clave optativa que paquetes de broadcast (por ejemplo, actualizaciones del RIP IP o IPX RIP/SAP) que se remite al destino remoto. En configuraciones de ejemplo de Static Routing, las actualizaciones de ruteo no se desean y se omite la palabra clave del broadcast.

      • dial-string - El número de teléfono del sitio remoto. Cualquier código de acceso (por ejemplo, 9 a salir de una oficina, de los códigos de marcación internacional, de los códigos de área) debe ser incluido.

    3. Aseegurese que los comandos dialer map especifican a las direcciones del salto siguiente correctas.

    4. Si la dirección del salto siguiente es incorrecta, cambíelo usando el comando dialer map.

    5. Aseegurese todas las otras opciones en los comandos dialer map se especifican correctamente para el protocolo que usted está utilizando.

    Para información detallada sobre configurar los Mapas de marcado, refiera a la Guía de Configuración de redes de área ancha del Cisco IOS y a la referencia del comando wide-area networking.

  • Problema con el módem de marcación

    • Aseegurese que el módem de marcación es operativo y está conectado con seguridad con el puerto correcto. Determine si otro módem funciona cuando está conectado con el mismo puerto.

Hacer el debug de a una sesión exec entrante entra generalmente en algunas categorías principales:

El cliente de marcación manual no recibe ningún prompt exec

  • El Autoselect se habilita en la línea

    La tentativa de acceder al modo EXEC presionando ingresa.

  • La línea se configura con el comando no exec

    1. Utilice el comando show line exec de ver el estatus de la línea apropiada.

      Marque las capacidades colocan para ver si dice el “ejecutivo suprimido.” Si éste es el caso, habilitan al comando no exec line configuration.

    2. Configure el comando exec line configuration en la línea de permitir que inicien a las sesiones EXEC. Este comando no tiene ningunos argumentos o palabra clave.

    El siguiente ejemplo gira el ejecutivo en la línea 7:

    line 7 
    exec
  • El control de flujo no se habilita.

    o

    El control de flujo se habilita solamente en un dispositivo (DTE o DCE).

    o

    Se configura mal el control de flujo.

    1. Utilice el comando show line aux-line-number exec y busque el siguiente en el campo de las capacidades:

      Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out
      

      Para más información, refiera a interpretar la salida de línea de la demostración en el capítulo 16.

      Si no hay mención del control de flujo de hardware en este campo, el control de flujo de hardware no se habilita en la línea. El control de flujo de hardware para las conexiones del Access Server al módem se recomienda.

      Para una explicación de la salida del comando show line, vea “usando la sección de los comandos Debug” en el capítulo 15.

    2. Configure el control de flujo de hardware en la línea usando el comando flowcontrol hardware line configuration. El siguiente ejemplo fija el control de flujo de hardware en la línea 7:

      line 7
      flowcontrol hardware

      Nota: Si por alguna razón usted no puede utilizar el control de flujo, limite la velocidad de línea a 9600 BPS. Velocidades más rápidas son probables dar lugar a los datos perdidos.

    3. Después de habilitar el control de flujo de hardware en el servidor de acceso o la línea del router, inicie a una sesión telnet reversa al módem vía esa línea. Para más información, vea la sección el “establecer de una sesión telnet reversa a un módem” en el capítulo 16.

    4. Utilice una cadena de comandos de módem que incluya el comando RTS/CTS Flow para su módem. Este comando se asegura de que el módem esté utilizando el mismo método de control de flujo (es decir, control de flujo de hardware) que el Cisco Access Server o el router. Vea su documentación del módem para la sintaxis exacta del comando de configuración.

  • La configuración de velocidad del módem no es bloqueada

    1. Utilice el comando show line exec en el servidor de acceso o el router. La salida para el puerto auxiliar debe indicar las velocidades actualmente configuradas del tx y del rx.

      Para una explicación de la salida del comando show line, vea “usando la sección de los comandos Debug” en el capítulo 15.

    2. Si la línea no se configura a la velocidad correcta, utilice el comando speed line configuration de fijar la velocidad de línea en el servidor de acceso o la línea del router. Fije el valor a la velocidad más alta del campo común entre el módem y el servidor de acceso o el puerto de router. Para fijar el velocidad en baudios de la terminal, utilice el comando speed line configuration. Este los comandos estableces el transmitir (a la terminal) y reciben (de la terminal) las velocidades.

      Sintaxis:

      velocidad BPS

      Descripción de la sintaxis:

      BPS - Velocidad en baudios en los bits por segundo (BPS). El valor por defecto es 9600 BPS.

      Ejemplo:

      El siguiente ejemplo fija las líneas 1 y 2 en un Cisco 2509 Access Server a 115200 BPS:

      line 1 2
      speed 115200

      Nota: Si por alguna razón usted no puede utilizar el control de flujo, limite la velocidad de línea a 9600 BPS. Velocidades más rápidas son probables dar lugar a los datos perdidos.

    3. Utilice el comando show line exec otra vez y confirme que la velocidad de línea está fijada al valor deseado.

    4. Cuando usted está seguro que el servidor de acceso o la línea del router está configurado para la velocidad deseada, inicie a una sesión telnet reversa al módem vía esa línea. Para más información, vea la sección el “establecer de una sesión telnet reversa a un módem” en el capítulo 16.

    5. Utilice una cadena de comandos de módem que incluya el comando lock dte speed para su módem. Vea su documentación del módem para la sintaxis exacta del comando de configuración.

    Nota: El comando lock dte speed, que pudo también ser referido mientras que la velocidad de puerto ajusta o modo guardado en memoria intermedia, se relaciona a menudo con la manera de la cual el módem maneja la corrección de errores. Este comando varía extensamente a partir de un módem a otro.

    Bloquear la velocidad del módem se asegura de que el módem comunica siempre con el Cisco Access Server o el router a la velocidad configurada en el puerto auxiliar Cisco. Si este comando no se utiliza, el módem invierte a la velocidad del link de datos (la línea telefónica) en vez de la comunicación a la velocidad configurada en el servidor de acceso.

Las sesiones de marcación manual consideran la “basura”

  • La configuración de velocidad del módem no es bloqueada

    1. Utilice el comando show line exec en el servidor de acceso o el router. La salida para el puerto auxiliar debe indicar las velocidades actualmente configuradas del tx y del rx.

      Para una explicación de la salida del comando show line, vea “usando la sección de los comandos Debug” en el capítulo 15.

    2. Si la línea no se configura a la velocidad correcta, utilice el comando speed line configuration de fijar la velocidad de línea en el servidor de acceso o la línea del router. Fije el valor a la velocidad más alta del campo común entre el módem y el servidor de acceso o el puerto de router.

      Para fijar el velocidad en baudios de la terminal, utilice el comando speed line configuration. Este los comandos estableces el transmitir (a la terminal) y reciben (de la terminal) las velocidades.

      Sintaxis:

      velocidad BPS

      Descripción de la sintaxis:

      BPS de velocidad en baudios en los bits por segundo (BPS). El valor por defecto es 9600 BPS.

      Ejemplo:

      El siguiente ejemplo fija las líneas 1 y 2 en un Cisco 2509 Access Server a 115200 BPS:

      línea 1 2

      velocidad 115200

      Nota: Si por alguna razón usted no puede utilizar el control de flujo, limite la velocidad de línea a 9600 BPS. Velocidades más rápidas son probables dar lugar a los datos perdidos.

    3. Utilice el comando show line exec otra vez y confirme que la velocidad de línea está fijada al valor deseado.

    4. Cuando usted está seguro que el servidor de acceso o la línea del router está configurado para la velocidad deseada, inicie a una sesión telnet reversa al módem vía esa línea. Para más información, vea la sección el “establecer de una sesión telnet reversa a un módem” en el capítulo 16.

    5. Utilice una cadena de comandos de módem que incluya el comando lock dte speed para su módem. Vea su documentación del módem para la sintaxis exacta del comando de configuración.

    Nota: El comando lock dte speed, que pudo también ser referido mientras que la velocidad de puerto ajusta o modo guardado en memoria intermedia, se relaciona a menudo con la manera de la cual el módem maneja la corrección de errores. Este comando varía extensamente a partir de un módem a otro.

    Bloquear la velocidad del módem se asegura de que el módem comunica siempre con el Cisco Access Server o el router a la velocidad configurada en el puerto auxiliar Cisco. Si este comando no se utiliza, el módem invierte a la velocidad del link de datos (la línea telefónica) en vez de la comunicación a la velocidad configurada en el servidor de acceso.

Síntoma: La sesión de marcado remoto abre en una sesión existente iniciada por otro usuario. Es decir, en vez de conseguir un prompt de inicio de sesión, un usuario de marcado ve una sesión establecida por otro usuario (que pudo ser un prompt de comando unix, sesión de editor de texto, y así sucesivamente).

La sesión de marcación manual se abre en la sesión existente

  • Módem configurado para el DCD siempre arriba

    1. El módem se debe configurar de nuevo para tener DCD alta solamente en el CD. Esto es generalmente realizado usando la cadena de comandos de módem &C1, pero marca su documentación del módem para la sintaxis exacta para su módem.

    2. Usted puede ser que tenga que configurar la línea del Access Server con la cual el módem está conectado con el comando no exec line configuration. Borre la línea con el comando clear line privileged exec, inicie a una sesión telnet reversa con el módem, y configure de nuevo el módem de modo que el DCD sea alto solamente en el CD.

    3. Termine a la sesión telnet ingresando la desconexión y configure de nuevo la línea del Access Server con el comando exec line configuration

  • El control del módem no se habilita en el servidor de acceso o el router

    1. Utilice el comando show line exec en el servidor de acceso o el router. La salida para el puerto auxiliar debe ser inout o RIisCD de la demostración en la columna de módem. Esto indica que el control del módem está habilitado en la línea del servidor de acceso o del router.

      Para una explicación de la salida de línea de la demostración, vea “usando la sección de los comandos Debug” en el capítulo 15.

    2. Configure la línea para el control del módem usando el comando modem inout line configuration. El control del módem ahora se habilita en el servidor de acceso.

    Nota: Esté seguro de utilizar el comando modem inout en vez del comando modem dialin mientras que la Conectividad del módem está en la pregunta. El u'ltimo comando permite que la línea valide las llamadas entrantes solamente. Las llamadas salientes serán rechazadas, haciéndola imposible establecer a una sesión telnet con el módem para configurarlo. Si usted quiere habilitar el comando modem dialin, haga tan solamente después que usted está seguro que está funcionando el módem correctamente.

  • Cableado incorrecto

    1. Marque el cableado entre el módem y el servidor de acceso o el router. Confirme que el módem está conectado con el puerto auxiliar en el servidor de acceso o el router con un cable rolled RJ-45 y un adaptador MMOD DB-25. Esta configuración del cableado es recomendada y soportada por Cisco para los puertos RJ-45. Estos conectores se etiquetan típicamente: Módem.

      Hay dos tipos del cableado RJ-45: derecho y rodado. Si usted se sostiene los dos finales de un RJ-45 telegrafían de lado a lado, usted verá ocho franjas coloreadas, o los contactos, en cada extremo. Si el orden de los pines de color es el mismo en cada extremo, el cable está derecho. Si se invierte el orden de los colores en cada extremo, entonces se enrolla el cable.

      El cable enrollado (CAB-500RJ) es estándar con el 2500/CS500 de Cisco.

    2. Utilice el comando show line exec de verificar que el cableado está correcto. Vea la explicación del comando show line hecho salir en la sección “usando los comandos Debug” en este capítulo 15.

El Módem receptor de marcado manual no desconecta correctamente

  • El módem no está detectando el DTR

    Ingrese la cadena de comando Hangup DTR modem. Este comando dice el módem caer el portador cuando la señal DTR se está recibiendo no más.

    En un módem compatible con Hayes la cadena &D3 es de uso general configurar la parada DTR en el módem. Para la sintaxis exacta de este comando, vea la documentación para su módem.

  • El control del módem no se habilita en el router o el servidor de acceso

    1. Utilice el comando show line exec en el servidor de acceso o el router. La salida para el puerto auxiliar debe mostrar el inout o RIisCD en la columna de módem. Esto indica que el control del módem está habilitado en la línea del servidor de acceso o del router.

      Para una explicación de la salida de línea de la demostración, vea “usando la sección de los comandos Debug” en el capítulo 15.

    2. Configure la línea para el control del módem usando el comando modem inout line configuration. El control del módem ahora se habilita en el servidor de acceso.

    Nota: Esté seguro de utilizar el comando modem inout en vez del comando modem dialin mientras que la Conectividad del módem está en la pregunta. El u'ltimo comando permite que la línea valide las llamadas entrantes solamente. Las llamadas salientes serán rechazadas, haciéndola imposible establecer a una sesión telnet con el módem para configurarlo. Si usted quiere habilitar el comando modem dialin, haga tan solamente después que usted está seguro que está funcionando el módem correctamente.

Resolver problemas las llamadas de salida

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 busca el 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)

Verificar el funcionamiento del dialer

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).

El tráfico no inicia un intento de marcado

  • 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, después 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” - no de 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 “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 direccionamiento del isthe del 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 comando show ip route [a.b.c.d] de verificar 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.

Llamada no puesta

Algunos Posibles problemas y acciones sugeridas son mencionados abajo:

  • 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 señale 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.

Llamada saliente del async - Verifique la operación del chat script

Si la llamada de salida es una llamada 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

Los problemas del chat script se pueden romper en tres categorías:

  • Error de configuración

  • Falla del módem

  • Falla de conexión

Error del chat script

Esta lista muestra las salidas posibles de las demostraciones y de las acciones sugeridas de charla del debug:

  • ningún chat script que corresponde con encontrado para [number]

    Un chat script no se ha configurado. Agregue uno.

  • Dialout del chat script acabado, estatus = conexión medida el tiempo hacia fuera; el host remoto no responde

    El módem no está respondiendo al chat script. Verifique la comunicación con el módem (refiera al cuadro 16-2 en el capítulo 16).

  • Espera del descanso: CONNECT(conectar)

    • Posibilidad 1: El módem local no está poniendo realmente la llamada. Verifique que el módem pueda poner una llamada realizando Telnet reverso al módem y manualmente iniciando un dial.

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

    • 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. Si el módem local es externo, dé vuelta encima del volumen del altavoz del módem y escuche los tonos del trainup. Si el trainup se corta precipitadamente, intente aumentar el valor de agotamiento del tiempo en el comando chat-script. Si el DESCANSO es ya 60 segundos o más, vea la sección de los preparativos del módem.

Llamada saliente ISDN

A la primera sospecha de una falla ISDN, en un BRI o 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 “interpretando la sección de la demostración isdn status output” en el capítulo 16 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 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

!--- The CONNECT message is the key indicator of success. If a CONNECT is not received,
!--- you may see a DISCONNECT or a RELEASE_COMP (release complete) message followed by
!--- a cause code (see below)

*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 de donde en el trayecto de llamada de extremo a extremo 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 las tablas que siguen para los significados de los diversos valores.

Nota: El informe de ejecución siguiente indica generalmente 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

Campos de código de causa

El cuadro 17-9 enumera los campos de código de causa ISDN que visualizan en el formato siguiente dentro de los comandos debug:

i=0x y1 y2 z1 z2 [a1 a2]

Campos de código de causa ISDN

Campo Descripción del valor
0x Los valores que siguen están en el hexadecimal.
y1 Codificación estándar 8--ITU-T.
y2 red A del usuario remoto 7--International de la porción de la red del usuario remoto 5--Private de la porción de la red de la red 4--Public del usuario local 3--Transit de la porción de la red del usuario local 2--Public de la porción de la red 0--User 1--Private--Red más allá punta funcionamiento entre redes
z1 Clase (más el número hexadecimal más importante) de valor de causa. Refiera a la tabla siguiente para información detallada sobre los valores posibles.
z2 Valor (menos el número hexadecimal más importante) del valor de causa. Refiera a la tabla siguiente para información detallada sobre los valores posibles.
a1 Campo de diagnóstico (opcional) que es siempre 8.
a2 Campo de diagnóstico (opcional) que es uno de los valores siguientes: 0--Unknown 1--Permanent 2--Transient

Valores de causa ISDN

La tabla siguiente enumera las descripciones de algunos de la mayoría de los valores de causa frecuentemente vistos del elemento de información de causa - el tercero y los cuartos bytes del código de la causa. Para información más completa sobre los códigos de ISDN y los valores, refiera comprensión de los códigos de la causa de desconexión del debug ISDN q931.

Valor hex Causa Explicación
81 Número (no asignado) Unallocated El número ISDN fue enviado al Switch en el formato correcto; sin embargo, el número no se asigna a ningún equipo de destino.
90 Verificación normal de llamadas La Verificación normal de llamadas ha ocurrido.
91 Usuario ocupado El sistema llamado reconoce el pedido de conexión pero no puede validar la llamada porque todos los canales B son funcionando.
92 Sin respuesta de usuarios La conexión no puede ser completada porque el destino no responde a la llamada.
93 Ninguna respuesta del usuario (usuario alertado) El destino responde al pedido de conexión pero no puede completar la conexión en el tiempo prescrito. El problema está en el extremo remoto de la conexión.
95 Llamada rechazada El destino es capaz de validar la llamada pero rechazado le por una razón desconocida.
9C El formato del número no es válido La conexión podría no ser establecida porque presentaron la dirección destino en un formato no reconocible o porque la dirección destino era incompleta.
9F Normal, sin especificar Informa si ocurrió un evento normal que no haya sido consecuencia de una causa estándar. No se requiere acción
A2 Ningún circuito/canal disponible La conexión no puede ser establecida porque no hay canal apropiado disponible tomar la llamada.
A6 Red no disponible El destino no puede ser alcanzado porque no está funcionando la red correctamente, y la condición pudo durar durante un largo período de tiempo. Un intento de reconexión inmediata será probablemente fracasado.
AC Circuito/canal requerido no disponible El equipo remoto no puede brindar el canal solicitado por un motivo desconocido. Esto pudo ser un problema temporario.
B2 Prestación solicitada no disponibe (requiere suscripción) El equipo remoto admite el servicio suplementario solicitado sólo mediante suscripción. Esto es con frecuencia una referencia al servicio de larga distancia.
B9 Capacidad portadora no autorizada El usuario pidió una capacidad portadora que la red proporciona, pero no autorizan al usuario a utilizarla. Esto pudo ser un problema de suscripción.
D8 Destino incompatible Indica que una tentativa fue hecha para conectar con el equipo no ISDN. Por ejemplo, a una línea analógica.
E0 El elemento de información obligatoria falta El equipo de recepción recibió un mensaje que no incluyó uno de los elementos de información obligatoria. Por lo general, esto se debe a un error en el canal D. Si ocurre este error sistemáticamente, señálelo a su proveedor del servicio ISDN.
E4 Contenidos de elemento de información no válidos El equipo remoto recibió un mensaje que incluye la información no válida en el elemento de información. Por lo general, esto se debe a un error en el canal D.

Llamada saliente de CAS

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 verificar el funcionamiento del dialer.

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:

  • haga el debug del módem

  • debug modem csm

  • 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# 
router#modem-mgmt csm no-debug-rbs 
neat msg at slot 0: debug-rbs is off 

Nota: 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. Refiera al capítulo 15 para la información de Troubleshooting T1.

Resolver problemas el PPP

Resolver problemas la porción PPP de una conexión comienza cuando usted sabe que la conexión de marcado, el ISDN o el async, establece con éxito.

Es importante entender lo que parece una secuencia acertada del debug PPP antes de que usted resuelva problemas la negociación PPP. De esta manera, comparando una sesión defectuosa del debug PPP contra una secuencia acertado-completada del debug PPP le guarda el tiempo y esfuerzo.

Lo que sigue es un ejemplo de una secuencia acertada PPP. Vea los detalles de la negociación de LCP PPP para una descripción detallada de los campos de resultado.

Montecito# 
Mar 13 10:57:13.415: %LINK-3-UPDOWN: Interface Async1, changed state to up
Mar 13 10:57:15.415: As1 LCP: O CONFREQ [ACKrcvd] id 2 len 25
Mar 13 10:57:15.415: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Mar 13 10:57:15.415: As1 LCP:    AuthProto CHAP (0x0305C22305)
Mar 13 10:57:15.415: As1 LCP:    MagicNumber 0x1084F0A2 (0x05061084F0A2)
Mar 13 10:57:15.415: As1 LCP:    PFC (0x0702)
Mar 13 10:57:15.415: As1 LCP:    ACFC (0x0802)
Mar 13 10:57:15.543: As1 LCP: I CONFACK [REQsent] id 2 len 25
Mar 13 10:57:15.543: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Mar 13 10:57:15.543: As1 LCP:    AuthProto CHAP (0x0305C22305)
Mar 13 10:57:15.543: As1 LCP:    MagicNumber 0x1084F0A2 (0x05061084F0A2)
Mar 13 10:57:15.543: As1 LCP:    PFC (0x0702)
Mar 13 10:57:15.547: As1 LCP:    ACFC (0x0802)
Mar 13 10:57:16.919: As1 LCP: I CONFREQ [ACKrcvd] id 4 len 23
Mar 13 10:57:16.919: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Mar 13 10:57:16.919: As1 LCP:    MagicNumber 0x001327B0 (0x0506001327B0)
Mar 13 10:57:16.919: As1 LCP:    PFC (0x0702)
Mar 13 10:57:16.919: As1 LCP:    ACFC (0x0802)
Mar 13 10:57:16.919: As1 LCP:    Callback 6  (0x0D0306)
Mar 13 10:57:16.919: As1 LCP: O CONFREJ [ACKrcvd] id 4 len 7
Mar 13 10:57:16.919: As1 LCP:    Callback 6  (0x0D0306)
Mar 13 10:57:17.047: As1 LCP: I CONFREQ [ACKrcvd] id 5 len 20
Mar 13 10:57:17.047: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Mar 13 10:57:17.047: As1 LCP:    MagicNumber 0x001327B0 (0x0506001327B0)
Mar 13 10:57:17.047: As1 LCP:    PFC (0x0702)
Mar 13 10:57:17.047: As1 LCP:    ACFC (0x0802)
Mar 13 10:57:17.047: As1 LCP: O CONFACK [ACKrcvd] id 5 len 20
Mar 13 10:57:17.047: As1 LCP:    ACCM 0x000A0000 (0x0206000A0000)
Mar 13 10:57:17.047: As1 LCP:    MagicNumber 0x001327B0 (0x0506001327B0)
Mar 13 10:57:17.047: As1 LCP:    PFC (0x0702)
Mar 13 10:57:17.047: As1 LCP:    ACFC (0x0802)
Mar 13 10:57:17.047: As1 LCP: State is Open
Mar 13 10:57:17.047: As1 PPP: Phase is AUTHENTICATING, by this end
Mar 13 10:57:17.047: As1 CHAP: O CHALLENGE id 1 len 28 from "Montecito"
Mar 13 10:57:17.191: As1 CHAP: I RESPONSE id 1 len 30 from "Goleta"
Mar 13 10:57:17.191: As1 CHAP: O SUCCESS id 1 len 4
Mar 13 10:57:17.191: As1 PPP: Phase is UP
Mar 13 10:57:17.191: As1 IPCP: O CONFREQ [Closed] id 1 len 10
Mar 13 10:57:17.191: As1 IPCP:    Address 172.22.66.23 (0x0306AC164217)
Mar 13 10:57:17.303: As1 IPCP: I CONFREQ [REQsent] id 1 len 40
Mar 13 10:57:17.303: As1 IPCP:    CompressType VJ 15 slots CompressSlotID
 (0x0206002D0F01)
Mar 13 10:57:17.303: As1 IPCP:    Address 0.0.0.0 (0x030600000000)
Mar 13 10:57:17.303: As1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Mar 13 10:57:17.303: As1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Mar 13 10:57:17.303: As1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Mar 13 10:57:17.303: As1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Mar 13 10:57:17.303: As1 IPCP: O CONFREJ [REQsent] id 1 len 22
Mar 13 10:57:17.303: As1 IPCP:    CompressType VJ 15 slots CompressSlotID
 (0x0206002D0F01)
Mar 13 10:57:17.303: As1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Mar 13 10:57:17.303: As1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Mar 13 10:57:17.319: As1 CCP: I CONFREQ [Not negotiated] id 1 len 15
Mar 13 10:57:17.319: As1 CCP:    MS-PPC supported bits 0x00000001 (0x120600000001)
Mar 13 10:57:17.319: As1 CCP:    Stacker history 1 check mode EXTENDED (0x1105000104)
Mar 13 10:57:17.319: As1 LCP: O PROTREJ [Open] id 3 len 21 protocol CCP
Mar 13 10:57:17.319: As1 LCP:  (0x80FD0101000F12060000000111050001)
Mar 13 10:57:17.319: As1 LCP:  (0x04)
Mar 13 10:57:17.319: As1 IPCP: I CONFACK [REQsent] id 1 len 10
Mar 13 10:57:17.319: As1 IPCP:    Address 172.22.66.23 (0x0306AC164217)
Mar 13 10:57:18.191: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async1,
 changed state to up
Mar 13 10:57:19.191: As1 IPCP: TIMEout: State ACKrcvd
Mar 13 10:57:19.191: As1 IPCP: O CONFREQ [ACKrcvd] id 2 len 10
Mar 13 10:57:19.191: As1 IPCP:    Address 172.22.66.23 (0x0306AC164217)
Mar 13 10:57:19.315: As1 IPCP: I CONFACK [REQsent] id 2 len 10
Mar 13 10:57:19.315: As1 IPCP:    Address 172.22.66.23 (0x0306AC164217)
Mar 13 10:57:20.307: As1 IPCP: I CONFREQ [ACKrcvd] id 2 len 34
Mar 13 10:57:20.307: As1 IPCP:    Address 0.0.0.0 (0x030600000000)
Mar 13 10:57:20.307: As1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Mar 13 10:57:20.307: As1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Mar 13 10:57:20.307: As1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Mar 13 10:57:20.307: As1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Mar 13 10:57:20.307: As1 IPCP: O CONFREJ [ACKrcvd] id 2 len 16
Mar 13 10:57:20.307: As1 IPCP:    PrimaryWINS 0.0.0.0 (0x820600000000)
Mar 13 10:57:20.307: As1 IPCP:    SecondaryWINS 0.0.0.0 (0x840600000000)
Mar 13 10:57:20.419: As1 IPCP: I CONFREQ [ACKrcvd] id 3 len 22
Mar 13 10:57:20.419: As1 IPCP:    Address 0.0.0.0 (0x030600000000)
Mar 13 10:57:20.419: As1 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
Mar 13 10:57:20.419: As1 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
Mar 13 10:57:20.419: As1 IPCP: O CONFNAK [ACKrcvd] id 3 len 22
Mar 13 10:57:20.419: As1 IPCP:    Address 10.1.1.1 (0x03060A010101)
Mar 13 10:57:20.419: As1 IPCP:    PrimaryDNS 171.68.10.70 (0x8106AB440A46)
Mar 13 10:57:20.419: As1 IPCP:    SecondaryDNS 171.68.10.140 (0x8306AB440A8C)
Mar 13 10:57:20.543: As1 IPCP: I CONFREQ [ACKrcvd] id 4 len 22
Mar 13 10:57:20.543: As1 IPCP:    Address 10.1.1.1 (0x03060A010101)
Mar 13 10:57:20.547: As1 IPCP:    PrimaryDNS 171.68.10.70 (0x8106AB440A46)
Mar 13 10:57:20.547: As1 IPCP:    SecondaryDNS 171.68.10.140 (0x8306AB440A8C)
Mar 13 10:57:20.547: As1 IPCP: O CONFACK [ACKrcvd] id 4 len 22
Mar 13 10:57:20.547: As1 IPCP:    Address 10.1.1.1 (0x03060A010101)
Mar 13 10:57:20.547: As1 IPCP:    PrimaryDNS 171.68.10.70 (0x8106AB440A46)
Mar 13 10:57:20.547: As1 IPCP:    SecondaryDNS 171.68.10.140 (0x8306AB440A8C)
Mar 13 10:57:20.547: As1 IPCP: State is Open
Mar 13 10:57:20.551: As1 IPCP: Install route to 10.1.1.1

Nota: Sus debugs pueden aparecer en un diverso formato. Este ejemplo muestra a más nuevo formato de salida del debugging de PPP cuál fue modificado en la versión de IOS 11.2(8). Vea el capítulo 16 para un ejemplo del debugging de PPP con las versiones anteriores del IOS.

Detalles de la negociación de LCP PPP

Sello de fecha/hora Descripción
10:57:15.415 Pedido de configuración saliente (O CONFREQ). El NAS envía un paquete de pedido de configuración PPP saliente al cliente.
10:57:15.543 Acuse de recibo entrante de la configuración (I CONFACK). El cliente reconoce la petición PPP de Montecito.
10:57:16.919 Pedido entrante de configuración (I CONFREQ). El cliente quiere negociar el protocolo de devolución de llamada.
10:57:16.919 Rechazo de la configuración saliente (O CONFREJ). El NAS rechaza la opción de devolución de llamada.
10:57:17.047 Pedido entrante de configuración (I CONFREQ). Los pedidos de cliente un nuevo conjunto de opciones. Note que la devolución de llamada de Microsoft no está pedida este vez.
10:57:17.047 Acuse de recibo de la configuración saliente (O CONFACK). El NAS valida el nuevo conjunto de opciones.
10:57:17.047 La negociación de LCP PPP se completa con éxito. El estado LCP es “se abre”. Los ambos lados han reconocido (CONFACK) el otro pedido de configuración del lado (CONFREQ).
10:57:17.047 hasta 10:57:17.191 La autenticación PPP se completa con éxito. Después de que el LCP negocie, la autenticación comienza. La autenticación debe ocurrir antes de que cualquier Network Protocol, tal como IP, se entregue. Los ambos lados autentican con el método negociado durante el LCP. El montecito está autenticando al cliente que usa la GRIETA.
10:57:20.551 El estado está abierto para el IP Control Protocol (IPCP). Una ruta se negocia y está instalada para el par IPCP, que es IP Address asignado 1.1.1.1.

Link Control Protocol

Encuentran a dos tipos de problema típicamente durante la negociación LCP.

El primer ocurre cuando un par hace los pedidos de configuración que el otro par no puede ni reconocerá. Mientras que esto es un suceso de aparición con frecuente, puede ser un problema si el solicitante insiste en el parámetro. Un Ejemplo ejemplo típico es al negociar el AUTHTYPE (también conocido como “AuthProto”). Por ejemplo, mucho Access Servers se configura para validar solamente la GRIETA para la autenticación. Si configuran al llamador para hacer solamente la autenticación PAP, los CONFREQ y los CONFNAK serán intercambiados hasta un par o el otro cae la conexión.

BR0:1 LCP: I CONFREQ [ACKrcvd] id 66 len 14
BR0:1 LCP:    AuthProto PAP (0x0304C023)
BR0:1 LCP:    MagicNumber 0xBC6B9F91 (0x0506BC6B9F91)
BR0:1 LCP: O CONFNAK [ACKrcvd] id 66 len 9
BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
BR0:1 LCP: I CONFREQ [ACKrcvd] id 67 len 14
BR0:1 LCP:    AuthProto PAP (0x0304C023)
BR0:1 LCP:    MagicNumber 0xBC6B9F91 (0x0506BC6B9F91)
BR0:1 LCP: O CONFNAK [ACKrcvd] id 67 len 9
BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
BR0:1 LCP: I CONFREQ [ACKrcvd] id 68 len 14
BR0:1 LCP:    AuthProto PAP (0x0304C023)
BR0:1 LCP:    MagicNumber 0xBC6B9F91 (0x0506BC6B9F91)
BR0:1 LCP: O CONFNAK [ACKrcvd] id 68 len 9
BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
...
...

El segundo tipo de problema en el LCP es cuando solamente los CONFREQ salientes se ven en un o ambo pares como en el ejemplo abajo. Éste es generalmente el resultado de qué se refiere como discrepancia de velocidad en la capa inferior. Esta condición puede ocurrir en el async o ISDN DDR.

Jun 10 19:57:59.768: As5 PPP: Phase is ESTABLISHING, Active Open  
Jun 10 19:57:59.768: As5 LCP: O CONFREQ [Closed] id 64 len 25  
Jun 10 19:57:59.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) 
Jun 10 19:57:59.768: As5 LCP: AuthProto CHAP (0x0305C22305) 
Jun 10 19:57:59.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2)
Jun 10 19:57:59.768: As5 LCP: PFC (0x0702)
Jun 10 19:57:59.768: As5 LCP: ACFC (0x0802) 
Jun 10 19:58:01.768: As5 LCP: TIMEout: State REQsent  
Jun 10 19:58:01.768: As5 LCP: O CONFREQ [REQsent] id 65 len 25 
Jun 10 19:58:01.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) 
Jun 10 19:58:01.768: As5 LCP: AuthProto CHAP (0x0305C22305) 
Jun 10 19:58:01.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2)
Jun 10 19:58:01.768: As5 LCP: PFC (0x0702)
Jun 10 19:58:01.768: As5 LCP: ACFC (0x0802). 
Jun 10 19:58:03.768: As5 LCP: TIMEout: State REQsent  
Jun 10 19:58:03.768: As5 LCP: O CONFREQ [REQsent] id 66 len 25 
Jun 10 19:58:03.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) 
Jun 10 19:58:03.768: As5 LCP: AuthProto CHAP (0x0305C22305) 
Jun 10 19:58:03.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2)
Jun 10 19:58:03.768: As5 LCP: PFC (0x0702)
Jun 10 19:58:03.768: As5 LCP: ACF.C (0x0802) 
Jun 10 19:58:05.768: As5 LCP: TIMEout: State REQsent  
Jun 10 19:58:05.768: As5 LCP: O CONFREQ [REQsent] id 67 len 25 

!--- This repeats every two seconds until:

Jun 10 19:58:19.768: As5 LCP: O CONFREQ [REQsent] id 74 len 25 
Jun 10 19:58:19.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) 
Jun 10 19:58:19.768: As5 LCP: AuthProto CHAP (0x0305C22305) 
Jun 10 19:58:19.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2)
Jun 10 19:58:19.768: As5 LCP: PFC (0x0702)
Jun 10 19:58:19.768: As5 LCP: ACFC (0x0802)  
Jun 10 19:58:21.768: As5 LCP: TIMEout: State REQsent  
Jun 10 19:58:21.768: TTY5: Async Int reset: Dropping DTR

Si la conexión es async, la causa probable es una discrepancia de velocidad entre el router y su módem. Esto está generalmente como resultado de no poder bloquear la velocidad DTE del módem a la velocidad configurada de la línea TTY. El problema se puede encontrar en cualquiera o ambos pares, así que marque ambos. Refiera al módem no puede enviar o recibir los datos anterior en este capítulo.

Si se consideran los síntomas cuando la conexión está sobre el ISDN, el problema es probable ser que un par está conectando en el 56K mientras que el otro está en 64K. Mientras que esta condición es rara, sucede. El problema podía ser un o ambo pares, o posiblemente la compañía telefónica. Utilice el debug ISDN q931 y examine los mensajes setup en cada uno de los pares. La capacidad portadora enviada a partir de un par debe hacer juego la capacidad portadora considerada en el mensaje setup recibido en el otro par. Como remedio posible, configure la velocidad, el 56K o el 64K de marca, en el mapa de marcado del comando interface level o en el comando dialer isdn speed configurado bajo un map-class.

*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

Esta situación es una que puede autorizar una llamada al TAC de Cisco. Recoja los productos siguientes de ambos pares antes de llamar TAC:

  • show running-config

  • show version

  • debug isdn q931

  • debug isdn events

  • debug ppp negotiation

Autenticación

La autenticación fallida es la sola la mayoría de las razones comunes para una falla PPP. Los nombres de usuario y contraseña configurados mal o unidos mal crean los mensajes de error en la salida de los debugs.

El siguiente ejemplo muestra que el Goleta del nombre de usuario no tiene permiso para marcar adentro al NAS, que no tiene un nombre de usuario local configurado para este usuario. Para reparar el problema, utilice el comando username name password password de agregar el nombre de usuario “Goleta” a la base de datos local AAA NAS:

Mar 13 11:01:42.399: As2 LCP: State is Open
Mar 13 11:01:42.399: As2 PPP: Phase is AUTHENTICATING, by this end
Mar 13 11:01:42.399: As2 CHAP: O CHALLENGE id 1 len 28 from "Montecito"
Mar 13 11:01:42.539: As2 CHAP: I RESPONSE id 1 len 30 from "Goleta"
Mar 13 11:01:42.539: As2 CHAP: Unable to validate Response.  Username Goleta not found
Mar 13 11:01:42.539: As2 CHAP: O FAILURE id 1 len 26 msg is "Authentication failure"
Mar 13 11:01:42.539: As2 PPP: Phase is TERMINATING

El siguiente ejemplo muestra que el nombre de usuario “Goleta” está configurado en el NAS. Sin embargo, la comparación de contraseña fallada. Para reparar este problema, utilice el comando username name password password de especificar la contraseña de inicio de sesión correcta para el Goleta:

Mar 13 11:04:06.843: As3 LCP: State is Open
Mar 13 11:04:06.843: As3 PPP: Phase is AUTHENTICATING, by this end
Mar 13 11:04:06.843: As3 CHAP: O CHALLENGE id 1 len 28 from "Montecito"
Mar 13 11:04:06.987: As3 CHAP: I RESPONSE id 1 len 30 from "Goleta"
Mar 13 11:04:06.987: As3 CHAP: O FAILURE id 1 len 25 msg is "MD/DES compare failed"
Mar 13 11:04:06.987: As3 PPP: Phase is TERMINATING

Para más información sobre la autenticación PAP refiera a configurar y a resolver problemas el protocolo ppp password authentication (PAP).

Protocolo network control

Después de que los pares hayan realizado con éxito la autenticación necesaria, la negociación se traslada a la fase NCP. Si configuran a ambos pares correctamente, la negociación NCP pudo parecer el siguiente ejemplo en el cual muestra PC del cliente una marca y la negociación con un NAS:

solvang# show debug
Generic IP:
IP peer address activity debugging is on
PPP:
PPP protocol negotiation debugging is on

*Mar  1 21:35:04.186: As4 PPP: Phase is UP
*Mar  1 21:35:04.190: As4 IPCP: O CONFREQ [Not negotiated] id 1 len 10
*Mar  1 21:35:04.194: As4 IPCP:    Address 10.1.2.1 (0x03060A010201)
*Mar  1 21:35:04.282: As4 IPCP: I CONFREQ [REQsent] id 1 len 28
*Mar  1 21:35:04.282: As4 IPCP:    CompressType VJ 15 slots CompressSlotID
 (0x0206002D0F01)
*Mar  1 21:35:04.286: As4 IPCP:    Address 0.0.0.0 (0x030600000000)
*Mar  1 21:35:04.290: As4 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
*Mar  1 21:35:04.298: As4 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
*Mar  1 21:35:04.306: As4 IPCP: O CONFREJ [REQsent] id 1 len 10
*Mar  1 21:35:04.310: As4 IPCP:    CompressType VJ 15 slots CompressSlotID
 (0x0206002D0F01)
*Mar  1 21:35:04.314: As4 CCP: I CONFREQ [Not negotiated] id 1 len 15
*Mar  1 21:35:04.318: As4 CCP:    MS-PPC supported bits 0x00000001 (0x120600000001)
*Mar  1 21:35:04.318: As4 CCP:    Stacker history 1 check mode EXTENDED (0x1105000104)
*Mar  1 21:35:04.322: As4 LCP: O PROTREJ [Open] id 3 len 21 protocol CCP
*Mar  1 21:35:04.326: As4 LCP:  (0x80FD0101000F12060000000111050001)
*Mar  1 21:35:04.330: As4 LCP:  (0x04)
*Mar  1 21:35:04.334: As4 IPCP: I CONFACK [REQsent] id 1 len 10
*Mar  1 21:35:04.338: As4 IPCP:    Address 10.1.2.1 (0x03060A010201)
*Mar  1 21:35:05.186: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async4,
 changed state to up
*Mar  1 21:35:07.274: As4 IPCP: I CONFREQ [ACKrcvd] id 2 len 22
*Mar  1 21:35:07.278: As4 IPCP:    Address 0.0.0.0 (0x030600000000)
*Mar  1 21:35:07.282: As4 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
*Mar  1 21:35:07.286: As4 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
*Mar  1 21:35:07.294: As4 IPCP: O CONFNAK [ACKrcvd] id 2 len 22
*Mar  1 21:35:07.298: As4 IPCP:    Address 10.1.2.2 (0x03060A010202)
*Mar  1 21:35:07.302: As4 IPCP:    PrimaryDNS 10.2.2.3 (0x81060A020203)
*Mar  1 21:35:07.310: As4 IPCP:    SecondaryDNS 10.2.3.1 (0x83060A020301)
*Mar  1 21:35:07.426: As4 IPCP: I CONFREQ [ACKrcvd] id 3 len 22
*Mar  1 21:35:07.430: As4 IPCP:    Address 10.1.2.2 (0x03060A010202)
*Mar  1 21:35:07.434: As4 IPCP:    PrimaryDNS 10.2.2.3 (0x81060A020203)
*Mar  1 21:35:07.442: As4 IPCP:    SecondaryDNS 10.2.3.1 (0x83060A020301)
*Mar  1 21:35:07.446: ip_get_pool: As4: validate address = 10.1.2.2
*Mar  1 21:35:07.450: ip_get_pool: As4: using pool default
*Mar  1 21:35:07.450: ip_get_pool: As4: returning address = 10.1.2.2
*Mar  1 21:35:07.454: set_ip_peer_addr: As4: address = 10.1.2.2 (3) is redundant
*Mar  1 21:35:07.458: As4 IPCP: O CONFACK [ACKrcvd] id 3 len 22
*Mar  1 21:35:07.462: As4 IPCP:    Address 10.1.2.2 (0x03060A010202)
*Mar  1 21:35:07.466: As4 IPCP:    PrimaryDNS 10.2.2.3 (0x81060A020203)
*Mar  1 21:35:07.474: As4 IPCP:    SecondaryDNS 10.2.3.1 (0x83060A020301)
*Mar  1 21:35:07.478: As4 IPCP: State is Open
*Mar  1 21:35:07.490: As4 IPCP: Install route to 10.1.2.2

Detalles de la negociación PPP NCP

Sello de fecha/hora Descripción
21:35:04.190 Pedido de configuración saliente (O CONFREQ). El NAS envía un paquete de pedido de configuración PPP saliente que contiene su dirección IP al par.
21:35:04.282 CONFREQ entrante. Las solicitudes de peer de hacer la compresión del encabezamiento VJ. Necesita una dirección IP para sí mismo, así como los direccionamientos de los servidores DNS principales y secundarios.
21:35:04.306 Outbound Config-Reject (CONFREJ). Se rechaza la compresión del encabezamiento VJ.
21:35:04.314 hasta 21:35:04.330 El par envía una petición de hacer el protocolo compression control; el protocolo completo es rechazado por el NAS mediante un mensaje protrej. El par no debe (y no hace) intentar revisar el CCP.
21:35:04.334 El par reconoce la dirección IP del NAS con un CONFACK.
21:35:07.274 CONFREQ entrante. Del par las peticiones no más de hacer la compresión del encabezamiento VJ, pero todavía necesitan una dirección IP para sí mismo, así como los direccionamientos de los servidores DNS principales y secundarios.
21:35:07.294 El NAS envía un CONFNAK que contiene el direccionamiento que quisiera que el par utilizara, y los direccionamientos de los servidores DNS principales y secundarios.
21:35:07.426 El par envía los direccionamientos de nuevo al NAS; una tentativa de confirmar que los direccionamientos fueron recibidos correctamente.
21:35:07.458 El NAS reconoce los direccionamientos con un CONFACK.
21:35:07.478 Cada lado de la conexión que publica un CONFACK, negociación acaba. El comando show interfaces Async4 en el NAS muestra el “IPCP: Ábrase”.
21:35:07.490 Una ruta del host al peer remoto está instalada en la tabla de ruteo NAS.

Es posible que los pares negocien simultáneamente más de un protocolo de la capa 3. No es infrecuente, por ejemplo, ver el IP y el IPX que son negociados. Es también posible que un protocolo negocie con éxito mientras que el otro no puede hacer tan.

Resolver problemas el NCP

Cualquier problema que ocurran durante la negociación NCP se puede localizar típicamente a las configuraciones de los pares de negociación. Si la negociación PPP falla durante la fase NCP, refiera a los pasos siguientes:

  1. Verifique la configuración del protocolo de la interfaz

    Examine la salida del privileged exec command show running-config. Verifique que la interfaz esté configurada para soportar el protocolo que usted desea ejecutar encima la conexión.

  2. Verifique el direccionamiento de la interfaz

    Confirme que la interfaz en la pregunta tiene un direccionamiento configurado. Si usa el [interface-name] del IP o el loopback innumerable del PPP-cliente IPX [number], asegúrese de que la interfaz de referencia está configurada con un direccionamiento.

  3. Verifique la disponibilidad de la dirección de cliente

    Si el NAS se supone para publicar una dirección IP al llamador, asegúrese de que tal direccionamiento esté disponible. La dirección IP que se distribuirá al llamador se puede obtener con uno de los métodos siguientes:

    • Configuración localmente en la interfaz. Marque la configuración de la interfaz para el comando peer default ip address a.b.c.d. en la práctica, este método debe ser utilizado solamente en las interfaces que validan las conexiones de un solo llamador, tal como encendido una interfaz del async (no un grupo async).

    • Agrupación de direcciones localmente configurada en el NAS. La interfaz debe tener el comando peer default ip address pool [pool-name]. Además, el pool se debe definir en el nivel del sistema con el comando ip local pool [pool-name] [first-address] [last-address]. El rango de direcciones definido en el pool debe ser bastante grande acomodar a tantos llamadores simultáneo-conectados pues el NAS es capaz.

    • Servidor DHCP. La interfaz NAS se debe configurar con el comando peer default ip address dhcp. Además, el NAS se debe configurar para señalar a un servidor DHCP con el DHCP-servidor del comando de configuración global ip [address].

    • AAA. Si usa el TACACS+ o el RADIUS para la autorización, el servidor de AAA puede ser configurado para dar una dirección IP específica a un llamador dado cada vez que el llamador conecte. Vea el capítulo 16 para más información.

  4. Verifique la configuración de direcciones del servidor

    Para volver a las direcciones configuradas de los servidores del Domain Name Servers o del Windows NT en respuesta a los pedidos de BOOTP, asegúrese de que el global-level commands async-bootp DNS-server [address] y el async-bootp nbns-server [address] están configurados.

    Nota: Mientras que el comando async-bootp subnet-mask [mask] puede ser configurado en el NAS, no negociarán a la máscara de subred entre el NAS y un cliente dial in PC PPP. Debido a la naturaleza de las conexiones Point-to-Point, el cliente utiliza automáticamente la dirección IP del NAS (aprendido durante la negociación IPCP) como el default gateway. No necesitan a la máscara de subred en ese entorno Point-to-Point. El PC sabe que si la dirección destino no hace juego a la dirección local, el paquete se debe remitir al default gateway (NAS) que se alcanza siempre vía el link PPP.

Antes de llamar el Equipo del TAC de Cisco Systems

Antes de llamar el Centro de Asistencia Técnica (TAC) de Cisco Systems, aseegurese le haber leído con este capítulo y haber completado las acciones sugeridas para su problema de sistema.

Además, haga lo que se describe a continuación y documente los resultados para que podamos proporcionarle una mejor asistencia:

Para todos los problemas, recoja la salida de los ejecutar-config de la demostración y muestre la versión. Asegúrese de que el comando service timestamps debug datetime msec esté en la configuración.

Por problemas de DDR, recoja el siguiente:

  • muestre el mapa de marcado

  • debug dialer

  • debug ppp negotiation

  • debug ppp authentication

Si el ISDN está implicado, recoja:

  • mostrar estado isdn

  • debug isdn q931

  • debug isdn events

Si los módems están implicados, recoja:

  • muestre las líneas

  • muestre la línea [x]

  • muestre el módem (si los módems integrados están implicados)

  • muestre el modem version (si los módems integrados están implicados)

  • haga el debug del módem

  • debug modem csm (si los módems integrados están implicados)

  • charla del debug (si un escenario DDR)

Si el T1s o los PRI está implicados, recoja:

  • muestre el T1 del regulador


Información Relacionada


Document ID: 10203