资深网络工程师的网络排障全过程，太强了！【附工具下载】

为什么要确认故障？

用户的描述可能是含糊不清的，报告的故障也不一定是真实的故障点，所以需要有经验的工程师进行确认故障的工作。

确认故障的四个要素：

• 故障的主体：哪个网络业务出现了故障。

• 故障的表现：故障的现象是什么样的。

• 故障的时间：用户是什么时间发现的故障，以及专业人员推测的故障出现的真实时间。

• 故障的位置：哪个网络组件出现了故障。对故障现象进行准确的描述。

最后应确认该故障是否属于自己的负责范围，即自己是否被赋予了相应的权限来处理该故障。

需要收集哪些信息：收集信息阶段主要是收集与故障相关的信息，如文档、网络变更情况等。

如何收集这些信息：

• 使用设备自身的操作命令；使用信息收集工具，如抓包工具、网管软件等。获取授权：

• 在对信息安全要求较高的网络环境中，对信息的收集是需要得到授权的，有时需要签署书面的授权文件。收集信息阶段的风险评估：

• 有些收集信息的操作，如对路由器或交换机执行”debug”命令，会导致设备的CPU占用率过高，严重的情况下甚至会使设备停止响应用户的操作指令，从而引入额外的故障现象。

• 所以在收集信息的时候应评估这些风险，平衡引入新故障的风险与解决现有故障的紧迫性之间的关系，并明确的告知用户这些风险，由用户来决定是否进行风险较大的信息收集工作。

如果通过逐一排查找到了故障的根本原因，并排除了故障，网络故障排除的流程就可以结束了。

复杂的网络环境中，故障现象消失后仍然需要观察一段时间，一方面确认用户报告的故障已经得到了解决，另一方面确认故障排除的过程中没有引入新的故障。

收尾工作包括相关文档的整理、信息的通告等。需要对之前网络故障排除流程中所有进行了变更的配置或软件进行备份，并做好故障排除文档的整理和移交工作。

为了避免同样的故障再次发生，在此阶段应该向用户提出改进建议。

我当时所负责的写字大楼包含若干个公司，为了保证每个公司都能独立上网，并且要求它们的上网状态不受其他公司的影响，我选用了路由交换机作为大楼网络的核心交换机。

同时在交换机上对每个单位设置了不同的虚拟工作子网。

由于每家单位分布在不同的楼层，每个楼层分布的公司数量也不完全相同，有的楼层有两、三家单位，有的楼层多达五、六家单位。

不同楼层的单位工作子网全部通过对应楼层的交换机，连接到大楼局域网中，并通过大楼网络中的硬件防火墙访问Internet网络。

为了提高网络管理效率，网络管理员平时都会通过远程连接方式对交换机进行管理、维护。

可是，那天早上一上班，我在扫描诊断局域网核心交换机各个交换端口的工作状态时，发现其中某个交换端口处于down状态。

于是我查看了网络管理档案，找到连接该端口的是五楼某二层交换机。

远程登录该楼层交换机时，发现迟迟无法登录成功，使用 ping 命令测试该交换机的 IP 地址时，返回的结果为“Request time out ”;

就在我纳闷为什么没有人报故障时，电话铃声如期而至，果然来自五楼的用户开始接二连三地报修网络故障了。

根据上述故障现象，我估计可能是楼层交换机的工作状态出现了意外。

于是跑到该故障交换机现场，切断该设备的电源，过一段时间后再次接通电源，进行重新启动。

等到启动操作完毕后，我又使用了 ping 命令测试该交换机的 IP 地址。

此时返回的结果已经正常，而且远程登录操作也能够很顺利地进行。

然而，半个小时之后，该故障交换机又出现了相同的故障现象，并且进行 ping 命令测试时，又返回了不正常的测试结果。

后来我不放心，又重新经过反复启动测试，发现故障交换机始终无法正常 ping 通。

01 深入排查

刚刚有说，DNS就相当于电话簿。

既然经过反复重启不能解决问题，我估计引起该故障的原因比较复杂，考虑到这种故障现象在网络管理过程中经常会碰到。

于是我按照下面的思路进行了深入排查：

考虑到整个大楼网络中，只有五楼的某个楼层交换机出现这种现象，所以，我初步判断可能是该楼层交换机自身问题引起的。 

为了能够确保可以准确定位故障原因，我准备利用一台工作状态正常的交换机来替换故障交换机，看看故障现象是否仍然存在。

同时，将那台被怀疑可能存在问题的交换机连接到一个独立的网络工作环境。

经过半个小时的测试、观察，我看到那台被连接到独立网络环境的故障交换机工作状态是正常的，而且在该网络环境下可以ping通它的 IP地址。

而那台新替换的交换机连接到大楼网络后，却不能正常 ping通了。

依照这些现象，我认为五楼的交换机自身出现问题的可能性几乎没有。在排除了故障交换机自身状态因素后，我对整个大楼网络的组网结构和网络状态重新进行了回顾。

由于大楼中其他楼层的用户都能正常上网，唯独五楼的一部分用户不能上网。

查阅五楼的组网资料，我看到五楼分布了五家单位，当时网络管理员在五楼布置了两台楼层交换机，将它们通过级联方式连接在一起；

同时在这两台交换机中划分了五个虚拟工作子网，保证了每家单位都能独立地工作于自己的虚拟工作子网中。

既然核心交换机上的对应端口已经被down掉，那么整个五楼的所有单位都不能上网才对，为什么现在只有一部分用户上报故障现象呢?

等到上班时间一到，我立即电话联系了其他几家没有报修网络故障的公司。得到的答复是说：他们刚刚才发现网络访问不正常，正准备向大楼网络管理员求救。

如此说来，整个五楼的所有单位都是不能正常上网的，那么引起该故障的原因应该在这几家单位的虚拟工作子网中。

在将故障排查范围锁定在位于五楼的五家单位之后，我认为既然重新启动五楼某个交换机的设备，能够暂时地将网络故障恢复。

只是在半个小时之后，相同的网络故障现象才会再次现象。

对照这种特殊的现象，我怀疑可能是网络广播风暴，造成了交换机在一定时间内发生了堵塞现象，最终堵死了核心交换机的对应交换端口。

为了便于分析故障，我利用网络监听工具对五楼交换机的级联端口进行了网络传输数据包分析。

结果发现无论是输入数据包流量，还是输出数据包流量，都非常地大，几乎超过了正常数值的100倍左右，这说明四楼的网络中出现了网络堵塞现象。

那么究竟是网络病毒引起的网络堵塞？

还是网络环路引起的网络堵塞呢？

我打算观察一下故障交换机级联端口的状态信息变化，特别是输出广播包的变化。如果输出广播包每秒钟都在不停增大的话，那十有八九就能证明五楼网络中存在网络环路现象。

基于这样的分析思路，我使用 Console控制线直接连接到故障交换机上，以系统管理员身份登录进入该系统后台。

同时使用 display 命令查看了该交换机级联端口的输出广播包的变化，并且每隔一秒钟查看一次，之后比较每次查看的结果。

经过反复测试，我发现故障交换机的输出广播包大小果然在不断地增大着。

这说明五楼的五家单位中，肯定存在网络环路现象。

仔细查看了五楼的两台交换机，我发现它们之间的物理连接是正常的。

此外，这两台交换机的各个交换端口直接与五楼各个房间的墙上上网插口相连。

按理来说，只要各个房间不随意使用交换机进行级联， 应该不会出现网络环路现象的。

现在，既然证明五楼网络中存在网络环路现象，这说明肯定有人在随意使用交换机进行扩展上网，我们只要找到扩展交换机，并对它的物理连接进行检查，就能迅速找到具体的故障节点了。

于是我电话联系了五楼各家单位的网络管理员，要求他们对各个办公房间进行检查，并上报使用下级交换机的房间。

没有多长时间，检查结果就反馈给了我，竟然有10个左右的房间使用了下级交换机进行扩展上网。

这时我知道这10个房间的网络连接，最有可能出现网络环路现象，那究竟是哪一个房间呢？

难道我要依次到各个房间的现场，查看他们的网络连接吗？

经过认真考虑，我找来了组网资料，将这10个房间使用的交换端口号码一一找了出来。

之后使用网络线缆直接插入到这些交换端口中，并在这些端口的视图模式状态下，依次ping故障交换机的IP地址。

结果ping到第六个交换端口时，我发现从该端口无法正常ping通。

为了判断该交换端口是否真的存在问题，我又在该交换端口视图模式状态下，使用 display 命令查看了该交换端口的状态信息。

经过查看分析，我发现该交换端口的输入、输出数据包大小明显不正常。于是，我估计该交换端口肯定是造成故障交换机工作状态不正常的原因。

查阅档案资料后，我迅速根据那个交换端口号码，找到了对应的那个上网房间。

到了现场后，我发现该房间中仅有的两个上网端口，都连接了小集线器，而这两台集线器下面都连接有几台计算机。

更要命的是还有一条网络线将它们直接连接在了一起，这样一来这两个集线器之间就形成了一个网络环路。 

该环路造成的广播风暴最终堵塞了故障交换机的级联端口，从而造成了整个楼网络都不能正常上网。

02 故障解决

将该多余的网络线缆拔除之后，我重新查看了该交换端口的状态信息。结果发现输入、输出数据包大小都恢复了正常。

再次查看核心交换机上对应的交换端口状态时，发现原因的“down”状态已经变成了“up”状态，而且此时我也能正常ping通四楼的故障交换机了。

这说明，问题果然是由五楼某个房间的用户非法扩展使用交换机或集线器引起的。后来，我经过进一步询问上网用户了解到，他们的房间在前天晚上进行了打扫除，当时所有的网络线全部被拔了下来。

当清洁工作结束之后，上网用户由于对连接知识了解不多，就随意进行了插接，最终造成了网络环路现象。

对于大多数普通用户来说，你能感受到的是畅爽的网络体验，但网络的稳定运行不是一朝一夕就能达成的，需要一线网工的不断努力和坚守。

向他们致敬！