Connection Failure with D Router as the User When L2TP Is Enabled in Coordinatio

Created Apr 02, 2016 08:10:58Latest reply Apr 02, 2016 14:14:08 870 1 0 0

The MA5200F adopts L2TP in coordination with an LNS. The VPDN is test normally on a PC, but the connection fails with the D router (The PPPoE dialing is available) as the user

  • x
  • convention:

Acessrock     Created Apr 02, 2016 14:14:08 Helpful(0) Helpful(0)

Alarm Information
1) The debugging information on the MA5200F (see the detailed process): * [0.60759870-] L2TP-8-02023000: L2TP::RcvStopCCN 2) The debugging information on the LNS (see the detailed process): *Mar 1 20:26:21.282: Vi1 VPDN: PPP LCP not accepting sent CONFACK Handling Process

1) Because the test on the PC is normally, there should be no problem about the L2TP configuration between the MA5200 and the LNS, and the tunnel should be established normally. 2) Through the trace of debugging packets on the MA5200F, it is found that the sent information is rejected by the LNS. So it is necessary to find reasons on the LNS. * [0.60759870-] L2TP-8-02023000: L2TP::RcvStopCCN 3) The debugging information on the LNS indicates that the packets from the MA5200F are normally received by the LNS until ICCN packets, and the L2TP session is normally established. But the LNS rejects the LCP CONFACK packets, as shown in the following information: *Mar 1 20:26:21.114: Tnl/Cl 13380/29 L2TP: I ICCN from MA5200F tnl 24, cl 1 *Mar 1 20:26:21.114: Vi1 PPP: Phase is DOWN, Setup *Mar 1 20:26:21.278: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up *Mar 1 20:26:21.278: Vi1 PPP: Using set call direction *Mar 1 20:26:21.278: Vi1 PPP: Treating connection as a callin *Mar 1 20:26:21.278: Vi1 PPP: Phase is ESTABLISHING, Passive Open *Mar 1 20:26:21.278: Vi1 PPP: No remote authentication for call-in *Mar 1 20:26:21.278: Vi1 LCP: State is Listen *Mar 1 20:26:21.282: Vi1 LCP: I FORCED CONFREQ len 14 *Mar 1 20:26:21.282: Vi1 LCP: MRU 1492 (0x010405D4) *Mar 1 20:26:21.282: Vi1 LCP: AuthProto PAP (0x0304C023) *Mar 1 20:26:21.282: Vi1 LCP: MagicNumber 0x0463AE06 (0x05060463AE06) *Mar 1 20:26:21.282: Vi1 LCP: I FORCED CONFACK len 10 *Mar 1 20:26:21.282: Vi1 LCP: MRU 1492 (0x010405D4) *Mar 1 20:26:21.282: Vi1 LCP: MagicNumber 0x9E670900 (0x05069E670900) *Mar 1 20:26:21.282: Vi1 VPDN: PPP LCP not accepting sent CONFACK 4) It can be seen that the LNS does not receive the LCP parameter (PAP or MRU) negotiated by the MA5200F and D router. The largest possibility is that the MRU value is too large. Solution: The LNS forces the LCP renegotiation. Modify the configuration at the client to the MRU non-negotiation or a smaller value. Configure the MTU under the VT on the MA5200 to a smaller value (1460 or so), and modify the MRU at the client to a smaller value. At last, the problem is solved by using solution a. Root Cause

The LNS does not receive the LCP parameter (PAP or MRU) negotiated by the MA5200F and D router. The largest possibility is that the MRU value is too large.

  • x
  • convention:

Responses

Reply
You need to log in to reply to the post Login | Register

Notice:To ensure the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but not limited to politically sensitive content, content concerning pornography, gambling, drug abuse and trafficking, content that may disclose or infringe upon others' intellectual properties, including commercial secrets, trade marks, copyrights, and patents, and personal privacy. Do not share your account and password with others. All operations performed using your account will be regarded as your own actions and all consequences arising therefrom will be borne by you. For details, see“ Privacy Policy.”
If the attachment button is not available, update the Adobe Flash Player to the latest version!
Fast reply Scroll to top