现象描述
某局点的东软VPN设备和锐捷EG设备之间的VPN隧道不定时中断，另外还存在24小时锐捷设备定期端口down和up的现象。
【调查过程与原因分析】
1）抓包分析，当不定期中断的时候，一台锐捷EG设备发送的感兴趣流为172.18.160.0/19==192.168.12.0/26，而另一台锐捷设备发送的感兴趣流为172.180.161.224/27==192.168.12.5，两台锐捷设备发送过来的感兴趣流存在包含关系，导致隧道不定期中断。
2）现场通过debug抓包分析，在一阶段超时的时候（东软的一阶段超时时间配置的是86400，锐捷设备一阶段超时时间也是86400，东软二阶段超时时间是28800，锐捷设备二阶段超时时间是3600），锐捷设备向东软设备发送一个delete sa的报文，东软收到此报文后，会删除一阶段的SA信息，接着删除二阶段的SA信息，并删除反向注入的路由，此时锐捷设备删除了一阶段的SA，但二阶段还是使用旧的SA，接着锐捷设备发起一阶段的重新协商，东软设备收到新协商以后会产生新的SA，锐捷设备再发起二阶段的协商，但此时锐捷设备使用的旧SA来进行封装，而东软设备二阶段是新的SA，收到锐捷旧的SA信息以后不会解密也不会去处理，锐捷设备继续使用旧的SA进行探测，在30秒计时器超时以后，锐捷设备才会使用新的SA进行协商，但本身锐捷设备端口down的超时时间是41秒，也就是说只有11秒钟（其实并没有11秒，前面协商阶段一和阶段二需要3秒）的时候用于协商和探测，锐捷本身是10秒钟探测一次，如果在这8秒钟里正好没有探测或者网络不好探测失败，则41秒超时时间过去了，接口会down掉。这也是24小时超时的根本原因。
【解决方案】
目前锐捷已经增加了一阶段60秒重传机制，另外还增加了检查东软发送的删除阶段二通告关联的阶段一是否一致，如果不一致给提示并能正常删除旧的阶段二。现在有四台锐捷新版本设备在某局点测试，其中三台五天来并未发生中断，另一台中断是因为dpd超时，调查发现是该网点本身网络不好，只有2M带宽，中断是因为网络问题造成，因此在目前的情况下锐捷修改的点可以解决问题，但基于今后成百上千个网点上连和考虑到网络延时问题，建议锐捷方可以把30秒计时器时间改得更小，以便能尽量保证在超时以前有更多的时间可以协商和连接，避免锐捷设备端口down。
