problem with dhcp setup
dhcp1 at thehobsons.co.uk
Tue Jun 19 14:13:39 UTC 2007
John Jason Brzozowski (CISSP, RHCT) wrote:
>I do agree with you, however, I am sure you would agree that DHCP servers
>have been accounting for client shortcomings for quite some time.
To a point yes, that is true - but how far REALLY should you go ? As
Glenn says, there is limited room in a packet for options,
particularly longer text options. Bear in mind that there's probably
some clients out there that will break if you send them options they
don't expect, not that I can recall hearing of any. Also, the UDP
packets aren't fragmentable, so if there's a network element with a
small MTU then that would break DHCP with large offer packets.
Don't forget that as an administrator you can deal with broken
clients by overriding the options list - in a host statement, in a
class, or for a whole pool or subnet. Unfortunately this is an
override, so the configured list replaces the client supplied list -
I think a useful enhancement would be to make it additive so the
options list became the set containing both teh admin and client
>As much as I hate to admit it this I suspect this will continue as
>we the adoption of IPv6 advances. You seem to be alluding to this
>below, in fact, you cite some great examples.
It will continue as long as people are able to get away with it.
Unfortunately DHCP is one of those 'boring' technologies that no-one
(well few outside the well versed network professionals) really cares
about - so to most people it's good enough if it works and they
really don't care about RFC compliance and stuff like that (or no-one
would use the MS server !). As long as users don't care, then vendors
aren't going to get worked up about it either because they know they
aren't generally going to get a lot of hassle about a poor DHCP
client. They know they'll get more complaints, and worse reviews in
the mags, if the plastic box isn't 'pretty' than they will from a
c**p DHCP client !
More information about the dhcp-users