I will explain some basic things about DHCP before going to the issue.
1) It is explained in RFC 2131.
2) The packets between server and clients are DHCPDISCOVER, DHCPOFFER,DHCPREQUEST and DHCPACK
3) After T1 time ( 50 % of lease time) the client should send unicast DHCPREQUEST to server. If server available, renew lease, if not continue using the lease.
4) If server is not present after T1 time wait for T2 time ( 87.5 % of lease time) and send broadcast DHCPREQUEST.
5) if Server is not available after T2, continue using the IP address till lease time expires. Stop using the IP and start sending broadcast DHCPDISCOVER.
Now the issue :
We had a server in which lease time is set as 15 min.The client gets the ip address and other parameter from server. The t1 time is 7 min, after T1 time the client should send unicast DHCPREQUEST, but it sends broadcast DHCPREQUEST. It appears as an issue because when client moves to renewing state it should send unicast DHCPREQUEST.
As per RFC 2131
At time T1 the client moves to RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease.
These are some of the Observations :
1) Server Windows 2008 DHCP server ( lease time 15 min)
2) Linux PC as client
Linux PC---switch--WINDOWS DHCP Server.
Once the client gets IP remove the server.
Linux showed DHCPREQUEST as broadcast packets.
In Linux the default arp timeout value is 60 sec and is configured using this parameter
After the arp entry for DHCP server will get deleted, the device will send ARP REQUEST for the DHCP server. After T1 time, if it does not get any arp reply, it is sending the BROADCAST DHCPREQUEST message.
If the server is always connected, the ARP will get resolved and it will send the unicast DHCPREQUEST.
So it seems not an issue. If ARP entry is present in the device, the client will send the unicast DHCPREQUEST, if it gets expired before T1 it will send broadcast DHCPREQUEST.
Let me know your comments, observation on this.
Keep learning, Keep sharing !!!