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