Ethernet de largo alcance (LRE) y Línea de suscriptor digital (xDSL) : Línea de suscriptor digital asimétrica (ADSL)

Guía de Configuración y Troubleshooting del Cisco DSL Router - El resolver problemas del PPPoA

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


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.

  • Layer 1 – Conectividad física DSL a su Digital Subscriber Line Access Multiplexer ISP (DSLAM)

  • 2.1 de la capa – Conectividad ATM

  • Capa 2.2 – Protocolo Point-to-Point sobre la atmósfera (PPPoA), el Point-to-Point Protocol over Ethernet (PPPoE), RFC1483 que interliga, o el rutear del RFC1483

  • Capa 3 – IP

La manera más fácil de determinar que le acodan debe comenzar a resolver problemas es publicar el comando show ip interface brief. La salida de este comando diferencia dbased levemente en su 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 estatuses del ATM0 y del ATM0.1 son ascendentes y el protocolo está para arriba, comience a resolver problemas en la capa 2.

Si las interfaces ATM están abajo, o si continúan subiendo y después yendo abajo (ellos no permanecen para arriba y suben), comience a resolver problemas en el Layer 1.

prerrequisitos

Requisitos

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 del Layer 1

¿Es la luz del Carrier Detect (CD) en el panel frontal del router DLS de Cisco con./desc.?

Si la luz CD está prendido, vaya a la sección de los problemas de la capa 2 de este documento.

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

¿Es su ISP usando un DSLAM que soporte chip Alcatel?

Verifique esta información con su ISP.

¿El puerto DSL en la parte de atrás del router DLS de Cisco está conectado en el conector de pared DSL?

Si el puerto DSL no está conectado en el conector de pared DSL, conecte el puerto con la pared con un cable 4-pin o 6-pin RJ-11. Esto es un cable de teléfono estándar.

¿Es la interfaz ATM en administrativo un estado inactivo?

Publique este comando en el enable mode en el router para determinar si la interfaz ATM0 está administrativo abajo:

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

Si el estatus de la interfaz ATM0 está administrativo abajo, publique el comando no shutdown bajo 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

¿Está la configuración de clavijas del cable correcta?

Si el estatus de la interfaz ATM0 está abajo y abajo, el router no ve un portador en la línea ADSL. Esto indica generalmente uno de dos problemas:

  • Los contactos activos en el conector de pared DSL son incorrectos.

  • Su ISP no ha dado vuelta encima de un servicio DSL en este conector de pared.

Distribuciones de clavijas del puerto del router DLS de Cisco xDSL

El conector RJ-11 proporciona una conexión xDSL a los medios externos vía un conector modular estándar RJ-11 6-pin.

Pin Descripción
3 XDSL_Tip
4 XDSL_Ring

Nota: El Cisco 1417 utiliza los contactos 2 y 5 en un conector modular estándar RJ-11 6-pin.

Para determinar si la interfaz ATM0 está abajo y abajo, publique el comando show interface atm 0 del enable mode del router:

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

Si la interfaz ATM está abajo y abajo — no no administrativo abajo — marque el pinout de su conector de pared DSL. El router DLS utiliza (4-pin o 6-pin) un cable estándar RJ-11 para proporcionar la conexión ADSL al conector de pared. Los pares de centro de contactos en el cable RJ-11 se utilizan para llevar la señal de ADSL (contactos 3 y 4 en un cable 6-pin, o los contactos 2 y 3 en un cable del pin 4). El no se aplica al Cisco 1417 que utiliza los contactos 2 y 5.

Si usted está seguro que usted tiene los contactos derechos en el conector de pared y la interfaz ATM0 todavía está abajo y abajo, substituya el cable RJ-11 entre el puerto DSL y su conector de pared. Si la interfaz todavía está abajo y abajo después de que usted substituya el cable RJ-11, entre en contacto su ISP y haga que el ISP verifique que han habilitado al servicio ADSL en el conector de pared que usted utiliza.

Si usted no está seguro qué contactos en su conector de pared son activos, pida su ISP.

¿Si usted está utilizando un Cisco 827 como su DSL Customer Premises Equipment (CPE), usted tiene la fuente de alimentación correcta para el Cisco 827?

Si usted ha verificado que su cable DSL es bueno y que usted tiene las configuraciones del cable correctas, el siguiente paso es aseegurarse le tener la fuente de alimentación correcta para los 827.

Nota: Los 827 no utiliza la misma fuente de alimentación que otros Cisco 800 Series Router.

Para determinar si usted tiene la fuente de alimentación correcta, en la parte de atrás del adaptador de energía busque la salida +12V 0.1A, -12V 0.1A, +5V 3A, -24V 0.12A, y -71V 0.12A. Si su fuente de alimentación está faltando el +12V y el -12V alimenta, después está para un diverso Cisco 800 Series Router y no trabaja en los 827. Observe que si usted utiliza la fuente de alimentación incorrecta, el Cisco 827 acciona para arriba pero no puede entrenar para arriba (conecte) al ISP DSLAM.

¿Está el modo de operación DSL correcto?

Si todo hasta esta punta en el procedimiento deTroubleshooting del Layer 1 está correcto, el siguiente paso es aseegurarse le tener el modo de operación correcto DSL. Cisco recomienda usando el auto del modo de operación dsl si usted no está seguro qué tecnología DMT su ISP utiliza. Éstos son los comandos de configurar el autodetection del modo de operación:

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

¿Es el circuito probado/aprovisionado correctamente?

Obtenga esta información de su ISP o compañía telefónica.

Acode 2 problemas

¿Usted tiene los valores correctos del circuito virtual permanente (PVC) (VPI/VCI)?

Complete estos pasos para determinar si usted tiene los valores /virtual del Identificador de circuito del identificador de trayecto virtual correcto (VPI/VCI) configurados en el router.

  1. Verifique su versión del software del ½ del ¿Â de Cisco IOSïÂ.

    Importante: Esto no trabaja con el Cisco IOS Software Release 12.1(1)XB.

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

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

    Router#debug atm events 
    ATM events debugging is on
    Router#
    2d18h:
    2d18h: RX interrupt: conid = 0, rxBd = 0x80C7EF74 length=52
    2d18h: Data Cell received on vpi = 8 vci = 35
    
    !--- Your VPI/VCI.
    
    2d18h:
    2d18h: RX interrupt: conid = 0, rxBd = 0x80C7EEC0 length=52
    2d18h: Data Cell received on vpi = 8 vci = 35
    2d18h:
    2d18h: RX interrupt: conid = 0, rxBd = 0x80C7EECC length=52
    2d18h: Data Cell received on vpi = 8 vci = 35
    2d18h:
    2d18h: RX interrupt: conid = 0, rxBd = 0x80C7EED8 length=52
    2d18h: Data Cell received on vpi = 8 vci = 35
  4. Aseegurese le tener eventos atmósfera del debug que se ejecutan en el router DLS de Cisco, y entonces vaya a una conexión de Internet de trabajo y comience a hacer ping la dirección IP su ISP asignado estáticamente a usted.

    No importa si usted haya configurado esta dirección IP en el router DLS de Cisco. Cuál es importante es que su interfaz ATM es up/up y que usted está haciendo ping la dirección IP su ISP le dio. Si usted no ve el resultado esperado después de la prueba de ping, entre en contacto su ISP para el soporte.

  5. Inhabilite el debugging en el router.

    << espere 60 segundos >>

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

    Verifique sus valores del VPI/VCI, y después realice los cambios necesarios a su configuración.

    Si usted no ve la salida durante los 60 segundos del debugging, entre en contacto su ISP.

¿Usted está recibiendo los datos de su ISP?

Si usted tiene los valores correctos PVC, el siguiente paso es verificar que usted está intentando negociar el PPP con su ISP. Para hacer esto, publique el comando show interface atm0 y marque los paquetes de entrada y de 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 están incrementando, usted debe recibir los Paquetes de negociación PPP de su ISP. En caso contrario, llame su ISP.

Si los contadores encuadernados de la salida están incrementando, usted debe enviar los Paquetes de negociación PPP. En caso contrario, marque la configuración en el router. Si el PPP se configura correctamente, los Paquetes de negociación PPP continuamente se envían la interfaz ATM0.

Si los paquetes están incrementando en las ambas direcciones, continúe con los pasos de Troubleshooting en este documento.

¿El PPP está negociando correctamente?

Si el Layer 1 es ascendente y usted tiene el VPI/VCI correcto, el siguiente paso es aseegurarse el PPP sube correctamente. Para lograr esto, usted necesita funcionar con a una serie de comandos debug en el router DLS de Cisco e interpretar la salida. El debug primario que usted utiliza es negociación ppp del debug. Esta salida de comando es un ejemplo de una negociación PPP satisfactoria:

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 error en una negociación PPP:

  • Ninguna respuesta del dispositivo remoto (su ISP)

  • (LCP) del Link Control Protocol no abierto

  • Falla de autenticación

  • Error del IP Control Protocol (IPCP)

Ninguna respuesta de su ISP

Su ISP que no responde no debe ser un problema puesto que usted verificó ya que los paquetes estén incrementando en la interfaz ATM0 en la dirección entrante. Sin embargo, si usted ve los paquetes el incrementar en el ATM0 en la dirección entrante, y cuando usted funciona con una negociación ppp del debug usted recibe esto, entre en contacto su ISP para verificar que los paquetes están enviados al router DLS 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 hay solamente los paquetes O, que son paquetes salientes. Para negociar con éxito el PPP, debe haber un paquete de entrada I de su ISP para cada paquete O enviado. Si los paquetes son el incrementar entrante pero usted no ve los paquetes I, entre en contacto su ISP para verificar los paquetes que se envían al router DLS de Cisco.

LCP no abierto

El LCP que no está abierto es causado generalmente por una discordancía en las opciones PPP. Esta discordancía ocurre cuando el router DLS de Cisco hace un parámetro PPP configurar que su ISP no soporta, o cuando su ISP tiene un parámetro configurado que el router DLS de Cisco no soporta. Esta salida muestra un ejemplo de una discordancía 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

Si es un I o un paquete O, un Configuración-Negativo-reconocimiento (CONFNAK) es indicativo de una discordancía de la configuración PPP. Cuáles estos los medios son ese un lado de la conexión PPP pregunta una opción PPP que el otro lado es incapaz o no configurado de realizarse. Si el router DLS de Cisco envía el CONFNAK (indicado por “O CONFNAK”), el router DLS de Cisco no puede realizarse o no configurado para la opción el ISP envía. Si el CONFNAK es enviado por su ISP (indicado por “ CONFNAK”), usted ha configurado una opción en el router DLS de Cisco que su ISP no está dispuesto a realizarse.

La línea después de que el CONFNAK describa la opción se rechaza que. En esta salida de ejemplo, la opción es Challenge Handshake Authentication Protocol (CHAP) pero podría ser cualquier opción. El único lugar en el router DLS de Cisco en donde las opciones PPP pueden ser configuradas es problema del marcador 1. de la interfaz el interface dialer 1 del comando show run para ver su configuración del interface dialer 1.

Si su ISP envía el I CONFNAK, busque los comandos bajo interface dialer 1 que hacen juego la línea después del CONFNAK y los quitan. Si el router DLS de Cisco envía el O CONFNAK, agregue un comando al interface dialer 1 de negociar correctamente el PPP con su ISP. En el caso del router que enviaba los paquetes, usted puede ser que necesite llamar el soporte de Cisco para determinar que los comandos necesitan ser habilitados en el router DLS de Cisco.

Falla de autenticación

Una falla de autenticación ocurre cuando su ISP no puede autenticar su nombre de usuario o la contraseña PPP. Hay dos escenarios en los cuales éste puede ocurrir. El primer escenario es una discordancía del tipo de autenticación, se causa que cuando usted no configura correctamente al router. Todas las configuraciones de autenticación enumeradas en este documento explican los tipos del protocolo password authentication (PAP) y de la autenticación CHAP. Para la flexibilidad de la configuración, usted debe hacer la GRIETA y el PAP configurar. Si usted no hace ambos configurar, usted puede ser que vea la salida de un comando debug ppp 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

O

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

!--- Receives CHAP requests from the service provider

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

!--- Sends out PAP requests

Router#undebug all

!--- Turns off ppp debug.

Para corregir ambos problemas de falta de coincidencia de la autenticación, refiera a la configuración apropiada de la opción de implementación del PPPoA y configure de nuevo la autenticación PPP.

El segundo escenario del problema de autenticación que usted puede encontrar es un nombre de usuario PAP o una contraseña incorrecto. Para determinar si éste es el problema, publique el comando debug ppp negotiation. Con la suposición que configuran a su router para la GRIETA y el PAP, como la configuración delineada anterior en esta guía muestra, su ISP no pudo utilizar la autenticación PAP.

Para determinar la autenticación usada por su ISP, marque las opciones en el paquete I CONFREQ enviado a usted de su ISP. Si este paquete es seguido por una opción llamada AuthProto PAP, usted está utilizando el PAP. ¿Si el I CONFREQ es seguido por una opción llamada AuthProto CHAP, usted está utilizando la GRIETA y debe proceder a cómo sé si mi nombre de usuario y contraseña de la GRIETA está correcto?

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

Después de que usted haya confirmado que su ISP utiliza el PAP, publique el comando debug ppp negotiation para confirmar que su nombre de usuario PAP y contraseña están 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 usted tiene un problema de la autenticación PAP, usted debe ver el estado LCP ir a abierto. Directamente siguiendo el cambio de estado LCP usted debe ver el PPP entrar una fase de autenticidad. Si una de las dos líneas siguientes contiene I AUTH-NAK, su nombre de usuario PAP o la contraseña PAP es incorrecta. En este momento, usted necesita configurar de nuevo su nombre de usuario PAP y contraseña usando esta secuencia de comandos. Observe que su nombre de usuario PAP y contraseña son con diferenciación 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 <username> password <password>
Router(config-if)#end
Router#write memory

¿Cómo sé si mi nombre de usuario y contraseña de la GRIETA está correcto?

Después de que usted haya confirmado que su GRIETA de las aplicaciones ISP, publica el comando debug ppp negotiation para confirmar que su nombre de usuario y contraseña de la GRIETA está correcto.

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 usted tiene un problema de la autenticación CHAP, usted debe ver el estado LCP ir a abierto. Directamente siguiendo el cambio de estado LCP usted debe ver el PPP entrar una fase de autenticidad. De esta punta usted ve una serie de líneas de la GRIETA. Si el último de estas líneas muestra el ERROR I, usted tiene el nombre de usuario y contraseña incorrecto de la GRIETA. Utilice esta secuencia de comandos para corregir su nombre de usuario y contraseña de la GRIETA. Observe que su nombre de usuario y contraseña es con diferenciación 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 <username> 
Router(config-if)#ppp chap password <password>
Router(config-if)#end
Router#write memory

¿Cómo sé cuando la autenticación PPP es acertada?

El ejemplo de Theis muestra una negociación acertada de la GRIETA.

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 acertada PAP.

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

Información Relacionada


Document ID: 71115