NE40E-AR2240 ipsec 业务突然不通

发布时间:  2016-06-26 浏览次数:  225 下载次数:  2
问题描述

NE40E-AR2240 ipsec  业务突然不通  如下图所示:

AR01侧的用户无法访问NE04侧的服务器1

告警信息
Apr  6 2016 22:05:11+00:00 BRIDB1_WN_AR_01 ADP-IPSEC/4/hwIPSecTunnelStateDown:OID: 1.3.6.1.4.1.2011.5.25.224.2.1.2 IPSec tunnel is deleted.(Policy name = zghz_map,policy seqnum =10,interface name =GigabitEthernet0/0/0,Local ip address =10.255.238.98,remote ip address =10.255.238.97,remote port =500)
Apr  6 2016 22:05:11+00:00 BRIDB1_WN_AR_01 %%01ADP-IPSEC/5/TunnelStateSwitched(l)[57886]:The IPSec tunnel state is switched DOWN. (local-ip: 10.255.238.98, remote-ip: 10.255.238.97)
Apr  6 2016 22:05:15+00:00 BRIDB1_WN_AR_01 ADP-IPSEC/4/hwIPSecTunnelStateDown:OID: 1.3.6.1.4.1.2011.5.25.224.2.1.2 IPSec tunnel is deleted.(Policy name = zghz_map,policy seqnum =10,interface name =GigabitEthernet0/0/0,Local ip address =10.255.238.98,remote ip address =10.255.238.97,remote port =500)
Apr  6 2016 22:05:15+00:00 BRIDB1_WN_AR_01 %%01ADP-IPSEC/5/TunnelStateSwitched(l)[57887]:The IPSec tunnel state is switched DOWN. (local-ip: 10.255.238.98, remote-ip: 10.255.238.97)
Apr  6 2016 22:05:21+00:00 BRIDB1_WN_AR_01 ADP-IPSEC/4/hwIPSecTunnelStateDown:OID: 1.3.6.1.4.1.2011.5.25.224.2.1.2 IPSec tunnel is deleted.(Policy name = zghz_map,policy seqnum =10,interface name =GigabitEthernet0/0/0,Local ip address =10.255.238.98,remote ip address =10.255.238.97,remote port =500)
Apr  6 2016 22:05:21+00:00 BRIDB1_WN_AR_01 %%01ADP-IPSEC/5/TunnelStateSwitched(l)[57888]:The IPSec tunnel state is switched DOWN. (local-ip: 10.255.238.98, remote-ip: 10.255.238.97)
Apr  6 2016 22:05:23+00:00 BRIDB1_WN_AR_01 ADP-IPSEC/4/hwIPSecTunnelStateDown:OID: 1.3.6.1.4.1.2011.5.25.224.2.1.2 IPSec tunnel is deleted.(Policy name = zghz_map,policy seqnum =10,interface name =GigabitEthernet0/0/0,Local ip address =10.255.238.98,remote ip address =10.255.238.97,remote port =500)
处理过程

1、从配置和日志分析发现, 问题发生时AR同NE之间BGP邻居未down,只有部分IPSEC隧道down,因此,首先排除网络问题导致中断可能,确认不是链路问题导致。

日志信息见附件

2、 发现IPSEC down时长有规律
分析日志发现首次IPSEC down是从4月2日开始,约17小时50分中断一次, 前几次IPSEC down因为是在放假或下班期间,down一段时间后链路都自动恢复了,因此,未对客户造成影响:


 

3、发现怀疑点
根据链路down规律分析,下一次down时间是在4月7日 19:40分,提前通知准备好到时间采集debug信息;
同时AR侧和NE侧沟通,发现双方IPSEC一阶段IKE老化重协商时间选择存在差异,AR是在隧道存活时间的70%时间点,而NE是在90%,当AR作为协商响应方时,当到达70%的时间点,AR认为IKE 一阶段已经不可靠,需要进行重新协商了,而对端NE设备又不会发起一阶段重协商,因为NE认为要到90%的时间点才会从新协商,这就导致在这20%的时间差中可能出现问题。    
结合正常的流程分析如下:

两端正常情况下IPSec协商流程:

 

 

问题出现过程两端IPSec协商情况:



 AR设备IPSec第一阶段为协商响应方,在软超时时间到达后(第一阶段老化时间的70%为软超时时间,早于NE设备90%的软超时时间),IPSec不会主动发起第一阶段协商,同时会进入到FD状态;在第一阶段FD状态下AR设备不会主动发起第二阶段协商,需要等待对端设备发起第二阶段协商;而NE设备出现不发起IPSec协商或协商失败的情况,则导致IPSec第二阶段表项到达老化时间进行老化删除,从而导致IPSec业务中断。 AR当前的实现都是符合协议的,AR和Cisco设备对接也不存在问题,只是对于会话刷新时间点的选择上,协议并没有明确规定,各产品有各自的实现,所以才会出现AR的刷新时间点和NE不一致情况。

根因
AR 一阶段的老化重协商时间早于NE时间,AR在进入FD状态后不会主动发送二阶段协商,而NE侧如也不发送主动协商,或协商失败,则会导致IPSEC 二阶段释放,从而导致业务中断。
解决方案

为了解决双方IPSEC在二阶段协商的配合问题,通过修改AR设备在IPSec第一阶段的协商方式,主动适应对方IPSec第二阶段不协商情况,且该功能在V200R005SPH017正式补丁已经实现。
加载V200R005SPH017补丁后,中断链路全部恢复,后续观察没有在出现。

END