Roy Vestal wrote:
I have a over 150 machines at the moment that will in some way have to
be booted diskless. Currently, we are using boot CD's but I want to
move away from the CD's so that the management of the environments is
centralized and the OS projects are consistant. However, not all of
these machines are going to be online at one time so I would like to
use a set of 100 IPs and have them randomly assigned when a machine is
brought online. Make sense?
This is a development lab and these machines are used mostly for
development and/or testing and are not online for long periods of time
(i.e days/weeks, not necessarily months). We now have 3 different
OS/env scenarios that we use where PXE would let us minimize
maintenance and more closely control the versions of the enviroments
used. However we "share" the network in question (with me being the
DHCP/DNS server admin <evil grin!> ) so we need to be able to secure
it from other groups outside our lab. And we are constantly adding new
machines and removing old machines from dev/testing pool so I want to
be able to manage these simply. Just adding/removing the mac's will be
painful enough.
In a nutshell, I need to overcommit my range by almost 100% to an
everchanging pool of machines/mac's.
If I may be so bold, I would suggest that what you're doing is going
about it the wrong way. "Securing" your IP addresses by limiting what
your DHCP server hands out is only marginally useful for a myriad of
reasons. First off, if you have users plugging in computers and
attempting to use this network segment, then they're going to try to get
an IP address. This means that either your DHCP server will assign them
one, another DHCP server will assign them one, or they'll have to make
one up on their own. If you give them an address, at least you can be
reasonably assured that it won't conflict with another machine. You
might run *out* of addresses, but that's a whole different problem. Not
giving out an address won't prevent you from running out, it just causes
the user to try to make one up, which is the same as the last option.
In that case, the user (especially as the range gets full) is likely to
choose an address that is in use, or will be in a few moments when that
test machine in the corner with the lease for it finishes rebooting.
Bad karma.
In the scenario above I haven't touched on yet, where you're sharing a
broadcast domain or have a dhcp relay to another dhcp server from your
network segment, then you're in a simple race condition. Your DHCP
clients that you *want* to have addresses, *might* get an address from
your server, or they *might* get an address from the other DHCP server.
I don't think I need to explain why that's bad. Trusting to the latency
of the closer DHCP server is also a very bad mistake. You should
basically never have two DHCP servers with an overlapping scope that
aren't a fail over pair.
So, tackle this problem by segmenting your broadcast domain. Ie. put
your test machines on another subnet, which either no one wants to be
on, or is allowed to be on, or physically can get on. This solves the
problem of wayward users connecting to the network. As for *how* to
segment yourself, consider turning off unused ports on managed switches,
using 802.1x authentication, simply changing your network addressing
scheme and installing a NAT router at the border back to the regular
network with the rest of the users - what ever you need to do to change
the network topology.
So you may say you can't do that for a myriad of reasons. Those reasons
are the real problem here. Find solutions to those problems, and you'll
be moving in the right direction to a better life through better
networking. Or maybe I'm just really naive and you have a complex and
unique problem. In that case, feel free to ignore the above ramblings.
Aaron S. Joyner
--
TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
TriLUG Organizational FAQ : http://trilug.org/faq/
TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
