Cisco DSL Router Configuration and Troubleshooting Guide Pppoe: DSL Router As A Pppoe Client Troubleshooting

Cisco DSL Router Configuration and
Troubleshooting Guide − PPPoE: DSL Router as a

PPPoE Client Troubleshooting
Document ID: 71124
Contents
Introduction
Prerequisites
Requirements
Components Used
Conventions
Layer 1 Issues
Is the carrier detect (CD) light on the front panel of the Cisco DSL Router on or off?
Is your ISP using a DSLAM that supports the Alcatel chipset?
Is the DSL port on the back of the Cisco DSL Router plugged into the DSL wall jack?
Is the ATM interface in an administratively down state?
Is the cable pinout correct?
Do you have the correct power supply for the Cisco 827?
Is the DSL operating−mode correct?
Is the circuit tested/provisioned correctly?
Layer 2 Issues
Do you have the correct PVC values (VPI/VCI)?
Are you receiving data from your ISP?
Is a PPPoE session up?
Are you receiving a PPPoE response from the aggregation router?
Is PPP negotiating properly?
How do I know if my PAP username and password are correct?
How do I know if my CHAP username and password are correct?
How do I know when PPP authentication is successful?
Why can I access some web pages with PPPoE but not others?
Adjust the PPPoE MTU Size on the Cisco DSL Router
Adjust the PPPoE MTU Size on the PC Using the Dr. TCP Utility
Additional MTU Troubleshooting Steps
Related Information
Introduction
There are many reasons why your Digital Subscriber Line (DSL) connection might not function properly. The
goal of this document is to isolate the cause of the failure and repair it. The first troubleshooting step is to
determine which layer of your Asynchronous Digital Subscriber Line (ADSL) service is failing. There are
three layers in which the failure can occur.
• Layer 1 DSL physical connectivity to the Digital Subscriber Line Access Multiplexer (DSLAM) of
your ISP
• Layer 2.1 ATM connectivity
• Layer 2.2 Point−to−Point Protocol over ATM (PPPoA), Point−to−Point Protocol over Ethernet
(PPPoE), RFC1483 Bridging, or RFC1483 Routing
• Layer 3 IP
The easiest way to determine which layer you should begin to troubleshoot is to issue the command show ip
interface brief. The output of this command differs slightly depending on your configuration.
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
If the statuses of ATM0 and ATM0.1 are up and the protocol is up, begin to troubleshoot at Layer 2.
If the ATM interfaces are down, or if they continue to come up and then go down (they do not stay up and
up), begin to troubleshoot at Layer 1.
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
This document is not restricted to specific software and hardware versions.
Conventions
Refer to Cisco Technical Tips Conventions for more information on document conventions.
Layer 1 Issues
Is the carrier detect (CD) light on the front panel of the Cisco DSL Router
on or off?
If the CD light is on, go to the Layer 2 Issues section of this document.
If the CD light is off, continue with the next question.
Is your ISP using a DSLAM that supports the Alcatel chipset?

Verify this information with your ISP.
Is the DSL port on the back of the Cisco DSL Router plugged into the
DSL wall jack?
If the DSL port is not plugged into the DSL wall jack, connect the port to the wall with a 4−pin or 6−pin
RJ−11 cable. This is a standard telephone cable.
Is the ATM interface in an administratively down state?

In order to determine if the ATM0 interface is administratively down, issue this command in enable mode on
the router:
Router#show interface atm 0
ATM0 is administratively down, line protocol is down
<... snipped ...>
If the ATM0 interface status is administratively down, issue the no shutdown command under the ATM0
interface.
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
Is the cable pinout correct?

If the ATM0 interface status is down and down, the router does not see a carrier on the ADSL line. This
generally indicates one of two issues:
1. The active pins on the DSL wall jack are incorrect.

2. Your ISP has not turned up a DSL service on this wall jack.
Cisco DSL Router xDSL Port Pinouts
The RJ−11 connector provides an xDSL connection to external media via a standard RJ−11 6−pin modular
jack.
Pin
Description
3
XDSL_Tip
4
XDSL_Ring
In order to determine if the ATM0 interface is down and down, issue the show interface atm 0 command
from enable mode of the router:
Router#show interface atm 0

ATM0 is down, line protocol is down
<... snipped ...>
If the ATM interface is down and downnot administratively downcheck the pinout of your DSL wall jack.
The DSL router uses a standard RJ−11 (4−pin or 6−pin) cable to provide the ADSL connection to the wall
jack. The center pair of pins on the RJ−11 cable is used to carry the ADSL signal (pins 3 and 4 on a 6−pin
cable, or pins 2 and 3 on a 4− pin cable).
If you are sure you have the right pins on the wall jack and the ATM0 interface is still down and down,
replace the RJ−11 cable between the DSL port and your wall jack. If the interface is still down and down after
you replace the RJ−11 cable, contact your ISP and have the ISP verify that DSL service has been enabled on
the wall jack that you use.
If you are not sure what pins on your wall jack are active, ask your ISP.
Do you have the correct power supply for the Cisco 827?
If you have verified that your DSL cable is good and that you have the correct pinouts, the next step is to
make sure you have the correct power supply for the 827.
Note: The 827 does not use the same power supply as other 800 series routers.
In order to determine if you have the correct power supply, on the back of the power adapter look for Output
+12V 0.1A, −12V 0.1A, +5V 3A, −24V 0.12A, and −71V 0.12A. If your power supply is missing the +12V
and −12V feeds, then it is for a different Cisco 800 series router and does not work on the 827. Note that if
you use the wrong power supply, the Cisco 827 powers up but is unable to train up (connect) to the ISP
DSLAM.
Is the DSL operating−mode correct?

If everything up to this point in the Layer 1 troubleshooting procedure is correct, the next step is to make sure
you have the correct DSL operating mode. Cisco recommends using dsl operating−mode auto if you are not
sure what DMT technology your ISP uses. These are the commands to configure operating−mode
autodetection:
Router(config)#interface atm 0
Router(config−if)#dsl operating−mode auto
Router#write memory
Is the circuit tested/provisioned correctly?

Obtain this information from your ISP or telephone company.
Layer 2 Issues
Do you have the correct PVC values (VPI/VCI)?
With a PPPoE deployment there is no easy way to dynamically discover your Permanent Virtual Circuit
(PVC) virtual path identifier/virtual channel identifier (VPI/VCI) values. Contact your ISP if you are not sure
of your PVC values.
Are you receiving data from your ISP?

If you have the correct PVC values, the next step is to verify that you are attempting to negotiate PPP with
your ISP. In order to do this, issue the command show interface atm0 and check the input and output packets.
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
If the input packet counters are incrementing, you should receive PPPoE negotiation packets from your ISP. If
this is not the case, call your ISP.
If the output bound counters are incrementing, you should be sending PPPoE negotiation packets. If this is not
the case, check the configuration on the router. If PPP is configured properly, PPP negotiation packets are
continually sent out the ATM0 interface.
If packets are incrementing in only the outbound direction, continue with the troubleshooting steps in this
document.
Is a PPPoE session up?

PPPoE is executed in two phases. The first phase is PPPoE session establishment, and the second phase is the
PPP negotiation. PPPoE must be established prior to the negotiation of standard PPP parameters. The easiest
way to determine if you have an active PPPoE session is to issue the show vpdn command.
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 this example, no PPPoE sessions are active. This is indicated by an SID of 0, and the RemMAC and
LocMAC of 0000.0000.0000. If you are in this state, proceed to the next section.
A PPPoE session that is successfully negotiated looks like this:
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 this example you can see that the SID is a non−zero number, and that both the RemMAC and LocMAC
fields are populated. The other field of interest is the Vast, which indicates whether PPP has been successfully
negotiated and authenticated. If the Vast is UP, PPP has been successfully negotiated and authenticated, and
you can proceed to the Why can I access some web pages with PPPoE but not others? section of this
document. If the Vast is DOWN, continue with the next section.
Are you receiving a PPPoE response from the aggregation router?

If you do not have an active PPPoE session established, you need to issue the debug vpdn pppoe−events
command to determine what PPPoE does not come up.
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
Router#undebug all
In this example, the Cisco DSL router continuously sends PPPoE Active Discovery Initiation (PADI) frames
to the ISP with no response. The PADI frame is the first in a series of PPPoE call−setup frames. If your ISP
does not respond with a PPPoE Active Discovery Offer (PADO), PPPoE negotiation does not succeed. The
only solution for this problem is to contact your ISP.
If you successfully negotiate PPPoE, your debug vpdn pppoe−events output looks like this output:
Router#debug vpdn pppoe−events

*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
If PPPoE is successfully negotiated, continue with the next section about troubleshooting PPP.
Is PPP negotiating properly?

If Layer 1 is up and you have the correct VPI/VCI, the next step is to make sure PPP comes up properly. In
order to accomplish this, you need to run a series of debug commands on the Cisco DSL router and interpret
the output. The primary debug you use is debug ppp negotiation. This output of the command is an example
of a successful PPP negotiation:
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: O CONFACK [REQsent] id 4 Len 10
2w3d: Vi1 IPCP: I CONFNAK [ACKsent] id 7 Len 10
2w3d: Vi1 IPCP: O CONFREQ [ACKsent] id 8 Len 10
2w3d: Vi1 IPCP: I CONFACK [ACKsent] id 8 Len 10
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#
There are four main points of failure in a PPP negotiation:
• No response from the remote device (your ISP)

• Link Control Protocol (LCP) not open
• Authentication failure
• IP Control Protocol (IPCP) failure
No Response from Your ISP
Your ISP not responding should not be a problem since you already verified that packets are incrementing on
the ATM0 interface in the inbound direction. However, if you see packets incrementing on ATM0 in the
inbound direction, and when you run a debug ppp negotiation you receive this output, contact your ISP to
verify that packets are sent to the Cisco DSL router.

*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


Router#undebug all
In this output there are only O packets, which are outbound packets. In order to successfully negotiate PPP,
there should be an I inbound packet from your ISP for each O packet sent. If packets are incrementing
inbound but you do not see I packets, contact your ISP in order to verify the packets that are sent to the Cisco
DSL router.
LCP Not Open
The LCP not being open is usually caused by a mismatch in PPP options. This mismatch occurs when the
Cisco DSL router has a PPP parameter configured that your ISP does not support, or when your ISP has a
parameter configured that the Cisco DSL router does not support. This output shows an example of a PPP
option mismatch:

*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.370: Vi1 LCP: O CONFNAK [ACKrcvd] id 181 Len 9
!−−− PPP option reject
!−−− PPP option that is rejected

Router#undebug all
Whether its an I or an O packet, a Configure−Negative−Acknowledge (CONFNAK) is indicative of a PPP

configuration mismatch. What this means is that one side of the PPP connection is asking for a PPP option
that the other side is unable or not configured to perform. If the Cisco DSL router sends the CONFNAK
(indicated by "O CONFNAK"), the Cisco DSL router is not able to perform or not configured for the option
the ISP sends. If the CONFNAK is sent by your ISP (indicated by "I CONFNAK"), you have configured an
option on the Cisco DSL router that your ISP is not willing to perform.
The line after the CONFNAK describes the option that is rejected. In this example output, the option is CHAP
but it could be any option. The only place on the Cisco DSL router where PPP options can be configured is
interface dialer 1. Issue the command show run interface dialer 1 in order to view your interface dialer 1
configuration.
If your ISP sends the I CONFNAK, look for commands under interface dialer 1 that match the line after the
CONFNAK and remove them. If the Cisco DSL router sends the O CONFNAK, add a command to interface
dialer 1 to properly negotiate PPP with your ISP. In the case of the router sending packets, you might need to
call the Cisco TAC in order to determine which command(s) need to be enabled on the Cisco DSL router.
Authentication Failure
An authentication failure occurs when your ISP is unable to authenticate your PPP username or password.
There are two scenarios in which this can occur. The first scenario is an authentication type mismatch, which
is caused when you do not properly configure the router. All the authentication configurations listed in this
document account for both PAP and CHAP authentication types. For configuration flexibility, you should
have both CHAP and PAP configured. If you do not have both configured, you might see output from a
debug ppp command like this output:

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
or

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
In order to correct both authentication mismatch problems, refer to the appropriate PPPoA implementation
option configuration and reconfigure PPP authentication.
The second authentication problem scenario you can encounter is an incorrect PAP username or password. In
order to determine if this is the problem, issue the command debug ppp negotiation. Assuming your router is
configured for both Challenge Handshake Authentication Protocol (CHAP) and Password Authentication
Protocol (PAP), as the configuration outlined earlier in this guide shows, your ISP might not be using PAP
authentication.
In order to determine the authentication used by your ISP, check the options in the I CONFREQ packet sent
to you from your ISP. If this packet is followed by an option called AuthProto PAP, you are using PAP. If
the I CONFREQ is followed by an option called AuthProto CHAP, you are using CHAP and should
proceed to How do I know if my CHAP username and password are correct?
How do I know if my PAP username and password are correct?

After you have confirmed that your ISP is using PAP, issue the debug ppp negotiation command to confirm
that your PAP username and password are correct.

*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: 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: 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]
If you have a PAP authentication problem, you should see the LCP state go to Open. Directly after the LCP
state change you should see PPP go into an Authenticating phase. If one of the next two lines contains I
AUTH−NAK, either your PAP username or PAP password is incorrect. At this point, you need to reconfigure
your PAP username and password using this sequence of commands. Note that your PAP username and
password are case sensitive.
Router(config)#interface dialer 1
Router(config−if)#ppp pap sent−username <username> password <password>
Router#write memory
How do I know if my CHAP username and password are correct?

After you have confirmed that your ISP uses CHAP, issue the debug ppp negotiation command in order to
confirm that your CHAP username and password are correct.

*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: 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: 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.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
If you have a CHAP authentication problem, you should see the LCP state go to Open. Directly after the LCP
state change you should see PPP go into an Authenticating phase. From this point you see a series of CHAP
lines. If the last of these lines shows I FAILURE, you have the wrong CHAP username and password. Use
this sequence of commands in order to correct your CHAP username and password. Note that your username
and password are case sensitive.
Router(config)#interface dialer 1
Router(config−if)#ppp chap hostname <username>
Router(config−if)#ppp chap password <password>
Router#write memory
How do I know when PPP authentication is successful?

This example shows a successful CHAP negotiation.

<... snipped ...>
*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
This example shows a successful PAP negotiation.

<... snipped ...>
*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
Why can I access some web pages with PPPoE but not others?
Access to only some web pages is a common problem when you run a PPPoE client on a router. By design,
PPPoE can support an MTU of up to 1492 bytes. Therefore, you must ensure that end devices send out frames
no larger than 1492 bytes. Limiting the MTU to 1492 bytes can be a problem because most PCs and end−user
workstations have a default MTU of 1500 bytes.
There are two options for adjusting the MTU size: adjust the MTU size at the router and adjust the MTU size
at the PC.
Adjust the PPPoE MTU Size on the Cisco DSL Router

Important Notes:
These configuration commands work only if you run Network Address Translation (NAT) or Port Address
Translation (PAT) on the Cisco DSL router.
The ip adjust−mss command in Cisco IOS® Software Release 12.2(2)XH has changed to ip tcp adjust−mss
<mss value>. This change is documented in Release Notes for the Cisco 800 Series Routers and Cisco 820
Series Routers for Cisco IOS Release 12.2(2)XH.
!
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 atm ilmi−keepalive
bundle−enable
!
interface atm0.1 point−to−point
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 <ip address of ethernet0> 0.0.255.255
!
Adjust the PPPoE MTU Size on the PC Using the Dr. TCP Utility
Complete these steps in order to change the MTU size on the PC. The registry change is saved when the
procedure finishes.
Note: The Dr. TCP utility is compatible with all Windows−based PCs.
1. Download the latest version of the Dr. TCP utility .

2. Refresh your browser page to ensure the page is current.
3. Run the Dr.TCP utility.
4. From the menu choose your Ethernet adapter.
5. In the MTU field, type 1492.
6. Click Apply to save the change, and then click Exit.
7. Reboot the PPPoE PC client.
You need to run the utility only once per PPPoE client PC.
Additional MTU Troubleshooting Steps

If you change the MTU size with Dr. TCP or on the Cisco DSL router and are still not able to browse certain
web sites, adjust the MTU size again. Change the MTU size to 1452 in Dr. TCP, or change the MSS adjust
value on the Cisco DSL router to 1412. If these sizes are too large, continue to lower the MTU sizes until you
reach a baseline of 1400 for Dr. TCP or 1360 for MSS adjust on the Cisco DSL Router.
Related Information
• ADSL Technology Support
• PPPoE Implementation Options
• Cisco DSL Router Configuration and Troubleshooting Guide
• Technical Support & Documentation − Cisco Systems
Contacts & Feedback | Help | Site Map

© 2012 − 2013 Cisco Systems, Inc. All rights reserved. Terms & Conditions | Privacy Statement | Cookie Policy | Trademarks of
Cisco Systems, Inc.
Updated: Oct 08, 2006 Document ID: 71124

Cisco DSL Router Configuration and Troubleshooting Guide Pppoe: DSL Router As A Pppoe Client Troubleshooting

Uploaded by

Copyright:

Available Formats

Cisco DSL Router Configuration and Troubleshooting Guide Pppoe: DSL Router As A Pppoe Client Troubleshooting

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cisco DSL Router Configuration and Troubleshooting Guide Pppoe: DSL Router As A Pppoe Client Troubleshooting

Uploaded by

Copyright:

Available Formats

Cisco DSL Router Configuration and

Troubleshooting Guide − PPPoE: DSL Router as a

827−ESC#show ip interface brief

If the CD light is off, continue with the next question.

Is your ISP using a DSLAM that supports the Alcatel chipset?

Is the ATM interface in an administratively down state?

Is the cable pinout correct?

1. The active pins on the DSL wall jack are incorrect.

Cisco DSL Router xDSL Port Pinouts

Router#show interface atm 0

Is the DSL operating−mode correct?

Is the circuit tested/provisioned correctly?

Are you receiving data from your ISP?

Router#show interface atm0

Is a PPPoE session up?

A PPPoE session that is successfully negotiated looks like this:

PPPoE Session Information

Are you receiving a PPPoE response from the aggregation router?

Router#debug vpdn pppoe−events

Is PPP negotiating properly?

Router#debug ppp negotiation

PPP protocol negotiation debugging is on

There are four main points of failure in a PPP negotiation:

• No response from the remote device (your ISP)

No Response from Your ISP

Router#debug ppp negotiation

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

*Mar 1 04:04:50.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)

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

*Mar 1 04:04:52.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)

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

*Mar 1 04:05:02.722: Vi1 LCP: MagicNumber 0x317722F4 (0x0506317722F4)

LCP Not Open

Router#debug ppp negotiation

!−−− 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

!−−− 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

Whether its an I or an O packet, a Configure−Negative−Acknowledge (CONFNAK) is indicative of a PPP

Router#debug ppp negotiation

!−−− Sends CHAP requests

00:34:29: Vi1 LCP: MagicNumber 0x01B63483 (0x050601B63483)

!−−− Receives PAP requests from the service provider

00:34:29: Vi1 LCP: MagicNumber 0xBC5233F9 (0x0506BC5233F9)

Router#debug ppp negotiation

!−−− Receives CHAP requests from the service provider

00:45:44: Vi1 LCP: MagicNumber 0xBC5C7DDC (0x0506BC5C7DDC)

!−−− Sends out PAP requests

!−−− Turn off ppp debug

How do I know if my PAP username and password are correct?

Router#debug ppp negotiation

!−−− "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"

How do I know if my CHAP username and password are correct?

Router#debug ppp negotiation