Booting diskless Suns over Ethernet "Bridges"

[Richard Goldsmith : MERLIN]

In response to    . . .
>I am looking for information relative to booting across an Ethernet
>Bridge....

Although I am not familiar with "T1" links, the set-up looks similar to
ours, where we have "Filtered Repeaters" connecting physically separate
ethernet segments into one LOGICAL ethernet, rather than "bridges" which
by definition would have addresses on two networks. 

The repeaters are said to be promiscuous, i.e. they grab everything they
see and copy it to the other end of a serial link and re-transmit it
unchanged onto the other segment. Because there is always a bandwidth
bottleneck, they would typically "learn" which source and destination
addresses require packet copying and reject/ignore those which are
contained at one segment end only. 

They have only one transceiver which inevitably cannot accept all packets
all the time on a heavily loaded network, and will then just fail to copy
some over. This is not serious when full acknowledge protocols are
employed because "lost" packets will be re-transmitted from source when
the acknowledge timeout expires. This can cause detectable delays however,
if it happens regularly.

We have found that a 64K serial link copes with all traffic between
segments with three transceivers at each end. The more transceivers that
are able to generate packets on a segment, the greater the maximum arrival
rate at the filtered repeater. The lance chip will cope but the buffering
in the repeater's memory will run out, and because it is not responsible
for acknowledgeing the packets itself (its own ethernet address is not
known to the hosts, nor even inserted in the packets), it cannot let the
originator know that the packet has become lost.

The real problem with BOOTING over such a link is that there will be no
mechanism for detecting and retransmitting lost packets. Using multiple
repeaters is dangerous because the packets are not number sequenced (in
the case of 3-Com terminal servers/network control server as we have
attempted, and possibly sun/sun also). Another factor going against you is
that during the boot download, the packet output rate is likely to be
higher than in all other situations (except "ping" which can swamp
anything).

We totally failed to boot a terminal server over our link and 3-com
predicted that it would not be guaranteed even if we upgraded the serial
link to 2Mb/sec - but it might just work! The boot file in this case is
much smaller than that required for a sun so I would estimate that it
would be foolhardy to rely on anything less than 4Mb/sec to succeed.
Ideally a microwave/fibre optic 10Mb/sec repeater link should be
considered.

If true "bridges" were used and the two ethernet segments were not
logically sharing the same network address space, the transfer problem
would be overcome, but you will have to check with sun if the software can
be made to boot over such an arrangement, as I doubt it will be able to
set the internet part of the address for booting transfers.

The only safe alternative to a 10Mb/sec link, is to have one sun at each
end with a disk to act as boot server to the local segment. 

The suppliers are right to remain uncommited because even if you get it to
work over a 1.5Mb/sec link one day, another day the different traffic
loading will make it fail.

The only way to find out is "suck it and see", but be prepared for some
dissappointment.

Hope this increases understanding.

Richard Goldsmith.  			M_GEMEW1::RICKG		(SINet)
					rickg at gemew1.sdr.slb.com (Internet)