On Thu, Jul 9, 2009 at 7:46 AM, Michael Balasko < michael.bala...@cityofhenderson.com> wrote:
> > Does anyone know of any RFC's that pertain to how a host device should > behave regarding DHCP when the link come up? Newer windows machines and > some flavors of *nix behave like I think they should and that is they > will attempt to renew a DHCP lease on a link up. One thing worth noting for Windows clients (at least for Windows XP), is that the DHCP client will attempt a renew first; however, the old lease is not destroyed upon link change. This shouldn't be a problem, but if the response received is a NAK, the client won't always gracefully fall back and attempt a new discovery attempt. I've seen WinXP clients bang on the DHCP server (ISC) for hours: NAK, REQUEST, NAK REQUEST, NAK, REQUEST ... I saw this problem on a campus network when laptops would connect to us with a stale lease for a home RFC1918 network, possibly with an indefinite time period. Windows isn't always well behaved. Does it seem like the devices are at least honoring their assigned lease times? Perhaps these errant devices could be assigned to a DHCP pool with a very short renewal period. Per the RFC, clients MUST stop using the lease when it expires. I've got a similar problem -- thermal printers in public areas where I'd love to use DHCP snooping/DAI. When purchased, they arrived with nonfunctional DHCP (NOT as advertised), are the only printers that are compatible with this system, and were not cheap. When we complained to the vendor, they told us it was a known problem, to quit whining and static assign, and that if we tried to RMA them, they would be refused. If you're looking to beat Xerox with a clue-bat wrapped in an RFC, perhaps a reminder of what SHOULD means could help: This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. Perhaps Xerox support could help you understand the reasoning they went through when the full implications of deviating from the RFC were carefully weighed... (Ha!) You've obviously got a problem which falls under the "full implications" umbrella. -Nick _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/