Eudemon 1000E由于ARP处理异常导致业务中断

发布时间:  2013-05-30 浏览次数:  141 下载次数:  0
问题描述
典型组网如图1所示,Eudemon 1000E作为内网的出口网关,保护内网的用户访问Internet。当Eudemon 1000E的配置完成后,内网用户正常上线一分钟,此后业务全部中断,无法上网。
告警信息
处理过程
步骤 1 检查出口线路。
1. 出现故障时,在Eudemon 1000E上执行display interface [ interface-type [ interface-number ] ]命令查看出接口状态,发现端口状态为UP且有报文收发。
2. 拿一台PC替换原来与Eudemon 1000E互连的外网设备,并把外网设备与Eudemon 1000E互连的地址配置在PC上,再使用ping命令,发现可以互相Ping通。
由此我们可推定出口线路正常,排除原因一。
步骤 2 检查Eudemon 1000E的基本配置。
1. 执行display ip interface brief命令查看Eudemon 1000E上所有接口的详细信息,显示地址配置正确,端口状态正常。
2. 执行display zone interface命令查看到Eudemon 1000E上所有接口都已经加入安全区域。
3. 通过检查配置发现已经打开了各接口所在区域的包过滤规则。
4. 执行display ip routing-table命令查看路由表中有实现业务互通的全部路由。
通过以上几点,可以排除原因二。
步骤 3 检查与Eudemon 1000E相连的对端设备的配置。
因为与Eudemon 1000E相连的对端设备可能是其它厂家的设备,我们不能直接查看。我们可以拿一台PC替换Eudemon 1000E,并把Eudemon 1000E的出口地址配置在PC上,查看PC上网的情况,发现各种业务正常,由此可以排除原因三。
步骤 4 检查是否存在ARP欺骗。
1. 业务中断后在Eudemon 1000E上,执行display arp命令,查看Eudemon 1000E的ARP缓存,显示有对端设备的ARP地址,并与此前没有变化,说明在Eudemon 1000E上没有ARP欺骗的情况。
2. 在Eudemon 1000E上Ping对端设备地址不通,初步怀疑故障与对端有关联。在Eudemon 1000E上线的最初执行debugging arp packet命令,分析debugging过程如下:
1. Eudemon 1000E向对端设备发出ARP请求报文。
2. 对端设备回应ARP响应报文给Eudemon 1000E。
3. 对端设备再次向Eudemon 1000E发送ARP请求报文。

按照正常的ARP请求情况下,对端设备不应该再次向Eudemon 1000E发送ARP请求报文,因为对端已经返回了ARP响应报文,说明对端已经知道Eudemon 1000E这段接口IP地址对应的MAC地址。
4. Eudemon 1000E没有给对端设备回应ARP响应报文(即不做理会)。
3. 通过以上的debugging过程分析,怀疑对端设备上可能运营某种防止ARP欺骗的机制。但由于对端设备不能做修改,可以在Eudemon 1000E的出接口上修改ARP表项的老化超时时间,即执行arp expire-timeexpire-time,此处的expire-time值为60秒。因为每60秒后ARP条目得以刷新,在刷新的同时,也使得对端设备的ARP缓存得以刷新,从而规避问题。
4. 通过在Eudemon 1000E的出接口上修改ARP表项的老化超时时间为60秒,发现业务恢复正常,此时确定原因为对端设备运营某种防止ARP欺骗的机制造成业务不通。
根因
 原因一:出口线路问题
 原因二:Eudemon 1000E配置问题
 原因三:与Eudemon 1000E相连的对端设备配置问题
 原因四:ARP欺骗
建议与总结
防止ARP欺骗的机制,基本原理如下:
当本端设备收到某条ARP请求时,把对端IP地址和MAC地址的映射记录下来并标记为未验证。向对端发送ARP回应报文,随后反过来再向对端设备发送ARP请求报文,如果能够收到ARP回应报文,说明不存在ARP欺骗,将相应的ARP条目设置为可信状态。如果在规定的时间(在本例中为1分钟)未收到回应则将相应条目至于不可信状态。在这个期间(1分钟内),数据报文能够正常转发。如果超过这个期间,就会因为ARP的问题,导致从对端设备回来的数据报文转发失败。

END