随着网络架构的不断升级,数据流通经过的中间设备也日益增加。面对客户端出现的异常情况,常规分析手法难以确定故障原因。本案例将介绍如何使用网络流量分析技术精准定位客户端异常启动的根因。
据某学校的教学老师反馈,x.x.84.*网段无盘客户端频繁出现无法正常启动的情况,而无法启动的客户端需改为同网段其他地址就能够正常启动。该校网络运维人员通过网络、无盘应用等多方排查仍未能定位故障原因,该故障已经存在数月,这严重影响了正常的教学进程。
根据该校网络运维人员所描述的故障现象,科来网络分析工程师决定在“主核心交换机”以及“5700接入交换机”处配置端口镜像,将最接近客户端和最接近服务器的两段流量镜像到科来网络回溯分析系统,以采集流量并进行分析,如下图所示。
图 8-1
首先抓取能够正常启动的无盘客户端的全部流量,分析并理解无盘启动过程的详细原理,再模拟客户端无法启动的异常情况,通过对比分析两者的流量差异,找出无法启动的原因。
客户端x.x.84.59(下文简写*.59)可以正常启动。
首先,通过科来网络回溯分析系统对1#core_to_84client链路中*.59客户端进行数据回溯分析,发现该客户端流量峰值达到75mbps。再对所有udp会话按开始时间升序排列后,从视图中看到客户端先和x.x.140.93无盘服务器单播交互了dhcp,随后服务器立刻通过tftp、udp等方式将操作系统的文件推送至客户端。之后,*.59客户端向广播地址(x.x.255.255)发出dhcp报文,同时和电信dns服务器x.x.152.99产生dns流量,此时表明客户端*.59已经正常启动并成功登录操作系统,如下图所示。
图 8-2
在后面分析中我们发现了客户端无法正常启动与第一个dhcp报文有关,所以本节着重分析dhcp。*.59客户端开机后,首先向x.x.140.93:4011发送dhcp请求,内容含“服务器名”、“引导文件名”等请求字段,1.5ms后服务器返回消息报文——服务器ip地址为x.x.149.93、引导文件名为0600,如下图所示。
图 8-3
图 8-4
从上文分析中得知:*.59客户端收到服务器返回的dhcp消息报文并获知引导文件名为0600,*.59客户端依此向服务器发送tftp请求下载0600文件。当客户端下载0600文件完毕后,便能根据0600文件配置要求,向服务器请求下载操作系统文件直至加载成功。
图 8-5
通过以上分析,我们对无盘启动过程原理进行总结:
ip x.x.84.39(下文简写*.39)的无盘客户端无法正常启动。通过回溯分析,可以看到*.39客户端流量峰值为4kbps,而在该时段内链路1#core_to_84client的流量峰值为155mbp,链路5700sw_to_core流量峰值为155mbp。因为客户端、服务器网口带宽都是千兆,因此不存在网络链路拥塞情况,所以无盘客户端无法启动的原因可以排除是网络拥塞造成的。
图 8-6
图 8-7
图 8-8
根据对正常启动的无盘客户端的数据分析小结,我们知道无盘启动顺序首先与dhcp有关,因此提取了dhcp流量,进行数据挖掘与精细化分析。*.39客户端连续向x.x.140.93无盘服务器发送dhcp请求,但均未收到服务器返回的消息报文,所以*.39客户端无法获知引导文件名,更无法向服务器下载引导文件。至此基本上断定:由于客户端未收到服务器dhcp返回消息,导致其无法获知引导文件名,从而造成客户端无法启动,如下图显示。
图 8-9
通过以上分析,无盘启动失败的客户端未收到服务器dhcp返回消息报文的可能原因有:
1、网络中的核心交换机、汇聚交换机、接入交换机转发造成的服务器回应报文丢包;
2、客户端发出dhcp请求内容有误,导致服务器收到消息但不回应;
3、若非前两点原因,可得出无盘服务器收到了客户端dhcp正确请求,由于无盘应用某种原因而不回应dhcp消息报文。
针对第一点,分析方法:在“靠近”服务器端的地方采集流量,观察服务器返回dhcp消息报文情况便可判断是否是网络问题。
在链路5700sw_to_core采集接入交换机的上行流量,该流量是最靠近服务器的流量数据,观察到客户端发送了dhcp请求后并未收到回应,这表明客户端无法启动问题不是核心交换机及汇聚交换机转发丢包造成的。
图 8-10
将镜像口手动调整到5700接入交换机并下联到无盘服务器接口,依然可见客户端发送了dhcp请求但服务器未回应,这表明导致客户端无法启动的问题并非是接入交换机转发丢包造成的,如下图所示。
图 8-11
针对第二点,分析方法:对比正常启动与无法启动的dhcp请求报文字段值,便可判断客户端发出的内容是否有误。
*.39客户端无法启动,1分钟后将该客户端ip地址改为x.x.84.3,便能顺利启动无盘。我们对x.x.84.3进行流量回溯分析,可以看到启动过程与x.x.84.59客户端一致,过程详细如下图。
图 8-12
该客户端在ip为x.x.84.39时无法启动,在ip为x.x.84.3时正常启动,比对两个ip发出的dhcp请求内容,可以准确判断故障原因是否与客户端请求有关。通过比对信息,发现除了“客户端已经知道ip地址”不同外,其他字段值均一致。所以,可以排除第二点可能的原因,如下两图所示。
x.x.84.39向x.x.149.93发送dhcp请求中载荷hex字段值:
其中c0 a8 54 27为客户端已经知道ip地址x.x.84.39。x.x.84.3向x.x.149.93发送dhcp请求中载荷hex字段值:
图 8-13
其中c0 a8 54 03为客户端已经知道ip地址x.x.84.3。总结:两者除了ip地址的hex字段不同,其它一致。表明发出的请求内容都一致。
图 8-14
综上分析,可以判定服务器因某种原因未回应正常的dhcp请求,从而造成此类问题。建议在无盘服务器回查对比x.x.84.3、x.x.84.39两个ip配置差异性,便能找出某些客户端ip无法启动的原因。
根据上文分析,判断是服务器收到了客户端发出的dhcp正确请求但未回应,导致客户端无法获知“引导文件名”,造成启动失败。通过数据包级精细分析,我们可以确定无盘客户端ip无法正常启动原因与服务器有关。建议详查无盘服务器。
繁杂网络环境中的操作系统启动异常现象,时常并非客户端的环境问题,有可能与之配套的服务器、网络等环境因素有关。运用网络原始流量分析技术,对当前问题事件进行数据包级别的深入分析,以及对网络多段数据详情对比,能帮助网络运维人员迅速精准定位事件发生原因及唯独,可视化网络运维性能,从而优化网络运营水平。