[comp.unix.questions] Mixing VAXclusters and SUNs

MACALLSTR@vax1.physics.oxford.ac.uk (07/24/90)

From:           John_Macallister <MACALLSTR@vax1.physics.oxford.ac.uk>


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? I've heard some rumours but would appreciate brief comments from
 anyone with first-hand experience. 
Thanks,
John

bob@MorningStar.Com (Bob Sutterfield) (07/25/90)

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 :-)