[Techtalk] serverless IP assignment?

[Raven, corporate courtesan]

Heya --

Quoth Malcolm (Mon, Feb 11, 2002 at 04:33:27PM -0500):
> > 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?
> 
> I have control over the IP space (it's set up on one of the "internal use 
> only" IP ranges).

	Okay -- that makes this easier.
 
> There is a potential for one non-our box existing on the network. It's IP is 
> known before hand however so we can avoid that IP. 

	Cool.
 
> There is logical for product reason for people to add new boxes, remove ones 
> that break, move them around the physical network (or between locations 
> owned by them). Having them forget to turn a machine on, or only run part of 
> their network at some times, is also likely.

	Okay -- what I would do if I were you...

	Assuming that you have 10.1.1.0/24 as your available subnet, and
you know that 10.1.1.1 is your gateway and 10.1.1.2 is that other
machine whose IP you have to avoid...

	When the machine boots, give it a starting IP randomly selected
from 10.1.1.250 to 10.1.1.254.  (Can you script in just picking one out
of your boot script?  Or you can randomize and hard code in as you
like.)  It then tries pinging the first available addresses in your
pool.  It will take the first available one (that doesn't reply).  So,
here's the sequence.

	Machine boots with 10.1.1.251.  Gateway IP and routing are
already coded in.  Machine pings 10.1.1.3 (the first available address).
It recieves a reply.  Machine pings 10.1.1.4.  It recieves a reply.
Machine pings 10.1.1.5.  No reply.  Machine ifdown's, and ifups with IP
of 10.1.1.5.  (Maybe? It rewrites this into its config files so that if it's
powercycled, it keeps its new IP.)

	This approach has several advantages.  Your IPs will be in
roughly sequential order.  This makes them a lot easier to keep track
of.  You won't have any machines likely to be sitting on the IPs that
newly booted machines will be using (thus making the duplicate IPs a lot
less likely).

	The big remaining design decision -- once the machine has a
"real" IP, do you want it to keep it?  If so, then you may have problems
if a broken machine is removed from the network and then put back in.
Say you have five machines on a given network.  They are:

10.1.1.3
10.1.1.4
10.1.1.5
10.1.1.6
10.1.1.7

	During a thunderstorm, 10.1.1.5 sparks and dies.  They take it
off the network.  They plug in a replacement machine, which takes the
first available IP (10.1.1.5).  The broken machine is fixed and returned
to service -- with 10.1.1.5.  Bingo -- duplicate IP again.  

	If all broken machines are going to be shipped back to y'all for
repair, this is okay -- you can just reimage it and have it search for
an IP again when it's plugged in.

	The reason you might want machines to keep their IPs is power
cuts.  When your five machines on a network all come back up, chances
are that they won't all grab unique IPs out of the booting pool, and you
have conflict and problems again.  If you had six machines on the
network and five booting IPs, you know there'll be at least one set of
duplicates.  This is bad, too.  It can be somewhat ameliorated by having
a large pool of IPs to boot with, but I don't know how much space you've
got to play with, or how many machines are likely to be on one network.

	The tradeoff is power-cut management (assuming the boxes aren't
all on good UPSs) or brokenness management.  If you're going to have
users moving machines between locations and you have different subnets
for those locations, then you're stuck with autodetect every time.  Pick
whichever one's best for your setup and run with that.  

> Topology is basically everyone on the same subnet. No routers or anything to 
> worry about. Sometimes the boxes may be run as standalone machines (no 
> network at all).

	How are you handling DNS and routing, then?  Default gateway to
something on your network?
 
> > Even possibly booting with a duplicate IP is a bad idea -- some
> > switches will turn off both ports, and neither box will have
> > connectivity.  
> 
> Not a problem as there's no switches involved.

	It's less bad if it's all hubs, but still somewhat unhappy.
 
> > I don't know how much control you have over the actual hardware design.
> 
> None basically. Half the systems concerned are legacy systems, so even if I 
> did, I have no ability to retrofit hardware on those already in the field.
 
	Will you be able to push your new code onto the boxes already
in the field, or will you have to interoperate with however they get
their IPs?  (If the latter, the above solution should work around that.)

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