“操作回溯”解决网络故障

网络环境

我校部分网络架构和业务分布如图1所示。

核心交换：锐捷S8606加AC扩展板，承载有线与无线业务。

汇聚交换：华为S7506，承载东西两栋教学楼的交换业务，与核心交换机通过两根万兆光纤聚合链接,同时链接锐捷桌面云虚拟化系统，六台服务器提供200点办公虚拟化支持。华三S5500，链接 FTP，DHCP等服务器设备。

接入交换：两栋教学楼楼层间部署华为S5130。

故障现象

早晨上班不久接到故障反馈：东教学楼A、B两个用户的桌面云打开速度慢，“开始”菜单无反应。按照描述，判断是一般应用层软件故障，丝毫没有联想到网络问题。笔者登录锐捷云桌面管理端，对A、B两个账户执行关机，重置系统操作。

没想到的是，在接下来的一个小时里，反映此症状的用户增加到十几人，范围也扩大到两栋教学楼的多个楼层。此时意识到可能是桌面云服务器故障，判断此十几个用户很可能是集中在某一台服务器上的。马上登录管理后台查看，结果各服务器CPU和内存使用率一切正常，仔细排查后发现，这些用户也并非集中在一台服务器上，推翻了此前的判断。

故障排查

与同事前往故障现场确认情况，有一典型办公室六台设备只有一台使用正常，其余都出现打开应用软件速度慢、无法关闭窗口情况。此时，意识到很可能是网络故障。将焦点集中到接入层交换机上，怀疑私接设备造成环路。测试网络连通率，在有故障的终端上Ping服务器，丢包率1-2%，未见较大异常。继续登录接入层交换机查看了CPU、风扇、温度等状态数据，皆一切正常。难道接入层设备没有问题？于是，继续登录汇聚层交换机查看各项数据，果不其然，还是一切正常。

此时，两栋教学楼的接入层和汇聚层检查完毕，依然无法定位故障，难道问题出在核心交换机上？同时，用户C反馈重要线索：今天FTP下载文件失败。此用户用的不是桌面云系统，而是实体机，侧方印证了故障出现在网络而非服务器上，很可能就出在锐捷S8606或者H3C 5500上。

图1 网络结构

图2 查看聚合组工作状况

随着故障范围缩小，决定变换思路，按照“操作回溯，现场还原”的原则，回忆之前对网络所做的各种操作，特别是对核心交换机的操作。时值周一，回忆上周五的操作如下：

1.增加了一个POE交换机直连核心交换机，做了更改VLAN和端口操作。

2.一台教室用服务器移机到H3C 5500上，也只在该交换机上增加了VLAN和端口。

无论如何也想不通，以上操作简单可靠，很难隐藏危机。但是依然制定策略如下：Down掉核心交换连接POE交换机的接口；将H3C 5500的VLAN恢复，并将教室用服务器关机。

故障解决

正要行动之际，忽然有人提示：周五下午有工程师过来更换了核心交换机上的一个万兆聚合模块。马上意识到问题可能出在这里，登录并查看聚合组工作状况，发现本应是2万兆的速率居然是1万兆（如图2）。

尝试删除聚合组，并重新配置，发现速率正常了，故障解除。

后来得知，当初聚合模块坏了一个，但是并未影响业务，工程师更换模块后也没有查看运行情况。猜测可能是新模块不匹配或是一端设备将其Down掉了。

经验总结

网络故障最难缠的就是隐性故障，时通时断或是时好时坏最挠头。本次解决故障过程，从应用层反馈故障挖掘到网络层诱因，又按照从低到高原则，从接入到核心逐层排查，最后冲刺阶段按照“操作回溯”方法进行定位，最终解决了故障。