Path: utzoo!attcan!uunet!husc6!ogccse!blake!oregon!jqj From: jqj@oregon.uoregon.edu (J Q Johnson) Newsgroups: comp.dcom.lans Subject: Re: Terminal Servers? (problems with Bridge) Message-ID: <136@oregon.uoregon.edu> Date: 28 Dec 88 05:57:14 GMT References: <147@iquery.UUCP> <12380@cup.portal.com> <689@hscfvax.harvard.edu> <480@mmlai.UUCP> <109@oregon.uoregon.edu> <1357@gazette.bcm.tmc.edu> Organization: University of Oregon Lines: 27 In <1357@gazette.bcm.tmc.edu>, sob@watson.bcm.tmc.edu (Stan Barber) replies: >>It should be noted that Bridge/3Com terminal servers can boot themselves >>over the network only from a special-purpose boot node (NCS) running XNS >>(even if you are using a TCP/IP or OSI version of the Bridge t.s.). > This is incorrect. The NCS does NOT run XNS. I have an NCS/AT that runs > TCP/IP just fine, thank you. Interesting. My CS200s (software v 20000) use UDP/IP for everything *except* booting. For booting, they send out XNS IDP packets with network number 0. What version are you running? >>Furthermore, the boot server must be on the SAME XNS NETWORK, normally >>the same Ethernet, as the terminal server. > The must be on the same ETHERNET, not the same XNS network. If you have > a large network that uses bridges or bridging routers, it all works. I stand by my phrasing. They must be on the same XNS network as defined by a this-net (net 0) IDP broadcast. Agreed that this network may contain several segments, and hence need not be "the same ETHERNET". The important thing is that it may not be an XNS internet -- a Hybridge is OK, but not an XNS router. > I agree that the 3Com/Bridge boot system is not the best, but let's try to > argue from accurate information. Agreed. Other problems with the 3Com/Bridge design: the bootstrap process (which uses XNS) does not appear to be able to cope well with lossy networks; the "remote" network management protocol (which uses UDP/IP) has effectively no security except obscurity of the protocol.