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.
Aucune spécification déterminée n'est requise pour ce document.
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
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.
Vérifiez ces informations auprès de votre FAI.
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.
É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
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 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.
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
Obtenez ces informations auprès de votre FAI ou de votre compagnie de téléphone.
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.
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 ...>
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
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
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.
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.
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.
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 ?
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
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
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