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).
END
Author : wuzheng FW0342
Document ID: EKB0000111318
Fault Type :