DHCPDISCOVER/DHCPOFFER, but no DHCPACK

It goes:

CLIENT -> DHCPDISCOVER
SERVER -> DHCPOFFER
CLIENT -> DHCPREQUEST
SERVER -> DHCPACK

You you are missing the DHCPREQUEST before the DHCPACK in your description.

If the client is on a different subnet than the DHCP server the DHCPOFFER is sent unicast to the DHCP-relay on port 67 UDP. The DHCP-relay agent broadcasts the DHCPOFFER to the subnet on UDP port 68.

I'd investigate connectivity issues related to the DHCPOFFER. Track it and see if it finds its way back to the client and if it does, why is the client not DHCPREQUEST:ing the address.

A common dhcp relay agent is the "ip helper-address" option in cisco switches under a specific interface.

Supposing your DHCP-server and DHCP-client are both connected to the same ethernet segment, and supposing such ethernet segment spans several L2-switches interconnected with various "trunk" (802.1q) links, I've run into similar issues when there was a mismatch between the configuration of at least one trunk link.

In detail, the never-ending cycle of DHCP-DISCOVER / DHCP-OFFER (as seen from the DHCP-server side), let me think that the DHCP-client is NOT receiving the DHCP-OFFER and, hence, stick reissuing the DHCP-DISCOVER message. Such DHCP-DISCOVER (as seen from the DHCP-client side) is correctly received from the DHCP-SERVER.

Considering the following scenario: the wrong/mismatched setup of the two trunk ports means that:

• VLAN X traffic sent by SW A to SW B along the trunk (or from the DHCP-Server to the DHCP-client), is UNTAGGED;
• VLAN X traffic sent by SW B to SW A along the trunk (or from the DHCP-Client to the DHCP-server), is TAGGED.
• due to the native VLAN setup of the trunk port of SW B, the DHCP-Client will not receive packets from DHCP-Server.

This is very easy to troubleshoot, if you "control" the DHCP-Client host. In such a case, supposing eth0 is the network interface used by the DHCP-client host, a simple:

tcpdump -n -i eth0 ether-host <dhcp-server-mac-address>

will show if the client receive the DHCP-OFFER from the DHCP-SERVER, or not.

Things are more difficult to troubleshoot if you can not control the client-side.

P.S.: Obviously problems above, as well as other related arguments, can be easily avoided used proper technologies (like GVRP, VTP or other not-strictly-manual-config-approach) but... this is out of the scope of this answer

Had the same issue. Not seeing any DHCPACKs. Problem here was:

disk full

dhcpd could not write to /var/lib/dhcp/dhcpd.leases.

I've seen this a few times and so far I've seen only two reasons:

• The IP address the DHCP server gave is already in use by another device. Usually you'd see a DHCPNAK though.
• Your firewall is accepting the traffic to the dhcp server, but not the traffic back

Fortunately both should be easy to test. Ping the IP address and check relevant firewalls.