I've noticed this several times: a switch starts to behave oddly. Usually if the switch doesn't fail outright, what tends to get noticed is that DHCP doesn't work.
We had a Linksys SRW-224P fail today. Systems which were still connected worked properly, until it came time to renew their DHCP lease. Once the lease expired, they stopped working, but up until then we couldn't detect a failure. This includes PoE VoIP phones -- they work fine until their lease is up, at which point they're done.
I've noticed this on the above-mentioned Linksys, three varieties of 3Com, and possibly half a dozen dumb switches.
What is it about DHCP that makes it sensitive to failing switches?
Perhaps you are looking at this from the wrong direction instead of asking why does DHCP not work maybe you should be asking why does TCP-based communication working on a unreliable network where there is packet loss or corruption.
TCP based communication is meant to be reliable and the protocol is designed to retry communication other protocols like UDP are not reliable. DHCP just happens to be using UDP. On a typical network most of what you see these days is TCP-based. Its resilience properties may be what is be allowing you to continue to have communication over failing hardware.
I would say that DHCP is a little more complex than say http requests, but I would debate myself trying to claim that a way to find out if your switch is breaking is to check if DHCP requests are successful through it. I'm pretty sure if you looked at your actual VOIP traffic, you'd notice packet loss. VOIP (UDP) packet loss might be noticeable in a call depending on the % being dropped. If a few get dropped it's no big deal, but with DHCP requests, these packets are actually important and since they don't get retransmitted it would break the request.
Might come in handy to understand all of the things DHCP does for you (via Cisco).
The ability to forward the bootp/dhcp helper request?
EDIT: Ok, since they are not layer 3 switches (probably should read this a bit more closely), they probably aren't involved in dhcp forwarding.
I've seen this behavior on two Netgear Smart Switches. In both cases the switches were ignoring all broadcast traffic. So the DHCP requests and replies were not being passed along.
DHCP is not just broadcast based. It it "Request" based. There is a connection to the network, then a request for an address on that network, then a reply sent from the DHCP server that either holds an address lease or reports a failure. The request is repeated on the client internally, sending out the request every few seconds and waiting for a response.
However if that response is not recieved, if it is dropped, or if it simply isn't passed through the switching devices properly, you won't be able to get an address. Check to make sure that your subnets are properly configured. I've noticed that many like to use the x.0.x bits to hold only the static managed devices (switches and printers) while keeping computers and servers on the x.1.x or otherwise (this is just an example). If you don't include the x.0.x in your subnet masking properly, you can end up with bitmasks that drop your dhcp requests, or misroute them.
Remember to include this x.0.x as the primary starting address, and then move on to set the subnetting as wide as you need with a masking that matches your dhcp in full; note that sume will set the subnetting with respect to the actual dhcp server, this is not useful, it creates packet leaks. If you set your dhcp to not hand out the static portion, you still need to set it inside your subnet.
If you subnet your dhcp, you should reconfigure the masks, adding 1 to the bitmask alteration. If you subnet 255.255.252.0 for your mask on your dhcp, you need to subnet 255.255.251.0 on your switches, to allow the requests for x.0.x address masks (static routes entered at the client) to carry the dhcp signal the same as the rest of the network. Make sure your subnet masking allows the subnets that need to interact to see each other, even if only to pass the dhcp requests through.
You can separate network services on windows machines (and now macs) by setting workgroup or domain restrictions. Access to services should be handled by login, not by vlan. Login can control the address you receive if you know how to write the script into your servers, but that should only be done when absolutely necessary. VLAN should only function to help a network tech track, trace and fix a problem by following the address masking scheme to a physical location.
Remember, you can bridge vlans of completely different masks, but this only allows them to see each other from a networking standpoint, not an access level. If they need access to services, the vlans should all be bridged to a major interface and that interface should carry the full mask containing all vlans, while the vlan interfaces carry only primary mask 255.255.255.0 (or whatever vlan subnet you put accross it).
The only thing I can think of is that the switch might not be able to update its ARP cache correctly to reflect the newly-assigned IP.