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 - Dépannage de PPPoA

18 octobre 2016 - 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 à votre multiplexeur d'accès de ligne d'abonné numérique ISP (DSLAM)

  • 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 dbased sur 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 ?

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

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 :

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

  • 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

Remarque: Cisco 1417 utilise les bornes 2 et 5 sur un connecteur modulaire standard du RJ-11 6-pin.

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) afin de fournir la connexion ADSL au connecteur de mur. Les paires centrales de broches sur le câble de RJ-11 sont utilisées 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). Ceci ne s'applique pas à Cisco 1417 qui utilise les bornes 2 et 5.

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

Si vous utilisez un Cisco 827 en tant que votre CPE DSL (CPE), 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 l'autre Routeurs de la gamme Cisco 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 du circuit virtuel permanent (PVC) (VPI/VCI) ?

Terminez-vous ces étapes afin de déterminer si vous avez les valeurs correctes d'identifiant de chemin virtuel/identifiant de circuit virtuel (VPI/VCI) configurées sur le routeur.

  1. Vérifiez votre version de logiciel de ½ du ¿  de Cisco IOSïÂ.

    Important : Ceci 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 le debug logging.

    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. Élimination des imperfections d'enable 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. Veillez-vous pour avoir le debug atm events s'exécutant sur le routeur de Cisco DSL, et puis allez à une connexion Internet fonctionnante et commencez à cingler l'adresse IP votre ISP statiquement assigné à vous.

    Il n'importe pas si vous ayez configuré cette adresse IP sur le routeur de Cisco DSL. Ce qui est important est que votre interface ATM est up/up et que vous cinglez l'adresse IP votre ISP vous avez donné. Si vous ne voyez pas la sortie prévue après le test de ping, entrez en contact avec votre ISP pour le support.

  5. Élimination des imperfections de débronchement sur le routeur.

    << attente 60 secondes >>

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

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

    Si vous ne voyez pas la sortie pendant les 60 secondes de l'élimination des imperfections, entrez en contact avec votre ISP.

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 paquet incrémentent, vous devriez recevoir des paquets de négociation PPP 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 PPP. 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 les deux directions, continuez les étapes de dépannage dans ce document.

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 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 ceci, entrez en contact avec votre ISP afin de 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 c'est un I ou un paquet O, une Configurer-Négatif-reconnaissance (CONFNAK) est indicative 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 protocole d'authentification CHAP (Challenge Handshake Authentication Protocol) 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 prenez en charge 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 des types de Password Authentication Protocol (PAP) et 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 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-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. Avec la supposition que votre routeur est configuré pour le CHAP et le 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 afin 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 suivant la modification d'état LCP vous devriez 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 suivant la modification d'état LCP vous devriez 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 ?

L'exemple de Theis 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

Informations connexes


Document ID: 71115