From: josh@cayman.com (Josh Littlefield)
Newsgroups: comp.protocols.appletalk
Subject: Re: Proteon AppleTalk Router problem
Date: 23 Jul 92 23:18:15 GMT
Organization: The Internet

>> 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.
....
>> 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.

Here's a wild guess.

I have no experience with Proteon routers in general, or specifically
AppleTalk through a Proteon, but I can explain how what you describe CAN
happen.

It sounds like when the Proteon is off, and the Apple router is not present,
you have no AppleTalk routers on your wire.  Correct?

In this case when a node (A) wishes to locate a service (a user opens the
Chooser) the node broadcasts an NBP LkUp packet directly to the local wire,
and the respective services (B) respond directly to the sending node.

In the case where a router is present, the same node (A) looking for a service
(in a particular zone) must send an NBP BrRq (Broadcast Request) to the router
in order have it, in turn, cause NBP LkUp packets to be broadcast on all
networks with the specified zone name.  For the local wire, the router would
be generating the broadcast NBP LkUp packets.  The respective services (B)
will respond to this lookup.

IF the router generates an NBP LkUp packet with a DDP source address set to
the address of the originating node (A), and a hop count of zero, the
receiving nodes (B) can (incorrectly) GLEEN an AARP entry mapping the node A
DDP address to the Router Ethernet address.  From now on when node B sends to
node A, it will use the Ethernet address of the router, causing all data from
B to A to go through the router.

	A            B          Router
	+------------+-----------+

1)	NBP BrRq-->----->---->-->+
2)	+<===<====<==+==<==NBP LkUp (broadcast)
3)                   NBP Rply>-->|
        +<---<----<-----<----<---|



If you see traffic from A to B also going through the router, it could result
from an overly generous implementation of a "best router cache".  I can
imagine an explanation for this, too, but it seems more far-fetched.  I KNOW
the situation I've descibed above will occur if a router behaves as I've
indicated.

Hope this helps.

-josh

/--------------------------------------*--------------------------------------\
| Josh Littlefield                                     Cayman Systems, Inc.   |
| josh@cayman.com                                      University Park at MIT |
| (617) 494-1999                                       26 Landsdowne Street   |
| fax: (617) 494-5167                                  Cambridge, MA  02139   |
\--------------------------------------*--------------------------------------/