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(1)//authentication request is sent to radius server
radius:afterAuth_Accept:user(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(3)//real-time accounting packet is received from radius server
radius:afteracct_resp:user(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).