From: paul@cthq.UUCP (Paul G. Smith)
Newsgroups: comp.protocols.appletalk
Subject: Proteon AppleTalk Router problem
Date: 23 Jul 92 18:15:09 GMT
Reply-To: paul@cthq.uucp
Organization: CommsTalk HQ
X-Mailer: uAccess - Macintosh Release: 1.5v4

Hi folks,

My friends have a new problem with their network (previously I reported
problems installing the Apple Internet Router, now solved). This one is
pretty bizarre, so I'm hoping someone out there has a useful suggestion.

The network is a medium sized Ethernet, mostly running non-AppleTalk protocols,
but the building in question contains a single thin EtherTalk bus,
and a single LocalTalk bus (recently bridged using the Apple Router: _not_
the subject of this new problem). Another building on the same site contains
another EtherTalk network, which needs to be connected to the first one
so that Macs can communicate using FileShare.

The problem only concerns the first (original) EtherTalk network, btw.
Note that all the Macs experiencing problems, including the file server,
are on the same EtherTalk cable and in the same zone, with the same
network number (1).

They have several (40 or 50) Proteon Routers on the site, which are used
to route other protocols. One of these is already in place between the two
EtherTalk cables. The IS people decided it would hence be appropriate to
use the Proteon Router to route AppleTalk traffic between the two
networks. Accordingly, they turned on the AT Phase 2 routing component in
the Proteon Router (both the EtherTalk networks are phase 2).

Immediately, the EtherTalk network #1's performance dropped by several orders
of magnitude. Access to the file server took from 5 to 20 times longer.
Turning the AT2 Router off again solved this.

Interestingly, connections (eg to the file server) made _before_ the Proteon
router was 'turned on', in a session, did not suffer the performance drop.

This is the point at which they asked me for some help.

My friends have a license for EtherPeek, and they also have a Spider Ethernet
traffic analyser. Looking at both, it became clear that when a new network
connection was opened up whilst the Proteon Router was routing AT2 traffic,
all the network packets for that connection would be sent first to the router,
and then on to the original destination. If the router was taken down mid-session,
packets would thereafter be sent direct to their true destination.

The higher-level (ie DDP & higher) portions of the packets showed the correct
AppleTalk network/node pairs for the true source and destination of each
packet, but the ELAP headers proved that transmission was taking place in
two steps: first to the router, and then on to the destination.

When the Apple Internet Router was brought on-line (connecting the
LocalTalk cable to the network) as a 'control' I found that: {i} if the
Proteon router was disabled, but the Apple router was running, the above
problem did not happen; {ii} if the Proteon Router was active, the
slowed-down two-step connections would only happen some of the time, and
that in each case they only occurred when the original NBP lookup/response
transactions (searching for the file server, or printer, or whatever) was
answered first by the Proteon router: when the Apple router answered first
a 'proper' connection would be set up.

At the AppleTalk protocol level, the NBP responses and the RTMP packets
emitted by the Proteon Router appear correct. Presumably the problem is
at the ELAP level? I'm not sure I am qualified to identify what/how etc.

Can anyone cast any light on this? Proteon only have one other user who
runs the AppleTalk routing software in the UK, and they are a government
establishment and hence not open to questioning. Proteon UK can't help.

Apologies for the length of this message...


best regards, Paul

----------------------------------------------------------------
Paul G Smith @ CommsTalk HQ       INTERNET:  "paul@cthq.uucp"   
AppleLink: "commstalk.hq" ("commstalk.hq@applelink.apple.com")
tel/fax:   + 44 491 574295  (dial 11 on 2nd dial tone for fax)
snail:	40 St Marks Road, Henley-on-Thames, Oxon. RG9 1LW. UK