来自差一个 MAC 地址的 DHCPDISCOVER 请求

来自差一个 MAC 地址的 DHCPDISCOVER 请求

在 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 的机器,并且我也不打算将 IP 提供给 00:30:48:fe:5c:9c(无论它是什么)。

我追踪了发生此问题的服务器并终止了所有正在运行的 DHCP 客户端,但 DHCPDISCOVER 请求并没有停止。

我可以通过拉以太网电缆来证明这是发送服务器 - 请求停止。

奇怪的是,发送服务器只有2个接口,分别是:

  • 00:30:48:fe:5c:9a
  • 00:30:48:fe:5c:9b

导致地址偏移的原因是什么?谁可能发送了请求?

细节

我的 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 而不是重新启动。

答案1

首先想到的是 Supermicro IPMI 接口(制造商显示的 MAC 地址为 Supermicro)。默认情况下,IPMI 卡会尝试提取 DHCP 地址。在较新的主板上,IPMI 接口是内置的,通常共享以太网端口。但有自己的 MAC 地址。

这是什么 Supermicro 主板或超级服务器型号?

答案2

检查接口的 BIOS 信息,而不仅仅是从操作系统中容易获取的信息。

服务器网卡内置 iSCSI(或 FCoE)支持正变得越来越普遍。当它们这样做时,是通过共享以太网卡,但使用不同的 MAC 地址。并且不同的 MAC 地址会相差一。您可以通过阻止加载存储驱动程序(或以某种方式配置该存储驱动程序)来停止 DHCP 请求。它看起来像某种 SCSI 或 FC 驱动程序。但是,如果是这样的话,额外的 DHCP 请求是无害的。

也可能是共享同一端口的管理(熄灯)接口。这可能也会显示在 BIOS 的某个地方。

答案3

错误消息本身会告诉您所有需要了解的信息。具体来说:no free leases。这意味着 DHCP 服务器没有更多可用地址可供分发。因为请求地址的机器没有得到地址,但是做过DHCP 服务器会不断请求有效响应。换句话说,您看错了问题所在。

答案4

您可以尝试使用该lshw -short命令获取有关硬件的详细信息。它可能会为您指明正确的方向。但是,正如约翰所说,它很可能是某种管理端口。您可能可以在交换机上过滤 mac。

就像是:

mac-address-table static 00:30:48:fe:5c:9c vlan <vlan> drop

相关内容