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 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?


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:  Bcast:  Mask:
          inet6 addr: fe80::230:48ff:fefe:5c9a/64 Scope:Link
          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)

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)

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:  Bcast:  Mask:
          inet6 addr: fe80::202:c903:8:81a0/64 Scope:Link
          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:  Mask:
          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.

  • Please post the output of ifconfig -a. What DHCP client are you using? – Insyte Mar 3 '11 at 4:45
  • 2
    @Insyte - ip link show is preferable to ifconfig -a since ifconfig is deprecated. – sciurus Mar 3 '11 at 5:34

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?

  • It's Supermicro H8QGi-F. – Aleksandr Levchuk Apr 1 '11 at 4:56
  • You were first to mention IPMI and you were right about sharing the eth port. It's surprising because there is a separate IPMI port but it's conveniently shared with the real eth too. Looking up the model number also validates it. I checked with @toppledwagon suggested command. This thing is potentially a security issue. – Aleksandr Levchuk Apr 1 '11 at 5:20
  • 1
    If you want it to use the dedicated port instead of the shared port plug in a cable (so it has link) and issue: 'ipmitool mc reset cold'. When you turn the machine on it determines whether to use the dedicated port or the shared port. That command will restart that process. – toppledwagon Apr 1 '11 at 5:58

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.

  • This is probably it. I'll check the BIOS. – Aleksandr Levchuk Mar 31 '11 at 15:07

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 a misunderstanding - I fixed my question – Aleksandr Levchuk Mar 3 '11 at 4:52
  • 6
    @Aleksandr, a network interface may have more than one MAC address. This is often the case when the same NIC is also used for system management (for the server hardware itself). The fact that the address is off by one suggests this may well be the case. As for the error, what I said still applies. – John Gardeniers Mar 3 '11 at 4:56

It's probably the IPMI card. You can disable the DHCP requests with this command:

sudo ipmitool lan set 1 ipsrc static

(You might need to change the '1' in that command depending on your lan channel.)

  • +1 Thank you for the command. I had to install ipmitool and openimpi and load modules: ipmi_si and ipmi_devintf – Aleksandr Levchuk Apr 1 '11 at 5:33
  • +1 Awesome! This command really helped stop my various SuperMicro mobos from flooding the DHCP servers logs with requests. – LaXDragon Apr 12 at 1:57

You could try using the lshw -short command 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:

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.