WAN : Protocole point à point (PPP)

Organigramme du dépannage PPP

16 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Cet organigramme vous aide à dépanner le protocole point-à-point (PPP), largement utilisé pour les solutions technologiques à plusieurs accès.

Dans les organigrammes et le résultat présenté d'échantillon ci-dessous, nous avons installé une connexion PPP d'accès de base (BRI) d'Integrated Services Digital Network (le RNIS) à l'autre utilisant le routage existant de Numéroteur-sur-exigence (DDR). Cependant, les mêmes étapes de dépannage s'appliquent aux connexions à d'autres Routeurs (tels que des succursales) avec des connexions PPP en utilisant le groupe rotatif de routeurs d'appels, le profil du numéroteur, ou le PPP au-dessus des liaisons série.

Pour plus d'informations sur le protocole point-à-point, et ses caractéristiques prises en charge en logiciel de Cisco IOSÝ, référez-vous à Cisco apprenant la connexion (clients enregistrés seulement) et la recherche utilisant le ppp de mot clé dans le domaine de formation de rechercher.

Pour une explication détaillée des différentes phases de la négociation PPP et de la sortie du debug ppp negotiation, référez-vous en configurant et dépannage du Password Authentication Protocol (PAP) de PPP.

Conditions préalables

Conditions requises

Assurez-vous que vous rencontrez ces conditions préalables :

  • Debug ppp negotiation et debug ppp authentication d'enable.

  • Vous devez lire et comprendre la sortie de debug ppp negotiation. Pour plus d'informations, reportez-vous à Comprendre les sorties de la commande debug ppp negotiation.

  • La phase d'authentification de PPP ne commence pas jusqu'à ce que la phase du Link Control Protocol (LCP) soit complète et soit dans « ouvrent » l'état. Si le debug ppp negotiation n'indique pas que LCP est ouvert, dépannez cette question avant que vous poursuiviez.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Terminologie

Ordinateur local (ou routeur local) : C'est le système que la session d'élimination des imperfections actuellement est exécutée en fonction. Comme vous déplacez la session de débogage d'un routeur à l'autre, appliquez le terme « ordinateur local » à l'autre routeur.

Pair : L'autre fin du lien point par point. Par conséquent, ce périphérique n'est pas l'ordinateur local.

Par exemple, si vous exécutez la commande de debug ppp negotiation sur le RouterA, c'est l'ordinateur local, et le RouterB est le pair. Cependant, si vous décalez l'élimination des imperfections plus d'au RouterB, puis ce devient l'ordinateur local et le RouterA va bien au pair.

Remarque: Les termes ordinateur local et pair n'impliquent pas des relations de client-serveur. Selon où la session de débogage est exécutée, le client entrant pourrait être l'ordinateur local ou le pair.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Dépannage des organigrammes

Ce document comporte quelques organigrammes pour aider au dépannage.

Remarque: Afin de dépanner avec succès, n'ignorez pas les étapes l'unes des affichées dans ces organigrammes.

Phase du Link Control Protocol de PPP (LCP)

/image/gif/paws/42887/ppp-tshoot-gen-01.gif

Modems asynchrones utilisés pour la Connectivité de PPP

Cette section explique comment des modems asynchrones peuvent être utilisés pour la Connectivité de PPP. Des trames LCP sortantes sont vues sur le routeur local, mais il n'y a aucune trame LCP entrante.

Dans ce cas, le problème a pu être dû à une de deux possibilités :

Pour plus d'informations détaillées sur le dépannage de modem, référez-vous aux Modems de dépannage.

Options sortantes du PPP LCP

L'organigramme ci-dessous met en valeur plusieurs des paramètres du PPP les plus communs LCP qui peuvent être négociés pendant la phase LCP. Cet organigramme vous aide à situer que les paramètres LCP votre ordinateur local de PPP n'est pas en pourparlers avec le pair de distant de PPP.

ppp-tshoot-gen-02.gif

Phase d'authentification de PPP

Le protocole point-à-point fournit une phase facultative qui garantit l'utilisateur du réseau une transmission de données sécurisée pour améliorer la sécurité des réseaux. Sur quelques liens il peut être desirable d'exiger d'un pair de PPP de s'authentifier avant de permettre des paquets de protocole de couche réseau à permuter. Pour n'importe quelle implémentation de PPP, la phase d'authentification est facultative par défaut. Si un administrateur réseau de PPP veut que le pair de PPP utilise un protocole d'authentification spécifique, il doit demander l'utilisation de ce protocole d'authentification pendant la phase du PPP LCP. C'est-à-dire, le protocole d'authentification utilisé doit être l'une des options négociées du PPP LCP entre les deux pairs de PPP.

À ce stade, on permet seulement le PPP LCP, le protocole d'authentification, et les paquets de surveillance de qualité de lien pendant la phase d'authentification. Assurez-vous qu'il n'y a aucun problème à ce stade avec aucun paramètre LCP-négocié par PPP avant de suivre les étapes de dépannage dans cette section.

Pour l'information de dépannage détaillée pour des problèmes de phase d'authentification de PPP, référez-vous à l'organigramme d'authentification de PPP de dépannage (CHAP ou PAP).

Négociations de NCP de PPP

Tandis que les différents protocoles de contrôle de réseau (NCPs) varient considérablement dans les données étant négociées, la structure globale de la conversation est semblable n'importe ce que des protocoles sont utilisés. Cette section couvre seulement la négociation de protocole de NCP IP (IPCP).

ppp-tshoot-gen-03.gif

La sortie ci-dessous affiche la sortie de débogage pour une négociation réussie IP pendant la négociation de NCP de PPP :

As4 PPP: Phase is UP
 As4 IPCP: O CONFREQ [Not negotiated] id 1 len 10
 As4 IPCP:    Address 10.1.2.1 (0x03060A010201)
 As4 IPCP: I CONFREQ [REQsent] id 1 len 28
 As4 IPCP:    CompressType VJ 15 slots CompressSlotID (0x0206002D0F01)
 As4 IPCP:    Address 0.0.0.0 (0x030600000000)
 As4 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
 As4 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
 As4 IPCP: O CONFREJ [REQsent] id 1 len 10
 As4 IPCP:    CompressType VJ 15 slots CompressSlotID (0x0206002D0F01)
 As4 CCP: I CONFREQ [Not negotiated] id 1 len 15
 As4 CCP:    MS-PPC supported bits 0x00000001 (0x120600000001)
 As4 CCP:    Stacker history 1 check mode EXTENDED (0x1105000104)
 As4 LCP: O PROTREJ [Open] id 3 len 21 protocol CCP
 As4 LCP:  (0x80FD0101000F12060000000111050001)
 As4 LCP:  (0x04)
 As4 IPCP: I CONFACK [REQsent] id 1 len 10
 As4 IPCP:    Address 10.1.2.1 (0x03060A010201)
 %LINEPROTO-5-UPDOWN: Line protocol on Interface Async4, changed state to up
 As4 IPCP: I CONFREQ [ACKrcvd] id 2 len 22
 As4 IPCP:    Address 0.0.0.0 (0x030600000000)
 As4 IPCP:    PrimaryDNS 0.0.0.0 (0x810600000000)
 As4 IPCP:    SecondaryDNS 0.0.0.0 (0x830600000000)
 As4 IPCP: O CONFNAK [ACKrcvd] id 2 len 22
 As4 IPCP:    Address 10.1.2.2 (0x03060A010202)
 As4 IPCP:    PrimaryDNS 10.2.2.3 (0x81060A020203)
 As4 IPCP:    SecondaryDNS 10.2.3.1 (0x83060A020301)
 As4 IPCP: I CONFREQ [ACKrcvd] id 3 len 22
 As4 IPCP:    Address 10.1.2.2 (0x03060A010202)
 As4 IPCP:    PrimaryDNS 10.2.2.3 (0x81060A020203)
 As4 IPCP:    SecondaryDNS 10.2.3.1 (0x83060A020301)
 ip_get_pool: As4: validate address = 10.1.2.2
 ip_get_pool: As4: using pool default
 ip_get_pool: As4: returning address = 10.1.2.2
 set_ip_peer_addr: As4: address = 10.1.2.2 (3) is redundant
 As4 IPCP: O CONFACK [ACKrcvd] id 3 len 22
 As4 IPCP:    Address 10.1.2.2 (0x03060A010202)
 As4 IPCP:    PrimaryDNS 10.2.2.3 (0x81060A020203)
 As4 IPCP:    SecondaryDNS 10.2.3.1 (0x83060A020301)
 As4 IPCP: State is Open
 As4 IPCP: Install route to 10.1.2.2

IPCP n'entre pas dans l'état ouvert dans la phase de négociation de NCP

ppp-tshoot-gen-04.gif

Problèmes de stabilité de lien de PPP

Comme stipulé dans l'organigramme ci-dessous, en ce moment, le lien est en hausse et passant des paquets, mais il ne se comporte pas comme il faudrait.

ppp-tshoot-gen-05.gif

Ne peut pas conduire des paquets au-dessus d'un lien de PPP IP

ppp-tshoot-gen-06.gif

La sortie ci-dessous affiche que la commande brief d'utilisateur et de show ip interface de show caller a sorti quand un appel est terminé avec succès et des paquets IP peuvent être envoyés au pair distant au-dessus de la connexion PPP.

maui-soho-01#show caller user maui-soho-02 detail
   User: maui-soho-02, line BR0:1, service PPP
   Active time 00:02:21, Idle time 00:00:57
   Timeouts: Absolute Idle
   Limits: - 00:02:00 
   Disconnect in: - 00:01:02 
   PPP: LCP Open, CHAP (local <--> local), IPCP
   LCP: -> peer, AuthProto, MagicNumber
   <- peer, AuthProto, MagicNumber
   NCP: Open IPCP
   IPCP: <- peer, Address
   -> peer, Address
   Dialer: Connected to #, inbound
   Idle timer 120 secs, idle 57 secs
   Type is ISDN, group BRI0
   IP: Local 10.0.1.1/24, remote 10.0.1.2
   Counts: 123 packets input, 3246 bytes, 0 no buffer
   0 input errors, 0 CRC, 0 frame, 0 overrun
   119 packets output, 2940 bytes, 0 underruns
   0 output errors, 0 collisions, 0 interface resets
   maui-soho-01#show ip interface brief
   Interface IP-Address OK? Method Status Protocol
   BRI0 10.0.1.1 YES NVRAM up up 
   BRI0:1 unassigned YES unset up up 
   BRI0:2 unassigned YES unset down down 
   Ethernet0 172.22.53.160 YES NVRAM up up 
   Serial0 unassigned YES NVRAM administratively down down

Erreurs de pool d'IP

ppp-tshoot-gen-07.gif

D'autres questions de stabilité de lien pp

ppp-tshoot-gen-08.gif

Pannes de grippage de la couche 2 IP

ppp-tshoot-gen-09.gif

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 42887