Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Terminologie

Konventionen

Fehlerbehebung Flussdiagramme

PPP Link Control Protocol (LCP)-Phase

PPP-Optionen für ausgehende LCP

PPP-Authentifizierungsphase

PPP-NCP-Verhandlungen

IPCP wird in der NCP-Verhandlungsphase nicht in den offenen Zustand überführt

Probleme mit der Stabilität von PPP-Verbindungen

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

IP-Pool-Fehler

Weitere Probleme mit der Stabilität von PP-Verbindungen

IP-Layer-2-Bind-Fehler

Zugehörige Informationen

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