Stroomdiagram voor PPP-probleemoplossing

Inleiding

Dit stroomschema helpt u bij het oplossen van point-to-point Protocol (PPP), dat veel wordt gebruikt voor meerdere oplossingen op het gebied van toegangstechnologie.

In de onderstaande stroomschema's en voorbeelduitvoer hebben we een ISDN-basisinterface (Integrated Services Digital Network) (BRI) PPP-verbinding naar een ander gebruik van ETHERNET Dialer-on-Demand Routing (DDR) ingesteld. Dezelfde stappen voor het oplossen van problemen zijn echter van toepassing op verbindingen met andere routers (zoals filialen) met PPP-verbindingen bij gebruik van Dialer Rotary-Group, Dialer Profile of PPP via seriële koppelingen.

Voor verdere informatie over Point-to-Point Protocol, en de ondersteunde functies in Cisco IOS® software, zie Cisco Learning Connection (alleen geregistreerde klanten) en zoekactie met het sleutelwoord ppp in het veld Zoeken naar training.

Voor een gedetailleerde uitleg van de verschillende fasen van PPP-onderhandeling en de uitvoer van debug ppp-onderhandeling, raadpleegt u PPP Password-verificatie (PAP) configureren en probleemoplossing.

Voorwaarden

Vereisten

Zorg ervoor dat u aan deze voorwaarden voldoet:

• Schakel debug ppp onderhandeling in en debug ppp authenticatie in.

• U moet de debug-onderhandelingoutput lezen en begrijpen. Raadpleeg het gedeelte Debug ppp onderhandeling voor meer informatie.

• De PPP-verificatiefase begint niet totdat de LCP-fase (Link Control Protocol) is voltooid en in "open" staat. Als de debug van de PPP-onderhandeling er niet op wijst dat LCP open is, Probleemoplossing voor deze kwestie voordat u doorgaat.

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

Terminologie

Lokale machine (of lokale router): Dit is het systeem waarop de debugsessie momenteel wordt uitgevoerd. Aangezien u de debugsessie van de ene router naar de andere verplaatst, pas de term "lokale machine" op de andere router toe.

Peer: Het andere uiteinde van de point-to-point link. Daarom is dit apparaat niet de lokale machine.

Bijvoorbeeld, als u de debug ppp onderhandeling opdracht op RouterA voert, is dit de lokale machine, en RouterB is de peer. Als u echter de debugging overhevelen naar RouterB, dan wordt het de lokale machine en RouterA wordt de peer.

Opmerking: de termen lokale machine en peer impliceren geen client-server relatie. Afhankelijk van de plaats waar de debug sessie wordt uitgevoerd, kan de dialinclient de lokale machine of peer zijn.

Conventies

Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.

Stroomdiagrammen voor probleemoplossing

Dit document bevat een aantal stroomschema's om te helpen bij het oplossen van problemen.

N.B.: Als u problemen wilt oplossen, slaat u geen van de stappen over die in deze stroomschema's worden weergegeven.

LCP-fase (PPP Link Control Protocol)

Asynchrone modems gebruikt voor PPP-connectiviteit

Deze sectie legt uit hoe asynchrone modems kunnen worden gebruikt voor PPP-connectiviteit. De uitgaande LCP-frames worden op de lokale router gezien, maar er zijn geen inkomende LCP-frames.

In dit geval zou het probleem te wijten kunnen zijn aan een van de twee mogelijkheden:

• De modems van zowel de lokale router als de router op afstand trainen, maar PPP begint niet op de router op afstand. Als u dit probleem wilt oplossen, raadpleegt u de modems wel goed trainen, maar PPP start de sectie niet in het document Problemen oplossen/modems.

• De modems van zowel de lokale als externe routers trainen wel Oke op en PPP begint op beide routers, maar de oproep daalt onmiddellijk. Dit vernietigt elke kans op het ontvangen van inkomende LCP-frames vanuit externe routers. Raadpleeg de modems voor het oplossen van dit probleem als u het probleem wilt oplossen, maar PPP start, maar de sectie voor het later oproepen van het oproepen van het OCR-document laat de informatie over probleemoplossing vallen.

Raadpleeg voor meer informatie over probleemoplossing de modems voor probleemoplossing.

PPP-opties voor uitgaande LCP-opties

Het onderstaande stroomschema benadrukt een aantal van de meest gebruikelijke LCP-parameters die tijdens de LCP-fase kunnen worden onderhandeld. Dit stroomschema helpt u om te plaatsen welke LCP parameters uw lokale machine niet met de PPP externe peer onderhandelt.

PPP-verificatiefase

Het Point-to-Point Protocol biedt een optionele fase die de netgebruiker een beveiligde datatransmissie garandeert om de netwerkbeveiliging te verbeteren. Op sommige verbindingen kan het wenselijk zijn om een peer PPP te vereisen om zichzelf voor te authentiek te verklaren alvorens de pakketten van het netwerk-laag protocol te toestaan om te worden uitgewisseld. Voor elke PPP-implementatie is de verificatiefase standaard optioneel. Als een PPP netwerkbeheerder de PPP peer om een specifiek authentificatieprotocol wil gebruiken, moet hij het gebruik van dat authenticatieprotocol tijdens de PPP LCP fase vragen. Dat wil zeggen, het gebruikte verificatieprotocol moet een van de overeengekomen PPP LCP-opties tussen beide PPP-peers zijn.

In deze fase zijn alleen PPP LCP, verificatieprotocol en link Quality-monitoringpakketten toegestaan tijdens de verificatiefase. Zorg ervoor dat er in dit stadium geen problemen zijn met door PPP onderhandelde parameters voordat u de stappen voor het oplossen in deze sectie volgt.

Voor gedetailleerde informatie over probleemoplossing voor problemen met PPP-verificatiefase, raadpleeg het stroomschema van Problemen opsporen en verhelpen PPP (CHAP of PAP)-verificatie.

PPP NCP-onderhandelingen

Terwijl de verschillende Network Control Protocols (NCP’s) zeer verschillend zijn in de gegevens waarover onderhandeld wordt, is de algemene structuur van het gesprek gelijk, ongeacht welke protocollen worden gebruikt. Deze sectie bestrijkt alleen IP (IPCP) NCP protocolonderhandeling.

De output hieronder toont de debug uitvoer voor een succesvolle IP-onderhandeling tijdens PPP NCP-onderhandeling:

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 gaat niet naar open staat in NCP onderhandelingsfase

Problemen met PPP-linkstabiliteit

Zoals in het onderstaande stroomschema staat, op dit punt, is de link omhoog en passeren pakketten, maar het gedraagt zich niet zoals het zou moeten.

Kan pakketten niet via een IP PPP-link routeren

De output hieronder toont de tonen bezoeker gebruiker en toont IP interface korte opdrachtoutput wanneer een vraag met succes wordt beëindigd en IP pakketten kunnen naar de afstandsbediening over de PPP verbinding worden verzonden.

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

fouten in IP-pool

Andere problemen met betrekking tot de koppelingsstabiliteit

IP Layer 2 Bind-falen

Gerelateerde informatie

• Ondersteuning van inbel- en toegangstechnologie
• De betekenis van debug ppp-onderhandeling
• Het begrijpen en configureren van PPP CHAP-verificatie
• PPP-verificatie met behulp van de ppp chap hostname en ppp-verificatie ketting om opdrachten aan te roepen
• Configuratie- en probleemoplossing van PPP Password-verificatie Protocol (PAP)
• Problemen oplossen PPP (CHAP of PAP)-verificatie
• Technische ondersteuning en documentatie – Cisco Systems