[comp.protocols.appletalk] One way AppleTalk?

george@swbatl.sbc.com (George Nincehelser 5-6544) (11/02/90)

I've run across a strange problem with our company's AppleTalk networks.  I've
got a guy installing a Shiva Fastpath 4 several states away who is having
problems seeing devices within certain zones that are local to me.  He sees
the zone names, but he can't see any devices in them.  We've used InterPoll
to confirm this (scanning for severl minutes).

We are running a Phase 1 network.

Any ideas?

-- 
   /   George D. Nincehelser           \  uunet!swbatl!george       \
  / /   Southwestern Bell Telephone     \  Phone: (314) 235-6544     \
 / / /   Advanced Technology Laboratory  \  Fax:  (314) 235-5797      \
/ / / /\  1010 Pine, St. Louis, MO 63101  \  de asini umbra disceptare \

jln@casbah.acns.nwu.edu (John Norstad) (11/03/90)

In article <1990Nov2.001254.12845@swbatl.sbc.com> george@swbatl.sbc.com 
(George Nincehelser 5-6544) writes:

> I've run across a strange problem with our company's AppleTalk networks. 
 > I've got a guy installing a Shiva Fastpath 4 several states away who is 
> having problems seeing devices within certain zones that are local to me.  
> He sees the zone names, but he can't see any devices in them.  We've used 
> InterPoll to confirm this (scanning for several minutes).
> 
> We are running a Phase 1 network.

Very interesting.  I'm currently struggling with similar problems, only in 
my case all my FastPath 4 boxes work fine.  Instead, I'm having this same 
problem with Shiva NetBridges, a TurboBridge, and IPTalk/atalkad-tunneled 
Gatorboxes!

As an example, I'll discuss a Shiva NetBridge case.  Here's a picture of 
part of our large campus AppleTalk Internet (we have about 40 nets and 27 
zones total in our Internet).  All of the nets in this picture are 
LocalTalk. (For best results, view this picture using a monospace font!)

        /------------------/ net A         /-----------------/ net B
               |                                    |
         Shiva NetBridge                    Hayes InterBridge
               |                                    |
   /---------------------------------------------------------/ net C
                          |
                 Hayes InterBridge
                          |
                  /-----------------------------/ net D
                                |
                          Shiva FastPath 4
                                |  
                               ...  IPTalk Tunnel
                                |
                          Shiva FastPath 4
                                |
                     /---------------------/ net E                         
                           

All 27 zone names appear properly in the Chooser on Macs on net A, but 
nothing can be found inside some of the zones (in either the Chooser or 
with Interpol).  I'll call such zones "empty."  In particular, in the 
diagram above, the zones for nets B and D are empty, while the zones for 
nets C and E are normal (non-empty).

It's interesting that the empty zones are exactly the ones whose nets are
immediately "behind" a Hayes InterBridge from net A's point of view.  Zones 
whose nets are immediately "behind" other kinds of routers are normal.  
This is true not only in the small picture I've presented above, but 
throughout our complete Internet - there are about 10 empty zones behind 
InterBridges total from the point of view of Macs on net A.

It's also interesting that net D is empty, while net E is normal, since 
traffic from net A must pass through net D to reach net E. So net A can 
see "through" net D, even though is can't see "in" net D.

I examined the routing and zone information tables inside both the NetBridge
and the InterBridge connecting nets B and C.  Both were perfectly normal - 
correct network numbers, next router fields, hop counts, status, and zone 
names for all of our zones and nets.  So it appears that the routers are 
communicating with each other using RTMP and ZIP correctly. In particular, 
the NetBridge's routing table entry for net B correctly pointed to the 
InterBridge joining nets B and C, with a hop count of 1, status "good", 
and the proper zone name in the ZIT.  Similarly, the InterBridge's routing 
table entry for net A correctly pointed to the NetBridge with a hop count of 1, status "good", and the proper zone name in the ZIT.

The problem is not symmetric: All the other nets on campus can see devices 
inside net A just fine.

We're using phase 1 also.  No phase 2 is involved anywhere here.  I checked, 
and as far as I can tell I have NOT enabled any zone "hiding" or "filtering" 
options in any of my routers, and all of my routers are configured to do 
phase 1 routing, not phase 2.

There must be something going wrong with the NBP Broadcast Request and 
zone-wide NBP Lookup broadcast mechanisms used to locate devices in zones. 
 
I wish I had a LocalTalk protocol analyzer to  investigate this problem in 
more detail, but I don't (we have one on order).

It's interesting that we're having this same problem with two different 
new Shiva NetBridges on campus (ROM v2.01).  A third older Shiva NetBridge 
(ROM v1.02) on campus in a similar configuration works just fine!

My problems with Gatorboxes and the TurboBridge are similar but not 
identical.  They also involve this "empty zone" phenomenon.

Has anybody else ever experienced this kind of problem?  What can cause 
it?  It's a mystery to me right now.  I have a natural suspicion that my 
problems are all related and may have a common cause, but I have no idea what that cause might be.  It is also possible that there is no common cause, and I
really have three separate problems.

John Norstad
Academic Computing and Network Services
Northwestern University
jln@casbah.acns.nwu.edu

josh@CAYMAN.COM (Josh Littlefield) (11/04/90)

>> > I've run across a strange problem with our company's AppleTalk networks. 
>>  > I've got a guy installing a Shiva Fastpath 4 several states away who is 
>> > having problems seeing devices within certain zones that are local to me.  
>> > He sees the zone names, but he can't see any devices in them.  We've used 
>> > InterPoll to confirm this (scanning for several minutes).
>> > 
>> > We are running a Phase 1 network.
>> 
>> Very interesting.  I'm currently struggling with similar problems, only in 
>> my case all my FastPath 4 boxes work fine.  Instead, I'm having this same 
>> problem with Shiva NetBridges, a TurboBridge, and IPTalk/atalkad-tunneled 
>> Gatorboxes!

[...lines deleted...]

>> There must be something going wrong with the NBP Broadcast Request and 
>> zone-wide NBP Lookup broadcast mechanisms used to locate devices in zones. 

Sounds like a you are suffering from a Phase 1/2 incompatibility.
Although you are not running Phase 2 EtherTalk, your new NetBridge
may be running Phase 2 LocalTalk.  For LocalTalk, there are indeed
changes associated with Phase 2.  Mostly it is in the form of the
RTMP packet, which can now describe extended networks on the AppleTalk
internet, and which was designed to be backward compatible.  However,
one additionally change was the addition of a the NBP Forward Request
packet. A router receiving an NBP Broadcast Request turns it into an
NBP Forward Request (instead of the old-style NBP Lookup directed
broadcast) and sends it on.  The last router is supposed to turn it
into an NBP Lookup broadcast.  But if the last router is a Phase 1
Hayes Interbridge, it won't work correctly.  The FwdReq packet, whose
DDP destination addr is (net N, node 0) will be dropped.

The fact that the older Shiva NetBridge has no trouble, but the newer
ones do would reinforce this guess.  As for the GatorBox, we will
generate a Forward request if the outbound interface is Phase 2, and
a directed NBP Lookup instead if the interface is Phase 1.  Release
1.5.0 always set our LocalTalk interface to Phase 2.  Our latest
releases (1.5.1 and now 1.6.0) allow LocalTalk to be set to Phase 1.
We consider atalkad tunnels to be Phase 1 and GatorBox point-to-point
tunnels to be Phase 2.

>> I wish I had a LocalTalk protocol analyzer to  investigate this problem in 
>> more detail, but I don't (we have one on order).

You may be interested in trying Watch.  Watch 1.6.1 is available for
anonymous FTP from cayman.cayman.com (192.31.222.1) in
~ftp/pub/Watch/watch.1.6.1.sit.hqx.  Watch will capture packets on
either LocalTalk or Ethernet (although it only supports a few Ethernet
cards).  It does a pretty good job of protocol decoding and may help
analyze your problems.  I use it instead of a LocalTalk sniffer and am
pretty happy with it.  It is unsupported, but freely available.
Constructive criticism is always welcome.

Hope this helps.

-josh

------------------------------------------------------------------------------
Josh Littlefield					Cayman Systems, Inc.
Engineering						University Park at MIT
josh@cayman.com 					26 Landsdowne Street
(617) 494-1999  					Cambridge, MA  02139
------------------------------------------------------------------------------