Cisco DSL Router PPPoA – Troubleshooting
There are many reasons why your digital Subscriber Line (DSL) connection may not be functioning properly. The intention of this phase is to isolate the motive of the failure and repair it. the primary troubleshooting step is to decide which layer of your Asynchronous digital Subscriber Line (ADSL) provider is failing. There are 3 layers wherein the failure can occur.
- Layer 1 – DSL physical connectivity to your ISP's Digital Subscriber Line Access Multiplexer(DSLAM)
- 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
 |
| Fig 1.1 DSL Router PPPoA |
The easiest way to determine which layer you should begin troubleshooting 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 troubleshooting at Layer 2.
If the ATM interfaces are down, or if they keep coming up and then going down (they don't stay up and up), begin troubleshooting at Layer 1.
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?
To determine if the ATM0 interface is administratively down, issue the following 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 is not seeing 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.
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 down—no longer administratively down—take a look at the pinout of your DSL wall jack. The DSL Router makes use of a fashionable RJ−eleven (4−pin or 6−pin) cable to offer the ADSL connection to the wall jack. The center pair of pins on the RJ−eleven cable is used to hold the ADSL sign (pins three and 4 on a 6−pin cable, or pins 2 and 3 on a 4− pin cable). this does not follow to the Cisco 1417 which makes use of pins 2 and 5. in case you are positive you have got the right pins on the wall jack and the ATM0 interface remains down and down, update the RJ−11 cable among the DSL port and your wall jack. If the interface is still down and down after changing the RJ−11 cable, contact your ISP and feature the ISP verify that ADSL service has been enabled on the wall jack you're the usage of. if you aren't sure what pins in your wall jack are energetic, ask your ISP.
If you are using a Cisco 827 as your DSL Customer Premises Equipment (CPE), 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 pin outs, 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.
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 will not work on the 827.
Note that if you use the wrong power supply, the Cisco 827 will power up but will be 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 is using. The commands to configure operating−mode auto detection are as follows:
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
Layer-2 Issues:-
Do you have the correct Permanent Virtual Circuit (PVC) values (VPI/VCI)?
Complete the following steps to determine whether you have the correct virtual path identifier/virtual circuit identifier (VPI/VCI) values configured on the router.
1. Verify your version of Cisco IOS® software. Important: This will not work with Cisco IOS Software Release 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. Configure the router for debug logging.
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. Enable debugging on the 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. Make sure you have debug ATM events running on the Cisco DSL Router, and then go to a working Internet connection and begin to ping the IP address your ISP statically assigned to you.It does not matter whether you have configured this IP address on the Cisco DSL Router. What is important is that your ATM interface is up/up and that you are pinging the IP address your ISP gave you. If you don't see the expected output after the ping test, contact your ISP for support.
5. Disable debugging on the router.
<< wait 60 seconds >>
Router#undebug all
!−−− Turn off the debug events.
All possible debugging has been turned off.
Verify your VPI/VCI values, and then make the necessary changes to your configuration.
If you do not see output during the 60 seconds of debugging, contact your ISP
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. 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 packet counters are incrementing, you should be receiving PPP negotiation packets from your ISP. If this isn't the case, call your ISP.
If the output bound counters are incrementing, you should be sending PPP negotiation packets. If this isn't the case, check the configuration on the router. If PPP is configured properly, PPP negotiation packets are continually sent out the ATM0 interface.
Is PPP negotiating properly?
If Layer 1 is up and you have the correct VPI/VCI, the next step is to make sure PPP is coming up properly. 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 will use is debug ppp negotiation. The following output of this 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: 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
There are four main points of failure in a PPP negotiation:
1. No response from the remote device (your ISP).
2. Link Control Protocol (LCP) not open
3. Authentication failure
4. 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 the following output, contact your ISP to verify that packets are being sent to the Cisco DSL Router.
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 is sending the CONFNAK (indicated by "O CONFNAK"), the Cisco DSL Router is not able to perform or not configured for the option the ISP is sending. If the CONFNAK is being 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 following the CONFNAK describes the option that is being rejected. In this example output, the option is Challenge Handshake Authentication Protocol (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 to view your interface dialer 1 configuration. If your ISP is sending the I CONFNAK, look for commands under interface dialer 1 that match the line following the CONFNAK and remove them. If the Cisco DSL Router is sending 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 may need to call the Cisco TAC 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 may occur. The first scenario is an authentication type mismatch, which is caused when you don't properly configure the router. All the authentication configurations listed in this document account for both Password Authentication Protocol (PAP) and CHAP authentication types. For configuration flexibility, you should have both CHAP and PAP configured. If you don't have both configured, you may see output from a debug ppp command like the following:
Router#debug ppp negotiation
00:34:29: Vi1 LCP:OCONFREQ [REQsent] id 53 Len 15
00:34:29: Vi1 LCP: AuthProto CHAP (0x0305C22305)
!−−− Sending 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)
!−−− Receiving PAP requests from the service provider.
00:34:29: Vi1 LCP: MagicNumber 0xBC5233F9 (0x0506BC5233F9)
00:34:29: Vi1 LCP:
Router# debug ppp negotiation
00:45:44: Vi1 LCP: I CONFREQ [Listen] id 141 Len 15
00:45:44: Vi1 LCP: AuthProto CHAP (0x0305C22305)
!−−− Receiving 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)
!−−− Sending out PAP requests.
Router#undebug all
!−−− Turn off ppp debug.
To correct both authentication mismatch problems, refer to the appropriate PPPoA implementation option configuration and reconfigure PPP authentication.
The second authentication problem scenario you may encounter is an incorrect PAP username or password. To determine if this is the problem, issue the command debug ppp negotiation. Assuming your router is configured for both CHAP and PAP, as the configuration outlined earlier in this guide shows, your ISP may not be using PAP authentication.
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.
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]
If you have a PAP authentication problem, you should see the LCP state go to Open. Directly following 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 the following sequence of commands. Note that your PAP username and password are case sensitive.
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 <username> password <password>
Router(config−if)#end
Router#write memory
How do I know if my CHAP username and password are correct?
After you have confirmed that your ISP is using CHAP, issue the debug ppp negotiation command to
confirm that your CHAP username and password are correct.
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
If you have a CHAP authentication problem, you should see the LCP state go to Open. Directly following 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 the following sequence of commands to correct your CHAP username and password. Note that your username and password are case sensitive.
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface dialer 1
Router(config−if)#ppp chap hostname <username>
Router(config−if)#ppp chap password <password>
Router(config−if)#end
Router#write memory
How do I know when PPP authentication is successful?
The following example shows a successful CHAP negotiation.
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
The following example shows a successful PAP negotiation.
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
