[c-nsp] DHCP behavior on a link up

[Phil Mayers]

On Thu, Jul 09, 2009 at 06:05:09PM +0100, nick hatch wrote:
>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

It's also worth noting that, driver-dependent, a brief link loss may not 
be "seen" by the IP stack and trigger a renew.

This is of interest if, like us, you trigger a port restart when kicking 
a machine off, to re-assign their VLAN.

>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.

Hmm. Interesting. I've not seen that, and we've got a lot of XP clients.  
In my experience, XP is possibly the "best" behaved DHCP client of the 
lot.

Don't get me started on the "great leap forward" that is Vista...  
broadcast DHCP? Yuck...

>
>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.

Note that many embedded devices (in my experience) do a sort of 
DHCP-lite or BOOTP-plus; they emit DHCP DISCO/REQUEST packets and handle 
DHCP options, but don't implement the "renew" bit of the protocol. HP 
3600 and 20xx printers are particular offenders.

>
>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.

That's... lovely. Sounds like a marvellous company!

We have this with some older kit. If and when we go to DHCP snooping, 
I'm going to handle this with a script that checks the MAC on 
snooping-disabled ports. If it's a known-incapable, fine, else re-enable 
snooping, which should hopefully stop people unplugging the 
photocopiers...

On the plus side, at least on Cisco you can upload an ARP ACL to include 
the exceptions. Some other vendors offer no such method, and exceptions 
have to be tied to the port. Sigh...