Guida alla configurazione e alla risoluzione dei problemi del router Cisco DSL - Risoluzione dei problemi PPPoA

Introduzione

I motivi per cui la connessione DSL (Digital Subscriber Line) potrebbe non funzionare correttamente sono numerosi. Lo scopo di questo documento è isolare la causa del guasto e ripararla. Il primo passaggio della procedura di risoluzione dei problemi consiste nel determinare il livello di errore del servizio ADSL (Asynchronous Digital Subscriber Line). L'errore può verificarsi su tre livelli.

• Layer 1 - Connettività fisica DSL al DSLAM (Digital Subscriber Line Access Multiplexer) dell'ISP

• Layer 2.1 - Connettività ATM

• Layer 2.2 - Protocollo PPPoA (Point-to-Point over ATM), PPPoE (Point-to-Point over Ethernet), Bridging RFC1483 o routing RFC1483

• Layer 3 - IP

Il modo più semplice per determinare il livello da cui iniziare a risolvere i problemi è tramite il comando show ip interface brief. L'output di questo comando varia leggermente in base alla configurazione.

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 lo stato di ATM0 e ATM0.1 è attivo e il protocollo è attivo, iniziare la risoluzione dei problemi sul layer 2.

Se le interfacce ATM non sono attive o se continuano a spostarsi verso l'alto o verso il basso (non sono attive o attive), iniziare la risoluzione dei problemi al layer 1.

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Problemi del Layer 1

Sul pannello anteriore del router Cisco DSL, la spia di rilevamento della portante (CD) è accesa o spenta?

Se la spia CD è accesa, andare alla sezione Problemi del Layer 2 in questo documento.

Se la spia CD è spenta, continuare alla domanda successiva.

L'ISP utilizza un DSLAM che supporta il chipset Alcatel?

Verificare queste informazioni con l'ISP.

La porta DSL sul retro del router Cisco DSL è collegata al connettore jack a parete DSL?

Se la porta DSL non è collegata alla presa a parete DSL, collegarla alla parete con un cavo RJ-11 a 4 o 6 pin. ossia un comune cavo telefonico.

L'interfaccia ATM è nello stato disattivato a livello amministrativo?

Per determinare se l'interfaccia ATM0 è disattivata a livello amministrativo, usare questo comando in modalità di abilitazione sul router:

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

Se lo stato dell'interfaccia ATM0 è disattivato a livello amministrativo, usare il comando no shutdown nell'interfaccia 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

Il pin-out del cavo è corretto?

Se lo stato dell'interfaccia ATM0 è inattivo e inattivo, il router non rileva un vettore sulla linea ADSL. Ciò indica in genere uno dei due problemi seguenti:

• I pin attivi sulla presa a parete DSL non sono corretti.

• L'ISP non ha attivato un servizio DSL su questa presa a muro.

Pinout porta xDSL router Cisco DSL

Il connettore RJ-11 fornisce una connessione xDSL a supporti esterni tramite un jack modulare standard RJ-11 a 6 pin.

Pin	Descrizione
3	Suggerimento_XDSL
4	XDSL_Ring

Nota: Cisco 1417 utilizza i pin 2 e 5 su un jack modulare RJ-11 a 6 pin standard.

Per determinare se l'interfaccia ATM0 è inattiva e inattiva, usare il comando show interface atm 0 dalla modalità di abilitazione del router:

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

Se l'interfaccia ATM è inattiva e inattiva (non amministrativamente inattiva), controllare il pin out della presa a parete DSL. Il router DSL utilizza un cavo standard RJ-11 (4 pin o 6 pin) per fornire la connessione ADSL al jack a parete. La coppia di pin centrale del cavo RJ-11 viene utilizzata per trasportare il segnale ADSL (pin 3 e 4 su un cavo a 6 pin, pin 2 e 3 su un cavo a 4 pin). Ciò non è valido per lo switch Cisco 1417 che utilizza i pin 2 e 5.

Se si è certi di avere i pin corretti sul connettore a parete e l'interfaccia ATM0 è ancora abbassata, sostituire il cavo RJ-11 tra la porta DSL e il connettore a parete. Se l'interfaccia rimane inattiva dopo la sostituzione del cavo RJ-11, contattare l'ISP e verificare che il servizio ADSL sia stato attivato sulla presa a muro utilizzata.

Se non si è certi dei pin attivi sulla presa a muro, rivolgersi all'ISP.

Se si utilizza un Cisco 827 come DSL Customer Premises Equipment (CPE), si dispone dell'alimentatore corretto per il Cisco 827?

Se si è verificato che il cavo DSL sia valido e che si disponga dei pin corretti, il passaggio successivo consiste nel verificare di disporre dell'alimentatore corretto per lo switch 827.

Nota: lo switch 827 non usa lo stesso alimentatore degli altri router Cisco serie 800.

Per determinare se si dispone dell'alimentatore corretto, sul retro dell'adattatore di alimentazione cercare Uscita +12V 0.1A, -12V 0.1A, +5V 3A, -24V 0.12A e -71V 0.12A. Se l'alimentatore non riceve alimentazione da +12V e -12V, è per un router Cisco serie 800 diverso e non funziona sul router 827. Se si usa l'alimentatore sbagliato, il Cisco 827 si accende ma non è in grado di addestrarsi (collegarsi) al DSLAM ISP.

La modalità operativa DSL è corretta?

Se tutto ciò che è stato fatto fino a questo punto nella procedura di risoluzione dei problemi del layer 1 è corretto, il passaggio successivo consiste nel verificare che sia disponibile la modalità operativa DSL corretta. Cisco consiglia di utilizzare la modalità operativa dsl auto se non si è certi della tecnologia DMT utilizzata dall'ISP. Di seguito sono riportati i comandi per configurare il rilevamento automatico della modalità operativa:

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

Il test o il provisioning del circuito è stato eseguito correttamente?

Ottenere queste informazioni dall'ISP o dalla compagnia telefonica.

Problemi del Layer 2

Si dispone dei valori VPI/VCI (Permanent Virtual Circuit) corretti?

Completare questa procedura per determinare se i valori VPI/VCI (Virtual Path Identifier/Virtual Circuit Identifier) configurati sul router sono corretti.

1. Verificare la versione del software Cisco IOS® in uso.

   Importante: Questa procedura non è valida con il software Cisco IOS versione 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. Configurare il router per la registrazione del 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. Abilitare il debug sul 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. Verificare che gli eventi ATM di debug siano in esecuzione sul router DSL Cisco, quindi accedere a una connessione Internet funzionante e iniziare a eseguire il ping dell'indirizzo IP assegnato in modo statico dal provider di servizi Internet.

   Non importa se l'indirizzo IP è stato configurato sul router DSL Cisco. È importante che l'interfaccia ATM sia attiva/attiva e che venga eseguito il ping dell'indirizzo IP fornito dall'ISP. Se dopo il ping non viene visualizzato l'output previsto, contattare l'ISP per assistenza.

5. Disabilitare il debug sul router.

   << attendere 60 secondi >>

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

   Verificare i valori VPI/VCI, quindi apportare le modifiche necessarie alla configurazione.

   Se durante i 60 secondi di debug non viene visualizzato alcun output, contattare l'ISP.

Si ricevono dati dall'ISP?

Se si dispone dei valori PVC corretti, il passaggio successivo consiste nel verificare che si stia tentando di negoziare il protocollo PPP con l'ISP. A tal fine, usare il comando show interface atm0 e controllare i pacchetti di input e output.

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 i contatori dei pacchetti sono in aumento, è consigliabile ricevere i pacchetti di negoziazione PPP dall'ISP. In caso contrario, contattare l'ISP.

Se i contatori associati all'output aumentano, è consigliabile inviare pacchetti di negoziazione PPP. In caso contrario, controllare la configurazione sul router. Se il protocollo PPP è configurato correttamente, i pacchetti di negoziazione PPP vengono inviati continuamente all'interfaccia ATM0.

Se i pacchetti aumentano in entrambe le direzioni, continuare con la procedura di risoluzione dei problemi descritta in questo documento.

Il PPP sta negoziando correttamente?

Se il layer 1 è attivo e si dispone del VPI/VCI corretto, il passaggio successivo è verificare che il protocollo PPP venga attivato correttamente. A tale scopo, eseguire una serie di comandi di debug sul Cisco DSL Router e interpretare l'output. Il debug principale utilizzato è la negoziazione PPP di debug. Questo output del comando è un esempio di negoziazione PPP riuscita:

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#

Una negoziazione PPP può non andare a buon fine per quattro motivi principali:

• Nessuna risposta dal dispositivo remoto (ISP)

• Mancata apertura del protocollo LCP (Link Control Protocol)

• Errore di autenticazione

• Errore del protocollo IPCP (IP Control Protocol)

Nessuna risposta dall'ISP

La mancata risposta dell'ISP non deve essere un problema, in quanto è stato già verificato che i pacchetti aumentano sull'interfaccia ATM0 in direzione in ingresso. Tuttavia, se si rilevano incrementi dei pacchetti su ATM0 nella direzione in entrata e quando si esegue una negoziazione PPP di debug si riceve questo messaggio, contattare l'ISP per verificare che i pacchetti siano inviati al router DSL 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

In questo output sono presenti solo pacchetti O, ossia pacchetti in uscita. Per la corretta negoziazione del protocollo PPP, deve essere presente un pacchetto I in entrata proveniente dall'ISP per ciascun pacchetto O inviato. Se i pacchetti in entrata aumentano ma non vengono visualizzati, contattare l'ISP per verificare i pacchetti inviati al router DSL Cisco.

Mancata attivazione del protocollo LCP

La mancata apertura di LCP è in genere causata da una mancata corrispondenza nelle opzioni PPP. Questa mancata corrispondenza si verifica quando il Cisco DSL Router ha un parametro PPP configurato non supportato dall'ISP o quando l'ISP ha un parametro configurato che non è supportato dal Cisco DSL Router. Questo output mostra un esempio di mancata corrispondenza dell'opzione 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

Il messaggio CONFNAK (Configure-Negative-Acknowledge) indica una mancata corrispondenza del protocollo PPP e può fare riferimento a un pacchetto I o a un pacchetto O. CONFNAK segnala che un lato della connessione PPP chiede un'opzione PPP che l'altro lato non è in grado di eseguire o non è stato configurato per eseguire. Se il router DSL Cisco invia il comando CONNAK (indicato da "O CONNAK"), non sarà possibile eseguire o configurare il router DSL Cisco per l'opzione inviata dall'ISP. Se la chiave CONFNAK viene inviata dall'ISP (indicato da "I CONFNAK"), è stata configurata un'opzione sul router DSL Cisco che l'ISP non è disposto a eseguire.

La riga che segue il messaggio CONFNAK descrive l'opzione rifiutata. In questo output di esempio, l'opzione è CHAP (Challenge Handshake Authentication Protocol), ma potrebbe essere un'opzione qualsiasi. L'unico punto del router DSL Cisco in cui è possibile configurare le opzioni PPP è l'interfaccia dialer 1. Per visualizzare la configurazione dell'interfaccia dialer 1, eseguire il comando show run interface dialer 1.

Se l'ISP invia il messaggio I CONFNAK, individuare l'opzione rifiutata nella riga successiva e cercare i comandi corrispondenti nell'interfaccia dialer 1, quindi rimuoverli. Se il router DSL Cisco invia il comando O CONNAK, aggiungere un comando all'interfaccia di connessione 1 per negoziare correttamente il protocollo PPP con l'ISP. Nel caso in cui il router invii pacchetti, potrebbe essere necessario chiamare il supporto Cisco per determinare i comandi da abilitare sul router DSL Cisco.

Errore di autenticazione

L'errore di autenticazione si verifica quando l'ISP non è in grado di autenticare il nome utente o la password PPP. L'errore può verificarsi in due scenari. Il primo scenario è una mancata corrispondenza del tipo di autenticazione, che si verifica quando il router non è configurato correttamente. Tutte le configurazioni di autenticazione elencate in questo documento rappresentano i tipi di autenticazione Password Authentication Protocol (PAP) e CHAP. Per assicurare una configurazione flessibile, è necessario configurare sia il protocollo CHAP sia il protocollo PAP. Se non sono stati configurati entrambi, è possibile che venga visualizzato l'output di un comando debug ppp, come nell'esempio seguente:

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.

Per risolvere entrambi i problemi di mancata corrispondenza dell'autenticazione, fare riferimento alla configurazione dell'opzione di implementazione PPPoA appropriata e riconfigurare l'autenticazione PPP.

Il secondo scenario del problema di autenticazione che si può verificare è un nome utente o una password PAP errati. Per determinare se la causa è questo, usare il comando debug ppp negotiation. Supponendo che il router sia configurato sia per la protezione CHAP che per PAP, come mostrato nella configurazione descritta in precedenza in questa guida, è possibile che l'ISP non stia utilizzando l'autenticazione PAP.

Per determinare l'autenticazione utilizzata dall'ISP, controllare le opzioni nel pacchetto I CONFREQ inviato dall'ISP. Se questo pacchetto è seguito da un'opzione chiamata AuthProto PAP, si sta utilizzando PAP. Se CONFREQ.I è seguito da un'opzione denominata AuthProto CHAP, si sta utilizzando la protezione CHAP e si consiglia di procedere alla sezione Come sapere se il nome utente e la password CHAP sono corretti?

Come posso sapere se il nome utente e la password del protocollo PAP sono corretti?

Dopo aver confermato che l'ISP utilizza il protocollo PAP, eseguire il comando debug ppp negotiation per verificare che il nome utente e la password del protocollo PAP siano corretti.

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 si verifica un problema di autenticazione PAP, lo stato LCP dovrebbe essere Aperto. Subito dopo la modifica dello stato LCP, il protocollo PPP dovrebbe entrare in una fase di autenticazione. Se una delle due righe successive contiene I AUTH-NAK, il nome utente PAP o la password PAP non sono corretti. A questo punto, è necessario riconfigurare il nome utente e la password PAP utilizzando questa sequenza di comandi. Il nome utente e la password PAP fanno distinzione tra maiuscole e minuscole.

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

Come posso sapere se il nome utente e la password del protocollo CHAP sono corretti?

Dopo aver confermato che l'ISP utilizza la protezione CHAP, eseguire il comando debug ppp negotiation per verificare che il nome utente e la password CHAP siano corretti.

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 si verifica un problema di autenticazione CHAP, lo stato LCP dovrebbe essere Aperto. Subito dopo la modifica dello stato LCP, il protocollo PPP dovrebbe entrare in una fase di autenticazione. Da questo punto viene visualizzata una serie di linee CHAP. Se l'ultima riga indica ERRORE, il nome utente e la password CHAP sono errati. Utilizzare questa sequenza di comandi per correggere il nome utente e la password CHAP. Il nome utente e la password fanno distinzione tra maiuscole e minuscole.

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

Come posso sapere quando l'autenticazione PPP è stata eseguita correttamente?

Nell'esempio viene mostrata una negoziazione CHAP riuscita.

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

Nell'esempio viene mostrata una negoziazione PAP riuscita.

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

Informazioni correlate

• Opzioni di implementazione PPPoA
• Guida alla configurazione e alla risoluzione dei problemi del router Cisco DSL
• Supporto ADSL
• Documentazione e supporto tecnico – Cisco Systems