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

None.

 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:

L2TP::Call1rcvICCNinstate5fromRemoteCall225

L2TP::ICall1recvCDNinstate9fromRemoteCall

L2TP::ITunnel2recvStopCCNinstate4

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).