在Linux的DHCP服务器中，我得到了一堆这些日志行：
dhcpd: DHCPDISCOVER from 00:30:48:fe:5c:9c via eth1: network 192.168.2.0/24: no free leases 我没有00：30：48：fe：5c：9c的机器，我不打算给00：30：48：fe：5c：9c发一个IP（不pipe怎么样）。
我跟踪了这个服务器，并杀死了所有正在运行的DHCP客户端，但DHCPDISCOVER请求并没有停止。
我可以通过拉动以太网电缆来certificate这是发送服务器 – 请求停止。
奇怪的是，发送服务器只有2个接口，它们是：
什么可能是一个地址的原因？ 谁可以发送请求？
我的DHCP客户端是Debian 6.0中的默认设置（Squeeze） http://packages.debian.org/squeeze/isc-dhcp-client
在DHCP客户端主机上：
root@n34:~# ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 100 link/ether 00:30:48:fe:5c:9a brd ff:ff:ff:ff:ff:ff 3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 00:30:48:fe:5c:9b brd ff:ff:ff:ff:ff:ff 4: ib0: <BROADCAST,MULTICAST> mtu 2044 qdisc noop state DOWN qlen 256 link/infiniband 80:00:00:48:fe:80:00:00:00:00:00:00:00:02:c9:03:00:08:81:9f brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff 5: ib1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast state UP qlen 256 link/infiniband 80:00:00:49:fe:80:00:00:00:00:00:00:00:02:c9:03:00:08:81:a0 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
在DHCP客户端主机上（与上面相同的信息）：
root@n34:~# ifconfig -a eth0 Link encap:Ethernet HWaddr 00:30:48:fe:5c:9a inet addr:192.168.2.234 Bcast:192.168.2.255 Mask:255.255.255.0 inet6 addr: fe80::230:48ff:fefe:5c9a/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:72544 errors:0 dropped:0 overruns:0 frame:0 TX packets:152773 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:4908592 (4.6 MiB) TX bytes:89815782 (85.6 MiB) Memory:dfd60000-dfd80000 eth1 Link encap:Ethernet HWaddr 00:30:48:fe:5c:9b UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Memory:dfde0000-dfe00000 ib0 Link encap:UNSPEC HWaddr 80-00-00-48-FE-80-00-00-00-00-00-00-00-00-00-00 BROADCAST MULTICAST MTU:2044 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:256 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) ib1 Link encap:UNSPEC HWaddr 80-00-00-49-FE-80-00-00-00-00-00-00-00-00-00-00 inet addr:192.168.3.234 Bcast:192.168.3.255 Mask:255.255.255.0 inet6 addr: fe80::202:c903:8:81a0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:2044 Metric:1 RX packets:1330 errors:0 dropped:0 overruns:0 frame:0 TX packets:255 errors:0 dropped:5 overruns:0 carrier:0 collisions:0 txqueuelen:256 RX bytes:716415 (699.6 KiB) TX bytes:17584 (17.1 KiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:560 (560.0 B) TX bytes:560 (560.0 B)
使用kexec而不是重新启动的Perseus对节点进行映像。
首先想到的是一个Supermicro IPMI接口（MAC地址制造商显示为Supermicro）。 默认情况下，IPMI卡尝试提取DHCP地址。 在较新的板上，IPMI接口是内置的，通常共享一个以太网端口。 但是有自己的MAC地址。
Supermicro的主板或超级服务器型号是什么？
检查接口的BIOS信息，而不仅仅是操作系统中的简单信息。
服务器网卡包含内置的iSCSI（或FCoE）支持正变得越来越普遍。当他们这样做时，它通过共享的以太网卡，但具有不同的MAC地址。 而不同的MAC地址将被closures。 您可以通过阻止加载存储驱动程序（或以某种方式configuration该存储驱动程序）来停止DHCP请求。 它看起来像某种SCSI或FC驱动程序。 如果是这样的话，额外的DHCP请求是无害的，但是。
也可能是共享相同端口的pipe理（熄灯）接口。 这可能也会出现在BIOS的某个地方。
错误信息本身告诉你所有你需要知道的。 具体说明： no free leases 。 这意味着DHCP服务器没有更多的空闲地址分发。 因为要求地址的机器没有得到一个，但是从DHCP服务器得到了有效的响应，所以要继续询问一个。 换句话说，你正在看问题的错误结局。
您可以尝试使用lshw -short命令获取硬件的详细信息。 它可能会指出你在正确的方向。 然而，正如John所说，这可能是某种pipe理港口。 你可能可以过滤你的交换机上的mac。
就像是：
mac-address-table static 00:30:48:fe:5c:9c vlan <vlan> drop
这可能是IPMI卡。 您可以使用此命令禁用DHCP请求：
sudo ipmitool lan set 1 ipsrc static
（您可能需要根据您的lan通道在该命令中更改'1'。）