RICKG@gemew1.sdr.slb.com (Richard Goldsmith : MERLIN) (02/01/89)
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@gemew1.sdr.slb.com (Internet)