Cisco DSL Router-Konfigurations- und Fehlerbehebungsleitfaden - PPPoA-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 mit Ihrem ISP Digital Subscriber Line Access Multiplexer (DSLAM)

• 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 diesen Befehl im Aktivierungsmodus des Routers aus, um festzustellen, 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:

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

• 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

Hinweis: Cisco 1417 verwendet die Stifte 2 und 5 an einer 6-poligen modularen Standard-RJ-11-Buchse.

Um zu bestimmen, ob die ATM0-Schnittstelle ausgefallen ist, führen Sie den Befehl show interface atm 0 aus enable mode 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-polig), um die ADSL-Verbindung zur Wandbuchse herzustellen. Das mittlere Pin-Paar des RJ-11-Kabels 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). Dies gilt nicht für den Cisco 1417, der die Stifte 2 und 5 verwendet.

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 ADSL-Service an der von Ihnen verwendeten Wandbuchse aktiviert wurde.

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

Wenn Sie einen Cisco 827 als DSL Customer Premises Equipment (CPE) verwenden, ist das Netzteil für den Cisco 827 richtig?

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 Cisco 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 Cisco Router der Serie 800 geeignet und funktioniert nicht auf dem 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 (Permanent Virtual Circuit) (VPI/VCI)?

Führen Sie diese Schritte aus, um festzustellen, ob auf dem Router die richtigen VPI/VCI-Werte (Virtual Path Identifier/Virtual Circuit Identifier) konfiguriert sind.

1. Überprüfen Sie Ihre Version der Cisco IOS®-Software.

   Wichtig: Dies funktioniert nicht mit der Cisco IOS-Softwareversion 12.1(1)XB.

   Router#show version 
   
   !--- Used to determine your Cisco IOS version.
   
   
   Cisco Internetwork Operating System Software
   IOS (tm) C820 Software (C820-OSY656I-M), Version 12.1(3)XG3, 
   EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)
   
   !--- The two lines immediately preceding appear on one line on the router.
    
   TAC:Home:SW:IOS:Specials for info
   Copyright (c) 1986-2000 by cisco Systems, Inc.
   Compiled Wed 20-Dec-00 16:44 by detang
   Image text-base: 0x80013170, data-base: 0x80725044
   <... snipped ...>

2. Konfigurieren Sie den Router für die Debug-Protokollierung.

   Router#configure terminal 
   Enter configuration commands, one per line. End with CNTL/Z.
   Router(config)#logging console
   Router(config)#logging buffer
   Router(config)#service timestamp debug datetime msec
   Router(config)#service timestamp log datetime msec
   Router(config)#end
   Router#write memory
   Building configuration...
   [OK]
   Router#terminal monitor

3. Aktivieren Sie Debugging auf dem Router.

   Router#debug atm events 
   ATM events debugging is on
   Router#
   2d18h:
   2d18h: RX interrupt: conid = 0, rxBd = 0x80C7EF74 length=52
   2d18h: Data Cell received on vpi = 8 vci = 35
   
   !--- Your VPI/VCI.
   
   2d18h:
   2d18h: RX interrupt: conid = 0, rxBd = 0x80C7EEC0 length=52
   2d18h: Data Cell received on vpi = 8 vci = 35
   2d18h:
   2d18h: RX interrupt: conid = 0, rxBd = 0x80C7EECC length=52
   2d18h: Data Cell received on vpi = 8 vci = 35
   2d18h:
   2d18h: RX interrupt: conid = 0, rxBd = 0x80C7EED8 length=52
   2d18h: Data Cell received on vpi = 8 vci = 35

4. Stellen Sie sicher, dass Sie ATM-Ereignisse auf dem Cisco DSL-Router debuggen haben, und gehen Sie dann zu einer funktionierenden Internetverbindung, und pingen Sie die IP-Adresse, die Ihnen Ihr ISP statisch zugewiesen hat.

   Es spielt keine Rolle, ob Sie diese IP-Adresse auf dem Cisco DSL-Router konfiguriert haben. Wichtig ist, dass Ihre ATM-Schnittstelle aktiv/aktiv ist und Sie die IP-Adresse pingen, die Ihnen Ihr ISP gegeben hat. Wenn die erwartete Ausgabe nach dem Ping-Test nicht angezeigt wird, wenden Sie sich an Ihren ISP, um Unterstützung zu erhalten.

5. Deaktivieren Sie das Debuggen auf dem Router.

   << Warten 60 Sekunden >>

   Router#undebug all 
   
   !--- Turn off the debug events.
   
   
   All possible debugging has been turned off.

   Überprüfen Sie Ihre VPI/VCI-Werte, und nehmen Sie dann die erforderlichen Änderungen an Ihrer Konfiguration vor.

   Wenn die Ausgabe während der 60 Sekunden des Debuggens nicht angezeigt wird, wenden Sie sich an Ihren ISP.

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 Paketzähler inkrementieren, sollten Sie PPP-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 PPP-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 in beide Richtungen steigen, fahren Sie mit den Schritten zur Fehlerbehebung in diesem Dokument 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 Befehlsausgabe 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 dies von Ihrem 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 an den Cisco DSL-Router gesendeten Pakete zu überprüfen.

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

Ob es sich um ein E/A-Paket handelt, ein CONFNAK (Configure-Negative-Acknowley) weist auf eine Nichtübereinstimmung der PPP-Konfiguration hin. Das bedeutet, dass eine Seite der PPP-Verbindung eine PPP-Option benötigt, 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 auf dem Cisco DSL-Router eine Option 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 Challenge Handshake Authentication Protocol (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 den Cisco Support 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 Password Authentication Protocol (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 im folgenden Beispiel 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

!--- Turns 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. Unter der Annahme, dass Ihr Router sowohl für CHAP als auch für PAP konfiguriert ist, wie die zuvor 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 PAP-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 gewechselt 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 gewechselt 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

Zugehörige Informationen

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