Guia de configuração e solução de problemas do roteador DSL Cisco - Solução de problemas de PPPoA

Introduction

Há muitas razões pelas quais sua conexão de Linha Digital do Assinante (DSL) pode não estar funcionando corretamente. O objetivo deste documento é isolar a causa da falha e consertá-la. O primeiro passo de troubleshooting é determinar qual camada de seu serviço de Asynchronous Digital Subscriber Line (ADSL) está falhando. Há três camadas nas quais a falha pode ocorrer.

• Camada 1 - Conectividade física DSL com o Multiplexador de Acesso de Linha de Assinante Digital (DSLAM - Digital Subscriber Line Access Multiplexer) do ISP

• Camada 2.1 - conectividade ATM

• Camada 2.2 - Point-to-Point Protocol over ATM (PPPoA), Point-to-Point Protocol over Ethernet (PPPoE), RFC1483 Bridging ou RFC1483 Routing

• Camada 3 - IP

A maneira mais fácil de determinar qual camada você deve começar a solucionar problemas é emitir o comando show ip interface brief. A saída desse comando é ligeiramente diferente com base na sua configuração.

827-ESC#show ip interface brief
Interface     IP-Address     OK?     Method     Status     Protocol
ATM0          unassigned     YES     manual 	    up         up
ATM0.1        unassigned     YES     unset  	    up         up
Ethernet0     10.10.10.1     YES     manual      up         up

Se os status de ATM0 e ATM0.1 estiverem ativos e o protocolo estiver ativo, comece a solucionar problemas na Camada 2.

Se as interfaces ATM estiverem inoperantes ou se continuarem a subir e descer (elas não ficam ativadas e ativadas), comece a solucionar problemas na Camada 1.

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

Conventions

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Problemas da camada 1

A luz de detecção de portadora (CD) no painel frontal do Cisco DSL Router está ligada ou desligada?

Se a luz do CD estiver acesa, vá para a seção Problemas da Camada 2 deste documento.

Se a luz do CD estiver apagada, continue com a próxima pergunta.

O seu ISP está usando um DSLAM que suporta o chipset Alcatel?

Verifique essas informações com o ISP.

A porta DSL na parte traseira do Cisco DSL Router está conectada à tomada de parede DSL?

Se a porta DSL não estiver conectada à tomada de parede DSL, conecte-a à parede com um cabo RJ-11 de 4 ou 6 pinos. Este é um cabo telefônico padrão.

A interface ATM está em um estado administrativamente inoperante?

Emita este comando no modo enable no roteador para determinar se a interface ATM0 está administrativamente inativa:

Router#show interface atm 0
ATM0 is administratively down, line protocol is down
<... snipped ...> 

Se o status da interface ATM0 estiver administrativamente inoperante, emita o comando no shutdown na interface ATM0.

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface atm 0
Router(config-if)#no shut
Router(config-if)#end
Router#write memory

A pinagem do cabo está correta?

Se o status da interface ATM0 estiver inativo e inativo, o roteador não verá uma portadora na linha ADSL. Isso geralmente indica um dos dois problemas:

• Os pinos ativos na tomada de parede DSL estão incorretos.

• O ISP não ativou um serviço DSL nesta tomada de telefone.

Pinagens da porta xDSL do roteador DSL da Cisco

O conector RJ-11 fornece uma conexão xDSL para mídia externa através de uma tomada modular RJ-11 de 6 pinos padrão.

Pino	Descrição
3	XDSL_Tip
4	XDSL_Ring

Observação: o Cisco 1417 usa pinos 2 e 5 em um conector modular RJ-11 de 6 pinos padrão.

Para determinar se a interface ATM0 está inativa e inativa, execute o comando show interface atm 0 no modo enable do roteador:

Router#show interface atm 0
ATM0 is down, line protocol is down
<... snipped ...>

Se a interface ATM estiver inativa e inativa - não administrativamente inativa - verifique a pinout da tomada de parede DSL. O Roteador DSL usa um cabo RJ-11 (4 ou 6 pinos) padrão para fornecer a conexão ADSL à tomada de parede. O par central de pinos no cabo RJ-11 é usado para transportar o sinal ADSL (pinos 3 e 4 em um cabo de 6 pinos ou pinos 2 e 3 em um cabo de 4 pinos). Isso não se aplica ao Cisco 1417 que usa pinos 2 e 5.

Se você tiver certeza de que tem os pinos certos na tomada de parede e a interface ATM0 ainda está inativa e inativa, substitua o cabo RJ-11 entre a porta DSL e a tomada de parede. Se a interface ainda estiver inativa e inativa depois de substituir o cabo RJ-11, entre em contato com o ISP e peça ao ISP para verificar se o serviço ADSL foi ativado na tomada de parede que você usa.

Se não tiver certeza de quais pinos na tomada de parede estão ativos, pergunte ao ISP.

Se você estiver usando um Cisco 827 como seu CPE (Customer Premises Equipment, Equipamento das Instalações do Cliente DSL), você tem a fonte de alimentação correta para o Cisco 827?

Se você verificou que o cabo DSL está bom e que tem as pinagens corretas, a próxima etapa é verificar se a fonte de alimentação do 827 está correta.

Observação: o 827 não usa a mesma fonte de alimentação que outros Cisco 800 Series Routers.

Para determinar se você tem a fonte de alimentação correta, na parte traseira do adaptador de alimentação procure Output +12V 0.1A, -12V 0.1A, +5V 3A, -24V 0.12A e -71V 0.12A. Se a fonte de alimentação não tiver os feeds de +12V e -12V, então é para um Cisco 800 Series Router diferente e não funciona no 827. Observe que se você usar a fonte de alimentação incorreta, o Cisco 827 é ligado, mas não consegue treinar (conectar) para o ISP DSLAM.

O modo operacional DSL está correto?

Se tudo até esse ponto no procedimento de identificação e solução de problemas da camada 1 estiver correto, a próxima etapa é verificar se você tem o modo operacional DSL correto. A Cisco recomenda o uso do modo operacional automático dsl se você não tiver certeza de qual tecnologia DMT seu ISP usa. Estes são os comandos para configurar a detecção automática do modo operacional:

Router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#interface atm 0
Router(config-if)#dsl operating-mode auto
Router(config-if)#end
Router#write memory

O circuito foi testado/provisionado corretamente?

Obtenha essas informações do ISP ou da companhia telefônica.

Problemas da camada 2

Você tem os valores corretos de PVC (Permanent Virtual Circuit, circuito virtual permanente) (VPI/VCI)?

Conclua estes passos para determinar se você tem os valores corretos de VPI/VCI (Virtual Path Identifier/Identificador de circuito virtual) configurados no roteador.

1. Verifique sua versão do software Cisco IOS®.

   Importante: Isso não funciona com o software Cisco IOS versão 12.1(1)XB.

   Router#show version 
   
   !--- Used to determine your Cisco IOS version.
   
   
   Cisco Internetwork Operating System Software
   IOS (tm) C820 Software (C820-OSY656I-M), Version 12.1(3)XG3, 
   EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)
   
   !--- The two lines immediately preceding appear on one line on the router.
    
   TAC:Home:SW:IOS:Specials for info
   Copyright (c) 1986-2000 by cisco Systems, Inc.
   Compiled Wed 20-Dec-00 16:44 by detang
   Image text-base: 0x80013170, data-base: 0x80725044
   <... snipped ...>

2. Configure o roteador para debug logging.

   Router#configure terminal 
   Enter configuration commands, one per line. End with CNTL/Z.
   Router(config)#logging console
   Router(config)#logging buffer
   Router(config)#service timestamp debug datetime msec
   Router(config)#service timestamp log datetime msec
   Router(config)#end
   Router#write memory
   Building configuration...
   [OK]
   Router#terminal monitor

3. Ative a depuração no roteador.

   Router#debug atm events 
   ATM events debugging is on
   Router#
   2d18h:
   2d18h: RX interrupt: conid = 0, rxBd = 0x80C7EF74 length=52
   2d18h: Data Cell received on vpi = 8 vci = 35
   
   !--- Your VPI/VCI.
   
   2d18h:
   2d18h: RX interrupt: conid = 0, rxBd = 0x80C7EEC0 length=52
   2d18h: Data Cell received on vpi = 8 vci = 35
   2d18h:
   2d18h: RX interrupt: conid = 0, rxBd = 0x80C7EECC length=52
   2d18h: Data Cell received on vpi = 8 vci = 35
   2d18h:
   2d18h: RX interrupt: conid = 0, rxBd = 0x80C7EED8 length=52
   2d18h: Data Cell received on vpi = 8 vci = 35

4. Verifique se você tem eventos de depuração ATM em execução no Cisco DSL Router e, em seguida, vá para uma conexão de Internet em funcionamento e comece a fazer ping no endereço IP que seu ISP atribuiu estaticamente a você.

   Não importa se você configurou esse endereço IP no Cisco DSL Router. O importante é que sua interface ATM está ativa/ativa e que você está fazendo ping no endereço IP que o ISP lhe forneceu. Se você não vir a saída esperada após o teste de ping, entre em contato com o ISP para obter suporte.

5. Desative a depuração no roteador.

   << esperar 60 segundos >>

   Router#undebug all 
   
   !--- Turn off the debug events.
   
   
   All possible debugging has been turned off.

   Verifique seus valores de VPI/VCI e faça as alterações necessárias na sua configuração.

   Se você não vir a saída durante os 60 segundos de depuração, entre em contato com o ISP.

Você está recebendo dados do ISP?

Se você tiver os valores de PVC corretos, a próxima etapa será verificar se você está tentando negociar o PPP com seu ISP. Para fazer isso, emita o comando show interface atm0 e verifique os pacotes de entrada e saída.

Router#show interface atm0
ATM0 is up, line protocol is up
Hardware is DSLSAR (with Alcatel ADSL Module)
MTU 4470 bytes, sub MTU 4470, BW 128 Kbit, DLY 16000 usec, 
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ATM, loopback not set
Encapsulation(s): AAL5, PVC mode
24 maximum active VCs, 256 VCS per VP, 1 current VCCs
VC idle disconnect time: 300 seconds
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 5 bits/sec, 0 packets/sec
5 minute output rate 7 bits/sec, 0 packets/sec
100 packets input, 5600 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
250 packets output, 1400 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 output buffer failures, 0 output buffers swapped out

Se os contadores de pacotes estiverem aumentando, você deverá receber pacotes de negociação PPP do ISP. Se esse não for o caso, ligue para o ISP.

Se os contadores de saída vinculados estiverem aumentando, você deve estar enviando pacotes de negociação PPP. Se esse não for o caso, verifique a configuração no roteador. Se o PPP estiver configurado corretamente, os pacotes de negociação PPP serão enviados continuamente para fora da interface ATM0.

Se os pacotes estiverem sendo incrementados em ambas as direções, continue com as etapas de solução de problemas neste documento.

O PPP está negociando corretamente?

Se a Camada 1 estiver ativa e você tiver o VPI/VCI correto, a próxima etapa é garantir que o PPP seja ativado corretamente. Para fazer isso, você precisa executar uma série de comandos debug no roteador DSL Cisco e interpretar a saída. A depuração primária que você usa é a negociação de debug ppp. Esta saída de comando é um exemplo de uma negociação PPP bem-sucedida:

Router#debug ppp negotiation

PPP protocol negotiation debugging is on

Router#
2w3d: Vi1 PPP: No remote authentication for call-out
2w3d: Vi1 PPP: Phase is ESTABLISHING
2w3d: Vi1 LCP: O CONFREQ [Open] id 146 len 10
2w3d: Vi1 LCP: MagicNumber 0x8CCF0E1E (0x05068CCF0E1E)
2w3d: Vi1 LCP: O CONFACK [Open] id 102 Len 15
2w3d: Vi1 LCP: AuthProto CHAP (0x0305C22305)
2w3d: Vi1 LCP: MagicNumber 0xD945AD0A (0x0506D945AD0A)
2w3d: Di1 IPCP: Remove route to 20.20.2.1
2w3d: Vi1 LCP: I CONFACK [ACKsent] id 146 Len 10
2w3d: Vi1 LCP: MagicNumber 0x8CCF0E1E (0x05068CCF0E1E)
2w3d: Vi1 LCP: State is Open
2w3d: Vi1 PPP: Phase is AUTHENTICATING, by the peer
2w3d: Vi1 CHAP: I CHALLENGE id 79 Len 33 from "6400-2-NRP-2"
2w3d: Vi1 CHAP: O RESPONSE id 79 Len 28 from "John"
2w3d: Vi1 CHAP: I SUCCESS id 79 Len 4
2w3d: Vi1 PPP: Phase is UP
2w3d: Vi1 IPCP: O CONFREQ [Closed] id 7 Len 10
2w3d: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
2w3d: Vi1 IPCP: I CONFREQ [REQsent] id 4 Len 10
2w3d: Vi1 IPCP: Address 20.20.2.1 (0x030614140201)
2w3d: Vi1 IPCP: O CONFACK [REQsent] id 4 Len 10
2w3d: Vi1 IPCP: Address 20.20.2.1 (0x030614140201)
2w3d: Vi1 IPCP: I CONFNAK [ACKsent] id 7 Len 10
2w3d: Vi1 IPCP: Address 40.1.1.2 (0x030628010102)
2w3d: Vi1 IPCP: O CONFREQ [ACKsent] id 8 Len 10
2w3d: Vi1 IPCP: Address 40.1.1.2 (0x030628010102)
2w3d: Vi1 IPCP: I CONFACK [ACKsent] id 8 Len 10
2w3d: Vi1 IPCP: Address 40.1.1.2 (0x030628010102)
2w3d: Vi1 IPCP: State is Open
2w3d: Di1 IPCP: Install negotiated IP interface address 40.1.1.2
2w3d: Di1 IPCP: Install route to 20.20.2.1
Router#

Há quatro pontos principais de falha em uma negociação PPP:

• Nenhuma resposta do dispositivo remoto (ISP)

• O LCP (Link Control Protocol) não está aberto

• Falha de autenticação

• Falha de IP Control Protocol (IPCP)

Nenhuma resposta do ISP

Seu ISP não responder não deve ser um problema, pois você já verificou que os pacotes estão aumentando na interface ATM0 na direção de entrada. No entanto, se você vir pacotes incrementando em ATM0 na direção de entrada e quando executar uma negociação debug ppp você receber isso, entre em contato com o ISP para verificar se os pacotes são enviados ao roteador DSL da Cisco.

Router#debug ppp negotiation
*Mar 1 04:04:50.718: Vi1 PPP: Treating connection as a callout
*Mar 1 04:04:50.718: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load]
*Mar 1 04:04:50.718: Vi1 PPP: No remote authentication for call-out
*Mar 1 04:04:50.722: Vi1 LCP: O CONFREQ [Closed] id 1 Len 10 

!--- "O" specifies an outbound packet

*Mar 1 04:04:50.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:04:52.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:04:52.722: Vi1 LCP: O CONFREQ [REQsent] id 2 Len 10 

!--- "O" specifies an outbound packet

*Mar 1 04:04:52.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:04:54.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:04:54.722: Vi1 LCP: O CONFREQ [REQsent] id 3 Len 10 
*Mar 1 04:04:54.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:04:56.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:04:56.722: Vi1 LCP: O CONFREQ [REQsent] id 4 Len 10
*Mar 1 04:04:56.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:04:58.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:04:58.722: Vi1 LCP: O CONFREQ [REQsent] id 5 Len 10
*Mar 1 04:04:58.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:05:00.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:05:00.722: Vi1 LCP: O CONFREQ [REQsent] id 6 Len 10
*Mar 1 04:05:00.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:05:02.722: Vi1 LCP: TIMEout: State REQsent 
*Mar 1 04:05:02.722: Vi1 LCP: O CONFREQ [REQsent] id 7 Len 10 

!--- "O" specifies an outbound packet

*Mar 1 04:05:02.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
Router#undebug all

Nesta saída há apenas O pacotes, que são pacotes de saída. Para negociar com êxito o PPP, deve haver um pacote de I de entrada do ISP para cada pacote O enviado. Se os pacotes estiverem incrementando a entrada, mas você não vir pacotes I, entre em contato com o ISP para verificar os pacotes enviados ao roteador DSL Cisco.

LCP não aberto

O LCP que não está sendo aberto geralmente é causado por uma incompatibilidade nas opções do PPP. Essa incompatibilidade ocorre quando o Cisco DSL Router tem um parâmetro PPP configurado que o ISP não suporta ou quando o ISP tem um parâmetro configurado que o Cisco DSL Router não suporta. Esta saída mostra um exemplo de incompatibilidade de opção PPP:

Router#debug ppp negotiation
*Mar 1 04:52:43.254: Vi1 PPP: Treating connection as a callout
*Mar 1 04:52:43.258: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load] 
*Mar 1 04:52:43.258: Vi1 PPP: No remote authentication for call-out 
*Mar 1 04:52:43.258: Vi1 LCP: O CONFREQ [Closed] id 3 len 10
*Mar 1 04:52:43.262: Vi1 LCP: MagicNumber 0x31A2F808 (0x050631A2F808)
*Mar 1 04:52:43.310: Vi1 LCP: I CONFREQ [REQsent] id 180 Len 14
*Mar 1 04:52:43.310: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 1 04:52:43.310: Vi1 LCP: MagicNumber 0x39D50E9B (0x050639D50E9B)
*Mar 1 04:52:43.314: Vi1 LCP: O CONFNAK [REQsent] id 180 Len 9

!--- PPP option reject

*Mar 1 04:52:43.314: Vi1 LCP: AuthProto CHAP (0x0305C22305)

!--- PPP option that is rejected

*Mar 1 04:52:43.314: Vi1 LCP: I CONFACK [REQsent] id 3 Len 10
*Mar 1 04:52:43.318: Vi1 LCP: MagicNumber 0x31A2F808 (0x050631A2F808)
*Mar 1 04:52:43.366: Vi1 LCP: I CONFREQ [ACKrcvd] id 181 Len 14
*Mar 1 04:52:43.366: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 1 04:52:43.366: Vi1 LCP: MagicNumber 0x39D50E9B (0x050639D50E9B)
*Mar 1 04:52:43.370: Vi1 LCP: O CONFNAK [ACKrcvd] id 181 Len 9 

!--- PPP option reject

*Mar 1 04:52:43.370: Vi1 LCP: AuthProto CHAP (0x0305C22305) 

!--- PPP option that is rejected

*Mar 1 04:52:43.418: Vi1 LCP: I CONFREQ [ACKrcvd] id 182 Len 14
*Mar 1 04:52:43.418: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 1 04:52:43.418: Vi1 LCP: MagicNumber 0x39D50E9B (0x050639D50E9B)
Router#undebug all

Seja um pacote de I ou O, um Configure-Negative-Acknowledge (CONFNAK) é indicativo de uma incompatibilidade de configuração de PPP. Isso significa que um lado da conexão PPP solicita uma opção PPP que o outro lado não pode ou não está configurado para executar. Se o roteador DSL da Cisco enviar o CONFNAK (indicado por "O CONFNAK"), o roteador DSL da Cisco não poderá executar ou não será configurado para a opção que o ISP envia. Se o CONFNAK for enviado pelo ISP (indicado por "I CONFNAK"), você configurou uma opção no roteador DSL Cisco que o ISP não está disposto a executar.

A linha após o CONFNAK descreve a opção que é rejeitada. Neste exemplo de saída, a opção é Challenge Handshake Authentication Protocol (CHAP), mas pode ser qualquer opção. O único lugar no Cisco DSL Router onde as opções PPP podem ser configuradas é o discador de interface 1. Emita o comando show run interface dialer 1 para exibir a configuração do seu discador de interface 1.

Se o seu ISP enviar o I CONFNAK, procure comandos no discador de interface 1 que correspondam à linha depois do CONFNAK e remova-os. Se o roteador DSL da Cisco enviar o O CONFNAK, adicione um comando ao discador de interface 1 para negociar corretamente o PPP com o ISP. No caso do roteador que envia pacotes, talvez seja necessário ligar para o Suporte da Cisco para determinar quais comandos precisam ser ativados no Roteador DSL da Cisco.

Falha de autenticação

Uma falha de autenticação ocorre quando o ISP não consegue autenticar seu nome de usuário ou senha do PPP. Há dois cenários nos quais isso pode ocorrer. O primeiro cenário é uma incompatibilidade de tipo de autenticação, causada quando você não configura corretamente o roteador. Todas as configurações de autenticação listadas neste documento são responsáveis pelos tipos de autenticação PAP (Password Authentication Protocol) e CHAP. Para flexibilidade de configuração, você deve ter o CHAP e o PAP configurados. Se você não tiver ambos configurados, você poderá ver a saída de um comando debug ppp como este exemplo:

Router#debug ppp negotiation
00:34:29: Vi1 LCP:O CONFREQ [REQsent] id 53 Len 15 
00:34:29: Vi1 LCP: AuthProto CHAP (0x0305C22305)

!--- Sends CHAP requests

00:34:29: Vi1 LCP: MagicNumber 0x01B63483 (0x050601B63483)
00:34:29: Vi1 LCP: I CONFREQ [REQsent] id 252 Len 14
00:34:29: Vi1 LCP: AuthProto PAP (0x0304C023)

!--- Receives PAP requests from the service provider

00:34:29: Vi1 LCP: MagicNumber 0xBC5233F9 (0x0506BC5233F9)
00:34:29: Vi1 LCP: O CONFREJ [REQsent] id 252 Len 8
Router#undebug all

OU

Router#debug ppp negotiation
00:45:44: Vi1 LCP: I CONFREQ [Listen] id 141 Len 15
00:45:44: Vi1 LCP: AuthProto CHAP (0x0305C22305)

!--- Receives CHAP requests from the service provider

00:45:44: Vi1 LCP: MagicNumber 0xBC5C7DDC (0x0506BC5C7DDC)
00:45:44: Vi1 LCP: O CONFREQ [Listen] id 255 Len 14
00:45:44: Vi1 LCP: AuthProto PAP (0x0304C023) 

!--- Sends out PAP requests

Router#undebug all

!--- Turns off ppp debug.

Para corrigir ambos os problemas de incompatibilidade de autenticação, consulte a configuração da opção de implementação PPPoA apropriada e reconfigure a autenticação PPP.

O segundo cenário de problema de autenticação que você pode encontrar é um nome de usuário ou senha PAP incorretos. Para determinar se esse é o problema, emita o comando debug ppp negotiation. Supondo que seu roteador esteja configurado para CHAP e PAP, como a configuração descrita anteriormente neste guia mostra, seu ISP pode não estar usando a autenticação PAP.

Para determinar a autenticação usada pelo ISP, verifique as opções no pacote I CONFREQ enviado a você do ISP. Se esse pacote for seguido por uma opção chamada AuthProto PAP, você estará usando PAP. Se o I CONFREQ for seguido por uma opção chamada AuthProto CHAP, você está usando o CHAP e deve prosseguir para Como saber se meu nome de usuário e senha do CHAP estão corretos?

Como saber se meu nome de usuário e senha PAP estão corretos?

Depois de confirmar que o ISP usa PAP, emita o comando debug ppp negotiation para confirmar se o nome de usuário e a senha do PAP estão corretos.

Router#debug ppp negotiation 
*Mar 2 00:50:15.741: Vi1 PPP: Treating connection as a callout
*Mar 2 00:50:15.745: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load]
*Mar 2 00:50:15.745: Vi1 PPP: No remote authentication for call-out
*Mar 2 00:50:15.745: Vi1 LCP: O CONFREQ [Closed] id 177 Len 10
*Mar 2 00:50:15.745: Vi1 LCP: MagicNumber 0x35EB5D4F (0x050635EB5D4F)
*Mar 2 00:50:15.789: Vi1 LCP: I CONFACK [REQsent] id 177 Len 10
*Mar 2 00:50:15.793: Vi1 LCP: MagicNumber 0x35EB5D4F (0x050635EB5D4F)
*Mar 2 00:50:17.241: Vi1 LCP: I CONFREQ [ACKrcvd] id 203 Len 14
*Mar 2 00:50:17.241: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 2 00:50:17.241: Vi1 LCP: MagicNumber 0x3E1D1E5E (0x05063E1D1E5E)
*Mar 2 00:50:17.245: Vi1 LCP: O CONFACK [ACKrcvd] id 203 Len 14
*Mar 2 00:50:17.245: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 2 00:50:17.245: Vi1 LCP: MagicNumber 0x3E1D1E5E (0x05063E1D1E5E)
*Mar 2 00:50:17.249: Vi1 LCP: State is Open
*Mar 2 00:50:17.249: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
*Mar 2 00:50:17.249: Vi1 PAP: O AUTH-REQ id 9 Len 14 from "cisco" 

!--- "cisco" is the PAP username configured on this DSL Router.

*Mar 2 00:50:17.297: Vi1 PAP: I AUTH-NAK id 9 Len 27 msg is "Authentication failure"
*Mar 2 00:50:17.301: Vi1 LCP: I TERMREQ [Open] id 204 Len 4
*Mar 2 00:50:17.301: Vi1 LCP: O TERMACK [Open] id 204 Len 4
*Mar 2 00:50:17.305: Vi1 PPP: Phase is TERMINATING [0 sess, 1 load]u
*Mar 2 00:50:19.305: Vi1 LCP: TIMEout: State TERMsent
*Mar 2 00:50:19.305: Vi1 LCP: State is Closed
*Mar 2 00:50:19.305: Vi1 PPP: Phase is DOWN [0 sess, 1 load]

Se você tiver um problema de autenticação PAP, verá o estado do LCP ir para Abrir. Após a alteração do estado do LCP, você verá o PPP entrar em uma fase de autenticação. Se uma das duas linhas seguintes contiver I AUTH-NAK, seu nome de usuário PAP ou senha PAP estão incorretos. Neste ponto, você precisa reconfigurar seu nome de usuário e senha PAP usando esta sequência de comandos. Observe que seu nome de usuário e senha PAP diferenciam maiúsculas e minúsculas.

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface dialer 1
Router(config-if)#ppp pap sent-username 
      
      
        password 
        
      
Router(config-if)#end
Router#write memory

Como saber se meu nome de usuário e senha de CHAP estão corretos?

Depois de confirmar que o ISP usa CHAP, emita o comando debug ppp negotiation para confirmar se o nome de usuário e a senha do CHAP estão corretos.

Router#debug ppp negotiation
*Mar 3 02:51:47.287: Vi1 PPP: Treating connection as a callout
*Mar 3 02:51:47.287: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load]
*Mar 3 02:51:47.291: Vi1 PPP: No remote authentication for call-out
*Mar 3 02:51:47.291: Vi1 LCP: O CONFREQ [Closed] id 188 Len 10
*Mar 3 02:51:47.291: Vi1 LCP: MagicNumber 0x3B821FF1 (0x05063B821FF1)
*Mar 3 02:51:47.339: Vi1 LCP: I CONFREQ [REQsent] id 204 Len 15
*Mar 3 02:51:47.343: Vi1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 3 02:51:47.343: Vi1 LCP: MagicNumber 0x43B3F393 (0x050643B3F393)
*Mar 3 02:51:47.343: Vi1 LCP: O CONFACK [REQsent] id 204 Len 15
*Mar 3 02:51:47.347: Vi1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 3 02:51:47.347: Vi1 LCP: MagicNumber 0x43B3F393 (0x050643B3F393)
*Mar 3 02:51:47.347: Vi1 LCP: I CONFACK [ACKsent] id 188 Len 10
*Mar 3 02:51:47.351: Vi1 LCP: MagicNumber 0x3B821FF1 (0x05063B821FF1)
*Mar 3 02:51:47.351: Vi1 LCP: State is Open
*Mar 3 02:51:47.351: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
*Mar 3 02:51:47.395: Vi1 CHAP: I CHALLENGE id 1 Len 32 from "6400-2-NRP3"
*Mar 3 02:51:47.395: Vi1 CHAP: Using alternate hostname cisco
*Mar 3 02:51:47.399: Vi1 CHAP: Username 6400-2-NRP3 not found
*Mar 3 02:51:47.399: Vi1 CHAP: Using default password
*Mar 3 02:51:47.399: Vi1 CHAP: O RESPONSE id 1 Len 26 from "cisco"  

!--- "cisco" is the CHAP username configured on this DSL Router.

*Mar 3 02:51:47.447: Vi1 CHAP: I FAILURE id 1 Len 26 MSG is "Authentication failure"
*Mar 3 02:51:47.447: Vi1 LCP: I TERMREQ [Open] id 205 Len 4
*Mar 3 02:51:47.451: Vi1 LCP: O TERMACK [Open] id 205 Len 4
*Mar 3 02:51:47.451: Vi1 PPP: Phase is TERMINATING [0 sess, 0 load]
*Mar 3 02:51:49.451: Vi1 LCP: TIMEout: State TERMsent
*Mar 3 02:51:49.451: Vi1 LCP: State is Closed
*Mar 3 02:51:49.451: Vi1 PPP: Phase is DOWN [0 sess, 0 load]
Router#undebug all

Se você tiver um problema de autenticação de CHAP, verá o estado do LCP ir para Abrir. Após a alteração do estado do LCP, você verá o PPP entrar em uma fase de autenticação. A partir desse ponto, você verá uma série de linhas CHAP. Se a última destas linhas mostrar I FAILURE, você tem o nome de usuário e a senha de CHAP incorretos. Use esta sequência de comandos para corrigir seu nome de usuário e senha de CHAP. Observe que seu nome de usuário e senha diferenciam maiúsculas e minúsculas.

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface dialer 1
Router(config-if)#ppp chap hostname 
      
       
Router(config-if)#ppp chap password 
      
      
Router(config-if)#end
Router#write memory

Como saber quando a autenticação PPP é bem-sucedida?

Este exemplo mostra uma negociação CHAP bem-sucedida.

Router#debug ppp negotiation
<... snipped ...>
*Mar 3 03:30:09.335: Vi1 LCP: State is Open
*Mar 3 03:30:09.335: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
*Mar 3 03:30:09.379: Vi1 CHAP: I CHALLENGE id 41 len 32 from "6400-2-NRP3"
*Mar 3 03:30:09.379: Vi1 CHAP: Using alternate hostname cisco
*Mar 3 03:30:09.379: Vi1 CHAP: Username 6400-2-NRP3 not found
*Mar 3 03:30:09.383: Vi1 CHAP: Using default password
*Mar 3 03:30:09.383: Vi1 CHAP: O RESPONSE id 41 Len 26 from "cisco"
*Mar 3 03:30:09.431: Vi1 CHAP: I SUCCESS id 41 Len 4

!--- CHAP negotiation was a success.

*Mar 3 03:30:09.431: Vi1 PPP: Phase is UP [0 sess, 1 load] 
<... snipped ...>
Router#undebug all

Este exemplo mostra uma negociação PAP bem-sucedida.

Router#debug ppp negotiation
<... snipped ...>
*Mar 3 03:33:19.491: Vi1 LCP: State is Open
*Mar 3 03:33:19.491: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 0 load]
*Mar 3 03:33:19.495: Vi1 PAP: O AUTH-REQ id 255 Len 16 from "cisco"
*Mar 3 03:33:19.539: Vi1 PAP: I AUTH-ACK id 255 Len 5
*Mar 3 03:33:19.539: Vi1 PPP: Phase is UP [0 sess, 0 load] 

!--- PAP negotiation was a success.

<... snipped ...>
Router#undebug all

Informações Relacionadas

• Opções de implementação do PPPoA
• Configuração e Guia de Troubleshooting do Cisco DSL Router
• Suporte ADSL
• Suporte Técnico e Documentação - Cisco Systems