[BBLISA] A question on DHCP "shoulds".

[Rob Taylor]

My personal preference is to use static IP addresses on 90% of servers.
I like it when my server can boot when the network is down. 
Also, if somehow a rogue dhcp server shows up(which can be mitigated other ways, I know), I know it won't affect the servers.
For highly dynamic server environments, like a computer cluster, I use dhcp, as those node's come and go, and get
re-provisioned relatively often.

There are some provisions in place to help prevent IP's that are already in use from being given out. Most
DHCP servers will ping an IP before handing it out to make sure it's not used, and I believe that most nodes
will perform a gratuitous arp before using an IP address, which should trigger an error if that IP is already in use. 


rgt

----- "John Hanks" <jbh at broadinstitute.org> wrote:

> On Mon, Aug 31, 2009 at 9:15 AM, Edward Ned
> Harvey<bblisa3 at nedharvey.com> wrote:
> >> I know that I can tell a DHCP server that machine with MAC address
> >> [bla] is to always get IP address [foo] this seems straight
> forward
> >> but the question is, if machine with MAC address [bla] treats it's
> IP
> >> address as statically assigned, as in, it's hardwritten into the
> >> configuration/startup scripts, does that "violate" (for lack of a
> >> better term) the rules of DHCP?
> >
> > Absolutely no problem.  I do this all the time, and here are the
> reasons
> > why:
> 
> I'm going to take the opposing viewpoint, if only to make this a more
> lively discussion.
> 
> My opinion is that the only machines in an environment that should be
> set statically are the DHCP and DNS servers and, if these are
> virtualized, the hosts which make up the virtualization
> infrastructure. My view of a network infrastructure places DHCP and
> DNS at the foundation. If I find myself layering complexity later,
> like making many static IP address assignments, then I prefer to step
> back
> and fix the underlying foundational issues in a way that preserves
> the
> centralized control of IP address assignment.
> 
> > If a linux machine is a dhcp client, then the linux machine will
> assign
> > itself whatever hostname the dhcp server says.  It will go modify
> its own
> > "hosts" file, and resolv.conf, and sysconfig/network.  I have a
> specific
> > requirement:  The "hosts" file must contain both the unqualified and
> FQDN of
> > the host.  "10.1.1.50  myserver  myserver.example.com"  But if the
> hsots
> > file is created by DHCP, that gets removed.  IMHO, I would call that
> OS
> > damage.  (A server should be totally static, and resilient, and
> behave well
> > regardless of other servers, within reasonable limits.)  Which means
> - sure,
> > that's no problem for laptops, but servers ... that's a big no-no.
> 
> I'd take the different path of configuring DHCP on the servers to
> build a hosts file which met the requirements. dhclient and dhcpcd
> both have hooks for pre and post scripts and I wouldn't be surprised
> if this particular problem were already addressed in these tools for
> most distributions, although I have no real example to point to as
> the
> default /etc/hosts has been sufficient for me so far (knock on wood,
> Murphy's law will likely kick me in the groin with this later today).
> 
> > So all linux servers get statically assigned IP's.
> >
> > Now - I never want to accidentally assign some other server the same
> IP
> > address.  So obviously the static IP addresses are assigned
> *outside* of the
> > dynamic pool.  But just to be really really sure ... I create  DHCP
> > reservation for each server, which will never be used because the
> server
> > will never request dhcp.
> >
> > By creating the reservation, I ensure it can never be assigned, even
> by
> > accident, to any other system.
> 
> What you have found comfort in is the exact reason I prefer the
> opposite solution. Enforcing this level of documentation upkeep, even
> (especially?) when I have been the only admin in a one-admin shop,
> has
> proven, umm, lets say difficult (I accept that I am irresponsible in
> these matters, thus the tendency toward self-enforcing solutions.) If
> every system gets it's assignment from the DHCP server, I have no
> choice but to maintain properly configured and up-to-date DHCP and
> DNS
> configurations. I envy those of you who have the discipline to
> maintain unenforced documentation systems, but it's just not
> something
> I do well.
> 
> DHCP and DNS are not emerging technologies, they are mature and
> stable, and in my view there's no reason to avoid exploiting the full
> power of them in managing a server environment. Backup DHCP servers
> are simplistic to set up for static ranges; reliable, robust and
> redundant services are easy to maintain. DNS is distributed by design
> and again, easy to make robust and redundant.
> 
> This is one of those 'many ways to skin a cat' areas and I suspect
> there are as many answers as there are sysadmins. My suggestion would
> be to invest some time in learning how DHCP and DNS can not just
> assign addresses and names, but become a foundational part of how you
> track and manage your systems and make your life easier down the
> road.
> The one thing about them that irritates me is the lack of a well done
> open source project to integrate the management of these two
> services.
> 
> jbh
> 
> _______________________________________________
> bblisa mailing list
> bblisa at bblisa.org
> http://www.bblisa.org/mailman/listinfo/bblisa