From: trier@slc6.ins.cwru.edu (Stephen C. Trier)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: BootP experience
Date: 29 Dec 1992 19:03:18 GMT
Organization: Case Western Reserve University, Cleveland OH (USA)
NNTP-Posting-Host: slc6.ins.cwru.edu

Hello, Scott!

You write:
>It seems to work great, but I'd like some feedback from someone using
>this in the real world managing 1000+ machines.

We fit, then.  The last time I checked, we had 3000 machines on our net,
of which about 2500 use BOOTP for configuration.  About 2/3 of those are
MS-DOS, and the rest are Macs.  Probably about a dozen systems use BOOTP
for booting; the rest use it strictly for IP configuration.

>Some of my questions include: How many servers per x nodes/nets?

The standard Unix BOOTP servers use hash tables for their addresses, so
they scale surprigingly well.  We have two main BOOTP servers, for
redundancy, with 4200 lines in the BOOTP table.  (No, I don't know why
there are so many entries for only 3000 hosts.  Either there's some
redundancy in there, someone hasn't been deleting retired network cards,
or my size numbers are out-of-date.)

By the way, we include all known systems in our BOOTP table, not just
those that need BOOTP.  You might want to consider this -- this turned
out to be much more convenient than I expected.

>Has anyone modified bootp to dynamically assign IP addresses to portable
>(palm-/lap-tops) machines?

We treat portables just like normal machines, but we can get away with
that because we are not subnetted.  I don't know how you'd deal with them
on a routed network.

I have heard of dynamic RARP servers.  I do not know whether dynamic
BOOTP servers exist.

>Have any security issues arisen from using BootP?

This has crossed my mind.  Some denial of service attacks are possible
when using BOOTP for config info, but they seem not to be too severe.
I haven't been able to come up with major problems in it when it is used
only for bland config info.

BOOTP-to-boot opens up a whole batch of possible holes, because the boot
kernel is then up for grabs -- anyone who feels like running BOOTP and
TFTP servers can control what kernel the booting machine gets.  That
obviously opens a large can of worms.

Since we use BOOTP pretty much only for config purposes, this latter hole
is not a problem.  The weakness is also common to most diskless-booting
schemes, not just BOOTP.

The thing to remember is that BOOTP should not change your trust decisions,
because there is no way to guarantee that a supposedly BOOTP-configured
machine is what it says it is.

>How much of an impact does using BootP have on a network in terms of
>broadcasts/second?

The impact is utterly miniscule.  I can't get hard numbers for you because
of the date (much of the campus is not here this week), but I can assure
you that we see far more traffic from ARP than from BOOTP.

You can compute some rough numbers yourself.  Assume 1000 computers, all
getting restarted once an hour, 24 hours a day, and assuming that the BOOTP
server always answers their requests on the first try, you should be seeing
one BOOTP broadcast every 3.6 seconds.

These numbers are tuned for worst-case.  Around here, we see one or two
BOOTP broadcasts a minute.

If you are really interested in some hard numbers, drop me a note around
January 20, the beginning of the new semester, and I'll grab a network
analyzer trace to see what kind of numbers we get.  I could also get you
some real numbers on how many machines run BOOTP.

>Is there anything I should be aware of before I start migrating the entire
>company to use BootP?

Not that I can think of.  BOOTP is an incredible boon for large networks.
It saves _immense_ headaches.  We have a base software package that everyone
gets when they get a network card.  (They can add on whatever specialized
packages they need.)  Once the network card driver is installed on the
machine, *no* further customization is necessary.  People can delete their
software and replace it with a copy of their neighbors, and no address
conflicts will result.  It saves a lot of hassle.

-- 
Stephen Trier                      "We want to offer you a price that you
Network software type               just can't afford to take advantage of."
Case Western Reserve University         - Sales blurb from HSC Software
trier@ins.cwru.edu