In a Linux DHCP server I'm getting a bunch of these log lines:
dhcpd: DHCPDISCOVER from 00:30:48:fe:5c:9c via eth1: network 192.168.2.0/24: no free leases
I don't have any machines with 00:30:48:fe:5c:9c and I don't intend to give out an IP to 00:30:48:fe:5c:9c (whatever that could be).
I tracked down the server that this is coming from and killed all the DHCP clients that were running but the DHCPDISCOVER requests do not stop.
I can prove that this is the sending server by pulling the Ethernet cable - the requests stop.
The strange thing is that the sending server only has 2 interfaces which are:
- 00:30:48:fe:5c:9a
- 00:30:48:fe:5c:9b
What can be the cause of the off-by-one address? Who could be sending the requests?
Details
My DHCP client is the default in Debian 6.0 (Squeeze) http://packages.debian.org/squeeze/isc-dhcp-client
On the DHCP client host:
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
On the DHCP client host (same info as above):
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)
The nodes were imaged with Perseus which uses kexec instead of rebooting.
Check the BIOS information for the interfaces, not just what's easy to get to from in the OS.
It's becoming common for server network cards to include iSCSI (or FCoE) support built in. When they do that, it's via a shared Ethernet card, but with a different MAC address. And the different MAC address will be off by one. You might be able to stop the DHCP requests by blocking loading a storage driver (or somehow configuring that storage driver). It would look like some kind of SCSI or FC driver. If that's what it is, the extra DHCP requests are harmless, however.
It's also possible that it's a management (lights out) interface sharing the same port. That would probably also show up somewhere in the BIOS.
The first thing that comes to mind is a Supermicro IPMI interface (MAC addresses manufacturer shows as Supermicro). By default, the IPMI cards try to pull a DHCP address. On newer boards the IPMI interfaces are built in and usually share an ethernet port. But have their own MAC address.
What Supermicro board or superserver model is it?
The error message itself tells you all you need to know. Specificaly:
no free leases. That means the DHCP server has no more free addresses to hand out. Because the machine asking for an address didn't get one, but did get a valid response from a DHCP server, it's going to keep on asking for one. In other words, you're looking at the wrong end of the problem.It's probably the IPMI card. You can disable the DHCP requests with this command:
(You might need to change the '1' in that command depending on your lan channel.)
You could try using the
lshw -shortcommand to get detailed info on your hardware. It may point you in the right direction. However, as John said it is likely a management port of some kind. You could probably filter the mac on your switch.Something like: