洞察一枚资深老网工的网络排障全过程，值得收藏！?2022/12/26 10:48:47

哦不明白

在际工作过程中，交换机的状态很容易受到外界的干扰，那样一来局域中就会出现各种各样的络故障。为了保证络运行稳定，我们必须在平时对交换机进行妥善管理、维护，避免交换机发生故障。?我们知道，交换机是局域中一种很重要的络设备，它的工作状态与客户端系统的上状态息息相关。ip域名查询网的相关知识也可以到网站具体了解一下，有专业的客服人员为您全面解读，相信会有一个好的合作！

可是，在际工作过程中，交换机的状态很容易受到外界的干扰，那样一来局域中就会出现各种各样的络故障。



为了保证络运行稳定，我们必须在平时对交换机进行妥善管理、维护，避免交换机发生故障。

本篇文章，转载自一位资深老工的排障经历贴。他以前在对某大楼局域进行维护时，曾经遇到过物理连接不当，而造成楼层交换机法通的故障现象。这种络故障的排查曾让他颇费一番周折。



由于该故障相对典型，而且其排查思路可供借鉴，所以特此分享给你。



络排障作为络工程师必备的技能之一，也是让不少新手头疼不已。



1故障现场

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



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



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



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



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



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



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



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



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



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



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



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



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



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



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











2深入排查

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



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

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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



那么究竟是络病引起的络堵塞还是络环路引起的络堵塞呢

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



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

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



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



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



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



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



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







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



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



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



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



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



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



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



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



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



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



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



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



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



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









3故障解决

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



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



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



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