Ethernet longue portée (LRE) et ligne numérique d'abonné (xDSL) : Ligne d'abonné numérique à débit asymétrique (ADSL)

Guide de configuration et de dépannage du routeur DSL Cisco - PPPoE : Dépannage d'un routeur DSL en tant que client PPPoE

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Il y a beaucoup de raisons pour lesquelles votre connexion de ligne d'abonné numérique (DSL) pourrait ne pas fonctionner correctement. Le but de ce document est d'isoler la cause de la panne et de la réparer. La première étape de dépannage est de déterminer quelle couche de votre service de ligne d'abonné numérique à débit asymétrique (ADSL) est en défaillance. Il y a trois couches en lesquelles la panne pourrait se produire.

  • Couche 1 ? Connectivité physique DSL au multiplexeur d'accès de ligne d'abonné numérique (DSLAM) de votre ISP

  • Couche 2.1 ? Connectivité ATM

  • Couche 2.2 ? Protocole point-à-point au-dessus d'atmosphère (PPPoA), de Protocole PPPoE (PPP sur Ethernet), de routage RFC1483 jetant un pont sur, ou RFC1483

  • Couche 3 ? IP

Le moyen le plus simple de déterminer ce qui est la couche que vous devriez commencer à dépanner pour émettre le brief de show ip interface de commande. La sortie de cette commande diffère légèrement selon votre configuration.

827-ESC#show ip interface brief
Interface     IP-Address     OK?     Method    Status     Protocol
ATM0          unassigned     YES     manual 	   up         up
ATM0.1        unassigned     YES     unset  	   up         up
Ethernet0     10.10.10.1     YES     manual    up         up

Si les états d'ATM0 et d'ATM0.1 sont en hausse et le protocole est en hausse, commencez à dépanner à la couche 2.

Si les interfaces ATM sont en baisse, ou s'ils continuent à monter et descendre alors (ils ne restent pas et se lèvent), commencez à dépanner à la couche 1.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Problèmes liés à la couche 1

Le voyant de la détection de porteuse (CD) sur le panneau avant du routeur DSL de Cisco DSL est-il allumé ou éteint ?

Si la lumière de CD est allumée, allez aux problèmes de la couche 2 la section de ce document.

Si la lumière de CD est éteinte, continuez la question suivante.

Votre ISP utilisant un multiplexeur d'accès DSL prenant en charge les puces d'Alcatel ?

Vérifiez ces informations avec votre ISP.

Le port DSL à l'arrière du Routeur DSL de Cisco est-il branché à la prise murale DSL ?

Si le port DSL n'est pas branché au connecteur de mur DSL, connectez le port au mur à un câble du RJ-11 4-pin ou 6-pin. C'est un câble téléphonique standard.

L'interface ATM a-t-elle été désactivée par un administrateur ?

Afin de déterminer si l'interface ATM0 est administrativement en baisse, émettez cette commande dans le mode enable sur le routeur :

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

Si l'état de l'interface ATM0 est administrativement en baisse, n'émettez l'aucune commande shutdown sous l'interface 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

La broche de câble est-elle correcte ?

Si l'état de l'interface ATM0 est en baisse et vers le bas, le routeur ne voit pas un transporteur sur la ligne ADSL. Ceci indique généralement une de deux questions :

  1. Les broches actives sur le connecteur de mur DSL sont incorrectes.

  2. Votre ISP n'a pas indiqué un service dsl sur ce connecteur de mur.

Sorties de port de xDSL de routeur de Cisco DSL

Le connecteur RJ-11 fournit une connexion de xDSL aux medias externes par l'intermédiaire d'un connecteur modulaire standard du RJ-11 6-pin.

Pin Description
3 XDSL_Tip
4 XDSL_Ring

Afin de déterminer si l'interface ATM0 est en baisse et vers le bas, émettez l'interface atm d'exposition 0 commandes du mode enable du routeur :

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

Si l'interface ATM est en baisse et vers le bas — pas administrativement vers le bas — vérifiez la sortie de votre connecteur de mur DSL. Le routeur DSL utilise un câble standard de RJ-11 (4-pin ou 6-pin) pour fournir la connexion ADSL au connecteur de mur. La paire centrale de broches sur le câble de RJ-11 est utilisée pour porter le signal ADSL (bornes 3 et 4 sur un câble 6-pin, ou bornes 2 et 3 sur un câble de 4 bornes).

Si vous êtes sûr que vous avez les broches droites sur le connecteur de mur et l'interface ATM0 est toujours vers le bas et en baisse, remplacez le câble de RJ-11 entre le port DSL et votre connecteur de mur. Si l'interface est toujours vers le bas et en baisse après que vous remplaciez le câble de RJ-11, entrez en contact avec votre ISP et faites vérifier l'ISP que le service dsl a été activé sur le connecteur de mur que vous utilisez.

Si vous n'êtes pas sûr quelles broches sur votre connecteur de mur sont en activité, demandez votre ISP.

Avez-vous le bloc d'alimentation correct pour le Cisco 827 ?

Si vous avez vérifié que votre câble DSL est bon et que vous avez les sorties correctes, l'étape suivante est de vous veiller pour avoir le bloc d'alimentation correct pour les 827.

Remarque: Les 827 n'utilise pas la même alimentation d'énergie que d'autres Routeurs de gamme 800.

Afin de déterminer si vous avez le bloc d'alimentation correct, au dos de l'adaptateur électrique recherchent la sortie +12V 0.1A, -12V 0.1A, +5V 3A, -24V 0.12A, et -71V 0.12A. Si votre alimentation d'énergie manque le +12V et le -12V alimente, alors cela est pour un routeur différent de gamme Cisco 800 et ne fonctionne pas sur les 827. Notez que si vous utilisez le bloc d'alimentation faux, le Cisco 827 met sous tension mais ne pouvez pas s'exercer (connectez) à l'ISP DSLAM.

Le mode opérationnel DSL est-il correct ?

Si tout jusqu'à ce point dans la procédure de dépannage de la couche 1 est correct, l'étape suivante est de vous veiller pour avoir le mode de fonctionnement correct DSL. Cisco recommande utilisant l'automatique de dsl operating-mode si vous n'êtes pas sûr quelle technologie DMT votre ISP utilise. Ce sont les commandes de configurer l'autodetection de mode de fonctionnement :

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

Le circuit est-il testé/équipé correctement ?

Obtenez ces informations de votre ISP ou opérateur téléphonique.

Problèmes de la couche 2

Avez-vous les valeurs correctes PVC (VPI/VCI) ?

Avec un déploiement de PPPoE il n'y a aucune méthode facile de découvrir dynamiquement vos valeurs d'identifiant/indentifiant de canal virtuel de chemin virtuel du circuit virtuel permanent (PVC) (VPI/VCI). Entrez en contact avec votre ISP si vous n'êtes pas sûr de vos valeurs PVC.

Recevez-vous des données de votre ISP ?

Si vous avez les valeurs correctes PVC, l'étape suivante est de vérifier que vous tentez d'être en pourparlers le PPP avec votre ISP. Afin de faire ceci, émettez l'interface atm0 d'exposition de commande et vérifiez les paquets d'entrée et sortie.

Router#show interface atm0
ATM0 is up, line protocol is up
Hardware is DSLSAR (with Alcatel ADSL Module)
MTU 4470 bytes, sub MTU 4470, BW 128 Kbit, DLY 16000 usec, 
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ATM, loopback not set
Encapsulation(s): AAL5, PVC mode
24 maximum active VCs, 256 VCS per VP, 1 current VCCs
VC idle disconnect time: 300 seconds
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 5 bits/sec, 0 packets/sec
5 minute output rate 7 bits/sec, 0 packets/sec
100 packets input, 5600 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
250 packets output, 1400 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 output buffer failures, 0 output buffers swapped out

Si les compteurs de paquets en entrée incrémentent, vous devriez recevoir des paquets de négociation de PPPoE de votre ISP. Si ce n'est pas le cas, appelez votre ISP.

Si les compteurs attachés de sortie incrémentent, vous devriez envoyer des paquets de négociation de PPPoE. Si ce n'est pas le cas, vérifiez la configuration sur le routeur. Si le PPP est configuré correctement, des paquets de négociation PPP sont continuellement envoyés l'interface ATM0.

Si les paquets incrémentent dans seulement la direction sortante, continuez les étapes de dépannage dans ce document.

Un PPPoE est-il session ?

Le PPPoE est exécuté en deux phases. La première phase est établissement de session de PPPoE, et la deuxième étape est la négociation PPP. Le PPPoE doit être établi avant la négociation des paramètres standard de PPP. Le moyen le plus simple de déterminer si vous avez une session active de PPPoE est d'émettre la commande de 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

Dans cet exemple, aucune session de PPPoE n'est en activité. Ceci est indiqué par un SID de 0, et le RemMAC et le LocMAC de 0000.0000.0000. Si vous êtes dans cet état, poursuivez à la section suivante.

Une session de PPPoE qui est avec succès négociée ressemble à ceci :

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

Dans cet exemple vous pouvez voir que le SID est un nombre différent de zéro, et que les champs de RemMAC et de LocMAC sont remplis. L'autre champ d'intérêt est le vaste, qui indique si le PPP a été avec succès négocié et authentifié. Si le vaste est, le PPP a-t-il été avec succès négocié et authentifié-, et pouvez-vous poursuivre au pourquoi peux j'accède à quelques pages Web avec le PPPoE mais pas d'autres ? section de ce document. Si le vaste est VERS LE BAS, continuez la section suivante.

Recevez-vous une réponse de PPPoE du routeur d'agrégation ?

Si vous ne faites pas établir une session active de PPPoE, vous devez émettre la commande de debug vpdn pppoe-events de déterminer quel PPPoE ne monte pas.

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

Dans cet exemple, le routeur de Cisco DSL envoie continuellement à PPPoE les trames actives de l'initiation de détection (PADI) à l'ISP sans la réponse. La trame PADI est la première dans une série de trames d'établissement de la communication de PPPoE. Si votre ISP ne répond pas avec une offre active de détection de PPPoE (PADO), la négociation de PPPoE ne réussit pas. La seule solution pour ce problème est d'entrer en contact avec votre ISP.

Si vous négociez avec succès le PPPoE, votre sortie de debug vpdn pppoe-events ressemble à cette sortie :

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

Si le PPPoE est avec succès négocié, continuez la section suivante au sujet du PPP de dépannage.

Le PPP négocie-t-il correctement ?

Si la couche 1 est en hausse et vous avez le VPI/VCI correct, l'étape suivante est de s'assurer que le PPP monte correctement. Afin d'accomplir ceci, vous devez exécuter une gamme de commandes de débogage sur le routeur de Cisco DSL et interpréter la sortie. Les primaires vous mettent au point que l'utilisation est debug ppp negotiation. Cette sortie de la commande est un exemple d'une négociation PPP réussie :

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#

Il y a quatre questions principales de panne dans une négociation PPP :

  • Aucune réponse du périphérique distant (votre ISP)

  • Le Link Control Protocol (LCP) pas s'ouvrent

  • Échec d'authentification

  • Panne du protocole de contrôle IP (IPCP)

Aucune réponse de votre ISP

Votre ISP ne répondant pas ne devrait pas être un problème puisque vous avez déjà vérifié que les paquets incrémentent sur l'interface ATM0 dans la direction d'arrivée. Cependant, si vous voyez des paquets incrémenter sur ATM0 dans la direction d'arrivée, et quand vous exécutez un debug ppp negotiation vous recevez cette sortie, entrez en contact avec votre ISP pour vérifier que des paquets sont envoyés au routeur de Cisco DSL.

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

Dans cette sortie il y a seulement des paquets O, qui sont les paquets sortants. Afin de négocier avec succès le PPP, il devrait y a un paquet entrant I de votre ISP pour chaque paquet O envoyé. Si les paquets sont incrémentation d'arrivée mais vous ne voyez pas des paquets I, entrez en contact avec votre ISP afin de vérifier les paquets qui sont envoyés au routeur de Cisco DSL.

LCP pas s'ouvrent

Le LCP n'étant pas ouvert est habituellement provoqué par une non-concordance dans les options PPP. Cette non-concordance se produit quand le routeur de Cisco DSL fait configurer un paramètre de PPP que votre ISP ne le prend en charge pas, ou quand votre ISP a un paramètre configuré que le routeur de Cisco DSL ne le prend en charge pas. Cette sortie affiche un exemple d'une non-concordance d'option PPP :

Router#debug ppp negotiation
*Mar 1 04:52:43.254: Vi1 PPP: Treating connection as a callout
*Mar 1 04:52:43.258: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load] 
*Mar 1 04:52:43.258: Vi1 PPP: No remote authentication for call-out 
*Mar 1 04:52:43.258: Vi1 LCP: O CONFREQ [Closed] id 3 len 10
*Mar 1 04:52:43.262: Vi1 LCP: MagicNumber 0x31A2F808 (0x050631A2F808)
*Mar 1 04:52:43.310: Vi1 LCP: I CONFREQ [REQsent] id 180 Len 14
*Mar 1 04:52:43.310: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 1 04:52:43.310: Vi1 LCP: MagicNumber 0x39D50E9B (0x050639D50E9B)
*Mar 1 04:52:43.314: Vi1 LCP: O CONFNAK [REQsent] id 180 Len 9

!--- PPP option reject

*Mar 1 04:52:43.314: Vi1 LCP: AuthProto CHAP (0x0305C22305)

!--- PPP option that is rejected

*Mar 1 04:52:43.314: Vi1 LCP: I CONFACK [REQsent] id 3 Len 10
*Mar 1 04:52:43.318: Vi1 LCP: MagicNumber 0x31A2F808 (0x050631A2F808)
*Mar 1 04:52:43.366: Vi1 LCP: I CONFREQ [ACKrcvd] id 181 Len 14
*Mar 1 04:52:43.366: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 1 04:52:43.366: Vi1 LCP: MagicNumber 0x39D50E9B (0x050639D50E9B)
*Mar 1 04:52:43.370: Vi1 LCP: O CONFNAK [ACKrcvd] id 181 Len 9 

!--- PPP option reject

*Mar 1 04:52:43.370: Vi1 LCP: AuthProto CHAP (0x0305C22305) 

!--- PPP option that is rejected

*Mar 1 04:52:43.418: Vi1 LCP: I CONFREQ [ACKrcvd] id 182 Len 14
*Mar 1 04:52:43.418: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 1 04:52:43.418: Vi1 LCP: MagicNumber 0x39D50E9B (0x050639D50E9B)
Router#undebug all

Si son un I ou un paquet O, une Configurer-Négatif-reconnaissance (CONFNAK) est indicatif d'une non-concordance de configuration PPP. Ce que ce le moyen est qu'un côté de la connexion PPP demande une option PPP que l'autre côté est incapable ou non configuré d'exécuter. Si le routeur de Cisco DSL envoie le CONFNAK (indiqué par « O CONFNAK »), le routeur de Cisco DSL ne peut pas exécuter ou non configuré pour l'option l'ISP envoie. Si le CONFNAK est envoyé par votre ISP (indiqué par « moi CONFNAK »), vous avez configuré une option sur le routeur de Cisco DSL que votre ISP n'est pas disposé à exécuter.

La ligne après que le CONFNAK décrive l'option qui est rejetée. Dans cet exemple de sortie, l'option est CHAP mais ce pourrait être n'importe quelle option. Le seul endroit sur le routeur de Cisco DSL où des options PPP peuvent être configurées est question de l'interface dialer 1. que l'exposition de commande exécutent l'interface dialer 1 afin de visualiser votre configuration de l'interface dialer 1.

Si votre ISP envoie l'I CONFNAK, recherchez les commandes sous l'interface dialer 1 qui apparient la ligne après le CONFNAK et les retirent. Si le routeur de Cisco DSL envoie l'O CONFNAK, ajoutez une commande à l'interface dialer 1 d'être en pourparlers correctement le PPP avec votre ISP. Dans le cas du routeur envoyant des paquets, vous pourriez devoir appeler Cisco TAC afin de déterminer quelles commandes doivent être activées sur le routeur de Cisco DSL.

Échec d'authentification

Un échec d'authentification se produit quand votre ISP ne peut pas authentifier votre nom d'utilisateur ou mot de passe de PPP. Il y a deux scénarios dans lesquels ceci peut se produire. Le premier scénario est une non-concordance de type d'authentification, qui est provoqué par quand vous ne configurez pas correctement le routeur. Toutes les configurations d'authentification répertoriées dans ce document expliquent le PAP et les types d'authentification CHAP. Pour la souplesse de configuration, vous devriez faire configurer le CHAP et le PAP. Si vous ne faites pas configurer chacun des deux, vous pourriez voir la sortie d'une commande de debug ppp comme cette sortie :

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

ou

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


Afin de corriger les deux problèmes de non-concordance d'authentification, référez-vous à la configuration appropriée d'option d'implémentation de PPPoA et modifiez l'authentification de PPP.

Le deuxième scénario de problème d'authentification que vous pouvez rencontrer est un nom d'utilisateur ou mot de passe incorrect PAP. Afin de déterminer si c'est le problème, émettez le debug ppp negotiation de commande. Assumant votre routeur est configuré pour les deux protocole d'authentification CHAP (Challenge Handshake Authentication Protocol) et le Password Authentication Protocol (PAP), car la configuration tracée les grandes lignes plus tôt de ce guide affiche, votre ISP ne pourrait pas utiliser l'authentification PAP.

Afin de déterminer l'authentification utilisée par votre ISP, vérifiez les options dans le paquet I CONFREQ envoyé à vous de votre ISP. Si ce paquet est suivi par une option appelée AuthProto PAP, vous utilisez le PAP. Si l'I CONFREQ est suivi par une option appelée le CHAP d'AuthProto, est-ce que vous utilisez le CHAP et devriez poursuivre à la façon dont je sais si mon nom d'utilisateur et mot de passe de CHAP sont correct ?

Comment est-ce que je sais si mon nom d'utilisateur et mot de passe PAP sont correct ?

Après que vous ayez confirmé que votre ISP utilise le PAP, émettez la commande de debug ppp negotiation de confirmer que votre nom d'utilisateur et mot de passe PAP sont correct.

Router#debug ppp negotiation 
*Mar 2 00:50:15.741: Vi1 PPP: Treating connection as a callout
*Mar 2 00:50:15.745: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load]
*Mar 2 00:50:15.745: Vi1 PPP: No remote authentication for call-out
*Mar 2 00:50:15.745: Vi1 LCP: O CONFREQ [Closed] id 177 Len 10
*Mar 2 00:50:15.745: Vi1 LCP: MagicNumber 0x35EB5D4F (0x050635EB5D4F)
*Mar 2 00:50:15.789: Vi1 LCP: I CONFACK [REQsent] id 177 Len 10
*Mar 2 00:50:15.793: Vi1 LCP: MagicNumber 0x35EB5D4F (0x050635EB5D4F)
*Mar 2 00:50:17.241: Vi1 LCP: I CONFREQ [ACKrcvd] id 203 Len 14
*Mar 2 00:50:17.241: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 2 00:50:17.241: Vi1 LCP: MagicNumber 0x3E1D1E5E (0x05063E1D1E5E)
*Mar 2 00:50:17.245: Vi1 LCP: O CONFACK [ACKrcvd] id 203 Len 14
*Mar 2 00:50:17.245: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 2 00:50:17.245: Vi1 LCP: MagicNumber 0x3E1D1E5E (0x05063E1D1E5E)
*Mar 2 00:50:17.249: Vi1 LCP: State is Open
*Mar 2 00:50:17.249: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
*Mar 2 00:50:17.249: Vi1 PAP: O AUTH-REQ id 9 Len 14 from "cisco" 

!--- "cisco" is the PAP username configured on this DSL router.

*Mar 2 00:50:17.297: Vi1 PAP: I AUTH-NAK id 9 Len 27 msg is "Authentication failure"
*Mar 2 00:50:17.301: Vi1 LCP: I TERMREQ [Open] id 204 Len 4
*Mar 2 00:50:17.301: Vi1 LCP: O TERMACK [Open] id 204 Len 4
*Mar 2 00:50:17.305: Vi1 PPP: Phase is TERMINATING [0 sess, 1 load]u
*Mar 2 00:50:19.305: Vi1 LCP: TIMEout: State TERMsent
*Mar 2 00:50:19.305: Vi1 LCP: State is Closed
*Mar 2 00:50:19.305: Vi1 PPP: Phase is DOWN [0 sess, 1 load]

Si vous avez un problème d'authentification PAP, vous devriez voir l'état LCP aller à ouvert. Directement après que la modification d'état LCP vous devrait voir le PPP entrer dans une phase authentifiante. Si une des deux prochaines lignes contient I AUTHENTIC-NAK, votre nom d'utilisateur PAP ou mot de passe PAP est incorrect. En ce moment, vous devez modifier votre nom d'utilisateur et mot de passe PAP utilisant cet ordre des commandes. Notez que votre nom d'utilisateur et mot de passe PAP distinguent les majuscules et minuscules.

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

Comment est-ce que je sais si mon nom d'utilisateur et mot de passe de CHAP sont correct ?

Après que vous ayez confirmé que votre CHAP d'utilisations ISP, émettent la commande de debug ppp negotiation afin de confirmer que votre nom d'utilisateur et mot de passe de CHAP sont correct.

Router#debug ppp negotiation
*Mar 3 02:51:47.287: Vi1 PPP: Treating connection as a callout
*Mar 3 02:51:47.287: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load]
*Mar 3 02:51:47.291: Vi1 PPP: No remote authentication for call-out
*Mar 3 02:51:47.291: Vi1 LCP: O CONFREQ [Closed] id 188 Len 10
*Mar 3 02:51:47.291: Vi1 LCP: MagicNumber 0x3B821FF1 (0x05063B821FF1)
*Mar 3 02:51:47.339: Vi1 LCP: I CONFREQ [REQsent] id 204 Len 15
*Mar 3 02:51:47.343: Vi1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 3 02:51:47.343: Vi1 LCP: MagicNumber 0x43B3F393 (0x050643B3F393)
*Mar 3 02:51:47.343: Vi1 LCP: O CONFACK [REQsent] id 204 Len 15
*Mar 3 02:51:47.347: Vi1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 3 02:51:47.347: Vi1 LCP: MagicNumber 0x43B3F393 (0x050643B3F393)
*Mar 3 02:51:47.347: Vi1 LCP: I CONFACK [ACKsent] id 188 Len 10
*Mar 3 02:51:47.351: Vi1 LCP: MagicNumber 0x3B821FF1 (0x05063B821FF1)
*Mar 3 02:51:47.351: Vi1 LCP: State is Open
*Mar 3 02:51:47.351: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
*Mar 3 02:51:47.395: Vi1 CHAP: I CHALLENGE id 1 Len 32 from "6400-2-NRP3"
*Mar 3 02:51:47.395: Vi1 CHAP: Using alternate hostname cisco
*Mar 3 02:51:47.399: Vi1 CHAP: Username 6400-2-NRP3 not found
*Mar 3 02:51:47.399: Vi1 CHAP: Using default password
*Mar 3 02:51:47.399: Vi1 CHAP: O RESPONSE id 1 Len 26 from "cisco"  

!--- "cisco" is the CHAP username configured on this DSL router.

*Mar 3 02:51:47.447: Vi1 CHAP: I FAILURE id 1 Len 26 MSG is "Authentication failure"
*Mar 3 02:51:47.447: Vi1 LCP: I TERMREQ [Open] id 205 Len 4
*Mar 3 02:51:47.451: Vi1 LCP: O TERMACK [Open] id 205 Len 4
*Mar 3 02:51:47.451: Vi1 PPP: Phase is TERMINATING [0 sess, 0 load]
*Mar 3 02:51:49.451: Vi1 LCP: TIMEout: State TERMsent
*Mar 3 02:51:49.451: Vi1 LCP: State is Closed
*Mar 3 02:51:49.451: Vi1 PPP: Phase is DOWN [0 sess, 0 load]
Router#undebug all

Si vous avez un problème d'authentification CHAP, vous devriez voir l'état LCP aller à ouvert. Directement après que la modification d'état LCP vous devrait voir le PPP entrer dans une phase authentifiante. De ce point vous voyez une gamme de lignes de CHAP. Si le bout de ces lignes affiche la PANNE I, vous avez le nom d'utilisateur et mot de passe faux de CHAP. Employez cet ordre des commandes afin de corriger votre nom d'utilisateur et mot de passe de CHAP. Notez que votre nom d'utilisateur et mot de passe distinguent les majuscules et minuscules.

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

Comment est-ce que je connais quand l'authentification de PPP est réussie ?

Cet exemple affiche une négociation réussie de CHAP.

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

Cet exemple affiche une négociation réussie PAP.

Router#debug ppp negotiation
<... snipped ...>
*Mar 3 03:33:19.491: Vi1 LCP: State is Open
*Mar 3 03:33:19.491: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 0 load]
*Mar 3 03:33:19.495: Vi1 PAP: O AUTH-REQ id 255 Len 16 from "cisco"
*Mar 3 03:33:19.539: Vi1 PAP: I AUTH-ACK id 255 Len 5
*Mar 3 03:33:19.539: Vi1 PPP: Phase is UP [0 sess, 0 load] 

!--- PAP negotiation was a success.

<... snipped ...>
Router#undebug all

Pourquoi est-ce que je peux accéder à quelques pages Web avec le PPPoE mais pas d'autres ?

Access seulement à quelques pages Web est un problème courant quand vous exécutez un PPPoE Client sur un routeur. Par conception, le PPPoE peut prendre en charge un MTU de jusqu'à 1492 octets. Par conséquent, vous devez s'assurer que les périphériques d'extrémité n'envoient octets pas plus grands de trames des que 1492. La limitation du MTU à 1492 octets peut être un problème parce que la plupart des PC et postes de travail d'utilisateur ont un MTU par défaut de 1500 octets.

Il y a deux options pour ajuster la taille de MTU : ajustez la taille de MTU au routeur et ajustez la taille de MTU au PC.

Ajustez la taille de MTU de PPPoE sur le routeur de Cisco DSL

Remarques importantes :

Ces commandes de configuration fonctionnent seulement si vous effectuez le Traduction d'adresses de réseau (NAT) ou la translation d'adresses d'adresse du port (PAT) sur le routeur de Cisco DSL.

L'IP ajustent-mss la commande dans la version de logiciel 12.2(2)XH de Cisco IOSÝ a changé au value> de <mss d'ip tcp adjust-mss. Ce changement est documenté des notes en version pour le Routeurs de la gamme Cisco 800 et les Routeurs de gamme Cisco 820 pour la Cisco IOS version 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 <ip address of ethernet0> 0.0.255.255 
!

Ajustez la taille de MTU de PPPoE sur le PC utilisant l'utilitaire de Dr. TCP

Terminez-vous ces étapes afin de changer la taille de MTU sur le PC. Le changement dans le registre est enregistré quand la procédure termine.

Remarque: L'utilitaire de Dr. TCP est compatible avec tout le PC Windows.

  1. Téléchargez la dernière version de l'utilitaire de Dr. TCPleavingcisco.com .

  2. Régénérez votre page de navigateur pour s'assurer que la page est en cours.

  3. Exécutez l'utilitaire Dr.TCP.

  4. Du menu choisissez votre adaptateur Ethernet.

  5. Dans le domaine de MTU, type 1492.

  6. Cliquez sur Apply pour sauvegarder la modification, et puis cliquez sur la sortie.

  7. Redémarrez le client PC de PPPoE.

Vous devez exécuter l'utilitaire seulement une fois par PC de PPPoE Client.

Étapes de dépannage supplémentaires de MTU

Si vous changez la taille de MTU avec Dr. TCP ou sur le routeur de Cisco DSL et ne pouvez toujours pas parcourir certains sites Web, ajustez la taille de MTU de nouveau. Changez la taille de MTU à 1452 dans Dr. TCP, ou changez le MSS ajustent la valeur sur le routeur de Cisco DSL à 1412. Si ces tailles sont trop grandes, continuez à diminuer les tailles de MTU jusqu'à ce que vous atteigniez une spécification de base de 1400 pour Dr. TCP ou 1360 pour MSS s'ajustent sur le routeur de Cisco DSL.

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 71124