Cisco DSL Router Configuration and Troubleshooting Guide - PPPoE: DSL-Router als PPPoE-Client-Fehlerbehebung

Einführung

Es gibt viele Gründe, warum Ihre DSL-Verbindung (Digital Subscriber Line) möglicherweise nicht ordnungsgemäß funktioniert. Ziel dieses Dokuments ist es, die Fehlerursache zu isolieren und zu beheben. Der erste Schritt zur Fehlerbehebung besteht darin, festzustellen, welche Ebene des ADSL-Diensts (Asynchronous Digital Subscriber Line) fehlschlägt. Der Ausfall kann auf drei Ebenen auftreten.

• Layer 1 - Physische DSL-Konnektivität zum Digital Subscriber Line Access Multiplexer (DSLAM) Ihres ISP

• Layer 2.1 - ATM-Konnektivität

• Layer 2.2 - Point-to-Point Protocol over ATM (PPPoA), Point-to-Point Protocol over Ethernet (PPPoE), RFC1483 Bridging oder RFC1483 Routing

• Layer 3 - IP

Am einfachsten können Sie ermitteln, auf welcher Ebene Sie die Fehlerbehebung beginnen sollen, indem Sie den Befehl show ip interface brief eingeben. Die Ausgabe dieses Befehls unterscheidet sich je nach Konfiguration geringfügig.

827-ESC#show ip interface brief
Interface     IP-Address     OK?     Method    Status     Protocol
ATM0          unassigned     YES     manual 	   up         up
ATM0.1        unassigned     YES     unset  	   up         up
Ethernet0     10.10.10.1     YES     manual    up         up

Wenn die Status von ATM0 und ATM0.1 aktiv sind und das Protokoll aktiviert ist, beginnen Sie mit der Fehlerbehebung auf Layer 2.

Wenn die ATM-Schnittstellen ausgefallen sind oder weiterhin hochfahren und dann ausfallen (sie bleiben nicht auf und ab), beginnen Sie mit der Fehlerbehebung auf Layer 1.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

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

Konventionen

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

Layer-1-Probleme

Ist die Beleuchtung des Carrier Detection (CD) an der Vorderseite des Cisco DSL-Routers ein- oder ausgeschaltet?

Wenn die CD-Lampe leuchtet, fahren Sie mit dem Abschnitt Layer-2-Probleme in diesem Dokument fort.

Wenn die CD-Lampe nicht leuchtet, fahren Sie mit der nächsten Frage fort.

Verwendet Ihr ISP einen DSLAM, der den Alcatel-Chipsatz unterstützt?

Überprüfen Sie diese Informationen mit Ihrem ISP.

Ist der DSL-Anschluss auf der Rückseite des Cisco DSL-Routers an die DSL-Wandbuchse angeschlossen?

Wenn der DSL-Anschluss nicht an die DSL-Wandbuchse angeschlossen ist, schließen Sie den Anschluss mit einem 4-poligen oder 6-poligen RJ-11-Kabel an die Wand an. Dies ist ein Standard-Telefonkabel.

Ist die ATM-Schnittstelle administrativ ausgefallen?

Führen Sie den folgenden Befehl im Aktivierungsmodus des Routers aus, um zu ermitteln, ob die ATM0-Schnittstelle vom Administrator deaktiviert wurde:

Router#show interface atm 0
ATM0 is administratively down, line protocol is down
<... snipped ...> 

Wenn der ATM0-Schnittstellenstatus vom Administrator deaktiviert wurde, führen Sie den Befehl no shutdown unter der ATM0-Schnittstelle aus.

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface atm 0
Router(config-if)#no shut
Router(config-if)#end
Router#write memory

Ist die Kabelbelegung korrekt?

Wenn der ATM0-Schnittstellenstatus ausgefallen ist, wird auf der ADSL-Leitung kein Carrier angezeigt. Dies weist im Allgemeinen auf eines von zwei Problemen hin:

1. Die aktiven Pins an der DSL-Wandbuchse sind falsch.

2. Ihr ISP hat keinen DSL-Dienst an dieser Wandbuchse aktiviert.

Pinbelegungen der Cisco DSL Router xDSL-Ports

Der RJ-11-Anschluss stellt über eine modulare RJ-11-Standardbuchse (6 Pins) eine xDSL-Verbindung zu externen Medien her.

Stift	Beschreibung
1	XDSL_Tipp
4	XDSL_Ring

Um zu bestimmen, ob die ATM0-Schnittstelle ausgefallen ist, führen Sie den Befehl show interface atm 0 im Aktivierungsmodus des Routers aus:

Router#show interface atm 0
ATM0 is down, line protocol is down
<... snipped ...>

Wenn die ATM-Schnittstelle ausgefallen oder inaktiv ist (nicht administrativ deaktiviert), sehen Sie sich die Pinbelegung der DSL-Wandbuchse an. Der DSL-Router verwendet ein Standard-RJ-11-Kabel (4 oder 6 Pins), um die ADSL-Verbindung mit der Wandbuchse herzustellen. Das mittlere Pin-Paar am RJ-11-Kabel dient zum Übertragen des ADSL-Signals (Pins 3 und 4 an einem 6-poligen Kabel oder Pins 2 und 3 an einem 4-poligen Kabel).

Wenn Sie sicher sind, dass Sie die richtigen Pins an der Wandbuchse haben und die ATM0-Schnittstelle immer noch nicht oder nicht verfügbar ist, ersetzen Sie das RJ-11-Kabel zwischen dem DSL-Anschluss und der Wandbuchse. Wenn die Schnittstelle nach dem Austausch des RJ-11-Kabels immer noch nicht erreichbar ist, wenden Sie sich an Ihren ISP, und lassen Sie den ISP überprüfen, ob der DSL-Dienst an der von Ihnen verwendeten Wandbuchse aktiviert wurde.

Wenn Sie nicht sicher sind, welche Pins an der Wandbuchse aktiv sind, fragen Sie Ihren ISP.

Verfügen Sie über das richtige Netzteil für den Cisco 827?

Wenn Sie überprüft haben, dass Ihr DSL-Kabel funktioniert und dass Sie die richtigen Pinbelegungen haben, müssen Sie als Nächstes sicherstellen, dass Sie über das richtige Netzteil für den 827 verfügen.

Hinweis: Das 827 verwendet nicht dasselbe Netzteil wie andere Router der Serie 800.

Um festzustellen, ob Sie das richtige Netzteil haben, suchen Sie auf der Rückseite des Netzadapters nach Ausgangsdaten +12 V 0,1 A, -12 V 0,1 A, +5 V 3A, -24 V 0,12 A und -71 V 0,12 A. Wenn Ihrem Netzteil die +12 V- und -12 V-Stromzugänge fehlen, dann ist es für einen anderen Router der Cisco Serie 800 geeignet und funktioniert nicht auf dem Router 827. Wenn Sie das falsche Netzteil verwenden, wird der Cisco 827 hochgefahren, kann jedoch nicht mit dem ISP DSLAM verbunden werden.

Ist der DSL-Betriebsmodus korrekt?

Wenn bis zu diesem Punkt des Fehlerbehebungsverfahrens für Layer 1 alles richtig ist, müssen Sie im nächsten Schritt sicherstellen, dass Sie den richtigen DSL-Betriebsmodus haben. Cisco empfiehlt die Verwendung von dsl-Betriebsmodus auto, wenn Sie nicht sicher sind, welche DMT-Technologie Ihr ISP verwendet. Dies sind die Befehle zum Konfigurieren der automatischen Erkennung im Betriebsmodus:

Router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#interface atm 0
Router(config-if)#dsl operating-mode auto
Router(config-if)#end
Router#write memory

Wurde der Stromkreis korrekt getestet/bereitgestellt?

Holen Sie diese Informationen von Ihrem ISP oder Telefonanbieter ein.

Layer-2-Probleme

Verfügen Sie über die richtigen PVC-Werte (VPI/VCI)?

Mit einer PPPoE-Bereitstellung ist es nicht einfach, Ihre Permanent Virtual Circuit (PVC) Virtual Path Identifier/Virtual Channel Identifier (VPI/VCI)-Werte dynamisch zu erkennen. Wenden Sie sich an Ihren ISP, wenn Sie sich nicht sicher sind, welche PVC-Werte Sie haben.

Erhalten Sie Daten von Ihrem ISP?

Wenn Sie die richtigen PVC-Werte haben, müssen Sie im nächsten Schritt überprüfen, ob Sie versuchen, PPP mit Ihrem ISP auszuhandeln. Geben Sie dazu den Befehl show interface atm0 ein und überprüfen Sie die Ein- und Ausgabepakete.

Router#show interface atm0
ATM0 is up, line protocol is up
Hardware is DSLSAR (with Alcatel ADSL Module)
MTU 4470 bytes, sub MTU 4470, BW 128 Kbit, DLY 16000 usec, 
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ATM, loopback not set
Encapsulation(s): AAL5, PVC mode
24 maximum active VCs, 256 VCS per VP, 1 current VCCs
VC idle disconnect time: 300 seconds
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 5 bits/sec, 0 packets/sec
5 minute output rate 7 bits/sec, 0 packets/sec
100 packets input, 5600 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
250 packets output, 1400 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 output buffer failures, 0 output buffers swapped out

Wenn die Zähler für die Eingabepakete inkrementiert werden, sollten Sie PPPoE-Verhandlungspakete von Ihrem ISP erhalten. Wenn dies nicht der Fall ist, wenden Sie sich an Ihren ISP.

Wenn die Zähler für die Ausgangsbindung inkrementieren, sollten Sie PPPoE-Verhandlungspakete senden. Ist dies nicht der Fall, überprüfen Sie die Konfiguration auf dem Router. Wenn PPP korrekt konfiguriert ist, werden PPP-Verhandlungspakete kontinuierlich über die ATM0-Schnittstelle gesendet.

Wenn Pakete nur in die ausgehende Richtung steigen, fahren Sie mit den in diesem Dokument beschriebenen Fehlerbehebungsschritten fort.

Ist eine PPPoE-Sitzung aktiv?

PPPoE wird in zwei Phasen durchgeführt. Die erste Phase ist die Einrichtung von PPPoE-Sitzungen, die zweite Phase ist die PPP-Aushandlung. PPPoE muss vor der Aushandlung von Standard-PPP-Parametern eingerichtet werden. Am einfachsten können Sie feststellen, ob Sie über eine aktive PPPoE-Sitzung verfügen, indem Sie den Befehl show vpdn ausführen.

Router#show vpdn
%No active L2TP tunnels
%No active L2F tunnels
%No active PPTP tunnels
PPPoE Tunnel and Session Information Total tunnels 1 sessions 1
PPPoE Tunnel Information
Session count: 1
PPPoE Session Information
SID  RemMAC          LocMAC          Intf   Vast   OIntf   VP/VC
0    0000.0000.0000  0000.0000.0000         UNKN   ATM0    8/35

In diesem Beispiel sind keine PPPoE-Sitzungen aktiv. Dies wird durch eine SID von 0 und die RemMAC und LocMAC von 00000000000 angegeben. Wenn Sie sich in diesem Zustand befinden, fahren Sie mit dem nächsten Abschnitt fort.

Eine erfolgreich ausgehandelte PPPoE-Sitzung sieht wie folgt aus:

Router#show vpdn
%No active L2TP tunnels 
%No active L2F tunnels 
PPPoE Tunnel and Session Information Total tunnels 1 sessions 1
PPPoE Tunnel Information
Session count: 1

PPPoE Session Information
SID  RemMAC           LocMAC          Intf    Vast   OIntf   VP/VC
1    0050.7359.35b7   0001.96a4.84ac  Vi1     UP     ATM0    8/35

In diesem Beispiel können Sie sehen, dass die SID eine Nicht-Null-Zahl ist und dass sowohl die RemMAC- und LocMAC-Felder ausgefüllt sind. Der andere Bereich ist der Vast, der angibt, ob PPP erfolgreich ausgehandelt und authentifiziert wurde. Wenn die Vast UP ist, wurde PPP erfolgreich ausgehandelt und authentifiziert, und Sie können mit der Option Warum kann ich mit PPPoE auf einige Webseiten zugreifen, aber nicht auf andere? Abschnitt dieses Dokuments. Wenn die Vast-Funktion ausgefallen ist, fahren Sie mit dem nächsten Abschnitt fort.

Erhalten Sie eine PPPoE-Antwort vom Aggregation Router?

Wenn Sie keine aktive PPPoE-Sitzung eingerichtet haben, müssen Sie den Befehl debug vpdn pppoe-events ausführen, um zu bestimmen, welche PPPoE-Sitzung nicht verfügbar ist.

Router#debug vpdn pppoe-events
*Mar  3 21:49:38.030: Sending PADI: vc=8/35
*Mar  3 21:49:38.030: padi timer expired
*Mar  3 21:50:10.030: Sending PADI: vc=8/35
*Mar  3 21:50:10.030: padi timer expired
*Mar  3 21:50:42.030: Sending PADI: vc=8/35
*Mar  3 21:50:42.030: padi timer expired
*Mar  3 21:51:14.030: Sending PADI: vc=8/35
*Mar  3 21:51:14.030: padi timer expired
*Mar  3 21:51:46.030: Sending PADI: vc=8/35
*Mar  3 21:51:46.030: padi timer expired
Router#undebug all

In diesem Beispiel sendet der Cisco DSL-Router kontinuierlich PPPoE-PADI-Frames (Active Discovery Initiation) an den ISP, ohne dass eine Antwort erfolgt. Der PADI-Frame ist der erste in einer Reihe von PPPoE-Anrufeinrichtungs-Frames. Wenn Ihr ISP nicht mit einem PPPoE Active Discovery Offer (PADO) antwortet, ist die PPPoE-Aushandlung nicht erfolgreich. Die einzige Lösung für dieses Problem ist, Ihren ISP zu kontaktieren.

Wenn Sie PPPoE erfolgreich aushandeln, sieht die Debug-Ausgabe von vpdn-PPPoE wie folgt aus:

Router#debug vpdn pppoe-events
*Mar  3 21:49:38.030: Sending PADI: vc=8/35
*Mar  3 21:50:10.030: PPPOE: we've got our pado and the pado timer went off
*Mar  3 21:50:35.030: OUT PADR from PPPoE tunnel
*Mar  3 21:50:50.030: IN PADS from PPPoE tunnel
Router#undebug all

Wenn PPPoE erfolgreich ausgehandelt wurde, fahren Sie mit dem nächsten Abschnitt zur Fehlerbehebung bei PPP fort.

Verhandelt die PPP ordnungsgemäß?

Wenn Layer 1 aktiviert ist und Sie über das richtige VPI/VCI verfügen, müssen Sie im nächsten Schritt sicherstellen, dass PPP ordnungsgemäß gestartet wird. Um dies zu erreichen, müssen Sie eine Reihe von Debug-Befehlen auf dem Cisco DSL-Router ausführen und die Ausgabe interpretieren. Das primäre Debugging, das Sie verwenden, ist die Debug-PPP-Aushandlung. Diese Ausgabe des Befehls ist ein Beispiel für eine erfolgreiche PPP-Aushandlung:

Router#debug ppp negotiation

PPP protocol negotiation debugging is on

Router#
2w3d: Vi1 PPP: No remote authentication for call-out
2w3d: Vi1 PPP: Phase is ESTABLISHING
2w3d: Vi1 LCP: O CONFREQ [Open] id 146 len 10
2w3d: Vi1 LCP: MagicNumber 0x8CCF0E1E (0x05068CCF0E1E)
2w3d: Vi1 LCP: O CONFACK [Open] id 102 Len 15
2w3d: Vi1 LCP: AuthProto CHAP (0x0305C22305)
2w3d: Vi1 LCP: MagicNumber 0xD945AD0A (0x0506D945AD0A)
2w3d: Di1 IPCP: Remove route to 20.20.2.1
2w3d: Vi1 LCP: I CONFACK [ACKsent] id 146 Len 10
2w3d: Vi1 LCP: MagicNumber 0x8CCF0E1E (0x05068CCF0E1E)
2w3d: Vi1 LCP: State is Open
2w3d: Vi1 PPP: Phase is AUTHENTICATING, by the peer
2w3d: Vi1 CHAP: I CHALLENGE id 79 Len 33 from "6400-2-NRP-2"
2w3d: Vi1 CHAP: O RESPONSE id 79 Len 28 from "John"
2w3d: Vi1 CHAP: I SUCCESS id 79 Len 4
2w3d: Vi1 PPP: Phase is UP
2w3d: Vi1 IPCP: O CONFREQ [Closed] id 7 Len 10
2w3d: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
2w3d: Vi1 IPCP: I CONFREQ [REQsent] id 4 Len 10
2w3d: Vi1 IPCP: Address 20.20.2.1 (0x030614140201)
2w3d: Vi1 IPCP: O CONFACK [REQsent] id 4 Len 10
2w3d: Vi1 IPCP: Address 20.20.2.1 (0x030614140201)
2w3d: Vi1 IPCP: I CONFNAK [ACKsent] id 7 Len 10
2w3d: Vi1 IPCP: Address 40.1.1.2 (0x030628010102)
2w3d: Vi1 IPCP: O CONFREQ [ACKsent] id 8 Len 10
2w3d: Vi1 IPCP: Address 40.1.1.2 (0x030628010102)
2w3d: Vi1 IPCP: I CONFACK [ACKsent] id 8 Len 10
2w3d: Vi1 IPCP: Address 40.1.1.2 (0x030628010102)
2w3d: Vi1 IPCP: State is Open
2w3d: Di1 IPCP: Install negotiated IP interface address 40.1.1.2
2w3d: Di1 IPCP: Install route to 20.20.2.1
Router#

Bei einer PPP-Aushandlung gibt es vier Hauptargumente für einen Misserfolg:

• Keine Antwort vom Remote-Gerät (Ihrem ISP)

• Link Control Protocol (LCP) nicht geöffnet

• Authentifizierungsfehler

• Ausfall des IP Control Protocol (IPCP)

Keine Antwort von Ihrem ISP

Ihr ISP reagiert nicht, sollte kein Problem sein, da Sie bereits überprüft haben, dass Pakete auf der ATM0-Schnittstelle in Eingangsrichtung erhöht werden. Wenn Sie jedoch Pakete sehen, die auf ATM0 in der eingehenden Richtung inkrementieren, und wenn Sie eine Debug-ppp-Aushandlung ausführen, erhalten Sie diese Ausgabe, wenden Sie sich an Ihren ISP, um zu überprüfen, ob Pakete an den Cisco DSL-Router gesendet werden.

Router#debug ppp negotiation
*Mar 1 04:04:50.718: Vi1 PPP: Treating connection as a callout
*Mar 1 04:04:50.718: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load]
*Mar 1 04:04:50.718: Vi1 PPP: No remote authentication for call-out
*Mar 1 04:04:50.722: Vi1 LCP: O CONFREQ [Closed] id 1 Len 10 

!--- "O" specifies an outbound packet.

*Mar 1 04:04:50.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:04:52.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:04:52.722: Vi1 LCP: O CONFREQ [REQsent] id 2 Len 10 

!--- "O" specifies an outbound packet.

*Mar 1 04:04:52.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:04:54.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:04:54.722: Vi1 LCP: O CONFREQ [REQsent] id 3 Len 10 
*Mar 1 04:04:54.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:04:56.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:04:56.722: Vi1 LCP: O CONFREQ [REQsent] id 4 Len 10
*Mar 1 04:04:56.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:04:58.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:04:58.722: Vi1 LCP: O CONFREQ [REQsent] id 5 Len 10
*Mar 1 04:04:58.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:05:00.722: Vi1 LCP: TIMEout: State REQsent
*Mar 1 04:05:00.722: Vi1 LCP: O CONFREQ [REQsent] id 6 Len 10
*Mar 1 04:05:00.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
*Mar 1 04:05:02.722: Vi1 LCP: TIMEout: State REQsent 
*Mar 1 04:05:02.722: Vi1 LCP: O CONFREQ [REQsent] id 7 Len 10 

!--- "O" specifies an outbound packet.

*Mar 1 04:05:02.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)
Router#undebug all

In dieser Ausgabe sind nur O-Pakete enthalten, bei denen es sich um ausgehende Pakete handelt. Um PPP erfolgreich auszuhandeln, sollte Ihr ISP ein I-eingehendes Paket für jedes E-Paket bereitstellen. Wenn eingehende Pakete inkrementieren, aber keine I-Pakete sehen, wenden Sie sich an Ihren ISP, um die Pakete zu überprüfen, die an den Cisco DSL-Router gesendet werden.

LCP nicht geöffnet

Das nicht geöffnete LCP wird in der Regel durch eine Diskrepanz in PPP-Optionen verursacht. Diese Diskrepanz tritt auf, wenn für den Cisco DSL-Router ein PPP-Parameter konfiguriert wurde, der von Ihrem ISP nicht unterstützt wird, oder wenn für Ihren ISP ein Parameter konfiguriert wurde, den der Cisco DSL-Router nicht unterstützt. Diese Ausgabe zeigt ein Beispiel für eine falsche PPP-Option:

Router#debug ppp negotiation
*Mar 1 04:52:43.254: Vi1 PPP: Treating connection as a callout
*Mar 1 04:52:43.258: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load] 
*Mar 1 04:52:43.258: Vi1 PPP: No remote authentication for call-out 
*Mar 1 04:52:43.258: Vi1 LCP: O CONFREQ [Closed] id 3 len 10
*Mar 1 04:52:43.262: Vi1 LCP: MagicNumber 0x31A2F808 (0x050631A2F808)
*Mar 1 04:52:43.310: Vi1 LCP: I CONFREQ [REQsent] id 180 Len 14
*Mar 1 04:52:43.310: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 1 04:52:43.310: Vi1 LCP: MagicNumber 0x39D50E9B (0x050639D50E9B)
*Mar 1 04:52:43.314: Vi1 LCP: O CONFNAK [REQsent] id 180 Len 9

!--- PPP option reject

*Mar 1 04:52:43.314: Vi1 LCP: AuthProto CHAP (0x0305C22305)

!--- PPP option that is rejected

*Mar 1 04:52:43.314: Vi1 LCP: I CONFACK [REQsent] id 3 Len 10
*Mar 1 04:52:43.318: Vi1 LCP: MagicNumber 0x31A2F808 (0x050631A2F808)
*Mar 1 04:52:43.366: Vi1 LCP: I CONFREQ [ACKrcvd] id 181 Len 14
*Mar 1 04:52:43.366: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 1 04:52:43.366: Vi1 LCP: MagicNumber 0x39D50E9B (0x050639D50E9B)
*Mar 1 04:52:43.370: Vi1 LCP: O CONFNAK [ACKrcvd] id 181 Len 9 

!--- PPP option reject

*Mar 1 04:52:43.370: Vi1 LCP: AuthProto CHAP (0x0305C22305) 

!--- PPP option that is rejected

*Mar 1 04:52:43.418: Vi1 LCP: I CONFREQ [ACKrcvd] id 182 Len 14
*Mar 1 04:52:43.418: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 1 04:52:43.418: Vi1 LCP: MagicNumber 0x39D50E9B (0x050639D50E9B)
Router#undebug all

Unabhängig davon, ob es sich um ein I- oder ein O-Paket handelt, ist ein CONFNAK (Configure-Negative-Acknowley) ein Hinweis auf eine Nichtübereinstimmung der PPP-Konfiguration. Das bedeutet, dass eine Seite der PPP-Verbindung eine PPP-Option anfordert, die die andere Seite nicht ausführen kann oder nicht konfiguriert ist. Wenn der Cisco DSL-Router den CONFNAK sendet (durch "O CONFNAK" angegeben), kann der Cisco DSL-Router die Option, die der ISP sendet, nicht ausführen oder nicht konfigurieren. Wenn der CONFNAK von Ihrem ISP gesendet wird (durch "I CONFNAK" gekennzeichnet), haben Sie eine Option auf dem Cisco DSL-Router konfiguriert, die Ihr ISP nicht durchführen möchte.

Die Zeile nach CONFNAK beschreibt die Option, die abgelehnt wird. In dieser Beispielausgabe lautet die Option CHAP, sie kann jedoch jede Option sein. Der einzige Ort auf dem Cisco DSL-Router, an dem PPP-Optionen konfiguriert werden können, ist der Schnittstellenwähler 1. Geben Sie den Befehl show run interface dialer 1 ein, um die Konfiguration des Schnittstellenwählers 1 anzuzeigen.

Wenn Ihr ISP den I CONFNAK sendet, suchen Sie unter Interface Dialer 1 nach Befehlen, die mit der Zeile nach dem CONFNAK übereinstimmen, und entfernen Sie sie. Wenn der Cisco DSL-Router den O CONFNAK sendet, fügen Sie einen Befehl zum Schnittstellenwähler 1 hinzu, um PPP mit Ihrem ISP korrekt auszuhandeln. Wenn der Router Pakete sendet, müssen Sie möglicherweise das Cisco TAC anrufen, um festzustellen, welche Befehle auf dem Cisco DSL-Router aktiviert werden müssen.

Authentifizierungsfehler

Ein Authentifizierungsfehler tritt auf, wenn Ihr ISP Ihren PPP-Benutzernamen oder Ihr Kennwort nicht authentifizieren kann. Dies kann in zwei Szenarien geschehen. Das erste Szenario ist eine nicht übereinstimmende Authentifizierungstyp, der ausgelöst wird, wenn Sie den Router nicht richtig konfigurieren. Alle in diesem Dokument aufgeführten Authentifizierungskonfigurationen gelten für die Authentifizierungstypen PAP und CHAP. Für eine flexible Konfiguration sollten sowohl CHAP als auch PAP konfiguriert sein. Wenn Sie nicht beide konfiguriert haben, wird möglicherweise die Ausgabe eines debug ppp-Befehls wie der folgenden Ausgabe angezeigt:

Router#debug ppp negotiation
00:34:29: Vi1 LCP:O CONFREQ [REQsent] id 53 Len 15 
00:34:29: Vi1 LCP: AuthProto CHAP (0x0305C22305)

!--- Sends CHAP requests

00:34:29: Vi1 LCP: MagicNumber 0x01B63483 (0x050601B63483)
00:34:29: Vi1 LCP: I CONFREQ [REQsent] id 252 Len 14
00:34:29: Vi1 LCP: AuthProto PAP (0x0304C023)

!--- Receives PAP requests from the service provider

00:34:29: Vi1 LCP: MagicNumber 0xBC5233F9 (0x0506BC5233F9)
00:34:29: Vi1 LCP: O CONFREJ [REQsent] id 252 Len 8
Router#undebug all

oder

Router#debug ppp negotiation
00:45:44: Vi1 LCP: I CONFREQ [Listen] id 141 Len 15
00:45:44: Vi1 LCP: AuthProto CHAP (0x0305C22305)

!--- Receives CHAP requests from the service provider

00:45:44: Vi1 LCP: MagicNumber 0xBC5C7DDC (0x0506BC5C7DDC)
00:45:44: Vi1 LCP: O CONFREQ [Listen] id 255 Len 14
00:45:44: Vi1 LCP: AuthProto PAP (0x0304C023) 

!--- Sends out PAP requests

Router#undebug all

!--- Turn off ppp debug 

Um beide Probleme in Bezug auf Authentifizierungskonflikte zu beheben, lesen Sie die Konfiguration der entsprechenden PPPoA-Implementierungsoption, und konfigurieren Sie die PPP-Authentifizierung neu.

Das zweite mögliche Authentifizierungsproblem ist ein falscher PAP-Benutzername oder -Passwort. Um festzustellen, ob das Problem vorliegt, führen Sie den Befehl debug ppp negotiation aus. Wenn Ihr Router sowohl für das Challenge Handshake Authentication Protocol (CHAP) als auch für das Password Authentication Protocol (PAP) konfiguriert ist, wie die oben in diesem Leitfaden beschriebene Konfiguration zeigt, verwendet Ihr ISP möglicherweise keine PAP-Authentifizierung.

Um die von Ihrem ISP verwendete Authentifizierung zu bestimmen, überprüfen Sie die Optionen im I CONFREQ-Paket, das Sie von Ihrem ISP erhalten haben. Wenn auf dieses Paket eine Option mit dem Namen AuthProto PAP folgt, verwenden Sie PAP. Wenn auf die I CONFREQ eine Option mit dem Namen AuthProto CHAP folgt, verwenden Sie CHAP und fahren Sie mit Woher weiß ich, ob mein CHAP-Benutzername und mein Kennwort korrekt sind?

Woher weiß ich, ob mein PAP-Benutzername und mein Passwort korrekt sind?

Nachdem Sie bestätigt haben, dass Ihr ISP PAP verwendet, geben Sie den Befehl debug ppp negotiation aus, um zu bestätigen, dass Ihr PAP-Benutzername und Ihr Kennwort korrekt sind.

Router#debug ppp negotiation 
*Mar 2 00:50:15.741: Vi1 PPP: Treating connection as a callout
*Mar 2 00:50:15.745: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load]
*Mar 2 00:50:15.745: Vi1 PPP: No remote authentication for call-out
*Mar 2 00:50:15.745: Vi1 LCP: O CONFREQ [Closed] id 177 Len 10
*Mar 2 00:50:15.745: Vi1 LCP: MagicNumber 0x35EB5D4F (0x050635EB5D4F)
*Mar 2 00:50:15.789: Vi1 LCP: I CONFACK [REQsent] id 177 Len 10
*Mar 2 00:50:15.793: Vi1 LCP: MagicNumber 0x35EB5D4F (0x050635EB5D4F)
*Mar 2 00:50:17.241: Vi1 LCP: I CONFREQ [ACKrcvd] id 203 Len 14
*Mar 2 00:50:17.241: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 2 00:50:17.241: Vi1 LCP: MagicNumber 0x3E1D1E5E (0x05063E1D1E5E)
*Mar 2 00:50:17.245: Vi1 LCP: O CONFACK [ACKrcvd] id 203 Len 14
*Mar 2 00:50:17.245: Vi1 LCP: AuthProto PAP (0x0304C023)
*Mar 2 00:50:17.245: Vi1 LCP: MagicNumber 0x3E1D1E5E (0x05063E1D1E5E)
*Mar 2 00:50:17.249: Vi1 LCP: State is Open
*Mar 2 00:50:17.249: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
*Mar 2 00:50:17.249: Vi1 PAP: O AUTH-REQ id 9 Len 14 from "cisco" 

!--- "cisco" is the PAP username configured on this DSL router.

*Mar 2 00:50:17.297: Vi1 PAP: I AUTH-NAK id 9 Len 27 msg is "Authentication failure"
*Mar 2 00:50:17.301: Vi1 LCP: I TERMREQ [Open] id 204 Len 4
*Mar 2 00:50:17.301: Vi1 LCP: O TERMACK [Open] id 204 Len 4
*Mar 2 00:50:17.305: Vi1 PPP: Phase is TERMINATING [0 sess, 1 load]u
*Mar 2 00:50:19.305: Vi1 LCP: TIMEout: State TERMsent
*Mar 2 00:50:19.305: Vi1 LCP: State is Closed
*Mar 2 00:50:19.305: Vi1 PPP: Phase is DOWN [0 sess, 1 load]

Wenn Sie ein PAP-Authentifizierungsproblem haben, sollte der LCP-Status zu Öffnen wechseln. Direkt nach der Änderung des LCP-Zustands sollte PPP in eine Authentifizierungsphase geschaltet werden. Wenn eine der nächsten beiden Zeilen I AUTH-NAK enthält, ist entweder Ihr PAP-Benutzername oder Ihr PAP-Kennwort falsch. Zu diesem Zeitpunkt müssen Sie Ihren PAP-Benutzernamen und Ihr Kennwort mithilfe dieser Befehlsfolge neu konfigurieren. Beachten Sie, dass bei Ihrem PAP-Benutzernamen und -Kennwort die Groß- und Kleinschreibung beachtet wird.

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface dialer 1
Router(config-if)#ppp pap sent-username 
      
      
        password 
        
      
Router(config-if)#end
Router#write memory

Woher weiß ich, ob mein CHAP-Benutzername und mein Kennwort korrekt sind?

Nachdem Sie bestätigt haben, dass Ihr ISP CHAP verwendet, geben Sie den Befehl debug ppp negotiation aus, um zu bestätigen, dass Ihr CHAP-Benutzername und Ihr Kennwort korrekt sind.

Router#debug ppp negotiation
*Mar 3 02:51:47.287: Vi1 PPP: Treating connection as a callout
*Mar 3 02:51:47.287: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load]
*Mar 3 02:51:47.291: Vi1 PPP: No remote authentication for call-out
*Mar 3 02:51:47.291: Vi1 LCP: O CONFREQ [Closed] id 188 Len 10
*Mar 3 02:51:47.291: Vi1 LCP: MagicNumber 0x3B821FF1 (0x05063B821FF1)
*Mar 3 02:51:47.339: Vi1 LCP: I CONFREQ [REQsent] id 204 Len 15
*Mar 3 02:51:47.343: Vi1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 3 02:51:47.343: Vi1 LCP: MagicNumber 0x43B3F393 (0x050643B3F393)
*Mar 3 02:51:47.343: Vi1 LCP: O CONFACK [REQsent] id 204 Len 15
*Mar 3 02:51:47.347: Vi1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 3 02:51:47.347: Vi1 LCP: MagicNumber 0x43B3F393 (0x050643B3F393)
*Mar 3 02:51:47.347: Vi1 LCP: I CONFACK [ACKsent] id 188 Len 10
*Mar 3 02:51:47.351: Vi1 LCP: MagicNumber 0x3B821FF1 (0x05063B821FF1)
*Mar 3 02:51:47.351: Vi1 LCP: State is Open
*Mar 3 02:51:47.351: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
*Mar 3 02:51:47.395: Vi1 CHAP: I CHALLENGE id 1 Len 32 from "6400-2-NRP3"
*Mar 3 02:51:47.395: Vi1 CHAP: Using alternate hostname cisco
*Mar 3 02:51:47.399: Vi1 CHAP: Username 6400-2-NRP3 not found
*Mar 3 02:51:47.399: Vi1 CHAP: Using default password
*Mar 3 02:51:47.399: Vi1 CHAP: O RESPONSE id 1 Len 26 from "cisco"  

!--- "cisco" is the CHAP username configured on this DSL router.

*Mar 3 02:51:47.447: Vi1 CHAP: I FAILURE id 1 Len 26 MSG is "Authentication failure"
*Mar 3 02:51:47.447: Vi1 LCP: I TERMREQ [Open] id 205 Len 4
*Mar 3 02:51:47.451: Vi1 LCP: O TERMACK [Open] id 205 Len 4
*Mar 3 02:51:47.451: Vi1 PPP: Phase is TERMINATING [0 sess, 0 load]
*Mar 3 02:51:49.451: Vi1 LCP: TIMEout: State TERMsent
*Mar 3 02:51:49.451: Vi1 LCP: State is Closed
*Mar 3 02:51:49.451: Vi1 PPP: Phase is DOWN [0 sess, 0 load]
Router#undebug all

Wenn Sie ein CHAP-Authentifizierungsproblem haben, sollte der LCP-Status zu Öffnen wechseln. Direkt nach der Änderung des LCP-Zustands sollte PPP in eine Authentifizierungsphase geschaltet werden. Von diesem Punkt aus sehen Sie eine Reihe von CHAP-Zeilen. Wenn die letzte dieser Zeilen I FEHLER anzeigt, haben Sie den falschen CHAP-Benutzernamen und das falsche Kennwort. Verwenden Sie diese Befehlsfolge, um Ihren CHAP-Benutzernamen und Ihr Kennwort zu korrigieren. Beachten Sie, dass bei Ihrem Benutzernamen und Kennwort die Groß- und Kleinschreibung beachtet wird.

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface dialer 1
Router(config-if)#ppp chap hostname 
      
       
Router(config-if)#ppp chap password 
      
      
Router(config-if)#end
Router#write memory

Woher weiß ich, wann die PPP-Authentifizierung erfolgreich ist?

Dieses Beispiel zeigt eine erfolgreiche CHAP-Aushandlung.

Router#debug ppp negotiation
<... snipped ...>
*Mar 3 03:30:09.335: Vi1 LCP: State is Open
*Mar 3 03:30:09.335: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
*Mar 3 03:30:09.379: Vi1 CHAP: I CHALLENGE id 41 len 32 from "6400-2-NRP3"
*Mar 3 03:30:09.379: Vi1 CHAP: Using alternate hostname cisco
*Mar 3 03:30:09.379: Vi1 CHAP: Username 6400-2-NRP3 not found
*Mar 3 03:30:09.383: Vi1 CHAP: Using default password
*Mar 3 03:30:09.383: Vi1 CHAP: O RESPONSE id 41 Len 26 from "cisco"
*Mar 3 03:30:09.431: Vi1 CHAP: I SUCCESS id 41 Len 4

!--- CHAP negotiation was a success.

*Mar 3 03:30:09.431: Vi1 PPP: Phase is UP [0 sess, 1 load] 
<... snipped ...>
Router#undebug all

Dieses Beispiel zeigt eine erfolgreiche PAP-Aushandlung.

Router#debug ppp negotiation
<... snipped ...>
*Mar 3 03:33:19.491: Vi1 LCP: State is Open
*Mar 3 03:33:19.491: Vi1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 0 load]
*Mar 3 03:33:19.495: Vi1 PAP: O AUTH-REQ id 255 Len 16 from "cisco"
*Mar 3 03:33:19.539: Vi1 PAP: I AUTH-ACK id 255 Len 5
*Mar 3 03:33:19.539: Vi1 PPP: Phase is UP [0 sess, 0 load] 

!--- PAP negotiation was a success.

<... snipped ...>
Router#undebug all

Warum kann ich auf einige Webseiten mit PPPoE zugreifen, aber nicht auf andere?

Der Zugriff auf nur einige Webseiten ist ein häufiges Problem, wenn Sie einen PPPoE-Client auf einem Router ausführen. PPPoE unterstützt standardmäßig eine MTU von bis zu 1.492 Byte. Daher müssen Sie sicherstellen, dass Endgeräte Frames senden, die nicht größer als 1492 Byte sind. Die Begrenzung der MTU auf 1.492 Byte kann ein Problem sein, da die meisten PCs und Workstations für Endbenutzer eine MTU-Standardgröße von 1.500 Byte aufweisen.

Es gibt zwei Optionen zum Anpassen der MTU-Größe: die MTU-Größe am Router anpassen und die MTU-Größe am PC anpassen.

Passen Sie die PPPoE-MTU-Größe auf dem Cisco DSL-Router an.

Wichtige Hinweise:

Diese Konfigurationsbefehle funktionieren nur, wenn Sie Network Address Translation (NAT) oder Port Address Translation (PAT) auf dem Cisco DSL-Router ausführen.

Der Befehl ip adjust-mss in Cisco IOS® Software Release 12.2(2)XH wurde in ip tcp adjust-mss <mss value> geändert. Diese Änderung ist in den Versionshinweisen für Cisco Router der Serie 800 und Cisco Router der Serie 820 für Cisco IOS Version 12.2(2)XH dokumentiert.

!
vpdn enable
no vpdn logging
!
vpdn-group pppoe
request-dialin 
protocol pppoe 
!
interface ethernet0
 no shut
 ip address <ip address> <subnet mask>
 ip adjust-mss 1452
 
!--- The TCP MSS command requires an MSS of 1452, not 1492.

 ip nat inside 
 no ip directed-broadcast
!
interface atm0
 no shut
 no ip address
 no ip directed-broadcast
 no atm ilmi-keepalive
 bundle-enable
!
interface atm0.1 point-to-point
 no ip directed-broadcast
 pvc <vpi/vci>
 pppoe-client dial-pool-number 1 
 !
!
interface dialer1
 ip address negotiated
 mtu 1492
 ip nat outside 
 encapsulation ppp
 dialer pool 1
 ppp chap hostname <username>
 ppp chap password <password>
 ppp pap sent-username <username> password <password>
! 
ip nat inside source list 1 interface dialer1 overload 
!
ip classless 
ip route 0.0.0.0 0.0.0.0 dialer1 
access-list 1 permit 
      
      
        0.0.255.255 
      
!

Passen Sie die PPPoE-MTU-Größe auf dem PC mithilfe des Dr. TCP-Dienstprogramms an.

Führen Sie diese Schritte aus, um die MTU-Größe auf dem PC zu ändern. Die Registrierungsänderung wird nach Abschluss des Vorgangs gespeichert.

Hinweis: Das Dienstprogramm Dr. TCP ist mit allen Windows-basierten PCs kompatibel.

1. Laden Sie die neueste Version des Dr. TCP-Dienstprogramms herunter.

2. Aktualisieren Sie Ihre Browserseite, um sicherzustellen, dass die Seite aktuell ist.

3. Führen Sie das Dienstprogramm Dr.TCP aus.

4. Wählen Sie aus dem Menü Ihren Ethernet-Adapter aus.

5. Geben Sie im Feld MTU (MTU) 1492 ein.

6. Klicken Sie auf Übernehmen, um die Änderung zu speichern, und klicken Sie dann auf Beenden.

7. Starten Sie den PPPoE PC-Client neu.

Sie müssen das Dienstprogramm nur einmal pro PPPoE-Client-PC ausführen.

Weitere Schritte zur MTU-Fehlerbehebung

Wenn Sie die MTU-Größe mit Dr. TCP oder auf dem Cisco DSL-Router ändern und immer noch nicht in der Lage sind, bestimmte Websites zu durchsuchen, passen Sie die MTU-Größe erneut an. Ändern Sie die MTU-Größe in Dr. TCP in 1452, oder ändern Sie den Wert für die MSS-Anpassung auf dem Cisco DSL-Router in 1412. Wenn diese Größen zu groß sind, reduzieren Sie die MTU-Größe weiter, bis Sie eine Basisgröße von 1400 für Dr. TCP bzw. 1360 für MSS-Anpassung auf dem Cisco DSL-Router erreichen.

Zugehörige Informationen

• Unterstützung von ADSL-Technologie
• PPPoE-Implementierungsoptionen
• Cisco DSL Router - Konfigurations- und Fehlerbehebungsleitfaden
• Technischer Support und Dokumentation - Cisco Systems