[Techtalk] serverless IP assignment?

[Raven, corporate courtesan]

Heya --

Quoth Malcolm (Mon, Feb 11, 2002 at 02:08:31PM -0500):
> > Are you *sure* you can't pick 1 to always be the DHCP server, 
> > or assign fixed IPs?  
> 
> How do you propose I pick one? Basically the user location has a
> collection of boxes that they install. Number of machines on the
> network is not predictable, nor is which machines is turned on first.
> Predictable user skill level is around the "can plug in and turn on
> the machine" level (I'm -very- glad I'm not doing tech support here).
> Asking them to designate a server (and then reliably turn that machine
> on first) is not really an option.

	Are the externals of the systems all the same?  And do you
control the IP space, or are you having to customize it to use addresses
out of some block that the customer owns?

	If you can somehow differentiate the externals of the boxes,
paint one case out of every set red.  Ship it in a big red carton.  Then
on the top and inside of every box shipped, put a big sign reading "The
red box MUST BE TURNED ON AND CONNECTED TO THE NETWORK FIRST.  If this
does not happen, nothing else will work!"  The red box, of course, is
your DHCP server.

	If all the systems are supposed to be identical, though, then
this may not be an option for you.  Of the IP space that you're using
addresses from, are there other customer boxes already up in this space,
or is it only conflicts with your own boxes that you have to worry
about?
 
> Basically I have no control over the actual environment. The boxes are 
> shipped to the locations and installed by the end users. There are 
> essentially no techs on location. The users may add or remove boxes at 
> random, or not turn one on, etc.

	Is there any (logical to your product) reason why they would do
this, or is it just "users will be users, and break any system in
inventive ways without ever reading the docs"?
 
> I don't. As far as I know, you can ping with a conflicting IP (you'll
> just get packets meant for other people too).

	And sometimes (depending on network topology and what your
switches are) you won't get any pings back.  Even possibly booting with
a duplicate IP is a bad idea -- some switches will turn off both ports,
and neither box will have connectivity.  It will usually work, but is
sub-optimal design.  In the long run, it's usually better to avoid
giving yourself headaches like that.  [grin]

> So I can set them to default to some IP, ping their randomly selected
> one, if there is no response from that IP, they can keep it. (If
> there's another box with the same default IP pinging a different
> target IP, it should be ignore as the return will not come from the IP
> selected). Once a valid IP is gotten, the network cards can be turned
> off and on again with the correct IP. (Then have to check for
> collisions if another machine has grabbed the IP in the mean time).

	That is kind of ugly, in case of the above sort of switching.
If your end-users aren't technical, they probably won't be able to tell
you much more than "it doesn't work -- yep, it's on, but it doesn't
work".  Is it too much to hope that you can put in the SLA for your
product, "You must have X free IP addresses for us to use to use our
product.  You must tell us what they are."?  Or maybe design some status
lights into the product (Ethernet link and activity, even, though a
"ping up" light would be nice)?  I don't know how much control you have
over the actual hardware design.

Cheers,
Raven

"What happens if you boot without the boot disk?  Where does it die?"
"If I boot without any boot diskette, it just boots into Windows."
  -- me and Katie, regarding OS problems