Path: utzoo!attcan!uunet!aecom!glen
From: glen@aecom.YU.EDU (Glen M. Marianko)
Newsgroups: comp.protocols.appletalk
Subject: Appletalk Bridge/Routing Inefficiency?
Message-ID: <2224@aecom.YU.EDU>
Date: 28 Mar 89 01:06:04 GMT
Organization: Albert Einstein College of Medicine, NY
Lines: 35

You learn something new every day - so, why not pass it along.  Well,
here is one that caught me by suprise.

We have an ethernet with two fastpath gateways (doesn't matter which
version/model), Macs connected to the localtalks on each and
an SE AFPServer with Kinetics Etherport card on the ethernet.
I put a Lanalyzer on the ethernet and what I found put me into
a spin which didn't end until a gracious engineer at Kinetics explained
things.

Basically, looking at the Lanalyzer when I launched an application from
a Mac on appletalk, I saw packets sometimes go directly to the fastpath
that directly bridged that segment, and - get this - other times it
would go to the OTHER fastpath which would forward the packets to the
bridging fastpath.  Now, to any normal network designer that would
seem like a terrible nono - first it imposes a buffering delay
getting packets from one fastpath to the other, let alone the extra
overhead of heaving more than 2-for-1 packets on the ethernet!

Careful observation of the ethernet showed that the server would
switch to the other gateway after that gateway did a Broadcast.
Assuming you had a large enough application to load, you could see
the path to your Mac alternate from the direct-connect fastpath
to the other and back after the respective broadcasts.

Turns out Appletalk has a single line table in the server for
routing packets to routers/bridges on different segments.  Every
time the fastpath broadcast an "I'm a bridge" packet, the server
would update its table and send the packets to that bridge.

Gee - is it me or do we really NEED Appletalk 2.0 YESTERDAY!
Hail to TCP/IP.

-- Glen Marianko, Supervisor of Data Communications
   glen@aecom.yu.edu