Hi Everyone,
Thanks in advance.
We have a subnet of laptops with predominently Windows 7 on a Windows 2008 R2 domain that make standard DHCP initial requests (Discover-->Offer-->Request-->Ack) and renewal of leases at 50% or less of lease time (Request of same IP-->Ack). In both instances the client IP address in the DHCPDiscover or DHCPRequest packet is 0.0.0.0. These exchanges work normally and are not a problem.
The same laptops moments later (on a 3 day lease) will make a broadcast of a DHCPDiscover with the client IP address of 10.2.3.XX. We have not been able to find a root cause for this behavior. When the broadcast is relayed to the DHCP server the the DHCPOffer is returned with a destination of the offered IP address instead of a broadcast to the asking subnet. This causes IP address leases to be issued that are neither accepted or declined by the client. We have to periodically clear the scope of these erroneous leases to allow legimate client DHCP requests to get fulfilled.
Another interesting fact is that all the bad leases on the DHCP server are marked as type DHCP/BOOTP and the good leases are marked as type DHCP, though in the scope advanced options we have clearly selected "DHCP ONLY". All requested leases, good and bad, are relayed. The leases get tagged with a 20 character hex value for the Unique ID that is just an ASCII mask of the IP address value of the lease. There are a few similar posts with no solution.
All of this is confirmed through packet analysis on all subnets. Would someone please help on the following questions?
1. Has anyone seen this before?
2. How can we stop the client from sending these broken DHCPDiscover packets without stopping legitimate packets?
3. If the client cannot be stopped, can we do this through NAP or some other filter without stopping legitimate packets?
Kind Regards,
Mark Simmerman