Risoluzione dei problemi di VDSL

Introduzione

In questo documento viene descritto come configurare il router Cisco Digital Subscriber Line (DSL) Customer Premise Equipment (CPE) per il servizio VDSL (Very High Bit Rate Digital Subscriber Line). Inoltre, viene spiegato come risolvere i problemi relativi al servizio VDSL sui Cisco serie 880, serie 890, serie 860 e sui moduli VDSL / Asynchronous Digital Subscriber Line (ADSL) Enhanced High Speed WAN Interface Card (EHWIC). Questo documento fa riferimento in modo particolare al servizio VDSL, anche se sui router e sui moduli menzionati potrebbero essere installati anche servizi ADSL. L'errore può verificarsi su tre livelli:

• Layer 1 - Connettività fisica DSL al Digital Subscriber Line Access Multiplexer (DSLAM) dell'ISP
• Layer 2.1 - Connettività Ethernet end-to-end
• Layer 2.2 - Point-to-Point Protocol over Ethernet (PPPoE), IP over Ethernet (IPoE), RFC1483 Bridging o RFC1483 Routing
• Layer 3 - IP

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

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

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

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 usa un dispositivo DSLAM che supporta il chipset Broadcom?

Verificare questa informazione presso il provider di servizi Internet. Verificare l'interoperabilità DSLAM del modello di router o della scheda con riferimento alla scheda tecnica.

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

Se la porta DSL non è collegata al connettore jack a parete DSL, collegarla con un cavo RJ-11 straight-through, ossia un comune cavo telefonico. Le linee VDSL utilizzano i pin 3 e 4.

Qual è lo stato del controller, la modalità operativa e la modalità di copertura della trasmissione (TC, Transmission Coverage)?

Vedere questo output di esempio:

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#

Nell'output del comando show controller, controllare quanto segue:

• Lo stato del controller è "UP". Se lo stato del controller è "Down", si è verificato un problema sul Layer 1 (relativo all'hardware, alla linea o all'interoperabilità con DSLAM). In questo caso, procedere con la risoluzione dei problemi del Layer 1.
• Controllare la modalità operativa, la modalità appresa e la modalità TC. Accertarsi di avere configurato la modalità operativa corretta nel controller. Cisco consiglia di usare la modalità operativa DSL automatica, se non si è sicuri della tecnologia Discrete Multi-Tone (DMT) usata dall'ISP. Questi sono 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)#controller vdsl 0
  
  Router(config-controller)#operating-mode auto
  
  Router(config-controller)#end
  
  Router#write memory

  Verificare la modalità appresa e accertarsi di aver negoziato la modalità corretta con l'ISP. Un altro parametro importante da considerare è la modalità TC. Nel caso in cui la modalità appresa sia VDSL2 o VDSL2+, la modalità TC sarà la modalità Packet Transfer Mode (PTM). In questo caso, è necessario che l'interfaccia PTM Ethernet sia nello stato "up" e tutti i parametri del layer superiore, il protocollo PPP ad esempio o IP, devono essere configurati nell'interfaccia Ethernet. Se la modalità appresa è ADSL, ADSL2 o ADSL2+, la modalità TC deve essere ATM e tutti i parametri del layer superiore devono essere configurati nel circuito permanente virtuale (PVC) di ATM. Se si modifica la modalità operativa tra ADSL e VDSL, potrebbe non essere necessario riavviare il router per attivare le interfacce Ethernet o ATM corrispondenti.

Controllare il margine di rumore e l'attenuazione. Il margine di rumore è il rapporto tra la potenza relativa del segnale DSL e il rumore. Più alto è il valore, migliore sarà il risultato:

• 6 dB o inferiore è insoddisfacente e comporterà problemi di sincronizzazione o sincronizzazione intermittente
• 7 dB-10 dB è giusto, ma non lascia molto spazio per le variazioni delle condizioni
• 11 dB-20 dB è buono, i problemi di sincronizzazione saranno minimi o del tutto assenti
• 20 dB-28 dB è eccellente
• 29 dB o superiore è ottimale

L'attenuazione è una misura della degradazione del segnale tra il DSLAM e il modem e dipende in larga misura dalla distanza. Più basso è il valore dB, migliore sarà il risultato.

• 20 dB o inferiore è ottimale
• 20 dB-30 dB è eccellente
• 30 dB-40 dB è molto buono
• 40 dB-50 dB è buono
• 50 dB-60 dB è insoddisfacente e potrebbe comportare problemi di connettività
• 60 dB o superiore è dannoso e comporterà problemi di connettività

Accertarsi di avere una delle versioni firmware più recenti del VDSL. Nel firmware più recente sono stati corretti la maggior parte dei problemi di interoperabilità noti. È possibile scaricare il firmware più recente da CCO.

Verificare che la DSL sia sincronizzata con le velocità upstream e downstream appropriate.

Il modello di router è corretto?

I router ADSL/VDSL sono disponibili in due versioni: 1) DSL sulla normale linea telefonica analogica, o POTS (Plain Old Telephone Service) (Annex-A) e 2) DSL sulla rete digitale di servizi integrati, o ISDN (Integrated Services Digital Network) (Annex-B). La connessione Annex-B è presente solo in alcuni paesi, mentre nella maggior parte del mondo viene usata la connessione Annex-A. Un router o una scheda DSL Annex-A non può sincronizzarsi con una linea Annex-B e viceversa. Verificare quindi di avere in uso il modello di router giusto. Per ulteriori informazioni, vedere la scheda tecnica del router.

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

Ottenere queste informazioni dall'ISP o dalla compagnia telefonica.

Problemi del Layer 2

L'interfaccia Ethernet è attiva?

Dopo aver verificato che la modalità appresa è VDSL, accertarsi che l'interfaccia Ethernet sia nello stato attivo.

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

Il provider si aspetta di ricevere traffico taggato? Se la risposta è affermativa, qual è l'identificativo della LAN virtuale (VLAN ID)?

La maggior parte dei provider si aspetta che l'apparecchiatura remota dell'utente, o dispositivo CPE (Customer Premise Equipment), invii traffico taggato. È possibile configurare il tagging VLAN come mostrato qui dopo aver ottenuto l'ID VLAN dall'ISP.

Router(config)#interface Ethernet0.835

Router(config-subif)#encapsulation dot1Q 835

Router(config-subif)#end

Router#

La voce Address Resolution Protocol (ARP) è stata popolata?

Stabilire se l'indirizzo MAC della postazione remota viene visualizzato nell'output del comando show arp.

Si ricevono i dati inviati dall'ISP?

Se l'ID VLAN è corretto, il passo successivo consiste nell'avviare la negoziazione del protocollo Point to Point (PPP) con l'ISP. A tale scopo, immettere il comando show interface Ethernet0 e controllare i pacchetti in ingresso e in uscita.

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

Se i contatori dei pacchetti aumentano, i pacchetti di negoziazione PPP dell'ISP sono ricevuti correttamente. In caso contrario, contattare l'ISP.

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

Il protocollo PPP ha effettuato la negoziazione correttamente?

Se il Layer 1 è attivo e l'ID VLAN è corretto, verificare che il protocollo PPP si attivi correttamente. A tale scopo, eseguire una serie di comandi di debug sul Cisco DSL Router e interpretare l'output. Il comando di debug principale utilizzato è debug ppp negotiation. 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 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#

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

Se l'ISP non risponde, ciò non dovrebbe essere un problema, poiché è già stato verificato che i pacchetti aumentano sull'interfaccia Ethernet0 nella direzione in entrata. Tuttavia, se i pacchetti aumentano sull'interfaccia Ethernet0 in entrata mentre si esegue il comando debug ppp negotiation, contatta l'ISP per verificare che i pacchetti vengano inviati al Cisco DSL Router.

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 sono presenti pacchetti I nell'output del comando, contattare l'ISP per verificare che i pacchetti vengano inviati al Cisco DSL Router.

Mancata attivazione del protocollo LCP

Se il protocollo LCP non si attiva, la causa è in genere una mancata corrispondenza nelle opzioni del protocollo 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 Cisco DSL Router invia il messaggio CONFNAK (ossia "O CONFNAK"), il Cisco DSL Router non è in grado di eseguire o non è configurato per l'opzione inviata dall'ISP. Se il messaggio CONFNAK è inviato dall'ISP ("I CONFNAK"), sul Cisco Router è stata configurata un'opzione che l'ISP non intende eseguire.

La riga che segue il messaggio CONFNAK descrive l'opzione rifiutata. Nell'esempio riportato, l'opzione rifiutata è il protocollo CHAP (Challenge Handshake Authentication Protocol), ma potrebbe essere qualsiasi opzione. Sul Cisco DSL Router, le opzioni PPP possono essere configurate esclusivamente dall'interfaccia dialer 1. Immettere il comando show run interface dialer 1 per visualizzare la configurazione dell'interfaccia 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 Cisco DSL Router invia il messaggio O CONFNAK, aggiungere un comando all'interfaccia dialer 1 per la corretta negoziazione del protocollo PPP con l'ISP. Nel caso in cui il router invii pacchetti, potrebbe essere necessario chiamare il supporto Cisco per determinare quali comandi devono essere abilitati sul Cisco DSL Router.

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 configurati entrambi i protocolli, l'output del comando debug ppp negotiation potrebbe essere:

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

Per correggere i problemi di mancata corrispondenza, riconfigurare il protocollo di autenticazione in modo che corrisponda a quello richiesto dall'ISP nel pacchetto CONFREQ in entrata.

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

Dopo aver verificato che l'ISP usa il protocollo PAP, immettere il comando debug ppp negotiation per confermare che il nome utente e la password del protocollo PAP sono 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]

Per risolvere il problema, contattare l'ISP e ottenere le credenziali corrette. È possibile riconfigurare le credenziali PAP con questi comandi:

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

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

Dopo aver verificato che l'ISP usa il protocollo CHAP, immettere il comando debug ppp negotiation per confermare che il nome utente e la password del protocollo PAP sono 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

Per risolvere il problema, contattare l'ISP e ottenere le credenziali corrette. È possibile riconfigurare le credenziali CHAP con questi comandi:

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

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

Problemi di prestazioni nelle connessioni PPPoE

Questa sezione tratta in modo specifico le connessioni PPPoE. Quando si usa l'MTU (Maximum Transmission Unit) predefinito nell'intefaccia dialer e connessioni PPPoE, si possono verificare problemi di velocità di trasmissione, rallentamenti nel browser e così via. Impostare l'MTU sul dialer PPPoE su 1492 per tenere conto degli otto byte utilizzati dall'header PPPoE. Per configurare il valore MTU corretto, immettere questi comandi:

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