Diagrama de flujo de resolución de problemas de ISDN BRI
Contenido
Introducción
Este documento ayuda a solucionar problemas de acceso de marcado manual de la Interfaz de velocidad básica (BRI) ISDN. En el siguiente diagrama de flujo y ejemplo de resultando, configuramos una conexión ISDN BRI para otra utilizando perfiles de marcador. Sin embargo, los mismos pasos para la resolución de problemas se aplican a conexiones a otros routers (como sucursales) y cuando se usa el Legacy Dial-on-demand Routing (DDR).
Nota: También puede utilizar la Comunidad de soporte de Cisco para ayudarle a resolver su problema ISDN.
Para obtener información introductoria sobre ISDN y DDR, refiérase a la formación de audio ubicada en la Conexión de aprendizaje de Cisco.
Diagrama de flujo
Para obtener más información sobre el ítem, haga clic en uno de los links que aparecen a continuación. Utilice el botón back (atrás) de su navegador para regresar a este diagrama de flujo.
Resolución de problemas: Cómo iniciar sesión y capturar estas depuraciones
Se puede conectar al router a través del cable de consola conectado al puerto serial de la computadora o mediante el uso de Telnet.
Si necesita conectarse al router a través de la consola, remítase a la sección Configuración correcta del emulador de terminales para obtener información sobre las conexiones de la consola. Si su router ya ha sido configurado para la conectividad en la Ethernet y desea conectarse a éste con telnet, simplemente utilice un cliente telnet para conectarse a la dirección IP Ethernet del router.
En cualquier caso (consola o telnet), es mejor utilizar un cliente que le permita conservar un historial del resultado recibido durante la sesión ya que quizás necesite volver al resultado de su depuración para buscar algunos mensajes en particular.
Active milisegundos en el resultado de la depuración y los mensajes de registro. Cuando se le solicite, ingrese la contraseña configurada en su router y el modo habilitar:
router>enable Password: (enter the enable password) router# router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)#service timestamps debug datetime msec router(config)#service timestamps log datetime msec
Si está conectado con telnet, escriba terminal monitor como se muestra a continuación:
router#terminal monitor router#
A continuación, ingrese los siguientes comandos debug:
router#debug isdn q931 ISDN Q931 packets debugging is on router#debug ppp negotiation PPP protocol negotiation debugging is on router#debug dialer packet Dial on demand packets debugging is on router#debug dialer Dial on demand events debugging is on router#debug ppp authentication PPP authentication debugging is on router#
Luego inicie el ping en el router llamador. A continuación, se muestra un ejemplo de resultado de depuración de una llamada exitosa. Las distintas fases, según se identifican en el diagrama de flujo, están resaltadas.
router#ping 194.183.201.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 194.183.201.1, timeout is 2 seconds: *Mar 1 00:06:36.383: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) ! -- The ping for 194.183.201.1 is interesting traffic and uses Dialer 1(Di1) *Mar 1 00:06:36.387: BR0 DDR: rotor dialout [priority] *Mar 1 00:06:36.391: BR0 DDR: Dialing cause ip (s=10.1.0.1, d=194.183.201.1) *Mar 1 00:06:36.395: BR0 DDR: Attempting to dial 8134 ! -- Number used to dial.
! -- This is configured using the dialer string or dialer map command
! -- If you do not see this message proceed to section
! -- Symptom: The Router Does Not Attempt to Dial *Mar 1 00:06:36.411: ISDN BR0: TX -> SETUP pd = 8 callref = 0x02 *Mar 1 00:06:36.415: Bearer Capability i = 0x8890 *Mar 1 00:06:36.423: Channel ID i = 0x83 *Mar 1 00:06:36.427: Called Party Number i = 0x80, '8134', Plan:Unknown, Type:Unknown *Mar 1 00:06:36.519: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0x82 *Mar 1 00:06:36.527: Channel ID i = 0x89 *Mar 1 00:06:36.727: ISDN BR0: RX <- CONNECT pd = 8 callref = 0x82 *Mar 1 00:06:36.743: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x02 *Mar 1 00:06:36.751: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up ! -- ISDN Layer 3 CONNECT message and Link Up message ! -- If you do not see this message proceed to section ! -- Symptom: The ISDN Call Does Not Connect Successfully *Mar 1 00:06:36.767: BR0:1: interface must be fifo queue, force fifo *Mar 1 00:06:36.775: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1 *Mar 1 00:06:36.787: BR0:1 PPP: Treating connection as a callout *Mar 1 00:06:36.791: BR0:1 PPP: Phase is ESTABLISHING, Active Open ! -- LCP negotiation begins *Mar 1 00:06:36.791: BR0:1 PPP: No remote authentication for call-out *Mar 1 00:06:36.795: BR0:1 LCP: O CONFREQ [Closed] id 3 len 10 *Mar 1 00:06:36.799: BR0:1 LCP: MagicNumber 0x0012586A (0x05060012586A) *Mar 1 00:06:36.859: BR0:1 LCP: I CONFREQ [REQsent] id 59 len 15 *Mar 1 00:06:36.863: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 1 00:06:36.867: BR0:1 LCP: MagicNumber 0x10D36A4C (0x050610D36A4C) *Mar 1 00:06:36.871: BR0:1 LCP: O CONFACK [REQsent] id 59 len 15 *Mar 1 00:06:36.875: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 1 00:06:36.875: BR0:1 LCP: MagicNumber 0x10D36A4C (0x050610D36A4C) *Mar 1 00:06:36.879: BR0:1 LCP: I CONFACK [ACKsent] id 3 len 10 *Mar 1 00:06:36.883: BR0:1 LCP: MagicNumber 0x0012586A (0x05060012586A) *Mar 1 00:06:36.887: BR0:1 LCP: State is Open ! -- LCP negotiation is complete. Any LCP state other than Open indicates
! -- that LCP negotiation has failed.
! -- If you do not see this message proceed to section
! -- Symptom: PPP LCP Phase Does Not Succeed *Mar 1 00:06:36.903: BR0:1 PPP: Phase is AUTHENTICATING, by the peer *Mar 1 00:06:36.907: BR0:1 CHAP: I CHALLENGE id 38 len 24 from "ISP" ! -- Incoming CHAP challenge *Mar 1 00:06:36.915: BR0:1 CHAP: Using alternate hostname XXXXX ! -- Using alternate hostname configured with ppp chap hostname command *Mar 1 00:06:36.915: BR0:1 CHAP: Username ISP not found *Mar 1 00:06:36.919: BR0:1 CHAP: Using default password ! -- Using password configured with ppp chap password command *Mar 1 00:06:36.923: BR0:1 CHAP: O RESPONSE id 38 len 26 from "XXXXX" ! -- Sending response from "XXXXX" which is the alternate hostname for the router *Mar 1 00:06:36.939: BR0:1 CHAP: I SUCCESS id 38 len 4 ! -- NAS has succesfully authenticated the router *Mar 1 00:06:36.943: BR0:1 PPP: Phase is UP ! -- PPP Authentication is successful ! -- PPP NCP (IPCP) negotiation begins *Mar 1 00:06:36.947: BR0:1 IPCP: O CONFREQ [Not negotiated] id 3 len 10 *Mar 1 00:06:36.951: BR0:1 IPCP: Address 0.0.0.0 (0x030600000000) ! -- This router does not have an address configured, so it sends a
! -- CONFREQ with the address 0.0.0.0. This tells the other peer to assign an address
! -- which is accomplished by the sending of a CONFNAK with the proper address. *Mar 1 00:06:36.955: BR0:1 IPCP: I CONFREQ [REQsent] id 26 len 10 *Mar 1 00:06:36.963: BR0:1 IPCP: Address 194.183.201.1 (0x0306C2B7C901) ! -- Incoming CONFREQ indicating the peer's IP address *Mar 1 00:06:36.967: BR0:1 IPCP: O CONFACK [REQsent] id 26 len 10 *Mar 1 00:06:36.971: BR0:1 IPCP: Address 194.183.201.1 (0x0306C2B7C901) ! -- The router accepts the peer's IP address
! -- (since it is not trying to assign one to the peer)
! -- Once the call is connected a route to this address will be installed *Mar 1 00:06:36.975: BR0:1 IPCP: I CONFNAK [ACKsent] id 3 len 10 *Mar 1 00:06:36.979: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902) ! -- The peer CONFNAKs our initial Address request of 0.0.0.0
! -- It responds with the address that this router could use
! -- The NAS can assign this using the peer default ip address or dialer map command *Mar 1 00:06:36.983: BR0:1 IPCP: O CONFREQ [ACKsent] id 4 len 10 *Mar 1 00:06:36.987: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902) ! -- This router requests the address previously suggested by the NAS *Mar 1 00:06:37.011: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10 *Mar 1 00:06:37.015: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902) ! -- NAS accepts the address requested by the client *Mar 1 00:06:37.015: BR0:1 IPCP: State is Open ! -- PPP NCP (IPCP) negotiation is complete ! -- If you do not see this message proceed to section
! -- Symptom: PPP NCP (IPCP) negotiation does not succeed *Mar 1 00:06:37.019: Di1 IPCP: Install negotiated IP interface address 194.183.201.2 *Mar 1 00:06:37.031: BR0:1 DDR: dialer protocol up *Mar 1 00:06:37.039: Di1 IPCP: Install route to 194.183.201.1 ! -- Route to peer is installed *Mar 1 00:06:37.943: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up *Mar 1 00:06:38.383: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:06:38.427: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:06:38.471: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:06:38.515: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) router# *Mar 1 00:06:42.783: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8134 unknown router#
Regresar al diagrama de flujo de resolución de problemas
Resolución de problemas: ¿Intenta marcar el router?
Para averiguar si el router intenta realizar una llamada, verifique si tiene las siguientes líneas en la salida de depuración del router que llama:
*Mar 1 00:06:36.395: BR0 DDR: Attempting to dial 8134
En la salida de depuración, 8134 es el número de directorio ISDN que el router intenta marcar. Esta cantidad se especificó con el comando dialer string o dialer map.
Regresar al diagrama de flujo de resolución de problemas
Síntoma: El router no intenta marcar
Si el router no intenta marcar, existen varias posibilidades:
No hay salida de depuración en absoluto
Si no se produce ningún resultado de depuración, es probable que el paquete IP que está enviando ni siquiera se enrute a la interfaz del marcador. Las causas más comunes de esto son:
- Verifique que la IP esté configurada en la interfaz del marcador. Debería tener una dirección IP en la interfaz del marcador o una interfaz de IP sin numerar (donde la interfaz es una interfaz up/up tal como Ethernet x, loopback x, etc.) o una dirección IP negociada (si el cliente obtendrá una dirección IP desde el NAS). Si se usa DDR heredada, la dirección IP debe configurarse en la interfaz física (ejemplo: interfaz BRI 0).
- Verifique que se configure el comando ip routing. Cuando observa su configuración usando el comando show running-config, no verá el comando no ip routing.
- Verifique que haya una ruta estática que apunte a la interfaz del marcador o al siguiente salto (si usa mapas del marcador).
El siguiente ejemplo (para el perfil del marcador) es una ruta estática para 172.22.53.0/24 con Marcador 1 de salto siguiente:
maui-soho-01(config)#ip route 172.22.53.0 255.255.255.0 dialer 1
El siguiente ejemplo (para DDR heredada) es una ruta estática para 172.22.53.0/24 con salto siguiente 172.16.1.1. La siguiente dirección hop debe coincidir con la dirección de IP en el mapa de sentencias de correspondencia de marcador que se utiliza para marcar:
maui-soho-01(config)#ip route 172.22.53.0 255.255.255.0 172.16.1.1
- Verifique que el marcador o la interfaz física no esté en estado inactivo o inactivo administrativamente. Use el comando show interface dialer X o show interface bri X para asegurarse de que la interfaz esté en el estado up/up (simulación).
Si la interfaz se encuentra administrativamente inactiva, utilice el comando no shutdown en el modo de configuración de la interfaz.
Si la interfaz se encuentra en estado de reserva, entonces el la interfaz del marcador o la interfaz BRI es un respaldo para una conexión que está en funcionamiento. Puede eliminar el comando de interfaz de soporte de la interfaz primaria o desconectar el cable de interfaz primaria.
Hay un Resultado de la depuración pero no hay un mensaje "Attempting to Dial" (Intentado marcar)
En este caso, es probable que haya un paquete de IP enrutado a la interfaz, pero el router lo rechaza y por algún motivo no inicia la llamada . Observe la salida de depuración a fin de determinar por qué no se realiza el intento de llamada. A continuación se muestran algunos ejemplos de resultados de depuración y sus posibles razones:
Ejemplo 1
*Mar 13 10:43:50.253: Di1 DDR: ip (s=10.1.1.1, d=172.22.53.1), 100 bytes, outgoing uninteresting (list 101).
El tráfico generado no coincide con la definición de tráfico interesante. Para este ejemplo modifique lista de acceso 101.
Una definición de tráfico interesante simple sería permitir todo el tráfico IP como en:
maui-soho-01(config)#dialer-list 1 protocol ip permit
Advertencia: Marcar todo el tráfico IP como interesante puede hacer que el link ISDN permanezca activo indefinidamente, especialmente si tiene un protocolo de ruteo u otro tráfico periódico. Ajuste la definición de tráfico interesante para adaptarla a sus necesidades.
Para obtener más información sobre el tráfico interesante, consulte el documento Tecnología de marcado: Descripciones y explicaciones.
Ejemplo 2
*Mar 1 00:07:22.255: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing uninteresting (no dialer-group defined).
No hay un grupo de marcadores configurado en la interfaz del marcador. Agregar un grupo de marcadores como en el siguiente ejemplo:
interface Dialer1 dialer-group X
Nota: El valor para X debe ser igual al utilizado con el comando dialer-list.
Ejemplo 3
*Mar 1 00:08:24.919: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing uninteresting (dialer-list 1 not defined).
Existe un enunciado de grupo de marcador en la interfaz de marcador, pero la lista de marcador a la que se refiere no existe. Configurar la lista de marcadores como en el siguiente ejemplo:
dialer-list X protocol ip permit
Nota: El valor para X debe ser el mismo utilizado con el comando dialer-group en la interfaz del marcador.
Ejemplo 4
*Mar 1 00:25:32.551: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:25:32.555: Di1 DDR: No free dialer - starting fast idle timer.
En este caso, el paquete de salientes se considerará lo suficientemente interesante para incrementar el link. No obstante, no existe una interfaz física disponible para tomar la llamada. Asegúrese de que dialer pool-member X esté configurado en la interfaz física y dialer pool X esté configurado en la interfaz del marcador. Ejemplo:
interface BRI0 dialer pool-member 1 ! interface Dialer1 dialer pool 1
Además, verifique que la interfaz BRI no esté en estado apagado.
Ejemplo 5
*Mar 1 00:37:24.235: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:37:24.239: Di1 DDR: Cannot place call, no dialer string set.
En este caso, no se configuró ninguna cadena de marcador en la interfaz de marcador. El router desea realizar una llamada pero no conoce el número de directorio ISDN al que llamar. Defina una cadena de marcador:
interface Dialer1 dialer string 8134
Para obtener más información sobre la resolución de problemas, consulte la sección "El router que llama no envía un mensaje SETUP" en el documento Solución de problemas de la Capa 3 ISDN BRI con el comando debug isdn q931.
Regresar al diagrama de flujo de resolución de problemas
Resolución de problemas: ¿Se conectó satisfactoriamente la llamada ISDN?
Para identificar si la llamada ISDN se conecta, busque el mensaje CONNECT_ACK y %LINK-3-UPDOWN en las depuraciones:
*Mar 1 00:06:36.743: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x02 *Mar 1 00:06:36.751: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
Si puede ver este mensaje, es porque su llamada ISDN se conectó satisfactoriamente y usted podrá proceder con el paso siguiente. Si no puede ver un mensaje como éste, lea acerca de las posibles causas más abajo.
Regresar al diagrama de flujo de resolución de problemas
Síntoma: La llamada ISDN no se conecta exitosamente.
- Si observa un resultado similar al siguiente, verifique que el cable ISDN esté enchufado correctamente en el router y en el conector de la compañía telefónica.
*Mar 1 21:31:18.190: Di1 DDR: ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 21:31:18.190: BR0 DDR: rotor dialout [priority] *Mar 1 21:31:18.198: BR0 DDR: Dialing cause ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4) *Mar 1 21:31:18.198: BR0 DDR: Attempting to dial 8134. *Mar 1 21:31:20.186: Di1 DDR: ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4), 100 bytes, outgoing interesting (ip PERMIT). *Mar 1 21:31:26.226: ISDN BR0: Could not bring up interface *Mar 1 21:31:26.226: BRI0: wait for isdn carrier timeout, call id=0x849E *Mar 1 21:31:26.246: ISDN BR0: Could not bring up interface. Success rate is 0 percent (0/5)
- Verifique que el circuito ISDN esté funcionando correctamente. Use el comando show isdn status para verificar que la Capa 1 esté en el estado ACTIVE, que la Capa 2 se encuentre en el estado MULTIPLE_FRAME_ESTABLISHED y que los SPID (si son necesarios) sean válidos. Para obtener más información, consulte el documento Uso del comando show isdn status para la resolución de problemas de BRI.
Si tiene el resultado de un comando show isdn status de su dispositivo Cisco, puede utilizar Cisco CLI Analyzer para mostrar posibles problemas y soluciones. Para utilizar Cisco CLI Analyzer, debe ser un usuario registrado, iniciar sesión y tener JavaScript habilitado. - Verifique que la cadena del marcador ISDN configurada sea la correcta. Recuerde que posiblemente tenga que agregar un cero, un nueve u otros dígitos adelante para obtener una línea externa cuando está conectado a través de un PBX.
- Si la conexión usa un contacto portador de larga distancia, su compañía telefónica local y proveedor de larga distancia para verificar que el servicio está activado. Frecuentemente, la compañía telefónica local tiene el circuito ISDN mal configurado de manera tal que las llamadas de larga distancia ISDN salientes no se transfieren a la red correcta del proveedor de larga distancia. También debe verificar que la red del proveedor de larga distancia esté funcionando.
En EE.UU. y en situaciones en las que la compañía telefónica o el proveedor de larga distancia no es capaz de solucionar el problema, podrá utilizar una Portadora entre centrales de suscripción previa (PIC). Los códigos PIC son prefijos de siete dígitos que identifican a las compañías telefónicas estadounidenses de larga distancia con las Compañías telefónicas locales (LEC). Esto permite que los clientes puedan utilizar diferentes portadoras de larga distancia para llamadas individuales. El código PIC está configurado como un prefijo al número marcado. La mayoría de las PIC tienen el formato 1010xxx.
No utilice ninguna cadena xxxxx del marcador ni ningún mapa del marcador para eliminar el número existente y luego configurar el nuevo número.
Por ejemplo, la cadena del marcador 10103215125551111.
- Busque un mensaje de desconexión ISDN.
El software del IOS® de Cisco decodifica el código de causa en este mensaje de desconexión y le proporciona un mensaje de texto claro que generalmente contiene información útil que conduce a la causa del problema. Las identificaciones posibles que puede encontrar aquí incluyen:
- Número sin asignar o no asignado
- Destino incompatible (ambos indican que el número marcado podría ser incorrecto)
- Número ocupado (lo que indica que el lado al que se llama está ocupado)
- Falla temporaria (que indica un corte de luz temporario en la red Telco).
Para encontrar el posible motivo para una causa de desconexión específica, consulte Introducción de los códigos de desconexión del comando debug isdn q931.
Por ejemplo, se puede indicar una desconexión debido a un número ISDN incorrecto con:
*Mar 3 00:10:38.756: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0xEB *Mar 3 00:10:38.764: Cause i = 0x84D8 - Incompatible destination
Refiriéndonos al documento Códigos de Causa de Desconexión referenciado anteriormente, podemos determinar que el código de desconexión fue causado por un intento de conexión a un equipo no ISDN (por ejemplo, una línea analógica).
Una desconexión a causa de un número con formato incorrecto puede ser indicada por medio de:
Aug 13 18:23:14.734: ISDN BR0: RX <- RELEASE_COMP pd = 8 callref = 0x86
Aug 13 18:23:14.742: Cause i = 0x829C - Invalid number format (incomplete number)Refiriéndonos al documento Comprensión de los Códigos de Causa de Desconexión debug isdn q931 podemos determinar que el código de desconexión fue causado por un formato no válido para el número ISDN remoto. La conexión falla debido a que la dirección de destino se presenta (hacia el switch) en un formato irreconocible o la dirección de destino está incompleta.
El siguiente ejemplo muestra una llamada rechazada debido a un número ISDN incorrecto:
*Mar 13 11:29:04.758: ISDN BR0: RX <- RELEASE_COMP pd = 8 callref = 0x83 *Mar 13 11:29:04.769: Cause i = 0x8295 - Call rejected
- Si su Telco le proporcionó Identificadores de perfil del servicio (SPID), asegúrese de que estén configurados en la interfaz BRI. Los SPID se utilizan comúnmente sólo en Estados Unidos con los tipos de switch NI y DMS (los switches de tipo 5ess no necesitan SPID).
interface BRI0 isdn spid1 51255511110101 5551111 isdn spid2 51255511120101 5551112
Puede utilizar el comando show isdn status para verificar si los SPID son correctos.
Para obtener más información, consulte el documento Solución de problemas de SPID BRI ISDN.
Si tiene el resultado de un comando show isdn status de su dispositivo Cisco, puede utilizar Cisco CLI Analyzer para mostrar posibles problemas y soluciones. Para utilizar Cisco CLI Analyzer, debe ser un usuario registrado, iniciar sesión y tener JavaScript habilitado. - Si el procedimiento antes descrito no resuelve el problema, utilice el documento Resolución de problemas relativos a ISDN BRI Capa 3 por medio de el comando debug isdn q931.
Regresar al diagrama de flujo de resolución de problemas
Resolución de problemas: ¿Tiene éxito la fase PPP LCP?
En el resultado de la depuración, debe ver la línea de mensaje siguiente:
*Mar 1 00:06:36.887: BR0:1 LCP: State is Open
Si puede ver esta línea, esto indica que se negoció exitosamente el protocolo de control de link (LCP). Cualquier estado que no sea abierto indica que LCP falló.
Regresar al diagrama de flujo de resolución de problemas
Síntoma: La fase PPP LCP no tiene éxito
Posible causa: PPP no está configurado
Si tiene un resultado de depuración similar a las siguientes líneas, esto indica que PPP no se inició.
*Mar 2 19:34:21.761: Di1 DDR: dialer protocol up. *Mar 2 19:34:23.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT). *Mar 2 19:34:25.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT). *Mar 2 19:34:27.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT) *Mar 2 19:34:27.753: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8101.
! -- Call connects but the router does not send any PPP CONFREQ packets *Mar 2 19:34:29.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT). Success rate is 0 percent (0/5)
Tenga en cuenta que en la salida de depuración el router no envía mensajes PPP CONFREQ. Esto se debe, probablemente, a que la interfaz no ha sido configurada para la encapsulación PPP.
En este caso, verifique que haya configurado el comando encapsulation ppp bajo la interfaz del marcador y la interfaz física. A continuación se presentan ejemplos:
interface Dialer1 encapsulation ppp or
interface BRI 0
encapsulation ppp
Posible causa: Discrepancia de velocidad de ISDN
A veces, es posible que vea sólo mensajes LCP CONFREQ salientes, pero no mensajes LCP entrantes. Se presenta un ejemplo a continuación:
*Mar 14 01:49:10.160: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up ! -- Call is connected. PPP negotiation will begin
*Mar 14 01:49:10.168: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1.
*Mar 14 01:49:10.188: BR0:1 PPP: Treating connection as a callout
*Mar 14 01:49:10.188: BR0:1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load] ! -- PPP negotiation begins
*Mar 14 01:49:10.196: BR0:1 LCP: O CONFREQ [Closed] id 24 len 15
*Mar 14 01:49:10.200: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:10.204: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A). ! -- Outgoing Configure-Request (CONFREQ)
*Mar 14 01:49:12.176: BR0:1 LCP: TIMEout: State REQsent ! -- Router has not received a CONFREQ from the peer, hence the timeout
*Mar 14 01:49:12.180: BR0:1 LCP: O CONFREQ [REQsent] id 25 len 15
*Mar 14 01:49:12.184: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:12.188: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A).
*Mar 14 01:49:14.160: BR0:1 LCP: TIMEout: State REQsent
*Mar 14 01:49:14.164: BR0:1 LCP: O CONFREQ [REQsent] id 26 len 15
*Mar 14 01:49:14.168: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:14.172: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A)
Este problema podría deberse a:
- El extremo remoto sin configuración para PPP. Configure el comando encapsulation ppp en el extremo remoto
- Los paquetes no están pasando por el medio de transmisión. La causa más común de este problema es una discordancia de velocidad ISDN.
La naturaleza del problema, desde el aspecto del ISDN, es que una de las partes probablemente se esté conectando a 56k mientras que la otra lo esté haciendo a 64k. Es posible que el circuito local o remoto no soporte las conexiones de 64K predeterminadas. Intente configurar ambos extremos para que se ejecuten a 56k.
Para perfiles de marcadores:
maui-soho-01(config)#interface Dialer1 maui-soho-01(config-if)#dialer string 81560 class 56k
! -- Dial 81560 and use the map-class named "56k" (defined below) maui-soho-01(config-if)#exit maui-soho-01(config)#map-class dialer 56k
! -- map-class named "56k" that was used with the dialer string
! -- in int Dialer1
maui-soho-01(config-map-clas)#dialer isdn speed 56
! -- Set the speed of the call to be 56k (default is 64k)
Para DDR heredado (mapas de marcado):
maui-soho-01(config)#interface bri 0 maui-soho-01(config-if)#dialer map ip 10.1.1.1 name maui-nas-08 speed 56 81560
!-- The keyword speed 56 sets the outgoing call rate at 56k
Posible causa: Los dos routers no coinciden en el protocolo de autentificación (CHAP o PAP) a utilizar
Si tiene un resultado de depuración similar al de las líneas a continuación, significa que su router y el lado remoto no han acordado qué protocolo de autenticación utilizar.
*Mar 1 00:07:24.051: BR0:1 LCP: I CONFREQ [ACKrcvd] id 136 len 14 *Mar 1 00:07:24.055: BR0:1 LCP: AuthProto PAP (0x0304C023) *Mar 1 00:07:24.059: BR0:1 LCP: MagicNumber 0x1110C3C5 (0x05061110C3C5) ! -- An incoming CONFREQ (Config-Request) indicating the peer is
! -- willing to do PAP *Mar 1 00:07:24.063: BR0:1 LCP: O CONFNAK [ACKrcvd] id 136 len 9 *Mar 1 00:07:24.063: BR0:1 LCP: AuthProto CHAP (0x0305C22305) ! -- The router send a Configure-Negative-Acknowledge (CONFNAK) rejecting PAP
! -- The router suggests CHAP instead *Mar 1 00:07:24.087: BR0:1 LCP: I CONFREQ [ACKrcvd] id 137 len 14 *Mar 1 00:07:24.091: BR0:1 LCP: AuthProto PAP (0x0304C023) *Mar 1 00:07:24.091: BR0:1 LCP: MagicNumber 0x1110C3C5 (0x05061110C3C5) ! -- The peer once again requests PAP
! -- This is probably because PAP is the only protocol configured on the peer
! -- The router will once again CONFNAK PAP and suggest CHAP *Mar 1 00:07:24.095: BR0:1 LCP: O CONFNAK [ACKrcvd] id 137 len 9 *Mar 1 00:07:24.099: BR0:1 LCP: AuthProto CHAP (0x0305C22305) ! -- The router NAKs PAP and suggests CHAP for the 2nd time *Mar 1 00:07:24.119: BR0:1 LCP: I TERMREQ [ACKrcvd] id 138 len 4 *Mar 1 00:07:24.123: BR0:1 LCP: O TERMACK [ACKrcvd] id 138 len 4 ! -- The two routers cannot agree on LCP parameters so the call is disconnected
En este caso, verifique que haya configurado lo siguiente:
interface Dialer1 encapsulation ppp ppp authentication chap pap callin ! -- This permits both CHAP and PAP and one-way authentication
Para más información sobre el Protocolo de autenticación por desafío mutuo (CHAP) o el Protocolo de autentificación por contraseña (PAP), consulte los siguientes documentos:
- Cómo funciona y se configura la autenticación PPP CHAP
- Autenticación de PPP utilizando los comandos ppp chap hostname y ppp authentication chap callin
- Configuración y resolución de problemas del Protocolo de autenticación de contraseñas (PAP, por sus siglas en inglés) de PPP
También puede utilizar la Comunidad de soporte de Cisco para más troubleshooting PPP.
Regresar al diagrama de flujo de resolución de problemas
Resolución de problemas: ¿La autenticación PPP se realiza correctamente?
Verifique el resultado de la depuración para obtener una línea similar a ésta.
*Mar 1 00:06:36.943: BR0:1 PPP: Phase is UP
Regresar al diagrama de flujo de resolución de problemas
Síntoma: La autentificación PPP no es exitosa
Asegúrese de haber configurado las siguientes líneas:
interface Dialer1 ppp chap hostname XXXXX ppp chap password YYYYY ppp pap sent-username XXXXX password YYYYY
En el ejemplo, XXXXX es su nombre de usuario y AAAA es su contraseña.
Nota: Configure solamente el nombre de usuario y la contraseña para el método de autenticación que usted y su empleado de par emplean. Por ejemplo, si ninguno usará PAP, no necesita el comando ppp pap sent-username. Sin embargo, si no está seguro si el par admite PAP o CHAP, entonces configure ambos.
Dependiendo de la versión y configuración del software Cisco IOS, la contraseña puede aparecer cifrada en su configuración. Si éste es el caso, cuando ejecuta un comando show running-configuration, puede ver la palabra “contraseña” seguida del dígito 7 y luego una secuencia de números como en el siguiente ejemplo:
interface Dialer1 ppp chap password 7 140005
En este caso, no puede verificar si la contraseña configurada es o no correcta observando la configuración. Para asegurarse de que la contraseña es correcta, simplemente ingrese al modo configuración y elimine y configure la contraseña una vez más. Para identificar una falla de contraseña en la depuración, compare su salida de depuración con la siguiente salida de muestra.
Si este router es el que autenticará el par, entonces asegúrese de configurar el comando username username password password, en el cual el nombre de usuario es el nombre suministrado por el router par para autenticación.
Ejemplo 1
Un mensaje como el de abajo significa que la contraseña CHAP no es válida.
*Mar 1 00:16:54.403: BR0:1 CHAP: I CHALLENGE id 94 len 24 from "ISP" ! -- Incoming CHAP challenge *Mar 1 00:16:54.407: BR0:1 CHAP: Using alternate hostname XXXXX ! -- Using alternate hostname configured with ppp chap hostname command *Mar 1 00:16:54.411: BR0:1 CHAP: Username ISP not found *Mar 1 00:16:54.415: BR0:1 CHAP: Using default password ! -- Using password configured with ppp chap password command *Mar 1 00:16:54.415: BR0:1 CHAP: O RESPONSE id 94 len 26 from "XXXXX" ! -- Sending response from "XXXXX" which is the alternate hostname for the router *Mar 1 00:16:54.439: BR0:1 CHAP: I FAILURE id 94 len 25 msg is "MD/DES compare failed" ! -- Incoming CHAP failure. The remote router failed to authenticate this router. ! -- Check the username and password configured on both routers *Mar 1 00:16:54.447: BR0:1 LCP: I TERMREQ [Open] id 165 len 4 *Mar 1 00:16:54.451: BR0:1 LCP: O TERMACK [Open] id 165 len 4
Consejo: Una falla CHAP entrante (indicada por CHAP: I FALLA) significa que el par no pudo autenticar el router. Utilice debug ppp negotiation en el router de par para determinar la causa exacta de la falla.
Para obtener más información, refiérase al documento Autenticación PPP usando los Comandos ppp chap hostname y ppp authentication chap callin.
Ejemplo 2
Un mensaje como el que se incluye a continuación podría significar que el nombre de usuario CHAP no es válido:
*Mar 1 00:18:34.831: BR0:1 CHAP: I CHALLENGE id 97 len 24 from "ISP" ! -- Incoming CHAP challenge *Mar 1 00:18:34.835: BR0:1 CHAP: Using alternate hostname Xdwqdqw ! -- Using alternate hostname configured with ppp chap hostname command *Mar 1 00:18:34.839: BR0:1 CHAP: Username ISP not found *Mar 1 00:18:34.839: BR0:1 CHAP: Using default password ! -- Using password configured with ppp chap password command *Mar 1 00:18:34.843: BR0:1 CHAP: O RESPONSE id 97 len 28 from "Xdwqdqw" ! -- Sending response from "Xdwqdqw" which is the alternate hostname
! -- for the router *Mar 1 00:18:34.867: BR0:1 CHAP: I FAILURE id 97 len 26 msg is "Authentication failure" ! -- Incoming CHAP failure. The remote router failed to authenticate
! -- this router. Check the username and password configured on both routers *Mar 1 00:18:34.875: BR0:1 LCP: I TERMREQ [Open] id 171 len 4 *Mar 1 00:18:34.879: BR0:1 LCP: O TERMACK [Open] id 171 len 4
Consejo: Una falla CHAP entrante (indicada por CHAP: I FALLA) significa que el par no pudo autenticar el router. Utilice debug ppp negotiation en el router de par para determinar la causa exacta de la falla.
Para obtener más información, refiérase al documento Autenticación PPP usando los Comandos ppp chap hostname y ppp authentication chap callin.
Ejemplo 3
Un mensaje como el siguiente significa que la contraseña PAP no es válida:
*Mar 1 00:21:33.927: BR0:1 PAP: O AUTH-REQ id 3 len 18 from "XXXXX" ! -- Outgoing PAP Authentication Request from XXXXX
! -- XXXXX is the username configured in
! -- ppp pap sent-username XXXXX password YYYYY *Mar 1 00:21:33.947: BR0:1 PAP: I AUTH-NAK id 3 len 27 msg is "Authentication failure" ! -- An incoming PAP failure. The peer could not authenticate this router
! -- Verify that the username and password configured on both routers
! -- are identical *Mar 1 00:21:33.955: BR0:1 LCP: I TERMREQ [Open] id 182 len 4 *Mar 1 00:21:33.955: BR0:1 LCP: O TERMACK [Open] id 182 len 4 *Mar 1 00:21:33.959: BR0:1 PPP: Phase is TERMINATING
Para obtener más información, vea el documento Configuración y solución de problemas del protocolo de autenticación de contraseña (PAP) de PPP.
Ejemplo 4
Un mensaje como el siguiente significa que el nombre de usuario PAP no es válido:
*Mar 1 00:20:41.023: BR0:1 PPP: Phase is AUTHENTICATING, by the peer *Mar 1 00:20:41.031: BR0:1 PAP: O AUTH-REQ id 1 len 17 from "ewddew" ! -- Outgoing PAP Authentication Request from ewddew
! -- ewddew is the username configured in
! -- ppp pap sent-username ewddew password YYYYY *Mar 1 00:20:41.047: BR0:1 PAP: I AUTH-NAK id 1 len 27 msg is "Authentication failure" ! -- An incoming PAP failure. The remote router could not authenticate
! -- this router. Check the username and password configured on both routers
! -- Note the PAP authentication failure in example 3 and 4 are identical.
! -- Hence the only way to determine if the username, password or both are
! -- wrong is to run debug ppp negotiation on the authenticating router *Mar 1 00:20:41.055: BR0:1 LCP: I TERMREQ [Open] id 178 len 4 *Mar 1 00:20:41.059: BR0:1 LCP: O TERMACK [Open] id 178 len 4 *Mar 1 00:20:41.063: BR0:1 PPP: Phase is TERMINATING
Para obtener más información, vea el documento Configuración y solución de problemas del protocolo de autenticación de contraseña (PAP) de PPP.
También puede utilizar la Comunidad de soporte de Cisco para más resolución de problemas PPP.
Regresar al diagrama de flujo de resolución de problemas
Resolución de problemas: ¿Se completa la fase PPP NCP (IPCP)?
El elemento clave negociado en IPCP es la dirección de cada entidad par. Antes de la negociación IPCP, cada peer está en uno de los dos estados posibles; Tiene una dirección IP o no tiene dirección IP. Si el par ya tiene una dirección, envía esa dirección en una CONFREQ al otro par. Si la dirección es aceptable para los otros pares, aparece un CONFACK. Si la dirección no es aceptable, la respuesta es un CONFNAK que contiene una dirección para que la utilice el par.
Esta es la única fase que no se puede identificar adecuadamente al observar sólo una línea. Para asegurarse de que el protocolo de control de IP (IPCP) se activa correctamente, debe verificar que las direcciones IP se han negociado en ambas direcciones. Busque las siguientes líneas en su depuración:
*Mar 1 00:06:36.967: BR0:1 IPCP: O CONFACK [REQsent] id 26 len 10 *Mar 1 00:06:36.971: BR0:1 IPCP: Address 194.183.201.1(0x0306C2B7C901)
y
*Mar 1 00:06:37.011: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10 *Mar 1 00:06:37.015: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902)
y
*Mar 1 00:06:37.015: BR0:1 IPCP: State is Open
Estos tres conjuntos de líneas no seguirán inmediatamente uno al otro. Es importante que verifique si existe un Configure Acknowledge de salida (O CONFACK, Configurar acuse de recibo de salida) que tiene, entre otras opciones, una dirección debajo.
También debe existir un Configure Acknowledge entrante (I CONFACK) con otra dirección IP por debajo.
Por último, debe haber una línea indicando que IPCP se encuentra en estado abierto. Después de esto, debería poder hacer ping exitoso a ambas direcciones IP directamente desde el router.
Regresar al diagrama de flujo de resolución de problemas
Síntoma: La negociación PPP NCP (IPCP) no tiene éxito
Problema: Falla en la negociación de la dirección IP
Una de las razones por las que IPCP podría fallar se debe a una falla de negociación de dirección IP. Por ejemplo, el NAS puede estar tratando de asignar una dirección al cliente mientras el router del cliente tiene una dirección IP diferente configurada u otro problema común es cuando el cliente solicita una dirección y el NAS no tiene ninguna dirección disponible para el cliente.
En el router de llamada:
Si el router llamado le asigna una dirección IP dinámicamente al router que realiza la llamada, verifique que disponga del comando ip address negotiated en la interfaz del marcador.
Si el proveedor NAS/ISP le ha dado una dirección IP estática, verifique que esta dirección IP (y la máscara de subred) estén configuradas en la interfaz del marcador con el comando ip address address subnet_mask.
En el router llamado:
Asegúrese de que la interfaz que controla la conexión (por ejemplo, la interfaz del marcador x) tenga una dirección IP y le esté asignando una dirección al par mediante la dirección del comando default ip address.
Nota: Si el router cliente tiene una dirección IP configurada, no es necesario asignar una dirección a través del comando peer default ip address
Para obtener más información, consulte el documento Tecnología de marcado: Técnicas de resolución de problemas.
Problema: El router llamado no puede establecer la Vinculación del perfil del marcador
Si el nombre de usuario autenticado no coincide con el nombre de dialer remote-name configurado en la interfaz del marcador, la llamada será desconectada por el router llamado. El siguiente es un ejemplo de resultado de marcador de depuración para este tipo de error.
En el router de llamada:
La siguiente depuración muestra una desconexión causada por una vinculación de perfil del marcador erróneo en el router llamado.
*Mar 15 03:19:13.050: BR0:1 CHAP: O CHALLENGE id 32 len 33 from "maui-soho-03"
*Mar 15 03:19:13.094: BR0:1 CHAP: I CHALLENGE id 32 len 33 from "maui-soho-01"
*Mar 15 03:19:13.094: BR0:1 CHAP: O RESPONSE id 32 len 33 from "maui-soho-03"
*Mar 15 03:19:13.134: BR0:1 CHAP: I SUCCESS id 32 len 4 ! -- CHAP authentication is successful
*Mar 15 03:19:13.222: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0xA0
*Mar 15 03:19:13.226: Cause i = 0x8090 - Normal call clearing ! -- We have received (RX) a DISCONNECT from the peer
! -- We have to move troubleshooting to the called router
*Mar 15 03:19:13.238: ISDN BR0: TX -> RELEASE pd = 8 callref = 0x20
*Mar 15 03:19:13.242: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 15 03:19:13.250: BR0 DDR: has total 2 call(s), dial_out 0, dial_in 0
*Mar 15 03:19:13.254: BR0:1 PPP: Phase is TERMINATING
*Mar 15 03:19:13.254: BR0:1 LCP: State is Closed
*Mar 15 03:19:13.254: BR0:1 PPP: Phase is DOWN
*Mar 15 03:19:13.254: BRI0:1 DDR: disconnecting call
Nota: Las depuraciones del lado llamado no ayudan a solucionar este problema, excepto para indicar que el par desconectó la llamada. Mueva la resolución de problemas al router llamado.
En el router llamado:
La siguiente depuración muestra una llamada que falla debido a problemas de vinculación del perfil del marcador.
*Mar 15 03:54:09.804: BR0:1 CHAP: O SUCCESS id 33 len 4
*Mar 15 03:54:09.808: BR0:1 CHAP: Processing saved Challenge, id 33
*Mar 15 03:54:09.812: BR0:1 DDR: Authenticated host maui-soho-03 with no matching dialer profile ! -- a binding failure because the dialer remote-name
! -- does not match the authenticated username
*Mar 15 03:54:09.816: BR0:1 DDR: disconnecting call
*Mar 15 03:54:10.086: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 15 03:54:10.093: BR0:1 PPP: Phase is TERMINATING [0 sess, 0 load]
Solución:
Configure el comando dialer pool number en la interfaz del marcador. El número de agrupamiento debe coincidir con el número de agrupamiento configurado en la interfaz física.
Configure el comando dialer remote-name en la interfaz del marcador. El nombre especificado debe coincidir exactamente con el nombre de usuario proporcionado por el router remoto para autenticación. En este ejemplo, el nombre de usuario autenticado es maui-soho-03.
Para obtener más información sobre la resolución de problemas de enlace, consulte el documento Configuración y resolución de problemas de perfiles de marcador.
También puede utilizar la Comunidad de soporte de Cisco para más troubleshooting PPP.
Regresar al diagrama de flujo de resolución de problemas
Problemas posteriores a la conexión
Síntoma: La llamada se desconecta antes de tiempo o la llamada no se desconecta en absoluto
Si la llamada se desconecta inesperadamente o la llamada nunca se desconecta, verifique el tiempo de espera inactivo del marcador y la definición de tráfico interesante. Puede usar el comando debug dialer packet para verificar si un paquete en particular es o no interesante. Por ejemplo:
Apr 26 01:57:24.483: Di1 DDR: ip (s=192.168.1.1, d=224.0.0.5), 64 bytes, outgoing uninteresting (list 101) Apr 26 01:57:26.225: Di1 DDR: ip (s=192.168.1.1, d=10.1.1.1), 100 bytes, outgoing interesting (list 101)
En el ejemplo anterior, los hellos OSPF no son interesantes por access-list 101, mientras que el segundo paquete es interesante por access-list 101.
- Modifique el descanso ocioso del marcador en la configuración de la interfaz del marcador. El valor predeterminado es 120 segundos, pero es posible que desee incrementar o disminuir este valor según sus necesidades.
- Cambie la definición de tráfico interesante (que se configura con el comando dialer-list). Si la llamada se desconecta prematuramente, puede definir el tráfico interesante de manera más amplia. Si la llamada nunca se desconecta cambie su definición de tráfico interesante por una más restrictiva. Por ejemplo, puede definir el tráfico del protocolo de ruteo como poco interesante. El siguiente es un ejemplo de una definición de tráfico interesante:
access-list 101 remark Interesting traffic for dialer-list 1 access-list 101 deny ospf any any
!--- mark OSPF as uninteresting
!--- This will prevent OSPF hellos from keeping the link up.
access-list 101 deny udp any any eq ntp ! -- Define ntp traffic as NOT interesting.
! -- This will prevent periodic ntp traffic from keeping
! -- the link up indefinitely.
access-list 101 permit ip any any
! -- All other IP traffic is interesting.
! -- Change this depending on your traffic needs.
dialer-list 1 protocol ip list 101 ! -- this interesting traffic is applied to the dialer
! -- interface using dialer-group 1Para obtener más información, consulte el documento Tecnología de marcado: Descripciones y explicaciones.
Síntoma: El router marca la conexión de manera periódica
En ciertas situaciones, puede observar que el router marca periódicamente la conexión, aunque no haya tráfico de usuario aparente que requiera que el link esté activo. Esto puede resultar en cargos altos por larga distancia, en donde el servicio ISDN se computa por minuto.
La causa más común es que un proceso que genera tráfico periódico (tal como un protocolo de ruteo, ntp, snmp etc) puede estar designado como interesante. La resolución de este problema involucra dos pasos:
- Identifique el tráfico que hace marcar al link.
- Designe a ese tráfico como no interesante.
Identifique el tráfico que hace marcar al link.
Para identificar el tráfico que ocasiona que el link marque, deberá activar debug dialer packet. Controle el router mientras el link ISDN está inactivo y observe algún tráfico periódico interesante que intente activar el link.
Consejo: A menos que sea específicamente necesario, designe todos los protocolos de ruteo configurados en el router como no interesantes.
El siguiente ejemplo muestra mensajes de saludo OSPF periódicas que se marcan como interesantes:
*Mar 15 00:25:58.865: Di1 DDR: ip (s=172.22.25.1, d=224.0.0.5), 64 bytes, outgoing interesting (ip PERMIT)
La única manera de identificar que el paquete anterior es un saludo OSPF es desde la dirección de destino (d=224.0.0.5) que se define para OSPF. La siguiente tabla enumera las direcciones que se usan para algunos protocolos de ruteo comunes.
|
Protocolo de ruteo
|
Dirección de Destino para Periódicos Actualizaciones o señales de mantenimiento |
|
RIPv1
|
255.255.255.255
|
|
RIPv2
|
224.0.0.9
|
|
EIGRP
|
224.0.0.10
|
|
OSPF
|
224.0.0.5
|
El tráfico que hace que el router marque (protocolo de ruteo u otro tráfico periódico) debe marcarse como poco interesante.
Designar el tráfico periódico como no interesante
Cambie la definición de tráfico interesante (que se configura con el comando dialer-list). En este ejemplo, se define el tráfico OSPF y NTP como no interesante. El siguiente es un ejemplo de una definición de tráfico interesante:
access-list 101 remark Interesting traffic for dialer-list 1 access-list 101 deny ospf any any
!--- mark OSPF as uninteresting
!--- This will prevent OSPF hellos from keeping the link up.
access-list 101 deny udp any any eq ntp ! -- Define ntp traffic as NOT interesting.
! -- This will prevent periodic ntp traffic from keeping
! -- the link up indefinitely.
access-list 101 permit ip any any
! -- All other IP traffic is interesting.
! -- Change this depending on your traffic needs.
dialer-list 1 protocol ip list 101 ! -- this interesting traffic is applied to the dialer interface
! -- using dialer-group 1
Para obtener más información, consulte el documento Tecnología de marcado: Descripciones y explicaciones.
Nota: OSPF tiene una característica llamada circuito de demanda que también se puede usar aquí. Consulte el documento Por qué el circuito de demanda OSPF continúa activando el link para obtener más información
Síntoma: El segundo canal B no se conecta
En muchas instancias, el router quizás se conecte sólo en un canal B mientras que el otro canal B permanece inactivo. Para obtener más información sobre la resolución de este problema, consulte el documento Resolución de problemas de fallas de llamada de segundo canal B en links ISDN BRI.
Problemas de conectividad IP
Si el link ISDN aparece pero no puede pasar tráfico a través del link, entonces el problema probablemente sea un problema relacionado con el ruteo o la NAT. Refiérase a la Comunidad de Soporte de Cisco para obtener más información de troubleshooting.
Si utiliza el link ISDN como respaldo a una conexión WAN, consulte el documento Configuración y Troubleshooting de Respaldo DDR.
Información Relacionada
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)