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