出错的DHCP服务器
转自《网管员世界》 上海博科资讯股份有限公司 陈运栋
一大早赶到公司，像往常一样打开我的网管电脑，咦，怎么登录的时间要那么久，正常的情况
只要30秒就可以进入桌面。我拔掉网线，一下子就登录进去了，但是我心里估计，一定没有登录到
域，而只是登录到本地。果然，我PING了一下域控服务器，没反应，一查IP地址，是
192.168.136.113，我们公司是采用DHCP分配IP地址的，网段应该是172.16.10.x才对，怎么会分配
到192.168.136.x网段了呢，肯定是有另外的一台DHCP服务器。此时同事们已纷纷打来电话说网络
不正常，无法上网，当时我想得很简单，找出那台DHCP服务器，关掉被误配置的服务，再通知大家
重新启动就能全部搞定，可是没想到的是更复杂的情况在等着我呢。
我使用IPCONFIG/ALL命令获取该DHCP服务器的IP地址为192.168.136.254，我再使用ping -a
192.168.136.254命令想获取该计算机的名字，因为在我们公司计算机名就是使用者的名字缩写，只要知道了
计算机的名字也就知道了该台计算机在哪里，可是令我失望的事情发生了，非但无法获取该台计算机的名称，
192.168.136.254根本连ping都ping不通。可是它的确是分配给我ip地址的一台计算机啊！
我开始疑惑了，为进一步了解获取ip地址的过程，我打开了网络抓包工具Sniffer pro4.5,在
开始抓包之前，我先拔掉了网线，因为一旦插上网线，第一步就是获取ip地址，而我只需要看最前
面的几个包就可以，这样可以减少需要查看的包的数量。结果发现192.168.136.254那台计算机用
的网卡居然是VMWare,造成现在网络瘫痪的罪魁祸首是一台安装有VMWare的计算机。可是现在如何
找到它呢？我们公司的网络拓扑是将近二十个交换机层层级联在一起，相当于一个广播域，当时摆
在我面前有两个办法：一是逐台检查24小时开机的服务器，因为我今天一大早就到公司了，不可能
是某人的工作用计算机；二是用二分法，逐交换机再逐端口地找出那台有问题的DHCP服务器。
由于考虑到第一种方法收效太慢，因此还是采用二分法，先关掉一半交换机，拿一台笔记本电脑
插在剩余的交换机上，运行ipconfig/renew命令，如果能renew且为错误的ip地址，则证明那台
DHCP服务器在这一半的交换机里，如此重复几次，则可以定位到一台交换机上，再逐端口找到那台
问题计算机，一共花了大约半个小时的时间，明确那个网口是E24，PowerEdge 600服务器，直接打
开VMWare WorkStation,查看“Virtual Network Setting",如图1。
一眼就可以发现该虚拟机在Vmnet0(Bridge)上打开了DHCP服务，再查看”DHCP",如图2.
可以看到，VMnet0上DHCP分发的IP地址正是192.168.136.x网段。把Vmnet0上的DHCP服务器删除
之后再通知大家重新启动，网络恢复正常。
这次从发现网络故障到网络恢复正常一共花了近一个小时时间，恢复时间较长主要因为时间都\
浪费在找到那台计算机上，通过这次故障我得出以下结论：
VMWare在使用中，尽量不要对Vmnet0做什么操作，如开DHCP等，该软件在实施这样的操作之前
会提示使用者这样会影响到真实的网络，但是对于初学者来说很难理解。
另外，DHCP服务有缺陷。本来我以为只有“Authorize"过的DHCP服务器才有权向局域网内计算机
分发IP地址，其实并非如此。由于计算机在获取IP地址之前根本无法与域控服务器通信，更无法受
到域安全策略的管理，DHCP的原理就是需要IP地址的计算机发一个广播包（DHCP REQUEST）,哪台
DHCP服务器先收到，回复一个DHCP ACK包，其中包含了分配的IP地址，这也就解释了此次故障发生
时部分同事的计算机获取的是正确的IP地址，因为他们机器的广播被获得授权的DHCP服务器先接
收，而部分同事因为获取了错误配置的DHCP服务器的响应从而获取了错误的IP地址。
