Discar e acessar : """Integrated Services Digital Networks (ISDN), Channel-Associated Signaling (CAS)"""

Executando chamadas de loopback para testar circuitos de BRI

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

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

Pré-requisitos

Requisitos

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

Antes que você tente este procedimento, obtenha a informação seguinte do telco:

  • Tipo de switch que deve ser configurado.

  • Services profile identifier (SPID) e o número de diretório local (LDN). O SPID e o LDN são exigidos no Estados Unidos da América.

  • Se ambos os canais B estão em um grupo de buscas. Se estão em um grupo de buscas nós precisamos somente discamos um número para alcançar um ou outro canal B.

  • Se chamar que a linha BRI precisa de ser feita no 56K ou no 64k

Componentes Utilizados

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

  • Cisco IOS Software Release 12.0(3)T, e mais tarde. Isto é 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. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.

Convenções

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 seu próprio Basic Rate Interface (BRI). 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 dá-lhe uma indicação forte que os circuitos de ISDN ao nuvem Telco são funcionais.

Há dois tipos de chamadas de loopback que você pode executar para testar uns circuitos de BRI:

  • Uma chamada de loopback da camada de ISDN 3??? para qual você pode usar o comando isdn call interface. Esta chamada de loopback pode ajudá-lo a verificar se as camadas de ISDN 1, 2, e 3 são funcionais entre o roteador e o switch de ISDN local. Este teste usa o canal D, e não faz dados de teste através dos canais B. Isto não envolve nenhuma mudança à configuração do roteador. Execute este teste primeiro. Se sucede, tente o teste da chamada de loopback de dados.

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

Estes procedimentos permitem somente que você teste se os circuitos de BRI ao switch local são funcionais. Não testa a conectividade ISDN fim-a-fim ou as edições relativa ao Dial-on-Demand Routing (DDR). Para obter mais informações sobre de pesquisar defeitos BRI refira os seguintes documentos:

Execute uma chamada de loopback da camada de ISDN 3

Esta seção fornece um exemplo de uma chamada de loopback bem sucedida da camada de ISDN 3. O comando isdn call permite chamadas ISDN que parte sem requisitos de DDR tais como o tráfego interessante e as rotas. Este comando pode somente ser usado para testar os circuitos de ISDN até a camada 3, e não pode ser usado para passar o tráfego ou como uma substituição para a configuração de DDR apropriada. Este comando verifica se os circuitos de ISDN, especialmente a camada 3, são funcionais.

Figura 1 indica o fluxo de chamadas e alguns das mensagens do q931 de ISDN debugar:

Figura 1 - O fluxo de chamadas, e alguns debugam mensagens do q931 de ISDN

/image/gif/paws/22802/bri_loopback_call1.gif

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 de chamada nos canais B diferentes. É importante que você se mantém a par destes “papéis dual” quando você interpreta a saída do q931 de ISDN debugar. Por exemplo, o roteador transmite um mensagem setup (TX- > SETUP), e recebe um demasiado (RX < - INSTALAÇÃO). A INSTALAÇÃO transmitida deve ser associada com a chamada feita quando o mensagem de configuração recebida for associado com a chamada recebida.

  • No exemplo acima, o número para o primeiro canal B é discado. Contudo, o telco reconhece que o primeiro canal B é ocupado (desde que faz o atendimento), e comuta o atendimento ao segundo canal B e a conexão é terminada com sucesso. Contudo, uma configuração incorreta no switch telco pode conduzir a uma falha da chamada de loopback. Isto pode acontecer quando o interruptor tenta atribuir o atendimento ao primeiro canal (que é ocupado fazer o atendimento). Peça o telco para adicionar ambos os canais B em um grupo de buscas. Contudo, a fim este teste, nós pode especificar o segundo número de canal B no comando isdn call interface trabalhar em torno desta edição.

  • Execute a chamada de loopback no outro roteador.

  • Se as chamadas de loopback sucedem, e o atendimento à extremidade remota continua a falhar, você pode tentar uma chamada de loopback de dados testar a integridade de dados do canal B como descrito na próxima seção.

Para obter informações sobre de como pesquisar defeitos todas as edições, refira estes documentos:

Execute uma chamada de loopback de dados

As chamadas de loopback de dados são úteis de testar se os canais B podem corretamente transmitir dados. Em muitas situações, debugar a negociação ppp pode continuamente falhar. Este teste pode ser usado para verificar a integridade de dados no canal B.

Nota: Este teste, ao contrário do teste anterior, envolve uma alteração de configuração ao roteador.

Em uma chamada de loopback de dados, nós configuramos duas interfaces do discador no roteador. A interface do discador é configurada com o endereçamento, a autenticação e os comandos ddr necessários discar com sucesso para fora na linha BRI, recebe a chamada recebida, liga-a à outra interface do discador, e conecta-a com sucesso.

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

Configurar o roteador

Para configurar o roteador para a chamada de loopback, termine estas etapas:

  1. Salvar a configuração running com a ajuda do comando copy running-config startup-config. Quando você faz assim, você pode recarregar e restaurar a executar-configuração à versão do teste preliminar depois que o teste está completo.

  2. Configurar a interface física.

    Nota: Esta seção supõe que você está ciente da informação ISDN-relacionada necessária como, tipo de switch, e 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. Configurar 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. Configurar 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. Configurar o nome de usuário e senha para a autenticação:

    username dialer1 password 0 dialer1
    username dialer2 password 0 dialer2
    

    O nome de usuário e senha é o mesmo que aqueles você configuraram com a ajuda dos comandos ppp chap hostname e ppp chap password sob cada interface do discador.

  6. Configurar rotas estáticas para maior 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ê configura os endereços IP de Um ou Mais Servidores Cisco ICM NT para o interface dialer 1 (etapa 3) e o discador 2 da relação (etapa 4) nas sub-redes separadas, as rotas estáticas não são necessárias.

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

    dialer-list 1 protocol ip permit

    Nota: o número de lista de discador deve ser o mesmo que esse configurado no discador-grupo sob a interface do discador. Neste exemplo, configure dialer-list 1.

  8. Quando o teste está completo, recarregue o roteador (não salvar a configuração) para retornar à configuração original usada antes do teste.

Inicie a chamada de loopback de dados

Nós iniciaremos agora a chamada de loopback de dados, e procuramos a conclusão bem sucedida da negociação de PPP. Uma negociação de PPP bem-sucedida indica que os canais B podem corretamente passar dados.

Figura 2 - Inicie a chamada de loopback de dados

bri_loopback_call2.gif

Ative estes debuga:

  • debug dialer

  • debug isdn q931

  • negociação de debug ppp

  • debugar a autenticação de PPP (opcional)

Nota: Quando a chamada de loopback é em andamento, o roteador executa como o Roteador chamado e o roteador de chamada nos canais B diferentes. É importante que você se mantém a par destes “papéis dual” quando você interpreta a saída dos comandos debug isdn q931 e debug ppp negotiation. Por exemplo, o roteador transmite um mensagem setup (TX- > SETUP), e recebe um demasiado (RX < - INSTALAÇÃO). A INSTALAÇÃO transmitida deve ser associada com a chamada feita, quando o mensagem de configuração recebida for associado com a chamada recebida.

Seja aqui debuga para a chamada ISDN lado a lado:

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: Os sibilos podem falhar devido às edições relativas à distribuição. Você pode esperar este. A negociação de PPP bem-sucedida é o teste verdadeiro de se os canais B podem corretamente passar dados no link. Se o atendimento falha, contacte o telco para mais informações sobre de como pesquisar defeitos a linha.


Informações Relacionadas


Document ID: 22802