在组网规模相对大一些的局域网环境中，交换机的使用数量往往比较多，这些交换机在进行相互连接时，很容易被人为地连接错误，从而引发网络环路故障，要是对应交换机没有正常启用STP功能时，网络环路故障就会造成通信数据包在网络传输通道中反复不停地进行转发，最终形成广播风暴，那样一来整个局域网都有可能发生瘫痪故障。笔者在管理、维护局域网的过程中也曾多次遭遇到这种网络故障，其中一次故障的排除经历令笔者记忆犹新，笔者巧妙地利用了新交换机的网络环回监测受控功能，迅速地找到了发生网络环路的节点，现在本文就将该故障的排除过程还原出来，供各位朋友参考交流!

　　案发现场

　　笔者所管理的局域网规模比较大，大约有300台左右的计算机分布在10层大楼上，每一台计算机都通过100M双绞线连接到各个楼层的二层交换机上，每一楼层的交换机又会通过宽带光纤线缆直接与单位局域网的核心交换机相连，最后局域网通过硬件防火墙连上了Internet网络。 为了便于高效管理和维护网络，笔者根据每个楼层的实际情况，在每一台二层交换机上都划分了多个虚拟工作子网，这样一来每个虚拟工作子网的上网状态是相互独立的，即使某个虚拟工作子网中不幸遭遇了网络病毒的袭击，也不会对整个局域网网络的稳定运行造成影响;同时，日后遇到网络故障时，笔者也能将故障范围缩小到某个虚拟工作子网中进行解决，而不需要在整个局域网中进行大范围排查。

　　平时，局域网中的所有计算机都能正常上网。可是，最近某一天，笔者突然接到电话，说八楼某房间不能正常上网，恳请能够到现场帮忙解决一下;笔者刚刚放下电话，准备远程登录进对应房间所连的二层交换机上，看看其交换端口是否处于激活、启用状态时，接二连三的电话不停地打到笔者的办公室，一打听这些故障电话都来自八楼，并且都报告说计算机突然不能正常上网。

　　谜雾重重

　　这么多来自八楼的故障电话，告诉笔者整个八楼看来都不能上网了，难道是对应楼层的交换机发生了死机或其他意想不到的故障了?以前笔者也多次遇到过某个楼层都不能上网的故障，每次只要重新启动一下对应楼层的二层交换机，往往就能恢复整个楼层的上网状态了。为了验证自己的猜测，笔者立即尝试以telnet连接来远程登录位于八楼的二层交换机系统，可是等了好长时间，也无法远程登录成功，显然该楼层的二层交换机工作状态不正常。笔者不放心，又以系统管理员身份登录进入了局域网的核心交换机，利用该交换机后台管理系统提供的“display cpu”命令，查看了核心交换机上各个插槽板卡的CPU消耗情况，结果发现2号板卡的CPU使用率已经超过了50%，而根据以往经验笔者得知，核心交换机每块插卡正常工作时CPU使用率不会超过50%的，正常处于20%-30%之间波动(如图1所示);继续检查时，笔者发现2号板卡中的某个交换端口恰好就是连接八楼二层交换机的那个端口，使用“display interface”命令查看该端口的工作状态时，该端口已经处于“down”状态了，同时笔者看到该端口的输入、输出数据流量特别大，达到了惊人的每秒万兆级别了，这与平时的每秒几百兆级别相差也太大了，看来位于八楼的二层交换机系统的确存在问题。

图1

　　由于无法远程登录八楼的二层交换机系统，笔者只好赶赴该交换机的现场，通过观察交换机控制面板上的信号灯状态，并不能找出明显的故障痕迹;不得已，笔者只好先尝试着重新启动一下该楼层交换机系统，重启成功没有多久，八楼中的计算机又能正常上网了，原以为这种故障现象已经被成功解决了，可是没有多长时间，八楼的二层交换机系统工作状态又不正常了，并且该交换机与核心交换机相连的级联端口输入、输出数据流量还是特别大。后来，笔者在核心交换机后台系统不停地执行“display interface”命令，查看八楼的二层交换机级联端口工作状态，发现该端口的输出广播包不停地增大，很明显上述故障问题不在八楼的二层交换机系统上，很可能是连接到该交换机下面的虚拟工作子网中出现了广播风暴现象。

　　峰回路转

　　一般来说，引起广播风暴现象的因素有很多，比方说虚拟工作子网中存在网络病毒或硬件设备损坏现象，或者是某个交换端口出现了瓶颈现象，也有可能是虚拟工作子网中出现了网络环路现象。由于八楼的二层交换机上同时划分有几个虚拟工作子网，每个虚拟工作子网中又包含了多台计算机，如果单纯依靠手工方法去寻找网络硬件设备的损坏或网络病毒，工作量将十分巨大。考虑到虚拟工作子网中发生网络硬件损坏的现象属于极个别现象，这种极个别的硬件损坏一般不会造成这么大输出、输入数据流量，为此笔者打算先从网络环路因素着手，来排除整个八楼不能上网的故障现象。

　　那么如何才能判断八楼的二层交换机上是否存在网络环路现象呢?查看对应交换机的操作说明书时，笔者偶然发现该交换机支持交换端口网络环回测试功能，我们一旦启用了该功能后，该功能就会自动扫描本地交换机中的各个交换端口状态，要是扫描到某个交换端口下面存在网络环路现象时，它就能自动把扫描结果保存到交换机系统的日志文件中，日后当我们怀疑该交换机下面存在网络环路现象时，只要查看对应的日志文件就可以了。此外，笔者还发现如果将某个Trunk类型的交换端口配置成网络环回受控功能时，该功能只要发现目标交换机下面存在网络环路现象，就会自动将Trunk类型的交换端口设置成自动关闭状态，以便及时制止网络环路现象继续影响、冲击整个网络。

　　依照上述分析，笔者在八楼的二层交换机后台系统，使用“display loopback-detection”命令查看了该交换机与核心交换机相连的级联端口环回测试状态(如图2所示)，发现该级联端口果然启用了网络环回受控测试功能，难道是该功能发现了目标交换机下面存在网络环路现象，从而自动关闭了级联端口的工作状态?为了验证自己的猜测，笔者立即进入级联端口的工作视图模式，在该模式状态下执行了“undo loopback-detection control enable”字符串命令，来临时取消级联端口的网络环回受控测试功能，之后再次使用“display interface”命令查看了级联端口的工作状态，果然笔者看到该端口的工作状态已经从原来的“down”变成了“up”，看来目标交换机下面真的存在网络环路现象。

　　由于“display loopback-detection”命令不但可以查看到究竟有哪些端口启用了网络环路测试功能，而且也能查看到究竟是哪个交换端口存在网络环路，为此笔者再次执行“display loopback-detection”字符串命令，查找到e0/12端口存在网络环路现象。果然，当笔者在全局系统配置模式下，执行“display interface e0/12”字符串命令查看该端口的工作状态时，发现该命令无法成功被执行，看来该端口下面的网络环路现象已经将该端口的传输通道堵塞起来了。为了避免e0/12端口继续影响整个位于八楼的二层交换机工作状态，笔者立即执字符串命令“interface e0/12”，进入e0/12端口的视图模式状态，在该状态下继续执行“shutdown”字符串命令，将该端口的工作状态暂时关闭;此时，笔者再次查看位于八楼的二层交换机级联端口状态时，发现该端口的输入、输出数据包大小已经变成了每秒200MB左右，并且进行上网测试时，整个八楼的计算机上网状态都恢复正常了，至此笔者基本认定上述故障就是由于e0/12端口下面存在网络环路引起的了。

　　经过进一步检查，笔者了解到e0/12端口连接到813房间，到现场检查该房间的网络连接时，笔者看到该房间私自连接了一个交换机，恰好该房间的网络连接由于受修理窗户的影响，发生了变化，工作人员不小心在该交换机上制造了网络环路现象，经过重新进行正确的物理连接，再将e0/12端口的工作状态启用起来，笔者看到该房间也能正常上网了，同时其他计算机的上网状态也一切正常。

　　经验总结

　　从上面的故障排除过程来看，巧妙将某个楼层交换机的Trunk端口配置成网络环回受控测试功能，可以快速地定位网络环路故障具体的发生位置;当然，即使我们没有启用网络环回受控测试功能，网络环回测试功能同样也能通过“display loopback-detection”命令，快速定位到发生环路故障的具体端口，只是不会将该端口立即关闭，如此一来可能造成整个网络发生堵塞现象。

　　此外，需要提醒各位注意的是，不要轻易将核心交换机的Trunk端口配置成网络环回受控测试功能，因为如果核心交换机下面的任何一个虚拟工作子网只要发生网络环路现象，那么局域网中所有其他虚拟工作子网的工作状态都会受到影响。