Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!columbia!amsterdam!dupuy
From: dupuy@amsterdam.columbia.edu (Alexander Dupuy)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Ethernet meltdowns
Message-ID: <4819@columbia.UUCP>
Date: Tue, 14-Jul-87 20:09:54 EDT
Article-I.D.: columbia.4819
Posted: Tue Jul 14 20:09:54 1987
Date-Received: Fri, 17-Jul-87 01:02:09 EDT
References: <8707140733.AA09249@topaz.rutgers.edu>
Sender: nobody@columbia.UUCP
Reply-To: dupuy@amsterdam.columbia.edu (Alexander Dupuy)
Followup-To: comp.protocols.tcp-ip
Distribution: world
Organization: Columbia University Computer Science Dept.
Lines: 37

We once had a similar problem with a broadcast storm started by a diskless
Sun-3 trying to boot without a server.  Although you are correct when you say
that the boot broadcast address is hardwired in the Sun-3 PROMs, there is a
workaround, at least if you aren't on a class A or B network with subnets
(which is the case here at Columbia, and probably at Rutgers, *sigh*).

When a Sun 3 (diskless or otherwise) tries to boot, it looks in the EEPROM on
the CPU board for a default boot device.  If none is found, it takes the first
bootable device it finds, in the order it looks for them: disk, tape, ethernet.

A device spec looks something like this: ty(#,#,#), where ty is the board type
and the three numbers are the controller #, unit #, and partition #.  The
defaults for these are all 0.  In the case of an ethernet device, the unit # is
actually the last component of an internet host number, with 0 signifying the
broadcast address (which is all ones, not zeros).

When a fresh-from-the-factory diskless Sun-3 boots, the PROM, not finding
anything better than an ethernet device to boot from, starts a TFTP boot from
the device ie(0,0,0) or le(0,0,0), which can result in network meltdown if no
server responds (and sometimes even when one does).

However, if the server is at address 128.59.0.110 (say) you can set the default
boot device to be ie(0,110,0), and the only broadcasts which the booting sun
will generate will be the initial RARP and ARP requests that can be answered by
any machine, not just the server.

The catch in this is that if the server is at address 128.59.16.110, the host
part of the address (by the pre-subnetting rules, anyhow) is the number 4206,
and the largest possible unit number is 255.  One hopes that Sun will someday
support subnets in the boot PROM, so that this is no longer a problem; in the
meantime, one might consider using subnet 0 (if that's legal) for Sun diskless
clients and servers.

@alex
---
arpanet: dupuy@columbia.edu
uucp:	...!seismo!columbia!dupuy