[c-nsp] DHCP behavior on a link up

[nick hatch]

On Thu, Jul 9, 2009 at 7:46 AM, Michael Balasko <
Michael.Balasko at 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