0

I am trying to set up a DHCP client that is supposed to get its IP address via DHCP. I have configured two DHCP servers (one in 192.168.X.X pool and the other in 162.16.X.X pool).

Then, the client starts the DHCP protocol and obtains a DHCP lease from one server (say 162 server). Now, before the lease time expires, the client sends a REQUEST message to renew the lease. But, now instead of the 162 server, the 192 server sends a NAK before the 162 sends an ACK.

Upon receiving the NAK from a wrong server, the client removes the IP address and starts sending DISCOVER messages again. Shouldn't the client wait for an ACK from the correct server?

Is this the expected behaviour or is it a bug in the client's dhclient implementation?

Packet Capture showing the issue

FYI. the above packet capture is done on the DHCP Relay's interface

| improve this question | | | | |
1

No. The screen shot you have provided is not a DHCPRequest renewal. Renewals are unicast to the DHCP server IP address. The screenshot shows a broadcast. Any DHCP server may respond to a broadcast DHCPRequest. You haven't provided details about the client so there probably will not be any useful responses as to if this is expected behavior, but that definitely is not a renewal.

https://stackoverflow.com/questions/12565095/how-client-unicasts-a-renew-dhcp-request-if-server-id-must-not-be-filled-in#12565447

Dynamic Host Configuration Protocol
https://www.ietf.org/rfc/rfc2131.txt

| improve this answer | | | | |
  • The client here is an SVI on a switch that is configured to get IP address via DHCP. Even I thought that this was some bug, but wanted to confirm with others – Anand Gokul M May 25 '17 at 7:10

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.