Freigeben über

When is DHCP NAK issued?

  • Artikel

Hi,

Recently I saw a lot of queries regarding when the Microsoft DHCP server issues a NAK to DHCP clients.

For simplification purposes, I am listing down the possible scenarios in which the server should NOT issue a NAK. This should give you a good understanding of DHCP NAK behavior.

When a DHCP server receives a DHCPRequest with a previously assigned address specified, it first checks to see if it came from the local segment by checking the GIADDR field. If it originated from the local segment, the DHCP server compares the requested address to the IP address and subnet mask belonging to the local interface that received the request.

DHCP server will issue a NAK to the client ONLY IF it is sure that the client, “on the local subnet”, is asking for an address that doesn’t exist on that subnet.

The server will send a NAK EXCEPT in the following scenarios:-

1. Requested address from possibly the same subnet but not in the address pool of the server:-

This can be the failover scenario in which 2 DHCP servers are serving the same subnet so that when one goes down, the other should not NAK to clients which got an IP from the first server.

2. Requested address on a different subnet:-

   If the Address is from the same superscope to which the subnet belongs, DHCP server will ACK the REQUEST.

 

Thanks,

Achint Setia,

Software Design Engineer,

Microsoft DHCP team.

Comments

  • Anonymous
    January 01, 2003
    Hai, If there is single DHCP Server, when a client sends DHCP Discover message, DHCP Server sends DHCP Offer message as Broadcas, but when there are multiple DHCP servers configured with DHCP Relay agent, DHCP Offer is Unicast(Source address is DHCP Relay agent's IP Address and Destination address is machine which requested the IP Address). Y is it so?? Whether the DHCP Offer is Broadcast or unicast??

  • Anonymous
    January 01, 2003
    Hi, I have some questions regarding DHCPNACK Basically, we had a dhcp migration recently. We have 1 site that uses ip helper to broadcast the dhcp broadcast request to our data center with DHCP Server A and DHCP Server B. For example, current subnet is 192.168.1.x (lease period is 1 day) And it was migrated to 192.168.2.x subnet (lease period is 8 day) which is hosted on DHCP Server B. Aparently it was running in parallel. Due to some routing issues, we have to fallback to 192.168.1.x. So the 192.168.2.x subnet was deactivated on DHCP Server B. Two to three days later, we have users that are not able to renew their ip address on subnet 192.168.1.x from DHCP Server A. I can see that there's lots of DHCPNACK. After fixing the routing issues, we switch back to the new subnet 192.168.2.x on Server B and clients are able to renew their IP Address. My question is what causes this (DHCP Server A denying ip lease to the client machines)?

  1. could it because there's some sort of binding that doesn't allow the client machines to renew their ip lease with another DHCP server (DHCP Server A)?
  2. Most of the machines are affected but not all.
  3. And which DHCP server will the client broadcast the DHCP request to if there's 2 DHCP server ip address set on the router for the ip helper? Any comments greatly appreciated.

  • Anonymous
    January 01, 2003
    This is the expected behavior DHCP offer across the DHCP relay the source and destination address change to unicast addresses . Please refer to rfc1542 for DHCP relay agent specific information. -Tushar

  • Anonymous
    January 08, 2008
    quote: [3. And which DHCP server will the client broadcast the DHCP request to if there's 2 DHCP server ip address set on the router for the ip helper?] Here the word broadcast implies that both servers will pick up the request. I really know very little about this topic, but it's my understanding that DHCP operates on a separate network layer than conventional network traffic, and since the client doesn't know any address, hence the need for address assigning equipment in routing tables, switches, and the address-giving dhcp server, it's  broadcasting it's request to all devices. All switches, routers, computers, servers, hubs, anything connected to the network which is not on the far side of some wall to this network layer, such as an internet gateway, will hear this request and either choose to respond, or discard the information. If the device hearing the response is configured as a DHCP server, that implies both servers should respond, unless you've programmed them not to somehow. Erego, both servers are on the network, they must both be responding while your clients are deciding for one reason or another to pick an IP which is given and stick to it. Why it's staying stuck during the migration is beyond me.