Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!mstar!mstar.morningstar.com!bob From: bob@MorningStar.Com (Bob Sutterfield) Newsgroups: comp.unix.questions Subject: Re: Mixing VAXclusters and SUNs Message-ID: Date: 24 Jul 90 20:51:41 GMT References: <23948@adm.BRL.MIL> Sender: usenet@MorningStar.COM (USENET Administrator) Reply-To: bob@MorningStar.Com (Bob Sutterfield) Organization: Morning Star Technologies Lines: 36 In-Reply-To: MACALLSTR@vax1.physics.oxford.ac.uk's message of 24 Jul 90 10:55:19 GMT In article <23948@adm.BRL.MIL> MACALLSTR@vax1.physics.oxford.ac.uk writes: We're about to add some SUN's to our Ethernet on which there are already 15+ VAX/VMS systems in a VAXcluster , 20+ terminal servers, 30+ IBM PC's using DECnet/PCSA/LANWORKS and an Apollo DN10000VS. Are there any gotchas to beware of? Assuming everyone's talking legal Ethernet or 802.3 or whatever, there should be no coexistence problems on the wire itself. Since you've already got quite a variety of toys, you've probably already passed that first test and won't need to worry about it any more. Many protocol suites can share the same wire (IP, DECnet, XNS, Appletalk, Banyan, 3Com, Novell...) without interfering with each other. You'll have more fun making everything talk to each other, but that's what IP is for. Since you mention only one Ethernet, you will need to worry about network traffic capacity at some point, particularly if you plan to run many of your workstations without disks. The usual solution is network segmentation, putting subcommunities behind firewalls of various sorts so that they can get to their most frequent conversation partners without bothering anyone else on the wire. What sort of segmenters you choose depends upon what sorts of interoperability you want with the folks on the other side of the firewall. They are available at each of the various levels of the network stack, and some are hybrids. Repeaters can extend the geographical coverage of your network but won't help with traffic problems. Bridges are protocol independent, but introduce potential management headaches. Routers know about particular protocol suites (some know about several), and can be used to build huge internets based on subcommunities of their favorite protocols. Gateways can enable disparate protocol suites to talk to each other in various (usually limited) ways, usually by interconnecting at the application level. Then there are "long-haul bridges" and "brouters" and "routing gateways", and the network equipment salesman's head disappears into a classic network cloud :-)