DHCPDISCOVER requests from an off-by-one MAC address

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.

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?

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.

DHCPDISCOVER requests from an off-by-one MAC address

Details

Related

Recent Posts