解决SVN5530在双机场景下 IPSEC VPN 业务切换慢问题

发布时间:  2014-11-03 浏览次数:  162 下载次数:  0
问题描述
某局点客户使用两台SVN5530设备挂在公网,配置了双机热备和ipsec vpn(对端设备USG),现在SVN设备业务切换正常,5秒不到就能切换过来,而ipsec vpn切换过来需要2-3分钟,客户希望让ipsec业务切换变快。
告警信息
处理过程
首先指导客户在两端设备上配置DPD和keepalive(对端是USG设备),测试发现切换还是较慢。
在把两端设备的IPSEC VPN ike版本设置成undo version2后
1) SVN主断开,主切备,15-17秒时间后,USG和SVN备重新建立起IPSec隧道。
2) SVN主起来,恢复主;30-32秒时间后,USG和SVN主重新建立起IPSec隧道。


根因
    SVN双机热备不支持IPSec会话的备份。在SVN主备切换后,USG保持着老的IKE SA和IPSec SA,未与切换后的SVN主设备重新建立IPSec隧道,致使IPSec业务一直未恢复。而手动清除USG的IKE SA和IPSec SA后,USG会快速和切换后的SVN主设备重新建立IPSec隧道,IPSec业务也随之恢复。

     USG,对于IKEv1方式的IPSec和IKEv2方式的IPSec,其检测对端下线的机制不同,导致检测间隔时间也不同。
对于IKEv2方式的IPSec,超时重传时间间隔从1到64以指数增长的方式增加。在8次尝试后还未收到对端发过来的报文,则认为对端已经下线,清空自己的IKE SA和IPSec SA。8次尝试间隔2分58秒,才能检测到对端已经下线。

对于IKEv1方式的IPSec,检测对端已经下线的时间长度,由下面的check-interval和retry-interval决定。
   ike dpd [ interval | on-demand ] check-interval [ retry-interval ]
check-interval表示触发DPD检测的时间,即在设定的时间间隔内没有收到对端IPSec报文,则会触发DPD检测。默认值为10。

retry-interval 表示DPD报文超时重传的时间间隔。发送DPD报文后,如果超过此时间间隔未收到正确的应答报文,DPD记录失败事件1次。当失败事件达到5次时,删除IKE SA和相应的IPSec SA。重传时间间隔仅对IKEv1方式的IPSec有效。默认值为5。

也就是默认情况下,IKEv1方式的IPSec,需要10+5*5=35秒,检测到对端已经下线。 而将retry-interval修改为2后,需要10+5*2=20秒,检测到对端已经下线。



解决方案
修改USG的ike peer参数,执行命令undo version 2,只能发起IKEv1协商,响应IKEv1协商。并且,修改SVN的ike peer参数,同样执行命令undo version 2,避免SVN作为IPSec发起方,USG不支持IKEv2而协商不成功。

建议与总结
该问题不是故障。是设备特性决定的。

END