Hot Downloads

Troubleshooting PPP Internet Connection On A Cisco Router

Written by Administrator. Posted in Cisco Routers - Configuring Cisco Routers

4.3333333333333 1 1 1 1 1 Rating 4.33 (6 Votes)
Troubleshooting PPP Internet Connection On A Cisco Router - 4.3 out of 5 based on 6 votes
Pin It

The Point-to-Point Protocol is one of the most popular protocols around used by engineers, ISPs and companies around the globe for authentication of remote users & router equipment.

The most common application of PPP is your ISP dialup account, whether it be ADSL, ISDN or even the good old analog modems - PPP is found in all of these connectivity methods.

PPP is a non-proprietary protocol, which also explains its wide adoption by vendors around the world.

Example Scenario

In this example, we'll be dealing with the PPP connection to our ISP. We are using a Cisco 2811 ISR router equipped with an HWIC-ADSLI card, which means we are connecting via ADSL and therefore using a virtual Dialer interface configured with our ISP account.


We will examine how to verify the connection to our ISP account and explain the steps that should be followed in case we are unable to connect. There are many reasons why a router might not be able to log in to the ISP account so we will cover the most common problems, which include: Incorrect username, incorrect password, invalid IP address & invalid authentication configuration.

Troubleshooting these possibilities will provide you with enough experience and information to help you deal with other similar problems that can occur during the ppp negotiation process.

Remember, the goal here is to cover these problematic cases, but most importantly - gear you up with enough experience and troubleshooting skills to help you tackle similar situations.


Incorrect Username or Password

This is a typical errors. You've mismatched the username and password, therefore unable to connect to the ISP account.

Under normal operation, you wouldn't be able to detect that your router is unable to connect to your ISP account. The results (e.g no Internet connection) will surely start making you wonder and start searching until you find out what's happening.

A quick check on the Dialer0 interface will confirm that there is a problem, as you notice there is no IP address assigned to it:

R1# show ip interface brief
Interface                 IP-Address        OK?       Method       Status    Protocol
FastEthernet0/0        YES        NVRAM       up           up
Service-Engine0/0       YES        TFTP           up          up
FastEthernet0/1       YES        NVRAM       up           up
Virtual-Access1       unassigned        YES        unset         up           up
Virtual-Template1         YES       TFTP           down      down
Virtual-Access2       unassigned        YES        unset         down      down
Virtual-Template2         YES       TFTP          down       down
Virtual-Access3       unassigned        YES        unset         up           up
Dialer0                   unassigned        YES        IPCP          up           up

To check whether there is an issue with the ISP account and get a deeper insight to the source of the problem, issue the following debug command:

*Apr 25 20:03:23.731: Vi3 CHAP: O RESPONSE id 188 len 39 from "This email address is being protected from spambots. You need JavaScript enabled to view it."

This debugging provides quite a bit of information during the authentication process and we've only included a portion of it. We don't want to analyse everything here, because later on we will deal with all this information without choice :)

In our lab, we've deliberately set an incorrect password to force these errors, and unfortunately the ISP response is not being specific on where the problem is. The response 'user unknown' tells us that either our username, This email address is being protected from spambots. You need JavaScript enabled to view it., or password is incorrect.

At this point, we at least know one of the two is causing the problem.

You can check your username by viewing the dialer configuration and try re-inserting your password, just in case you mistyped it the first time. If this gives the same result, then obviously the account credentials you've got are incorrect.

Thankfully most ISPs have a customer web-portal that allows them to log into their account and change usernames and passwords. If you've got this capability, use it. If not, a quick call to your ISP will prove most useful.

Lastly, if you would like to check you have inserted the correct account password, under your dialer interface, copy the type 7 password value from the dialer configuration:

Next, visit our Cisco Type 7 Password Decrypt / Decoder / Cracker Tool and insert the hashed password so it can reveal it:



Incorrectly Configured IP Address on Dialer interface

In many cases, engineers might select to statically configure the static IP address, purchased from the ISP, directly on the dialer interface. If all settings are correct and the ISP has provided the correct IP address you should expect no surprises.

It happens many times though, that the incorrect IP address has been provided and when the router authenticates to the ISP it is unable to route any packets towards the Internet.

The short and effective way around this problem is to never assign any IP address to the Dialer interface unless it's required. Services such as Crypto VPN tunnels to remote offices, various Internet services served to the Public (mail, web etc.) do not usually require you to configure the statically assigned IP address directly to the Dialer interface.

Allowing the ISP take care of the IP address assignment to your Dialer interface will in many cases help you avoid these problems completely.

For the purpose of our example, assuming we've got an incorrect IP address configured, following is the repeated behaviour we would encounter:

R1# debug ppp negotiation
PPP protocol negotiation debugging is on

*Apr 26 00:26:53.815: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to up
*Apr 26 00:26:54.525: Di0 IPCP: Install route to
*Apr 26 00:26:54.529: Di0 IPCP: Remove route to
*Apr 26 00:26:54.529: Di0 IPCP: Remove default route thru
*Apr 26 00:27:34.624: Di0 IPCP: Install route to
*Apr 26 00:27:34.629: Di0 IPCP: Remove route to
*Apr 26 00:27:34.629: Di0 IPCP: Remove default route thru
*Apr 26 00:28:00.579: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to down

The router will continuously install and remove the default route provided by the ISP. The Virtual-Access interface is then shutdown and brought back up. This behavior will continue non-stop until you either shutdown the Dialer interface or correct the problem.

Changing our tactic, we decide to correct this problem and let the Dialer interface negotiate the IP address from our ISP:

R1# config terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# interface dialer 0
R1(config-if)# ip address negotiated
R1(config-if)# end

On the next cycle of negotiation, the Dialer interface is assigned its IP address:

*Apr 26 00:34:48.667: %LINK-3-UPDOWN: Interface Virtual-Access3, changed state to up
*Apr 26 00:34:48.667: %DIALER-6-BIND: Interface Vi3 bound to profile Di0
*Apr 26 00:34:50.655: %LINK-3-UPDOWN: Interface Dialer0, changed state to up
*Apr 26 00:34:52.595: Di0 IPCP: Install negotiated IP interface address
*Apr 26 00:34:52.599: Di0 IPCP: Install route to
*Apr 26 00:34:53.217: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to up


Invalid Authentication Configuration

Another common configuration problem is the ppp authentication direction, where your router should only authenticate to your ISP and not expect the ISP to authenticate to it as well.

The typical ppp authentication command under the dialer interface provides a number of supported authentication protocols (pap, chap, ms-chap, ms-chap-v2) but also allows you to control which way the authentication occurs:

R1(config-if)# ppp authentication chap ?
....WORD ..... ..Use an authentication list with this name
....callback .....Authenticate remote on callback only
....callin .........Authenticate remote on incoming call only
....callout .......Authenticate remote on outgoing call only
....default .......Use the default authentication list
....eap........... Extensible Authentication Protocol (EAP) ....Microsoft Challenge Handshake Authentication Protocol Microsoft CHAP Version 2 (MS-CHAP-V2) ....Allow use of username*OTP for one-time passwords
....optional .....Allow peer to refuse to authenticate
....pap ...........Password Authentication Protocol (PAP)

Notice the 'callin' option in the above output. This option is almost always used and effectively tells the router not to expect the peer router (ISP) to authenticate back (to local router).

Here is the debugging output when we configure the ppp authentication method without the 'callin' parameter:

*Apr 26 01:16:07.647: Vi3 PPP: Outbound ip packet dropped
*Apr 26 01:16:07.651: Vi3 PPP: Outbound ip packet dropped
*Apr 26 01:16:07.651: Vi3 LCP: I CONFREJ [ACKsent] id 204 len 9
*Apr 26 01:16:07.651: Vi3 LCP: AuthProto CHAP (0x0305C22305)
*Apr 26 01:16:07.651: Vi3 LCP: O CONFREQ [ACKsent] id 205 len 15
*Apr 26 01:16:07.651: Vi3 LCP: AuthProto CHAP (0x0305C22305)
*Apr 26 01:16:07.651: Vi3 LCP: MagicNumber 0x1E7F0974 (0x05061E7F0974)
*Apr 26 01:16:08.347: Vi3 LCP: I CONFREJ [ACKsent] id 205 len 9
*Apr 26 01:16:08.347: Vi3 LCP: AuthProto CHAP (0x0305C22305)
*Apr 26 01:16:08.347: Vi3 LCP: Failed to negotiate with peer
*Apr 26 01:16:08.347: Vi3 PPP: Sending Acct Event[Down] id[2D]
*Apr 26 01:16:08.347: Vi3 LCP: O TERMREQ [ACKsent] id 206 len 4
*Apr 26 01:16:08.347: Vi3 PPP: Phase is TERMINATING
*Apr 26 01:16:08.387: Vi3 LCP: I TERMACK [TERMsent] id 206 len 4
*Apr 26 01:16:08.387: Vi3 LCP: State is Closed
*Apr 26 01:16:08.387: Vi3 PPP: Phase is DOWN
*Apr 26 01:16:08.387: Vi3 PPP: Phase is ESTABLISHING, Passive Open
*Apr 26 01:16:08.387: Vi3 LCP: State is Listen
*Apr 26 01:16:08.387: Vi3 PPP: Outbound ip packet dropped
*Apr 26 01:16:08.391: Vi3 PPP: Outbound ip packet dropped
*Apr 26 01:16:08.391: Vi3 PPP: Outbound ip packet dropped
*Apr 26 01:16:09.111: Vi3 PPP: Outbound cdp packet dropped
*Apr 26 01:16:10.547: Vi3 LCP: Timeout: State Listen
*Apr 26 01:16:10.547: Vi3 PPP: Authorization NOT required
*Apr 26 01:16:10.547: Vi3 LCP: O CONFREQ [Listen] id 207 len 15
*Apr 26 01:16:10.547: Vi3 LCP: AuthProto CHAP (0x0305C22305)

So always ensure that you add the 'callin' parameter at the end of the 'ppp authentication' command.

Further analysing the authentication protocol, generally all ISPs support CHAP primarily and PAP as a secondary option. However, due to the large amount of security breaches on accounts, PAP support is being dropped as it sends all account details in clear text, without any type of encryption.

CHAP authentication on the other hand sends a hashed result of the stored password. The router sends its hashed result to the ISP so it may compare it. If the calculated hash is identical to the one received by the ISP router, that means the password stored by each matches the other.

Following is the recommended ppp authentication options for most ISPs:

ppp chap hostname This email address is being protected from spambots. You need JavaScript enabled to view it. password

Of course, if your ISP supports CHAP, you can safely remove all references to the PAP authentication method.


Article Summary

This article showed you how to configure and troubleshoot your PPP connection on your Cisco router. We covered the most common problems found in PPP connections, how to identify them and successfully resolve them and also provided general information about PPP which can be used to troubleshoot other similar scenarios.

If you have found the article useful, we would really appreciate you sharing it with others by using the provided services on the top left corner of this article. Sharing our articles takes only a minute of your time and helps reach more people through such services.

Back to Cisco Routers Section

Pin It

Articles To Read Next:


Cisco Routers

  • SSL WebVPN
  • Securing Routers
  • Policy Based Routing
  • Router on-a-Stick

VPN Security

  • Understand DMVPN
  • GRE/IPSec Configuration
  • Site-to-Site IPSec VPN
  • IPSec Modes

Cisco Help

  • VPN Client Windows 8
  • VPN Client Windows 7
  • CCP Display Problem
  • Cisco Support App.

Windows 2012

  • New Features
  • Licensing
  • Hyper-V / VDI
  • Install Hyper-V


  • File Permissions
  • Webmin
  • Groups - Users
  • Samba Setup