No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>


To have a better experience, please upgrade your IE browser.


R2611 functions as LNS of L2TP, and PC cannot dial in sometime, or it takes a long time for dial-in

Publication Date:  2012-07-27 Views:  302 Downloads:  0
Issue Description
R2611 functions as LNS of L2TP, and PC cannot dial in sometime, or it takes a long time for dial-in 

Alarm Information


Handling Process
After investigation, we find radius server does not require accounting, so disable the accounting functionality of radius server (undoaaaaccounting-schemepppdefaultradius), and configure it to aaaaccounting-schemeoptional, viz. accounting as optional.  Let the user perform a test, and the user feedbacks that he could dial up normally. After another day’s application and test, the user reflects he could dial in successfully.

Root Cause

 That some PCs could dial in successfully indicates the configurations of L2TP are correct. Since the user is configured to radius authentication, the problem perhaps arises from radius authentication and accounting.

1. Turn on the debug switch (debugl2tpall) of L2TP, and you have the following information:




From the information above, we could find that the ICCN information received by LNS (R2611) from LAC has been in negotiation stage in a session; later, CDN and StopCCN packets are received, which needs to release Session and Tunnel, indicating that Session has not been established.

2. Turn on the switch of radius packet (debugradiuspacket and debugradiusevent),and you have the following information:

radius:afterAuth_Request:user[13](1)//authentication request is sent to radius server

radius:afterAuth_Accept:user[13](1)//successful authentication is received from radius server

radius:afteracct_start_reqinRD_LocalAcctStart:user(13)state(2)//start-accounting packet is sent to radius server;

radius:afteracct_resp:user[13](3)//real-time accounting packet is received from radius server

radius:afteracct_resp:user[13](0)//packet of accounting down is received from radius server

The information above shows that the failure of accounting by radius server results in abnormal L2TP dialup for users. After checkup for the configuration, it is found the user is configured with radius accounting (aaaaccounting-schemepppdefaultradius).