引言：在网络管理工作中，经常遇上一些莫名其妙的“软故障”，这些故障并非由于硬件所引起， 而是由于病毒、木马、用户误操作所导致，这类故障通常需要结合多类数据分析来定位其源头进行解决。本文介绍了一个由于用户误操作所导致的网络故障以及解决办法，希望给各位同行解决此类问题带来启发。

突发性的网络故障往往令网络管理人员措手不及，需要在最短的时间内解决故障，恢复业务运转，这也是网络管理人员的价值所在。以往的网络故障很多都是由于硬件故障引起的，因此找到故障设备进行更换即可，我们称之为“硬故障”。这种故障解决相对简单，通过对各类网络设备的状态监控即可进行故障定位。

随着硬件工艺水平的提高及容灾技术的发展，发生“硬故障”的概率越来越低。但是由于病毒、木马、ARP攻击、用户误操作等一系列原因导致的网络故障比例大幅增加，我们称之为“软故障”。解决软故障比解决硬故障更加困难，如果没有丰富的网络维护经验，仅凭网络设备状态监控系统，是很难定位软故障源头的。如果定位不了故障源头，一方面难以解决故障，另一方面也无法向上级领导提供准确的故障报告及相关建议，难以彻底杜绝此类网络故障的发生。所以，解决软故障的能力很大程度上反映了网络管理人员的水平。

笔者所在单位不久前发生过一起网络故障，这次故障牵涉范围很广，对业务的影响也比较大。但是，笔者最终在较短时间内找到了故障源头，及时解决了问题。同时，也提交了详细的故障报。下面将对该起网络故障进行详细介绍。

背景及故障现象

笔者所在单位是在CBD大楼办公，各个业务及职能部门分布在不同的楼层，中心机房设置在5楼，每个楼层会有一个网络设备间用于放置接入交换机及相关配线架，然后通过综合布线工程将各个楼层办公室的办公电脑接入网络。每层网络设备间的接入交换机与汇聚交换机通过光纤互联，汇聚交换机与核心交换机也通过光纤互联，这是一个典型的“核心-汇聚-接入”的三层网络架构。局域网内服务器IP通过静态方式分配，用户电脑的IP则是由一台Windows Server 2003 DHCP服务器自动分配。每个楼层都是一个独立的网段，通过VLAN技术进行划分，交换机品牌全部为思科。

某工作日上午8:10左右，还没有到上班时间，笔者接到用户反映：6楼业务部门两台电脑无法上网。由于其他楼层的用户上网均无异常，当时笔者以为是病毒或者电脑自身问题所导致，就联系了维护电脑终端的同事前去处理。10分钟后，同事打来电话，说故障现象很奇怪，那两台故障电脑都进行了重启，一台恢复正常，另一台还是不能上网，而且后续开机的电脑，也是一部分正常，另一部分不能上网。由于马上就要到8:30上班时间，如果拖延时间太长，恐怕会影响业务，引起用户不满。

笔者立即亲自赶赴现场，在排除了硬件、病毒及网络后台相关的问题之后，发现故障主机通过DHCP获得的IP都是192.168.1.0/24网段的地址，但是单位DHCP服务器统一分配的IP均是172.19.0.0/16网段的地址，而且分配的网关、DNS等其他参数也都不正确。如果为故障主机静态指定一个正常IP，则该主机的网络通信恢复正常。但是故障主机数量太多，不可能挨个手动指定IP。而且，故障源头没有找到，后续肯定还会出现问题，所以必须尽快找到故障源头并加以解决。

故障分析

故障现象初步分析，用户无法上网的原因就是DHCP分配地址错误，但是之前已经排查过单位的DHCP服务器，证明其运行正常。考虑到故障仅仅发生在6楼业务部门这一个网段，这只能有一个解释，就是该网段内出现了另外一台DHCP服务器。用户主机在发出DHCP广播请求时，两台DHCP服务器均会收到请求包并给出响应，然后将相应的DHCP配置下发给对应的主机，这时就会发生冲突，哪个响应包先到达主机，主机就会“采纳”哪台DHCP服务器下发的配置，就会出现上述同一网段IP地址不一致的现象。

如果主机获得的不是单位DHCP服务器下发的配置，那么肯定无法上网。由于单位最近并无访客接入内网，所以能够排除恶意攻击的可能，最有可能就是用户无意的误操作所导致的。只有找出这台冲突的DHCP服务器，才能彻底解决问题。

看着故障主机DHCP分配的192.168.1.0/24网段的IP，笔者突然想起前期给各部门部署过一些TPLink无线路由器，这些无线路由器内部分配的IP就是192.168.1.0/24这个网段，但是当初部署时，从楼层交换机出来的主线接入的都是无线路由器的WAN口，这两个网段应该逻辑上已完全隔离，即使无线路由器上启用DHCP服务，也不会影响到172.19.0.0/16网段的主机。除非有人将WAN口的主线接到LAN口上，并且没有关闭无线路由器自带的DHCP服务，这种情况下，无线路由器也会为局域网内其他主机提供DHCP服务，造成主机DHCP配置混乱，无法正常上网。

故障解决

通过分析得出故障的原因后，下一步就必须找到“惹事”的无线路由器。由于6楼业务部门部署无线路由器范围大，且数量较多，每个设备的物理位置也不能确定，挨个排查不现实，只能通过后台数据来进行分析， 最终定位目标无线路由器。笔者所采用的步骤如下。

1.分析单位DHCP服务器IP分配数据，定位该无线路由器所接入的交换机端口。如果主线接入了无线路由器的LAN口，并且接入该无线路由器的终端是从单位DHCP服务器获取的IP，那么主线对应的交换机端口很可能对应多台无线终端，只要找到端口和终端数是“一对多”的关系，那么该交换机端口接入的很可能就是目标无线路由器。由于单位的DHCP服务器上都记录了当前的终端接入信息，可以通过主机名称来区别是否为手机终端（如图 1）。

从图1可以看出，主机名中含有“android”字符的记录应该为android手机终端，这种命名方式是android系统所特有的。下面再通过交换机上的ARP表和MAC地址转发表来确定这几个手机终端是否都接入同一个交换机端口。由于DHCP服务器上已经记录了手机终端的MAC地址，所以可以通过“show macaddress address XXXX.XXXX.XXXX” 和“show cdp neighbor”命令最终获取手机终端的接入端口，结果如下图2和图3所示。

从上图2和图3可知，这两个手机终端均接入了同一台交换机的Gi0/25口，可以确定从该交换机Gi0/25口接入的是目标无线路由器。

图1 手机终端DHCP记录

图2 接入端口示意图1

图3 接入端口示意图2

2.定位该无线路由器的物理位置。通过步骤（1）找到目标无线路由器所接入的端口后，我们就可以着手进行处理。为了尽快恢复局域网的正常并找到目标无线路由器的物理位置，笔者在交换机对应端口上使用了“shutdown”命令，将该端口关闭，然后通知故障用户重新启动电脑，果不其然，所有主机立即恢复正常。

过了几分钟后，客服人员打来电话，说6楼某业务科室反映手机连接无线路由器无法上网，经过现场检查，该科室内无线路由器主线果然是接在LAN口上，经核实，系昨天一位同事将笔记本带来公司，但是该笔记本无线网卡是坏的，只能通过有线网络上网，于是顺手将无线路由器上的WAN口主线拔下来临时接在笔记本上使用，用完后就随意插到了LAN口上，由于无线路由器的DHCP功能并没有关闭，结果就导致了今天的网络故障。

至此，此次网络故障的源头已经找到。笔者将主线接回WAN口，并将交换机端口重新开启，经过测试，网络恢复正常。

故障总结

这次网络故障属于典型的由于用户误操作而引发的“软故障”。由于故障源头在较短时间内找到，没有严重影响业务，在提交了故障说明后，领导并没有追责。但是从这次故障可以看出，一个合格的网络管理人员必须能在较短时间内以清晰的思路去追溯故障源头，特别是能够充分利用网络后台相关数据进行深度关联分析，进而解决问题。

随着虚拟化、云计算、无线网络等先进技术在企业内的推广使用，传统网络架构已经发生了深度变革，这种变化将会引发更多“不可思议”的网络问题，网络管理人员必须要有充足的准备去迎接挑战。