Comprendre la sortie de la commande debug ppp negotiation

Présentation au sujet: "Comprendre la sortie de la commande debug ppp negotiation"— Transcription de la présentation:

1 Comprendre la sortie de la commande debug ppp negotiation
ccnp_cch ccnp_cch

2 Sommaire • Introduction
• Phases de la négociation PPP • Etapes LCP, Authentification et NCP • Résolution de problème avec la commande debug ppp negotiation • Lecture de la sortie de la commande debug ppp negotiation • Exemple de sortie de la commande debug ppp negotiation • Glossaire des messages courants ccnp_cch

3 Introduction ccnp_cch
PPP (Point to Point Protocol) est l'encapsulation la plus communément utilisée dans les applications d'accès distants. PPP permet à deux machines sur une liaison de communication point à point de négocier des paramètres pour l'authentification, la compression et les protocoles de couche 3 tels que IP. Une défaillance dans la négociation PPP entre deux routeurs entraine une déconnexion de liaison. La commande debug ppp negotiation vous permet de voir les transactions PPP pour la négociation, d'identifier le problème ou la phase quand une erreur se produit et de trouver une solution. Cependant il est impératif que vous sachiez lire et interpréter la sortie de la commande debug ppp negotiation. Ce document fournit une méthode pour lire la sortie de la commande debug ppp negotiation. Prérequis • La négociation PPP entre deux proches ne peut pas commencer tant que la couche physique (RNIS, V24, ....) ne fonctionne pas correctement. Par exemple si vous utilisez PPP avec RNIS, les couches RNIS doivent être établies pour que PPP puisse être activé et opérationnel. • PPP doit être validé sur les interfaces des deux routeurs. Utilisez la commande encapsulation ppp. • Activez les marques de temps en millisecondes sur le routeur en utilisant la commande suivante: Router(config)# service timestamp debug datetime msec ccnp_cch

4 Echec Authentification Succès Authentification
Phases de la négociation PPP Durant la négociation PPP, la liaison passe par plusieurs phases décrites dans le tableau ci-dessous. Le résultat final est que PPP est soit "UP" soit "DOWN". Phase Description DOWN PPP n'est pas opérationnel. Le message suivant s'affiche lorsque la liaison et PPP passent non opérationnels: *Mar 3 23:32:50.296: BRI0/0:1 PPP Phase is DOWN ESTABLISHING PPP passe dans cette phase quand il reçoit l'indication que la coche physique est établie. La négociation LCP est réalisée dans cette phase. *Mar 3 23:33:06.296: BRI0/0:1 PPP Phase is ESTABLISHING AUTHENTICATING Si l'authentification PPP (CHAP ou PAP) est requise sur la liaison, PPP passe dans cette phase. L'authentification est optionnelle. *Mar 3 23:33:06.400: BRI0/0:1 PPP Phase is AUTHENTICATING UP Lorsque l'authentification est réalisée, PPP passe dans cette phase. La négociation NCP (Network Control Protocol) est réalisée dans cette phase. *Mar 3 23:33:06.660: BRI0/0:1 PPP Phase is UP TERMINATING Passe de terminaison PPP *Mar 3 23:33:07.900: BRI0/0:1 PPP Phase is TRMINATING Echec Négociation LCP LCP State Open; Pas d'Authentification LCP State Open DOWN Liaison UP ESTABLISHING AUTHENTICATING (CHAP,PAP) Echec Authentification Succès Authentification Renégociation LCP TERMINATING UP Fermeture PPP ccnp_cch

5 Les paquets de négociation PPP
Le tableau suivant inclut les paquets de négociation PPP qui sont utilisés pour les négociations LCP et NCP (Network Control Protocol). Paquet Code Description CONFREQ Configure-Request L'équipement ouvre une connexion avec le proche en transmettant ce message avec les options de configuration et les valeurs désirées par l'émetteur. Toutes les options et les valeurs sont négociées en même temps. Si le proche répond avec CONFREJ ou CONFNAK, le routeur transmet un autre CONFREQ avec un nouvel ensemble d'options et de valeurs. CONFREJ Configure-Reject SI une ou plusieurs options de configuration reçues dans le CONFREQ ne sont pas acceptables ou reconnues, le routeur répond avec CONFREJ. Les options rejetées sont dans le message CONFREJ. CONFNAK Configure-Negative-Acknowledge (NAK) Si l'option de configuration est reconnue et acceptable mais la valeur n'est pas acceptable, le routeur transmet un CONFNAK. Le routeur inclut les options et les valeurs qu'il peut accepter dans le message CONFNAK . Le proche pourra inclure ces options dans le prochain message CONFREQ. CONFACK Configure-Acknowledge(ACK) Si toutes les options et valeurs du message CONFREQ sont reconnues et acceptables, le routeur transmet un message CONFACK TERMREQ Terminate-Request Utilisé pour la fermeture LCP TERMACK Terminate-ACK Transmis en réponse à TERMREQ Note: Chaque extrémité transmet des CONFREQ avec les options et les valeurs qu'elle désire. Les options négociées peuvent être différentes pour chaque sens. ccnp_cch

6 Etapes LCP, Authentification et NCP
Dans certaines des phases de PPP décrites précedenment, PPP passe par des étapes spécifiques telles que la négociation LCP, l'authentification et la négociation NCP. Pour plus d'informations sur ces étapes, reférez-vous aux RFC1548 et RFC1661. LCP (étape obligatoire) LCP est une phase dans laquelle les paramètres d'établissement, de configuration et de test de la connexion de liaison de données sont négociés. Un état LCP State Open signifie que la négociation LCP a été réalisée avec succès tandis qu'un état LCP Close signifie que la négociation LCP a échoué. Le schéma ci-dessous représente un exemple d'échange LCP Routeur 1 Routeur 2 CONFREQ Option :Authentification Valeur: PAP Ce routeur accepte l'option Authentification mais pas la valeur PAP. Il répond avec CONFNAK et suggère CHAP CONFNAK Option :Authentification Valeur: CHAP Le routeur est configuré pour accepter PAP ou CHAP CONFREQ Option :Authentification Valeur: CHAP Toutes les options sont acceptées, un CONFACK CONFACK CONFREQ Option :Authentification Valeur: CHAP CONFACK La négociation LCP utilise aussi un paramètre appelé MagicNumber utilisé pour déterminer si la liaison est bouclée. Une valeur aléatoire est transmise sur la liaison et si la même valeur est reçue, le routeur en déduit que la liaison est bouclée. ccnp_cch

7 Résolution de problème avec la commande debug ppp negotiation
Authentification (Etape Optionnelle par défaut) A cette étape, l'authentification est réalisée en utilisant un protocole (PAP ou CHAP) négocié lors de la négociation LCP. NCP (Etape Obligatoire) Cette étape est utilisée pour établir et configurer différents protocoles de couche réseau. Les routeurs échangent des messages IPCP (IP Control Protocol) pour négocier les options spécifiques au protocole. D'après le RFC1332, IPCP négocie deux options : la compression et l'affectation des adresses IP. IPCP est aussi utilisé pour passer des informations relatives au réseau telles que serveurs DNS et serveurs WINS primaire et secondaire La négociation est réalisée avec les messages CONF décrits dans la section Paquets de négociation PPP. Résolution de problème avec la commande debug ppp negotiation Quand vous lisez une sortie de la commande debug ppp negotiation pour résoudre des problèmes, suivez les instructions suivantes: 1. Identifiez les transitions de phases dans la sortie de la commande debug Déterminez l'ordre des phases pour l'établissement de la connexion. Par exemple, UP, Authentification, etc.... Ceci peut aider à identifier la phase pour laquelle la connexion est en echec Pour la phase dans laquelle le problème se produit , recherchez les messages indiquant que LCP, L'authentification ou NCP sont corrects • L'état LCP doit être "open". Vous pouvez également regarder le dernier message CONFACK entrant ou sortant pour vérifier si les paramètres requis ont bien été négociés • L'authentification doit être réussie. Si l'authentification bidirectionnelle est utilisée, chaque transaction doit être réussie • L'état IPCP doit être "open". Vérifiez que l'adressage est correct et qu'une route vers le proche est installée. ccnp_cch

8 Lecture de la sortie de la commande debug ppp negotiation
La majorité des lignes dans la sortie de la commande debug ppp negotiation sont caractérisées par: 1. Une marque de temps (Timestamp). Les marques de temps en millisecondes sont très utiles. 2. Interface et numéro d'interface.Ceci est très utile pour la résolution de problèmes quand plusieurs interfaces sont utilisées.Par exemple, certaines connexions (telles les liaisons Multilink) sont controlées par l'interface physique au début puis par l'interface "dialer" ou l'interface "virtual-access". 3. Type de message PPP. Ceci indique si la ligne est un message PPP général, LCP, PAP , CHAP ou IPCP. 4. Sens du message. Un "I" indique un message entrant , un "O" indique un message sortant. Ceci permet de savoir si le message est généré ou reçu par le routeur. 5. Message. Pour la négociation, cette section inclut les transactions particulières en cours de négociation. 6. Champ ID. Utilisé pour établir la correspondance entre les reqêtes et les réponses. Une réponse peut être associée avec un message entrant utilisant le champ ID. Cette option est particulièrement utile quand le message entrant et la réponse sont très éloignés dans la sortie de la commande debug. 7. Longueur(Length). C'est la longueur du champ information. Ce n'est pas très utile pour la résolution de problème. Note: Les 4 à 7 n'apparaissent pas dans tous les messages PPP, cela dépend de la fonction du message. *Mar 1 00:06:37.034:BR0:1 LCP: I CONFREQ [Listen] id 7 len 17 Timestamp en msec Longueur Champ ID Interface Message Etape ccnp_cch

9 Exemple de sortie de la commande debug ppp negotiation
maui-soho-01#debug ppp negotiation PPP protocol negotiation debugging is on maui-soho-01# *Mar 1 00:06:36.645: %LINK-3UPDOWN: Interface BRI0:1, changed state to up !-- Couche physique établie( couche 1 RNIS) *Mar 1 00:06:36.661: BR0:1 PPP: Treating connection as a callin *Mar 1 00:06:36.665: BR0:1 PPP: Phase is ESTABLISHING, Passive Open (0 sess, 0 load) !-- PPP phase d'établissement. Début de la négociation LCP *Mar 1 00:06:36.669: BR0:1 LCP: State is Listen *Mar 1 00:06:37.034: BR0:1 LCP: I CONFREQ [Listen] id 7 len 17 !-- Message CONFREQ entrant id 7 *Mar 1 00:06:37.038: BR0:1 LCP: AuthProto PAP (0x0304C023) *Mar 1 00:06:37.042: BR0:1 LCP: MagicNumber 0x507A214D (0x A214D) *Mar 1 00:06:37.046: BR0:1 LCP: Callback 0 (0x0D0300) !-- Le proche a requis: !-- Option: Protocole d'authentification, Valeur: PAP !-- Option: MagicNumber (utilisé pour détecter les boucles) !-- Option: Callback, Valeur: 0 (Pour PPP Callback; 6 pour MS Callback) *Mar 1 00:06:37.054: BR0:1 LCP: 0 CONFREQ [Listen] id 4 len 15 !-- Message CONFREQ emis vers le proche avec les paramètres désirés !-- Le champ ID est égal à 4 et n'a pas de relation avec le message précédent *Mar 1 00:06:37.058: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 1 00:06:37.062: BR0:1 LCP: MagicNumber 0x1081E7E1 (0x E7E1) !-- Le routeur a requis: !-- Option: Protocole d'authentification, Valeur: CHAP !-- Option: MagicNumber (utilisé pour détecter les boucles) *Mar 1 00:06:37.066: BR0:1 LCP: 0 CONFREJ [Listen] id 7 len 7 !-- Message CONFREJ pour le message avec l'id 7 !-- C'est la réponse au premier message CONFREQ reçu *Mar 1 00:06:37.070: BR0:1 LCP: Callback 0 (0x0D0300) !-- L'option rejetée est Callback !-- Si le routeur voulait faire du MS Callback au lieu du PPP Callback, !-- il aurait transmis un message CONFNAK *Mar 1 00:06:37.098: BR0:1 LCP: I CONFACK [REQsent] id 4 len 15 !-- Message de réponse au message avec le champ ID égal à 4 *Mar 1 00:06:37.102: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 1 00:06:37.106: BR0:1 LCP: MagicNumber 0x1081E7E1 (0x E7E1) !-- Le proche peut supporter les paramètres requis *Mar 1 00:06:37.114: BR0:1 LCP: I CONFREQ [ACKrcvd] id 8 len 14 !-- Message CONFREQ entrant avec l'ID égal à 8 !-- C'est un message CONFREQ du proche en réponse au CONFREJ id 7 *Mar 1 00:06:37.117: BR0:1 LCP: AuthProto PAP (0x0304C023) *Mar 1 00:06:37.121: BR0:1 LCP: MagicNumber 0x507A214D (0x A214D) !-- Le proche a requis: !-- Option: Protocole d'authentification, Valeur: PAP !-- Option: MagicNumber (utilisé pour détecter les boucles) *Mar 1 00:06:37.125: BR0:1 LCP: O CONFNAK [ACKrcvd] id 8 len 9 !-- Message de réponse au message avec le champ ID égal à 8 *Mar 1 00:06:37.129: BR0:1 LCP: AuthProto CHAP (0x0305C22305) !-- Le routeur reconnaît l'option authentification !-- mais il n'accepte pas PAP et suggère CHAP dans le message CONFNAK ccnp_cch

10 Mar 1 00:06:37. 165: BR0:1 LCP: I CONFREQ [ACKrcvd] id 9 len 15
*Mar 1 00:06:37.165: BR0:1 LCP: I CONFREQ [ACKrcvd] id 9 len 15 !-- Message CONFREQ entrant avec l'ID égal à 9 *Mar 1 00:06:37.169: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 1 00:06:37.173: BR0:1 LCP: MagicNumber 0x507A214D (0x A214D) !-- L'authentification CHAP est requise *Mar 1 00:06:37.177: BR0:1 LCP: O CONFACK [ACKrcvd] id 9 len 15 !-- Message CONFACK émis avec l'ID égal à 9 *Mar 1 00:06:37.181: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 1 00:06:37.185: BR0:1 LCP: MagicNumber 0x507A214D (0x A214D) *Mar 1 00:06:37.189: BR0:1 LCP: State is open !-- L'état de LCP passe à Open *Mar 1 00:06:37.193: BR0:1 PPP: Phase is AUTHENTICATING, by both [0 sess, 0 load] !-- La phase PPP est AUTHENTICATING. L'authentification bidirectionnelle indiquée !-- par le mot-clé "both" va commencer *Mar 1 00:06:37.201: BR0:1 CHAP: O CHALLENGE id 4 len 33 from "maui-soho-01" !-- Challenge CHAP sortant *Mar 1 00:06:37.225: BR0:1 CHAP: I CHALLENGE id 3 len 33 from "maui-soho-03" !-- Challenge entrant venant du proche *Mar 1 00:06:37.229: BR0:1 CHAP: Waiting for peer to authenticate first *Mar 1 00:06:37.237: BR0:1 CHAP: I RESPONSE id 4 len 33 from "maui-soho-03" !-- Réponse du proche *Mar 1 00:06:37.244: BR0:1 CHAP: O SUCCESS id 4 len 4 !-- Le routeur a authentifié le proche avec succès *Mar 1 00:06:37.248: BR0:1 CHAP: Processing saved Challenge, id 3 *Mar 1 00:06:37.260: BR0:1 CHAP: 0 RESPONSE id 3 len 33 from "maui-soho-01" *Mar 1 00:06:37.292: BR0:1 CHAP: I SUCCESS id 3 len 4 !-- Message SUCCESS entrant, les deux extrémités se sont authentifiées *Mar 1 00:06:37.296: BR0:1 PPP: Phase is UP [0 sess, 0 load] !-- La phase de PPP est maintenant UP, la négociation NCP va commencer *Mar 1 00:06:37.304: BR0:1 IPCP: 0 CONFREQ [Closed] id 4 len 10 *Mar 1 00:06:37.308: BR0:1 IPCP: Address (0x0306AC160101) !-- Message CONFREQ émis indiquant que l'adresse locale est *Mar 1 00:06:37.312: BR0:1 CDPCP: O CONFREQ [Closed] id 4 len 4 *Mar 1 00:06:37.320: BR0:1 CDPCP: I CONFREQ [REQSent] id 4 len 4 *Mar 1 00:06:37.324: BR0:1 CDPCP: O CONFACK [REQSent] id 4 len 4 !-- Messages pour le protocole CDP *Mar 1 00:06:37.332: BR0:1 IPCP: I CONFREQ [REQSent] id 4 len 10 *Mar 1 00:06:37.336: BR0:1 IPCP: Address (0x0306AC160102) !-- Message CONFREQ entrant indiquant que l'adresse du proche est !-- Une adresse égale à indique que le proche n'a pas d'adresse et !-- demande au routeur local de lui en fournir par la négociation IPCP *Mar 1 00:06:37.344: BR0:1 IPCP: O CONFACK [REQSent] id 4 len 10 *Mar 1 00:06:37.348: BR0:1 IPCP: Address (0x306AC160102) *Mar 1 00:06:37.356: BR0:1 IPCP: I CONFACK [ACKSent] id 4 len 10 *Mar 1 00:06:37.360: BR0:1 IPCP: Address (0x306AC160101) *Mar 1 00:06:37.363: BR0:1 IPCP: State is Open !-- L'état IPCP est "Open". Notez que dans la négociation IPCP chaque extrémité !-- accepte l'adresse IP du proche et une adresse est affectée au proche. *Mar 1 00:06:37.371: BR0:1 CDPCP: I CONFACK [ACKSent] id 4 len 4 *Mar 1 00:06:37.375: BR0:1 CDPCP: State is Open !-- L'état CDCP est "Open" *Mar 1 00:06:37.387: BR0:1 IPCP: Install route !-- Une route vers le proche est installée *Mar 1 00:06:38.288: %LINEPROTO-UPDOWN: Line protocol on Interface BRI0:1 changed state to up *Mar 1 00:06:42.609: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to maui-soho-03 ccnp_cch

11 Glossaire des messages courants
Usage général CONFREQ(Configure-Request): Quand la couche la plus basse est disponible (Up), un message Configure-Request est transmis pour démarrer la première phase PPP (phase LCP). Ce message est utilisé dans les phases LCP et NCP pour tenter de configurer la connexion. L'équipement ouvre une connexion avec le proche en transmettant ce message avec les options de configuration et les valeurs désirées par l'émetteur. Toutes les options et les valeurs sont négociées en même temps. Si le proche répond avec CONFREJ ou CONFNAK, le routeur transmet un autre CONFREQ avec un nouvel ensemble d'options et de valeurs. CONFACK(Configure-Acknowledge): Si toutes les options dans le message CONFREQ sont reconnues et toutes les valeurs sont acceptées, le routeur transmet un message CONFACK. CONFREJ(Configure-Reject): Si une option quelconque de configuration reçue dans le message CONFREQ n'est pas acceptable ou est non reconnue, le routeur répond avec un message CONFREJ. L'option non acceptée (dans le message CONFREQ) est incluse dans le message CONFREJ. CONFNAK(Configure Negative Acknowledge): Si une option quelconque de configuration reçue dans le message CONFREQ est acceptable mais sa valeur ne l'est pas alors le routeur répond avec un message CONFNAK.Le routeur insère l'option et sa valeur qu'il accepte dans le message CONFNAK. ECHOREQ (Echo Request) et ECHOREP (Echo Reply) PPP utilise des messages de type "keepalive" pour maintenir l'état de la liaison. Ces messages sont des trames ECHOREQ qui sont transmises au host distant qui doit par des trames ECHOREP. Par défaut, si le routeur n'a pas reçu cinq trames ECHOREP consécutives, il considère que la liaison est hors-service et le protocole PPP est fermé. TERMREQ (Termination Request): Cette trame est transmise par le proche qui libère la connexion PPP TERMACK (Termination Acknowledge): Cette trame est transmise en réponse à une trale TERMREQ. Elle libère totalement la connexion PPP et ferme le protocole PPP. ccnp_cch

12 LCP (Line Control Protocol)
TERMINATING: Indique que la connexion PPP a été libérée. Une connexion LCP ou NCP peut être libérée par: Fermeture Administrative (LCP seulement) Quand la couche physique passe hors-service Quand les négociations échouent Sur détection de bouclage de liaison L'entrée dans cette phase se fait aussi sur réception d'une trame TERMREQ venant du host PPP distant. LCP (Line Control Protocol) ACCM (Asynchronous Control Character Map): C'est une des options négociées dans le message CONFREQ. ACCM fixe les séquences Escape de contrôle. ACCM indique au port quels sont les caractères de contrôle à ignorer dans le flux de données. Si le routeur à l'autre extrémité ne supporte pas l'option ACCM, le port est forcé d'utiliser FFFFFFFF. Dans ce cas vous devez utiliser la commande : ppp accm match 000a000 ACFC (Address and Control Field Compression): Option LCP qui permet de transmettre les messages plus efficacement AuthProto <Authentication Protocol): C'est le type de protocole d'authentification négocié dans le message CONFREQ. Il doit être agrée par les deux extrémités durant la phase de négociation. Cette option n'apparaît pas si aucune authentification n'a été configurée. Les valeurs possibles sont CHAP ou PAP Callback "#": Option de Callback négociée. Le numéro après le mot-clé Callback indique quel est le type de Callback négocié. Le numéro 0 indique un Callback PPP tandis que le numéro 6 indique un Callback de type Microsoft disponible sur les routeurs Cisco. CHAP (Challenge Handshake Authentication Protocol): Indique que le protocole d'authentification négocié est CHAP EndpointDisc (End Point Discriminator): Option LCP utilisée pour identifier un proche PPP dans une connexion PPP Multilink ccnp_cch

13 ccnp_cch LCP:State is Open:
Cette ligne indique que la négociation PPP a réussi. LQM (Line Quality Monitoring) Line Quality Monitoring est disponible (LQM) est disponible sur les liaisons séries avec PPP. LQM contrôle la qualité de la ligne et déconnecte la liaison quand la qualité passe en dessous d'un pourcentage configuré. Les pourcentages sont calculés pouer les sens entrants et sortants. Quand LQM est validé, des LQR (Link Quality Report) sont transmis à chaque période de "keepalive". Les LQRs sont transmis à la place des "keepalive". Si LQM n'est pas configuré, des messages "keepalive" sont transmis périodiquement et tous les messages LQR entrants ont une réponse avec un autre LQR. MagicNumber Le support du MagicNumber est disponible sur toutes les interfaces série. Lors de son utilisation PPP tente toujours de négocier les MagicNumbers qui sont utilisés pour déterminer si la liaison est bouclée. Une chaine aléatoire est transmise dans les messages et si celle-ci est reçue en retour , le routeur en déduit que la liaison est bouclée. La liaison sera mise hors-service sur détection de bouclage d'après l'utilisation de la commande down-when-looped. PAP (Password Authentification Protocol) Indique que le protocole d'authentification négocié par les hosts PPP est PAP. PFC (Protocol Field Compression) Cette option est positionnée "ON" ou "OFF" pour les champs protocole de la compression. MRRU (Max Receive Reconstructed Unit) C'est une option LCP négociée durant l'établissement LCP PPP Multilink qui détermine le nombre maximum d'octets pouvant constituer une trame. SI MRRU n'est pas négociée dans LCP, PPP multilink ne peut pas être utilisé sur cette liaison. MRU (Maximum Received Unit) Option LCP négociée dans le message CONFREQ pour fixer la taille maximum des paquets échangés. ccnp_cch

14 Authentification ccnp_cch AUTH-REQ (Authentication Request):
Cette trame est transmise par le host PPP local sur lequel l'authentification est validée pour demander au host distant de transmettre un nom d'utilisateur et un mot de passe pour s'authentifier. Cette trame est utilisée uniquement avec PAP. AUTH-ACK (Authentication Acknowledge): Cette trame est trame est transmise par le proche s'authentifiant. Cette trame transporte le nom d'utilisateur et le mot de passe. Cette trame est utilisée uniquement avec PAP. AUTH-NAK or FAILURE: Cette trame est tramise par le proche PPP Authentifiant quand l'authentification est en échec sur le proche PPP authentifiant. CHALLENGE: C'est la trame CHAP Challenge transmise depuis le proche PPP authentifiant vers le proche à authentifier. La trame Challenge est constituée d'un ID, d'un nombre aléatoire et soit du nom local du serveur d'accès soit du nom d'utilisateur distant. Cette trame est utilisée uniquement avec CHAP. RESPONSE: C'est la trame de réponse CHAP transmise par le proche PPP en authentification vers le proche PPP authentifiant. La réponse est constituée de deux parties: Une valeur hash MD Soit le nom local du serveur d'accès soit le nom d'utilisateur distant. Cette trame est utilisée uniquement avec CHAP. ccnp_cch

15 NCP (Network Control Protocol)
Address a.b.c.d: - Pour un message CONFREQ sortant ce message indique l'adresse que le routeur local désire utiliser. Si l'adresse est la machine locale demande au proche de lui fournir une adresse IP Pour un message CONFREQ entrant ce message indique l'adresse que le routeur de lui fournir une adresse IP. - Pour un message CONFNAK sortant ce message indique l'adresse IP que le proche doit utiliser au lieu de celle suggérée dans le message CONFREQ. - Pour un message CONFNAK entrant ce message indique l'adresse IP que le host local doit utiliser au lieu de celle suggérée dans le message CONFREQ. - Pour un message CONFACK sortant ce message indique l'adresse IP requise par le est acceptable pour la machine locale - Pour un message CONFACK entrant ce message indique l'adresse IP requise par le host local est acceptable par le proche. CCP (Compression Control Protocol): Ceci indique qu'un protocole de compression est en cours de négociation entre les extrémités PPP. L'IOS Cisco supporte les protocoles suivants pouvant être négociés sur une connexion PPP: MS-Point-to-Point Compression (MS-PPC), Stacker, et Predictor CDPCP (Cisco Discovery Control Protocol): Indique une négociation CDP dans la phase NCP. Pour dévalider cdp sur le routeur utilisez la commande no cdp run CODEREJ (Code Reject): Un paquet code-reject est transmis en réponse à la réception d'un code de paquet inconnu par le host PPP distant. Install route to a.b.c.d: Le routeur en fin de phase IPCP (NCP pour le protocole de couche 3 IP) doit installer une route vers le host distant PPP dans la table de routage et celle-ci doit apparaître comme "connected" dans la table de routage. Si vous ne voyez pas ce message, vérifiez que no peer neighbor-route n'a pas été configuré. ccnp_cch

16 ccnp_cch IPCP( IP Control Protocol):
Indique que IP est le protocole de couche réseau en cours de négociation NCP IPCP: State Open: Ceci indique que IPCP a été négocié avec succès PROTREJ (Protocol Reject): Le proche PPP, sur réception d'un protocol non reconnu, utilise le message PROTREJ pour indiquer que le proche tente d'utiliser un protocole non supporté. A la réception de ce message le proche doit arreter de transmettre les paquets indiquant ce protocole dès que possible. ccnp_cch