03-07-2014 10:45 PM - edited 03-07-2019 06:36 PM
Hi
Why would a client send a new DHCP discover after receiving a DHCP ack from the DHCP server?
Solved! Go to Solution.
03-08-2014 11:34 AM
Hi,
Why would a client send a new DHCP discover after receiving a DHCP ack from the DHCP server?
It would do it if it discovers an IP address conflict. You see, the client is not allowed to use an IP address util it receives a DHCPACK message from the server. If, after receiving it, the clients detects (usually via ARP) that the IP address is already used, it will send a DHCPDECLINE message to the server, informing it about the conflict, and will start the entire DHCP process from scratch.
I have also seen a client caught in an endless loop of DISCOVER/OFFER/REQUEST/ACK messages that were being exchanged very rapidly. I discovered later that the server was misconfigured and was providing two addresses of default gateway, one of them being 255.255.255.0 (obviously the administrator mindlessly put in the IP address of the default gateway and its netmask into configuration, but the DHCP server offered the netmask as just another gateway address). This caused the client to immediately fail when applying the configuration, and restart the DHCP process, only arriving at the same issue over and over again.
Best regards,
Peter
03-08-2014 11:34 AM
Hi,
Why would a client send a new DHCP discover after receiving a DHCP ack from the DHCP server?
It would do it if it discovers an IP address conflict. You see, the client is not allowed to use an IP address util it receives a DHCPACK message from the server. If, after receiving it, the clients detects (usually via ARP) that the IP address is already used, it will send a DHCPDECLINE message to the server, informing it about the conflict, and will start the entire DHCP process from scratch.
I have also seen a client caught in an endless loop of DISCOVER/OFFER/REQUEST/ACK messages that were being exchanged very rapidly. I discovered later that the server was misconfigured and was providing two addresses of default gateway, one of them being 255.255.255.0 (obviously the administrator mindlessly put in the IP address of the default gateway and its netmask into configuration, but the DHCP server offered the netmask as just another gateway address). This caused the client to immediately fail when applying the configuration, and restart the DHCP process, only arriving at the same issue over and over again.
Best regards,
Peter
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide