Subject: Re: questions to netatalk
From: Charles Clark (cmclark@umich.edu)
Date: Sat Nov 28 1992 - 13:59:37 EST
> From: roeck@conware.de (Guenter Roeck)
> Hello,
>
> I am an implementer of AppleTalk router software at Conware GmbH. After
> examination of the Michigan implementation netatalk 1.2.1 and comparison with
etc. This was mailed to us at Uof Michigan and replied to the original
author by wes. Here is the content of his reply, FYI.
From: wes.craig@umich.edu
Subject: Re: Request for comments to netatalk 1.2.1
To: JUELG <juelg@ccmailgate.conware.de>
cc: netatalk@itd.umich.edu
Date: Thu, 26 Nov 92 21:57:16 -0500
----------------
> From: JUELG <juelg@ccmailgate.conware.de>
> To: netatalk@itd.umich.edu
Konrad, thanks for the comments. You have obviously spent significant
time looking over the code. I think that's great, so I'll try to take
as much care with my reply.
> NBP:
> 1. In NBP e.g. register packets are sent to the AppleTalk
> internet address 0000.00 .I assume that these packets are
> handled by DDP as local packets and no packets are sent out
> to any data link. Is this assumption correct ?
Right. ATADDR_ANYNET.ATADDR_ANYNODE (0.0 on suns, 65535.0 on 4.4BSD
machines) is the configured loopback interface. Currently, atalkd
manages the local machine's NBP database. Some method was needed to
communicate with atalkd for name registration and deletetion. We
picked a new NBP type, since that would localize the database control
in the same code as NBP lookups, etc.
We're currently considering putting the NBP database in the kernel, so
that when sockets go away, the NBP name is automatically deleted.
> RTMP:
> 2. Bad entries are not deleted from the routing table at a
> RT-check.
This is true. They are marked as deleted, however, and should not be
sent out (see below).
> 3. Bad entries and entries with a distance >= 15 are included
> in RTMP data packets. Bad entries are sent with the distance
> given in the routing table.
Yup. This is a bug. There is actually a patch that corrects the
second problem, sending out entries with bogus distances. I'm
surprised that you are the first to mention the former problem...
> 4. A routing table entry does not have a port number associated
> with it.
It has a gateway associated with it, so we can calculate the port. (As
a matter of fact, the 1.3 version of atalkd has an interface list, a
gateway list, and a route list, each depending from the next higher
entry -- routes are under gateways, which are under interfaces. This
way we can keep track of the full routing set for each router and can
immediately have an alternate route when a router goes down, and
implement split horizon routing at little cost.)
> 5. Only better routes are accepted from any neighboured
> routers. AppleTalk Phase I (the book) also accepts routes
> with equal distances.
Since on unix, there is no atomic modify for routes, to change the
route each time we receive a route of equal distance will cause holes
in our routing.
> 6. No worse route is accepted, if the routing table entry's
> gateway is equal to the source address in the RTMP packet
> (and the ports are equal).
Good point. We should be doing this.
> 7. Split horizon is applied (split horizon is not defined in
> Phase I).
Even tho it's not in the phase 1 spec, we do split horizon because it
makes too much sense. As a matter of fact, we were doing split horizon
routing before phase 2 was released.
> 8. Each router must read the source of a RTMP data or a RTMP
> response packet if the receiving port isn't already
> configured with a nonzero network number. This is not being
> done in netatalk. Thus, how is the port being configured if
> it's not a seed router ?
In 1.2.1 and earlier, we don't do auto-configuration net numbers.
Version 1.3 can auto-configure everything (both phase 1 and 2), and
*always* goes through auto-configuration in case there is a
configuration conflict with some other router.
> 9. Only a timer of 30 seconds is used for both the validity and
> the send timer. Accordingly to the specification of Phase I
> the following timer values must be used:
> validity timer 20 seconds
> send timer 10 seconds
Yes. The alarm should actually be 10 seconds. If this is done, the
validity timer is then correct at 20 seconds (it is currently 60
seconds, two alarm cycles).
> Point 2. could cause a large routing table, and together with
> point 3. will result in large RTMP data packets. Also the
> exhaustive search through the RT is more expensive in computing
> time.
Right. As I mentioned, this is fixed in version 1.3.
> Furthermore, counting to infinity can occur in case of split
> horizon. Therefore the distance of entries should be checked
> before updating routing entries or no routing information may
> be sent about routes with a distance greater than 14. Otherwise
> counting to infinity wouldn't break.
There is a patch that fixes the problem of accepting routes with bad
distances. I'm not sure what you're trying to say regarding counting
to infinity. My understanding is that phase 1 guarentees that counting
to infinity will be a problem. Split horizon works to fix the
problem.
>ZIP:
> 10. ZIP Takedown and ZIP Bringup are not handled.
The implementation is that we don't accept Takedown and Bringup. This
is primarily a security decision.
> 11. The ZIP Query-Retransmission timer is set to 30 seconds
> (Phase I defines 10 seconds).
As in the rtmp timers, the alarm should actually to 10 seconds, not 30
seconds. This was especially problematic on our campus, since proteon
routers only send one tuple in ZIP replies. Since we send as many
tuples as will fit in our ZIP queries, and only queue 10 packets at the
ddp layer, we would only get about 12 ZIP replies during each ZIP query
transmission. Compared to the ~150 networks we had at the time, this
made convergence take a long time.
wes
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:09:05 EST