PPP-Fehlerbehebung Flussdiagramm

Einführung

Dieses Ablaufdiagramm unterstützt Sie bei der Fehlerbehebung für das Point-to-Point Protocol (PPP), das häufig für mehrere Access-Technologielösungen verwendet wird.

In den Flussdiagrammen und der unten gezeigten Beispielausgabe haben wir mithilfe von Legacy Dialer-on-Demand Routing (DDR) eine ISDN-PPP-Verbindung (Basic Rate Interface) für eine andere Schnittstelle eingerichtet. Die gleichen Fehlerbehebungsschritte gelten jedoch auch für Verbindungen zu anderen Routern (z. B. Zweigstellen) mit PPP-Verbindungen, wenn Dialer Rotary-Group, Dialer Profile oder PPP über serielle Verbindungen verwendet wird.

Weitere Informationen zum Point-to-Point-Protokoll und den unterstützten Funktionen der Cisco IOS®-Software finden Sie in Cisco Learning Connection (nur registrierte Kunden). Suchen Sie dort unter dem Stichwort ppp im Feld "Nach Schulungen suchen".

Eine ausführliche Erläuterung der verschiedenen Phasen der PPP-Aushandlung und der Ausgabe der Debug-PPP-Aushandlung finden Sie unter Konfigurieren und Beheben von PPP Password Authentication Protocol (PAP).

Voraussetzungen

Anforderungen

Stellen Sie sicher, dass Sie die folgenden Voraussetzungen erfüllen:

• Aktivieren Sie Debug-PPP-Aushandlung und Debug-PPP-Authentifizierung.

• Sie müssen die Debug-ppp-Aushandlung lesen und verstehen. Weitere Informationen finden Sie unter Grundlagen der Debug-PPP-Aushandlung.

• Die PPP-Authentifizierungsphase beginnt erst, wenn die Phase des Link Control Protocol (LCP) abgeschlossen ist und sich im "offenen" Zustand befindet. Wenn die Debug-PPP-Aushandlung nicht anzeigt, dass das LCP offen ist, beheben Sie dieses Problem, bevor Sie fortfahren.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.

Terminologie

Lokaler Computer (oder lokaler Router): Dies ist das System, auf dem die Debugsitzung gerade ausgeführt wird. Wenn Sie die Debugsitzung von einem Router auf den anderen verschieben, übernehmen Sie den Begriff "lokales System" auf den anderen Router.

Peer: Das andere Ende der Punkt-zu-Punkt-Verbindung. Daher ist dieses Gerät nicht der lokale Computer.

Wenn Sie beispielsweise den Befehl debug ppp negotiation auf RouterA ausführen, ist dies der lokale Computer, und RouterB ist der Peer. Wenn Sie das Debuggen jedoch auf RouterB verschieben, wird es zum lokalen Computer und RouterA zum Peer.

Hinweis: Die Begriffe "lokales System" und "Peer" implizieren keine Beziehung zwischen Client und Server. Je nachdem, wo die Debugsitzung ausgeführt wird, kann der Wählclient der lokale Computer oder Peer sein.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).

Fehlerbehebung Flussdiagramme

Dieses Dokument enthält Ablaufdiagramme, die bei der Fehlerbehebung helfen.

Hinweis: Um die Fehlerbehebung erfolgreich durchzuführen, dürfen Sie keine der in diesen Flussdiagrammen aufgeführten Schritte überspringen.

PPP Link Control Protocol (LCP)-Phase

Asynchrone Modems für PPP-Verbindungen

In diesem Abschnitt wird erläutert, wie asynchrone Modems für PPP-Verbindungen verwendet werden können. Ausgehende LCP-Frames werden auf dem lokalen Router angezeigt, es gibt jedoch keine eingehenden LCP-Frames.

In diesem Fall könnte das Problem auf eine von zwei Möglichkeiten zurückzuführen sein:

• Die Modems sowohl des lokalen Routers als auch des Remote-Routers werden aktiviert, aber PPP startet auf dem Remote-Router nicht. Um dieses Problem zu beheben, lesen Sie den Abschnitt Modems "Modems in Ordnung", PPP startet jedoch nicht im Abschnitt "Modems-Fehlerbehebung".

• Die Modems der lokalen Router und der Remote-Router sind in Ordnung, und PPP beginnt auf beiden Routern, aber der Anruf wird sofort beendet. Dadurch wird jede Möglichkeit des Empfangs eingehender LCP-Frames von Remote-Routern zunichte gemacht. Um dieses Problem zu beheben, lesen Sie den Abschnitt Modems do train up okay, PPP starts, aber der Anruf wird später im Dokument Troubleshooting Modems (Fehlerbehebung bei Modems) beendet.

Ausführlichere Informationen zur Modemfehlerbehebung finden Sie unter Modems-Fehlerbehebung.

PPP-Optionen für ausgehende LCP

Im folgenden Flussdiagramm werden einige der gebräuchlichsten PPP-LCP-Parameter hervorgehoben, die während der LCP-Phase ausgehandelt werden können. Dieses Flussdiagramm hilft Ihnen herauszufinden, welche LCP-Parameter Ihr lokales PPP-System nicht mit dem PPP-Remote-Peer verhandelt.

PPP-Authentifizierungsphase

Das Point-to-Point-Protokoll bietet eine optionale Phase, die dem Netzwerkbenutzer eine sichere Datenübertragung zur Verbesserung der Netzwerksicherheit garantiert. Bei einigen Verbindungen kann es wünschenswert sein, dass sich ein PPP-Peer authentifiziert, bevor der Austausch von Protokollpaketen der Netzwerkschicht zugelassen wird. Für jede PPP-Implementierung ist die Authentifizierungsphase standardmäßig optional. Wenn ein PPP-Netzwerkadministrator möchte, dass der PPP-Peer ein bestimmtes Authentifizierungsprotokoll verwendet, muss er die Verwendung dieses Authentifizierungsprotokolls während der PPP-LCP-Phase anfordern. Das heißt, das verwendete Authentifizierungsprotokoll muss eine der ausgehandelten PPP-LCP-Optionen zwischen beiden PPP-Peers sein.

In dieser Phase sind während der Authentifizierungsphase nur PPP LCP, das Authentifizierungsprotokoll und die Pakete zur Überwachung der Verbindungsqualität zulässig. Stellen Sie sicher, dass derzeit keine Probleme mit über PPP ausgehandelten LCP-Parametern auftreten, bevor Sie die Schritte zur Fehlerbehebung in diesem Abschnitt befolgen.

Detaillierte Informationen zur Fehlerbehebung bei Problemen in der PPP-Authentifizierungsphase finden Sie im Fehlerbehebungs-PPP (CHAP oder PAP) Authentication Flow Chart.

PPP-NCP-Verhandlungen

Während sich die Daten in den verhandelten Netzwerksteuerungsprotokollen (NCPs) stark unterscheiden, ist die Gesamtstruktur der Konversation unabhängig von den verwendeten Protokollen ähnlich. Dieser Abschnitt behandelt nur die Aushandlung des IP-NCP-Protokolls (IPCP).

Die folgende Ausgabe zeigt die Debug-Ausgabe für eine erfolgreiche IP-Aushandlung während der PPP-NCP-Aushandlung:

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 wird in der NCP-Verhandlungsphase nicht in den offenen Zustand überführt

Probleme mit der Stabilität von PPP-Verbindungen

Wie im unten stehenden Flussdiagramm angegeben, ist die Verbindung an diesem Punkt aktiv und leitet Pakete weiter, verhält sich aber nicht so, wie sie sollte.

Pakete können nicht über eine IP-PPP-Verbindung geroutet werden.

Die folgende Ausgabe zeigt den Benutzer des Anrufers anzeigen und die Befehlsausgabe für die IP-Schnittstellenbeschreibung anzeigen, wenn ein Anruf erfolgreich beendet wird und IP-Pakete über die PPP-Verbindung an den Remote-Peer gesendet werden können.

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

IP-Pool-Fehler

Weitere Probleme mit der Stabilität von PP-Verbindungen

IP-Layer-2-Bind-Fehler

Zugehörige Informationen

• Unterstützung von DFÜ- und Zugriffstechnologie
• Debugging-PPP-Aushandlung
• PPP CHAP-Authentifizierung verstehen und konfigurieren
• PPP-Authentifizierung mit dem PPP-chap-Hostnamen und den ppp-Authentifizierungschap-Callin-Befehlen
• Konfiguration und Fehlerbehebung für PPP Password Authentication Protocol (PAP)
• Fehlerbehebung Authentifizierung nach PPP (CHAP oder PAP)
• Technischer Support und Dokumentation - Cisco Systems