Subject: netatalk, zones & routers

From: Jon Piesing <[email-masked]>
Date: Wed, 19 Jan 94 14:46:06 GMT

This question really belongs in an FAQ but I haven't managed to find one so ......

Currently we are using netatalk 1.3 on one of the networks here. We want to put
some Macs on another network. The two networks are connected by a number of Suns
each of which have 2 ethernet interfaces.

As an experiment, I configured one of these Suns to have netatalk running on
both interfaces and then setup netatalk on a Sun on the 'other' network. I then used
aecho to try and get the two Suns to talk to each other. It doesn't work, aecho does
work between Suns on the current network. ( The atalkd.conf files for both of these
machines are below ).

If I use "etherfind -apple" on the gateway machine I get the following output
when I use "aecho" on the Sun on the 'other' network to try and talk to the
gateway. I get nothing if I use aecho on the gateway to try and talk to the
Sun on the 'other' network.

# etherfind -apple
Using interface le0
                                            icmp type
 lnth proto         source     destination   src port   dst port
   67  AppleTalk  8:0:20:9:aa:ae -> 9:0:7:ff:ff:ff
   66  AppleTalk  8:0:20:9:aa:ae -> 9:0:7:ff:ff:ff
   66  AppleTalk  8:0:20:9:aa:ae -> 9:0:7:ff:ff:ff
   66  AppleTalk  8:0:20:9:aa:ae -> 9:0:7:ff:ff:ff
 
In the man page for atalkd there is the following sentence "atalkd automatically acts as 
a router if there is more  than one interface." Does this mean that atalkd would let
Macs on the two different networks talk to eachother ? Would let us backup Macs
on one network to an exabyte on the other network using Retrospect Remote ?

Thanks in advance.

Jon Piesing
Philips Research Redhill UK

The atalkd.conf file for the gateway Sun is :-

#
# Format of lines in this file:
#
#    interface [ -seed ] [ -phase { 1 | 2 } ] [ -addr net.node ]
#       [ -net first[-last] ] [ -zone ZoneName ] ...
#
# -seed only works if you have multi-interfaces.  Any missing arguments are
# automatically configured from the network.  Note: lines can't actually be
# split, tho it's a good idea.
#
# le1 = network all Macs are currently connected to
le1 -phase 2
# le0 - network we would like to connect some Macs to
le0 -seed -phase 2 -net 9461-9471 -zone PRL

The atalkd.conf file for the Sun connected to the same network as le0 above is :-

#
# Format of lines in this file:
#
#    interface [ -seed ] [ -phase { 1 | 2 } ] [ -addr net.node ]
#       [ -net first[-last] ] [ -zone ZoneName ] ...
#
# -seed only works if you have multi-interfaces.  Any missing arguments are
# automatically configured from the network.  Note: lines can't actually be
# split, tho it's a good idea.
#
le0 -phase 2 -net 9461 -zone PRL

---

From: [email-masked]
Date: Wed, 19 Jan 1994 18:18:17 -0500

> From:    Jon Piesing <[email-masked]>
> To:      [email-masked]

> This question really belongs in an FAQ but I haven't managed to

There is one, for anon-ftp in terminator.  However, I don't think it
would answer any of the questions you've posed.

> Does this mean that atalkd would let Macs on the two different networks
> talk to each other?

Yes, certainly.  The machine I sit at acts as a router for a variety of
machines, for AppleTalk and IP.

> le0 -phase 2 -net 9461 -zone PRL

So, it appears that you don't have any AppleTalk routers, other than
the netatalk machine you're trying to bring up.  If that's the case,
then the le1 interface will need to have network numbers defined.  For
instance, your atalkd.conf on the router could be

    le0 -seed -phase 2 -net 1 -zone PRL
    le1 -seed -phase 2 -net 2 -zone PRL

If you do have another router on the le1 interface, then you
configuration is fine, if a little esoteric, e.g. do you really need
room for 2500 nodes on the le0 interface?

Just in general, the non-routing machine doesn't need an atalkd.conf,
at all.  It will dynamically configure.  Having (incorrect) information
in a machine's atalkd.conf can cause problems similar to what you
describe, since atalkd is not as good as it could be at ignoring
incorrect information.

:wes