MA5200G作LAC由于Radius下发L2TP属性错误导致隧道无法建立

发布时间:  2012-07-27 浏览次数:  137 下载次数:  0
问题描述
MA5200G下的L2TP用户拨号失败:故障用户原本一直使用正常,突然故障,MA5200G上无用户相关上下线失败记录。
告警信息

处理过程
1、在MA5200G侧针对故障用户的MAC做Trace业务跟踪,结果如下:
  [2009/11/25 19:58:40-][L2TP][0010-5cfa-2d8d]:Send SCCRQ to LNS (userid=49326,callid=5663,tunnelid=9044)                                                     
  [2009/11/25 19:58:40-][L2TP][0010-5cfa-2d8d]:Failed to analyze LNS packet(callid=5663,reasoncode=30)
对端LNS设备上跟踪的结果为LAC发送了L2TP隧道协商终止报文STOPCCN。
2、将该用户所在的域更改为不认证不计费,配置本地配置L2TP组测试后反复拨号测试均正常,基本判断为Radius侧问题导致。debug radius报文确认radius仅下发如下属性:
[Tunnel-password(69)                ] [21] [0196e65a31ee406fcb2e7d8145b394a2d0
45e4]    
[Tunnel-Server-Endpoint(67)         ] [17] [1][x.x.x.x]                
[Tunnel-Medium-type(65)             ] [6 ] [1][1]                             
[Tunnel-Type(64)                    ] [6 ] [1][3]   
除密码无法判断下发是否正确外,其他属性均正确。
3、在MA5200G上debug l2tp error进一步查找隧道协商失败的原因,结果如下:
LAC ERROR  ::Chap response doesn't pass authentication!
结合L2TP协议分析:
L2TP在建立控制连接的过程中,混合了一个简单,可选的,类似CHAP的鉴权系统。当LAC或LNS需要建立一个连接时,在将在SCCRQ和SCCRP消息中发送Challenge AVP,当对端接收到此消息,将回应一个Challenge Response AVP,如果回应消息不匹配或不认识,隧道的建立将被取消。在此类鉴权过程中,LAC和LNS的共享密码是必须的,此密码与对AVP加密的密码是一样的。
这其中过程就是LAC发送SCCRQ会携带chanllenge1发送给LNS, 由LNS按照规则(CHAPID+密码+chanllenge1)计算出 chanllenge1 response,在SCCRP中带回,同时SCCRP也带回LNS侧的chanllenge2 ,然后LAC侧根据本地的(CHAPID+密码+chanllenge1)计算出值和LNS侧回应作验证,同时也计算出(CHAPID+密码+chanllenge2)计算出 chanllenge2 response 发送给LNS,LNS再进行匹配验证。两端都验证通过tunnel才建立。
4、由此可以判断,如果chanllenge报文出错,密码错误的可能性最大,为了确认是否为密码问题导致,在MA5200G侧配置了禁止接收Radius下发的Tunnel-password(69)号属性,测试结果为用户拨号正常,至此,可以确认为Radius侧下发密码错误。
5、Radius端重新下发正确密码后,问题解决。
根因
由于故障突然发生,且LAC和LNS侧均未修改过配置,判断可能原因有:
1、LAC或LNS侧设备故障。
2、Radius侧下发的相关L2TP属性有错误。
本案例属于第二种情况
建议与总结
1、在处理由Radius下发L2TP属性时用户拨号失败的问题时,如果检查两端配置都正确的情况下,建议修改为本地配置L2TP组test  l2tp-tunnel测试,来缩小故障范围。
2、在处理L2TP隧道密码错误的问题时,密码错误会直接导致SCCRP报文协商不通过,且在调试LAC和LNS设备时都不会明确打印出隧道密码错误,而是chanllenge报文处理错误,因此需要注意chanllenge中所对应的相关属性。

END