Guía de Configuración y Troubleshooting del Router DSL de Cisco - PPPoE: Resolución de problemas del router DSL como cliente PPPoE

Introducción

Hay muchas razones por las que puede que su conexión de Digital Subscriber Line (DSL) no funcione correctamente. El objetivo de este documento es aislar la causa del error y repararla. El primer paso de Troubleshooting es determinar qué capa de su servicio Asynchronous Digital Subscriber Line (ADSL) está fallando. Hay tres capas en las que puede producirse el error.

• Capa 1 - Conectividad física DSL al Multiplexor de acceso a línea de suscriptor digital (DSLAM) de su ISP

• Capa 2.1 - Conectividad ATM

• Capa 2.2: protocolo punto a punto sobre ATM (PPPoA), protocolo punto a punto sobre Ethernet (PPPoE), puente RFC1483 o routing RFC1483

• Capa 3 - IP

La forma más sencilla de determinar qué capa debe comenzar a resolver problemas es ejecutar el comando show ip interface brief. El resultado de este comando varía ligeramente según la configuración.

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

Si los estados de ATM0 y ATM0.1 están activos y el protocolo está activo, comience a resolver problemas en la Capa 2.

Si las interfaces ATM están inactivas, o si continúan subiendo y luego bajan (no se mantienen en funcionamiento), comience a resolver problemas en la Capa 1.

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Problemas de Capa 1

¿La portadora detecta (CD) en el panel frontal del router DSL de Cisco está encendida o apagada?

Si la luz del CD está encendida, vaya a la sección Problemas de Capa 2 de este documento.

Si la luz del CD está apagada, continúe con la siguiente pregunta.

¿Utiliza el ISP un DSLAM compatible con el chipset Alcatel?

Compruebe esta información con el ISP.

¿El puerto DSL de la parte posterior del router DSL de Cisco está conectado a la toma de pared DSL?

Si el puerto DSL no está enchufado a la toma de pared DSL, conecte el puerto a la pared con un cable RJ-11 de 4 o 6 pines. Este es un cable telefónico estándar.

¿La interfaz ATM se encuentra en estado administrativamente inactivo?

Para determinar si la interfaz ATM0 está administrativamente inactiva, ejecute este comando en el modo enable en el router:

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

Si el estado de la interfaz ATM0 está administrativamente inactivo, ejecute el comando no shutdown bajo la interfaz 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

¿La clavija del cable es correcta?

Si el estado de la interfaz ATM0 está desactivado, el router no ve una portadora en la línea ADSL. Esto indica generalmente uno de dos problemas:

1. Los pines activos en la toma de pared DSL son incorrectos.

2. El ISP no ha activado un servicio DSL en esta toma de pared.

Clavijas del puerto xDSL del router DSL de Cisco

El conector RJ-11 proporciona una conexión xDSL a medios externos a través de un conector modular estándar RJ-11 de 6 pines.

PIN	Descripción
3	XDSL_Tip
4	XDSL_Ring

Para determinar si la interfaz ATM0 está inactiva, ejecute el comando show interface atm 0 desde el modo de habilitación del router:

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

Si la interfaz ATM está inactiva y no está inactiva (no administrativamente), verifique la clavija de su toma de pared DSL. El router DSL utiliza un cable RJ-11 estándar (4 o 6 pines) para proporcionar la conexión ADSL a la toma de pared. El par central de pines del cable RJ-11 se utiliza para llevar la señal ADSL (pines 3 y 4 en un cable de 6 pines o pines 2 y 3 en un cable de 4 pines).

Si está seguro de que tiene los pines correctos en la toma de pared y la interfaz ATM0 sigue inactiva y descendente, reemplace el cable RJ-11 entre el puerto DSL y la toma de pared. Si la interfaz sigue inactiva y sin funcionar después de reemplazar el cable RJ-11, póngase en contacto con el ISP y haga que éste verifique que el servicio DSL se haya habilitado en la toma de pared que utiliza.

Si no está seguro de qué pines de la toma de pared están activos, consulte al ISP.

¿Dispone de la fuente de alimentación correcta para el Cisco 827?

Si ha verificado que el cable DSL es bueno y que tiene las clavijas correctas, el siguiente paso es asegurarse de que tiene la fuente de alimentación correcta para el 827.

Nota: El 827 no utiliza la misma fuente de alimentación que otros routers de la serie 800.

Para determinar si tiene la fuente de alimentación correcta, en la parte posterior del adaptador de corriente busque Salida +12 V 0.1A, -12 V 0.1A, +5 V 3A, -24 V 0.12A y -71 V 0.12A. Si la fuente de alimentación no tiene las fuentes +12V y -12V, entonces es para un router Cisco de la serie 800 diferente y no funciona en el 827. Tenga en cuenta que si utiliza la fuente de alimentación incorrecta, el Cisco 827 se enciende pero no puede conectarse al ISP DSLAM.

¿El modo de funcionamiento DSL es correcto?

Si todo hasta este punto en el procedimiento de resolución de problemas de la Capa 1 es correcto, el siguiente paso es asegurarse de que tiene el modo de funcionamiento DSL correcto. Cisco recomienda utilizar dsl Operating-mode auto si no está seguro de qué tecnología DMT utiliza su ISP. Estos son los comandos para configurar la autodetección en modo de funcionamiento:

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

¿Se ha probado/suministrado correctamente el circuito?

Solicite esta información al ISP o a la compañía telefónica.

Problemas de Capa 2

¿Dispone de los valores PVC correctos (VPI/VCI)?

Con una implementación PPPoE, no es fácil descubrir dinámicamente los valores de identificador de ruta virtual/identificador de canal virtual (VPI/VCI) del Circuito virtual permanente (PVC). Póngase en contacto con el ISP si no está seguro de los valores de PVC.

¿Recibe datos del ISP?

Si tiene los valores PVC correctos, el siguiente paso es verificar que está intentando negociar PPP con el ISP. Para hacer esto, ejecute el comando show interface atm0 y verifique los paquetes de entrada y salida.

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

Si los contadores de paquetes de entrada aumentan, debe recibir paquetes de negociación PPPoE del ISP. Si no es así, llame al ISP.

Si los contadores de salida enlazados aumentan, debería enviar paquetes de negociación PPPoE. Si este no es el caso, verifique la configuración en el router. Si PPP se configura correctamente, los paquetes de negociación PPP se envían continuamente fuera de la interfaz ATM0.

Si los paquetes están aumentando sólo en la dirección saliente, continúe con los pasos de solución de problemas de este documento.

¿Está activa una sesión PPPoE?

PPPoE se ejecuta en dos fases. La primera fase es el establecimiento de la sesión PPPoE y la segunda es la negociación PPP. PPPoE debe establecerse antes de la negociación de los parámetros PPP estándar. La forma más sencilla de determinar si tiene una sesión PPPoE activa es ejecutar el 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

En este ejemplo, no hay sesiones PPPoE activas. Esto es indicado por un SID de 0, y el RemMAC y el LocMAC de 0000.0000.0000. Si se encuentra en este estado, vaya a la siguiente sección.

Una sesión PPPoE que se negocia con éxito tiene el siguiente aspecto:

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

En este ejemplo puede ver que el SID es un número distinto de cero, y que los campos RemMAC y LocMAC se rellenan. El otro campo de interés es el Vast, que indica si PPP se ha negociado y autenticado con éxito. Si Vast es UP, PPP se ha negociado y autenticado correctamente y puede continuar con el ¿Por qué puedo acceder a algunas páginas web con PPPoE pero no a otras? de este documento. Si Vast está ABAJO, continúe con la siguiente sección.

¿Recibe una respuesta PPPoE del router de agregación?

Si no se ha establecido una sesión PPPoE activa, debe ejecutar el comando debug vpdn pppoe-events para determinar qué PPPoE no aparece.

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

En este ejemplo, el router DSL de Cisco envía continuamente tramas PPPoE Active Discovery Initiation (PADI) al ISP sin respuesta. La trama PADI es la primera de una serie de tramas de configuración de llamadas PPPoE. Si el ISP no responde con una oferta de descubrimiento activo (PADO) de PPPoE, la negociación PPPoE no se realiza correctamente. La única solución para este problema es ponerse en contacto con el ISP.

Si negocia con éxito PPPoE, la salida de debug vpdn pppoe-events es similar a esta salida:

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

Si PPPoE se negocia correctamente, continúe con la siguiente sección sobre la solución de problemas de PPP.

¿Está negociando el PPP correctamente?

Si la Capa 1 está activa y tiene el VPI/VCI correcto, el siguiente paso es asegurarse de que PPP se activa correctamente. Para lograr esto, necesita ejecutar una serie de comandos debug en el router DSL de Cisco e interpretar el resultado. El debug primario que utiliza es debug ppp negotiation. Este resultado del comando es un ejemplo de una negociación PPP exitosa:

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#

Hay cuatro puntos principales de falla en una negociación PPP:

• No hay respuesta del dispositivo remoto (su ISP)

• Protocolo de control de enlaces (LCP) no abierto

• Falla de autenticación

• Falla del protocolo de control IP (IPCP)

No hay respuesta del ISP

El ISP que no responda no debe ser un problema, ya que ya verificó que los paquetes están aumentando en la interfaz ATM0 en la dirección entrante. Sin embargo, si ve que los paquetes se incrementan en ATM0 en la dirección entrante y cuando ejecuta una debug ppp negotiation recibe este resultado, póngase en contacto con su ISP para verificar que los paquetes se envían al router DSL de 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

En esta salida sólo hay O paquetes, que son paquetes salientes. Para negociar exitosamente PPP, debe haber un paquete I entrante de su ISP para cada paquete O enviado. Si los paquetes están aumentando de entrada pero no ve los paquetes I, comuníquese con su ISP para verificar los paquetes que se envían al router DSL de Cisco.

LCP no abierto

El LCP que no está abierto suele estar causado por una discordancia en las opciones PPP. Esta discordancia ocurre cuando el router DSL de Cisco tiene un parámetro PPP configurado que su ISP no soporta, o cuando su ISP tiene un parámetro configurado que el router DSL de Cisco no soporta. Este resultado muestra un ejemplo de una discordancia de la opción 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

Tanto si se trata de un paquete de E como de O, un Configure-Negative-Acknowledge (CONFNAK) indica una discordancia de configuración PPP. Esto significa que un lado de la conexión PPP está pidiendo una opción PPP que el otro lado no puede o no está configurado para realizar. Si el router DSL de Cisco envía el mensaje CONFNAK (indicado por "O CONFNAK"), el router DSL de Cisco no puede realizar o no está configurado para la opción que envía el ISP. Si el ISP envía la CONFNAK (indicado por "I CONFNAK"), ha configurado una opción en el router DSL de Cisco que el ISP no está dispuesto a realizar.

La línea después de CONFNAK describe la opción que se rechaza. En este resultado de ejemplo, la opción es CHAP pero podría ser cualquier opción. El único lugar en el router DSL de Cisco donde se pueden configurar las opciones PPP es el marcador de interfaz 1. Ejecute el comando show run interface dialer 1 para ver su configuración del marcador de interfaz 1.

Si su ISP envía el comando I CONFNAK, busque los comandos bajo el marcador de interfaz 1 que coincidan con la línea después de CONFNAK y retírelos. Si el router DSL de Cisco envía el comando O CONFNAK, agregue un comando al marcador de interfaz 1 para negociar correctamente PPP con su ISP. En el caso del router que envía paquetes, puede que necesite llamar al TAC de Cisco para determinar qué comandos deben habilitarse en el router DSL de Cisco.

Falla de autenticación

Se produce un error de autenticación cuando el ISP no puede autenticar su nombre de usuario o contraseña PPP. Hay dos escenarios en los que esto puede ocurrir. El primer escenario es una discordancia de tipo de autenticación, que se produce cuando no configura correctamente el router. Todas las configuraciones de autenticación enumeradas en este documento representan los tipos de autenticación PAP y CHAP. Para obtener flexibilidad en la configuración, debe tener CHAP y PAP configurados. Si no tiene ambos configurados, puede ver el resultado de un comando debug ppp como este resultado:

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 corregir ambos problemas de discordancia de autenticación, refiérase a la configuración de la opción de implementación PPPoA apropiada y reconfigure la autenticación PPP.

El segundo escenario de problema de autenticación que puede encontrar es un nombre de usuario o contraseña PAP incorrecto. Para determinar si este es el problema, ejecute el comando debug ppp negotiation. Suponiendo que el router esté configurado tanto para el protocolo de autenticación por desafío mutuo (CHAP) como para el protocolo de autenticación por contraseña (PAP), como muestra la configuración descrita anteriormente en esta guía, es posible que el ISP no esté utilizando la autenticación PAP.

Para determinar la autenticación utilizada por su ISP, verifique las opciones en el paquete I CONFREQ enviado desde su ISP. Si a este paquete le sigue una opción llamada AuthProto PAP, está utilizando PAP. Si la I CONFREQ está seguida de una opción llamada CHAP de autenticación, usted está utilizando CHAP y debe continuar con ¿Cómo sé si mi nombre de usuario y contraseña CHAP son correctos?

¿Cómo sé si mi nombre de usuario y contraseña PAP son correctos?

Después de haber confirmado que su ISP está utilizando PAP, ejecute el comando debug ppp negotiation para confirmar que su nombre de usuario y contraseña PAP son correctos.

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]

Si tiene un problema de autenticación PAP, debería ver el estado LCP ir a Open. Directamente después del cambio de estado de LCP, debe ver que PPP entra en una fase Authenticating. Si una de las dos líneas siguientes contiene I AUTH-NAK, su nombre de usuario PAP o contraseña PAP es incorrecto. En este momento, debe reconfigurar su nombre de usuario y contraseña PAP usando esta secuencia de comandos. Tenga en cuenta que su nombre de usuario y contraseña PAP distinguen entre mayúsculas y 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

¿Cómo sé si mi nombre de usuario y contraseña CHAP son correctos?

Después de haber confirmado que su ISP utiliza CHAP, ejecute el comando debug ppp negotiation para confirmar que su nombre de usuario y contraseña CHAP son correctos.

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

Si tiene un problema de autenticación CHAP, debería ver el estado LCP ir a Open. Directamente después del cambio de estado de LCP, debe ver que PPP entra en una fase Authenticating. A partir de este punto verá una serie de líneas CHAP. Si la última de estas líneas muestra I FAILURE, tiene el nombre de usuario y la contraseña CHAP incorrectos. Utilice esta secuencia de comandos para corregir su nombre de usuario y contraseña CHAP. Tenga en cuenta que el nombre de usuario y la contraseña distinguen entre mayúsculas y 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

¿Cómo se sabe cuándo la autenticación PPP es exitosa?

Este ejemplo muestra una negociación CHAP exitosa.

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 ejemplo muestra una negociación PAP exitosa.

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 qué puedo acceder a algunas páginas web con PPPoE pero no a otras?

El acceso a sólo algunas páginas Web es un problema común cuando se ejecuta un cliente PPPoE en un router. Por diseño, PPPoE puede soportar una MTU de hasta 1492 bytes. Por lo tanto, debe asegurarse de que los dispositivos finales envíen tramas no mayores de 1492 bytes. Limitar la MTU a 1492 bytes puede ser un problema porque la mayoría de las PC y estaciones de trabajo de usuario final tienen una MTU predeterminada de 1500 bytes.

Hay dos opciones para ajustar el tamaño de la MTU: ajuste el tamaño de la MTU en el router y ajuste el tamaño de la MTU en la PC.

Ajuste del Tamaño de MTU PPPoE en el Router DSL de Cisco

Notas Importantes:

Estos comandos de configuración funcionan sólo si ejecuta la traducción de direcciones de red (NAT) o la traducción de direcciones de puerto (PAT) en el router DSL de Cisco.

El comando ip adjust-mss en Cisco IOS® Software Release 12.2(2)XH ha cambiado a ip tcp adjust-mss <mss value>. Este cambio se documenta en Release Notes para Cisco 800 Series Routers y Cisco 820 Series Routers para Cisco IOS Release 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 el tamaño de MTU PPPoE en el PC con la utilidad Dr. TCP

Complete estos pasos para cambiar el tamaño de la MTU en el PC. El cambio del registro se guarda cuando finaliza el procedimiento.

Nota: La utilidad Dr. TCP es compatible con todos los PC basados en Windows.

1. Descargue la última versión de la utilidad de Dr. TCP .

2. Actualice la página del explorador para asegurarse de que la página está actualizada.

3. Ejecute la utilidad Dr.TCP.

4. En el menú, elija el adaptador Ethernet.

5. En el campo MTU, ingrese 1492.

6. Haga clic en Apply (Aplicar) para guardar el cambio y luego haz clic en Exit (Salir).

7. Reinicie el cliente de PC PPPoE.

Sólo debe ejecutar la utilidad una vez por PC cliente PPPoE.

Pasos adicionales de solución de problemas de MTU

Si cambia el tamaño de la MTU con Dr. TCP o en el router Cisco DSL y aún así no puede explorar ciertos sitios Web, ajuste el tamaño de la MTU nuevamente. Cambie la medida del MTU a 1452 en Dr. TCP o cambie el valor de ajuste del MSS a 1412 en el router DSL de Cisco. Si estos tamaños son demasiado grandes, continúe disminuyendo los tamaños de MTU hasta alcanzar una línea de base de 1400 para Dr. TCP o 1360 para el ajuste MSS en el router DSL de Cisco.

Información Relacionada

• Compatibilidad con tecnología ADSL
• Opciones de implementación de PPPoE
• Guía de configuración y resolución de problemas del router DSL de Cisco
• Soporte Técnico y Documentación - Cisco Systems