Guida alla configurazione e risoluzione dei problemi dei router Cisco DSL - PPPoE: Router DSL come client PPPoE Risoluzione dei problemi

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 a seconda della 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à 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:

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

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

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 il collegamento ADSL al jack a parete. La coppia di pin centrale del cavo RJ-11 viene utilizzata per trasportare il segnale ADSL (i pin 3 e 4 su un cavo a 6 pin, o i pin 2 e 3 su un cavo a 4 pin).

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 e inattiva dopo la sostituzione del cavo RJ-11, contattare l'ISP e verificare che il servizio DSL sia stato attivato sulla presa a muro utilizzata.

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

Si dispone dell'alimentatore corretto per 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 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 alimenta i connettori +12V e -12V, è per un router Cisco serie 800 diverso e non funziona sul router 827. Se si utilizza un alimentatore errato, il Cisco 827 si accende ma non è in grado di effettuare la connessione al DSLAM dell'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 PVC corretti (VPI/VCI)?

Con un'implementazione PPPoE non è possibile individuare in modo dinamico i valori VPI/VCI (Virtual Path Identifier/Virtual Channel Identifier) del PVC (Permanent Virtual Circuit). Contattare l'ISP se non si è certi dei valori PVC.

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 di input sono in aumento, è consigliabile ricevere i pacchetti di negoziazione PPPoE dal provider di servizi Internet. In caso contrario, contattare l'ISP.

Se i contatori associati all'output sono in aumento, è consigliabile inviare pacchetti di negoziazione PPPoE. 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 solo nella direzione in uscita, continuare con la procedura di risoluzione dei problemi descritta in questo documento.

È in corso una sessione PPPoE?

Il protocollo PPPoE viene eseguito in due fasi. La prima fase è l'istituzione di sessioni PPPoE, la seconda fase è la negoziazione PPP. La PPPoE deve essere stabilita prima della negoziazione dei parametri PPP standard. Il modo più semplice per determinare se una sessione PPPoE è attiva è usare il 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

Nell'esempio non sono attive sessioni PPPoE. Questo stato è indicato da un SID di 0, mentre i valori RemMAC e LocMAC di 000.0000.0000. In questo caso, passare alla sezione successiva.

Una sessione PPPoE negoziata correttamente ha il seguente aspetto:

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

Nell'esempio riportato di seguito, il SID è un numero diverso da zero e vengono compilati sia il campo RemMAC che il campo LocMAC. L'altro campo di interesse è Vasta, che indica se il protocollo PPP è stato negoziato e autenticato correttamente. Se Vast è attivo, il protocollo PPP è stato negoziato e autenticato correttamente. È possibile passare alla sezione Perché è possibile accedere ad alcune pagine Web con PPPoE ma non ad altre? sezione del presente documento. Se l'opzione Vast è inattiva, continuare con la sezione successiva.

Si riceve una risposta PPPoE dal router di aggregazione?

Se non è stata stabilita una sessione PPPoE attiva, è necessario utilizzare il comando debug vpdn pppoe-events per determinare il tipo di PPPoE che non viene attivato.

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

Nell'esempio, il router Cisco DSL invia continuamente i frame PADI (Active Discovery Initiation) PPPoE all'ISP senza alcuna risposta. Il frame PADI è il primo di una serie di frame PPPoE per la configurazione delle chiamate. Se l'ISP non risponde con un'offerta di rilevamento attivo PPPoE (PADO), la negoziazione PPPoE non ha esito positivo. L'unica soluzione per questo problema è contattare l'ISP.

Se la negoziazione del protocollo PPPoE ha esito positivo, l'output debug vpdn pppoe-events sarà simile al seguente:

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

Se PPPoE viene negoziato correttamente, continuare con la sezione successiva sulla risoluzione dei problemi relativi a PPP.

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 primario 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 output, 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

Che si tratti di un pacchetto I o O, una CONFNAK (Configure-Negative-Conferme) è indicativa di una mancata corrispondenza di configurazione PPP. Ciò significa che un lato della connessione PPP richiede un'opzione PPP che l'altro lato non è in grado o non è configurato per eseguire. Se il router Cisco DSL invia il comando CONNAK (indicato da "O CONNAK"), il router Cisco DSL non può eseguire o non è configurato 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 ma potrebbe essere qualsiasi opzione. 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 CONFIK, aggiungere un comando all'interfaccia di connessione 1 per negoziare correttamente il protocollo PPP con l'ISP. Nel caso in cui il router invii i pacchetti, potrebbe essere necessario chiamare il TAC 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 sono valide sia per i tipi di autenticazione PAP che 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 questo:

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

!--- Turn 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 il protocollo CHAP (Challenge Handshake Authentication Protocol) che per il protocollo PAP (Password Authentication Protocol), come mostrato nella configurazione descritta in precedenza in questa guida, è possibile che l'ISP non utilizzi 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 sta utilizzando PAP, eseguire il comando debug ppp negotiation per verificare che il nome utente e la password 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?

Questo esempio mostra 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

Perché è possibile accedere ad alcune pagine Web con PPPoE ma non ad altre?

L'accesso solo ad alcune pagine Web è un problema comune quando si esegue un client PPPoE su un router. In base alla progettazione, il PPPoE può supportare una MTU fino a 1492 byte. Pertanto, è necessario verificare che i dispositivi terminali non inviino frame più grandi di 1492 byte. Limitare l'MTU a 1492 byte può essere un problema perché la maggior parte dei PC e delle workstation dell'utente finale ha una MTU predefinita di 1500 byte.

Per regolare le dimensioni dell'MTU, è possibile procedere in due modi: regolare le dimensioni dell'MTU sul router e le dimensioni dell'MTU sul PC.

Regolazione delle dimensioni dell'MTU PPPoE sul router Cisco DSL

Note importanti:

Questi comandi di configurazione funzionano solo se si esegue Network Address Translation (NAT) o Port Address Translation (PAT) sul router DSL Cisco.

Il comando ip adjust-mss nel software Cisco IOS® versione 12.2(2)XH è stato modificato in ip tcp adjust-mss <mss value>. Questa modifica è documentata nelle note di versione per i router Cisco serie 800 e i router Cisco serie 820 per Cisco IOS versione 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 
      
!

Regolare le dimensioni dell'MTU PPPoE sul PC utilizzando l'utility TCP Dr

Completare questa procedura per modificare le dimensioni dell'MTU sul PC. La modifica del Registro di sistema viene salvata al termine della procedura.

Nota: l'utilità Dr TCP è compatibile con tutti i PC basati su Windows.

1. Scaricare la versione più recente dell'utilità TCP Dr.

2. Aggiornare la pagina del browser per assicurarsi che sia aggiornata.

3. Eseguire l'utilità Dr.TCP.

4. Dal menu scegliere la scheda Ethernet.

5. Nel campo MTU, digitare 1492.

6. Fare clic su Apply (Applica) per salvare le modifiche, quindi su Exit (Esci).

7. Riavviare il client PPPoE PC.

È necessario eseguire l'utility una sola volta per ogni PC client PPPoE.

Ulteriori passaggi per la risoluzione dei problemi MTU

Se si modificano le dimensioni MTU con il protocollo TCP Dr o sul router DSL Cisco e non è ancora possibile esplorare alcuni siti Web, modificare nuovamente le dimensioni MTU. Modificare le dimensioni dell'MTU a 1452 in Dr. TCP o modificare il valore MSS sul router DSL Cisco a 1412. Se queste dimensioni sono troppo grandi, continuare a ridurre le dimensioni dell'MTU finché non si raggiunge una linea di base di 1400 per il protocollo TCP Dr o di 1360 per il valore MSS sul router DSL Cisco.

Informazioni correlate

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