Solución de problemas de VDSL

Introducción

Este documento describe cómo configurar el router para equipos en las instalaciones del cliente (CPE) de Cisco Digital Subscriber Line (DSL) para el servicio de línea de suscriptor digital de velocidad de bits muy alta (VDSL). Explica cómo resolver problemas relacionados con VDSL en las tarjetas de interfaz WAN de alta velocidad (EHWIC) mejoradas de las series 880, 890, 860 y VDSL/Asynchronous Digital Subscriber Line (ADSL) de Cisco. Este documento es muy específico para el servicio VDSL, aunque puede tener servicio ADSL o VDSL en los routers y módulos mencionados anteriormente. 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) del ISP
• Capa 2.1: conectividad de extremo a extremo Ethernet
• Capa 2.2: protocolo de punto a punto sobre Ethernet (PPPoE), IP sobre Ethernet (IPoE), puente RFC1483 o routing RFC1483
• Capa 3 - IP

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.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

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 su ISP un DSLAM que admita el chipset Broadcom?

Verifique la información del ISP. Verifique la interoperabilidad DSLAM para el modelo o tarjeta del router que se refiere a la hoja de datos.

¿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á conectado a la toma de pared DSL, conecte el puerto a la pared con un cable RJ-11 directo. Este es un cable telefónico estándar. Las líneas VDSL utilizan los pines 3 y 4.

¿Cuál es el estado del controlador, el modo de funcionamiento y el modo de cobertura de transmisión (TC)?

Vea este ejemplo de salida:

Router#show controller vdsl 0/1/0

!--- Make sure the controller is in UP state. In case you see it in down state,
 it indicates a Layer 1 issue (Hardware issue, Line issue, Interoperability
 issue with DSLAM etc.)

Controller VDSL 0/1/0 is UP

Daemon Status:         Up 

!--- XTU-R and XTU-C shows local (Cisco Router) and remote (DSLAM) DSL related
 details like chipset vendor, Vendor ID etc.

                        XTU-R (DS)        XTU-C (US)
Chip Vendor ID:        'BDCM'             'BDCM'
Chip Vendor Specific:   0x0000             0xA1AA
Chip Vendor Country:    0xB500             0xB500
Modem Vendor ID:        'CSCO'             '    '
Modem Vendor Specific:  0x4602             0x0000
Modem Vendor Country:   0xB500             0x0000
Serial Number Near:     FOC15163V2Q 2911/K9 15.5(1)T
Serial Number Far:     
Modem Version Near:     15.5(1)T
Modem Version Far:      0xa1aa

Modem Status:         TC Sync (Showtime!) 

!--- Below shows the configured DSL operating mode, trained mode and TC mode.

DSL Config Mode:     AUTO 
Trained Mode:        G.993.2 (VDSL2) Profile 17a
TC Mode:             PTM 
Selftest Result:     0x00 
DELT configuration:  disabled 
DELT state:          not running 

Full inits:          1
Failed full inits:   0
Short inits:         0
Failed short inits:  0

!--- DSL firmware related details 

Firmware    Source        File Name 
--------    ------        ----------
VDSL        embedded       VDSL_LINUX_DEV_01212008

Modem FW  Version:    130205_1433-4.02L.03.B2pvC035j.d23j
Modem PHY Version:    B2pvC035j.d23j
Trellis:         ON              ON
SRA:              disabled         disabled
 SRA count:          0             0
Bit swap:          enabled         enabled
 Bit swap count:     0             0
!--- Attenuation and Noise margin are two important parameters which points to
 the line quality and intern the stability of the DSL connection
Line Attenuation:        0.0 dB          0.0 dB
Signal Attenuation:      0.0 dB          0.0 dB
Noise Margin:           11.1 dB          6.0 dB
Attainable Rate:       40440 kbits/s    3280 kbits/s
Actual Power:           14.5 dBm          4.9 dBm
Per Band Status:        D1      D2      D3      U0     U1     U2     U3
Line Attenuation(dB):   20.0    48.3    73.7    9.4    37.9   56.2   N/A    
Signal Attenuation(dB): 20.0    48.3    N/A    10.2    36.2   53.3   N/A    
Noise Margin(dB):       10.9    11.3    N/A     5.9    6.0    6.0    N/A    
Total FECC:        97252         0
Total ES:          7             0
Total SES:         0             0
Total LOSS:        0             0
Total UAS:        24             24
Total LPRS:        0             0
Total LOFS:        0             0
Total LOLS:        0             0

!--- DSL trained speed can be found below

DSChannel1   DSChannel0    US Channel1   US Channel0
Speed (kbps):              0           25087             0            3192
SRA Previous Speed:        0               0             0               0
Previous Speed:            0               0             0               0
Reed-Solomon EC:           0           97252             0               0
CRC Errors:                0              15             0               0
Header Errors:             0              62             0               0
Interleave (ms):        0.00            8.00          0.00            8.00
Actual INP:             0.00            3.01          0.00            2.00

Training Log :    Stopped
Training Log Filename :    flash:vdsllog.bin

Router#

Verifique esto en el resultado del comando show controller:

• El estado del controlador es "UP". Si se encuentra en el estado "Abajo", indica un problema de Capa 1 (problema de hardware, problema de línea o problema de interoperabilidad con DSLAM). Continúe con la resolución de problemas de Capa 1 en este caso.
• Verifique el modo de funcionamiento, el modo entrenado y el modo TC. Asegúrese de tener el modo de funcionamiento correcto configurado bajo el controlador. Cisco recomienda que utilice DSL Operating-mode auto si no está seguro de qué tecnología de tono múltiple discreto (DMT) utiliza el ISP. Estos son los comandos para configurar la autodetección del modo de funcionamiento:

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

  Observe el modo entrenado y asegúrese de tener el modo correcto negociado con el ISP. Otro parámetro importante que se debe observar es el modo TC. En caso de que el modo de formación sea VDSL2 o VDSL2+, el modo TC será Packet Transfer Mode (PTM). En este caso, debe ver la interfaz Ethernet PTM en el estado "up" y todos los parámetros de capa superior como PPP, IP, etc. deben configurarse bajo la interfaz Ethernet. Si el modo entrenado es ADSL, ADSL2 o ADSL2+, el modo TC debe ser ATM y todos los parámetros de capa superior deben configurarse bajo el Circuito virtual permanente (PVC) ATM en este caso. Si cambia el modo de funcionamiento entre ADSL y VDSL, es posible que no necesite reiniciar el router para activar las interfaces Ethernet o ATM correspondientes.

Compruebe el margen de ruido y la atenuación. El margen de ruido es la potencia relativa de la relación señal/ruido DSL. Cuanto mayor sea el número, mejor será la medición:

• 6dB o inferior es malo y no experimentará problemas de sincronización o sincronización intermitente
• 7 dB-10 dB es justo, pero no deja mucho espacio para diferencias en las condiciones
• 11dB-20dB es bueno con pocos problemas de sincronización o ninguno
• 20dB-28dB es excelente
• 29 dB o superior sobresaliente

La atenuación es una medida de cuánto se ha degradado la señal entre el DSLAM y el módem. Esto se debe en gran medida a la distancia que separa el intercambio. Cuanto más bajo sea el dB, mejor será para esta medición.

• 20 dB y menos están pendientes
• 20dB-30dB es excelente
• 30dB-40dB es muy bueno
• 40 dB-50 dB es bueno
• 50 dB-60 dB es deficiente y podría experimentar problemas de conectividad
• 60 dB o superior son inadecuados y tendrán problemas de conectividad

Asegúrese de tener una de las versiones más recientes del firmware VDSL. El firmware más reciente soluciona la mayoría de los problemas de interoperabilidad conocidos. Puede descargar el firmware más reciente de CCO.

Verifique que el DSL esté sincronizado con las velocidades de flujo ascendente y descendente adecuadas.

¿Tiene el modelo de router correcto?

Tenga en cuenta que los routers ADSL/VDSL vienen en dos versiones; 1) DSL sobre servicio telefónico sencillo antiguo (anexo A) y 2) DSL sobre red digital de servicios integrados (anexo B). En algunos países, los proveedores de servicios de Internet proporcionan una conexión del anexo B, mientras que en la mayoría de los demás es del anexo A. Un router o tarjeta DSL del Anexo A no se sincronizará con una línea del Anexo B y viceversa. Por lo tanto, debe asegurarse de que dispone del modelo de router adecuado. Consulte la hoja de datos del router para obtener más información.

¿Se ha probado/suministrado correctamente el circuito?

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

Problemas de Capa 2

¿Está activa la Ethernet PTM?

Una vez verificado que el modo entrenado es VDSL, asegúrese de que la interfaz Ethernet esté en el estado "activo".

Router#show ip interface brief

Interface                  IP-Address      OK? Method Status                Protocol
Embedded-Service-Engine0/0 unassigned      YES NVRAM  administratively down down    
GigabitEthernet0/0         unassigned      YES NVRAM  up                    up      
GigabitEthernet0/0.1       unassigned      YES unset  up                    up           
GigabitEthernet0/1         unassigned      YES NVRAM  administratively down down    
GigabitEthernet0/2         192.168.22.1    YES NVRAM  up                    up      
ISM0/1                     unassigned      YES unset  up                    up      
ATM0/1/0                   unassigned      YES NVRAM  administratively down down    
!--- Verify that the Ethernet interface is in up state
Ethernet0/1/0              unassigned      YES NVRAM  up                    up

¿El proveedor espera tráfico etiquetado? En caso afirmativo, ¿qué es el identificador de LAN virtual (ID de VLAN)?

La mayoría de los proveedores esperan tráfico etiquetado desde el equipo de las instalaciones del cliente (CPE). Puede configurar el etiquetado de VLAN como se muestra aquí después de obtener el ID de VLAN del ISP.

Router(config)#interface Ethernet0.835

Router(config-subif)#encapsulation dot1Q 835

Router(config-subif)#end

Router#

¿Se ha completado la entrada del protocolo de resolución de direcciones (ARP)?

Determine si la dirección MAC del mando a distancia está en la salida del comando show arp.

¿Recibe datos del ISP?

Si tiene el ID de VLAN correcto, el siguiente paso es verificar el intento de negociar el protocolo punto a punto (PPP) con el ISP. Para hacer esto, ingrese el comando show interface Ethernet0 y verifique los paquetes de entrada y salida.

Router#show interface ethernet0

Ethernet0/1/0 is up, line protocol is up 
  Hardware is VDSL_ETHERNET, address is 30f7.0d7e.3408 (bia 30f7.0d7e.3408)
  MTU 1500 bytes, BW 3261 Kbit/sec, DLY 3000 usec, 
     reliability 255/255, txload 19/255, rxload 1/255
  Encapsulation 802.1Q Virtual LAN, Vlan ID  1., loopback not set
  Keepalive set (10 sec)
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:19, output 00:00:00, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/1024 (size/max)
  5 minute input rate 23000 bits/sec, 19 packets/sec
  5 minute output rate 244000 bits/sec, 29 packets/sec
     3096276 packets input, 3672318911 bytes, 0 no buffer
     Received 0 broadcasts (1517324 IP multicasts)
     0 runts, 0 giants, 1 throttles 
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     1287646 packets output, 240862302 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     1 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out


Router#show controller vdsl 0 datapath
ptm0            Link encap:Ethernet  HWaddr 02:10:18:01:00:02  
                UP BROADCAST RUNNING MULTICAST  MTU:1600  Metric:1
                RX packets:3111732 errors:0 dropped:0 overruns:0 frame:0
                TX packets:1311107 errors:0 dropped:0 overruns:0 carrier:0
                collisions:0 txqueuelen:1000 
                RX bytes:3677814427 (3.4 GiB)  TX bytes:265796876 (253.4 MiB)

atm/ptm interface statistics for port 0
in octets                   4983267
out octets                  27636440
in packets                  16376
out packets                 26024
in OAM cells                0
out OAM cells               0
in ASM cells                0
out ASM cells               0
in packet errors            0
in cell errors              0

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

Si los contadores de salida enlazados aumentan, debe enviar paquetes de negociación PPP. 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 Ethernet0.

¿El PPP negocia correctamente?

Si la Capa 1 está activa y tiene el ID de VLAN correcto, el siguiente paso es asegurarse de que PPP se active correctamente. Para lograr esto, necesita ejecutar una serie de comandos debug en el router DSL de Cisco e interpretar el resultado. El comando debug primario que utiliza es debug ppp negotiation. Este resultado del comando es un ejemplo de 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 10.10.10.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 10.10.10.1 (0x030614140201)
2w3d: Vi1 IPCP: O CONFACK [REQsent] id 4 Len 10
2w3d: Vi1 IPCP: Address 10.10.10.1 (0x030614140201)
2w3d: Vi1 IPCP: I CONFNAK [ACKsent] id 7 Len 10
2w3d: Vi1 IPCP: Address 10.1.1.1 (0x030628010102)
2w3d: Vi1 IPCP: O CONFREQ [ACKsent] id 8 Len 10
2w3d: Vi1 IPCP: Address 10.1.1.1 (0x030628010102)
2w3d: Vi1 IPCP: I CONFACK [ACKsent] id 8 Len 10
2w3d: Vi1 IPCP: Address 10.1.1.1 (0x030628010102)
2w3d: Vi1 IPCP: State is Open
2w3d: Di1 IPCP: Install negotiated IP interface address 10.1.1.1
2w3d: Di1 IPCP: Install route to 10.10.10.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

Si su ISP no responde, esto no debería ser un problema ya que ya verificó que los paquetes aumentan en la interfaz Ethernet0 en la dirección entrante. Sin embargo, si los paquetes se incrementan en Ethernet0 en la dirección entrante, y usted recibe esto cuando ejecuta debug ppp negotiation, comuníquese 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 aumentan de entrada, pero no ve paquetes I, comuníquese con su ISP para verificar los paquetes que se envían al router DSL de Cisco.

LCP no abierto

Si el LCP no está abierto, esto suele deberse a una discordancia en las opciones PPP. Esta discordancia se produce cuando el router DSL de Cisco tiene un parámetro PPP configurado que el ISP no admite o cuando el ISP tiene un parámetro configurado que el router DSL de Cisco no admite. 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

Ya sea un paquete de E o S, un Configure-Negative-Acknowledge (CONFNAK) indica una discordancia de configuración PPP. Esto significa que un lado de la conexión PPP solicita 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 (indicada por "I CONFNAK"), ha configurado una opción en el router DSL de Cisco que el ISP no desea realizar.

La línea después de CONFNAK describe la opción que se rechaza. En este resultado de ejemplo, la opción es Protocolo de autenticación por desafío mutuo (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. Ingrese 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 el ISP. En el caso de que el router envíe paquetes, es posible que deba llamar al Soporte 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 CHAP (Password Authentication Protocol, protocolo de autenticación de contraseña) 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 negotiation como este ejemplo:

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

Para corregir ambos problemas de discordancia de autenticación, necesita reconfigurar el protocolo de autenticación al solicitado por el ISP en el paquete CONFREQ entrante.

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

Después de haber confirmado que su ISP utiliza PAP, ingrese 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]

Debe ponerse en contacto con el ISP y obtener las credenciales correctas para corregir esto. Puede reconfigurar las credenciales PAP con estos comandos:

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 <username> password <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, ingrese 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

Debe ponerse en contacto con el ISP y obtener las credenciales correctas para corregir esto. Puede reconfigurar las credenciales CHAP con estos comandos:

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface dialer 1
Router(config-if)#ppp chap hostname <username> 
Router(config-if)#ppp chap password <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
This example shows a successful PAP negotiation.
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

Problemas de rendimiento sobre PPPoE

Esta sección es específica para las conexiones PPPoE. Se espera ver problemas con el rendimiento, la navegación lenta, etc. con las conexiones PPPoE cuando se utiliza el tamaño predeterminado de la unidad máxima de transmisión (MTU) en la interfaz del marcador. Debe establecer la MTU en el marcador PPPoE en 1492 para tener en cuenta los ocho bytes utilizados por el encabezado PPPoE. Ingrese estos comandos para configurar la MTU adecuada:

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface dialer 1
Router(config-if)#mtu 1492