Guide de configuration et de dépannage du routeur DSL Cisco - Dépannage de PPPoA

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 à votre multiplexeur d'accès DSLAM (Digital Subscriber Line Access Multiplexer) 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 en fonction de 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 ?

Émettez cette commande en mode enable sur le routeur afin de déterminer si l'interface ATM0 est désactivée administrativement :

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 :

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

• 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

Remarque : le Cisco 1417 utilise les broches 2 et 5 sur une prise modulaire standard RJ-11 à 6 broches.

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) afin de 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). Cela ne s'applique pas au Cisco 1417 qui utilise les broches 2 et 5.

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

Si vous utilisez un Cisco 827 comme équipement client DSL (CPE), 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 Cisco 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

Disposez-vous des valeurs correctes de circuit virtuel permanent (PVC) (VPI/VCI) ?

Complétez ces étapes afin de déterminer si les valeurs VPI/VCI (Virtual Path Identifier/Virtual Circuit Identifier) correctes sont configurées sur le routeur.

1. Vérifiez votre version du logiciel Cisco IOS®.

   Important : Cela ne fonctionne pas avec le logiciel Cisco IOS Version 12.1(1)XB.

   Router#show version 
   
   !--- Used to determine your Cisco IOS version.
   
   
   Cisco Internetwork Operating System Software
   IOS (tm) C820 Software (C820-OSY656I-M), Version 12.1(3)XG3, 
   EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)
   
   !--- The two lines immediately preceding appear on one line on the router.
    
   TAC:Home:SW:IOS:Specials for info
   Copyright (c) 1986-2000 by cisco Systems, Inc.
   Compiled Wed 20-Dec-00 16:44 by detang
   Image text-base: 0x80013170, data-base: 0x80725044
   <... snipped ...>

2. Configurez le routeur pour la journalisation de débogage.

   Router#configure terminal 
   Enter configuration commands, one per line. End with CNTL/Z.
   Router(config)#logging console
   Router(config)#logging buffer
   Router(config)#service timestamp debug datetime msec
   Router(config)#service timestamp log datetime msec
   Router(config)#end
   Router#write memory
   Building configuration...
   [OK]
   Router#terminal monitor

3. Activez le débogage sur le routeur.

   Router#debug atm events 
   ATM events debugging is on
   Router#
   2d18h:
   2d18h: RX interrupt: conid = 0, rxBd = 0x80C7EF74 length=52
   2d18h: Data Cell received on vpi = 8 vci = 35
   
   !--- Your VPI/VCI.
   
   2d18h:
   2d18h: RX interrupt: conid = 0, rxBd = 0x80C7EEC0 length=52
   2d18h: Data Cell received on vpi = 8 vci = 35
   2d18h:
   2d18h: RX interrupt: conid = 0, rxBd = 0x80C7EECC length=52
   2d18h: Data Cell received on vpi = 8 vci = 35
   2d18h:
   2d18h: RX interrupt: conid = 0, rxBd = 0x80C7EED8 length=52
   2d18h: Data Cell received on vpi = 8 vci = 35

4. Assurez-vous que des événements ATM de débogage sont exécutés sur le routeur DSL Cisco, puis accédez à une connexion Internet opérationnelle et commencez à envoyer une requête ping à l'adresse IP que votre FAI vous a attribuée de manière statique.

   Peu importe que vous ayez configuré cette adresse IP sur le routeur DSL Cisco. Ce qui est important, c'est que votre interface ATM est activée et que vous envoyez une requête ping à l'adresse IP que votre FAI vous a fournie. Si vous ne voyez pas le résultat attendu après le test ping, contactez votre FAI pour obtenir de l'aide.

5. Désactivez le débogage sur le routeur.

   « patientez 60 secondes »

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

   Vérifiez vos valeurs VPI/VCI, puis apportez les modifications nécessaires à votre configuration.

   Si le résultat ne s'affiche pas au cours des 60 secondes de débogage, contactez votre FAI.

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 sont incrémentés, vous devez recevoir des paquets de négociation PPP 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 PPP. 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 dans les deux directions, poursuivez avec les étapes de dépannage de ce document.

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. Cette sortie de 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 lorsque vous exécutez une négociation debug ppp vous recevez ceci, contactez votre FAI afin de 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’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 (Challenge Handshake Authentication Protocol) mais il peut s'agir de 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 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 support Cisco afin de déterminer quelles commandes doivent être activées sur le routeur DSL 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 (Password Authentication Protocol) 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 dans cet exemple :

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

!--- Turns 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é à la fois pour CHAP et PAP, comme le montre la configuration décrite précédemment dans ce guide, votre FAI peut ne pas utiliser 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 le I CONFREQ est suivi 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 afin de 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. Directement après la modification de l'é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. Directement après la modification de l'é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 illustre 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

Informations connexes

• Options d'implémentation PPPoA
• Guide de configuration et de dépannage du routeur DSL Cisco
• Support ADSL
• Support et documentation techniques - Cisco Systems