SR8805-F二次认证失败问题处理经典案例

某客户组网如图所示，PPPOE用户通过拨号触发SR8805-F设备与对端BRAS设备进行二次认证，建立L2TP隧道，建立隧道的协商参数由服务器下发，但是建立L2TP隧道的时候，建立失败。另外，现场在L2TP组试图下配置了source-ip，从debug信息来看，也没有生效。

*Jun 15 17:41:23:591 2016 HNYX_Bras_SR8805F_Test L2TPV2/7/EVENT: -MDC=1;

 TunnelID=3134: Processed invalid SCCRP packet in Wait-reply state, sent StopCCN packet to the peer and deleted the local tunnel.

从现场收集的debug信息来看，可能是隧道验证出现了问题，现场测试不经过二次认证的话，PPPOE可以拨号成功，于是在这两种方式下对服务器进行抓包，从两次抓包结果来分析，在不进行二次认证的时候，设备与radius服务器交互的radius access-accept报文中不存在tunnel password字段，但是在进行二次认证的时候，服务器会给设备下发建立L2TP隧道时候的密码，但是从服务器的配置来看，服务器上配置的隧道密码等参数都是都是和对端设备对应起来的，但是隧道始终建立不起来。

于是在实验室测试，使用free-radius，深澜等其他服务器对接都没有问题，从实验室测试结果来看，使用现场的密码，tunnel-password字段仅有21字节，但是现场tunnel-password字段已经是34字节了，问题就在于现场的服务器为何解析出来的密文长度这么长，需要了解下该服务器厂商的专业人员，解释一下该密码处理方式，后经过现场人员的交流，确认是服务器厂商下发隧道密码加密算法的问题，修改加密算法后，二次认证成功。

另外的一个问题，source-ip不生效的问题，也需要服务器侧下发该属性，否则不生效。

1、对于二次认证不成功的问题，需要检查AAA服务器侧下发隧道的密码加密方式，修改后，二次认证成功。

2、对于source-ip在设备上配置后不生效的问题，也需要服务器侧配置，给设备下发Tunnel-Client-Endpoint属性。

对于遇到类似的问题，现场需要开启debug信息来确认失败的原因，然后服务器侧抓取设备与服务器交互的报文，最好也可以抓取设备与对端设备交互的报文。排查的时候，最好多方面排查，不仅仅从设备侧排查，这样才能抓住问题的根本原因。