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

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 DSLAM (Digital Subscriber Line Access Multiplexer) de votre FAI

• Couche 2.1 - Connectivité ATM

• Couche 2.2 - Protocole point à point sur ATM (PPPoA), protocole point à point sur Ethernet (PPPoE), pontage RFC1483 ou routage RFC1483

• Couche 3 - IP

Le moyen le plus simple de déterminer la couche que vous devez commencer à dépanner est d’exécuter la commande show ip interface brief. Le résultat 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 ATM0 et ATM0.1 sont actifs et que le protocole est actif, commencez à résoudre les problèmes au niveau de la couche 2.

Si les interfaces ATM sont en panne, ou si elles continuent de s’activer puis de s’arrêter (elles ne restent pas actives et actives), commencez à effectuer le dépannage au niveau de la couche 1.

Conditions préalables

Conditions requises

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

Components Used

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 le voyant CD est allumé, accédez à la section Problèmes de couche 2 de ce document.

Si le voyant CD est éteint, passez à la question suivante.

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

Vérifiez ces informations auprès de votre FAI.

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é sur la prise murale DSL, connectez le port au mur à l'aide d'un câble RJ-11 à 4 ou 6 broches. Il s'agit d'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 désactivée administrativement, émettez cette commande en 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 désactivé administrativement, exécutez la commande no 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

Le brochage du câble est-il correct ?

Si l’état de l’interface ATM0 est désactivé et désactivé, le routeur ne voit pas de porteuse sur la ligne ADSL. Cela indique généralement l'un des deux points suivants :

1. Les broches actives de la prise murale DSL sont incorrectes.

2. Votre FAI n'a pas activé de service DSL sur cette prise murale.

Brochage des ports xDSL du routeur DSL Cisco

Le connecteur RJ-11 fournit une connexion xDSL à un support externe via une prise modulaire standard RJ-11 à 6 broches.

Broche	Description
3	XDSL_Tip
4	XDSL_Ring

Afin de déterminer si l’interface ATM0 est désactivée et désactivée, émettez la commande show interface atm 0 à partir du mode enable du routeur :

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

Si l’interface ATM est désactivée (et non désactivée administrativement), vérifiez le brochage de votre prise murale DSL. Le routeur DSL utilise un câble RJ-11 standard (4 ou 6 broches) pour fournir la connexion ADSL à la prise murale. La paire de broches centrale du câble RJ-11 est utilisée pour transporter le signal ADSL (broches 3 et 4 sur un câble à 6 broches ou broches 2 et 3 sur un câble à 4 broches).

Si vous êtes sûr que les broches appropriées se trouvent sur la prise murale et que l'interface ATM0 est toujours désactivée, remplacez le câble RJ-11 entre le port DSL et la prise murale. Si l'interface est toujours désactivée après le remplacement du câble RJ-11, contactez votre FAI et demandez-lui de vérifier que le service DSL a été activé sur la prise murale que vous utilisez.

Si vous ne savez pas quelles broches de votre prise murale sont actives, demandez à votre FAI.

Disposez-vous de l'alimentation appropriée pour le Cisco 827 ?

Si vous avez vérifié que votre câble DSL est correct et que vous disposez des brochages appropriés, l'étape suivante consiste à vous assurer que vous disposez de l'alimentation appropriée pour le 827.

Remarque : le 827 n'utilise pas le même bloc d'alimentation que les autres routeurs de la gamme 800.

Afin de déterminer si vous disposez de l'alimentation appropriée, à l'arrière de l'adaptateur secteur, recherchez Sortie +12 V 0,1 A, -12 V 0,1 A, +5 V 3A, -24 V 0,12 A et -71 V 0,12 A. Si les alimentations +12 V et -12 V sont manquantes, il s'agit d'un autre routeur de la gamme Cisco 800 qui ne fonctionne pas sur le modèle 827. Notez que si vous utilisez le mauvais bloc d'alimentation, le Cisco 827 s'allume mais ne peut pas s'entraîner (se connecter) au DSLAM du FAI.

Le mode opérationnel DSL est-il correct ?

Si tout est correct jusqu’à ce point dans la procédure de dépannage de la couche 1, l’étape suivante consiste à vous assurer que vous disposez du mode de fonctionnement DSL approprié. Cisco recommande d'utiliser le mode d'exploitation automatique dsl si vous ne savez pas quelle technologie DMT votre FAI utilise. Voici les commandes permettant de configurer la détection automatique en 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 auprès de votre FAI ou de votre compagnie de téléphone.

Problèmes liés à la couche 2

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

Avec un déploiement PPPoE, il n'y a aucun moyen simple de découvrir dynamiquement vos valeurs VPI/VCI (Permanent Virtual Circuit). Contactez votre FAI si vous n'êtes pas sûr des valeurs de votre circuit virtuel permanent.

Recevez-vous des données de votre FAI ?

Si vous disposez des valeurs PVC correctes, l'étape suivante consiste à vérifier que vous essayez de négocier PPP avec votre FAI. Pour ce faire, exécutez la commande show interface atm0 et vérifiez les paquets d'entrée et de 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 d'entrée s'incrémentent, vous devez recevoir des paquets de négociation PPPoE de votre FAI. Si ce n'est pas le cas, appelez votre FAI.

Si les compteurs de liaison de sortie sont incrémentés, vous devez envoyer des paquets de négociation PPPoE. Si ce n’est pas le cas, vérifiez la configuration sur le routeur. Si le protocole PPP est configuré correctement, les paquets de négociation PPP sont continuellement envoyés par l’interface ATM0.

Si les paquets s'incrémentent uniquement dans la direction sortante, poursuivez avec les étapes de dépannage de ce document.

Une session PPPoE est-elle active ?

PPPoE est exécuté en deux phases. La première phase est l'établissement de la session PPPoE et la deuxième phase est la négociation PPP. PPPoE doit être établi avant la négociation des paramètres PPP standard. La façon la plus simple de déterminer si vous avez une session PPPoE active consiste à émettre la commande 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 PPPoE n'est active. Ceci est indiqué par un SID de 0, et RemMAC et LocMAC de 0000.0000.0000. Si vous êtes dans cet état, passez à la section suivante.

Une session PPPoE négociée avec succès 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 RemMAC et LocMAC sont renseignés. L'autre domaine d'intérêt est le Vast, qui indique si le protocole PPP a été négocié et authentifié avec succès. Si le Vast est UP, PPP a été négocié et authentifié avec succès, et vous pouvez passer à la section Pourquoi puis-je accéder à certaines pages Web avec PPPoE mais pas à d'autres ? de ce document. Si le Vast est DOWN, passez à la section suivante.

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

Si aucune session PPPoE active n'est établie, vous devez émettre la commande debug vpdn pppoe-events pour déterminer ce que PPPoE ne génère 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 DSL Cisco envoie en continu des trames PADI (Active Discovery Initiation) PPPoE au FAI sans réponse. La trame PADI est la première d'une série de trames de configuration d'appel PPPoE. Si votre FAI ne répond pas avec une offre de découverte active PPPoE (PADO), la négociation PPPoE échoue. La seule solution à ce problème est de contacter votre FAI.

Si vous négociez PPPoE avec succès, la sortie debug vpdn pppoe-events ressemble à la sortie suivante :

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 PPPoE est négocié avec succès, passez à la section suivante sur le dépannage de PPP.

Est-ce que le PPP négocie correctement ?

Si la couche 1 est active et que vous disposez du VPI/VCI correct, l’étape suivante consiste à s’assurer que le protocole PPP fonctionne correctement. Pour ce faire, vous devez exécuter une série de commandes debug sur le routeur DSL Cisco et interpréter le résultat. Le débogage principal que vous utilisez est debug ppp negotiation. Ce résultat de la commande est un exemple de 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 points principaux d’échec dans une négociation PPP :

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

• Le protocole LCP (Link Control Protocol) n'est pas ouvert

• Échec de l'authentification

• Échec du protocole IPCP (IP Control Protocol)

Aucune réponse de votre FAI

Votre FAI ne répondant pas ne doit pas poser de problème, car vous avez déjà vérifié que les paquets s’incrémentent sur l’interface ATM0 dans la direction entrante. Cependant, si vous voyez des paquets s'incrémentant sur ATM0 dans la direction entrante, et que vous exécutez une négociation debug ppp vous recevez cette sortie, contactez votre FAI pour vérifier que les paquets sont envoyés au routeur 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

Dans ce résultat, il n'y a que O paquets, qui sont des paquets sortants. Afin de négocier avec succès PPP, il doit y avoir un paquet I entrant de votre FAI pour chaque paquet O envoyé. Si les paquets sont en train d'augmenter en entrée mais que vous ne voyez pas de paquets I, contactez votre FAI afin de vérifier les paquets qui sont envoyés au routeur DSL Cisco.

LCP non ouvert

Le fait que le protocole LCP ne soit pas ouvert est généralement dû à une non-correspondance dans les options PPP. Cette non-correspondance se produit lorsque le routeur DSL Cisco a un paramètre PPP configuré que votre FAI ne prend pas en charge, ou lorsque votre FAI a un paramètre configuré que le routeur DSL Cisco ne prend pas en charge. Ce résultat montre un exemple de non-correspondance 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

Qu’il s’agisse d’un paquet d’E ou d’un paquet O, un CONFNAK (Configure-Negative-Acknow) indique une non-correspondance de configuration PPP. Cela signifie qu’un côté de la connexion PPP demande une option PPP que l’autre côté n’est pas capable ou n’est pas configuré pour exécuter. Si le routeur DSL Cisco envoie la CONFNAK (indiquée par "O CONFNAK »), le routeur DSL Cisco ne peut pas exécuter ou n'est pas configuré pour l'option envoyée par le FAI. Si la CONFNAK est envoyée par votre FAI (indiqué par "I CONFNAK »), vous avez configuré une option sur le routeur DSL Cisco que votre FAI n'est pas prêt à exécuter.

La ligne qui suit la CONFNAK décrit l'option rejetée. Dans cet exemple de sortie, l'option est CHAP mais elle peut être n'importe quelle option. Le seul emplacement sur le routeur DSL Cisco où les options PPP peuvent être configurées est l’interface dialer 1. Exécutez la commande show run interface dialer 1 afin d'afficher la configuration de l'interface dialer 1.

Si votre FAI envoie la CONFNAK I, recherchez des commandes sous interface dialer 1 qui correspondent à la ligne après la CONFNAK et supprimez-les. Si le routeur DSL de Cisco envoie la CONFNAK O, ajoutez une commande à l’interface dialer 1 pour négocier correctement PPP avec votre FAI. Dans le cas d’un routeur qui envoie des paquets, vous devrez peut-être appeler le centre d’assistance technique de Cisco afin de déterminer quelles commandes doivent être activées sur le routeur DSL de Cisco.

Échec de l'authentification

Une erreur d'authentification se produit lorsque votre FAI ne parvient pas à authentifier votre nom d'utilisateur ou votre mot de passe PPP. Il existe deux scénarios dans lesquels cela peut se produire. Le premier scénario est une non-correspondance de type d'authentification, qui est provoquée lorsque vous ne configurez pas correctement le routeur. Toutes les configurations d'authentification répertoriées dans ce document prennent en compte les types d'authentification PAP et CHAP. Pour plus de souplesse, vous devez configurer CHAP et PAP. Si vous n'avez pas configuré les deux, vous pouvez voir la sortie d'une commande debug ppp comme ceci :

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-correspondance d'authentification, référez-vous à la configuration appropriée de l'option d'implémentation PPPoA et reconfigurez l'authentification PPP.

Le deuxième scénario de problème d'authentification que vous pouvez rencontrer est un nom d'utilisateur ou un mot de passe PAP incorrect. Afin de déterminer si c'est le problème, émettez la commande debug ppp negotiation. En supposant que votre routeur est configuré pour le protocole CHAP (Challenge Handshake Authentication Protocol) et le protocole PAP (Password Authentication Protocol), comme le montre la configuration décrite précédemment dans ce guide, votre FAI n'utilise peut-être pas l'authentification PAP.

Afin de déterminer l'authentification utilisée par votre FAI, vérifiez les options dans le paquet I CONFREQ qui vous est envoyé par votre FAI. Si ce paquet est suivi d'une option appelée PAP AuthProto, vous utilisez PAP. Si l'option I CONFREQ est suivie d'une option appelée AuthProto CHAP, vous utilisez CHAP et devez passer à Comment savoir si mon nom d'utilisateur et mon mot de passe CHAP sont corrects ?

Comment savoir si mon nom d'utilisateur et mon mot de passe PAP sont corrects ?

Après avoir confirmé que votre FAI utilise PAP, émettez la commande debug ppp negotiation pour confirmer que votre nom d'utilisateur et votre mot de passe PAP sont corrects.

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 à Ouvrir. Juste après le changement d'état LCP, vous devriez voir le protocole PPP entrer dans une phase d'authentification. Si l'une des deux lignes suivantes contient I AUTH-NAK, votre nom d'utilisateur PAP ou votre mot de passe PAP est incorrect. À ce stade, vous devez reconfigurer votre nom d'utilisateur et votre mot de passe PAP à l'aide de cette séquence de commandes. Notez que votre nom d'utilisateur et votre mot de passe PAP sont sensibles à la casse.

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

Comment savoir si mon nom d'utilisateur et mon mot de passe CHAP sont corrects ?

Après avoir confirmé que votre FAI utilise CHAP, émettez la commande debug ppp negotiation afin de confirmer que votre nom d'utilisateur et votre mot de passe CHAP sont corrects.

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 à Ouvrir. Juste après le changement d'état LCP, vous devriez voir le protocole PPP entrer dans une phase d'authentification. À partir de ce point, vous voyez une série de lignes CHAP. Si la dernière de ces lignes indique I FAILURE, vous avez le mauvais nom d'utilisateur et mot de passe CHAP. Utilisez cette séquence de commandes afin de corriger votre nom d'utilisateur et votre mot de passe CHAP. Notez que votre nom d'utilisateur et votre mot de passe sont sensibles à la casse.

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

Comment savoir si l’authentification PPP réussit ?

Cet exemple montre une négociation CHAP réussie.

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 illustre une négociation PAP réussie.

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 puis-je accéder à certaines pages Web avec PPPoE mais pas à d'autres ?

L'accès à certaines pages Web est un problème courant lorsque vous exécutez un client PPPoE sur un routeur. Par conception, PPPoE peut prendre en charge un MTU pouvant atteindre 1 492 octets. Par conséquent, vous devez vous assurer que les périphériques finaux envoient des trames d’une taille maximale de 1 492 octets. Limiter la MTU à 1 492 octets peut poser problème car la plupart des PC et des stations de travail des utilisateurs finaux ont une MTU par défaut de 1 500 octets.

Il existe deux options pour ajuster la taille du MTU : réglez la taille MTU au niveau du routeur et réglez la taille MTU au niveau du PC.

Régler la taille MTU PPPoE sur le routeur DSL Cisco

Remarques importantes :

Ces commandes de configuration ne fonctionnent que si vous exécutez NAT (Network Address Translation) ou PAT (Port Address Translation) sur le routeur DSL Cisco.

La commande ip adjust-mss dans le logiciel Cisco IOS® Version 12.2(2)XH est passée à ip tcp adjust-mss <valeur mss>. Cette modification est documentée dans les notes de version des routeurs de la gamme Cisco 800 et des routeurs de la gamme Cisco 820 pour 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 
      
      
        0.0.255.255 
      
!

Ajustez la taille MTU PPPoE sur le PC à l'aide de l'utilitaire Dr TCP

Complétez ces étapes afin de modifier la taille de MTU sur le PC. La modification du Registre est enregistrée lorsque la procédure est terminée.

Remarque : L'utilitaire Dr TCP est compatible avec tous les PC Windows.

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

2. Actualisez la page de votre navigateur pour vous assurer qu'elle est à jour.

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

4. Dans le menu, choisissez votre adaptateur Ethernet.

5. Dans le champ MTU, tapez 1492.

6. Cliquez sur Apply pour enregistrer la modification, puis cliquez sur Exit.

7. Redémarrez le client PC PPPoE.

Vous devez exécuter l'utilitaire une seule fois par PC client PPPoE.

Étapes de dépannage MTU supplémentaires

Si vous modifiez la taille de MTU avec Dr TCP ou sur le routeur DSL Cisco et que vous ne parcourez toujours pas certains sites Web, réajustez la taille de MTU. Remplacez la taille de MTU par 1452 dans le protocole Dr TCP ou modifiez la valeur de réglage MSS sur le routeur DSL Cisco par 1412. Si ces tailles sont trop grandes, continuez à réduire les tailles de MTU jusqu'à ce que vous atteigniez une ligne de base de 1400 pour Dr TCP ou 1360 pour MSS ajustés sur le routeur DSL Cisco.

Informations connexes

• Prise en charge de la technologie ADSL
• Options d'implémentation PPPoE
• Guide de configuration et de dépannage du routeur DSL Cisco
• Support et documentation techniques - Cisco Systems