Frequent DHCP Request Broadcasts

scan your systems for viruses/ spyware

http://secunia.com/virus_information/13554/yanz.a/

I am running Trend Micro Antivirus and it is up to date.  All users do not have admin rights on their workstations and I see no evidence of viruses on the computers.

Something's not right. You are correct that an 8 day lease should not try to renew for 4 days.

Shooting in the dark...

Have you verified the MAC address for the offending workstation?
If you assign it a static address, does it still broadcast?
Do you show any other entries with 'ipconfig /all'?
Have you tried disabling APIPA?  http://www.windowsitpro.com/Article/ArticleID/15007/15007.html
Any wireless networking?

routinet,  Thanks for the suggestions.

Have you verified the MAC address for the offending workstation?  
Yes.

If you assign it a static address, does it still broadcast?
Will try on one of them.

Do you show any other entries with 'ipconfig /all'?
No.

Have you tried disabling APIPA?  http://www.windowsitpro.com/Article/ArticleID/15007/15007.html
No, because It has a specified address to assign from and I don't think it would broadcast.  Also, wouldn't it only work if no other address were available?

Any wireless networking?
Not on internal workstations.

>>> Will try on one of them.

Is more than one workstation exhibiting this behavior?  Can you find any differences between workstations that do and workstations that don't?

APIPA is SUPPOSED to take over when no other DHCP server is found, but I've seen stranger things.  Like I said, shooting in the dark.  :)

Yes, there are several workstations.  One difference I see is the 1394 adapter.  What is it's function?

1394 is Firewire.  It is the direct competitor to USB, and originated on Macs.  It is not a network device, though, and should not have any impact on DHCP.

Well, I guess its time to get out the shotgun and shoot in the dark.  I can't find anything that would cause this.  Just in the past 4 hours of monitoring, 29 workstations from different locations inside the building have sent out 2 DHCP requests each with no reply from either DHCP server.  I am concentrating on 5 workstations now.  I mostly see 6 requests from each except for one that has 4 requests and 1 that has sent 27.
Could faulty or noisy network cables possibly cause this?

My only other idea is to use some kind of packet monitoring (like Ethereal) to watch the traffic.  Eventually, you may find some sort of pattern that leads you to the cause of the behavior.  

I would not think that faulty cables would do this.  At least, not without responses from the server.  If a faulty cable caused a disconnect, then the client would send out a new discover request in an effort to reacquire its lease.  Even if the fault was momentary, triggering the discover request should also trigger the rest of the DORA sequence between the client and server.

Do you have any of your workstations set to automatically search for network shares?
Have you traced the DHCP's server handling of these broadcast requests?
Have you inspected the individual broadcasts to verify they are, in fact, DHCP requests?

I originally found this issue with Ethereal.  I finally got a good capture of one of the computers that has this problem.  The computer with a static address sends out a broadcast, it's MAC address is confirmed, to the broadcast MAC address of ff:ff:ff:ff:ff:ff.  There are 290 bytes in the frame, protocols in the frame eth:ip:udp:bootp.  At the bottom of the packet that I printed from Ethereal, it mentions Option 53:  DHCP Message Type = DHCP Inform and Option 43:  Vendor-Specific Information (2 bytes).  The DHCP server responds with an ACK, then the originating computer responds with an ACK.  The first packet's source port is 68.  The second and third are 67.

That explains it.  I will see what I can do to tweak the driver or set the option.  Thanks!