Subject: [netatalk-admins] Multi-zone routing

From: Hans Gerwitz <[email-masked]>
Date: Wed, 4 Mar 1998 15:23:24 -0600

Please read patiently, I don't want to leave anything out:

I've just put into production a FreeBSD 2.2.5 box (Dell Dimension 486) 
with netatalk 1.4b2 (no patches).  This machine has three network cards 
(3Com 509b), one to our 'backbone' and the others to subnets.  TCP/IP 
gateway functions are working flawlessly.

I've commented out the two lines in the startup script for afpd and papd, 
as I am only routing on this machine.

atalkd.conf is as follows:
ep0 -phase 2 -net 20 -addr 20.10 -zone "slu" -zone "ACAD" -zone "SLU MED"
ep1 -seed -phase 2 -net 2557 -addr 2557.1 -zone "RH_LAB"
ep2 -seed -phase 2 -net 2444 -addr 2444.1 -zone "MATH_CS"

Note that the first interface, ep0, is the backbone card and is 
auto-configuring wonderfully.

The problem: AppleTalk routing appears to work flawlessly from the 
subnets.  A machine in zone RH_LAB, for example, has no trouble seeing 
items in MATH_CS or any other zone.

>From outside these subnets, though, NBP registration is flakey for the 
zones defined for the subnets (RH_LAB and MATH_CS).  Selecting one of 
these zones from any machine outside the subnets may or may not list 
devices contained within.  Note that the zones are always available, just 
not their contents.  Leaving the chooser open, one can watch the devices 
occasionally appear, only to later disappear.  Leaving machines 
side-by-side (both physically and network-wise) on the chooser, you will 
see only one see into the zones, while the other still cannot.

Once a connection is established with a device, however, it is reliable.

Said another way: NBP registration for seeded networks does not reliably 
broadcast to the non-seed backbone, but is reliable on that and other 
seeded nets.

Finally, some possibly relevant information.  I am getting frequent 
syslog errors from atalkd that read:
"rhrouter atalkd[160]: as_timer sendto: Network is unreachable"

These come in spurts of about 6 every 20 minutes or so.

As I write this, I just received a number of these messages from atalkd:
"rhrouter atalkd[160]: nbp brrq sendto 22921.0: No buffer space available"

There were many of these, each for a different network number (all to the 
.0 broadcast), but not one for every network number on our net.  I should 
note that our AppleTalk network here is a mess, with many, many Novell 
servers that have been improperly set up to seed the backbone, and to 
define zones, even though they do not have subnets (some of these had 
subnets that have been removed, most were simply copied from existing 
misconfigured servers from admin that don't know any better.)  The router 
I've described, though, is the only one experiencing this problem, and 
the Novell-based one it replaced did not experience this, using the same 
network numbers in the same location.

Thanks in advance for any help you can offer.

 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hans Gerwitz                                   [email-masked]
Academic Computing Development, Information Technology Services
Saint Louis University                    <http://www.slu.edu/>

---

From: Julian Elischer <[email-masked]>
Date: Thu, 05 Mar 1998 09:56:52 +0800

> Thanks in advance for any help you can offer.

I did the kernel port of the netatalk stack.
Unfortunatly we don;t have a sufficiently comprehensive atalk network
here however for me to test some of the more complicated scenarios.
Some part that I think may be broken...

1/ handling some loopback situations
2/ handling some broadcast situations.

	 don;t know enough about the higher level protocols to be
able to guess what is wrong and am hoping that people such as 
yourself will be able to give mem good descriptions of what is not
If I can get good descriptions, 
e.g. "loopback packets to my own atalk address do not get back to me"
tehn I can fix them (this was actually the case in 2.2.5 without the
patches in the 2.2.5 erratum page).

you DID apply those patches to 2.2.5 right?

julian