Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!pacbell.com!lll-winken!ptavv.llnl.gov!oberman
From: oberman@ptavv.llnl.gov
Newsgroups: comp.dcom.lans
Subject: Re: TCP/IP and ETHERTALK on same cable?
Message-ID: <1991Apr29.074624.1@ptavv.llnl.gov>
Date: 29 Apr 91 14:46:24 GMT
References: <6458@baird.cs.strath.ac.uk>
Sender: usenet@lll-winken.LLNL.GOV
Lines: 41
Nntp-Posting-Host: ptavv.llnl.gov

In article <6458@baird.cs.strath.ac.uk>, andrew@cs.strath.ac.uk (Andrew Watson) writes:
> I have been given the task of investigating the possibility of networking
> MACs and SPARCs together. Certain applications I want to use are based on
> TCP/IP , eg. NCSA TelNet , while others use Ethertalk. What I am wondering
> is whether it is possible to run both types of application over the same 
> Ethernet network without having to use a gateway?

Sure, it's possible, but EtherTalk is not the most robust of protocols in a
large environment.

We have over 3000 Macs on our network all sharing a common backbone with
DECnet, IP, and lots of other stuff. While most things livwe in peace,
EtherTalk causes a lot of trouble when someone misconfigures a system. I guess
you might say it's too trusting.

As an example, recently someone brought up AppleTalk on a Sun Sparc and
misconfigured it. It started sending out ZIP GetNetInfo Replys claiming the
backbone was a bogus zone. Every system which booted while this was up believed
it and could not connect to the remainder of the network. It took several hours
to track this down and then every system that thought it was in the bogus zone
had to be rebooted.

Other configuration errors can cause Multicast storms, often in the 2000
frame/sec range. Not nice.

But, assuming you can keep users from doing dumb things and yourself from
making mistakes in setup, it works fine. If you can avoid the large backbone
and route most of your traffic, you will most likely find things work pretty
well. Since we have a huge bridged backbone with thousnads of nodes on it, we
are pretty much a worst case scenerio.

Also, try to avoid Phase 1 traffic. Phase 1 was designed for very small nets
and does not scale nearly as well as Phase 2, which in turn still scales
poorly. Phase 1 to Phase 2 transition routers are especially bad things.

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: oberman@icdc.llnl.gov		(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything. Especially
anything gnu.