Executando chamadas de loopback para testar circuitos BRI

Introduction

Este documento fornece instruções de como executar loopbacks para testar circuitos Basic Rate Interface (BRI).

Prerequisites

Requirements

Os leitores deste documento devem estar cientes destes tópicos:

• A saída dos comandos debug isdn q931 e debug ppp negotiation.

• Conceitos gerais de configuração de perfil de discador DDR. Para obter mais informações sobre perfis de discador, consulte Configuração e Troubleshooting de Perfis de Discador.

Antes de tentar este procedimento, obtenha as seguintes informações da Telco:

• Tipo de switch a ser configurado.

• Identificadores de perfil de serviço (SPID) e o número de diretório local (LDN). O SPID e o LDN são necessários nos Estados Unidos da América.

• Se ambos os canais B estão em um grupo de busca. Se eles estiverem em um grupo de busca, precisaremos discar apenas um número para acessar o canal B.

• Se a chamada na linha BRI precisa ser feita em 56k ou 64k

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• Software Cisco IOS versão 12.0(3)T e posterior. Isso ocorre porque o comando isdn call foi introduzido no Cisco IOS Software Release 12.0(3)T.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. All of the devices used in this document started with a cleared (default) configuration. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.

Conventions

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Informações de Apoio

Em uma chamada de loopback, o roteador disca o número ISDN de sua própria BRI (Basic Rate Interface Interface de Taxa Básica). A chamada prossegue para a nuvem da empresa de telecomunicações, onde a empresa de telecomunicações a encaminha para o segundo canal de BRI. Essa chamada agora é vista pelo roteador como uma chamada de entrada no segundo canal. Portanto, o roteador envia e recebe a chamada ISDN.

Uma chamada de circuito de retorno testa a capacidade de o roteador iniciar e encerrar uma chamada ISDN. Uma chamada de loopback bem-sucedida fornece uma forte indicação de que o circuito ISDN para a nuvem de telecomunicações está funcionando.

Há dois tipos de Chamadas de Loopback que você pode executar para testar um circuito BRI:

• Uma chamada de loopback ISDN de Camada 3 ??? para o qual você pode usar o comando isdn call interface. Essa chamada de loopback pode ajudá-lo a verificar se as Camadas 1, 2 e 3 de ISDN estão funcionando entre o roteador e o switch ISDN local. Este teste usa o canal D e não testa dados nos canais B. Isso não envolve alterações na configuração do roteador. Execute este teste primeiro. Se tiver êxito, tente o teste de chamada de loopback de dados.

• Uma chamada de loopback de dados ??? que testa se os canais B podem realmente transmitir dados. Isso envolve uma alteração de configuração no roteador.

Esses procedimentos permitem testar se o circuito BRI para o switch local está funcionando. Ele não testa a conectividade ISDN de ponta a ponta nem problemas relacionados ao DDR (dial-on-demand routing, roteamento de discagem sob demanda). Para obter mais informações sobre a solução de problemas de BRIs, consulte os seguintes documentos:

• Fluxograma de Troubleshooting de ISDN BRI

• Troubleshooting do ISDN BRI Layer 3 usando o Comando debug isdn q931

Executar uma Chamada de Loopback de Camada 3 ISDN

Esta seção fornece um exemplo de uma chamada de loopback de Camada 3 ISDN bem-sucedida. O comando isdn call permite chamadas ISDN de saída sem requisitos de DDR, como tráfego interessante e rotas. Esse comando só pode ser usado para testar o circuito ISDN até a camada 3 e não pode ser usado para transmitir tráfego ou como uma substituição para a configuração DDR adequada. Esse comando verifica se o circuito ISDN, especialmente a camada 3, está funcionando.

A Figura 1 exibe o fluxo de chamadas e algumas das mensagens debug isdn q931:

Figura 1 - O fluxo de chamada e algumas mensagens 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 a chamada de loopback, o roteador executa como o roteador chamado e o roteador chamador em diferentes canais B. É importante que você controle essas "funções duplas" ao interpretar a saída debug isdn q931. Por exemplo, o roteador transmite uma mensagem de configuração (TX -> SETUP) e recebe uma também (RX <- SETUP). A CONFIGURAÇÃO transmitida deve ser associada à chamada de saída enquanto a mensagem CONFIGURAÇÃO recebida está associada à chamada de entrada.

• No exemplo acima, o número do primeiro canal B é discado. No entanto, a telco reconhece que o primeiro canal B está ocupado (já que faz a chamada) e comuta a chamada para o segundo canal B e a conexão é concluída com êxito. No entanto, uma configuração incorreta no switch telco pode resultar em uma falha da chamada de loopback. Isso pode acontecer quando o switch tenta atribuir a chamada ao primeiro canal (que está ocupado fazendo a chamada). Peça à telco para adicionar ambos os canais B em um grupo de busca. No entanto, para a finalidade deste teste, podemos especificar o segundo número de canal B no comando isdn call interface para contornar esse problema.

• Execute a chamada de loopback no outro roteador.

• Se as chamadas de loopback forem bem-sucedidas e a chamada para a extremidade remota continuar a falhar, você pode tentar uma chamada de loopback de dados para testar a integridade dos dados do canal B, conforme descrito na próxima seção.

Para obter informações sobre como solucionar qualquer problema, consulte estes documentos:

• Fluxograma de Troubleshooting de ISDN BRI

• Troubleshooting do ISDN BRI Layer 3 usando o Comando debug isdn q931

Executar uma chamada de loopback de dados

As Chamadas de Loopback de Dados são úteis para testar se os canais B podem transmitir dados corretamente. Em muitas situações, a negociação de debug ppp pode falhar continuamente. Esse teste pode ser usado para verificar a integridade dos dados no canal B.

Observação: esse teste, diferentemente do teste anterior, envolve uma alteração de configuração no roteador.

Em uma Chamada de Loopback de Dados, configuramos duas interfaces de discador no roteador. A interface do discador é configurada com os comandos necessários de endereçamento, autenticação e DDR para discar com êxito na linha BRI, receber a chamada recebida, ligar a outra interface do discador e estabelecer ligação com êxito.

Crie um perfil de discador para discar outro perfil de discador no mesmo roteador.

Configurar o roteador

Para configurar o roteador para a chamada de loopback, faça o seguinte:

1. Salve a configuração atual com a ajuda do comando copy running-config startup-config. Ao fazer isso, você pode reinicializar e restaurar a configuração atual para a versão de pré-teste depois que o teste for concluído.

2. Configure a interface física.

   Observação: esta seção pressupõe que você está ciente das informações necessárias relacionadas à ISDN, como, por exemplo, tipo de switch e SPIDs.

   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 a primeira interface do discador:

   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 a segunda interface do discador:

   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 o nome de usuário e as senhas para autenticação:

   username dialer1 password 0 dialer1
   username dialer2 password 0 dialer2
   

   O nome de usuário e as senhas são os mesmos que você configurou com a ajuda dos comandos ppp chap hostname e ppp chap password em cada interface de discador.

6. Configure rotas estáticas para clareza:

   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.
   
   

   Dica: se você configurar os endereços IP para a interface Dialer 1 (Etapa 3) e interface Dialer 2 (Etapa 4) em sub-redes separadas, as rotas estáticas não serão necessárias.

7. Configure a definição de tráfego interessante.

   dialer-list 1 protocol ip permit

   Observação: o número da lista de discadores deve ser o mesmo que o configurado no dialer-group na interface do discador. Neste exemplo, configure dialer-list 1.

8. Quando o teste estiver concluído, recarregue o roteador (não salve a configuração) para retornar à configuração original usada antes do teste.

Iniciar a chamada de loopback de dados

Agora, iniciaremos a chamada de loopback de dados e procuraremos a conclusão bem-sucedida da negociação de PPP. Uma negociação PPP bem-sucedida indica que os canais B podem transmitir dados corretamente.

Figura 2: Iniciar a chamada de loopback de dados

Ative estas depurações:

• debug dialer

• debug isdn q931

• negociação de debug ppp

• debug ppp authentication (opcional)

Observação: quando a chamada de loopback está em andamento, o roteador é executado como o roteador chamado e o roteador chamador em diferentes canais B. É importante que você controle essas "funções duplas" ao interpretar a saída dos comandos debug isdn q931 e debug ppp negotiation. Por exemplo, o roteador transmite uma mensagem de configuração (TX -> SETUP) e recebe uma também (RX <- SETUP). A CONFIGURAÇÃO transmitida deve ser associada à chamada de saída, enquanto a mensagem CONFIGURAÇÃO recebida é associada à chamada de entrada.

Aqui estão as depurações para a chamada ISDN back-to-back:

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#

Observação: os pings podem falhar devido a problemas relacionados ao roteamento. Você pode esperar isso. A negociação bem-sucedida do PPP é o verdadeiro teste para determinar se os canais B podem transmitir dados corretamente no link. Se a chamada falhar, entre em contato com a telco para obter mais informações sobre como solucionar problemas da linha.

Informações Relacionadas

• Fluxograma de Troubleshooting de ISDN BRI
• Troubleshooting do ISDN BRI Layer 3 usando o Comando debug isdn q931
• Configuração e troubleshooting de perfis de discagem
• Autenticação PPP Usando os Comandos ppp chap hostname e ppp authentication chap callin
• Suporte à tecnologia de discagem e acesso
• Suporte Técnico e Documentação - Cisco Systems

Histórico de revisões