Version: MA5200F 7135. RADIUS floods L2TP-related attributes.
Topology: PC of users----L2----MA5200F----INTERNET----LNS.
Symptoms: It prompts failure to connect with remote server during dialing of users.
1. Check the configurations of MA5200F, and no problem is found.
2. At MA5200F, check the debugging information of Radius packets, and the attribute flooded by RADIUS is normal.
3. At MA5200F, ping the address of LNS, and the route is reachable.
4. At MA5200F, check the debugging information of L2TP; it is found that MA5200F has transmitted SCCRQ message to request setup of tunnel with LNS, but no response from LNS is received. After five times that MA5200F have transmitted SCCRQ messages, the users are cut off.
5. Check the configurations of LNS, and no problem is found. At LNS, check the debugging information of L2TP, and the SCCRQ request sent by MA5200F has been received, but it does not respond SCCRP message. Check the configurations of LNS, and the LAC in vpdn-group is configured with tunnel node name. The tunnel node name transmitted in SCCRQ messaged sent by LAC(MA5200F) is the host name (default) of MA5200F, not the same as the one configured at LNS. Up to now, The problem is located at the configuration of relevant parameters for the cooperation between LNS and LAC. At LNS, change the tunnel node name of LAC to the same as MA5200F( also, change MA5200F to be the same as the LNS. There are two methods: a) change the host name, but it may influence the BIND services; b) In L2TP group view, use tunnel name command to change the tunnel node name). Test it through dialing again, and tunnel and session can set up normally. Users can access LNS through dialing at remote, and the problem is solved.
1. MA5200F is problematic in configuration.
2. RADIUS floods false attributes.
3. The route between LAC(MA5200F) and LNS is problematic.
4. LNS is problematic in configurations.