Realización de llamadas de bucle invertido para probar circuitos BRI

Introducción

Este documento proporciona instrucciones sobre cómo realizar loopbacks para probar circuitos de Basic Rate Interface (BRI).

Prerequisites

Requirements

Quienes lean este documento deben tener conocimiento de los siguientes temas:

• El resultado de los comandos debug isdn q931 y debug ppp negotiation.

• Conceptos generales de configuración del perfil del marcador DDR. Para obtener más información sobre los perfiles de marcador, vea Configuración y resolución de problemas de perfiles de marcador.

Antes de intentar este procedimiento, obtenga la siguiente información de la compañía telefónica:

• Tipo de switch que se va a configurar.

• Identificadores de perfil de servicio (SPID) y número de directorio local (LDN). La SPID y la LDN son necesarias en los Estados Unidos de América.

• Si ambos canales B están en un grupo de búsqueda. Si se encuentran en un grupo de búsqueda, sólo necesitamos marcar un número para alcanzar cualquiera de los canales B.

• Si la llamada en la línea BRI debe realizarse a 56k o 64k

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• Cisco IOS Software Release 12.0(3)T y posterior. Esto se debe a que el comando isdn call se introdujo en la versión 12.0(3)T del software del IOS de Cisco.

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

Convenciones

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

Antecedentes

En una llamada de loopback, el router marca el número ISDN de su propia interfaz de velocidad básica (BRI). La llamada prosigue hacia la nube de la compañía telefónica en donde la llamada se conmuta hasta el segundo canal BRI. Esta llamada ahora es detectada por el router como una llamada entrante en el segundo canal. Por lo tanto, el router envía y recibe la llamada ISDN.

Una llamada de loopback comprueba la capacidad del router para iniciar y finalizar una llamada ISDN. Una llamada de loopback exitosa le da una fuerte indicación de que el circuito ISDN a la nube de la compañía telefónica funciona.

Hay dos tipos de llamadas de bucle invertido que puede realizar para probar un circuito BRI:

• ¿Una llamada de loopback de Capa 3 ISDN ??? para el cual puede utilizar el comando isdn call interface. Esta llamada de loopback puede ayudarle a verificar si las Capas ISDN 1, 2 y 3 funcionan entre el router y el switch ISDN local. Esta prueba utiliza el canal D y no prueba los datos a través de los canales B. Esto no implica cambios en la configuración del router. Realice primero esta prueba. Si se realiza correctamente, intente la prueba de llamada de loopback de datos.

• ¿Una llamada de loopback de datos? que comprueba si los canales B pueden pasar realmente datos. Esto implica un cambio de configuración en el router.

Estos procedimientos sólo le permiten comprobar si el circuito BRI al switch local funciona. No prueba la conectividad ISDN de extremo a extremo ni los problemas relacionados con el enrutamiento de marcado a pedido (DDR). Para obtener más información sobre la resolución de problemas de BRI, consulte los siguientes documentos:

• Diagrama de flujo de resolución de problemas de ISDN BRI

• Resolución de problemas de la Capa 3 de ISDN BRI mediante el comando debug isdn q931

Realización de una Llamada de Loopback de Capa 3 ISDN

Esta sección proporciona un ejemplo de una llamada loopback exitosa de Capa 3 de ISDN. El comando isdn call habilita las llamadas ISDN salientes sin requisitos DDR, como tráfico interesante y rutas. Este comando sólo se puede utilizar para probar el circuito ISDN hasta la Capa 3 y no se puede utilizar para pasar tráfico o como sustitución de la configuración DDR adecuada. Este comando verifica si el circuito ISDN, especialmente la Capa 3, es funcional.

La figura 1 muestra el flujo de llamada y algunos de los mensajes debug isdn q931:

Figura 1 - El flujo de llamada y algunos mensajes debug isdn q931

maui-soho-04#isdn call interface bri 0 5551111

!--- The router dials 5551111 (the ISDN number of the router's own BRI). !--- If the BRI circuit has two different phone numbers for each B-channel, !--- use the number that belongs to the second B-channel. !--- You can use this command to make calls at 56k, with the speed 56 option
.
maui-soho-04#
*Mar  1 17:55:08.344: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x09

!--- Q931 Setup message is Transmitted (TX) to the telco switch.

*Mar  1 17:55:08.360:         Bearer Capability i = 0x8890
*Mar  1 17:55:08.360:         Channel ID i = 0x83
*Mar  1 17:55:08.364:         Keypad Facility i = '5551111'
*Mar  1 17:55:08.484: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0x89

!--- Call Proceeding message is Received (RX) from the telco switch. !--- The switch now processes the call.

*Mar  1 17:55:08.488:         Channel ID i = 0x89
*Mar  1 17:55:08.516: ISDN BR0: RX <-  SETUP pd = 8  callref = 0x12

!--- A Setup message is Received (RX) from the switch. This message is for the !--- incoming call. Remember that the router sent a Setup message (for the !--- outgoing call) and now receives a SETUP message for the same call.

*Mar  1 17:55:08.516:         Bearer Capability i = 0x8890
*Mar  1 17:55:08.520:         Channel ID i = 0x8A
*Mar  1 17:55:08.520:         Signal i = 0x40 - Alerting on - pattern 0 
*Mar  1 17:55:08.532:         Called Party Number i = 0xC1, '5551111'
*Mar  1 17:55:08.532:         Locking Shift to Codeset 5
*Mar  1 17:55:08.532:         Codeset 5 IE 0x2A  i = 0x808001038001118001, '<'
*Mar  1 17:55:08.564: ISDN BR0: Event: Received a DATA call from  on B2 at 64 Kb/s
*Mar  1 17:55:08.620: %DIALER-6-BIND: Interface BRI0:2 bound to profile Dialer1
*Mar  1 17:55:08.652: ISDN BR0: TX ->  CALL_PROC pd = 8  callref = 0x92

! --- Transmit (TX) a Call Proceeding message for the incoming call.

*Mar  1 17:55:08.652:         Channel ID i = 0x8A
*Mar  1 17:55:08.700: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
*Mar  1 17:55:08.988: ISDN BR0: TX ->  CONNECT pd = 8  callref = 0x92

! --- Transmit (TX) a Connect message for the incoming call.

*Mar  1 17:55:08.988:         Channel ID i = 0x8A
*Mar  1 17:55:09.040: ISDN BR0: RX <-  CONNECT_ACK pd = 8  callref = 0x12

! --- Receive (RX) a Connect Acknowledgment for the incoming call.

*Mar  1 17:55:09.040:         Channel ID i = 0x8A
*Mar  1 17:55:09.040:         Signal i = 0x4F - Alerting off 
*Mar  1 17:55:09.064: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x89

! --- Receive (RX) a Connect message for the outgoing call.

*Mar  1 17:55:09.076: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x09
*Mar  1 17:55:09.080: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
*Mar  1 17:55:09.104: %DIALER-6-BIND: Interface BRI0:1 bound to profile BRI0
*Mar  1 17:55:09.112: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 5551111 

! --- Call is now connected. Loopback call is successful.

Notas:

• Durante la llamada de loopback, el router funciona como el router llamado y el router que llama en diferentes canales B. Es importante que realice un seguimiento de estos "roles duales" cuando interprete la salida debug isdn q931. Por ejemplo, el router transmite un mensaje de configuración (TX -> SETUP) y también recibe uno (RX <- SETUP). La CONFIGURACIÓN transmitida debe estar asociada a la llamada saliente mientras que el mensaje SETUP recibido está asociado a la llamada entrante.

• En el ejemplo anterior, se marca el número del primer canal B. Sin embargo, la compañía telefónica reconoce que el primer canal B está ocupado (ya que realiza la llamada), y conmuta la llamada al segundo canal B y la conexión se completa correctamente. Sin embargo, una configuración incorrecta en el switch de la compañía telefónica puede dar lugar a una falla en la llamada de loopback. Esto puede ocurrir cuando el switch intenta asignar la llamada al primer canal (que está ocupado realizando la llamada). Pida a la compañía telefónica que agregue ambos canales B en un grupo de búsqueda. Sin embargo, a los efectos de esta prueba, podemos especificar el segundo número de canal B en el comando isdn call interface para solucionar este problema.

• Realice la llamada de loopback en el otro router.

• Si las llamadas de loopback se realizan correctamente y la llamada al extremo remoto continúa fallando, puede probar una llamada de loopback de datos para probar la integridad de los datos del canal B como se describe en la siguiente sección.

Para obtener información sobre cómo resolver cualquier problema, consulte estos documentos:

• Diagrama de flujo de resolución de problemas de ISDN BRI

• Resolución de problemas de la Capa 3 de ISDN BRI mediante el comando debug isdn q931

Realizar una llamada de loopback de datos

Las llamadas de loopback de datos son útiles para probar si los canales B pueden transmitir datos correctamente. En muchas situaciones, debug ppp negotiation puede fallar continuamente. Esta prueba se puede utilizar para verificar la integridad de los datos en el canal B.

Nota: Esta prueba, a diferencia de la anterior, implica un cambio de configuración en el router.

En una llamada de loopback de datos, configuramos dos interfaces de marcador en el router. La interfaz del marcador se configura con los comandos de direccionamiento, autenticación y DDR necesarios para marcar correctamente en la línea BRI, recibir la llamada entrante, enlazar a la otra interfaz del marcador y conectarse correctamente.

Cree un perfil de marcador para marcar otro perfil de marcador en el mismo router.

Configure el router

Para configurar el router para la llamada de loopback, complete estos pasos:

1. Guarde la configuración en ejecución con la ayuda del comando copy running-config startup-config. Cuando lo haga, puede reiniciar y restaurar la configuración en ejecución a la versión anterior a la prueba después de que la prueba haya finalizado.

2. Configure la interfaz física.

   Nota: En esta sección se supone que es consciente de la información necesaria relacionada con ISDN como, por ejemplo, tipo de switch y SPID.

   interface BRI0
    no ip address
    
   !--- Do not configure an IP address on the physical interface. !--- The IP address will be configured on the dialer. 
   
    encapsulation ppp
    !--- physical interface uses PPP encapsulation
    dialer pool-member 1
    
   !--- Assign BRI0 as member of dialer pool 1. !--- Dialer pool 1 is specified in interface Dialer 1, and !--- interface Dialer 2.
   
    isdn switch-type basic-ni
    isdn spid1 71355511110101 5551111
    isdn spid2 71355511120101 5551112
    
   !--- switch-type and SPID configuration. !--- Contact the telco for this information. 
   
    ppp authentication chap callin   
    
   !--- The physical interface uses CHAP authentication. !--- Authentication is required on the physical interface to bind the !--- incoming call to the right dialer profile.
   
   

3. Configure la primera interfaz del marcador:

   interface Dialer1
    ip address 1.1.1.1 255.255.255.0
    
   !--- Assign an IP address to the dialer interface. !--- In this example, the IP addresses for both dialers !--- are in the same subnet.
   
    encapsulation ppp
    
   !--- The dialer interface uses PPP (same as the physical BRI interface).
   
    dialer pool 1
   
    !--- his defines Dialer pool 1. BRI 0 is a member of this pool.
   
    dialer remote-name dialer2
    
   !--- This name must match the name used by the other dialer interface to !--- authenticate itself. Dialer string 7135551112. !--- Phone number for the other B-channel. !--- If your connection only needs one number for both B-channels !--- (that is, they are in a hunt-group), use that number here.
   
    dialer-group 1
    
   !--- Apply interesting traffic definition from dialer-list 1.
   
    ppp authentication chap callin
   
    !--- Use one-way CHAP authentication. This is sufficient for this test.
   
    ppp chap hostname dialer1
   
    !--- CHAP hostname to be sent out for authentication.
   
    ppp chap password dialer1
   
    !--- CHAP Password to be sent out for authentication.
   
   

4. Configure la segunda interfaz del marcador:

   interface Dialer2
    ip address 1.1.1.2 255.255.255.0
   
    !--- Assign an IP address to the dialer interface. !--- In this example, IP address for both dialers are in the same subnet.
   
    encapsulation ppp
    dialer pool 1
   
    !--- This defines Dialer pool 1. !--- BRI 0 is a member of this pool.
   
    dialer remote-name dialer1
   
    !--- This name must match the name used by the other dialer interface !--- (dialer1) to authenticate itself. Dialer string 7135551111. !--- Phone number for the other B-channel. !--- If your connection only has one number for both B-channels !--- (that is, they are in a hunt-group), use that number here.
   
    dialer-group 1
   
    !--- Apply interesting traffic definition from dialer-list 1.
   
    ppp authentication chap callin
    ppp chap hostname dialer2
   
    !--- CHAP hostname to be sent out for authentication.
   
    ppp chap password dialer2
   
    !--- CHAP Password to be sent out for authentication.
   
   

5. Configure el nombre de usuario y las contraseñas para la autenticación:

   username dialer1 password 0 dialer1
   username dialer2 password 0 dialer2
   

   El nombre de usuario y las contraseñas son las mismas que las configuradas con la ayuda de los comandos ppp chap hostname y ppp chap password en cada interfaz de marcador.

6. Configure rutas estáticas para mayor claridad:

   ip route 1.1.1.1 255.255.255.255 Dialer1
   
   !--- Note that the route for 1.1.1.1 points to dialer1.
   
   ip route 1.1.1.2 255.255.255.255 Dialer2
   
   !--- Note that the route for 1.1.1.2 points to dialer2. !--- The routes are used to determine which dialer interface is !--- used for dialout.
   
   

   Sugerencia: Si configura las direcciones IP para la interfaz Dialer 1 (Paso 3) y la interfaz Dialer 2 (Paso 4) en subredes separadas, las rutas estáticas no son necesarias.

7. Configure la definición de tráfico interesante.

   dialer-list 1 protocol ip permit

   Nota: el número de lista de marcador debe ser el mismo que el configurado en grupo de marcador en la interfaz de marcador. En este ejemplo, configure dialer-list 1.

8. Cuando se complete la prueba, recargue el router (no guarde la configuración) para volver a la configuración original utilizada antes de la prueba.

Inicio de la llamada de bucle invertido de datos

Ahora iniciaremos la llamada de loopback de datos y buscaremos la finalización exitosa de la negociación PPP. Una negociación PPP exitosa indica que los canales B pueden pasar los datos correctamente.

Figura 2: Inicio de la llamada de bucle invertido de datos

Active estas depuraciones:

• debug dialer

• debug isdn q931

• debug ppp negotiation

• debug ppp authentication (opcional)

Nota: Cuando la llamada de loopback está en curso, el router funciona como el router llamado y el router que llama en diferentes canales B. Es importante que realice un seguimiento de estos "roles duales" cuando interprete el resultado de los comandos debug isdn q931 y debug ppp negotiation. Por ejemplo, el router transmite un mensaje de configuración (TX -> SETUP) y también recibe uno (RX <- SETUP). La CONFIGURACIÓN transmitida debe estar asociada a la llamada saliente, mientras que el mensaje SETUP recibido está asociado a la llamada entrante.

Aquí están los debugs para la llamada ISDN adosada:

router#show debug
Dial on demand:
  Dial on demand events debugging is on
PPP:
  PPP protocol negotiation debugging is on
ISDN:
  ISDN Q931 packets debugging is on
  ISDN Q931 packets debug DSLs. (On/Off/No DSL:1/0/-)
  DSL  0 --> 1
  1 -

router#ping 1.1.1.1

!--- Because of the static route entry shown in step 6 above, !--- the call is made out from dialer 1. 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

03:40:41: BR0 DDR: rotor dialout [priority]
03:40:41: BR0 DDR: Dialing cause ip (s=1.1.1.1, d=1.1.1.1)
03:40:41: BR0 DDR: Attempting to dial 7135551112
03:40:41: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x08

!--- Outgoing SETUP message.

03:40:41:         Bearer Capability i = 0x8890
03:40:41:         Channel ID i = 0x83
03:40:41:         Keypad Facility i = '7135551112'
03:40:41: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0x88
03:40:41:         Channel ID i = 0x89
03:40:41: ISDN BR0: RX <-  SETUP pd = 8  callref = 0x2A

!--- Incoming SETUP message on the other B-channel.

03:40:41:         Bearer Capability i = 0x8890
03:40:41:         Channel ID i = 0x8A
03:40:41:         Signal i = 0x40 - Alerting on - pattern 0
03:40:41:         Called Party Number i = 0xC1, '5551112', Plan:ISDN,
  Type:Subscriber(local)
03:40:41:         Locking Shift to Codeset 5
03:40:41:         Codeset 5 IE 0x2A  i = 0x808001038001118001, '<'
03:40:42: ISDN BR0: Event: Received a DATA call from  on B2 at 64 Kb/s

!--- Note that the call comes in on the second B-channel (BRI0:2). !--- Hence the outgoing call must have been on BRI0:1.

03:40:42: ISDN BR0: Event: Accepting the call id 0xB
03:40:42: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up.
03:40:42: BR0:2 PPP: Treating connection as a callin
03:40:42: BR0:2 PPP: Phase is ESTABLISHING, Passive Open [0 sess, 0 load]
03:40:42: BR0:2 LCP: State is Listen

!--- PPP LCP negotiations begin. 

03:40:42: ISDN BR0: TX ->  CALL_PROC pd = 8  callref = 0xAA
03:40:42:         Channel ID i = 0x8A
03:40:42: ISDN BR0: TX ->  CONNECT pd = 8  callref = 0xAA
03:40:42:         Channel ID i = 0x8A
03:40:42: ISDN BR0: RX <-  CONNECT_ACK pd = 8  callref = 0x2A
03:40:42:         Channel ID i = 0x8A
03:40:42:         Signal i = 0x4F - Alerting off
03:40:42: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x88
03:40:42: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
03:40:42: BR0:1: interface must be fifo queue, force fifo
03:40:42: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1
03:40:42: BR0:1 PPP: Treating connection as a callout
03:40:42: BR0:1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load]
03:40:42: BR0:1 PPP: No remote authentication for call-out

!--- One-way authentication (configured with PPP authentication CHAP callin).

03:40:42: BR0:1 LCP: O CONFREQ [Closed] id 11 len 10
03:40:42: BR0:1 LCP:    MagicNumber 0x513D7870 (0x0506513D7870)
03:40:42: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x08
03:40:42: BR0:2 LCP: I CONFREQ [Listen] id 11 Len 10
03:40:42: BR0:2 LCP:    MagicNumber 0x513D7870 (0x0506513D7870)
03:40:42: BR0:2 LCP: O CONFREQ [Listen] id 11 Len 15
03:40:42: BR0:2 LCP:    AuthProto CHAP (0x0305C22305)
03:40:42: BR0:2 LCP:    MagicNumber 0x513D7A45 (0x0506513D7A45)
03:40:42: BR0:2 LCP: O CONFACK [Listen] id 11 Len 10
03:40:42: BR0:2 LCP:    MagicNumber 0x513D7870 (0x0506513D7870)
03:40:42: BR0:1 LCP: I CONFREQ [REQsent] id 11 Len 15
03:40:42: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
03:40:42: BR0:1 LCP:    MagicNumber 0x513D7A45 (0x0506513D7A45)
03:40:42: BR0:1 LCP: O CONFACK [REQsent] id 11 Len 15
03:40:42: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
03:40:42: BR0:1 LCP:    MagicNumber 0x513D7A45 (0x0506513D7A45)
03:40:42: BR0:1 LCP: I CONFACK [ACKsent] id 11 Len 10
03:40:42: BR0:1 LCP:    MagicNumber 0x513D7870 (0x0506513D7870)
03:40:42: BR0:1 LCP: State is Open
03:40:42: BR0:1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
03:40:43: BR0:2 LCP: I CONFACK [ACKsent] id 11 Len 15
03:40:43: BR0:2 LCP:    AuthProto CHAP (0x0305C22305)
03:40:43: BR0:2 LCP:    MagicNumber 0x513D7A45 (0x0506513D7A45)
03:40:43: BR0:2 LCP: State is Open
03:40:43: BR0:2 PPP: Phase is AUTHENTICATING, by this end [0 sess, 1 load]

!--- Authentication begins.

03:40:43: BR0:2 CHAP: O CHALLENGE id 7 Len 26 from "router"
03:40:43: BR0:1 CHAP: I CHALLENGE id 7 Len 26 from "router"
03:40:43: BR0:1 CHAP: Using alternate hostname dialer1

!--- Use the alternate hostname specified with PPP CHAP hostname !--- under int Dialer 1.

03:40:43: BR0:1 CHAP: Username router not found
03:40:43: BR0:1 CHAP: Using default password
03:40:43: BR0:1 CHAP: O RESPONSE id 7 Len 28 from "dialer1"

!--- Outgoing CHAP response sent on B-channel 1. 

03:40:43: BR0:2 CHAP: I RESPONSE id 7 Len 28 from "dialer1"

!--- Incoming CHAP response seen on B-channel 2.

03:40:43: BR0:2 CHAP: O SUCCESS id 7 Len 4

!--- Authentication is successful

03:40:43: BR0:2: interface must be fifo queue, force FIFO
03:40:43: %DIALER-6-BIND: Interface BR0:2 bound to profile Di2

!--- Call (from Dialer 1) is bound to int Dialer 2. !--- This is because the dialer remote-name dialer1 command is !--- configured under int dialer 2. Binding fails when the dialer remote-name !--- command is omitted, or is incorrect, .

03:40:43: BR0:2 PPP: Phase is UP [0 sess, 0 load]

!--- IPCP negotiation begins.

03:40:43: BR0:2 IPCP: O CONFREQ [Not negotiated] id 1 Len 10
03:40:43: BR0:2 IPCP:    Address 1.1.1.2 (0x030601010102)
03:40:43: BR0:2 CDPCP: O CONFREQ [Closed] id 1 Len 4
03:40:43: BR0:1 CHAP: I SUCCESS id 7 Len 4
03:40:43: BR0:1 PPP: Phase is UP [0 sess, 1 load]
03:40:43: BR0:1 IPCP: O CONFREQ [Not negotiated] id 1 Len 10
03:40:43: BR0:1 IPCP:    Address 1.1.1.1 (0x030601010101)
03:40:43: BR0:1 CDPCP: O CONFREQ [Closed] id 1 Len 4
03:40:43: BR0:1 IPCP: I CONFREQ [REQsent] id 1 Len 10
03:40:43: BR0:1 IPCP:    Address 1.1.1.2 (0x030601010102)
03:40:43: BR0:1 IPCP: O CONFACK [REQsent] id 1 Len 10
03:40:43: BR0:1 IPCP:    Address 1.1.1.2 (0x030601010102)
03:40:43: BR0:1 CDPCP: I CONFREQ [REQsent] id 1 Len 4
03:40:43: BR0:1 CDPCP: O CONFACK [REQsent] id 1 Len 4
03:40:43: BR0:2 IPCP: I CONFREQ [REQsent] id 1 Len 10
03:40:43: BR0:2 IPCP:    Address 1.1.1.1 (0x030601010101)
03:40:43: BR0:2 IPCP: O CONFACK [REQsent] id 1 Len 10
03:40:43: BR0:2 IPCP:    Address 1.1.1.1 (0x030601010101)
03:40:43: BR0:2 CDPCP: I CONFREQ [REQsent] id 1 Len 4
03:40:43: BR0:2 CDPCP: O CONFACK [REQsent] id 1 Len 4
03:40:43: BR0:2 IPCP: I CONFACK [ACKsent] id 1 Len 10
03:40:43: BR0:2 IPCP:    Address 1.1.1.2 (0x030601010102)
03:40:43: BR0:2 IPCP: State is Open

!--- IPCP on B-channel 2 is Open.

03:40:43: BR0:1 IPCP: I CONFACK [ACKsent] id 1 Len 10
03:40:43: BR0:1 IPCP:    Address 1.1.1.1 (0x030601010101)
03:40:43: BR0:1 IPCP: State is Open

!--- IPCP on B-channel 1 is Open.

03:40:43: BR0:2 DDR: dialer protocol up
03:40:43: BR0:1 DDR: dialer protocol up
03:40:43: Di2 IPCP: Install route to 1.1.1.1
03:40:43: Di1 IPCP: Install route to 1.1.1.2
03:40:44: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:2, 
changed state to up
03:40:44: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, 
changed state to up

!--- Both B-channels are up.

...
Success rate is 0 percent (0/5)
router#

Nota: Los pings pueden fallar debido a problemas relacionados con el ruteo. Se puede esperar esto. La negociación PPP exitosa es la verdadera prueba de si los canales B pueden pasar correctamente los datos en el link. Si la llamada falla, póngase en contacto con la compañía telefónica para obtener más información sobre cómo resolver problemas de la línea.

Información Relacionada

• Diagrama de flujo de resolución de problemas de ISDN BRI
• Resolución de problemas de la Capa 3 de ISDN BRI mediante el comando debug isdn q931
• Configuración y resolución de problemas en perfiles de marcador
• Autenticación de PPP utilizando los comandos ppp chap hostname y ppp authentication chap callin
• Soporte de Tecnología de Discado y Acceso
• Soporte Técnico y Documentación - Cisco Systems

Historial de revisiones