Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a remote client machine that is sending out DHCPDISCOVER's. The server is responding with a DHCPOFFER, but there is no DHCPACK.

This repeats about every 30 seconds from the same host. Is there something I can do remotely or do I need to get someone to reboot it? It's in a data centre so I may have to travel there to do it!


Thanks for the suggestions. I've had all the machines rebooted, but I still have issues. I think there is an issue with my configuration. Does this look correct?

#
# /etc/dhcpd.conf for primary DHCP server
#

authoritative;
ddns-update-style none;
deny duplicates;
default-lease-time 600;
max-lease-time 3600;

# Our fixed hosts
host host2  { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.202; }
host host3  { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.203; }
host host4  { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.204; }
host host5  { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.205; }

subnet x.x.x.128 netmask 255.255.255.128 {
  option subnet-mask 255.255.255.128;
  option broadcast-address x.x.x.255;
  option routers x.x.x.129;
  option domain-name-servers 8.8.8.8, 8.8.4.4;

  # Testing pool.
  pool {
    max-lease-time 300; # 5 minutes
    range x.x.x.250 x.x.x.254;
    deny known-clients;
  }

  # Our hosts - I didn't have this pool declaration before, do I need it if I want
  # the hosts to be running dhcp but always get the same address?
  pool {
    max-lease-time 1800;
    range x.x.x.200 x.x.x.220;
    deny unknown-clients;
  }
}
share|improve this question
    
DHCPRequest should come before the DHCPAck. Are you seeing that? Try running a packet capture on the server and look for the DHCPDiscover, DHCPOffer, DHCPRequest and DHCPAck to and from the server. Is the client on the same LAN segment as the server? If not, is the router separating the two configured as a DHCP relay? – joeqwerty Jan 26 '13 at 18:27
    
It turned out the problem was due to a misconfiguration. I had a static range overlapping a dynamic range. – Matt May 13 '15 at 20:16

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.

share|improve 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.

share|improve this answer
    
Many thanks. I was seeing discover, offer, request, request, request and no ack and this was the cause. There was nothing in /var/log/syslog either, for the same reason. It's about time I learned to check this first when I see strange behaviour that starts suddenly. – Rob Fisher Apr 3 '15 at 0:00

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.

share|improve this answer
    
Thanks. I pinged the address offered but no response. I then set up a host entry for it forcing it to offer a different address but this didn't seem to help. Will check the firewall. – Matt Jan 26 '13 at 19:21

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: enter image description here 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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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