Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!ucla-cs!zen!ucbvax!CUNIXC.COLUMBIA.EDU!cck
From: cck@CUNIXC.COLUMBIA.EDU (Charlie C. Kim)
Newsgroups: comp.protocols.appletalk
Subject: Re: Need HELP with caps 4.0
Message-ID: <8709202059.AA06712@columbia.edu>
Date: Sun, 20-Sep-87 16:58:57 EDT
Article-I.D.: columbia.8709202059.AA06712
Posted: Sun Sep 20 16:58:57 1987
Date-Received: Sun, 20-Sep-87 23:38:11 EDT
References: <@andrew.cmu.edu:hp-pcd!orstcs.CS.ORST.EDU!ruffwork@hplabs.hp.com> <782100001@orstcs.CS.ORST.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 106

Some explanation.  Most of the problems I've seen are problems with
setting up the KIP code.  In particular, the usual problem is that
people have not setup things so that all the "routing" is done
correctly.

CAP lets KIP do all the routing.  We've tried other methods in the
past and they are a pain.  However, the KIP method is not fool proof
by any means.

When CAP needs to send a packet, it sends the packet to the gateway
listed in atalk.local under the assumption that it will forward it to
the correct gateway (e.g. appletalk personal network) or host.
Basically, it treats the KIP box as a AppleTalk bridge and assumes
that it has the functionality of an AppleTalk bridge (and when
properly configured it does have all the necessary functionality - it
is a combination AppleTalk bridge and IP router).  By putting your
host (net 55.32, node 1) in atalk.local as the gateway, you are
telling host how to reach that host, but it will not be able to reach
any other host via "AppleTalk" protocols.

Routing of most packets is done by looking up the network (as listed
in atalkatab and sent by atalkad) and replacing the last byte of the
IP address with the node number (e.g. in 128.193.y.x - x gets replaced
with node #).  Thus, a path for registration, etc. can be found.  Important
point: you can only reach the ethernet "subnets" that are specified in
atalkatab.  For instance, if you have entries for 128.193.32 and
128.193.36, but not 128.193.35, then you will not be able to reach
anything on 128.193.35 via the Appletalk protocols.  (Telnet, etc.
works because IP routing is done differently).

NBP lookups are done differently though.  CAP sends a NBP packet type
of "BrLk" ("Bridge Lookup") to the closest "AppleTalk Bridge" (e.g.
the KIP gateway).  The KIP gateway/AppleTalk bridge in turn goes
through it routing tables, as sent by atalkad, and sends a NBP "LkUp"
packet to each valid network/host/kip-box.  It does this in the
following way based up the "flags" field in the atalkatab:
	o if 'K' send a NBP LkUp on the NBP port (wildcarded on
	   AppleTalk net) to the specified AppleTalk bridge (KFPS
	   running KIP).  Since it is a lkup and not brRq pkt, it will
	   be sent to the correct network.  In all present cases, this
	   LkUp pkt should be a broadcast directed to the AppleTalk
	   Personal Network attached to the Kinetics box.
	o if 'N' send a NBP LkUp as a broadcast on the NBP port.
	  - the broadcast address used depends upon the selection of
	   (0,1,2,3).  (wildcard'ed on Appletalk net).  This will be a
	   broadcast on an ethernet network.  Make sure the broadcast
	   address is acceptable for all hosts on the ethernet
	   network.  FAILURE TO DO SO MAY RESULT IN MASSIVE DISRUPTION
	   OF YOUR ETHERNET NETWORK!!!  For instance sending a
	   broadcast of 128.x.255.255 or 128.x.x.255 on a network with
	   BSD 4.2 hosts (that expect broadcasts on 128.59.0.0) may
	   result in a storm of ARP requests from the various BSD 4.2
	   hosts.
	o if 'H' send a NBP LkUp to the specfied host on the KIP
	   redirector socket.  The specfied host should be running
	   atalkrd.  atalkrd listens to the redirector socket and
	   when it receives a packet, it will send it to the list of
	   specified hosts on the NBP port.
If you think carefully about this, you'll see the problem resolves
into how to reach the hosts that have atis running or Macintoshes with
registered names.  Adding support for a direct NBP Lookup route that
would allow people specify which hosts were running atis (e.g have
servers) would simply things, but there are unacceptable penalties in
doing this for larger setups (you are limited to 64 entries in this
atalkatab - this is an implementation problem).

So you see there are two things that get specfied in the atalkatab.
The first is a mapping from the IP address domain to the AppleTalk
address domain.  This part most people get right.  The second is a
specfication for how NBP should be done.  This is something that is
easy to mess up.  YOU MUST GET THE SECOND PART RIGHT TO USE CAP.  All
CAP clients and servers are highly dependent upon being able to do NBP
lookups by their very nature. It could be alleviated in part by making
the Unix hosts into "AppleTalk bridges" as well.  (If zones ever get
implemented, then there will be a greater need for this since you must
have an AppleTalk bridge to reach from one zone to the another).

(By the way, in this particular case, the problem is probably that the
host 128.193.32.1 is subnetted or is a BSD 4.2 based system.  In the
first case, it would expect broadcasts on 128.193.32.255 and in the
second, on 128.193.0.0).

If the answer if the first, you are running with subnets on all your
machines, then the answer is simple - redo things with the flags as
"n1" and be careful about specifying the broadcast address for the
kbox (which really should be for its subnet).

If the answer is the second, then you will have to use the redirector
to do things properly.  You can try playing games with the kbox
broadcast address, but don't count on it working.  There are other
minor problems here too (mostly dealing with the exchange of KBOX
routing data).

If you run hybrid - e.g. partially subnetted and partially not, then
you will have problems.  I speak from experience here - we run most of
our network with LANBridge-100s with a couple of subnetted IP
gateways.  This really makes life interesting.  The only way to
properly deal with this environment is to have zones.  This allows NBP
LkUps to be a bit more directed.  (Actually any environment will gain
from using zones).

Well, enough.

Charlie C. Kim
User Services
Columbia University