使用L2TP协议的VPDN需要在LNS配置重协商

newaaa

现象描述:
    某局采用VPDN（NAS与LNS之间建L2TP隧道）的方式实现PC+手机上网，在调测过程中，发现用手机+PC的方式拨测时，NAS与LNS之间的L2TP隧道建立起来了，Tunnel id 都分配到了，但很快对端LNS把建立的隧道挂断了（对端LNS为CISCO的7206路由器）。

告警信息:

原因分析:
    该局是通过RADIUS识别“用户名/密码”判断是何种用户，当RADIUS识别到用户名是WAP，密码是WAP，被叫是172，判断为WAP用户，返回其中三个属性值Attr( 64)( Tunnel-Type): 0x32000003，Attr( 65)(  Tunnel-Medium-Type): 0x32000001，Attr( 67)( Tunnel-Server-Endpoint): 211.136.252.6给NAS，NAS根据收到的属性值与LNS之间建L2TP隧道，期间需要验证用户名、密码、TunnelPassword、LocalName等项，这是一次验证，一次验证通过，NAS（也就是RPU板）与LNS之间的L2TP隧道建立；出于安全性，NAS与LNS之间的L2TP隧道建立之后，用户终端（PC）与LNS之间传输数据之前，还须要进行用户终端与LNS之间的PPP协商，其中主要是对用户名、密码进行验证，这是二次验证；若二次验证通过，则用户可以上网，否则L2TP隧道将拆掉。
处理过程:
   经过对L2TP的LOG文件仔细分析，发现每次都是LNS把刚建立起来的L2TP隧道挂断，用户终端与LNS之间的PPP链路建不起来，我们推断可能是LNS侧不响应用户终端发起的二次验证，经过反复多次拨测和分析，最后在对端LNS的VPDN配置中加上LCP再次协商lcp renegotiation always ，问题解决。
LNS侧VPDN的配置（一部分）
vpdn-group 1
accept-dialin
  protocol l2tp
  virtual-template 1
terminate-from hostname as8010
local name lns
lcp renegotiation always；--LCP再次协商
no l2tp tunnel authentication     
                  
建议与总结:
NAS通过L2TP协议建立VPDN，需要二次协商，LNS侧需要加上“lcp 重协商”的配置。