Guia de configuração e solução de problemas do roteador DSL Cisco - PPPoE: Roteador DSL como um cliente PPPoE Solução de problemas

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) de seu 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 varia um pouco dependendo da 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?

Para determinar se a interface ATM0 está administrativamente inativa, emita este comando no modo enable no roteador:

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:

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

2. 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

Para determinar se a interface ATM0 está inativa e inativa, execute o comando show interface atm 0 no modo de ativação 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).

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 para o ISP verificar se o serviço DSL 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.

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 roteadores da série 800.

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 roteador Cisco 800 Series 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 de PVC corretos (VPI/VCI)?

Com uma implantação PPPoE, não há uma maneira fácil de descobrir dinamicamente os valores do identificador de caminho virtual/identificador de canal virtual (VPI/VCI) do PVC (Permanent Virtual Circuit). Entre em contato com o ISP se não tiver certeza dos valores de PVC.

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 pacote de entrada estiverem aumentando, você deverá receber pacotes de negociação PPPoE do ISP. Se esse não for o caso, ligue para o ISP.

Se os contadores de saída vinculados estiverem aumentando, você deve enviar pacotes de negociação PPPoE. 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 incrementando apenas na direção de saída, continue com as etapas de solução de problemas neste documento.

Uma sessão PPPoE está ativa?

O PPPoE é executado em duas fases. A primeira fase é o estabelecimento da sessão PPPoE, e a segunda fase é a negociação PPP. O PPPoE deve ser estabelecido antes da negociação dos parâmetros PPP padrão. A maneira mais fácil de determinar se você tem uma sessão PPPoE ativa é emitir o comando show vpdn.

Router#show vpdn
%No active L2TP tunnels
%No active L2F tunnels
%No active PPTP tunnels
PPPoE Tunnel and Session Information Total tunnels 1 sessions 1
PPPoE Tunnel Information
Session count: 1
PPPoE Session Information
SID  RemMAC          LocMAC          Intf   Vast   OIntf   VP/VC
0    0000.0000.0000  0000.0000.0000         UNKN   ATM0    8/35

Neste exemplo, nenhuma sessão PPPoE está ativa. Isso é indicado por um SID de 0, e o RemMAC e LockMAC de 0000.000.0000. Se você estiver nesse estado, vá para a próxima seção.

Uma sessão PPPoE negociada com êxito é semelhante a esta:

Router#show vpdn
%No active L2TP tunnels 
%No active L2F tunnels 
PPPoE Tunnel and Session Information Total tunnels 1 sessions 1
PPPoE Tunnel Information
Session count: 1

PPPoE Session Information
SID  RemMAC           LocMAC          Intf    Vast   OIntf   VP/VC
1    0050.7359.35b7   0001.96a4.84ac  Vi1     UP     ATM0    8/35

Neste exemplo, você pode ver que o SID é um número diferente de zero e que os campos RemMAC e LockMAC estão preenchidos. O outro campo de interesse é o Vast, que indica se o PPP foi negociado e autenticado com êxito. Se o Vast é UP, o PPP foi negociado e autenticado com êxito e você pode prosseguir para o Por que posso acessar algumas páginas da Web com PPPoE, mas não outras? deste documento. Se Vast estiver DOWN, continue com a próxima seção.

Você está recebendo uma resposta PPPoE do roteador de agregação?

Se você não tiver uma sessão PPPoE ativa estabelecida, será necessário emitir o comando debug vpdn pppoe-events para determinar o que PPPoE não é ativado.

Router#debug vpdn pppoe-events
*Mar  3 21:49:38.030: Sending PADI: vc=8/35
*Mar  3 21:49:38.030: padi timer expired
*Mar  3 21:50:10.030: Sending PADI: vc=8/35
*Mar  3 21:50:10.030: padi timer expired
*Mar  3 21:50:42.030: Sending PADI: vc=8/35
*Mar  3 21:50:42.030: padi timer expired
*Mar  3 21:51:14.030: Sending PADI: vc=8/35
*Mar  3 21:51:14.030: padi timer expired
*Mar  3 21:51:46.030: Sending PADI: vc=8/35
*Mar  3 21:51:46.030: padi timer expired
Router#undebug all

Neste exemplo, o roteador DSL da Cisco envia continuamente quadros PADI (Ative Discovery Initiation) de PPPoE para o ISP sem resposta. O quadro PADI é o primeiro de uma série de quadros de configuração de chamada PPPoE. Se o ISP não responder com uma PADO (PPPoE Ative Discovery Offer), a negociação de PPPoE não será bem-sucedida. A única solução para esse problema é entrar em contato com o ISP.

Se você negociar com êxito o PPPoE, sua saída debug vpdn pppoe-events se parecerá com esta saída:

Router#debug vpdn pppoe-events
*Mar  3 21:49:38.030: Sending PADI: vc=8/35
*Mar  3 21:50:10.030: PPPOE: we've got our pado and the pado timer went off
*Mar  3 21:50:35.030: OUT PADR from PPPoE tunnel
*Mar  3 21:50:50.030: IN PADS from PPPoE tunnel
Router#undebug all

Se o PPPoE for negociado com êxito, continue com a próxima seção sobre solução de problemas do PPP.

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 Cisco DSL e interpretar a saída. O principal debug que você usa é debug ppp negotiation. Esta saída do 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 essa saída, 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 da 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 roteador DSL da Cisco tem um parâmetro PPP configurado que o ISP não suporta ou quando o ISP tem um parâmetro configurado que o roteador DSL da Cisco 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 está solicitando 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 da 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 é CHAP, mas pode ser qualquer opção. O único lugar no roteador DSL da Cisco 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 à interface dialer 1 para negociar corretamente o PPP com o ISP. No caso do roteador que envia pacotes, talvez seja necessário ligar para o Cisco TAC para determinar que comando(s) precisa(m) ser ativado(s) no roteador DSL 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 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 esta saída:

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

or

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

!--- Turn 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 o Challenge Handshake Authentication Protocol (CHAP) e o Password Authentication Protocol (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 está usando 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. Logo 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. Logo 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

Por que posso acessar algumas páginas da Web com PPPoE, mas não outras?

O acesso a apenas algumas páginas da Web é um problema comum quando você executa um cliente PPPoE em um roteador. Por design, o PPPoE pode suportar uma MTU de até 1.492 bytes. Portanto, você deve garantir que os dispositivos finais enviem quadros com no máximo 1492 bytes. Limitar o MTU a 1.492 bytes pode ser um problema porque a maioria dos PCs e estações de trabalho de usuário final têm um MTU padrão de 1.500 bytes.

Há duas opções para ajustar o tamanho da MTU: ajuste o tamanho da MTU no roteador e ajuste o tamanho da MTU no PC.

Ajuste o tamanho da MTU do PPPoE no roteador DSL da Cisco

Notas Importantes:

Esses comandos de configuração só funcionam se você executar a Tradução de Endereço de Rede (NAT - Network Address Translation) ou a Conversão de Endereço de Porta (PAT - Port Address Translation) no roteador DSL da Cisco.

O comando ip adjust-mss no Cisco IOS® Software Release 12.2(2)XH mudou para ip tcp adjust-mss <mss value>. Essa alteração está documentada nas Release Notes dos Cisco 800 Series Routers e Cisco 820 Series Routers para Cisco IOS versão 12.2(2)XH.

!
vpdn enable
no vpdn logging
!
vpdn-group pppoe
request-dialin 
protocol pppoe 
!
interface ethernet0
 no shut
 ip address <ip address> <subnet mask>
 ip adjust-mss 1452
 
!--- The TCP MSS command requires an MSS of 1452, not 1492.

 ip nat inside 
 no ip directed-broadcast
!
interface atm0
 no shut
 no ip address
 no ip directed-broadcast
 no atm ilmi-keepalive
 bundle-enable
!
interface atm0.1 point-to-point
 no ip directed-broadcast
 pvc <vpi/vci>
 pppoe-client dial-pool-number 1 
 !
!
interface dialer1
 ip address negotiated
 mtu 1492
 ip nat outside 
 encapsulation ppp
 dialer pool 1
 ppp chap hostname <username>
 ppp chap password <password>
 ppp pap sent-username <username> password <password>
! 
ip nat inside source list 1 interface dialer1 overload 
!
ip classless 
ip route 0.0.0.0 0.0.0.0 dialer1 
access-list 1 permit 
      
      
        0.0.255.255 
      
!

Ajuste o tamanho da MTU PPPoE no PC usando o utilitário Dr TCP

Conclua estes passos para alterar o tamanho da MTU no PC. A alteração do registro é salva quando o procedimento é concluído.

Observação: o utilitário Dr. TCP é compatível com todos os PCs baseados em Windows.

1. Baixe a versão mais recente do utilitário Dr. TCP.

2. Atualize a página do navegador para garantir que a página esteja atualizada.

3. Execute o utilitário Dr.TCP.

4. No menu, escolha o adaptador Ethernet.

5. No campo MTU, digite 1492.

6. Clique Apply (Aplicar) para salvar a alteração e clique em Exit (Sair).

7. Reinicialize o cliente do PC PPPoE.

Você precisa executar o utilitário apenas uma vez por PC cliente PPPoE.

Etapas adicionais de solução de problemas de MTU

Se você alterar o tamanho do MTU com o Dr. TCP ou com o roteador Cisco DSL e ainda não conseguir navegar por determinados sites, ajuste o tamanho do MTU novamente. Altere o tamanho do MTU para 1452 em Dr. TCP ou altere o valor de ajuste do MSS no roteador DSl Cisco para 1412. Se os tamanhos forem grandes demais, continue reduzindo os tamanhos MTU até alcançar uma linha de base de 1400 para Dr. TCP ou 1360 para ajuste MSS no roteador Cisco DSL.

Informações Relacionadas

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