复杂网络环境下网络故障排查实例分享

       客户的网络环境可能比较复杂,网络中的网络设备中也配置了很多安全规则,可能会导致我们的软硬件产品部署到客户环境后遇到了一系列无法连通、丢包等多种问题。本文大概讲述一下之前遇到过的两个典型的网络故障问题,给大家提供一个借鉴或参考。

1、概述

       在项目验收之前,软硬件设备要先部署到客户环境中先试用调试一段时间,一是看软硬件产品能否正常运行,二是看产品的功能及性能能否达到客户的要求。其中产品能否适应客户复杂的组网环境是一个很重要的考察指标,该指标的含义是,软硬件产品在客户的网络环境中能跑通,产品各项业务能顺利地完成联调测试。

       如果产品在客户的网络环境中无法正常跑通,特别是安全级别比较高的客户,他们的网络环境异常复杂,出于安全考虑客户也无法提供完整的网络拓扑结构,只能从我们的产品出发逐步去排查,使用wireshark在产品侧和服务器侧分别进行抓包分析,同时请客户的网络管理部门协助我们一起排查。

       复杂的网络问题排查起来会相当地吃力,要一步一步分模块分区域进行排查,需要消耗大量的人力和时间,需要安排专业的技术支持和研发人员去客户现场排查。更为头疼的是,问题有时不是必现的,有时很容易出现,有时又要运行很长一段时间才会复现,这样时间会持续的更久,有的项目的问题排查会持续一个月到数个月之久。

2、实例1:组播包被网络设备拦截、IP与MAC地址绑定

       在某客户环境中部署了一台主服务器和一台备用服务器(其实真实环境下部署了多台不同业务的服务器,此处为了方便说明问题特意做了简化描述),当主服务器出问题时,要将备用服务器运行起来,快速地切换到备用服务器上。两台服务器使用的是同一个IP地址,当切换到备用服务器时,备用服务器会发出抢占IP的广播包通知大家,该广播包是以组播的方式发出去的。但广播包发出去后,备用服务器会经常出现网络不通的情况,导致产品的业务时不时地出现问题。

       经分析发现,当我们以组播的方式发送抢IP的广播包时,华为交换机收到该包后处理的有问题,直接将服务器在交换机上的端口给短暂的停用一会,感觉可能是华为交换机的bug。但客户是比较信任华为的产品质量的,认为是我们服务器的问题,需要我们从服务器侧去解决。华为是大厂商,又是专业做网络设备的,他们做出的网络设备都是电信级的,所以客户不太相信问题出在华为的交换机上,坚持认为是我们的服务器有问题。后来我们将广播的方式由组播改成单播,才解决备用服务器抢不到IP的这个问题。

       此外,备用服务器在抢到目标IP后还是有问题,备用服务器还是连接不上。经研究发现,客户的网络安全级别比较高,网络设备系统中配置了大量的安全规则,在规则中将IP和MAC地址绑定了,一旦发现使用IP的设备的MAC地址对应不上,就会将该设备封禁掉。比如主服务器中,IP是和主服务器的MAC地址绑定的,当切换到备用服务器上后,IP对应的设备MAC地址就变了,这样就会被网络设备拦截了,导致备用服务器还是连接不上。所以让客户在网络设备中放行主备服务器公用的IP,保证该IP不会因为对应的MAC地址变更被封禁。

3、实例2:设备中的Linux系统TCPIP网络协议栈中的重定向选项被关闭,导致无法响应网关回馈的ICMP  redirect重定向消息

       在某客户的环境中,部署了多套软硬件产品,结果在某个网络节点下的产品在与服务器交互中有严重的丢包现象,在其他网络节点中产品都没问题。客户也有使用其他厂商设备,把其他厂商的设备拿到这个有问题的网络节点下也没问题,就单单我们的产品有问题,这个问题很是诡异,在刚开始排查时是一头雾水。

       设备中配置了网关,设备也可以通过该网关连到服务器上,但通过该网关走出去的连接会有明显的丢包,业务上因为有明显的丢包也出现了明显的异常。后来经过wireshark抓包发现,当设备通过网关发送连接请求时,网关会给设备回复一个ICMP redirect重定向的消息,回复该消息的目的是让设备不要走我这个网关出去,而是从消息中携带的IP出去。但通过tracert查看路由得知,发起的连接还是从网关出去的,并没有从网关回复的ICMP redirect消息中指定的IP出去,这个也是比较奇怪的。

       后来现场的技术支持在设备的linux系统中输入sysctrl –a|grep redirect命令查看系统TCPIP协议栈的所有的重定向选项,结果看到系统TCPIP协议栈的redirect选项都被关闭了,如下所示:

扫描二维码关注公众号,回复: 13988843 查看本文章

       这就对了,设备内置的Linux系统的重定向选项都被关闭了,导致网关给设备回复ICMP redirect重定向消息后,设备没有处理该重定向消息,将该条消息丢弃了,所以设备通过协议栈发起的连接还是走网关的,并没有走网关指定的IP出去的。

       后来经核实,给设备安装的Linux系统是经过裁剪并重新做了很多配置的,其中出于安全考虑,特意将系统中的TCPIP协议栈的重定向选项给关闭了,这个和排查的结论就能对上了。后来通过脚本将系统TCPIP协议栈的重定向选项都打开了,设备连接服务器就没问题了,所有的业务也都能正常稳定地跑起来了。

猜你喜欢

转载自blog.csdn.net/chenlycly/article/details/124044427